| 15:17.46 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 15:17.46 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk |
| 15:19.02 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:27.15 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-lfwjtxxtaqneohxd) |
| 16:42.14 | file | my chan_pjsip connected line review is rather small, if anyone is interested |
| 17:44.13 | mjordan | leedm777: ping |
| 17:44.21 | leedm777 | mjordan: pong |
| 17:45.09 | mjordan | so, in RTCP land, a single RTCP SR/RR report can contain n number of report blocks. Asterisk historically has always only really sent and/or reported on a single report block in an RTCP packet. That isn't changing. |
| 17:45.31 | mjordan | However, I'm at least trying to account for a future where we would want to report multiple report blocks within a single SR/RRR packet |
| 17:45.35 | mjordan | RR, not RRR |
| 17:45.49 | mjordan | that would really mean that for a single report, we would want to generate multiple AMI events |
| 17:45.55 | mjordan | one for each report block. |
| 17:46.32 | mjordan | Ideally, the to_ami function would return a list of ast_manager_event_blob objects to be raised as result of the 'to_ami' portion. |
| 17:46.53 | leedm777 | hm |
| 17:47.05 | mjordan | I don't really want to make that change. However, can we think of any other situation where you would want a single Stasis-Core message to produce multiple AMI/JSON messages? |
| 17:47.34 | mjordan | it isn't really a problem today since we won't actually handle multiple reports, but if that feature was ever added, the to_* functions would be 'off'. |
| 17:48.10 | mjordan | And really, this is an AMI problem only. The JSON blob already structures the reports, so it handles the situation fine. |
| 17:48.24 | leedm777 | I don't even know if I would change the to_* function. I would make ast_manager_event_blob linked listable. |
| 17:48.45 | mjordan | leedm777: agreed |
| 17:48.48 | leedm777 | So that the typical case of a 1:1 mapping is not cumbersome. |
| 17:49.10 | mjordan | yeah. I don't think I'm going to make the change because this feels very odd, and we've existed for 10+ years only reporting on a single SR/RR without a lot of fuss |
| 17:49.42 | mjordan | I can't think of anything else that might need that, but I could be mistaken |
| 17:49.47 | leedm777 | If we ever enter a strange world where the AMI response events need to go through stasis, then it might come up again. |
| 17:49.53 | leedm777 | But I have no idea why we would ever do that. |
| 17:50.44 | mjordan | well... |
| 17:50.53 | leedm777 | But if we needed it, it would be a backward compatible change to ast_manager_event_blob, so I have zero worries about it. |
| 17:51.03 | mjordan | sounds good to me. |
| 17:51.25 | mjordan | I was thinking that you would need the responses ordered wrt the other events, but technically a response event chain occurs due to an action executed, not due to an internal change in Asterisk |
| 17:51.34 | mjordan | if we have a response event chain that occurs unsolicited, then we might want that. |
| 18:14.50 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 18:14.51 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 18:28.34 | mjordan | jrose_atDigium: so, throwing a channel snapshot in a datastore for later retrieval sounds like the only plausible way to get at the transferer when Park isn't the first extension in the dialplan that the transfer target is being transferred to |
| 18:28.56 | jrose_atDigium | Yes. |
| 18:28.57 | mjordan | jrose_atDigium: however, that same concept may apply elsewhere - wherein you have to store information about a channel that affected you and you need to retrieve it, but that channel no longer exists |
| 18:29.16 | mjordan | so, the multi-channel-blob thing allows you to store channels in an ao2 container with 'roles' |
| 18:29.26 | mjordan | you might be able to either use that or do something similar to create a generic mechanism |
| 18:29.41 | jrose_atDigium | So we could throw a multichannel blob into a channel datastore and call it a day, yes. |
| 18:29.55 | jrose_atDigium | I can see that working without too horribly much effort. |
| 18:30.18 | mjordan | the benefit there is if we run into this again, we don't have to have multiple datastores for each use case |
| 18:30.45 | mjordan | so the second BUGBUG (or first) is to get MoH work with local channel swapping. What is happening with the local channels? |
| 18:31.18 | jrose_atDigium | I'm trying to remember what caused that... basically the idea is that a local channel would enter the parking bridge and then be swapped for a regular channel. |
| 18:31.21 | jrose_atDigium | I think... |
| 18:31.27 | jrose_atDigium | it might have been when you park a multichannel bridge |
| 18:31.37 | mjordan | right, but that shouldn't happen anymore. |
| 18:31.44 | mjordan | I think we decided that the Local channel stays in the parking slot |
| 18:31.49 | jrose_atDigium | then the multichannel bridge has a channel (or a bunch of them) leave |
| 18:31.56 | mjordan | ah. |
| 18:31.59 | jrose_atDigium | until there is only one channel left |
| 18:32.05 | mjordan | right, and an optimization occurs |
| 18:32.08 | jrose_atDigium | then merge madness |
| 18:32.16 | jrose_atDigium | or yeah |
| 18:32.18 | jrose_atDigium | optimization rather |
| 18:32.27 | jrose_atDigium | and the channel swaps for the local channel and then sadness. |
| 18:32.29 | mjordan | does this happen with a normal two-party bridge and an optimizing local channel? |
| 18:33.05 | jrose_atDigium | Well, that's what I'm not so sure of. I'm worried that there was a much more trivial way to have that happen. |
| 18:33.15 | mjordan | well, that would be the trivial way |
| 18:33.34 | jrose_atDigium | I'm going to say yes. |
| 18:33.38 | mjordan | so, when the local channel optimization occurs, you should get a push when the channel swaps out with the local, right? |
| 18:33.51 | jrose_atDigium | yep |
| 18:33.56 | mjordan | why isn't the MoH started on the push? |
| 18:34.01 | jrose_atDigium | It is now. |
| 18:34.10 | mjordan | so... how is this still a bug? ;-) |
| 18:34.37 | jrose_atDigium | The bug... is that it doesn't respect one of the arguments to the park extension. |
| 18:34.41 | jrose_atDigium | Namely the ringing option. |
| 18:35.03 | jrose_atDigium | So if the local channel is set to ring, when the roles are applied it will turn into music on hold. |
| 18:35.30 | jrose_atDigium | It's a very minor bug which is why I haven't bothered to fix it yet. |
| 18:36.52 | jrose_atDigium | I think it's just going to require doing a roles copy from the swapee to the swapper |
| 18:37.02 | jrose_atDigium | Except that might be overkill |
| 18:37.42 | jrose_atDigium | Speaking of which, I spelled 'roles' as 'roels' in that comment and that makes me a sad 'padna'. |
| 18:44.44 | mjordan | jrose_atDigium: gotchya. |
| 18:45.01 | mjordan | I'm fine if we apply the role however, as that would be a more 'permanent' way of making sure all logic is applied |
| 18:53.57 | file | opticron, haha |
| 18:54.10 | opticron | <_< |
| 18:54.10 | *** join/#asterisk-dev oej (~Adium@host-95-195-134-45.mobileonline.telia.com) |
| 18:54.10 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:54.11 | opticron | >_> |
| 18:54.18 | opticron | ducks |
| 19:00.20 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-nfrntjbqbtmbhepx) |
| 19:03.17 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-gmbrshlxllnogrmf) |
| 19:03.17 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 19:30.31 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-vkysljznjviewdmx) |
| 19:30.31 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 20:00.41 | file | gooses |
| 20:31.58 | Kobaz | so i'm adjusting app_voicemail to handle multiple extension delivery |
| 20:33.17 | Kobaz | it looks like someone started it but didn't finish |
| 20:33.22 | Kobaz | it's like half-written |
| 20:44.22 | JunK-Y | so half-a-beer for you! |
| 20:58.25 | *** join/#asterisk-dev alecdavis (~alecdavis@202.36.76.21) |
| 21:04.53 | alecdavis | iax friends: i'm looking for a shipit on review 2594. or at least feedback. |
| 21:12.18 | mjordan | alecdavis: would this be the transfer race condition? |
| 21:13.02 | mjordan | it would indeed |
| 21:13.58 | mjordan | alecdavis: I can take a look at it tonight, but it'd be good to get two pairs of eyes on it. seanbright might be a good person to ask as well |
| 21:25.32 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-vkysljznjviewdmx) |
| 21:43.34 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 22:35.14 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 22:39.36 | *** join/#asterisk-dev opticron (~opticron@pianoben.ch) |
| 22:39.36 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 23:25.22 | *** join/#asterisk-dev snuff-work (~snuffy@58.171.153.93) |
| 23:25.22 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:33.08 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 23:33.08 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |