| 00:08.23 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
| 00:15.39 | *** join/#asterisk cemotyz09 (~cemotyz09@cpe-70-121-128-59.satx.res.rr.com) |
| 00:59.05 | *** join/#asterisk guerby (~guerby@april/board/guerby) |
| 02:03.26 | *** join/#asterisk lankanmon (~LKNnet@CPE64777d632383-CM64777d632380.cpe.net.cable.rogers.com) |
| 02:17.32 | *** join/#asterisk guerby (~guerby@april/board/guerby) |
| 03:32.15 | life_of_e | Hmm, ok, segfault when starting the dynamic loader |
| 04:09.12 | life_of_e | Fixed the segfault. It appears there's another place somewhere that filters out characters sent to SendDTMF |
| 04:24.32 | *** join/#asterisk sa02irc (~sa02irc@155-079-043-212.ip-addr.inexio.net) |
| 04:42.21 | life_of_e | booyeah! |
| 04:43.54 | life_of_e | Add four lines to res_rtp_asterisk.c and set the endpoint to use dtmfmode=rfc2833. PSTN FXO Hook flash. |
| 04:46.59 | life_of_e | If I can figure out how to cross compile so I can just copy the object files I won't have to build from scratch on the main server |
| 04:48.16 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 04:48.57 | *** join/#asterisk m4rcu5 (nobody@546AF885.cm-12-3d.dynamic.ziggo.nl) |
| 06:00.53 | [TK]D-Fender | life_of_e, Impressed you managed to get it figured... please post it as a patch and good odds they'll merge it into the main making future upgrades easier |
| 06:11.23 | life_of_e | Thanks TK, I'm stubborn ;) Where are patches typically submitted? |
| 06:13.27 | drmessano | https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process |
| 06:15.09 | life_of_e | Thanks drmessano. Looks like that's going to be a weekend project because I have to learn the entire patch process. I edit a lot of code here and there but have never submitted a patch anywhere. |
| 06:22.44 | *** join/#asterisk miralin (~Thunderbi@81.177.202.137) |
| 06:24.06 | [TK]D-Fender | heads off to bed |
| 06:34.39 | life_of_e | Not sure why it didn't work as an INFO message but that's probably to do with the expectations of the ATA and the exact formatting of the message. But the RTP worked so I'm hoping the change in res_rtp_asterisk carries over to PJSIP. I tried all this using the endpoints configured via chan_sip |
| 06:45.16 | *** join/#asterisk puzzola (~puzzola@unaffiliated/puzzola) |
| 06:58.04 | drmessano | Well you really should test with PJSIP |
| 06:58.15 | drmessano | Chan_sip is dead |
| 06:58.32 | life_of_e | Yeah, I have to learn how to convert the sip.conf to pjsip.conf |
| 06:58.47 | life_of_e | My hope, though, is that the code I edited is agnostic of the channel |
| 06:59.28 | life_of_e | I wasn't editing one of the channel driver files I was editing main/app.c and res/res_rtp_asterisk.c |
| 07:00.16 | life_of_e | I had tried chan_sip.c first because there was code in there for an INFO packet but that didn't work correctly so I went digging to see what happened when dtmfmode was rfc2833 instead of info |
| 07:01.56 | *** join/#asterisk lankanmon (~LKNnet@CPE64777d632383-CM64777d632380.cpe.net.cable.rogers.com) |
| 07:03.33 | *** join/#asterisk jkroon (~jkroon@165.16.203.57) |
| 07:20.33 | *** join/#asterisk sysgrammer_moe (~sysgramme@d50-117-158-201.yt.northwestel.net) |
| 07:23.08 | *** join/#asterisk pchero_work (~pchero@87.213.240.121) |
| 07:40.52 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 07:44.58 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 08:12.58 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 08:13.43 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 08:58.28 | *** join/#asterisk pchero_work (~pchero@87.213.247.82) |
| 09:15.45 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 09:41.11 | *** join/#asterisk sekil (~sekil@87.116.191.5) |
| 10:26.52 | *** join/#asterisk pchero_work (~pchero@87.213.247.82) |
| 10:32.51 | *** join/#asterisk lankanmon (~LKNnet@CPE64777d632383-CM64777d632380.cpe.net.cable.rogers.com) |
| 10:59.57 | *** join/#asterisk duo_ubuntu (24465d69@gateway/web/freenode/ip.36.70.93.105) |
| 11:08.42 | wyoung | hi gang |
| 11:50.35 | *** join/#asterisk sekil (~sekil@nat-73.net011.net) |
| 12:05.27 | *** join/#asterisk sysgrammer_moe (~sysgramme@d50-117-158-201.yt.northwestel.net) |
| 12:09.20 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 12:14.15 | *** join/#asterisk m4rcu5 (nobody@546AF885.cm-12-3d.dynamic.ziggo.nl) |
| 12:15.43 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 13:09.26 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
| 13:17.03 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
| 13:25.57 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 13:26.48 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 13:39.00 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 13:44.50 | *** join/#asterisk rpifan (~rpifan@p578D20EA.dip0.t-ipconnect.de) |
| 13:48.09 | *** join/#asterisk Janos (~Janos@201.204.94.76) |
| 13:53.37 | *** join/#asterisk cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 13:53.38 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 14:11.13 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 14:11.51 | *** join/#asterisk samwierema (~samwierem@195.240.143.134) |
| 14:24.48 | *** join/#asterisk bford (uid283514@gateway/web/irccloud.com/x-wggxzkblcikgilkr) |
| 14:24.48 | *** mode/#asterisk [+o bford] by ChanServ |
| 14:28.28 | *** join/#asterisk kharwell (kharwell@nat/digium/x-holndwzdbjpwaxyi) |
| 14:28.28 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 14:40.31 | *** join/#asterisk elguero (~miguel323@74-95-21-41-Connecticut.hfc.comcastbusiness.net) |
| 14:42.04 | *** join/#asterisk pchero_work (~pchero@87.213.240.121) |
| 15:06.43 | *** join/#asterisk Janos (~Janos@201.204.94.76) |
| 15:10.54 | *** join/#asterisk rmudgett (rmudgett@nat/digium/x-cbushwkthwlfokvp) |
| 15:10.54 | *** mode/#asterisk [+o rmudgett] by ChanServ |
| 15:13.48 | *** join/#asterisk MarkSX (~MarkSX@unaffiliated/marksx) |
| 15:49.13 | *** join/#asterisk elguero (~miguel323@74-95-21-41-Connecticut.hfc.comcastbusiness.net) |
| 16:04.29 | *** join/#asterisk c-- (4ffaf7c1@gateway/web/freenode/ip.79.250.247.193) |
| 16:07.43 | c-- | if a voip provider has a "D2T" naptr record to _sip._tcp.provider.com, doesn't that mean that the server behind that address should respond to *TCP* requests on port 5060? |
| 16:11.09 | Samot | No. |
| 16:11.26 | Samot | Does _sip._tcp.provider.com actually resolve to 5060? |
| 16:20.07 | *** join/#asterisk pchero_work (~pchero@87.213.240.121) |
| 16:20.19 | c-- | correction, i tried it from a different network and it does indeed work. "nc -w 10 -z phone-wei.provider.com. 5060 ; echo $?" -> 0 |
| 16:21.32 | c-- | what i did: "dig provider.com NAPTR +short" -> "60 50 "S" "SIP+D2T" "" _sip._tcp.phone.provider.com." (and another line for UDP) |
| 16:22.47 | c-- | ... and then "dig _sip._tcp.phone.provider.com. SRV +short" -> "10 1 5060 phone-wei.provider.com." (and another one) |
| 16:24.13 | c-- | Samot: ... so i wanted to see if it goes through the firewall: "nc -w 10 -z phone-wei.provider.com. 5060 || echo ERROR" -> "ERROR" which is why i asked. |
| 16:29.59 | *** join/#asterisk miralin (~Thunderbi@81.177.202.137) |
| 16:36.48 | *** join/#asterisk Janos (~Janos@201.204.94.76) |
| 16:39.26 | *** join/#asterisk simplisticpotato (~simplisti@rrcs-74-219-86-4.central.biz.rr.com) |
| 16:40.46 | *** join/#asterisk gerhard7 (~gerhard7@ip5657ee30.direct-adsl.nl) |
| 16:45.15 | sibiria | during heavy-ish load tests with 16.2.1 and pjsip, i'm now and then running into res_rtp_asterisk.c: RTCP SR transmission error to 1.2.3.4:13129, rtcp halted Operation not permitted |
| 16:45.33 | sibiria | the port is within the defined range in rtp.conf, but i know that this has its roots in a permission error |
| 16:45.38 | sibiria | i'm just not sure what or why |
| 16:46.37 | sibiria | they start showing up at around 200-250 simultaneous calls |
| 16:47.19 | sibiria | over 15000 test calls i get maybe 10 of these errors, so in one sense it's not really a big issue |
| 16:51.06 | Samot | When you say simultaneous you mean connected? |
| 16:51.15 | sibiria | yes fully connected calls |
| 16:51.30 | Samot | How many are in "setup"? |
| 16:52.07 | Samot | And are these outbound? |
| 16:52.11 | sibiria | around 20-30 |
| 16:52.27 | sibiria | both - i get the same error on both endpoints |
| 16:52.33 | sibiria | one dials the other |
| 16:52.50 | sibiria | the one doing the dialing actually spits out a lot more of these errors - but it's still not a crazy amount |
| 16:53.31 | Samot | Where are the calls originating from? |
| 16:53.45 | Samot | Is this replicating Endpoint -> Asterisk -> Endpoint? |
| 16:54.05 | sibiria | it's asterisk -> asterisk, plain call files |
| 16:54.35 | Samot | So local channel to PJSIP trunk |
| 16:54.56 | sibiria | yes |
| 16:55.01 | sibiria | i suspect the problem is some resource throttling or starvation outside asterisk. i'm just not sure what it may be |
| 16:55.15 | Samot | Well each channel is going to need two RTP ports. |
| 16:55.25 | sibiria | my range is 10k ports |
| 16:55.28 | Samot | And there will be two channels per call. |
| 16:55.32 | Samot | I understand... |
| 16:55.41 | Samot | But 15000 calls = 4 x RTP ports. |
| 16:56.31 | Samot | 10000 RTP ports means 2500 calls |
| 16:56.56 | Samot | I'm not saying you don't have a problem. |
| 16:57.06 | Samot | I'm just giving a scope. |
| 16:57.12 | sibiria | yes i understand |
| 16:57.16 | sibiria | they should be freed up soon enough after the channels are closed |
| 16:57.36 | sibiria | but i'm gonna see how it fares if i stretch the range out to cover 30k ports |
| 16:57.38 | Samot | How many calls are you originating at once? |
| 16:57.44 | Samot | How many call files are you dumping in? |
| 16:57.57 | sibiria | few - 10 every second |
| 16:58.14 | Samot | 3 at a time? |
| 16:58.23 | sibiria | 10 at a time, each second |
| 16:58.30 | Samot | ah. |
| 16:59.28 | sibiria | it digests that part just fine, even at 50 calls per second but with shorter duration causing a peak of 200-250 connected calls |
| 17:00.09 | sibiria | i'll play around with the rtp port range a bit to see if that's where it might be at |
| 17:00.53 | Samot | But the permissions thing might be worth it too |
| 17:23.53 | *** join/#asterisk friedrich (~friedrich@aextron.de) |
| 17:41.09 | *** join/#asterisk jrun (~jrun@unaffiliated/glphvgacs) |
| 17:42.45 | *** part/#asterisk jrun (~jrun@unaffiliated/glphvgacs) |
| 17:46.57 | *** join/#asterisk sa02irc (~sa02irc@155-079-043-212.ip-addr.inexio.net) |
| 18:12.39 | genewitch | motherfucker |
| 18:12.42 | genewitch | sorry |
| 18:12.58 | genewitch | my windows changed numbers |
| 18:17.09 | *** join/#asterisk Chotaire (chotaire@unaffiliated/chotaire) |
| 18:25.10 | *** join/#asterisk defsdoor_ (~Andrew@cpc120600-sutt6-2-0-cust232.19-1.cable.virginm.net) |
| 18:31.12 | *** join/#asterisk rpifan (~rpifan@p578D20EA.dip0.t-ipconnect.de) |
| 18:31.22 | *** join/#asterisk file (sid178970@asterisk/developer-and-muffin-lover/file) |
| 18:31.22 | *** mode/#asterisk [+o file] by ChanServ |
| 18:31.55 | *** join/#asterisk csavinovich (sid296765@gateway/web/irccloud.com/x-eyuibrfqzcxbnfbh) |
| 18:31.55 | *** mode/#asterisk [+o csavinovich] by ChanServ |
| 18:34.31 | *** join/#asterisk tehgooch (tehgooch@unaffiliated/tehgooch) |
| 18:34.33 | *** join/#asterisk mducharme (uid303982@gateway/web/irccloud.com/x-dzitunrbfekkrzyt) |
| 18:34.39 | *** join/#asterisk leftleg_ (sid291906@gateway/web/irccloud.com/x-ibtwxgjxxtdermic) |
| 18:39.10 | *** join/#asterisk pchero (~pchero@dhcp-077-249-058-090.chello.nl) |
| 18:50.32 | *** join/#asterisk blast_hardcheese (~blast_har@unaffiliated/blast-hardcheese/x-0199635) |
| 18:56.21 | *** join/#asterisk Janos (~Janos@201.204.94.76) |
| 19:05.29 | *** join/#asterisk _mwoodj_ (~mwoodj@pdpc/sponsor/digium/hyper-eye) |
| 19:23.43 | *** join/#asterisk pyro25 (699e1607@gateway/web/freenode/ip.105.158.22.7) |
| 19:58.28 | *** join/#asterisk LoKoMurdoK (~LoKoMurdo@fedora/LoKoMurdoK) |
| 20:11.07 | *** join/#asterisk rpifan (~rpifan@p578D20EA.dip0.t-ipconnect.de) |
| 20:47.53 | blast_hardcheese | Reading through chan_sip, as well as rfc5411, it doesn't seem obvious that it's possible for a terminating AGI to add additional headers to a channel during the initial OK; am I overlooking something simple here? I'm trying to provide some additional context for middleware (opensips) to pick up on when handling terminating calls |
| 20:49.21 | blast_hardcheese | The origination side is pretty straightforward, though it seems as though SIPADDHEADER is only used for that path; there's seemingly no infrastructure to add headers in the other direction |
| 20:49.43 | Samot | You can add headers to the initial INVITE |
| 20:49.53 | file | both chan_sip and chan_pjsip do not support adding headers except on initial INVITE |
| 20:50.15 | Samot | That's it. OpenSIPs or Kamailio will be needed for SIP message manipulation. |
| 20:51.21 | blast_hardcheese | that makes sense. If I have context in an AGI, is there a good channel to pass information through to opensips other than the payload, or is that my primary channel? |
| 20:51.37 | Samot | You add sip headers. |
| 20:51.49 | Samot | On your initial invite.. |
| 20:52.12 | Samot | You'll have to have opensips store them in some way for grabbing during the dialog |
| 20:52.21 | blast_hardcheese | on the receive path? I'm not making the INVITE, I'm receiving it |
| 20:52.29 | blast_hardcheese | Is there documentation around something like this? I was unable to find it |
| 20:52.46 | Samot | Are you sending this from opensips? |
| 20:52.50 | blast_hardcheese | No |
| 20:52.59 | blast_hardcheese | I'm receiving from a carrier |
| 20:53.05 | Samot | OK, you cannot do anything with the replies. |
| 20:53.08 | blast_hardcheese | I have no control over the INVITE |
| 20:53.18 | Samot | If you need to do that, you have to get opensips or kamailio |
| 20:53.37 | Samot | So that when Asterisk sends a reply, you can do stuff with it before passing it back to the carrier. |
| 20:53.46 | blast_hardcheese | ah, I understand. Is this a hard limitation in asterisk then, not a violation of the protocol? |
| 20:53.51 | blast_hardcheese | that makes sense, I'll focus there |
| 20:53.55 | Samot | Correct. |
| 20:54.02 | blast_hardcheese | OK, thank you for the pointers! |
| 21:00.47 | *** join/#asterisk salviadud (~ralfalfa@187-162-213-198.static.axtel.net) |
| 21:04.47 | *** join/#asterisk TandyUK (~admin@TandyUK/staff/James) |
| 21:36.42 | *** join/#asterisk Helenah (~s98259@unaffiliated/iveeee) |
| 22:01.12 | *** join/#asterisk blast_ha1dcheese (~blast_har@unaffiliated/blast-hardcheese/x-0199635) |
| 22:04.34 | *** join/#asterisk infinity_ (~brendon@web2.artsopolis.com) |
| 22:04.50 | infinity_ | does anyone know how to disable this polycom (I think its lync) login? https://www.screencast.com/t/ODDBpBdsT |
| 22:05.45 | infinity_ | or skype. not sure |
| 22:39.48 | Samot | Uhm. If they have those options you might have the wrong phonez |
| 22:42.55 | infinity_ | It was working until i reset it to factory defaults. |
| 22:43.07 | infinity_ | i feel like when I was onsite years ago i pressed somethign on the menu to bypass it. |
| 22:43.59 | infinity_ | the other weird issue i'm having is the phone is trying to goto time.windows.com instead of the ntp server configured in the cfg file. |
| 22:44.19 | infinity_ | The time is wrong, but the phone ignores the ntp settings which is how I got into this mess. |
| 22:44.37 | infinity_ | And it's just this one phone that is giving me grief. Hrmz. |
| 22:50.37 | Samot | Well they have specific firmware for Skpe/Lync |
| 22:51.23 | infinity_ | Can I just format the filesystem on the phone and let it re-download? |
| 23:07.23 | *** join/#asterisk tomaluca95 (~quassel@kde/developer/tomaluca) |
| 23:17.02 | sibiria | i think i've found a bug in res_rtp_asterisk |
| 23:17.18 | sibiria | (regarding the RTCP errors i ran into earlier during stress-testing 16.2.1) |
| 23:17.50 | sibiria | it occurs when the two endpoints' rtcp interval is identical |
| 23:18.03 | sibiria | whether the default of 5000ms, 7500ms, 2000ms, anything |
| 23:18.12 | sibiria | but if i keep them 500ms apart, the problem goes away |
| 23:19.35 | sibiria | so the work-around was to just change rtcpinterval in rtp.conf on one of the endpoints |
| 23:19.55 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 23:21.30 | sibiria | i suppose there is some risk of this happening against when interacting with any other SIP provider, should they be slinging rtcp packets at the same interval |
| 23:21.35 | sibiria | -against |
| 23:28.43 | *** part/#asterisk kharwell (kharwell@nat/digium/x-holndwzdbjpwaxyi) |