| 00:18.35 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 00:18.35 | *** 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:12.32 | coreyfarrell | tzafrir: not sure if you're interested, I just posted a review that adds some support for systemd socket activation - https://gerrit.asterisk.org/5877 |
| 01:13.35 | coreyfarrell | just mentioning since you added the initial support for systemd sd_notify. |
| 01:59.43 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8065:f0e7:c36b:87f:fad6) |
| 01:59.43 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 06:36.00 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 06:40.51 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:47.22 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:52.57 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a06:a402:100:0:b52d:f5a3:433:72ff) |
| 07:50.54 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:50.54 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:55.00 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:32.10 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a06:a402:100:0:b52d:f5a3:433:72ff) |
| 08:48.22 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a06:a402:100:0:b52d:f5a3:433:72ff) |
| 08:50.25 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a06:a402:100:0:b52d:f5a3:433:72ff) |
| 08:53.42 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a06:a402:100:0:b52d:f5a3:433:72ff) |
| 09:06.42 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 09:26.56 | *** join/#asterisk-dev leifmadsen (~leifmadse@asterisk/documenteur-extraordinaire/blitzrage) |
| 09:26.56 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 10:04.26 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 13:33.11 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 13:33.11 | *** 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 |
| 13:36.32 | gtjoseph | coreyfarrell: what's the use case for asterisk socket activation? |
| 13:41.14 | tzafrir | And how long does it typically take for Asterisk to respond to this initial activation? |
| 13:41.32 | gtjoseph | i just tried the cli activation and it was immediate |
| 13:49.54 | gtjoseph | same for ami |
| 13:51.20 | tzafrir | Regarding stopping asterisk: the README recommends against 'core stop now'. |
| 13:51.44 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-briiyqqdaqquvebw) |
| 13:51.44 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 13:52.20 | tzafrir | Is the SIGTERM handler (under systemd, so all child processes will die) good enough? |
| 13:54.10 | gtjoseph | i'm not thriled with SIGTERM if there are open database connections or transactions in flight. |
| 14:11.37 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-atdnesnfuhezpwdn) |
| 14:11.37 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:18.01 | *** join/#asterisk-dev libardi (~libardi@179.159.11.133) |
| 14:22.08 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:22.08 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:25.36 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-tpxqbqiiptbwdfpy) |
| 14:25.36 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:09.23 | coreyfarrell | gtjoseph: I responded to your comments on gerrit. |
| 15:09.48 | coreyfarrell | about SIGTERM I think that's probably the safest way to have systemd stop asterisk. |
| 15:10.39 | coreyfarrell | if you use "core stop gracefully" and any channel is active it will timeout, then systemd will send SIGKILL. |
| 15:11.45 | coreyfarrell | maybe we need something between 'core stop now' and 'core stop gracefully' which would immediately hangup all channels then do the graceful style shutdown? |
| 15:12.12 | gtjoseph | that'd be interesting |
| 15:17.39 | coreyfarrell | worth noting: db.c is shutdown cleanly by SIGTERM (reliably). If you tell systemd to use 'core stop gracefully' and it times out due to an open channel this would cause asterisk to terminate without running db.c cleanup. |
| 15:18.35 | gtjoseph | ah, cool |
| 15:18.44 | gtjoseph | well, kinda |
| 15:18.46 | coreyfarrell | tzafrir: I didn't find anything about 'core stop now' in the README or man file. can you point me to the document which recommends against it? |
| 15:19.13 | tzafrir | I meant the README.txt of this commit |
| 15:21.18 | coreyfarrell | ah.. if using CLI socket activation it is not recommended to use CLI to stop Asterisk. in Asterisk SIGTERM does the same thing as 'core stop now'. |
| 15:24.15 | coreyfarrell | during my testing I configured Asterisk incorrectly where it refused startup resulting in exit(1), in this case systemd (231 at least) still runs the ExecStop command. |
| 15:47.15 | *** join/#asterisk-dev newtonr (~newtonr@99-104-129-136.lightspeed.brhmal.sbcglobal.net) |
| 15:47.15 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 15:51.26 | coreyfarrell | gtjoseph: BTW I'm running into an issue now with the http activation. I think it has something to do with FreeBind=true. it'll be a little bit before I can test it further though my system is a bit frozen right now. |
| 15:51.47 | gtjoseph | no prob |
| 15:55.30 | file | rmudgett: I tried to cheat on my declined streams, it didn't pan out |
| 15:55.59 | gtjoseph | cheating = bad |
| 15:56.20 | rmudgett | file: Cheat how? |
| 15:57.47 | file | rmudgett: I used a fixed payload for the required one in the declined stream |
| 15:57.59 | file | but our tests explicitly test for all the offered payloads |
| 15:58.40 | rmudgett | The rfc says only the first payload is required |
| 15:58.51 | file | sorta |
| 15:59.15 | file | At least one MUST be present, as specified by SDP. |
| 15:59.36 | file | but I don't see a requirement that it has to be from the offer, and it specifically states it is ignored |
| 16:03.31 | rmudgett | I wasn't sure about that either. I took it to mean only the first offered had to be returned. |
| 16:04.01 | rmudgett | and none of the attributes needed to be added either. |
| 16:04.11 | file | yeah |
| 16:07.41 | file | that's my only SDP O/A test issue right now, so that's coooool |
| 16:12.41 | gtjoseph | rmudgett: re your comment on using bridge->tech_pvt... this would require creating a new structure, vectors, and memory management since native_rtp_bridge_start is called twice with bridge in the exact same state and the exact same arguments. |
| 16:14.06 | rmudgett | Yes, yes it would. It will also have the right lifetimes for the rtp instances. |
| 16:14.21 | gtjoseph | or i could just move the detach |
| 16:14.34 | gtjoseph | which i thought i did |
| 16:14.41 | gtjoseph | but it must have gotten lost |
| 16:15.06 | rmudgett | The bridge_channel->tech_pvt is destroyed when the framehook is detached and that happens before the stop call. |
| 16:15.39 | rmudgett | The stop call needs to clear the bridge pointers for both channels while the channel locks are held. |
| 16:17.32 | gtjoseph | it does clear the bridger pointers |
| 16:18.15 | gtjoseph | when the first channel leaves the bridge |
| 16:19.23 | rmudgett | It needs to clear the bridge pointers using the saved rtp instance pointers and not asking the channel driver for them. The channel driver may not give the same pointers (or likely not return them) when the start was called. |
| 16:19.50 | gtjoseph | yeah ok |
| 16:21.08 | gtjoseph | really i need to save off glue |
| 16:21.52 | file | misread save as sniff, was concerned |
| 16:22.04 | gtjoseph | that too |
| 16:36.42 | file | and just like that, SDP O/A passes, as do basic calls |
| 16:37.37 | file | is fax still broken? yes, but that's by design |
| 16:38.17 | file | nothing? tough crowd |
| 16:52.59 | gtjoseph | @rmudgett: are reading the correct patch??? ramehook detach WAS being called after bridge_stop. |
| 16:53.08 | coreyfarrell | gtjoseph: I figured out the issue, it wasn't FreeBind=true.. for some reason the first call to getsockname silently fails, returns something with sockaddr.sa_family == AF_UNSPEC. so the sockaddr comparison fails. |
| 16:53.10 | gtjoseph | s/ramehook/framehook/ |
| 16:53.25 | gtjoseph | @coreyfarrell: gotchA |
| 16:54.41 | coreyfarrell | this means that HTTP socket activation would fail only if it was the first FD passed to asterisk. in earlier tests systemd must have been passing CLI or AMI as the first FD. |
| 17:01.46 | rmudgett | gtjoseph: Ok so you had changed the ordering. Still doesn't change the fact that it is the bridge that must guarantee to undo what was done on start when stopping the native bridge. |
| 17:24.27 | *** join/#asterisk-dev DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
| 17:24.27 | *** mode/#asterisk-dev [+o DivideBy0] by ChanServ |
| 18:14.44 | *** join/#asterisk-dev opticron_ (~opticron@75.76.59.35) |
| 18:14.44 | *** mode/#asterisk-dev [+o opticron_] by ChanServ |
| 18:17.41 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00bdb66a44e3af352c.ipv6.abo.wanadoo.fr) |
| 18:40.35 | dan_j | gtjoseph: I'm around for the next 2 hours if you are. If not convenient, I'll try again tomorrow. |
| 18:41.16 | gtjoseph | actually i'm getting ready to go on vacation so one of the other team members might have to help you out. |
| 18:41.21 | gtjoseph | @cresl1n: ^^ |
| 18:41.28 | dan_j | ok, enjoy |
| 18:41.40 | cresl1n | Thanks gtjoseph for the mention |
| 18:42.10 | gtjoseph | I was merely pointing out that you might have to get someone else. :) |
| 18:42.26 | cresl1n | I grok'd it |
| 18:43.38 | file | vacation all I ever wanted, vacation had to get away |
| 18:45.57 | *** join/#asterisk-dev DivideBy0x0 (~DivideBy0@unaffiliated/divideby0x0) |
| 18:45.57 | *** mode/#asterisk-dev [+o DivideBy0x0] by ChanServ |
| 18:46.13 | cresl1n | sends file some roofers |
| 18:46.24 | file | cresl1n: thanks! |
| 18:57.14 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-adhvsgpkztciicgk) |
| 18:57.14 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 19:23.11 | *** join/#asterisk-dev malcolmd (malcolmd@pdpc/sponsor/digium/malcolmd) |
| 19:23.11 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 19:43.28 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 19:43.28 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 20:06.13 | gtjoseph | rmudgett: is there any value at all in having native_rtp_bridge_start called twice in the exact same context? right now it is, once for each channel and we do the full processing each time. |
| 20:07.03 | gtjoseph | basically we call the exact same code with the exact same parameters each time. |
| 20:08.39 | rmudgett | Is this the call from native_rtp_bridge_join()? |
| 20:08.45 | gtjoseph | yeah |
| 20:09.21 | rmudgett | That is called for each channel that joins. The first channel should short circuit out early since the second hasn't joined yet. |
| 20:09.41 | gtjoseph | well, they have kinda. |
| 20:09.59 | gtjoseph | join is literally called in a traverse of bridge->channels |
| 20:10.57 | gtjoseph | so both channels are already in that list when join is called the first time |
| 20:11.03 | gtjoseph | but if there's no value, i'll do the short circuit |
| 20:15.08 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 20:18.32 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-170.cust.bezeqint.net) |
| 20:18.32 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:19.53 | rmudgett | Yeah. We are officially telling the technology that the channel has joined. Looking at the bridge_native_dahdi.c implementation, I only start it once. IIRC that is why I also created the tech->start/stop callbacks. |
| 20:20.10 | gtjoseph | gotcha |
| 20:21.36 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-rrmtixsywalexakl) |
| 20:21.36 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 20:22.07 | gtjoseph | so i wonder then. sdhould start and stop actually be called by the start and stop callbacks rather than the join leave callbacks??? |
| 20:22.45 | file | be very very careful.. |
| 20:23.00 | gtjoseph | i know, that's why i'm asking. |
| 20:25.44 | gtjoseph | any history on why native didn't use start/stop or did it just predate rmudgett's addition of the callbacks? |
| 20:26.37 | file | I do not recall, that module has gone through a lot of tweaking to make it work through the different cases |
| 20:26.54 | rmudgett | join/leave predated start/stop. I created start/stop when I did the dahdi native bridge |
| 20:28.21 | rmudgett | the rtp native bridge existed before I created the dahdi native bridge |
| 20:36.15 | gtjoseph | the start and stop callbacks aren't symmetric. :( |
| 20:36.23 | gtjoseph | start gets called after the joins |
| 20:36.40 | gtjoseph | stop gets called after the leaves |
| 20:38.07 | rmudgett | I was noticing that. The start/stop have slightly different sues for native type bridges vs bridge techs that bridges can be created with. |
| 20:38.20 | rmudgett | s/sues/uses/ |
| 20:38.32 | gtjoseph | yep |
| 20:39.00 | gtjoseph | by the time stop is called, the channels are gone so there's really no cleanup that can be done there |
| 20:39.28 | gtjoseph | but thstya may be good |
| 20:39.31 | gtjoseph | start |
| 20:39.36 | rmudgett | create->start->join->leave->stop->destroy and in the smartbridge operation their ordering it a bit different. |
| 20:40.03 | gtjoseph | yeah, start and join are reversed |
| 20:40.54 | gtjoseph | actually i'd think join then start would be correct |
| 20:41.10 | gtjoseph | start the bridge once the required number of channels are joined |
| 20:41.22 | rmudgett | For native techs in a smartbridge operation that works best. |
| 20:43.17 | rmudgett | Any channel leaving acts as a stop for native bridge techs |
| 20:43.43 | gtjoseph | all of them? |
| 20:43.48 | gtjoseph | i haven't looked |
| 20:45.08 | rmudgett | For native bridge techs like rtp and dahdi, any channel leaving needs to act like a stop because two and only two channels can be in a native bridge for it to function. |
| 20:46.08 | gtjoseph | yeah makes sense |
| 21:03.40 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.174) |
| 21:07.21 | gtjoseph | crap i was hoping to avoid using a vector but i guess not |
| 21:09.16 | rmudgett | It will work better in master with multistream support. |
| 21:09.27 | gtjoseph | i can't wait that long :) |
| 21:09.28 | file | eventually. |
| 21:10.09 | rmudgett | The vector will work better... |
| 21:11.51 | gtjoseph | kinda. just one more thing to maintain |
| 21:12.15 | gtjoseph | unless..... |
| 21:12.30 | gtjoseph | there's a path to get a specific framehook from a channel |
| 21:13.20 | rmudgett | For that you need the framehook id and the channel. |
| 21:13.42 | gtjoseph | yeah but then i'd have the same issue of having to store off the id. |
| 21:14.09 | gtjoseph | to bad there wasn't a char[] in the hook interface |
| 21:15.16 | gtjoseph | oh, maybe i can compare the event_cb pointer to see if it's the bridges. |
| 21:15.40 | file | remember: don't be clever |
| 21:16.12 | gtjoseph | i'm trying to work within the constraints available. :) |
| 21:21.48 | *** join/#asterisk-dev Gugge (gugge@92.246.2.105) |
| 21:21.55 | *** join/#asterisk-dev Tim_Toady (~fuzzy@snf-33276.vm.okeanos.grnet.gr) |
| 23:03.39 | *** join/#asterisk-dev leedm777 (~textual@173-16-52-28.client.mchsi.com) |
| 23:03.39 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 23:21.22 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-atdnesnfuhezpwdn) |
| 23:48.19 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8021:a46b:4db8:8b13:947a) |
| 23:48.20 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |