| 00:14.37 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-88-3.dialup.adsl.anteldata.net.uy) |
| 00:19.47 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 00:19.47 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |
| 00:53.52 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-220-77.dialup.adsl.anteldata.net.uy) |
| 01:50.17 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-220-77.dialup.adsl.anteldata.net.uy) |
| 03:09.09 | *** join/#asterisk-dev scgm11_ (~scgm11@29.114.26.186.static.intelnet.net.gt) |
| 03:19.40 | *** join/#asterisk-dev chazzam (~chazz@vps.roguewerks.com) |
| 03:20.47 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-220-77.dialup.adsl.anteldata.net.uy) |
| 04:09.14 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 06:47.47 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 06:54.48 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 07:00.28 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 07:18.50 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.40) |
| 07:22.15 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:22.15 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:30.30 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 07:53.39 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:56.04 | *** join/#asterisk-dev zopsi (~zopsi@dir.ac) |
| 09:33.52 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 09:37.40 | *** join/#asterisk-dev moy (sid47040@gateway/web/irccloud.com/x-xzhimwtouutodkdf) |
| 11:58.07 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 12:30.12 | *** join/#asterisk-dev bof23 (~Thunderbi@185.13.183.107) |
| 12:50.56 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-50-102-28.dialup.adsl.anteldata.net.uy) |
| 12:57.52 | *** join/#asterisk-dev afournier (~admin@217.108.205.201) |
| 13:00.14 | stefan27 | seanbright or file ; I think I have narrowed down the potential problem with chan_sip's rtcp_mux related to the ice gathering process when asterisk receives an INVITE. I tried to sketch down the test case in https://pastebin.com/JvXTFRrA . |
| 13:00.29 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 13:00.52 | file | so, it's chan_sip specific? |
| 13:02.05 | *** join/#asterisk-dev newtonr (~newtonr@173-21-147-197.client.mchsi.com) |
| 13:02.05 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:02.06 | stefan27 | I do not know that, I just noticed what is written in the pastebin. but it looks like the chan_sip.c code set_ice_components() {... /* We both support RTCP mux. Only one ICE component necessary */ |
| 13:02.06 | stefan27 | <PROTECTED> |
| 13:02.26 | file | nods |
| 13:02.37 | stefan27 | but the SDP offer announces that it supports rtcp_mux but also sends RTCP candidates |
| 13:03.11 | stefan27 | asterisk seems to build rcand composed of both RTP and RTCP components, but we do end up using RTCP mux in the end, and for some reason this fact makes the ice checks fail |
| 13:04.11 | stefan27 | when the SDP offer announces rtcp_mux but does not provide RTCP candidates (corresponding to rtcpmuxpolicy require), asterisk only builds one component in its rcand, and the resulting ice checks end up succeeding |
| 13:04.56 | stefan27 | Do you or seanbright have a test environment where you can reproduce these call cases? It's quite hard to propagate all the data |
| 13:05.08 | file | nope, I haven't touched anything of that stuff |
| 13:05.27 | stefan27 | (assuming either of you deem this inofficial issue worth the time and want to debug it at this time) |
| 13:05.33 | stefan27 | Aha |
| 13:05.37 | file | I'd suggest filing an issue |
| 13:07.16 | stefan27 | Yeah I'll make a jira; was just wondering if I could directly discuss with the author of the related code |
| 13:07.37 | file | seanbright did the chan_sip part, putnopvut did the res_rtp_asterisk and chan_pjsip part |
| 13:08.40 | stefan27 | cool, maybe one of them will feel like discussing it later |
| 13:09.02 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 13:44.03 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 13:44.03 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 13:59.52 | file | hrm! |
| 14:02.17 | stefan27 | https://issues.asterisk.org/jira/browse/ASTERISK-26982 |
| 14:04.21 | stefan27 | I hope that defines a well-defined issue even if the description is ugly. |
| 14:16.10 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-eabjubpdblgwhbee) |
| 14:16.10 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:16.51 | cresl1n | stefan27: did you figure out which version it broke in? |
| 14:17.28 | stefan27 | yes, 13.15 |
| 14:19.44 | stefan27 | but I'm still playing with unknowns here. I don't know the semantics for rtcpMuxPolicy='require' vs rtcpMuxPolicy='negotiate' i.e. how that is supposed to be conveyed via SDP; the issue report is full of guesses in that way, but the symtoms are clear |
| 14:19.51 | stefan27 | I'm hoping someone else can repreoduce it |
| 14:44.00 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-ajpqubjjjwwwgiqc) |
| 14:44.00 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:48.35 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 15:48.35 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 15:56.05 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 16:42.09 | *** join/#asterisk-dev moy (sid47040@gateway/web/irccloud.com/x-fdhcmkdwloxtpjuh) |
| 16:46.08 | *** join/#asterisk-dev bof22 (~Thunderbi@ARennes-650-1-246-146.w2-14.abo.wanadoo.fr) |
| 16:51.59 | scgm11_ | @stefan27 I will try to reproduce the issue now with 13.15 and rtcpmux= yes |
| 17:02.51 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-32-13.wall.uls.co.za) |
| 17:10.23 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00cc46703f95273da7.ipv6.abo.wanadoo.fr) |
| 17:14.58 | *** part/#asterisk-dev afournier (~admin@217.108.205.201) |
| 17:39.01 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00cc46703f95273da7.ipv6.abo.wanadoo.fr) |
| 17:46.07 | *** join/#asterisk-dev libardi (~libardi@187.64.228.189) |
| 19:14.31 | stefan27 | Thank you scgm11_ for verifying the issue |
| 19:15.24 | kharwell | for app streamecho I can maybe see two case scenarios. 1. each stream is echoed back to itself 2. one stream is echoed onto all the others. Should I go ahead an put in support for both? Is there a third? |
| 19:15.42 | file | kharwell: k.i.s.s |
| 19:15.52 | scgm11_ | confimed the issue with firefox starting the call |
| 19:15.53 | stefan27 | If you have a JIRA account you can comment that you were able to reproduce the issue on https://issues.asterisk.org/jira/browse/ASTERISK-26982, otherwise I can update it tomorrow, but it would be nice if someone using pjsip could test it too |
| 19:16.23 | kharwell | file: so just the first one then for now? |
| 19:16.30 | scgm11_ | chrome to chrome seems to work ok |
| 19:17.00 | stefan27 | yeah chrome by default has rtcpMuxPolicy require so it doesn't send RTCP ice candidates |
| 19:17.20 | file | kharwell: I dunno from client side if 2 makes it easier or 1, that'd be my only ponderance |
| 19:23.22 | cresl1n | kharwell: only support case 2 for now |
| 19:23.31 | cresl1n | IMHO |
| 19:23.43 | cresl1n | that's the SFU case we're trying to support for app_confbridge |
| 19:23.56 | cresl1n | one sendonly, and 6 receiveonly or something like that |
| 19:24.59 | kharwell | heh 1 was easy so I already had that in, so I'll leave it and do 2 as well then since that'll support the other stuff |
| 20:14.50 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-170.cust.bezeqint.net) |
| 20:14.50 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:04.40 | *** join/#asterisk-dev malcolmd (malcolmd@pdpc/sponsor/digium/malcolmd) |
| 21:04.40 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 23:12.07 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-eabjubpdblgwhbee) |