| 00:33.39 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 00:41.10 | *** join/#asterisk-dev acidfoo_ (~acidfoo@198-48-218-90.cpe.pppoe.ca) |
| 01:04.26 | *** join/#asterisk-dev raspberrypifan (~raspberry@2604:2000:6016:be00:6355:b61:14e7:dbba) |
| 05:06.28 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 05:24.00 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 06:41.22 | *** join/#asterisk-dev tzafrir (~tzafrir@185.28.153.1) |
| 06:41.22 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:10.35 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 07:10.35 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:38.57 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:01.42 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-32-14.wall.uls.co.za) |
| 08:09.13 | oej | Hello folks! |
| 08:12.46 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 08:14.52 | *** join/#asterisk-dev tzafrir (~tzafrir@185.28.153.1) |
| 08:14.52 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 10:05.26 | *** join/#asterisk-dev tzafrir (~tzafrir@185.28.153.1) |
| 10:05.26 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 10:31.28 | *** join/#asterisk-dev tzafrir (~tzafrir@213.57.118.74) |
| 10:31.29 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 10:37.22 | *** join/#asterisk-dev acidfoo_ (~acidfoo@198-48-218-90.cpe.pppoe.ca) |
| 11:46.59 | *** join/#asterisk-dev pc-m (~user@modemcable094.94-70-69.static.videotron.ca) |
| 13:51.05 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:51.05 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:05.07 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-vhpmjwizawipzfez) |
| 15:05.07 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:24.01 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 15:44.11 | *** join/#asterisk-dev raspberrypifan (~raspberry@2604:2000:6016:be00:6355:b61:14e7:dbba) |
| 15:52.18 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-plkrehuobgrvktrl) |
| 16:03.51 | *** join/#asterisk-dev newtonr (~newtonr@173-21-146-94.client.mchsi.com) |
| 16:03.51 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 16:04.10 | newtonr | putnopvut, I'm trying to figure out how I can improve the PJSIP_HEADER documentation. I wonder if you can help me understand when you can and can't read PJSIP headers from a channel? As an example of my confusion (brought on by falves issue) - right now I've tested by trying to read the Call-ID with both PJSIP_HEADER and CHANNEL for comparison. In both a pre-dial gosub and a pre-bridge gosub I can succesfully read the call-id of |
| 16:04.10 | newtonr | the callee channel with CHANNEL, but PJSIP_HEADER does not return anything. |
| 16:04.10 | newtonr | My call scenario is ALICE dialing BOB, with the most basic dial string possible. |
| 16:05.03 | putnopvut | What you're going to find in that case is that trying to retrieve a PJSIP_HEADER in a case like that is not going to work because we have not constructed an outgoing INVITE yet at the time that you are checking it. |
| 16:05.09 | gtjoseph | iirc in pre-dial, you can only read what't you;ve added. |
| 16:05.49 | putnopvut | In addition, the CHANNEL function will retrieve the call-id because that's a property of the SIP dialog. We created that at the time the channel was created, so you are able to retrieve the Call-ID via the CHANNEL function at that point. |
| 16:06.10 | putnopvut | In general, trying to retrieve SIP headers during a pre-dial is not going to work out. |
| 16:06.30 | putnopvut | You can SET SIP headers in a pre-dial just fine though. |
| 16:07.19 | putnopvut | As you've found, there are some details that will end up in SIP headers (like call-id) that you are able to get at that point, but in general you're going to find that most of the SIP header data is not retrievable because it just doesn't exist yet. |
| 16:07.46 | *** join/#asterisk-dev libardi (~kvirc@187.64.229.94) |
| 16:10.59 | newtonr | putnopvut, So does, PJSIP_HEADER work only on the INVITE then? |
| 16:11.04 | rmudgett | You should be able to read the PJSIP_HEADERs of Alice when Alice calls Bob |
| 16:11.30 | gtjoseph | not in a pre-dial handler |
| 16:11.32 | newtonr | rmudgett, pre-bridge didn't work either |
| 16:12.12 | newtonr | pre-dial and pre-bridge did not work. I figured that pre-bridge would work since it happens after the answer |
| 16:12.39 | putnopvut | newtonr: Reading PJSIP_HEADER() is only going to work accurately on inbound INVITEs (i.e. the Alice channel). Trying to read PJSIP_HEADER() on an outbound channel is not going to work. |
| 16:13.00 | rmudgett | That's because you are operating on Bob's channel which is an outgoing channel. You can only read headers that came in on an incoming INVITE and the headers that you have already set on Bob's outgoing channel. |
| 16:13.07 | putnopvut | Presumably, we could make the headers available pre-bridge since we've actually sent the INVITE by then, but I don't think the code is suited to do so right now. |
| 16:13.38 | rmudgett | Not much use then either. |
| 16:13.53 | putnopvut | Yeah, at that point, we've already sent it. So ... not sure what you'd do with that info |
| 16:13.54 | rmudgett | as its too late to influnence anything |
| 16:14.06 | newtonr | rmudgett, the U option says it operates on the callee channel, the outbound channel. But from what you and putnopvut are saying it sounds like that doesn't matter - PJSIP_HEADER works only on the inbound channel then regardless? |
| 16:14.37 | rmudgett | READing works on inbound. WRITING works on outbound |
| 16:14.38 | gtjoseph | pre-bridge happens when re receive an OK but before we add the channel to the bridge? |
| 16:14.39 | putnopvut | specifically, READING PJSIP_HEADER() only works in the inbound |
| 16:14.49 | putnopvut | gtjoseph: correct |
| 16:15.17 | gtjoseph | cool. actually you CAN read, but only what you've already put in. :) |
| 16:16.01 | newtonr | lol |
| 16:16.22 | newtonr | Okay I think I'm understanding better. Yeah the current documentation is just ambiguous enough to be confusing and not helpful |
| 16:16.57 | rmudgett | newtonr: Hows that for a trio barage? |
| 16:17.21 | gtjoseph | probably my documentation... sorry. :) |
| 16:18.07 | newtonr | lol hey it has several great examples. it just isn't clear on when you can read and write |
| 16:18.14 | newtonr | rmudgett, excellent! |
| 16:18.50 | newtonr | putnopvut, rmudgett, gtjoseph, Okay I'll make some edits and run it by you guys |
| 16:19.27 | putnopvut | Sure. |
| 16:19.40 | putnopvut | My time at work is nearly up for the day, so I probably won't be around to look at your suggested edits. |
| 16:19.48 | newtonr | There is no rush |
| 16:19.54 | newtonr | thanks! |
| 17:48.04 | *** join/#asterisk-dev fish9370 (~Miranda@mbox.fpg.ru) |
| 17:49.01 | fish9370 | It's possible set variable on channel after Dial and bofore Dial end? With some option |
| 17:49.35 | fish9370 | I need set cdr variable on new CDR |
| 17:52.49 | gtjoseph | Have you looked at the U argument to Dial? |
| 17:53.55 | fish9370 | 5 sec |
| 17:57.26 | fish9370 | before this routine is executed a new cdr-entry will be created? |
| 17:57.49 | gtjoseph | i don't believe so. |
| 17:58.26 | gtjoseph | the subroutine happens before the 2 legs of the call are connected. |
| 17:59.04 | fish9370 | but I need set my own variable to NEW one CDR on new leg |
| 17:59.40 | gtjoseph | i think you're going to just have to try it. |
| 17:59.52 | fish9370 | but before dial new cdr is not exists, and after dial it's finalized |
| 18:01.07 | fish9370 | the problem is I make this in AGI script |
| 18:01.38 | fish9370 | I would not want to call a subroutine |
| 18:02.11 | gtjoseph | not sure then, sorry. |
| 18:02.20 | fish9370 | maybe somebody append new option in source code& |
| 18:02.57 | fish9370 | ? |
| 18:03.34 | gtjoseph | anything's possible but i'm still not sure why the U option won't work for you. |
| 18:04.14 | fish9370 | I try it. But it not clean solution |
| 18:05.03 | fish9370 | I have all my logic in AGI, |
| 18:05.17 | gtjoseph | where do you call Dial from? |
| 18:05.26 | fish9370 | from AGI |
| 18:06.09 | fish9370 | like this $agi->exec("Dial {$technology}/{$span}/{$number_to},{$ringtime},tTL({$max_duration})", ""); |
| 18:06.12 | gtjoseph | ah, ok. so you're concerned that the AGI has to call Dial with a handler that'll call AGI again? |
| 18:07.54 | fish9370 | yes, and not only this |
| 18:08.47 | fish9370 | where I get data in subroutine |
| 18:09.11 | gtjoseph | i understand now. i'm thinking. |
| 18:14.41 | gtjoseph | unfortunately, i can't think of another way to do what you want, sorry. |
| 18:15.42 | fish9370 | are you Asterisk developer? |
| 18:15.48 | gtjoseph | yes |
| 18:16.14 | fish9370 | how to initiate new feature for Asterisk? |
| 18:16.47 | gtjoseph | go to issues.asterisk/org and create an issue. |
| 18:16.55 | gtjoseph | .org |
| 18:17.22 | fish9370 | my English is bad. No body understand me ( |
| 18:18.22 | fish9370 | but I need to try |
| 18:18.41 | gtjoseph | i understood you. :) Explain as best you can what you want and why you need it. Maybe someone will have another answer. You can also join the asterisk and asterisk-dev mailing lists mailing lists and ask there. |
| 18:18.53 | gtjoseph | It's a holiday weekend in the US though. |
| 18:19.36 | fish9370 | ok, thank you very much |
| 18:19.59 | gtjoseph | lists.digium.com is the link for the mailing lists. |
| 18:21.34 | fish9370 | thanks :) |
| 18:23.50 | fish9370 | how I can get account for issues service? |
| 18:24.07 | gtjoseph | there should be a link on the first page. let me look |
| 18:24.52 | gtjoseph | signup.asterisk.org |
| 18:25.33 | fish9370 | thank you |
| 18:41.30 | *** join/#asterisk-dev klow (~textual@96.81.150.137) |
| 18:42.59 | klow | Hey all. Does any version asterisk support 256 bit ciphers for SRTP ? Have been trying to use 256 bit srtp from some of my phones and getting unsupported cipher suite. Is this a libsrtp issue or asterisk issue? Willing to build/patch asterisk to get this working as its a hard requirement for me currently . |
| 18:44.10 | gtjoseph | there's nothing in asterisk that would limit this. what does 'openssl ciphers' say? |
| 18:45.49 | file | the SRTP negotiation code has to be extended to allow it, and to give the info to libsrtp |
| 18:45.59 | gtjoseph | really? |
| 18:46.15 | file | yes |
| 18:46.32 | klow | So no "easy" |
| 18:46.40 | klow | way to get this support currently without code change .. |
| 18:46.49 | file | no, it requires code change |
| 18:46.56 | gtjoseph | sorry, my bad. |
| 18:47.55 | klow | would you say that is because SRTP was designed only with 128bit ciphers in mind , and 256 bit is an afterthought, though it is gaining some popularity if you will (many endpoints now supporting 256 bit ciphers) |
| 18:48.30 | klow | I'm assuming currently that libsrtp has been modified to allow 256 bit crypto .. i think it has |
| 18:48.38 | file | sure - the original endpoints never did 256 so it was never added, and noone has added it since |
| 18:49.42 | gtjoseph | does this apply to both sdes and dtls? |
| 18:49.50 | klow | Is something I could feature request ? Thanks file |
| 18:50.13 | file | we don't currently accept feature requests on the issue tracker without a patch, you could try bringing it up on the mailing list and seeing if it piques the curiosity of someone |
| 18:51.10 | file | gtjoseph, oui |
| 18:51.24 | gtjoseph | hmmm. |
| 18:51.48 | klow | OK will do , thanks. If you dont mind me asking one more thing. ZRTP - this is just partially working through unofficial patches currently ? |
| 18:52.02 | klow | 1-1 calls only.. pass-through essentially ? |
| 18:52.04 | file | I don't know anything of ZRTP. |
| 18:52.24 | file | Everything relating to it is third party, so I have no insight there. |
| 19:02.17 | rmudgett | file gtjoseph For the subscription OOM issue. I'm now seeing that the bottleneck is the sorcery contact update observers. |
| 19:02.35 | gtjoseph | hmmm. |
| 19:02.46 | rmudgett | There seems to be several contact observers. |
| 19:02.51 | gtjoseph | what specifically in the observers? |
| 19:02.54 | gtjoseph | yeah |
| 19:03.14 | gtjoseph | and is it contact or contact_status? |
| 19:03.45 | rmudgett | Just that processing the sorcery/contact taskprocessor is backing up more than any other. |
| 19:04.10 | rmudgett | It is contact not contact_status |
| 19:04.31 | gtjoseph | i can't think of anything offhand that's serialized there unless there something in the stasis/ami event stuff. |
| 19:04.34 | rmudgett | Although that serializer is also getting backed up but not as much |
| 19:05.15 | rmudgett | sorcery/contact 36k processed 21k hi-water |
| 19:05.32 | gtjoseph | yikes. |
| 19:05.40 | rmudgett | sorcery/contact_status 51k processed 9700 hi-water |
| 19:05.50 | gtjoseph | is it just update or create/delete as well (or can you tell)? |
| 19:06.32 | rmudgett | can't tell. Just looked at who puts stuff on the sorcery/contact serializer |
| 19:07.26 | rmudgett | This is initial testing with my patch to put SIP messages into consistent distributor serializers |
| 19:07.29 | gtjoseph | it's probably create/delete. every time a register/unregister happens, the contact observer's fire but we also change teh stat eof the endpoint |
| 19:07.59 | rmudgett | yeah could be create/delete more than update |
| 19:08.19 | gtjoseph | that code is at the top of pjsip_configuration. |
| 19:09.25 | rmudgett | I was expecting the distributor serializers to eliminate the REGISTER transaction (key exist) |
| 19:09.55 | rmudgett | and the subscribe request expiration 0 is invalid messages to go away |
| 19:10.12 | rmudgett | but they still happen. |
| 19:10.33 | gtjoseph | too bad. some other issue then. |
| 19:10.46 | file | why would they be eliminated? |
| 19:11.22 | rmudgett | With the patch to make the pjsip distributor select serializers based upon call-id and from-tag hash |
| 19:11.42 | rmudgett | the serializer picked should be the same for all messages in the dialog |
| 19:11.51 | file | sure |
| 19:12.58 | rmudgett | So retransmissions should be filtered because they would always be processed by the same serializer |
| 19:12.59 | *** join/#asterisk-dev F2Knight (~F2Knight@c-50-139-85-237.hsd1.or.comcast.net) |
| 19:13.05 | F2Knight | Having a core dump issue - not sure what is causing it any help would be wonderful - Backtrace located here > https://gist.github.com/tuxpowered/6a8ecc6037548aed24a7f51500bc3e25 |
| 19:13.38 | file | rmudgett, I don't know if they'd hit the transaction layer at that point or not... if they did then yes they'd be filtered |
| 19:13.44 | file | maybe. |
| 19:14.41 | gtjoseph | F2Knight: make sure you're using the latest unixodbs and mysql connector libs. |
| 19:14.48 | gtjoseph | unixodbs |
| 19:14.51 | rmudgett | Course it also depends upon how long the messages were sitting in the serializer. But the distributor serializers didn't have much backlog. Hi-water marks 50-70 |
| 19:14.54 | gtjoseph | unixodbc |
| 19:14.56 | F2Knight | you think its the odbc? |
| 19:15.05 | F2Knight | its off a freepbx distort. |
| 19:15.23 | F2Knight | currently 2.2.14-14.el6 |
| 19:15.48 | gtjoseph | well, some of the issues we've seen lately in odbc have been fixed with upgrades to both of those packages. |
| 19:17.19 | F2Knight | sorry both of which packages? unixodbc and what else? |
| 19:17.35 | F2Knight | oh mysql connector I see |
| 19:17.53 | gtjoseph | yeah, usually mysql-connector-odbc |
| 19:19.57 | F2Knight | mysql-connector-odbc = 5.1.5r1144-7.el6 |
| 19:20.05 | F2Knight | there appear to be no updates available |
| 19:20.46 | gtjoseph | there are, just not for that distro. :( 5.3.4 is the latest. |
| 19:21.15 | F2Knight | !@#$#!@# F!@#PBX. |
| 19:21.28 | F2Knight | and darn client that insists on using it. |
| 19:21.36 | F2Knight | um... any suggestions or work arounds? |
| 19:22.23 | F2Knight | we are pushing a rather large amount of CDR traffic, through ODBC to a MariaDB on a remote server |
| 19:22.49 | gtjoseph | sorry, not from me. |
| 19:23.05 | F2Knight | joy . |
| 19:33.22 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-84-109-18-138.red.bezeqint.net) |
| 19:33.22 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 19:43.29 | *** join/#asterisk-dev klow (~textual@96.81.150.137) |
| 21:25.36 | *** join/#asterisk-dev klow (~textual@96.81.150.137) |