| 00:39.36 | *** join/#asterisk-dev serafie (~erin@172.56.3.108) |
| 01:09.59 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:43e:3501:2677:3ff:fe8f:2730) |
| 02:04.46 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:105:69a2:816b:f941) |
| 02:12.15 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:43e:3501:2677:3ff:fe8f:2730) |
| 02:21.15 | *** join/#asterisk-dev serafie (~erin@172.56.3.108) |
| 03:41.30 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 04:21.13 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 05:37.38 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 05:37.38 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 06:07.03 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:a9a3:77cc:8b00:13a6) |
| 06:16.13 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 06:16.13 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:54.14 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 07:54.15 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:41.09 | oej | Morning folks! |
| 08:58.53 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:58.53 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:58.20 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 11:06.45 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:714c:20f1:5f9c:28b3) |
| 11:27.08 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 11:36.51 | *** join/#asterisk-dev vlad_starkov (~vlad_star@194.67.31.130) |
| 12:40.37 | jsmith | Greetings and salutations, all |
| 13:18.57 | seanbright | morning |
| 13:34.46 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:34.46 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:47.11 | *** join/#asterisk-dev mjordan (~matt@nat/digium/x-hrczolxxgckgjcry) |
| 13:47.11 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:48.27 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-bipqsuzxezboajgh) |
| 14:11.25 | mjordan | opticron: r3398 |
| 14:12.00 | mjordan | opticron: I'm a bit confused - in that test, the ARI application creates the bridge |
| 14:12.12 | mjordan | opticron: shouldn't it expect to receive the bridge destroyed events as a result? |
| 14:15.42 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:43e:3501:2677:3ff:fe8f:2730) |
| 14:17.52 | opticron | mjordan, when you create a bridge, it's not automatically associated with an application (unless something changed that I'm unaware of) |
| 14:17.59 | mjordan | that's wrong |
| 14:18.21 | mjordan | if an application creates a bridge, why would the application not immediately be subscribed to it? Making that a two-step process seems silly |
| 14:19.50 | opticron | it does, but I don't see how a subscription would be automatically created via the POST that creates the bridge since there is no way of associating that POST with the application sending it unless there is an additional parameter to specify the application name |
| 14:20.34 | opticron | which is probably the direction this needs to go |
| 14:20.54 | mjordan | yeah. This is kinda ugly. |
| 14:21.20 | mjordan | It feels like we're making the simple case here hard |
| 14:25.33 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-jftikzrbbfaudvbh) |
| 14:28.10 | opticron | ok, so I'll discard the review in lieu of an issue to fix this problem correctly |
| 14:30.19 | mjordan | opticron: go ahead and e-mail the -dev list before you discard it. |
| 14:30.42 | mjordan | opticron: there's basically an open question here: do we tie an ARI HTTP request with a websocket connection? |
| 14:31.15 | mjordan | if the answer is no, then there's not much to do, and the changes in the test are correct. |
| 14:32.10 | mjordan | for some reason, I thought that the act of authenticating would tie your token to an application. But that doesn't look to be right. |
| 14:35.27 | file | yeah... what we keep running into is "create a resource and subscribe application to it" |
| 14:35.50 | mjordan | I think my comment on the review is wrong in the sense that it is working as designed; I just don't like the design :-P |
| 14:36.32 | mjordan | and we probably should do *something* about it. That could be the authentication token that you're handed back is tied to applications; it could be that a POST that creates something has an option field that automagically subscribes it to applications you specify |
| 14:36.48 | mjordan | really, since we create a subscription for a channel in a Stasis application, this affects bridges the most |
| 14:43.26 | file | mjordan, it would be nice to have it magically do it but I don't think it's viable... even using the credentials to tie it back doesn't work because you may have multiple apps |
| 14:44.23 | mjordan | file: probably can't do it on login. You could tell a POST to subscribe it to multiple applications by providing those applications in the POST |
| 14:44.36 | file | yes |
| 14:44.53 | mjordan | you need to have the subscription created on creation, in case something else sneaks in and changes the state |
| 14:45.09 | mjordan | granted, unlikely unless you have multiple ARI sessions going, and *somehow* they know of the bridge and push a channel into it |
| 14:45.11 | file | yes, same thing I originally had for channel origination |
| 14:45.59 | file | I'm down with that |
| 15:03.35 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 15:03.35 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 15:07.39 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 15:08.26 | *** join/#asterisk-dev otherwiseguy (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 15:09.05 | *** join/#asterisk-dev vlad_starkov (~vlad_star@212.34.52.66) |
| 15:18.20 | mjordan | interesting. fulldisclosure went dark: http://seclists.org/fulldisclosure/2014/Mar/332 |
| 15:18.58 | file | oh, yeah, I forgot you would have only just gotten to that |
| 15:19.02 | jsmith | mjordan: Yup... it did |
| 15:20.00 | mjordan | jsmith: did you see http://nmap.org/mailman/listinfo/fulldisclosure? |
| 15:20.32 | mjordan | er, ignore that ? |
| 15:20.44 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 15:20.44 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 15:31.20 | *** join/#asterisk-dev vlad_starkov (~vlad_star@212.34.52.66) |
| 15:55.03 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 15:55.38 | *** join/#asterisk-dev newtonr (~newtonr@173-17-135-67.client.mchsi.com) |
| 15:55.38 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 16:24.07 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 16:25.40 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 16:25.40 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:57.45 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 16:57.45 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:06.47 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:2876:3269:1e31:eed3) |
| 17:10.55 | pabelanger | Does the plumbing exist in asterisk to open a connection to a specific IP / rtp port for the purpose of consuming audio? |
| 17:11.01 | pabelanger | minus the SIP part |
| 17:11.53 | sgriepentrog | pabelanger: you can look at it this way: sip and mgcp share the same rtp protocol (both wrap sdp) |
| 17:13.59 | pabelanger | sgriepentrog, I was thinking more along the lines of the new RTP engine in asterisk. Being able to pass in the IP and port to open via a dialplan app or something |
| 17:14.17 | pabelanger | I suspect a new rtp engine module would need to be written |
| 17:14.30 | file | erm, no |
| 17:14.33 | mjordan | There isn't a new RTP engine |
| 17:14.42 | mjordan | new RTP implementation, but no, you wouldn't need that |
| 17:15.00 | pabelanger | maybe I am confusing this |
| 17:15.06 | skrusty | how incomplete is the asterisk wiki for AMI? Has PeerStatus event been dropped or is it just ommited from the asterisk wiki? |
| 17:15.10 | mjordan | pabelanger: what instructs Asterisk to listen on an RTP port and do something with it? |
| 17:15.23 | mjordan | skrusty: it is complete for 12. Pretty much complete for 11. |
| 17:15.58 | skrusty | ok - i see it under 12 |
| 17:16.19 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 17:16.39 | pabelanger | mjordan, I would do it pragmatically some how. For example, exten => s,1,OpenRTP(1.1.1.1:1234) |
| 17:16.42 | mjordan | skrusty: not all events were documented for Asterisk 11. A call for documentation help was issued, but ... yeah. |
| 17:16.58 | mjordan | pabelanger: okay, so now how do you close it? |
| 17:17.00 | skrusty | yeah :) |
| 17:17.13 | pabelanger | my use case is using something like FFmpeg to stream audio over RTP |
| 17:17.37 | pabelanger | mjordan, again, pragmatically. another dialplan function, or on channel hangup |
| 17:17.44 | mjordan | pabelanger: you're trying to create a channel driver without a channel driver |
| 17:17.49 | pabelanger | right |
| 17:18.27 | pabelanger | Like before, trying to come up with the best way to get audio into asterisk from an external source |
| 17:18.29 | mjordan | pabelanger: it's doable. But the RTP engine is going to require you to do some gyrations, since things in Asterisk are generally channel based. For example, it is perfectly valid for something to send your "stream" RTP |
| 17:18.36 | pabelanger | without using SIP |
| 17:18.51 | mjordan | pabelanger: if you're trying to stream audio into Asterisk, you need a channel. |
| 17:19.18 | pabelanger | So, I guess it is a local channel for now |
| 17:19.24 | mjordan | pabelanger: there's no way around that. A channel is the media path from Asterisk to something else. Dialplan aside, that's it's purpose. Trying to circumvent that is going to hurt. |
| 17:19.43 | sgriepentrog | what about hold music - that's an example of audio stream that isn't channel based? |
| 17:19.46 | mjordan | keeping in mind, nothing you've shown has indicated that is a source of any performance limitatrion |
| 17:19.57 | mjordan | sgriepentrog: that is a media source that is internal to Asterisk |
| 17:20.17 | sgriepentrog | right. And even the streaming version requires asterisk to initiate the connection. |
| 17:20.18 | mjordan | which also is piggy backed onto a channel |
| 17:20.22 | sgriepentrog | oh |
| 17:20.32 | mjordan | that is, you can't start MoH on ... nothing |
| 17:20.36 | mjordan | you still need a channel |
| 17:20.40 | mjordan | Local, SIP, IAX, whatever |
| 17:20.41 | sgriepentrog | right. |
| 17:20.53 | pabelanger | I wonder if I could just wrap ffplay, like we do with app_mpg123 |
| 17:21.01 | mjordan | at which point, if your goal is to have RTP coming from an external source, it has to be put onto some sort of channel for it to be consumed by anything else |
| 17:21.04 | pabelanger | as the long way around the POC |
| 17:21.18 | mjordan | but you still have a channel... so how is this buying you anything? |
| 17:21.39 | pabelanger | not sure what you mean |
| 17:21.49 | mjordan | SIP is just signaling. Once it is set up, it's effectively not doing anything. All you're doing is creating another way of setting up the stream. |
| 17:22.09 | mjordan | say you call a dialplan application to create an RTP stream with something. Okay, what channel is going to service those frames? |
| 17:22.19 | pabelanger | local for now |
| 17:22.20 | sgriepentrog | really sounds like sip is the easiest way of getting an audio stream into asterisk - worst case you have to add a codec for your format. |
| 17:22.29 | pabelanger | I'd be dumping it into a bridge |
| 17:22.29 | mjordan | k, so how is this any different than a SIP channel? |
| 17:22.38 | pabelanger | my device does not support SIP |
| 17:22.46 | mjordan | so write a channel driver that talks to it |
| 17:22.49 | pabelanger | my media server is just, a media player |
| 17:22.58 | mjordan | that would be the "correct" way |
| 17:23.57 | pabelanger | but said channel driver would just be a wrapper to local channel, right? If I wanted to do chan_ffmpeg (streaming RTP)? |
| 17:24.07 | pabelanger | or am I missing what you are saying |
| 17:24.10 | mjordan | your channel driver can be whatever you want |
| 17:24.50 | mjordan | to be frank, implement it how you feel like. At the end of the day, you need something that creates an instance of the RTP engine (specifying an implementation), and it needs to read/write frames to/from it |
| 17:24.58 | mjordan | if you want to do that in something other than a channel driver, go for it |
| 17:26.52 | pabelanger | okay, so I'm going to look at chan_bridge_media.c and see what it is doing. |
| 17:28.42 | file | it does virtually nothing, the core code is in core_unreal.c which is what Local ends up using |
| 17:29.39 | file | which pretty much creates a virtual channel conduit between two points |
| 17:31.18 | pabelanger | infact, I think I just need the reverse of what chan_multicast_rtp does. Instead of transmitting audio, I want to listen for it, the redirect it some place |
| 17:31.32 | pabelanger | okay, thanks for answering my questions |
| 17:32.54 | file | notes chan_multicast_rtp is a channel driver |
| 17:35.06 | putnopvut | I've spent the morning looking into the PJSIP qualify test failure. The failure occurs because when Asterisk shuts down, the sorcery cleanup function kills the wizards container. After that, a scheduled qualify operation happens, which calls ast_sorcery_retrieve_by_id(), which attempts to access a freed wizard. |
| 17:35.35 | putnopvut | Fixing this is a bit of a problem, because the PJSIP qualify code is part of res_pjsip.so, which cannot be unloaded currently. So we can't unschedule qualifies on module unload. |
| 17:36.16 | putnopvut | SImilarly, registering a cleanup handler from within res_pjsip/pjsip_options.c wouldn't help because its cleanup handler would run after sorcery's, meaning there would still be a gap where scheduled qualifies could run and crash. |
| 17:36.54 | putnopvut | So I'm curious if there are any good suggestions on how to ensure that the PJSIP qualify code can unschedule qualifies before sorcery cleans itself up. |
| 17:37.20 | file | putnopvut, shouldn't the instance have a ref to the wizard so it should still be valid? |
| 17:37.27 | mjordan | suggestion #1: sorcery should probably be tolerant to having a request come in after the wizard is gone |
| 17:37.38 | mjordan | suggestion #2: I don't have one. res_pjsip needs to be unloadable. |
| 17:39.24 | putnopvut | file: the sorcery instance has a ref to an ast_sorcery_object_wizard, which is still valid. However the ast_sorcery_object_wizard apparently does not have a reference to the ast_sorcery_wizard, because that shizzle's gone. |
| 17:39.45 | file | it should |
| 17:41.07 | putnopvut | In sorcery_apply_wizard_mapping, it appears that the object_wizard does not get a ref to the wizard. The line is just "object_wizard->wizard = wizard". The wizard's module is reffed, but the wizard itself is not. |
| 17:41.52 | putnopvut | I'll mess with that and see if that fixes things up. |
| 17:58.45 | putnopvut | Yep, giving the object_wizard a reference to the wizard, as suspected, caused me to be able to run the test 120 times in a row with no failures/crashes. |
| 18:04.00 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 18:04.00 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:15.44 | *** join/#asterisk-dev danjenkins_ (~dan@80.4.22.208) |
| 18:16.37 | seanbright | mjordan: given digium's position on opus, is a format_opus.c out of the question for asterisk? |
| 18:16.54 | seanbright | similar to format_g729.c |
| 18:17.18 | mjordan | seanbright: nope, that'd be fine. No transcoding there. |
| 18:17.25 | seanbright | alrighty |
| 18:24.48 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 18:50.18 | *** join/#asterisk-dev devlap (~DevWork@74.10.31.134) |
| 18:54.21 | *** join/#asterisk-dev chazzam (~chazz@donutokyo.info) |
| 19:28.12 | seanbright | and of course .opus files are stored in ogg containers |
| 19:28.19 | seanbright | ugh. |
| 19:28.42 | file | I think I knew that |
| 20:04.20 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 20:27.40 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 20:28.03 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 20:41.34 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 20:41.34 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:47.33 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 20:50.07 | *** join/#asterisk-dev roxlu (~roxlu@69-21.ftth.alicecomfortplus.nl) |
| 20:56.42 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 20:56.42 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 21:02.38 | *** join/#asterisk-dev dwayne (~dwayne@c-71-207-208-112.hsd1.al.comcast.net) |
| 21:05.08 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:07.32 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 21:16.16 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:43e:3501:2677:3ff:fe8f:2730) |
| 21:20.07 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 22:20.37 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 22:29.14 | *** join/#asterisk-dev Narkov2 (7346a934@gateway/web/freenode/ip.115.70.169.52) |
| 22:30.39 | Narkov2 | Has anyone got time to look at ASTERISK-23484? I think I've got a solution however I don't know the codebase well enough to implement the fix. |
| 22:34.46 | *** join/#asterisk-dev snuff-work (~snuffy@203.63.71.233) |
| 22:34.46 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 22:35.15 | Narkov2 | The HANGUPCAUSE variable is being set in chan_sip.c handle_response (line 23760) but then it is getting overwritten at handle_response_invite (line 23040) |
| 22:42.33 | mjordan | Narkov2: if you don't hit "Send Back", it usually doesn't show back up on bug marshal's queues |
| 22:43.53 | Narkov2 | Oh!! |
| 22:44.12 | mjordan | Narkov2: keep in mind in your example there, you've got a Local channel that is actually in the 'h' extension |
| 22:44.14 | Narkov2 | I thought my reply would trigger that. Thanks for the heads up. |
| 22:44.41 | Narkov2 | mjordan: I've removed the Local channel in my later tests. This is just SIP<->SIP and the same issue occures. |
| 22:44.44 | WIMPy | HANGUPCAUSE seems to be random in the h extension. |
| 22:45.19 | WIMPy | In my tests I sometimes got what I see in the extension after the Dial() and sometimes 16. |
| 22:45.59 | mjordan | Narkov2: fair enough. The answer to your question though is "no, no one has looked at it deeply yet" |
| 22:46.37 | Narkov2 | mjordan: Thanks. I didn't want to sound pushy but having not done the "send back", I now know why :) |
| 22:46.48 | *** part/#asterisk-dev mjordan (~matt@nat/digium/x-hrczolxxgckgjcry) |
| 22:46.59 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 22:47.53 | file | oh, it's late |
| 23:12.16 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 23:13.41 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 23:22.15 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-jftikzrbbfaudvbh) |