| 00:09.40 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 00:27.58 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 00:39.43 | *** join/#asterisk-dev terryw (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 01:11.40 | *** join/#asterisk-dev philippel (uid10480@gateway/web/irccloud.com/x-wkitoqvssrxbinuk) |
| 01:20.26 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 01:20.26 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 01:22.59 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 01:28.21 | *** join/#asterisk-dev sgriepentrog (~sgriepent@2602:306:bdc4:84e0:20c:29ff:fe01:6302) |
| 13:07.50 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 13:07.50 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Asterisk 12 now released. Do the release dance! -=- Follow on Twitter at @AsteriskDev |
| 13:48.39 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-mvbfqidtiriiyqbs) |
| 13:48.39 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:50.25 | mjordan | elguero: ping |
| 13:51.05 | elguero | mjordan: pong - imagine in regards to failing test |
| 13:51.53 | mjordan | :-D |
| 13:51.58 | mjordan | I have a few I caused as well |
| 13:52.09 | mjordan | huzzah for continuous integration! |
| 13:52.40 | elguero | yep, awesome... I have a patch and was doing some extra testing |
| 13:53.39 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 13:56.31 | *** join/#asterisk-dev Dovid (~Dovid@static-173-63-105-210.nwrknj.fios.verizon.net) |
| 14:06.20 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-uewcmrfokbompqch) |
| 14:08.41 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-igxgivfxjxvcefqf) |
| 14:08.41 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:12.22 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:12.22 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:16.21 | file | elguero, I'm just glad we caught it |
| 14:19.19 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 14:25.10 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:25.10 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:35.10 | *** join/#asterisk-dev sgalarneau (~sgalarnea@nat/digium/x-ilhfvvnzewsroxvw) |
| 14:45.16 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-nvjhfymwzcqbpeky) |
| 14:47.49 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 14:59.15 | file | la la la |
| 15:05.51 | seanbright | i love that song |
| 15:26.17 | Qwell | seanbright: the cover is better |
| 15:28.45 | *** join/#asterisk-dev IMS77 (~IMS77@srvmail.castel.fr) |
| 15:30.22 | *** part/#asterisk-dev IMS77 (~IMS77@srvmail.castel.fr) |
| 15:40.46 | mjordan | oh stasis cache, how did I anger thee |
| 15:45.40 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.33) |
| 15:46.06 | file | mjordan, you EXISTED |
| 15:48.50 | mjordan | I know :-\ |
| 15:49.16 | mjordan | my abuse of topics and forwarding relationships has not gone unnoticed |
| 16:00.05 | opticron | putnopvut, merged into https://origsvn.digium.com/svn/asterisk/team/group/ari-greedy-atxfer |
| 16:01.24 | *** join/#asterisk-dev mbowie (~mbowie@162.212.36.9) |
| 16:03.13 | putnopvut | opticron: thanks muchly |
| 16:20.33 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.33) |
| 16:26.39 | tm1000 | file: you on? |
| 16:28.44 | file | yes |
| 16:31.19 | tm1000 | file: one last question about webrtc I swear, just trying to figure out a good way to determine if pjsip or chan_sip is controlling the websocket. The best way I can think of is to run: module show like res_pjsip_transport_websocket, and see if the use count is above 0 and status is Running |
| 16:31.51 | file | that should work |
| 16:32.14 | tm1000 | k |
| 16:32.28 | file | ponders |
| 16:32.39 | file | we could make the pjsip one use a different URL, actually |
| 16:36.33 | mjordan | file: if it were configurable on the transport, that would be a "good thing" |
| 16:37.34 | tm1000 | mjordan: I strongly agree |
| 16:37.42 | tm1000 | however I wasnt going to push anything since 12 is feature locked |
| 16:38.06 | tm1000 | file: different url, different something, but the guessing is kind of painful to be honest |
| 16:38.31 | file | it should be... possible |
| 16:38.36 | mjordan | well.... (a) it doesn't mean it should be done. (b) interoperability concerns are still problematic. Running chan_sip + chan_pjsip together is sort of what we were trying to ensure with this, and this feels like a bug (that is, you can't split apart the two on websockets easily) |
| 16:39.01 | mjordan | s/it should be done/it shouldn't be done |
| 16:39.29 | tm1000 | mjordan: Yeah its confusing in my land since I run both at the same time and I have to guess through the CLI which device to write out (think auto creating webrtc devices) |
| 16:47.50 | tm1000 | mjordan: because really if I have both chan_sip and pjsip enabled and I go and create a webrtc device on pjsip it wont work and how am I suppose to know that? (as an end user) if chan sip is taking control :-) |
| 16:48.36 | mjordan | rationalization! |
| 16:48.42 | file | sleepy |
| 16:48.46 | mjordan | tm1000: mind opening an issue for it? |
| 16:54.46 | tm1000 | mjordan: sure how would I word it? like how I put it above? |
| 16:54.53 | mjordan | yup |
| 17:07.50 | tm1000 | mjordan: also thereâs no permit/deny in pjsip? |
| 17:07.59 | tm1000 | (I havent looked yet, just asking off hand) |
| 17:08.23 | tm1000 | might be in auth though I assume |
| 17:26.09 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 17:35.36 | tm1000 | mjordan: file https://issues.asterisk.org/jira/browse/ASTERISK-24106 |
| 17:36.44 | mjordan | tm1000: thanks |
| 18:23.58 | putnopvut | jrose_atDigium: I've noticed something interesting when it comes to the ordering of SUBSCRIBE responses and NOTIFYs that Asterisk sends. |
| 18:24.35 | jrose_atDigium | Is interesting synonymous with annoying in this usage? |
| 18:24.55 | putnopvut | Looking at the code, it seems like the order of messages should be receive SUBSCRIBE, send NOTIFY, send 200 OK for SUBSCRIBE. However, when I performed manual tests I saw it go receive SUBSCRIBE, send 200 OK for SUBSCRIBE, send NOTIFY. |
| 18:25.09 | putnopvut | But I can swear in past tests, I had it go the "expected" way. |
| 18:25.32 | putnopvut | The big difference is that I upgraded my PJSIP installation, and it may be that upgrading it caused the order of messages to change to the way I saw them occur in my manual tests. |
| 18:25.54 | jrose_atDigium | Well, on initial subscribes I'm getting rx: SUBSCRIBE -> tx: 200 -> tx: NOTIFY |
| 18:26.13 | jrose_atDigium | on resubscribes, I'm getting rx: SUBSCRIBE -> tx: NOTIFY -> tx: 200 |
| 18:26.17 | putnopvut | Yep. The ordering I was talking about only applied to subscription renewal and termination |
| 18:26.26 | jrose_atDigium | k |
| 18:26.32 | jrose_atDigium | I guess I could try upgrading PJSIP then. |
| 18:26.35 | putnopvut | On the initial SUBSCRIBE, it's impossible to send a NOTIFY until the dialog is established. That occurs with the 200 OK. |
| 18:27.03 | putnopvut | Yeah, give that a shot and see if it makes a difference. If it doesn't, then ... I'll have to figure out what makes that happen. |
| 18:27.30 | jrose_atDigium | will do |
| 18:33.16 | putnopvut | jrose_atDigium: so, I just ran a manual test and found that on unsubscribing, the order went receive SUBSCRIBE, send NOTIFY, send 200 OK. However, my SIPp scenario that I wrote still passed because I used the start_txn and response_txn attributes in my scenario. So the SIPp scenarios in the test need to be altered to use those attributes so that ordering of the messages in different transactions won't matter. |
| 18:33.40 | putnopvut | I'll pastebin the scenario I used so you can see what I mean. |
| 18:33.43 | jrose_atDigium | kk |
| 18:33.54 | jrose_atDigium | I just checked my pjsip version and it's up to date anyway. |
| 18:35.09 | putnopvut | http://ur1.ca/htbfj |
| 18:35.41 | putnopvut | Notice that the final SUBSCRIBE I send has start_txn="endit" and the 200 OK for the SUBSCRIBE has response_txn="endit" |
| 18:35.57 | putnopvut | Even though the NOTIFY was received before the 200 OK, the scenario still passed. |
| 18:37.37 | putnopvut | jrose_atDigium: omg, scatch what I just told you. |
| 18:37.44 | putnopvut | or "scratch" rather. |
| 18:37.46 | file | lol |
| 18:37.58 | jrose_atDigium | Yeah, I tried it without much luck. |
| 18:39.39 | putnopvut | SO! The reason my manual testing worked is due to a bit of a fluke. |
| 18:41.03 | putnopvut | Here's what happens: Asterisk receives SUBSCRIBE. Asterisk attempts to send NOTIFY. Since the NOTIFY is huge, PJSIP attempts to use TCP to send the NOTIFY. The SIPp scenario is not set up for TCP so this fails. Now the 200 OK for the SUBSCRIBE is sent. Now the NOTIFY is resent using the fallback transport of UDP. |
| 18:41.25 | jrose_atDigium | oooooh my. |
| 18:41.39 | putnopvut | The reason why my scenario was passing was because the 200 OK for the SUBSCRIBE was able to sneak in between the two attempts to send the NOTIFY. |
| 18:42.04 | jrose_atDigium | I hope then that I don't run into that too soon. |
| 18:42.32 | jrose_atDigium | At least not while doing regular list tests... suddenly lists of lists is starting to sound more cringeworthy |
| 18:42.39 | putnopvut | So in your case, the scenario failed either because sending the large message over TCP succeeded, or because the NOTIFY was not large enough to warrant sending over TCP |
| 18:43.08 | putnopvut | Can you pastebin what the NOTIFY looked like in your scenario? |
| 18:43.17 | sgalarneau | lists of lists -> caddr |
| 18:43.49 | jrose_atDigium | Well, I would... |
| 18:43.54 | jrose_atDigium | but www.pastebin.com |
| 18:44.04 | jrose_atDigium | oh |
| 18:44.07 | jrose_atDigium | and now it's working again |
| 18:44.17 | jrose_atDigium | it was overloaded for a short bit |
| 18:44.47 | jrose_atDigium | http://pastebin.com/8nVptFMj |
| 18:44.49 | jrose_atDigium | there you go |
| 18:45.02 | jrose_atDigium | putnopvut: ^ |
| 18:45.34 | putnopvut | Yeah, so it's failing the TCP send and falling back to UDP, but it's happening for you before attempting to send the 200 OK. Interesting. |
| 18:47.12 | jrose_atDigium | I don't think it's trying to do TCP at all. |
| 18:47.45 | jrose_atDigium | I set the transport to UDP and nothing is mentioned about it doing any fallback in the logs. |
| 18:48.36 | putnopvut | "0851 (tdta0x7f1f94011d60), will try next server: Unsupported transport (PJSIP_EUNSUPTRANSPORT)" is at the top of your log. |
| 18:48.45 | jrose_atDigium | ah |
| 18:48.47 | putnopvut | Not sure what was before that. |
| 18:48.52 | jrose_atDigium | I'll grab it |
| 18:49.08 | jrose_atDigium | [Jul 23 13:18:51] DEBUG[16502] res_pjsip_endpoint_identifier_user.c: Retrieved endpoint sipp |
| 18:49.10 | jrose_atDigium | [Jul 23 13:18:51] WARNING[16502] pjsip: tsx0x7f1f94013 .......Temporary failure in sending Request msg NOTIFY/cseq=30851 (tdta0x7f1f94011d60), will try next server: Unsupported transport (PJSIP_EUNSUPTRANSPORT) |
| 18:49.10 | jrose_atDigium | [Jul 23 13:18:51] VERBOSE[16502] res_pjsip_logger.c: <--- Transmitting SIP request (2403 bytes) to UDP:127.0.0.1:5061 ---> |
| 18:49.40 | jrose_atDigium | Prior to that it was just a log of the SUBSCRIBE message |
| 18:51.46 | putnopvut | Ah! That PJSIP_EUNSUPTRANSPORT is because PJSIP is trying to send over TCP, but you don't have any TCP transports set up at all. So it's a quick failure. In my case, I have a TCP transport, but it's the far end (SIPp) that does not. So Asterisk actually transmits the NOTIFY over TCP (and I can see it in the log) and falls back to UDP because the far end did not accept the TCP connection. |
| 18:52.43 | putnopvut | So in your case, the failure is detected immediately and the fallback likely happens within the same thread. In my case, The failure is detected by the event loop and it automatically falls back to UDP later. |
| 18:52.53 | putnopvut | So much is being explained, now :) |
| 18:54.17 | putnopvut | So, going forward, if we want to have consistency in tests, we want to have an environment that mimicks yours. So the ordering of the messages in the scenario needs to be altered so that for resubscription and subscription termination, the expected order is receive SUBSCRIBE, send NOTIFY, send 200 OK for SUBSCRIBE. |
| 19:02.51 | jrose_atDigium | Hmmm, interesting. |
| 19:03.55 | file | 2403 bytes, tasty |
| 19:09.44 | leifmadsen | fragmentation! |
| 19:11.38 | mjordan | what we have here is a failure to communicate |
| 19:13.08 | gtjoseph | mjordan: you need to work on your accent. |
| 19:14.02 | mjordan | I can't really fake it very well. |
| 19:14.36 | gtjoseph | try this... what we have heah is a failyah ta communicate |
| 19:17.57 | putnopvut | There's controversy about whether the warden actually says "a" in the sentence or not. |
| 19:22.02 | gtjoseph | Looks like Strother Martin's character says "What we've got here is failure to communicate" but Paul Newman's character says "What we have here is a failure to communicate" at the end of the film. |
| 19:26.17 | leifmadsen | but what do they say in the G'n'R song? |
| 19:26.18 | leifmadsen | :D |
| 19:27.23 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 19:27.23 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:38.09 | TazzNZ | morning all |
| 19:40.59 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 19:57.37 | newtonr | mjordan, how could we make the raw sounds from sounds trunk available to Stephen and Dennis (re: their list message) ? I'm guessing right now you can only get access if you have a cert for origsvn? |
| 19:58.38 | newtonr | Yeah looks like you need origsvn access to check it out |
| 20:02.38 | mjordan | newtonr: do we have the sounds they were looking for? |
| 20:03.44 | newtonr | Yeah in sounds trunk. They want the raw 48kHz core and extra prompts, rather than the converted flavors. |
| 20:04.05 | Qwell | extra sounds is definitely not 48k |
| 20:04.13 | mjordan | you could always tar it up. |
| 20:04.13 | newtonr | yeah not all of extra is |
| 20:04.20 | newtonr | some of extra is |
| 20:04.52 | mjordan | I'd svn export it, tar it up, and see how big it is |
| 20:05.01 | leifmadsen | it'll be pretty large :) |
| 20:05.03 | mjordan | and probably just the en versions |
| 20:05.08 | leifmadsen | that. |
| 20:05.15 | leifmadsen | and only the new ones that were re-recorded |
| 20:05.38 | mjordan | yup |
| 20:05.54 | mjordan | if the tarball is prohibitively large, we can try to think of something else. |
| 20:06.47 | newtonr | alrighty |
| 20:10.47 | *** join/#asterisk-dev Tim_Toady (~fuzzy@snf-33276.vm.okeanos.grnet.gr) |
| 20:29.25 | newtonr | lol, the command, file, identifies "extra/en/fifth.wav" and a couple others as "Claris clip art?" |
| 20:48.41 | putnopvut | Ugh. Ever spend a lot of time crafting the perfect solution to the problem, and with about 2% left, you realize that that final 2% is impossible to do and you have to do it all over again? |
| 20:49.22 | sgalarneau | in general, or today? |
| 20:51.59 | putnopvut | Well, I had it happen today. |
| 20:52.59 | newtonr | putnopvut, that is when you realize that alcohol IS the solution to the problem |
| 20:53.12 | putnopvut | maybe. |
| 20:53.23 | putnopvut | And by "maybe" I mean "definitely" |
| 20:54.41 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 20:54.41 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:01.40 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:02.11 | leifmadsen | putnopvut: yes... I hate this. |
| 21:02.42 | mjordan | putnopvut: nuts. |
| 21:03.02 | mjordan | putnopvut: file: as an aside, do you know if we have an API call that reports (any) of the local addresses? |
| 21:03.15 | mjordan | I'm finding that reporting a local address of 0.0.0.0 is not what people are looking for |
| 21:03.39 | putnopvut | mjordan: in what context? I think PJSIP provides a function to get the local IP address. Not sure if there's anything within Asterisk for it though. I'd have to look. |
| 21:03.51 | mjordan | no worries, I can look |
| 21:05.31 | putnopvut | ast_find_ourip() perhaps? |
| 21:05.52 | putnopvut | include/asterisk/acl.h |
| 21:08.12 | *** join/#asterisk-dev sgriepentrog (~sgriepent@75.76.28.27) |
| 21:09.51 | mjordan | I love how that is in acl.h |
| 21:22.14 | *** join/#asterisk-dev terryw (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 21:22.37 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 21:25.28 | ipengineer | Does anyone know if Asterisk/PJSIP not setting the r-uri based on the contact from the 200 ok is a known issue? This issue has crept up in later versions. |
| 21:26.16 | ipengineer | I am not sure where it broke down but 12.0.0 was working as expected and not sure what release after that changed how the ruri is being set |
| 21:35.19 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-uewcmrfokbompqch) |
| 21:37.16 | ipengineer | Here is the SIP TRACE with the 200 and ACK: https://gist.github.com/zconkle/d0a65f7c4cde3093761f |
| 22:17.19 | *** join/#asterisk-dev bulkorok (~Benjamin@gw1.pinguin.ag) |
| 22:55.31 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 22:55.31 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 23:28.18 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 23:35.01 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 23:55.46 | *** part/#asterisk-dev bulkorok (~Benjamin@gw1.pinguin.ag) |