| 00:21.55 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 00:39.12 | *** part/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 00:45.48 | *** join/#asterisk-dev suneye (suneye@119.122.31.189) |
| 00:56.30 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 01:22.36 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 01:39.44 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.185) |
| 01:56.43 | spditner | In a channel driver (that I'm writing from scratch), if I have a monitoring thread processing incoming control packets, how do I go about accessing pvt/channel records to do something like call ast_rtp_instance_activate()? |
| 01:57.29 | spditner | It seems to work if I call it inside a method invoked during channel creation, but not if I do it from the monitoring thread after I've found the right pvt & channel structures. |
| 01:59.26 | spditner | I'm a complete pthreads noob, and I'm not entirely clear on whether channel threads and a channel driver's monitoring thread would be sharing the same data. |
| 02:23.40 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 02:23.40 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 02:40.21 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.22) |
| 02:41.58 | pabelanger | SUCCESS! |
| 02:41.59 | pabelanger | http://pastebin.com/iLB9a2ij |
| 02:42.06 | pabelanger | first ARI application |
| 03:27.53 | *** join/#asterisk-dev Sjors (~sgielen@foo.kassala.de) |
| 03:33.42 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 03:33.42 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 03:40.56 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.238) |
| 04:41.33 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.12) |
| 04:47.33 | *** join/#asterisk-dev atcmmi (~atcmmi@116.7.103.132) |
| 04:55.22 | *** join/#asterisk-dev suneye (suneye@119.122.31.189) |
| 05:42.14 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.68) |
| 06:06.33 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.215) |
| 07:28.06 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.116) |
| 08:16.04 | *** join/#asterisk-dev danjenkins (~danjenkin@146.185.158.234) |
| 08:16.39 | *** part/#asterisk-dev danjenkins (~danjenkin@146.185.158.234) |
| 08:21.12 | *** join/#asterisk-dev danjenkins (~danjenkin@146.185.158.234) |
| 08:31.44 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.20) |
| 08:42.22 | *** join/#asterisk-dev danjenkins (~danjenkin@146.185.158.234) |
| 09:18.38 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.61.47) |
| 09:52.15 | *** join/#asterisk-dev suneye (~atcmmi@116.7.103.132) |
| 11:05.02 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.124) |
| 11:13.21 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.124) |
| 11:14.14 | *** join/#asterisk-dev otherwiseguy (~otherwise@38.121.226.130) |
| 11:15.41 | *** join/#asterisk-dev otherwiseguy (~otherwise@38.121.226.130) |
| 11:39.39 | *** join/#asterisk-dev danjenkins (~danjenkin@146.185.158.234) |
| 11:46.59 | *** join/#asterisk-dev danjenkins (~danjenkin@146.185.158.234) |
| 11:56.29 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 12:08.17 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 12:12.50 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.138) |
| 12:26.58 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.138) |
| 12:39.25 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:b8e3:8445:4c72:cd65) |
| 12:45.02 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 12:45.02 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 12:53.57 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 13:00.14 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.61.47) |
| 13:04.25 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-79-141.user.veloxzone.com.br) |
| 13:11.50 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.138) |
| 13:17.47 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-plfqgkvsyslxzdye) |
| 13:22.41 | danjenkins | Is my irc proxy working properly? |
| 13:25.49 | roderickm | danjenkins: I read you |
| 13:52.12 | danjenkins | roderickm: woohoo |
| 13:52.35 | danjenkins | it was eeerily quiet in here, thought I'd broken it! |
| 13:58.19 | *** join/#asterisk-dev dronacid (~dronacid@vpn.openroot.de) |
| 14:01.10 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-gdxuihybfprixtuy) |
| 14:05.14 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:05.14 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:08.24 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.122) |
| 14:11.16 | *** join/#asterisk-dev spditner (~simon@206-248-134-87.dsl.teksavvy.com) |
| 14:16.39 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-84-109-18-138.red.bezeqint.net) |
| 14:16.40 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 14:18.50 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-zcdfyxmvvfqpsxwd) |
| 14:18.50 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:36.31 | anonymouz666 | Hello guys. I have a question regarding a memory corruption. I have 4 asterisk instances running in the same server brand. Each instance crashes at least 1 time/day. The dumps are spreading all over the code but always with malloc() and other related memory functions. That happens ONLY in this server brand. Which way will be more recommended to workaround this? Change memory chips? Update |
| 14:36.31 | anonymouz666 | do Asterisk 11 (I think won't make any difference)? Change server brand? |
| 14:36.58 | anonymouz666 | It is running 1.8 right now. |
| 14:42.10 | opticron | have you run memory tests on those systems? |
| 14:43.17 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-bnhvwzbuqppjkasf) |
| 14:43.17 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:44.16 | opticron | alternatively, your setup may be exposing memory corruption in asterisk |
| 14:45.31 | mjordan | anonymouz666: also, minor version can be important. What exact version of 1.8 are you running? |
| 14:45.42 | anonymouz666 | 1.8.16 |
| 14:46.47 | anonymouz666 | opticron: I have this version running fine in lots of heavy loaded setups, these crashes happens only on those servers |
| 14:47.34 | anonymouz666 | that's odd |
| 14:48.39 | anonymouz666 | starting with version 1.8.20 memory debug was improved |
| 14:48.48 | anonymouz666 | wiki states that |
| 14:49.07 | mjordan | yup |
| 14:49.17 | mjordan | we solved a bunch of memory corruptions. You may want to try moving to the latest 1.8 |
| 14:49.31 | mjordan | (granted, they were in chan_agent for the most part) |
| 14:50.03 | anonymouz666 | I would jump directly to the latest 11. |
| 14:50.41 | anonymouz666 | I take the risk, very good feedback from the community |
| 14:51.29 | leifmadsen | leedm777: thanks again for ari.asterisk.org -- I just used it this morning on the base VM with Asterisk 12 I created while at astridevcon, and with a couple of modifications in my configuration files (ari.conf and http.conf) I got it connected! |
| 14:51.42 | leifmadsen | that saved me a bunch of time puttering with swagger |
| 15:33.43 | Kobaz | do de do |
| 15:33.44 | Kobaz | okay so |
| 15:34.06 | Kobaz | say i wanted to add an ast_verb to show when rtp starts flowing related to a specific peer |
| 15:34.11 | Kobaz | what would be a good place to add that |
| 15:35.04 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 15:35.04 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 15:40.11 | Kobaz | ! Structure that represents the glue that binds an RTP instance to a channel */ struct ast_rtp_glue { |
| 15:40.13 | Kobaz | okay found that |
| 15:44.44 | *** join/#asterisk-dev tensai (~tensai@174-126-39-53.cpe.cableone.net) |
| 15:46.05 | leifmadsen | Kobaz: you were not at astricon! |
| 15:46.13 | leifmadsen | I did not get my yearly fill of juggling |
| 15:46.14 | Kobaz | i know |
| 15:46.18 | mjordan | wow |
| 15:46.18 | Kobaz | my brother's wedding |
| 15:46.21 | mjordan | we could have had so much juggling |
| 15:46.25 | Kobaz | i know :( |
| 15:46.29 | Kobaz | next year for sure |
| 15:46.37 | Kobaz | no weddings planned |
| 15:46.40 | mjordan | Kobaz: there was actual juggling implements provided by Tzafrir in devcon |
| 15:46.46 | Kobaz | oh no |
| 15:46.47 | Kobaz | aw man |
| 15:46.53 | Kobaz | yeah i signed up for devcon and everything |
| 15:46.55 | pabelanger | wedding and astricon, pft |
| 15:46.56 | Kobaz | reserved the hotel |
| 15:47.04 | leifmadsen | do what paul did! |
| 15:47.10 | leifmadsen | go to astricon, show up 1 day before you get married |
| 15:47.16 | leifmadsen | he is kind of a big deal like that |
| 15:47.48 | mjordan | with a very understanding wife apparently :-) |
| 15:47.59 | Kobaz | i do torches now |
| 15:48.05 | mjordan | !!! |
| 15:48.13 | Kobaz | and i've been doing lots of fire spinning |
| 15:48.22 | mjordan | I've been trying to convince Jonathan to do flaming chainsaw |
| 15:48.24 | mjordan | chainsaws |
| 15:48.51 | Kobaz | you need a little chainsaw |
| 15:48.56 | Kobaz | special juggling chainsaws |
| 15:49.12 | Kobaz | my husqvarna 455 would *not* be fun to juggle |
| 15:49.51 | Kobaz | so, maybe write a verb() based on packet count? |
| 15:50.00 | Kobaz | if packet count = 0, then obviously your sending the first one |
| 15:50.16 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-tpesulebhgtitouq) |
| 15:56.42 | Kobaz | okay here goes |
| 15:59.57 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-wygceaetpgarcwmr) |
| 16:06.49 | Kobaz | <PROTECTED> |
| 16:06.51 | Kobaz | <PROTECTED> |
| 16:06.55 | Kobaz | why can't i do that? |
| 16:07.00 | Kobaz | res_rtp_asterisk.c:1133: error: dereferencing pointer to incomplete type |
| 16:07.10 | Kobaz | is my c that rusty? |
| 16:07.26 | mjordan | chan is opaque |
| 16:07.30 | Kobaz | not in 1.8 |
| 16:07.32 | mjordan | or rather, ast_channel is an opaque type |
| 16:07.38 | mjordan | ah |
| 16:07.44 | mjordan | than ast_rtp_instance is :-) |
| 16:07.51 | Kobaz | oooh |
| 16:07.57 | mjordan | but something clearly is on that line |
| 16:08.05 | Kobaz | yeah okay, it's instance than |
| 16:08.09 | Kobaz | i didn't look at the base struct |
| 16:08.21 | Kobaz | struct ast_channel *chan = ast_rtp_instance_get_chan(instance); |
| 16:08.23 | Kobaz | that works |
| 16:09.04 | Kobaz | adding a verb() for the start of an rtp flow |
| 16:09.15 | Kobaz | it should help me in finding where my audio delays are coming from |
| 16:09.43 | Kobaz | SIP/A calls SIP/B |
| 16:09.58 | Kobaz | SIP/B picks up and says "hello.... hello...? hellllooooooo?" |
| 16:10.09 | Kobaz | SIP/A hears the third "...eeelllo" |
| 16:11.10 | mjordan | Kobaz: is securertp on? |
| 16:11.15 | Kobaz | nope |
| 16:11.19 | mjordan | directmedia? |
| 16:11.34 | Kobaz | nope |
| 16:12.45 | Kobaz | and |
| 16:12.57 | Kobaz | this is all local lan... no nat, no funny business |
| 16:14.21 | sgriepentrog | loadavg on the machine? does wireshark show the delay in rtp startup between the call legs? |
| 16:15.08 | Kobaz | i wiresharked the sip and didn't notice anything unusual |
| 16:15.17 | Kobaz | i'll wireshark the rtp after i add the extra debugging |
| 16:15.24 | Kobaz | loadavg is pretty normal |
| 16:15.42 | Kobaz | <PROTECTED> |
| 16:15.49 | sgriepentrog | load is your problem |
| 16:15.55 | Kobaz | it's a quad core |
| 16:16.33 | sgriepentrog | run (install if needed) nmon and use the v option to show if your load is cpu or disk related |
| 16:16.57 | sgriepentrog | my bet is it's disk throughput causing asterisk processing lags. |
| 16:17.14 | Kobaz | very few parts of asterisk write to disk in my setup |
| 16:17.16 | sgriepentrog | If your load is more than 1 reguarly you need to resolv that. |
| 16:17.43 | Kobaz | sgriepentrog: a load of > 1 isn't necessarily bad |
| 16:18.16 | sgriepentrog | but is often directly related to lag in response on asterisk. As it, it works, but ... |
| 16:18.20 | Kobaz | i do suspect it's disk though, i'm watching top spike to 60% iowait |
| 16:18.51 | sgriepentrog | find your disk throughput culprit and your problem will disappear. |
| 16:19.04 | Kobaz | yeah |
| 16:19.06 | sgriepentrog | Or: add array, ssd, or combination thereof |
| 16:19.08 | Kobaz | sounds like it |
| 16:19.23 | opticron | <3 SSD |
| 16:19.27 | Kobaz | i thought i fixed all my io issues before, so that's not something i've been keeping an eye on |
| 16:19.31 | sgriepentrog | ran into that alot in my previous life - most commonly on vm's though |
| 16:19.55 | Kobaz | iowait is the death of everything |
| 16:20.30 | sgriepentrog | loadavg >1 is not a killer, but it's a clue that you need to look at what's bogging things down. 5 is actually pretty bad. 10 is game over |
| 16:20.38 | Kobaz | echo 1 > /proc/sys/vm/block_dump |
| 16:20.44 | Kobaz | sgriepentrog: no |
| 16:20.49 | Kobaz | sgriepentrog: you don't understand load average |
| 16:21.20 | Kobaz | http://www.linuxjournal.com/article/9001 |
| 16:22.06 | sgriepentrog | I do, and I know I'm spouting nonsense, but I also know that fixing what's causing loadavg fixes such problems in large asterisk installs. |
| 16:22.35 | Kobaz | it can |
| 16:22.38 | Kobaz | but |
| 16:22.44 | Kobaz | iowait is the big enemy |
| 16:22.47 | sgriepentrog | It's an issue with the realtime nature of asterisk. |
| 16:22.51 | Kobaz | your load average can be 0.5 |
| 16:22.59 | Kobaz | and if your iowait is 99% |
| 16:23.10 | Kobaz | well, then if all you're looking at is load average you'll never find anything |
| 16:24.25 | Kobaz | nmon looks cool but it's not detailed enough |
| 16:24.27 | Kobaz | i like my method |
| 16:24.30 | sgriepentrog | But: don't let me stop you from proving me wrong and finding the real cause is something else that we can actually code around. |
| 16:24.36 | sgriepentrog | exactly |
| 16:25.05 | Kobaz | echo 1 > /proc/sys/vm/block_dump; sleep 60; tail -n 20000 /var/log/syslog | egrep "READ|WRITE|dirtied" | grep -v kjournal | awk '{print $6}'| sort | uniq -c | sort -rn | head; echo 0 > /proc/sys/vm/block_dump |
| 16:25.08 | Kobaz | that'll find your ioload source |
| 16:25.53 | sgriepentrog | I like it because it give me a quick check and confirmation on cpu vs mem vs disk issues. There's lots of details on it, but that method is better for digging into specific causes. |
| 16:26.28 | sgriepentrog | Depends if you're in a position to just throw more x at the problem, or have the time to actually fix the cause. |
| 16:26.51 | Kobaz | so munin is throwing in lots of disk writes |
| 16:27.07 | Kobaz | i should put munin on a ramdisk |
| 16:27.59 | Kobaz | coding around this problem would involve adding more async io in asterisk |
| 16:28.26 | sgriepentrog | which is always a good thing ;-) |
| 16:28.26 | Kobaz | asterisk should never get disk io bound while processing audio |
| 16:28.51 | mjordan | theoretically, sure. But it also depends on what you're telling it to do. |
| 16:28.55 | sgriepentrog | I think chan_pjsip actually will fix that. |
| 16:29.00 | Kobaz | ie: peer-to-peer audio should never *ever* get interrupted because the disk is busy (that's my theory) |
| 16:29.14 | mjordan | Kobaz: that's impossible. |
| 16:29.17 | Kobaz | like Monitor() is a great example |
| 16:29.33 | Kobaz | Monitor()'s disk writing is directly in the audio bridging thread |
| 16:29.37 | mjordan | Kobaz: if you have 1000 threads all with data to be written to disk, and you *never* service them because you have 1000 threads processing RT audio, you'll run out of memory and crash |
| 16:29.38 | sgriepentrog | In theory good, but practice (at least my experience with even older 1.4 asterisk) different |
| 16:29.46 | mjordan | Kobaz: sure, which is why you should only use MixMonitor |
| 16:29.52 | Kobaz | yeah exactly |
| 16:30.03 | Kobaz | but there's other places in asterisk that can use an async io approach |
| 16:30.09 | mjordan | but even with MixMonitor - which pushes the data to another thread to be written to disk - at some point in time, you have to devote some CPU to write that to disk |
| 16:30.10 | Kobaz | just like Monitor->MixMonitor |
| 16:30.36 | mjordan | where else you are recording in a Bridge? |
| 16:30.41 | mjordan | are/you |
| 16:30.48 | Kobaz | mjordan: well, true.. with the 1000 threads situation, but if you're within your cpu load i'm assuming |
| 16:31.06 | Kobaz | when i record in a bridge (meetme) i have one recorder |
| 16:31.37 | mjordan | which is why MeetMe was replaced |
| 16:31.37 | Kobaz | but like if you have audio-bridging waiting on disk io, any blip of an issue with throughput speeds and bam, dropped frames |
| 16:33.40 | sgriepentrog | to be honest, if you have plenty of unused ram being used as cache, it takes fairly sustained throughput issues to cause dropped frames |
| 16:33.53 | Kobaz | sgriepentrog: depends what you're doing |
| 16:34.13 | Kobaz | like my example if you use Monitor (which you shouldn't).. you'll get dropped frames pretty easily |
| 16:34.36 | Kobaz | i have yet to narrow down specific other io bottlenecks in the asterisk code, but i know they are there |
| 16:36.15 | Kobaz | mjordan: so back to my original point and finer refining it... if you're not cpu/thread bound, you should never drop audio frames do to disk io |
| 16:36.37 | mjordan | yes. But we've done a lot of work between 1.8 and 11 to provide options to not to that |
| 16:36.46 | Kobaz | ah nice |
| 16:36.56 | mjordan | but you have to use the right facilities - so if you're still using Monitor or MeetMe, you're kind of running into that old technology |
| 16:37.03 | Kobaz | i haven't gotten into 11 quite yet, i ported my code over but i have lots of adjustments to do to make everything work right |
| 16:37.08 | Kobaz | yeah |
| 16:37.14 | mjordan | ConfBridge + MixMonitor should resolve your recording woes for bridged participants. If not, I'd be surprised where the bottlenecks still are. |
| 16:37.28 | Kobaz | well i use Meetme + MixMonitor on an idle channel |
| 16:37.52 | Kobaz | should probably move to confbridge, but i don't have any load issues related to that (at the moment) |
| 16:38.33 | Kobaz | this particular box that i'm having io load issues is mostly just bridging two party calls, maybe a meetme once a week |
| 16:39.34 | Kobaz | i should add iowait to my watcher system |
| 16:42.37 | Kobaz | what the hell |
| 16:42.44 | Kobaz | <PROTECTED> |
| 16:42.53 | Kobaz | md is doing crazy amounts of disk writes |
| 16:43.02 | Kobaz | but no processes are really writing anything |
| 16:43.07 | Kobaz | and it's not doing a resync |
| 16:43.43 | sgriepentrog | you're running mdadm? cat /proc/mdstat to see if it's rebuilding array? |
| 16:44.06 | Kobaz | yeah it's not.. i checked that yeap |
| 16:55.32 | Kobaz | mm |
| 16:55.49 | Kobaz | the only way that i found so far to get a filename from a block number is debugfs, which likes to run on unmounted filesystems |
| 17:00.00 | pabelanger | [Oct 18 12:59:24] ERROR[13083][C-00000003]: res_stasis_playback.c:295 play_on_channel: Unimplemented |
| 17:00.24 | pabelanger | guess /channel/:id/play is not implemented? |
| 17:01.02 | opticron | pabelanger, are you prefixing with sound:? |
| 17:01.47 | mjordan | pabelanger: it is implemented - was demo'd at AstriCon :-) |
| 17:02.23 | pabelanger | okay |
| 17:02.30 | pabelanger | I must not be using it correctly then |
| 17:02.38 | pabelanger | both channel and bridge return the error |
| 17:02.58 | file | what URI are you providing for the sound? |
| 17:03.10 | pabelanger | that's likely the issue |
| 17:03.18 | pabelanger | what is the format?] |
| 17:03.25 | file | as opticron said if you are using the built-in sounds then the URI is sound:<name> |
| 17:03.28 | file | example, sound:demo-congrats |
| 17:03.45 | pabelanger | Ah |
| 17:04.02 | pabelanger | I was doing like http://localhost:8088/ari/sounds/{id} |
| 17:09.54 | pabelanger | okay, works |
| 17:09.55 | pabelanger | cool |
| 17:11.36 | pabelanger | perhaps we use the file:// URI over just sound: to indicate a audio prompt to asterisk |
| 17:11.45 | pabelanger | going to see how to get that working |
| 17:11.46 | file | it's not a file, it's a sound |
| 17:12.04 | file | you can retrieve information about sounds - such as what ones are available, their description, the formats |
| 17:12.04 | mjordan | in fact, it has multiple files associated with it |
| 17:12.13 | file | indeed |
| 17:15.05 | pabelanger | okay, so guess we need to update documentation to reference URN not URI |
| 17:17.39 | pabelanger | when we do add external sound support, I would expect it to accept an URI right? http://google.com/sound.wav Would you also have to pass the format of the file too? |
| 17:17.44 | pabelanger | or is the .wav enought? |
| 17:18.20 | file | unknown |
| 17:18.31 | Kobaz | ah by default debugfs is read-only so you can use it on a mounted filesystem |
| 17:18.33 | Kobaz | it's just soooo slow |
| 17:18.37 | Kobaz | it has to like read the whole disk |
| 17:18.41 | pabelanger | http://www.twilio.com/docs/api/twiml/play' |
| 17:18.48 | pabelanger | Seems like a good way |
| 17:19.02 | pabelanger | if fact, I really like the MIME type concept |
| 17:21.18 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 17:27.21 | pabelanger | Ya, once remote URI come into play, I think the lang parameter is basically dead for playback |
| 17:27.49 | pabelanger | media=sound:en/demo-congrats might be all that is needed |
| 17:28.08 | mjordan | right now, language should default to whatever asterisk has as the default |
| 17:28.20 | mjordan | but yes, if you referencing a specific remote resource, language clearly has no impact. |
| 17:28.28 | mjordan | You're working outside the confines of the Asterisk managed sound resources |
| 17:28.42 | pabelanger | Yar |
| 17:28.48 | mjordan | so you'd almost certainly have to reference a specific file resource, which would also necessitate an extension |
| 17:29.15 | mjordan | but that's the difference between sound:foo and file://foo.wav or http://foo.wav - they're different things :-) |
| 17:37.07 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 17:37.07 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 17:43.32 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 17:48.32 | pabelanger | okay, so once a playback is create |
| 17:48.40 | pabelanger | I need to use /playback/:id to control it? |
| 17:52.52 | pabelanger | okay, looks so |
| 17:53.58 | mjordan | typ |
| 17:54.00 | mjordan | er |
| 17:54.01 | mjordan | yup |
| 17:54.12 | pabelanger | cool |
| 17:54.39 | pabelanger | now to try a bridge |
| 18:03.22 | pabelanger | well! |
| 18:03.24 | pabelanger | err |
| 18:03.25 | pabelanger | wee! |
| 18:03.50 | pabelanger | so, how do I control audio to be queued in a bridge? |
| 18:04.04 | pabelanger | looks like each command adds a new announcer to the bridge |
| 18:04.22 | pabelanger | vs channel/play queues them |
| 18:20.14 | pabelanger | okay cool, found ASTERISK-22677 know issue |
| 18:25.50 | pabelanger | okay, trying to wrap my brain around why you would have skipms and offsetms for /channel/:id/play |
| 18:26.05 | pabelanger | they seem to do the same thing |
| 18:26.37 | mjordan | putnopvut: file: since I'm the one pushing for that... |
| 18:26.38 | pabelanger | additionally, skipms appears to be to control the audio, but isn't that was /playback is for? |
| 18:26.55 | mjordan | where that == a NOTICE message or some other clearly visible indication when a REGISTER request fails |
| 18:27.29 | putnopvut | mjordan: what I don't understand is why you don't put something that just says "SIP request <method type> could not be matched to an endpoint" |
| 18:27.33 | mjordan | I'd say there is a slight difference between REGISTER requests and other requests. If you're someone setting up a phone, the first thing your phone is likely to do is send a REGISTER request |
| 18:27.38 | mjordan | putnopvut: I'd be fine with that |
| 18:27.41 | putnopvut | It can print for INVITE, REGISTER, SUBSCRIBE, etc. |
| 18:28.01 | mjordan | that'd be fine. My biggest concern is that we print *something* |
| 18:28.11 | putnopvut | I'm not against printing something. I'm just against REGISTER getting special treatment in the distrubutor code. |
| 18:28.24 | mjordan | right now, a misconfiguration of a phone is likely to print nothing at all to the CLI, and having to troll the security log for a fat fingered config is annoying |
| 18:28.27 | mjordan | putnopvut: works for me |
| 18:28.51 | leedm777 | pabelanger: skipms is how much it skips when you control forward or reverse. offsetms is how much to skip before playing. |
| 18:28.58 | mjordan | pabelanger: both of those settings are analogous to their options in ControlPlayback |
| 18:29.08 | mjordan | pabelanger: offsetms says where to start playback in the audio - that is, start at an offset |
| 18:29.21 | mjordan | pabelanger: skipms is the amount of time you want to skip when a user initiates a fast forward or reverse |
| 18:29.35 | mjordan | pabelanger: neither are a control mechanism; rather, they set up how the control mechanisms will affect the resource |
| 18:29.44 | mjordan | so they are required in the creation of the playback resource |
| 18:30.05 | mjordan | leedm777: heh, I had my IRC chat window locked and didn't see that you answered as well. Jinx |
| 18:30.27 | leedm777 | mjordan: more answers is better, right? |
| 18:30.32 | leedm777 | at least we agreed :-D |
| 18:30.33 | pabelanger | I must be missing it, how do you control the audio file with /channel/:id/play ? |
| 18:30.55 | mjordan | pabelanger: play returns back the id of the playback resource |
| 18:31.06 | mjordan | pabelanger: you control the media using the playback resource |
| 18:32.58 | pabelanger | Right, by why would anybody do /play?offsetms=1000&skipms=1000 vs /play?offsetms=2000 or /play?skipms=2000 |
| 18:33.07 | pabelanger | why 2 different parameters for the same thing? |
| 18:33.14 | leedm777 | pabelanger: they are not the same thing |
| 18:33.45 | leedm777 | pabelanger: let's say you have a 10 minute audio file. you want to start 3 minutes into it, but skip in 15 second increments |
| 18:34.03 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.166) |
| 18:34.15 | leedm777 | pabelanger: you would pass in ?skipms=15000&offsetms=180000 |
| 18:35.13 | pabelanger | okay, then what? |
| 18:35.51 | pabelanger | so, the audio will play at the 3mins mark and skip every 15 secs? |
| 18:36.00 | leedm777 | The skipms only comes into play when the playback/control?operation={forward,reverse} |
| 18:36.22 | leedm777 | It will play normally, but when there's a forward/reverse command, it will forward/reverse in 15 second increments |
| 18:36.39 | mjordan | pabelanger: it is the same as this - https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+Application_ControlPlayback |
| 18:36.53 | mjordan | skipms => skipms; offsetms => o option |
| 18:37.09 | leedm777 | <aside>ideally that would have been a parameter on the control, but there are implementation details which make it necessary to setup ahead of time</aside> |
| 18:37.49 | mjordan | The value of putting them on the control is relatively minor |
| 18:37.53 | zerohalo | was just typing about how it would be nice to have it on the forward/reverse option but was beaten to iy |
| 18:37.54 | mjordan | offsetms really couldn't have been |
| 18:37.58 | mjordan | skipms is... meh. |
| 18:38.14 | mjordan | zerohalo: there is a forward/reverse option, but they're on the playback control resource |
| 18:38.23 | pabelanger | leedm777, Ya, that's what I would think too. Moving skipms into /playback/control then you can modify it as you please |
| 18:38.27 | mjordan | zerohalo: the amount of duration that they skip is specified when the operation is started |
| 18:38.43 | mjordan | pabelanger: large implementation effort, relatively non-existent payoff. |
| 18:38.46 | jrose_atDigium | mmichelson+mjordan: Ok, so log on everything and not just register. Does that include responses in addition to requests and do I need to put what type of request we failed to match with in the log message? |
| 18:38.47 | zerohalo | right - but allowing us to select skipms on that actual f/r operation would be sweet |
| 18:38.55 | mjordan | shrugs |
| 18:39.14 | mjordan | jrose_atDigium: just do requests for now. |
| 18:39.25 | leedm777 | We can get much sweeter things for much less effort |
| 18:39.38 | leedm777 | But, maybe, someday... |
| 18:39.42 | pabelanger | zerohalo, Ya, that's the issue I see with setting it when the prompt is played. And a little confusing |
| 18:39.54 | pabelanger | for now, I'll skip it and deal with it later :D |
| 18:40.29 | zerohalo | well, it's not a departure from what I do now, but I was thinking of a recording playback - perhaps I want to add >> 5s >> 10 and >>30s buttons to the playback control |
| 18:40.40 | zerohalo | yeah - eventually |
| 18:40.59 | mjordan | pabelanger: zerohalo: if you guys are interested in doing that work, I can point you in the right direction |
| 18:41.12 | zerohalo | Happy to be pointed |
| 18:41.18 | pabelanger | mjordan, sure, I'll give it a try |
| 18:41.25 | mjordan | zerohalo: so, in file.c is where the actual media playback operation is controlled |
| 18:41.41 | mjordan | you'll see that there are some new control frames for manipulating the audio stream as it is played back on the channel |
| 18:41.51 | mjordan | AST_CONTROL_STREAM_REVERSE/AST_CONTROL_STREAM_FORWARD |
| 18:41.57 | mjordan | you'd need to do the following: |
| 18:42.12 | mjordan | have the skip duration stored somewhere on the control frame, and pulled off when that frame is handled in file.c |
| 18:42.36 | mjordan | right now, it "knows" the skip duration if it was passed in by the starting of the operation, and will default to 3000 ms if it doesn't have one |
| 18:42.48 | mjordan | but you could also store it on the control frame and use it there |
| 18:42.49 | mjordan | then |
| 18:43.15 | mjordan | in res_stasis_playback, you'd need to put the skipms duration on the control frame when you raise it |
| 18:43.26 | mjordan | i.e., in playback_reverse and playback_forward |
| 18:43.37 | mjordan | that may take some modifications in stasis_app_control_queue_control |
| 18:43.52 | mjordan | or else, you'll need to create the full frame before queuing it, so you probably won't be able to just "use" stasis_app_control_queue_control |
| 18:44.03 | mjordan | that's the guts of the work at any rate, minus the resource model changes |
| 18:45.49 | zerohalo | right - okay... hrm.. maybe I can add barry white/chipmunk playback speed there as well |
| 18:46.36 | zerohalo | pokes around |
| 18:50.45 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.166) |
| 19:00.17 | zerohalo | oh, this doesn't look too bad |
| 19:07.27 | zerohalo | hrm |
| 19:08.06 | zerohalo | anyway - fun project... we'll see what happens over the weekend |
| 19:40.26 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.166) |
| 20:14.47 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 20:14.49 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 20:34.47 | *** join/#asterisk-dev wedhorn (~wedhorn@27-33-41-99.static.tpgi.com.au) |
| 20:41.36 | *** join/#asterisk-dev leifmadsen (~lmadsen@asterisk/documenteur-extraordinaire/blitzrage) |
| 20:41.36 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 20:42.15 | pabelanger | okay, this is pretty crazy. bridge-create, bridge-music-add foo, bridge-channel-add foo bar, channel-music-add bar |
| 20:42.18 | pabelanger | moh on top of moh |
| 20:42.19 | pabelanger | :D |
| 20:42.55 | leifmadsen | so much moh! |
| 20:42.58 | leifmadsen | you can't get enough |
| 20:43.04 | pabelanger | you dawg, I heard you like moh |
| 20:46.36 | mjordan | the possibilities are endless! |
| 20:46.41 | mjordan | so long as what you want is moh. |
| 20:48.30 | pabelanger | Ya, now that audio is flowing, trying to decided if it is better to drop people into a bridge place them on hold or just do it per channel |
| 20:57.39 | mjordan | there's a lot of interesting use cases to work through whether or not a bridge operation is better or a channel operation is better |
| 20:58.04 | mjordan | i.e., do you record the bridge? Or do you monitor the channel? (Once we have monitoring in, anyway) |
| 20:58.13 | mjordan | but at least both are options |
| 20:58.30 | pabelanger | right |
| 20:59.29 | jrose_atDigium | pabelanger: You know, the first thing I thought of when music on hold in bridges became a thing was sketchy 'chat lines' that get advertised at night with smooth jazz |
| 21:00.10 | jrose_atDigium | Since moh to the bridge doesn't actually put the parties on hold yeah |
| 21:00.15 | pabelanger | I plan to be the first sketchy chat lines using ARI! |
| 21:00.36 | pabelanger | Ya, more thinking for a queueing POV |
| 21:00.59 | pabelanger | music_while_wait |
| 21:01.08 | mjordan | pabelanger: have you tried holding bridges yet? |
| 21:01.22 | pabelanger | mjordan, no, but give me 1 min and I can |
| 21:01.38 | mjordan | play around with those - they're basically what a queue would use while callers wait. |
| 21:01.48 | mjordan | also: once you have that, take a look at putting a channel in as an announcer |
| 21:01.53 | mjordan | good fun there :-) |
| 21:02.05 | jrose_atDigium | The most interesting thing about holding bridges is that the entertainment can be interrupted by an announcer. |
| 21:02.19 | jrose_atDigium | And that it resumes without breaking anything |
| 21:02.24 | jrose_atDigium | I think... |
| 21:02.27 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.221) |
| 21:02.29 | mjordan | jrose_atDigium: you did write that... |
| 21:03.08 | jrose_atDigium | Yes. I have full confidence that I tested it. At some point. And it worked. For a while. |
| 21:03.35 | mjordan | jrose_atDigium: you're filling me with hope here |
| 21:03.50 | jrose_atDigium | It's not that elaborate of a feature. It'll probably be fine. |
| 21:05.27 | pabelanger | okay |
| 21:05.30 | pabelanger | just did it |
| 21:05.35 | pabelanger | in a hold bridge |
| 21:06.24 | pabelanger | so, why is the difference between bridge-add mixing, bridge-moh-add foo vs bridge-add holding |
| 21:06.39 | pabelanger | s/why/what |
| 21:07.45 | mjordan | so. A holding bridge has a different mixing technology than a mixing bridge |
| 21:07.46 | jrose_atDigium | a holding bridge is incapable of mixing audio for one thing |
| 21:08.01 | mjordan | right |
| 21:08.04 | jrose_atDigium | it just relays audio from an announcer channel to the other channels in the bridge if there is one |
| 21:08.20 | pabelanger | okay, a caller in holdbridge is inherently muted? |
| 21:08.22 | mjordan | and other channels have their audio dropped, as opposed to being sent to other participants |
| 21:08.40 | mjordan | If by muted, your voice frames are perma-deleted, yes |
| 21:08.45 | pabelanger | okay |
| 21:08.46 | jrose_atDigium | muted implies action. A caller in a holding bridge never had a voice to begin with |
| 21:08.47 | pabelanger | yup |
| 21:08.52 | mjordan | pabelanger: think parking :-) |
| 21:08.55 | pabelanger | ya |
| 21:09.12 | pabelanger | and when an announcer talks to the bridge, everybody hears it at the same time? |
| 21:09.16 | jrose_atDigium | yes |
| 21:09.17 | mjordan | with the option of having channels join as "announcers" - they can play audio to all channels simulatenously |
| 21:09.24 | mjordan | "Your call is important to us" |
| 21:09.36 | pabelanger | interesting |
| 21:09.37 | mjordan | "Buy our products, plz" |
| 21:10.02 | mjordan | in a mixing bridge, everyone can hear and talk to everyone else |
| 21:10.14 | jrose_atDigium | "Can haz ur buziness in futoor" |
| 21:10.26 | pabelanger | okay |
| 21:10.27 | mjordan | the operations are the same - you can play MoH in a holding bridge or a mixing bridge, but in a mixing bridge - even with MoH - participants can still talk |
| 21:10.30 | pabelanger | ya, I don't have another caller in my bridges. just me on sipml5 |
| 21:11.17 | jrose_atDigium | *playing MOH on a holding bridge is funny since channels will usually be playing MOH already* |
| 21:11.33 | jrose_atDigium | You'll just be interrupting their MOH with an announcer channel playing MOH |
| 21:11.45 | pabelanger | ya |
| 21:11.48 | pabelanger | did that already |
| 21:12.21 | jrose_atDigium | Technically I think channels are able to use features while in a holding bridge too, but I don't think anything exposes that yet. |
| 21:13.17 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-xnncjwmnsiwkinzt) |
| 21:13.32 | pabelanger | Hmm |
| 21:13.45 | mjordan | jrose_atDigium: that'd be weird and strange. |
| 21:13.50 | pabelanger | okay, so I guess you cannot remove a channel from a bridge while an audio prompt is playing to the channel |
| 21:14.03 | pabelanger | guess we'll need DELETE /channels/:id/play |
| 21:14.05 | pabelanger | to stop audio |
| 21:14.13 | jrose_atDigium | mjordan: Not if the holding bridge had its own specific functions |
| 21:14.25 | jrose_atDigium | Like 'press 6 to cry for help' |
| 21:14.34 | mjordan | true, but that'd be a lot of hard coded C |
| 21:14.39 | jrose_atDigium | '5 to cycle to another awesome song' |
| 21:14.44 | mjordan | with ARI, that should just be done using DTMF events |
| 21:14.51 | jrose_atDigium | Yeah |
| 21:14.54 | pabelanger | ARI deadlock, woops |
| 21:15.06 | jrose_atDigium | I'm still stuck in the old world at the moment |
| 21:15.31 | jrose_atDigium | I'm not sure if discovering the new world makes the old world go away or not yet. |
| 21:16.25 | mjordan | it does, just slowly |
| 21:16.28 | mjordan | pabelanger: deadlock? |
| 21:16.43 | pabelanger | mjordan, my ARI HTTP request has yet to return |
| 21:16.54 | pabelanger | waiting to see if it will |
| 21:17.10 | pabelanger | $ .tox/py27/bin/ari channel-audio-add 1382130220.19 sound:demo-congrats a few times |
| 21:17.21 | pabelanger | $ .tox/py27/bin/ari bridge-channel-remove da86a7bf-05e9-4933-bc3f-40870a54fdbc 1382130220.19 |
| 21:17.21 | mjordan | probably not a deadlock so much as something gone strangly wrong. |
| 21:17.25 | pabelanger | there |
| 21:17.31 | mjordan | ah |
| 21:17.39 | mjordan | you queued up a sound and then removed from a bridge? |
| 21:17.39 | pabelanger | Ya, tried to remove a channel from bridge while playing audio to channel |
| 21:17.42 | mjordan | yup |
| 21:17.44 | pabelanger | ya |
| 21:17.44 | mjordan | it will finish the audio |
| 21:17.58 | pabelanger | okay, so need to stop the audio |
| 21:18.07 | pabelanger | time to see how to do DELETE /channels/:id/play |
| 21:18.18 | mjordan | take the playback object and just stop it |
| 21:18.42 | jrose_atDigium | Well, there was some talk about making the playback channels 'lonely' so that they would just leave on their own if they weren't playing to anyone. |
| 21:19.14 | pabelanger | well, that could be tricky, I don't really know what audio prompt is playing at that point of time |
| 21:19.17 | mjordan | jrose_atDigium: yes, but this is also a more general thing - if you're playing media on a channel, you can't do much else with it until that operation finishes |
| 21:19.23 | pabelanger | so, how do I know the playback id? |
| 21:19.31 | mjordan | pabelanger: it is returned when you start the play operation |
| 21:19.32 | jrose_atDigium | when you first queue the sound file |
| 21:19.36 | jrose_atDigium | you receive a playback id |
| 21:19.45 | pabelanger | Right, but say I queue like 10 prompts |
| 21:19.51 | pabelanger | and then want to stop it some time in the future |
| 21:20.00 | pabelanger | how do I know what prompt asterisk is playing at that point in time |
| 21:20.20 | jrose_atDigium | You should receive start and stop events when each prompt starts and stops playing, but those aren't in there yet I think |
| 21:20.32 | jrose_atDigium | on your websocket that is |
| 21:20.36 | mjordan | hrm. They aren't? |
| 21:20.36 | pabelanger | Ah, |
| 21:20.39 | mjordan | I thought we had those events |
| 21:20.47 | jrose_atDigium | The events are defined, but unissued |
| 21:20.49 | pabelanger | no events |
| 21:20.55 | mjordan | phooey. |
| 21:20.56 | jrose_atDigium | I filed an issue for it earlier this week |
| 21:20.59 | mjordan | ah |
| 21:21.00 | mjordan | kk |
| 21:21.17 | mjordan | pabelanger: that being said, that's one of those things a library should probably track |
| 21:21.29 | pabelanger | Ya, seems to be |
| 21:21.30 | mjordan | if a user queues up a sound, having a list of sounds that are queued up is useful |
| 21:21.40 | jrose_atDigium | ASTERISK-22710 |
| 21:22.16 | pabelanger | what function in asterisk stops audio on a channel today? |
| 21:22.22 | mjordan | there isn't |
| 21:22.24 | jrose_atDigium | I don't think there is one |
| 21:22.32 | mjordan | it's a control frame |
| 21:22.40 | mjordan | more plumbing that was put in to support such things for Asterisk 12 :-) |
| 21:22.57 | pabelanger | okay |
| 21:23.18 | pabelanger | that explains why DELETE /channels/:id/play doesn' |
| 21:23.20 | pabelanger | t exist :D |
| 21:23.43 | mjordan | you could have one, and it would just emulate the stop control on the playback resource |
| 21:24.02 | pabelanger | right |
| 21:24.06 | jrose_atDigium | pabelanger: You are looking in the wrong place. It's DELETE /playback/:id |
| 21:24.08 | mjordan | it would just queue up the same control frame. From the perspective of the routines that play the media, that's the only way to prematurely end the playback |
| 21:24.22 | mjordan | but yes, doing it on the playback resource is more consistent |
| 21:25.52 | pabelanger | lol |
| 21:26.01 | pabelanger | GET /Playbacks missing |
| 21:26.03 | pabelanger | :( |
| 21:26.18 | pabelanger | wait |
| 21:26.24 | pabelanger | it is /playback |
| 21:26.30 | pabelanger | missing the s |
| 21:26.53 | jrose_atDigium | I don't think you can get a list of all the currently running playbacks |
| 21:27.02 | jrose_atDigium | There is a get playback by ID function though |
| 21:27.15 | pabelanger | no support in asterisk for listing them? |
| 21:27.31 | jrose_atDigium | Well, not yet. I'm not sure if we'd ever have a real purpose for doing so either |
| 21:42.28 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-84-109-18-138.red.bezeqint.net) |
| 21:42.29 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:01.44 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 22:01.57 | *** join/#asterisk-dev dseeb (~dseeb@eth217.tas.adsl.internode.on.net) |
| 22:20.31 | pabelanger | how can I check to see if a channel is currently playing audio in asterisk? |
| 22:21.19 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 22:22.12 | pabelanger | going to see about adding 409 Conflict or something else to bridge-channel-remove |
| 22:22.21 | pabelanger | rather then just block |
| 22:23.09 | mjordan | pabelanger: alas, that is a non-trivial question |
| 22:24.07 | mjordan | pabelanger: in general, ast_channel_stream(c) should return something non-NULL |
| 22:24.18 | pabelanger | k |
| 22:24.20 | mjordan | where c is your channel |
| 22:24.31 | pabelanger | let me see what happens when I use that |
| 22:24.47 | mjordan | which makes him sad, because that means you can only have one stream per channel :-( |
| 22:26.51 | pabelanger | mjordan, would I have to wrap that into a stasis_app from res/ari/resource_bridge.c ? |
| 22:28.46 | mjordan | pabelanger: actually, I'm not sure :-) That may be a better question for leedm777 for opticron |
| 22:28.56 | pabelanger | okay |
| 22:29.14 | pabelanger | going to try directly accessing ast_channel_stream() and see what happens |
| 22:29.27 | mjordan | so long as you don't modify it, you should be okay |
| 22:54.25 | pabelanger | Sweet |
| 22:54.27 | pabelanger | it worked |
| 22:54.32 | pabelanger | asterisk return'd right away |
| 23:36.31 | *** join/#asterisk-dev dseeb (~dseeb@eth217.tas.adsl.internode.on.net) |
| 23:36.40 | *** part/#asterisk-dev dseeb (~dseeb@eth217.tas.adsl.internode.on.net) |
| 23:36.46 | *** join/#asterisk-dev dseeb (~dseeb@eth217.tas.adsl.internode.on.net) |
| 23:47.09 | Kobaz | hmm |
| 23:47.28 | Kobaz | so when you have channel<->dialplan why is the rtp instance->chan null ? |
| 23:47.49 | Kobaz | how do you find out what channel the rtp is sending/receiving on behalf of, with an unbridged channel? |