| 00:09.29 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 00:09.29 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 00:21.19 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 00:21.19 | *** 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 |
| 01:10.06 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-50-167-254.dialup.adsl.anteldata.net.uy) |
| 04:01.55 | *** join/#asterisk-dev sh_smith (foobar@cpe-76-174-26-91.socal.res.rr.com) |
| 06:03.52 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 06:45.35 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:48.44 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 06:48.45 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 06:52.46 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 07:38.36 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 09:01.48 | *** join/#asterisk-dev jkroon (~jkroon@165.255.161.211) |
| 09:26.30 | *** join/#asterisk-dev bof23 (~Thunderbi@185.13.183.107) |
| 12:28.35 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-frtjrkgowmktsjxo) |
| 12:28.35 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 12:35.08 | *** join/#asterisk-dev CELYA_ (~Thunderbi@149-221-190-109.dsl.ovh.fr) |
| 13:27.47 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 13:27.47 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 13:29.17 | cresl1n | waves |
| 13:29.37 | file | waves |
| 13:39.39 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-166-135.dialup.adsl.anteldata.net.uy) |
| 13:57.01 | *** join/#asterisk-dev newtonr (~newtonr@173-21-147-197.client.mchsi.com) |
| 13:57.01 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:00.42 | cresl1n | file: |
| 14:00.44 | cresl1n | your comment on https://gerrit.asterisk.org/#/c/5509/ |
| 14:01.19 | file | wat |
| 14:01.22 | cresl1n | Why did you think we should cherry pick that into 13 and 14? |
| 14:01.32 | file | because it's a bug fix that is applicable there? |
| 14:02.48 | cresl1n | ok |
| 14:02.54 | cresl1n | I guess it's only one line |
| 14:04.34 | cresl1n | file: what about his concerns? |
| 14:07.43 | file | update_peer is how PJSIP works, and the bridging module doesn't react to srcchange to trigger the re-invite |
| 14:07.53 | file | and the minimum change required to fix it is that one line change |
| 14:08.08 | cresl1n | thanks for explaining :-) |
| 14:14.35 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-yisacxzuhqjqjqub) |
| 14:14.35 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:19.37 | cresl1n | waves to kharwell |
| 14:19.50 | kharwell | cresl1n: ahoy |
| 14:19.59 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:20.00 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:38.23 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-ykmobytexbsrgmlz) |
| 14:38.23 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:07.43 | *** join/#asterisk-dev zopsi (~zopsi@dir.ac) |
| 15:34.18 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-kxrmawssgsmguulj) |
| 15:34.18 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 15:49.36 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:53.12 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 16:43.45 | *** join/#asterisk-dev newtonr_ (~newtonr@173-21-147-197.client.mchsi.com) |
| 16:43.45 | *** mode/#asterisk-dev [+o newtonr_] by ChanServ |
| 16:52.33 | *** join/#asterisk-dev newtonr (~newtonr@173-21-147-197.client.mchsi.com) |
| 16:52.33 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 16:55.30 | *** join/#asterisk-dev newtonr__ (~newtonr@173-21-147-197.client.mchsi.com) |
| 16:55.30 | *** mode/#asterisk-dev [+o newtonr__] by ChanServ |
| 17:00.18 | *** join/#asterisk-dev newtonr (~newtonr@173-21-147-197.client.mchsi.com) |
| 17:00.18 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 17:34.58 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 17:52.19 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-170.cust.bezeqint.net) |
| 17:52.19 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 17:58.57 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 17:58.57 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 18:14.18 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 18:14.18 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 18:16.07 | seanbright | never good to forget your nickserv password |
| 18:17.22 | file | says you |
| 18:17.43 | *** join/#asterisk-dev Marquis42 (~Marquis42@d14-69-240-195.try.wideopenwest.com) |
| 18:17.43 | *** mode/#asterisk-dev [+o Marquis42] by ChanServ |
| 18:22.28 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-ordpzpyjdieeqzqk) |
| 18:23.24 | jameswf | @file mind a PM? |
| 18:23.34 | file | sure |
| 18:24.40 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-mykgzfqqioundgcz) |
| 18:24.40 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 18:28.51 | *** join/#asterisk-dev newtonr_ (~newtonr@173-21-147-197.client.mchsi.com) |
| 18:28.51 | *** mode/#asterisk-dev [+o newtonr_] by ChanServ |
| 18:29.40 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d002928690bad647759.ipv6.abo.wanadoo.fr) |
| 18:43.47 | putnopvut | So, I just learned, like right this past minute, that Asterisk "cheats" when sending RTCP SDES packets by putting a CNAME block in there but having it be zero-length. |
| 18:44.39 | putnopvut | For the task I'm currently working, I want to put an SDP attribute in outgoing media descriptions that says "The following RTP SSRC is associated with the following CNAME" |
| 18:44.43 | file | fakes surprise |
| 18:44.49 | putnopvut | I *thought* I'd be able to just use what we have already |
| 18:44.54 | putnopvut | But it turns out, we have nothing. |
| 18:45.08 | putnopvut | So if we were to start populating the CNAME with something, what should we populate it with? |
| 18:45.20 | seanbright | sean bright |
| 18:45.31 | seanbright | that's my vote |
| 18:45.34 | putnopvut | Done! |
| 18:45.36 | file | I... don't know |
| 18:45.41 | file | winning lottery numbers! |
| 18:45.45 | putnopvut | a=ssrc 12345678 cname:sean bright |
| 18:46.24 | putnopvut | This seems like a good bike-shed topic for the dev-list |
| 18:46.37 | seanbright | Therefore, the CNAME should be derived algorithmically and not entered manually, when possible. To meet these requirements, the following format should be used unless a profile specifies an alternate syntax or semantics. The CNAME item should have the format "user@host", or "host" if a user name is not available as on single- user systems. For both formats, "host" is either the fully qualified domain name of the host |
| 18:47.19 | putnopvut | Hm, sounds like we could cheat a bit and just use the hostname of the system |
| 18:47.26 | putnopvut | But we'd have a lot of duplicate cnames that way |
| 18:48.08 | putnopvut | So probably would make sense to have it be something like "<channel_name>@<host>" |
| 18:48.49 | putnopvut | Hm, but then you'd have repeated CNAMEs across media streams on a session |
| 18:49.11 | putnopvut | So maybe "<channel_name>-<media_type>-<index>@<host>" |
| 18:49.24 | putnopvut | Where media_type is "audio" "video" etc |
| 18:49.35 | putnopvut | and index is the index of the stream. |
| 18:49.38 | *** join/#asterisk-dev samoied (~samoied@186.222.23.25) |
| 18:49.46 | putnopvut | I think I'll go with that. |
| 18:49.49 | samoied | Hello Guys! |
| 18:49.58 | seanbright | i have no idea if i reading canonical documentation on the subject |
| 18:50.03 | seanbright | i am* |
| 18:50.12 | samoied | Anyone knows a HA solution for asterisk, that can handle active calls? |
| 18:50.48 | samoied | I can replicate sip registration state easily. |
| 18:51.15 | samoied | But didn't found any way to continue a call in another server. |
| 18:51.58 | seanbright | putnopvut: To provide a binding across multiple media tools used by one participant in a set of related RTP sessions, the CNAME should be fixed for that participant. |
| 18:52.11 | seanbright | i don't know enough to say that means across audio/video/whatever |
| 18:52.28 | putnopvut | Hrm |
| 18:52.45 | putnopvut | Well RTP sessions indicates more than just multiple streams. |
| 18:53.01 | putnopvut | So it's almost like you're indicating a user rather than a unique name |
| 18:53.32 | putnopvut | So something simple like "<device>@<host>" |
| 18:54.05 | putnopvut | samoied: sorry not ignoring you, but I'm not really clued in very well on that sort of thing, sorry. |
| 18:54.41 | seanbright | putnopvut: yes |
| 18:55.16 | seanbright | what does pjsip do? |
| 18:55.16 | seanbright | heh |
| 18:55.20 | samoied | putnopvut: no problem. Thanks. |
| 18:55.37 | putnopvut | seanbright: ha! great question |
| 18:56.21 | file | it builds a random string |
| 18:56.40 | file | at least for the video one |
| 18:56.52 | seanbright | i think the UAC use case is simple |
| 18:56.59 | seanbright | with a B2BUA it's a lot more complicated |
| 18:57.13 | seanbright | OR |
| 18:57.15 | file | yeah, it builds a random string for both |
| 18:57.17 | seanbright | i'm talking out of my ass |
| 19:01.02 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-uffwntvxpiwsokbd) |
| 19:01.02 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 19:02.43 | rmudgett | Could use some eyes on https://gerrit.asterisk.org/#/c/5415/ to get that patch in. Eyes gtjoseph, file, seanbright |
| 19:03.10 | seanbright | rmudgett: did you +1 your own patch? |
| 19:03.11 | seanbright | tsk tsk |
| 19:04.08 | gtjoseph | looks |
| 19:08.03 | rmudgett | Nobody would think I was ok with the patch as it is even thought there are a lot of memory leaks. I have a more invasive follow on patch to fix those. :) |
| 19:08.48 | gtjoseph | so you want us to merge a patch with known leaks????? :) |
| 19:09.46 | rmudgett | Patch series aren't that easy to work with; especially when the patches are authored by several people. |
| 19:09.59 | gtjoseph | don't i know it |
| 19:11.04 | *** join/#asterisk-dev newtonr__ (~newtonr@173-21-147-197.client.mchsi.com) |
| 19:11.04 | *** mode/#asterisk-dev [+o newtonr__] by ChanServ |
| 19:11.36 | gtjoseph | ok, i'm gonna +2 it and let it fall where it may |
| 19:11.48 | seanbright | i'm reviewing |
| 19:11.56 | seanbright | and i already have a nitpick |
| 19:11.57 | gtjoseph | cool. i'll wait then |
| 19:12.06 | seanbright | meh, go for it/ |
| 19:12.23 | seanbright | RTP payload types can only be 7 bits, we don't need an int to store that |
| 19:12.29 | seanbright | that's my pedantry for the day |
| 19:14.57 | gtjoseph | thinking ahead for when we have 2 billion codecs |
| 19:15.19 | seanbright | future proof. |
| 19:16.48 | *** join/#asterisk-dev malcolmd (malcolmd@pdpc/sponsor/digium/malcolmd) |
| 19:16.48 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 19:17.55 | rmudgett | At the rate new codecs come along, we won't need to wait for the year 5 billion to have that many. |
| 19:21.00 | *** join/#asterisk-dev jkroon (~jkroon@105.7.110.16) |
| 19:28.15 | rmudgett | wishes he didn't have so many round holes when he only has square pegs |
| 20:42.05 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-hqukmtlkfxffqrih) |
| 20:42.06 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 20:53.42 | *** join/#asterisk-dev newtonr (~newtonr@173-21-147-197.client.mchsi.com) |
| 20:53.42 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 21:15.07 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-166-135.dialup.adsl.anteldata.net.uy) |
| 21:25.52 | gtjoseph | rmudgett: the issue with chanisavail is that it calls ast_request, which ultimately calls session_alloc but since the final free of session is done by the end of the pjsip transaction and we never start a transaction in the first place, nothing cleans up the session. |
| 21:27.41 | rmudgett | Yes and ast_request() followed by ast_hangup() is a valid call sequence. Off nominal error paths have to do it to get rid of a channel that was never called. You can even do it via ARI: Create the channel then delete it. |
| 21:28.45 | gtjoseph | yep, there needs to be a shortcut in ast_sip_session_terminate that detects if a request was never sent and unreffs csession |
| 21:29.24 | rmudgett | ast_sip_session_alloc() puts a ref here: inv_session->mod_data[session_module.id] = ao2_bump(session); that needs to be cleaned up. |
| 21:29.59 | gtjoseph | i know but it can onlt be cleaned up if a request wasn't sent |
| 21:30.56 | rmudgett | The PJSIP_INV_STATE_NULL case looks promising. |
| 21:31.14 | rmudgett | In ast_sip_session_terminate() |
| 21:32.19 | gtjoseph | yeah i have to look at the pjsip state machine to see when it changes it., |
| 21:32.35 | rmudgett | Though it may wind up in session_inv_on_tsx_state_changed or session_inv_on_state_changed |
| 21:33.10 | gtjoseph | if it did, it would have hit the cleanup task that unreffs session for good |
| 21:33.37 | rmudgett | Which is mostly why I hadn't created a fix to go with the issue. :) |
| 21:33.49 | gtjoseph | gee thanks :) |
| 21:37.39 | rmudgett | Dang it jenkins. Pass the SDP patch. What's this core dump format not recognized? |
| 21:38.13 | gtjoseph | that's a long standing issue that has nothing to do with jenkins |
| 21:38.24 | gtjoseph | i'll try and fix it tonight though |
| 21:39.22 | gtjoseph | oooooohhhh. i think i can test session->inv_session->invite_tsx for null |
| 21:40.44 | rmudgett | That would be true then but it will also be true after any INVITE transaction. |
| 21:40.55 | gtjoseph | nope |
| 21:41.05 | rmudgett | Right |
| 21:41.21 | rmudgett | *oh right |
| 21:42.33 | gtjoseph | if PJSIP_INV_STATE_NULL && session->inv_session->invite_tsx == NULL then i shoul dbe able to kill the session |
| 21:42.48 | gtjoseph | at least that's what testing shows so far |
| 21:44.54 | gtjoseph | i wish there was an indicator for outgoing session though |
| 21:45.37 | rmudgett | I think PJSIP_INV_STATE_NULL implies that the tsx hasn't been created yet. |
| 21:46.12 | gtjoseph | i've got a debug statement in there now and i'm trying some scenarios |
| 22:17.33 | *** join/#asterisk-dev samoied (~samoied@186.222.23.25) |
| 22:24.17 | *** join/#asterisk-dev newtonr_ (~newtonr@173-21-147-197.client.mchsi.com) |
| 22:24.17 | *** mode/#asterisk-dev [+o newtonr_] by ChanServ |
| 22:44.06 | *** join/#asterisk-dev newtonr (~newtonr@173-21-147-197.client.mchsi.com) |
| 22:44.06 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 22:59.54 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-yisacxzuhqjqjqub) |
| 23:09.47 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-164-222.dialup.adsl.anteldata.net.uy) |