| 05:26.36 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 05:26.36 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 06:47.52 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 06:48.22 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 06:54.07 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 07:19.14 | *** join/#asterisk-dev klow (~textual@c-98-247-49-57.hsd1.wa.comcast.net) |
| 07:19.22 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 07:19.22 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:36.49 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:26.10 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:26.10 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:12.33 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 09:12.33 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 10:39.00 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 10:39.01 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 11:33.41 | file | Monday! |
| 12:24.42 | *** join/#asterisk-dev malcolmd (malcolmd@pdpc/sponsor/digium/malcolmd) |
| 12:24.42 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 12:38.32 | *** join/#asterisk-dev oej (~oej@46-22-127-214.bredband.alvsjo.qonet.se) |
| 12:38.32 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:39.24 | *** join/#asterisk-dev Marquis42 (bwatkins@nat/redhat/x-uoielxwzwerazzku) |
| 12:51.39 | *** join/#asterisk-dev acidfu_ (~acidfoo@modemcable002.114-70-69.static.videotron.ca) |
| 14:01.44 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 14:09.15 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-gmdyzifvkzpodqkn) |
| 14:09.30 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 14:11.36 | *** join/#asterisk-dev kpfleming (kpfleming@unaffiliated/kpfleming) |
| 14:21.17 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-jxgbuabkwchgciyk) |
| 14:21.18 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:34.11 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-lvqqkcdgcbvorvkc) |
| 14:47.49 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-172.cust.bezeqint.net) |
| 14:47.49 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 14:50.53 | file | hrms |
| 14:54.39 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:54.39 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 15:01.03 | kpfleming | so⦠HSV geek lunch today? |
| 15:02.14 | file | kpfleming, please hold for 10 minutes - we're in standup |
| 15:13.02 | cresl1n | kpfleming! |
| 15:13.06 | cresl1n | you are in town? |
| 15:13.55 | file | he is! |
| 15:14.00 | file | he's somewhere in Digium HQ |
| 15:14.58 | kpfleming | i am on the third floor, in an office facing the flapole |
| 15:15.05 | kpfleming | in the (gasp) sales area |
| 15:15.57 | file | UNCLEAN UNCLEAN |
| 15:32.08 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-172.cust.bezeqint.net) |
| 15:32.08 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 15:44.28 | kpfleming | i propose that lunchers meet at 11:45 in the lobby and then we go somewhere to obtain lunch |
| 15:51.55 | file | somewhere tasty? |
| 15:52.30 | file | kpfleming, Taco Bell! |
| 16:25.37 | *** join/#asterisk-dev F2Knight (~F2Knight@c-50-139-85-237.hsd1.or.comcast.net) |
| 16:27.15 | gtjoseph | What was the purpose of the dial bridge used by stasis/control? It's at the root of the ari issue i've been chasing. |
| 16:27.36 | file | rmudgett can probably elaborate |
| 16:28.40 | rmudgett | The hidden dial bridge was to separate the created channels that haven't been "put into" an explicit bridge yet. |
| 16:29.20 | gtjoseph | ok, so why? |
| 16:29.34 | gtjoseph | why does it need to be put in a bridge at this tiome? |
| 16:29.46 | rmudgett | The hidden bridge was to handle frames from the dialed channel without having hideous threading issues. |
| 16:30.31 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-jxjlvztsahirowzw) |
| 16:30.31 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 16:30.42 | rmudgett | With the hidden bridge, the bridging system would always handle the dialed channel's received frames. |
| 16:30.48 | gtjoseph | hmmm. the issue is that nothing removes it from the bridge |
| 16:31.02 | rmudgett | Otherwise, there would be contention about which thread would handle those frames. |
| 16:31.12 | gtjoseph | should a HangupRequest automatically remote it? |
| 16:31.18 | gtjoseph | remove |
| 16:32.03 | rmudgett | Since stasis puts channels into bridges as departable, stasis must always manually depart/remove the channel from the bridging system. |
| 16:32.36 | gtjoseph | rats. |
| 16:34.39 | rmudgett | See my previous rants about stasis using departable channels. :D |
| 16:35.06 | gtjoseph | i'll pass, thanks :) |
| 16:37.05 | gtjoseph | if i manually remove it, should i do it before or after calling ast_softhangup? |
| 16:39.19 | rmudgett | That I cannot answer of the top of my head. |
| 16:39.45 | rmudgett | It doesn't really make a difference as far as the bridging system is concerned. |
| 16:40.00 | gtjoseph | i was just hinking about event ordering |
| 16:40.17 | gtjoseph | i'll try it both ways and see |
| 16:41.56 | mjordan | I always find it interesting that something that levied requirements against a framework during its inception is somehow to blame for that framework not bothering to really meet those requirements. |
| 16:42.42 | mjordan | lunches |
| 17:00.27 | gtjoseph | rmudgett: assuming a dialed channel has answered, when *should* a channel be removed from the dial bridge? only when it's been put into another bridge? |
| 17:20.02 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d002cd646f4949d6a1c.ipv6.abo.wanadoo.fr) |
| 17:36.55 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 17:54.06 | *** join/#asterisk-dev F2Knight_ (~F2Knight@c-50-139-85-237.hsd1.or.comcast.net) |
| 18:08.04 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-mmrefyvufvvblunn) |
| 18:08.04 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 18:08.17 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-32-14.wall.uls.co.za) |
| 18:09.32 | rmudgett | gtjoseph: The stasis application is controlling the channel so it should be putting it where it wants it. |
| 18:11.39 | *** join/#asterisk-dev Navion (~Navion@rivendell/users/navion) |
| 18:11.39 | rmudgett | With stasis applications, there shouldn't be much automatically done with a channel. |
| 18:12.50 | rmudgett | With a channel hanging up the only thing that it can do in a stasis application is go away so that could be automatically done. |
| 18:24.20 | *** join/#asterisk-dev klow (~textual@c-98-247-49-57.hsd1.wa.comcast.net) |
| 18:52.27 | gtjoseph | rmudgett: the problerm is that a stasis app has no idea about the dial bridge. |
| 18:52.50 | gtjoseph | we put it in the bridge but only take it out if we put it in anothe rbridge |
| 18:53.04 | gtjoseph | but what if the app never puts it in another bridge? |
| 18:53.44 | rmudgett | As far as the user's stasis app is concerned it is not in a bridge. That is why that bridge is hidden. |
| 18:53.59 | gtjoseph | my point exactly |
| 18:54.08 | gtjoseph | how should it come out of the dial bridge? |
| 18:54.22 | rmudgett | If the channel is hung up then it needs to go away. That is about the only automatic thing a channel in a stasis application can do. |
| 18:54.47 | rmudgett | The stasis application does know about the channel since it created it. |
| 18:55.32 | gtjoseph | so then it's ast_ari_channels_hangup that should remove it if it's still in the dial bridge |
| 18:56.29 | gtjoseph | back to my earlier question though. once the channel has been answered, does the dial bridge do anything? |
| 18:56.47 | rmudgett | The hidden bridge is an implementation detail. The user's stasis application does know about the channel and it is under the control of that application. |
| 18:56.59 | gtjoseph | yes, i nkow that |
| 18:57.03 | rmudgett | If that application never DELETE's it then that is the application's fault. |
| 18:57.43 | rmudgett | The application is supposed to be getting events about the dial status if the application has told it to dial. |
| 18:57.53 | gtjoseph | yes i get that part. i'm now trying to understand why channels created with ast_ari_channels_originate_with_id don't use the dial bridge |
| 18:58.19 | gtjoseph | ultimately i'm trying to figure out where to put the dial bridge cleanup. |
| 18:58.39 | rmudgett | The hidden dial bridge? |
| 18:58.46 | gtjoseph | correct |
| 19:00.40 | rmudgett | Ok. ast_ari_channels_originate_with_id() predates the new dialing stuff so it does a normal originate. When the originated channel answers then it gives it to the stasis application. |
| 19:01.08 | gtjoseph | ok, so it's just dev timing that it doesn't use the dial bridge? |
| 19:01.33 | rmudgett | Dev timing? |
| 19:01.38 | gtjoseph | development |
| 19:01.45 | gtjoseph | we just didn't get arouind to it. |
| 19:02.20 | rmudgett | No. It uses the old method where the dialing was handled under the hood. |
| 19:02.35 | rmudgett | For backwards compatibility. |
| 19:02.37 | gtjoseph | well, both paths ultimaterly call ast_call. |
| 19:03.09 | gtjoseph | anyway, when has the hidden dial bridge outlived it usefulness? |
| 19:03.59 | rmudgett | The hidden dial bridge is permanent. All channels that are dialed using the new method get stuck there since there is only one. |
| 19:04.14 | gtjoseph | let me rephrase.... |
| 19:04.24 | gtjoseph | when does a channel have no need for the dial bridge? |
| 19:04.50 | gtjoseph | er, no longer have a need for |
| 19:04.56 | rmudgett | Only if it is hung up. |
| 19:05.20 | gtjoseph | or placed in another bridge? |
| 19:05.36 | rmudgett | A created channel that is dialed is stuck there. It is up to the stasis app to do something with it. |
| 19:06.05 | gtjoseph | stuck where??? it doesn't even know about the dial bridge |
| 19:06.13 | gtjoseph | it can't do anything with it |
| 19:06.29 | rmudgett | Restate: A created channel is put there until the stasis app does something with it. |
| 19:06.58 | gtjoseph | that didn't help. :) |
| 19:07.00 | rmudgett | The stasis app is not supposed to know about the hidden bridge. That's why it is hidden. |
| 19:07.08 | gtjoseph | I KNOW!!!!!! |
| 19:07.32 | gtjoseph | so what actions can the app take on a channel that cause it to be removed from the dial bridge. |
| 19:07.43 | mjordan | feels like he's reading who's on first |
| 19:07.58 | rmudgett | Putting the channel into a bridge. |
| 19:08.07 | rmudgett | Destroying the channel |
| 19:08.19 | rmudgett | Dialing the channel. |
| 19:08.26 | mjordan | rmudgett: did you guys test other operations on a channel? That is, is it legal to say call /record on a channel while it is in the dial bridge? |
| 19:08.29 | gtjoseph | destroying the channel currently doesn't remove it from the dial bridge. |
| 19:08.36 | rmudgett | Strike dialing as it will stay in the hidden bridge. |
| 19:08.45 | gtjoseph | that's the issue i'm trying to solve. |
| 19:08.56 | mjordan | gtjoseph: That's what I guessed :-) |
| 19:09.04 | rmudgett | mjordan: It was implemented by mark |
| 19:09.06 | mjordan | I vaguely recall asking putnopvut about that a few months ago |
| 19:09.20 | mjordan | and, IIRC, the answer was "I'm not sure" |
| 19:09.22 | file | mjordan, an additional change went in to stop silly operations on such channels prior |
| 19:09.27 | mjordan | file: ah, gotchya |
| 19:09.43 | mjordan | might have been done after that conversation, as it was quite a bit ago. |
| 19:09.44 | gtjoseph | mjordan: it's those tests that exposed that we're not removing the channeld from the dial bridge on destroy. |
| 19:09.49 | mjordan | ah ha |
| 19:09.51 | mjordan | so yay testing |
| 19:09.57 | gtjoseph | exactly |
| 19:10.03 | mjordan | does a /release operation work? |
| 19:10.19 | mjordan | or is that illegal to do as well? |
| 19:10.33 | gtjoseph | aint no release that i can see. |
| 19:10.46 | rmudgett | <PROTECTED> |
| 19:10.49 | rmudgett | ? |
| 19:11.20 | rmudgett | Yes a /continue is illegal. It makes no sense to put an undialed or dialed channel into dialplan. |
| 19:11.24 | mjordan | sure, continue |
| 19:11.48 | mjordan | rmudgett: sense doesn't really matter, what matters is if there is a predictable outcome :-) |
| 19:11.58 | mjordan | if that predictable outcome is a 409, that's just fine |
| 19:12.01 | mjordan | or 403, or whatever |
| 19:12.18 | file | and to further answer why the old originate was not updated - not doing so also reduced the chance of regressions in that area and minimized change |
| 19:13.04 | gtjoseph | got another question about ast_bridge_set_after_callback... |
| 19:13.17 | seanbright | gtjoseph: IT'S A HIDDEN BRIDGE GOD DAMINT |
| 19:13.28 | seanbright | sorry... i'm fine now |
| 19:13.30 | gtjoseph | go away you :) |
| 19:13.32 | rmudgett | The subsequent patch makes those silly to do actions like continue/record/playback return a 4xx code. |
| 19:14.00 | gtjoseph | if anyone wants top follow along i'm in res/stasis/control.c add_to_dial_bridge |
| 19:14.47 | gtjoseph | the scenario is that the app created a local channel, then dials it. the extension answers does a 3 second playback and hangs up. |
| 19:14.54 | rmudgett | Who wants to follow. It seems like we've gone round in circles. :) |
| 19:15.10 | gtjoseph | in this case it's the failure callback that get's called. |
| 19:15.46 | gtjoseph | not sure why it's not the normal callback |
| 19:27.21 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-32-14.wall.uls.co.za) |
| 19:29.10 | gtjoseph | i almost hate asking this but... rmudgett: if a stasis app explicitly puts a channel in a bridge and the channel is subsequently hung up by the dialplan, the channel is automatically removed from the bridge. is this a bug or feature? |
| 19:35.24 | rmudgett | Outside of stasis things are automatic because they need to be. Inside of stasis there shouldn't be much that is automatic. The stasis app is in control. About the only thing that could be automatic is if the channel hangs up. It should go away. |
| 19:36.40 | gtjoseph | hmmm. then i'm not understanding why the channel is not being removed from the dial bridge automatically then. the channel generates a HangupRequest with cause 16.get a Hanup |
| 19:37.27 | gtjoseph | i nwonder if it's because we null out control->bridge. |
| 21:41.19 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-172.cust.bezeqint.net) |
| 21:41.19 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:51.25 | *** join/#asterisk-dev klow (~textual@96.81.150.137) |
| 23:03.21 | *** join/#asterisk-dev klow (~textual@96.81.150.137) |
| 23:15.57 | *** join/#asterisk-dev snuff-work (~blatus@203.87.61.22) |
| 23:15.57 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:18.33 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-gmdyzifvkzpodqkn) |
| 23:18.34 | *** join/#asterisk-dev klow (~textual@96.81.150.137) |
| 23:45.52 | *** join/#asterisk-dev klow (~textual@96.81.150.137) |