| 00:02.55 | Dovid | so ${AGIEXITONHANGUP} would kill it instantly and wont let it complete. correcT? I assume the correct way would be to do Set(AGIEXITONHANGUP=yes) or is it Set(${AGIEXITONHANGUP}=yes) ? |
| 00:04.17 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 00:04.17 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 01:10.30 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-xbicaupqfvfwboug) |
| 03:46.31 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 04:07.46 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 06:30.17 | *** join/#asterisk-dev snuff-home (~brad@203-219-29-182.tpgi.com.au) |
| 06:30.26 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 06:40.03 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 06:42.40 | *** join/#asterisk-dev danjenkins (~dan@mail.hotel-latour.co.uk) |
| 07:27.55 | *** join/#asterisk-dev danjenkins (~dan@91.229.124.114) |
| 08:02.06 | *** join/#asterisk-dev wanna (~wanna@194.183.244.5) |
| 08:08.55 | *** join/#asterisk-dev danjenkins (~dan@91.229.124.114) |
| 08:25.47 | *** join/#asterisk-dev danjenkins (~dan@91.229.124.114) |
| 09:44.06 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 09:44.06 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Asterisk 13.0.0-beta1 now released. Do the (beta) release dance! -=- Follow on Twitter at @AsteriskDev |
| 09:56.36 | *** join/#asterisk-dev jsmith (~jsmith@fedora/jsmith) |
| 09:56.37 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 11:17.28 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 11:17.30 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 12:19.37 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-nrvkmtjkhtoxdzxy) |
| 12:38.43 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-jaowwhslkzveyyif) |
| 12:39.24 | *** join/#asterisk-dev Dovid (~Dovid@static-173-63-105-210.nwrknj.fios.verizon.net) |
| 13:04.12 | *** join/#asterisk-dev leifmadsen (~free-mads@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:04.12 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:04.25 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-tlayaxgmszwsvtlj) |
| 13:04.25 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:14.51 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-euuqenpunsoumcae) |
| 13:14.51 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:17.45 | *** join/#asterisk-dev ovoshlook (55158cfd@gateway/web/freenode/ip.85.21.140.253) |
| 13:18.08 | ovoshlook | Hello. When do call have this error |
| 13:18.11 | ovoshlook | ast_rtp_new: Oh dear... we couldn't allocate a port for RTP instance '0x7f00b81c7028' |
| 13:19.07 | WIMPy | I'd suppose if you have more calls than RTP ports assigned. |
| 13:19.48 | ovoshlook | only 1 call. tested system |
| 13:20.00 | mjordan | this really belongs in #asterisk |
| 13:20.02 | ovoshlook | pots - 6000 |
| 13:41.35 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:41.35 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:02.46 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-zbddgcapubkeqjvi) |
| 14:21.33 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 14:43.38 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:e1b3:169a:3b4c:a150) |
| 14:48.24 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-sdvchhytdijafftu) |
| 14:48.28 | *** join/#asterisk-dev tonyclewis (sid6025@gateway/web/irccloud.com/x-recvphfkwpltvhxw) |
| 14:48.50 | *** join/#asterisk-dev tm1000 (tm1000@2600:3c00::f03c:91ff:fe6e:6894) |
| 14:51.04 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:51.04 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:51.23 | *** join/#asterisk-dev sgalarneau (~sgalarnea@nat/digium/x-sanujjsbuehfpfpp) |
| 14:51.40 | *** join/#asterisk-dev Sjors (~sgielen@foo.kassala.de) |
| 14:51.54 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-nriapdseqxgesqjt) |
| 14:54.22 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-quprhfiygjclsyca) |
| 14:58.25 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 14:58.25 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 14:58.34 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-boazibqgrwhttvpx) |
| 14:58.34 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:58.39 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 14:58.39 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 14:59.08 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-lfjhlfnwkbkglhkg) |
| 15:01.49 | *** part/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 15:03.45 | *** join/#asterisk-dev coreyf1513 (~coreyfarr@71-80-124-168.dhcp.wlmn.ct.charter.com) |
| 15:06.48 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 15:18.02 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.33) |
| 15:32.25 | *** join/#asterisk-dev Gugge (gugge@kriminel.dk) |
| 15:35.55 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-stfpamouorxeqkco) |
| 15:35.55 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:42.33 | *** join/#asterisk-dev mbowie (~mbowie@162.212.36.9) |
| 15:46.30 | *** join/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 15:46.46 | *** join/#asterisk-dev Gugge (gugge@kriminel.dk) |
| 15:50.03 | seanbright | fuck me i hate #asterisk |
| 15:51.00 | leifmadsen | seanbright: I stopped joining it |
| 15:51.03 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-xzhsryaaiygsdumt) |
| 15:51.19 | leifmadsen | it was a distraction and the level of incompetence was starting to bother me :) |
| 15:51.22 | Marquis42 | Same. The s/n ratio is just awful. |
| 15:55.47 | seanbright | leifmadsen: Marquis42: enjoy - http://pastebin.com/raw.php?i=C3ynhzkz |
| 15:55.59 | seanbright | if you get bored and read that: please let me know if i am insane or not |
| 15:56.23 | russellb | tl;dr |
| 15:56.41 | seanbright | here's a highlight: i |
| 15:56.42 | seanbright | err |
| 15:56.46 | seanbright | 11:49 < seanbright> how many fucking times do i have to say that? |
| 15:56.49 | seanbright | heh |
| 15:56.53 | Marquis42 | lol |
| 15:57.09 | leifmadsen | seanbright: you should just use a channel with better s/n :) |
| 15:57.11 | babak | rmudgett hi,how DAHDISendCallreroutingFacility knows it should send deflection code because in reasons there are just cfu|cfb|cfnr|unknown not reason for deflection? |
| 15:57.23 | leifmadsen | like a social channel :) |
| 15:57.27 | seanbright | heh |
| 15:57.39 | leifmadsen | because you're a good guy :) |
| 15:59.13 | seanbright | can someone op me in #asterisk please? :) |
| 15:59.15 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-stfpamouorxeqkco) |
| 15:59.23 | seanbright | oh happy friday |
| 15:59.40 | Qwell | seanbright: tempting |
| 15:59.44 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-bzbjwmzbyesbreob) |
| 15:59.44 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 16:00.27 | babak | rmudgett: without answer I used this application but in trace I see just operation value 14, not 13 for deflection |
| 16:02.08 | *** join/#asterisk-dev Corydon76_ (~quassel@c-69-137-93-158.hsd1.tn.comcast.net) |
| 16:02.09 | *** mode/#asterisk-dev [+o Corydon76_] by ChanServ |
| 16:24.51 | rmudgett | babak: operation 14 (CallRerouting) is selected because you are using Point-To-Point mode in ETSI. Operation 13 (CallDeflection) is selected if you are using Point-To-Multi-Point mode in ETSI. |
| 16:25.11 | rmudgett | ETSI EN 300 207-1 |
| 16:25.43 | rmudgett | There is a big difference between PTP mode of operation verses PTMP mode of operation |
| 16:26.23 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-kjwltrzegnvqzhet) |
| 16:27.47 | babak | rmudgett: thanks (in PRI) what is difference in messags between cfu cfnr and deflection ? |
| 16:28.16 | babak | how asterisk knows which one should send |
| 16:28.16 | rmudgett | PRI is only PTP mode of operation. In BRI you can operate in PTP mode or PTMP mode |
| 16:28.17 | babak | ? |
| 16:28.46 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-tuykxaisgzxvgvvm) |
| 16:31.05 | babak | so DAHDISendCallreroutingFacility may be sent befor call answer for call deflection and after call answer for cfnr... ? |
| 16:31.26 | babak | sorry |
| 16:32.07 | babak | all time no answer |
| 16:32.15 | rmudgett | CFNR is Call Forward No Reply in other words, no answer after a timeout |
| 16:34.02 | babak | rmudgett: with small changes ECT worked for ITU but seems for call deflection no need to change anything for ITU |
| 16:37.27 | babak | ITU Q952.7 ECT |
| 16:41.19 | rmudgett | ETSI EN 300 207-1 is what was implemented for ETSI |
| 16:42.00 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-pvbtarwtrzvhtmbk) |
| 16:48.02 | babak | rmudgett: am I correct ? Asterisk sends same messages for All services call Deflection or cfu|cfb|cfnr , it is local exchanges that decides uses destination number Asterisk sends(=Call deflection) or use its own(local exchange saved) destination number(=cfu|cfb|cfnr) |
| 16:51.12 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-uonsgfnruxkokhxx) |
| 16:51.12 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 17:01.59 | babak | according to ETSI EN 300 207-1 DiversionReason ::= ENUMERATED{unknown (0),cfu (1),cfb (2),cfnr (3),cdAlerting (4),cdImmediate (5)} |
| 17:03.48 | babak | I worry not implementing cdImmediate reason make Local exchange do mistake and fire other services and do not uses destination number sends in Asterisk facility message and use local exchange saved destination numbaer |
| 17:38.22 | WIMPy | What destination number? Or not? Or what? |
| 17:39.40 | babak | in cfb cfu cfnr the number saved in local exchange is used for transfering the call |
| 17:40.16 | babak | but in call deflection pbx tell the local exchange the destination number |
| 17:40.36 | WIMPy | Don't say transfer. That's yet another thing. |
| 17:40.54 | babak | ok yes diverson |
| 17:40.55 | WIMPy | s/pbx/the terminal/ |
| 17:41.47 | babak | diversion/forward |
| 17:42.41 | WIMPy | Diversion was actually better. It includes both CF and CD. |
| 17:45.33 | babak | my point is just in CD the destination number sent by pbx so in DAHDISendCallreroutingFacility the reason for CD like cdimmadiate should be implemented so the local exchange do not use its saved number and extract destination number from facility message sent by Asterisk |
| 17:46.26 | WIMPy | Why should it use anything other than the supplied destination? |
| 17:48.18 | babak | because ordinary bahavior of CFU CFB CFNR is it , they use number saved in local exchanges user profile for forwarding |
| 17:49.29 | WIMPy | Yes, but CF is something completely different from CD or PR. |
| 17:50.40 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-uonsgfnruxkokhxx) |
| 17:52.34 | babak | according to ETSI EN 300 207-1 also it seems just Cd can request local exchange to set destination number |
| 17:55.10 | WIMPy | Doesn't make sense to me. Where do you find that? |
| 17:55.52 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-nlmlywxcmoduwwcr) |
| 17:55.58 | babak | find what ? |
| 17:57.17 | WIMPy | Your last staement. |
| 17:58.58 | babak | ETSI and IYU is similar this is definition of CD: |
| 17:59.06 | babak | The call deflection (CD) supplementary service allows the served user to respond to an incoming |
| 17:59.07 | babak | call offered by the network by requesting redirection of that call to another number specified in the |
| 17:59.07 | babak | response. This redirection is only allowed before the called user has answered the call. It may occur |
| 17:59.07 | babak | immediately as a response to the DSS1 set-up message of the access or during the alerting phase |
| 17:59.17 | babak | IYU/ITY |
| 17:59.23 | babak | IYU/ITU |
| 18:00.12 | WIMPy | And how is that related? |
| 18:00.57 | babak | "....another number specified in the response..." |
| 18:01.05 | babak | The CFNR supplementary service enables a served user to have the network redirect to another user |
| 18:01.05 | babak | calls which are addressed to the served user's ISDN number, and for which the connection is not |
| 18:01.05 | babak | established within a defined period of time. The CFNR supplementary service may operate on all calls, or |
| 18:01.05 | babak | just those associated with specified basic services. The served user's ability to originate calls is unaffected |
| 18:01.05 | babak | by the CFNR supplementary service. |
| 18:01.24 | babak | ".....the network redirect to another user....." |
| 18:01.39 | WIMPy | Don't flood. |
| 18:01.51 | WIMPy | And angain you're changing topic. |
| 18:03.05 | babak | compare "another number specified in the response" and "the network redirect to another user." |
| 18:04.03 | WIMPy | First you need to find out if you're talking baout CF or CD. |
| 18:06.22 | babak | I am telling difference between CD and CFU/CFNR and the need for adding reason for CD in DAHDISendCallreroutingFacility |
| 18:06.46 | WIMPy | I'm sorry, but that doesn't make any sense to me so far. |
| 18:10.14 | babak | the ability for rerouting calls based on local Asterisk database give us ability like IN(Intelligent Network) services without need to enabling SSP functions and INAP |
| 18:10.46 | babak | may be make sense for rmudgett |
| 18:11.24 | WIMPy | I think he knows the difference between CF and CD. |
| 18:16.23 | gtjoseph | file: got a minute or 2 for a pjsip question? |
| 18:16.33 | file | not right now |
| 18:16.42 | file | you can ask and I may be able to answer |
| 18:17.08 | gtjoseph | :) i'll hit you up later or Monday. |
| 18:17.18 | file | currently in a meeting |
| 18:52.18 | *** join/#asterisk-dev philippel (uid10480@gateway/web/irccloud.com/x-ovfrrbkciyjndjuw) |
| 19:38.41 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 20:00.33 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 20:07.41 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-csrbjezoelranyrl) |
| 20:08.45 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-jcciqypjecqlfsvd) |
| 20:08.45 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 20:11.36 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-vvhsehbtqfibjmbr) |
| 20:11.36 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 20:13.36 | seanbright | file: unpossible? |
| 20:13.42 | file | yes |
| 20:13.58 | file | admits that was an experiment to see who would bring it up |
| 20:13.59 | Marquis42 | Me fail english? |
| 20:14.24 | seanbright | it's not technically _wrong_ |
| 20:14.34 | seanbright | but unusual |
| 20:14.51 | Marquis42 | I don't really know for sure if it is or isn't, I was just quoting The Simpsons. |
| 20:25.39 | jsmith | seanbright: It's because he's speaking Canadianese |
| 21:21.49 | *** join/#asterisk-dev snuff-home (~brad@203-219-29-182.tpgi.com.au) |
| 21:21.49 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 21:28.30 | gtjoseph | file: mjordan: would it bother either of you philosophically if I added the capability for a pjsip outbound registration to handle multiple server_uris? |
| 21:28.45 | file | what would it do? |
| 21:29.00 | gtjoseph | register to multiple servers from 1 object |
| 21:30.23 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-jcciqypjecqlfsvd) |
| 21:30.27 | gtjoseph | from a trunk perspective... An aor can have multiple contacts, an identify can have multiple matches, but you need a separate registration for each registration. |
| 21:30.48 | file | right, because they are separate |
| 21:31.00 | file | trying to lump multiple under the same thing is complicated |
| 21:31.09 | gtjoseph | how so? |
| 21:31.25 | file | if one is registered and one isn't, what's the state of that outbound registration? |
| 21:31.48 | gtjoseph | registered |
| 21:32.01 | file | but you're only registered to one |
| 21:32.02 | gtjoseph | if at least 1 is ok |
| 21:32.22 | snuff-home | file i was playing with my 7941 other day.. didn't have much luck in making *(pjsip) and it get along. will prob attempt more things today |
| 21:32.48 | gtjoseph | yep but if you lumpoed 2 server uris in the same registration then presumable they're interchangable |
| 21:33.00 | file | they may or may not be |
| 21:33.09 | gtjoseph | if you want to track them separately, you cdreate multiple |
| 21:33.12 | file | that depends upon the environment |
| 21:33.36 | file | and is not something I would want to explain to a user |
| 21:33.47 | gtjoseph | exactly. most of us with multi-server providers would want to lump them together |
| 21:33.57 | gtjoseph | but it doesnm't prevent the current behavior |
| 21:34.20 | file | it doesn't, but I don't see what it adds over just having multiple entries - and it complicates it from a code perspective |
| 21:34.25 | file | and is something else to explain behavior wise |
| 21:35.05 | gtjoseph | it's compicated now because a 'trunk' is comp[osed of multiple pjsip object... |
| 21:35.23 | gtjoseph | you can use multiple contacts in an aor for outbound |
| 21:35.36 | gtjoseph | you can use multiple matches in an identify for inbound |
| 21:35.50 | file | yes, and those are straight forward to explain |
| 21:35.51 | gtjoseph | but you have to have multiple registrations for the same trunk |
| 21:35.53 | file | and make sense |
| 21:36.29 | gtjoseph | it would make sense to anyone who has to configure itsp trunks with multiple servers |
| 21:36.32 | file | I'd take this to the -dev list to get more input |
| 21:36.39 | gtjoseph | ok, that's fair. |
| 21:36.54 | file | above is my personal opinion, and I could see it backfiring |
| 21:37.19 | gtjoseph | :) |
| 21:41.17 | file | like my first inclination when I see that is an ordered list for failover |
| 21:41.31 | file | because the configuration object says outbound registration |
| 21:42.24 | gtjoseph | maybe but we do the same thing for match in identify |
| 21:43.35 | file | I'm not sure you can compare the two like that... |
| 21:44.22 | gtjoseph | for an itsp who requires registration, it's actually a 1 for 1. |
| 21:44.32 | gtjoseph | for every registration you need a match |
| 21:44.48 | file | due to the way the architecture currently is, yes |
| 21:44.58 | file | (there's a patch up to remove that requirement) |
| 21:45.20 | gtjoseph | how would that be removed? |
| 21:45.37 | gtjoseph | automatic identify |
| 21:45.38 | gtjoseph | ? |
| 21:45.44 | file | you can match based on a user parameter you send in your registration Contact |
| 21:45.59 | gtjoseph | true. i saw that patch |
| 21:46.10 | file | since Contact is preserved when they call you it can be used to do the match |
| 21:46.16 | file | it's how some softphones do it |
| 21:46.22 | file | and hardware phones |
| 21:46.34 | file | other devices have different SIP instances running on different ports and use that |
| 21:46.35 | gtjoseph | still makes it difficult to have to have multuple registration objects when you only need 1 of each of the others |
| 21:47.05 | gtjoseph | this is all coming up because I'm updating my gui for pjsipo BTW |
| 21:47.32 | file | just because you have to have multiple registration objects does not make it bad, or make extending a single registration object to encompass multiple registrations ^_^ |
| 21:47.39 | file | the solution |
| 21:48.14 | gtjoseph | it does if you have to write special code to generate and parse the objects |
| 21:50.11 | file | I just have this bad feeling that this is going into chan_sip where 1 thing is actually for n things... |
| 21:51.02 | gtjoseph | i don't see the similarity but I shuddered just the same |
| 21:51.04 | gtjoseph | :) |
| 21:51.25 | file | I configure it with 3 URIs |
| 21:51.30 | file | my outbound registration is actually 3 outbound registrations |
| 21:51.40 | file | one object, multiple things |
| 21:52.11 | gtjoseph | yeeees. i configure 1 identify with 5 matches. I configure 1 aor with multiple contacts |
| 21:52.36 | gtjoseph | i'm actually qualifying each of those contacts to boot |
| 21:52.37 | file | an identify does not spawn multiple things as a result of 5 matches |
| 21:53.08 | gtjoseph | from a code perspective that's true |
| 21:53.33 | gtjoseph | from a user perspective, it's 5 things |
| 21:53.57 | file | -dev list this |
| 21:54.04 | file | we just fundamentally disagree |
| 21:54.05 | gtjoseph | will do |
| 22:02.52 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 22:07.13 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-csrbjezoelranyrl) |
| 23:18.44 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 23:18.45 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:54.49 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |