| 01:07.05 | *** join/#asterisk bhans (~bhans@unaffiliated/bhans) |
| 01:26.50 | *** join/#asterisk Katty (uid62315@gateway/web/irccloud.com/x-ejaiudnzglgkvtqe) |
| 01:39.08 | *** join/#asterisk viro (~viro@unaffiliated/viro) |
| 01:48.01 | *** join/#asterisk sl4ck (~slack@185.57.80.147) |
| 01:54.04 | *** join/#asterisk shootbird (~quassel@beepbeep.serverpit.com) |
| 02:08.50 | *** join/#asterisk Dovid (~dovid@47.21.222.138) |
| 02:20.18 | *** join/#asterisk shootbird (~quassel@beepbeep.serverpit.com) |
| 02:32.43 | *** join/#asterisk shootbird (~quassel@beepbeep.serverpit.com) |
| 02:33.09 | *** join/#asterisk sl4ck (~slack@103.254.153.99) |
| 02:40.49 | *** join/#asterisk Oatmeal (~Suzeanne@2602:306:3676:c60:ddb8:9716:daf2:63bc) |
| 02:55.07 | *** join/#asterisk puzzled (~puzzled@2001:982:1097:1::1:3) |
| 03:19.45 | *** join/#asterisk Rini (uid196547@gateway/web/irccloud.com/x-alfyzdmftydvrobd) |
| 04:26.53 | *** join/#asterisk fstd_ (~fstd@unaffiliated/fisted) |
| 04:37.46 | *** join/#asterisk qakhan (~qakhan@50-204-254-11-static.hfc.comcastbusiness.net) |
| 04:38.14 | qakhan | hi all, is there any way we can save sip registeration in DB? |
| 04:39.13 | qakhan | like when an extension registered or unregistered, save extension status in DB |
| 04:50.29 | *** join/#asterisk slack1 (~slack@103.254.153.99) |
| 05:22.27 | *** join/#asterisk Dovid (~dovid@74.123.202.218) |
| 05:29.35 | *** join/#asterisk xzork (~Thunderbi@213.153.251.228) |
| 05:34.45 | *** join/#asterisk xzork (~Thunderbi@213.153.251.228) |
| 05:37.26 | *** join/#asterisk jkroon (~jkroon@uls-154-73-32-13.wall.uls.co.za) |
| 05:48.58 | denysonique | indications.conf set to country=uk under [general] does not producte the right Ringing() tone |
| 05:50.00 | denysonique | or actually it does |
| 05:56.31 | *** join/#asterisk skrusty (~skrusty@88.150.145.104) |
| 05:56.31 | *** mode/#asterisk [+o skrusty] by ChanServ |
| 05:58.34 | *** join/#asterisk xzork (~Thunderbi@81.215.229.142) |
| 05:59.09 | *** join/#asterisk evilman_work (~evilman@87.244.6.228) |
| 06:04.06 | *** join/#asterisk viro (~viro@unaffiliated/viro) |
| 06:44.33 | *** join/#asterisk miralin (~Thunderbi@195.19.212.23) |
| 06:47.02 | *** join/#asterisk daemon (~daemon@hostname.racing) |
| 06:55.15 | *** join/#asterisk Cory (~Cory@unaffiliated/cory) |
| 06:57.16 | *** join/#asterisk justdave (~dave@unaffiliated/justdave) |
| 06:57.29 | *** join/#asterisk smkelly (~smkelly@mykonos.smkelly.org) |
| 06:58.25 | *** join/#asterisk bof22 (~Thunderbi@185.13.183.107) |
| 07:13.18 | *** join/#asterisk Rasputin3711 (~Rasputin3@87.255.254.66) |
| 07:13.53 | *** join/#asterisk bof23 (~Thunderbi@185.13.182.47) |
| 07:56.27 | *** join/#asterisk Nugget (~nugget@rennsport.macnugget.org) |
| 08:09.36 | *** join/#asterisk Rac-on (jasper@bambi.rac-on.nl) |
| 08:15.19 | *** join/#asterisk tzafrir (~tzafrir@local.xorcom.com) |
| 08:16.58 | *** join/#asterisk pchero_work (~pchero@109.70.54.56) |
| 08:19.58 | *** join/#asterisk jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 08:32.05 | *** join/#asterisk AviiNL (~AviiNL@185.21.52.255) |
| 08:32.36 | *** join/#asterisk TandyUK (~admin@87.252.44.195) |
| 08:36.49 | *** join/#asterisk J0hnSteel (~J0hnSteel@92.55.117.100) |
| 08:45.13 | *** join/#asterisk DanB (~DanB@x2f7f5f0.dyn.telefonica.de) |
| 08:49.09 | *** join/#asterisk troyt (~troyt@2601:681:4601:bbc1:44dd:acff:fe85:9c8e) |
| 09:02.34 | *** join/#asterisk hehol (~hehol@gatekeeper.loca.net) |
| 09:20.49 | *** join/#asterisk Mp5shooter (~Mp5@unaffiliated/mp5shooter) |
| 09:24.14 | Mp5shooter | WARNING[101041] res_pjsip_sdp_rtp.c: Unable to get rtp codec payload code for slin |
| 09:24.34 | Mp5shooter | seeing this line in the logs for slin, testlaw, and silk at the beginning of inbound calls... anyone know what this means? |
| 09:32.28 | *** join/#asterisk ThomasKeller (~Thomas@vmx.ethz.ch) |
| 09:33.09 | *** join/#asterisk pa (~pa@unaffiliated/pa) |
| 09:39.36 | *** join/#asterisk cbeyerlein (~cbeyerlei@huckebein.pecudis.de) |
| 09:46.16 | cbeyerlein | Heya.. Whats the proper process to request a backport of some stuff from Asterisk 14 to Asterisk 13? |
| 09:46.54 | cbeyerlein | essentially its about this PJSIP media hold passthrough stuff I need in Ast13: https://reviewboard.asterisk.org/r/4103/diff/#index_header |
| 09:57.18 | jkroon | cbeyerlein, as far as I know 14 is the LTS release of 13 - so perhaps a better approach is to upgrade? |
| 10:00.02 | cbeyerlein | AFAIK 13 is LTS, 14 not |
| 10:00.13 | cbeyerlein | that why we prefer to stay on 13 |
| 10:21.54 | jkroon | hmm, actually you're right I think. Sorry about that. Generally I don't think new features normally added to LTS releases. |
| 10:28.09 | *** join/#asterisk thiagoc (~thiagoc@unaffiliated/thiagoc) |
| 10:37.37 | *** join/#asterisk miralin (~Thunderbi@195.19.212.23) |
| 10:39.46 | *** part/#asterisk Mp5shooter (~Mp5@unaffiliated/mp5shooter) |
| 10:51.35 | *** join/#asterisk Nugget (~nugget@rennsport.macnugget.org) |
| 10:58.50 | *** join/#asterisk sl4ck (~slack@103.254.153.99) |
| 11:05.29 | *** join/#asterisk jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 11:06.46 | *** join/#asterisk ixyd (~denzs@b2b-46-252-133-250.unitymedia.biz) |
| 11:19.23 | jkroon | cbeyerlein, based on past experience i'd suggest filing a bug, and then taking it to gerrit.asterisk.org if you've got patches (which you can build). There is a tutorial somewhere, but I can also suggest joining #asterisk-dev. Dev queries are better handled there. |
| 11:22.19 | *** join/#asterisk loevoe (511d2daa@gateway/web/freenode/ip.81.29.45.170) |
| 11:23.17 | loevoe | Hello, have anyone experience with getting the g722 codec to use 16kHz sample rate instead of 8kHz? |
| 11:35.07 | *** join/#asterisk Tiffon (~name@unaffiliated/tiff0n) |
| 11:54.35 | *** part/#asterisk xzork (~Thunderbi@81.215.229.142) |
| 12:30.02 | cbeyerlein | jkroon, thx for the insight |
| 12:32.28 | *** join/#asterisk jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 12:38.23 | *** join/#asterisk sl4ck (~slack@88-111-150-65.dynamic.dsl.as9105.com) |
| 12:52.12 | *** join/#asterisk KaliLinuxGR (~alexandro@unaffiliated/kalilinuxgr) |
| 13:18.47 | *** join/#asterisk jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 13:24.49 | *** join/#asterisk miralin (~Thunderbi@195.19.212.23) |
| 13:27.35 | *** join/#asterisk Rini (uid196547@gateway/web/irccloud.com/x-ijswrzhmqnfeppoh) |
| 13:36.43 | *** join/#asterisk somepoortech (~somepoort@72-0-128-202.static.firstlight.net) |
| 13:38.43 | *** join/#asterisk rwb (~Thunderbi@204.13.43.166) |
| 13:51.00 | *** join/#asterisk [TK]D-Fender (~joe@216.191.106.165) |
| 13:58.55 | *** join/#asterisk bittis (~whatever@81.21.47.137) |
| 14:00.53 | bittis | hey guys, i have a quick question, writing an agi script in perl, what i noticed is that when executing the dial app, if a call is succesful it doesn't return control back to the script, is this normal behaviour? |
| 14:03.02 | *** join/#asterisk Cory (~Cory@unaffiliated/cory) |
| 14:22.04 | *** join/#asterisk rwb (~Thunderbi@204.13.43.166) |
| 14:24.59 | *** join/#asterisk zapata (~zapata@2a02:b18:581:10:8527:399f:b4b1:4b14) |
| 14:27.48 | *** join/#asterisk rwb (~Thunderbi@204.13.43.166) |
| 14:33.14 | [TK]D-Fender | Depends how you trap the call termination. |
| 14:33.18 | [TK]D-Fender | This is well documented |
| 14:57.29 | bittis | i am looking at the g option |
| 15:04.55 | [TK]D-Fender | generally not the way and that only covers 1 sides ending of the call |
| 15:05.02 | [TK]D-Fender | as that* |
| 15:09.07 | *** join/#asterisk jameswf (uid27319@gateway/web/irccloud.com/x-cfcsihcwputbhmgu) |
| 15:13.19 | bittis | the senario is that i dial via iax2, should i be looking at a different way? |
| 15:21.22 | *** join/#asterisk jetlag (~jetlag@c-71-226-222-56.hsd1.nj.comcast.net) |
| 15:22.21 | *** join/#asterisk monsterco (~monsterco@toroon474aw-lp130-02-70-50-209-133.dsl.bell.ca) |
| 15:23.19 | *** join/#asterisk xzork (~Thunderbi@81.215.229.142) |
| 15:23.48 | *** join/#asterisk shootbird (~quassel@beepbeep.serverpit.com) |
| 15:27.28 | *** part/#asterisk monsterco (~monsterco@toroon474aw-lp130-02-70-50-209-133.dsl.bell.ca) |
| 15:27.56 | *** join/#asterisk kharwell (kharwell@nat/digium/x-rtjfgdxeonpoldlr) |
| 15:27.56 | *** mode/#asterisk [+o kharwell] by ChanServ |
| 15:28.51 | *** join/#asterisk xzork (~Thunderbi@81.215.229.142) |
| 15:28.55 | *** join/#asterisk pvoigt (~Linux@unaffiliated/pvoigt) |
| 15:37.01 | *** join/#asterisk rwb (~Thunderbi@204.13.43.166) |
| 15:44.53 | *** join/#asterisk newtonr (RustyNewto@nat/digium/x-vdksioyulklbgctl) |
| 15:44.53 | *** mode/#asterisk [+o newtonr] by ChanServ |
| 15:46.46 | igcewieling1 | bittis: I solved the issue by never dialing from an AGI. |
| 15:47.06 | *** join/#asterisk brad_mssw (~brad@66.129.88.50) |
| 15:47.39 | igcewieling1 | on my systems there is an AGI script which does the database lookups, then sets a bunch of dialplan vairables then exits back to the dialplan for the actual dialing. A hangup AGI is run when the call is done. |
| 15:54.45 | [TK]D-Fender | bittis, You need your script to deal with the HUP. Again, go look at language specific coding notes. |
| 15:54.59 | [TK]D-Fender | The channel-type is not important, jsut how your script handles calls |
| 15:56.28 | bittis | thanks for the info guys |
| 15:56.40 | bittis | what do you mean by HUP ? |
| 15:57.21 | bittis | SIGHUP? |
| 15:58.09 | *** join/#asterisk Dovid (~dovid@ool-321d6484.dyn.optonline.net) |
| 15:58.42 | *** join/#asterisk zhold (~zhold@95.183.48.101) |
| 15:59.27 | [TK]D-Fender | yes |
| 15:59.43 | [TK]D-Fender | Get Googling <- |
| 16:01.38 | bittis | yes sir! thanks for pointing the right way :) |
| 16:14.39 | *** join/#asterisk miralin (~Thunderbi@194.8.128.47) |
| 16:15.52 | *** join/#asterisk xzork (~Thunderbi@213.153.251.228) |
| 16:16.07 | *** join/#asterisk Dovid (~dovid@ool-3f8fe7c9.dyn.optonline.net) |
| 16:19.14 | *** join/#asterisk Chainsaw (~chainsaw@gentoo/developer/chainsaw) |
| 16:23.47 | *** join/#asterisk rmudgett (rmudgett@nat/digium/x-cakrkvmuqpohoyjz) |
| 16:23.47 | *** mode/#asterisk [+o rmudgett] by ChanServ |
| 16:25.08 | *** join/#asterisk cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 16:25.08 | *** mode/#asterisk [+o cresl1n] by ChanServ |
| 16:45.57 | *** join/#asterisk rrittgarn (~rrittgarn@75-150-221-205-Illinois.hfc.comcastbusiness.net) |
| 16:53.15 | *** join/#asterisk luckman212 (~luckman21@unaffiliated/luckman212) |
| 17:03.16 | *** join/#asterisk tristero (~al.f.zero@unaffiliated/transfinite) |
| 17:07.03 | TandyUK | <PROTECTED> |
| 17:07.10 | TandyUK | any verbosity level that will make that message useful |
| 17:07.34 | TandyUK | like is this a packet to one of my users, or just dropped repsonses to an invite attempt being retransmitted |
| 17:07.45 | TandyUK | the one key piece of info that is missing imho: Remote IP |
| 17:08.36 | Chainsaw | TandyUK: At verbose 10 I see the destination. |
| 17:08.54 | Chainsaw | TandyUK: But I couldn't tell you what exact level it triggers at. |
| 17:11.24 | TandyUK | the other annoying one (which i undertsnad is a TLS timeout) is WARNING[1703]: chan_sip.c:4293 retrans_pkt: Timeout on 9f7cf984184a0831faa93a1867c568c1 on non-critical invite transaction. |
| 17:11.31 | TandyUK | and thats from 'core set verbose 10' |
| 17:13.03 | TandyUK | ideally if this stuff is from driveby login fails, id like to be blocking this |
| 17:15.06 | [TK]D-Fender | you probably are. |
| 17:15.29 | [TK]D-Fender | that is the kind of message you get if the packet is responding is being rejected from the stack based on firewalling |
| 17:15.31 | [TK]D-Fender | check for that |
| 17:17.53 | *** join/#asterisk xzork (~Thunderbi@213.153.251.228) |
| 17:23.31 | TandyUK | without the destination IP i have nothign to chack against though |
| 17:23.42 | TandyUK | thats what tells me very easily if its one of my users or not |
| 17:24.01 | [TK]D-Fender | You check against iptables |
| 17:24.18 | [TK]D-Fender | and the full debug because 8 will TELL you where it's trying to send that to |
| 17:24.18 | TandyUK | i think you miss the point lol |
| 17:24.23 | [TK]D-Fender | * |
| 17:24.36 | TandyUK | i have 'core set verbose 10' and am not seeing ips |
| 17:24.38 | [TK]D-Fender | [TK]D-Fender> and the full debug because * will TELL you where it's trying to send that to <- |
| 17:24.39 | [TK]D-Fender | SIP DEBUG |
| 17:24.45 | [TK]D-Fender | verbose means nothing |
| 17:25.02 | TandyUK | unless you mean turn on sip sebug, in whcih case good luck ever seeing anything because we have about 1000 lines a second being logged at that point |
| 17:25.31 | TandyUK | and i can enable sip debug for a specific ip, becvause at this point i dont know the ip i want to filter ;) |
| 17:25.34 | TandyUK | cant* |
| 17:27.38 | [TK]D-Fender | Oh yes you can... |
| 17:27.45 | [TK]D-Fender | because the packet will be right ebfore the error |
| 17:29.00 | WIMPy | TandyUK: For SIP debugging use sngrep. You can't do without. |
| 17:30.13 | TandyUK | cant use sngrep with TLS on centos 5 |
| 17:30.41 | TandyUK | for tcp/udp its fine, but C5 is missing ssl/tls compoenents which arent compilable |
| 17:30.46 | WIMPy | The sword of crypto cuts both ways. |
| 17:30.52 | TandyUK | indeed |
| 17:31.09 | TandyUK | im waiting for my system provider to release a C6 version which i'll be gladly updating to |
| 18:04.38 | igcewieling1 | lawful intercepts can also be an issue when using TLS |
| 18:10.23 | *** join/#asterisk Qwell (~north@asterisk/developer/Qwell) |
| 18:10.43 | *** mode/#asterisk [+o Qwell] by ChanServ |
| 18:12.16 | *** join/#asterisk robmal (r@wporzo.pl) |
| 18:22.25 | *** join/#asterisk tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 18:33.00 | *** join/#asterisk tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 18:35.40 | *** join/#asterisk luckman212 (~luckman21@unaffiliated/luckman212) |
| 18:42.29 | *** join/#asterisk tzafrir (~tzafrir@bzq-82-81-175-197.red.bezeqint.net) |
| 19:09.52 | *** join/#asterisk ericNL (eric@eyeswideshut.xs4all.nl) |
| 19:20.17 | *** join/#asterisk Samot_ (sid133316@gateway/web/irccloud.com/x-cpucqplneoztddbr) |
| 19:20.19 | *** join/#asterisk jrun (~jrun@unaffiliated/glphvgacs) |
| 19:20.59 | *** join/#asterisk Rini_ (uid196547@gateway/web/irccloud.com/x-tamjuzmzqlntwqsx) |
| 19:21.04 | *** join/#asterisk GameGamer43_ (sid5533@gateway/web/irccloud.com/x-xewtzbpkaejpkqso) |
| 19:21.58 | *** join/#asterisk Gugge_ (gugge@92.246.2.105) |
| 19:23.17 | *** join/#asterisk giesen_ (~ggiesen@2001:19f0:0:1019:5400:ff:fe25:bda6) |
| 19:26.28 | *** join/#asterisk _skrusty (~skrusty@88.150.145.104) |
| 19:26.28 | *** mode/#asterisk [+o _skrusty] by ChanServ |
| 19:27.00 | *** join/#asterisk x5eb (~seb@seb-hpws2.elen.ucl.ac.be) |
| 19:28.52 | *** join/#asterisk ericNL (eric@eyeswideshut.xs4all.nl) |
| 19:32.41 | jrun | while voicemail is recording, asterisk stops sending audio stream out which seems to be timing out on rtp on the other end. is it possible to send a blank audio stream while recording? |
| 19:33.47 | jrun | transmit_silence i got from ml just now. thanks. |
| 19:34.56 | *** join/#asterisk thiagoc (~thiagoc@unaffiliated/thiagoc) |
| 19:45.23 | *** join/#asterisk ericNL (eric@eyeswideshut.xs4all.nl) |
| 19:46.48 | *** join/#asterisk Dovid (~dovid@ool-3f8fe413.dyn.optonline.net) |
| 19:47.54 | DivideBy0 | any luck with your concurrent MOH issue Dovid? |
| 20:04.16 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
| 20:04.41 | *** join/#asterisk tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 20:11.02 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
| 20:17.18 | *** join/#asterisk yokel (~yokel@unaffiliated/contempt) |
| 20:23.30 | *** join/#asterisk yokel_ (~yokel@unaffiliated/contempt) |
| 20:27.45 | *** join/#asterisk rwb (~Thunderbi@204.13.43.166) |
| 20:37.55 | *** join/#asterisk ericNL (eric@eyeswideshut.xs4all.nl) |
| 20:43.25 | *** join/#asterisk ericNL (eric@eyeswideshut.xs4all.nl) |
| 20:53.37 | *** join/#asterisk libardi (~kvirc@179.159.9.234) |
| 21:07.43 | *** join/#asterisk cervajs2 (~cervajs2@178.148.broadband4.iol.cz) |
| 21:09.04 | *** join/#asterisk wyoung (~wyoung@wesleyy.com) |
| 21:10.56 | cervajs2 | hi, whats the recommended way of using members in app_queue? i'm using local channels because i need some variables but there are problems (ringall: same call answered by two agents. call stop ringing to agent via local channel in 13.10 and higher. ... ) |
| 21:12.51 | cervajs2 | is there some rule "if you use 10 dialplan actions and 1AGI app which returns data within 1sec, you can use local channel for app_queue". |
| 21:22.38 | *** join/#asterisk Jesterboxboy (~Thunderbi@80-109-194-26.cable.dynamic.surfer.at) |
| 21:25.27 | *** join/#asterisk tirej (~tirej@unaffiliated/tirej) |
| 21:31.07 | *** join/#asterisk defsdoor (~andy@cpc35-sutt4-2-0-cust184.19-1.cable.virginm.net) |
| 21:55.56 | *** join/#asterisk aiksa[LV] (~aiksaLV]@212.70.182.82) |
| 21:56.29 | aiksa[LV] | hi everyone |
| 22:09.35 | aiksa[LV] | ari is driving me mad |
| 22:09.57 | aiksa[LV] | Recording Finished event without Recording started event |
| 22:10.04 | aiksa[LV] | and vice versa in random |
| 22:11.10 | DivideBy0 | aiksa[LV]: we'd have to see a paste of it |
| 22:11.49 | DivideBy0 | are you giving the recording an ID when you request it? |
| 22:12.22 | *** join/#asterisk prauscher (~prauscher@sheldon.prauscher.de) |
| 22:12.59 | prauscher | hey. i want to create a callfile which rings two lines and uses the first responding for execution. basically like Dial() works, but as callfile-channels |
| 22:13.38 | prauscher | Using the &-syntax in the Channel-field of the callfile does not work - is there any other way? |
| 22:14.19 | prauscher | my usecase is: i want to create a reminder for a conference call. my pbx shall ring all my lines and the first i pick up should be connected to the matching outgoing number |
| 22:14.38 | prauscher | (the conference room is not hosted on the same pbx) |
| 22:15.50 | *** join/#asterisk tristero (~al.f.zero@unaffiliated/transfinite) |
| 22:18.12 | aiksa[LV] | Divideby0 - hmm paste of decoded tcpdump |
| 22:18.46 | aiksa[LV] | so you could see recording initiation actions and events in one page |
| 22:19.46 | aiksa[LV] | or just ari debug where this happens? Because under normal circumstances I should always have recording started event first , right? |
| 22:19.52 | DivideBy0 | sure, usually we just see a debug |
| 22:20.06 | DivideBy0 | you can receive the events out of order |
| 22:20.19 | aiksa[LV] | yeah; i know that; |
| 22:20.25 | aiksa[LV] | wait a second |
| 22:22.42 | igcewieling1 | prauscher: see Local Channels |
| 22:25.13 | aiksa[LV] | DivideBy0: http://pastebin.com/ckymh3ww |
| 22:25.30 | aiksa[LV] | you can see recording finished at the end, but I never get recording started |
| 22:25.41 | aiksa[LV] | which i initated from ari |
| 22:26.12 | aiksa[LV] | and sometimes its the other way round - I see recording started, but never recieve recording finished |
| 22:27.41 | *** join/#asterisk fstd (~fstd@unaffiliated/fisted) |
| 22:27.47 | DivideBy0 | do you have another stasis app that's running at the same time? maybe you left it running in another session? |
| 22:27.54 | aiksa[LV] | and after that last event - no other events are fired recarding the recordings |
| 22:28.39 | aiksa[LV] | there are two statsis apps running both with different names; |
| 22:29.01 | aiksa[LV] | and if i swtich on debug for both - there are still events missing |
| 22:30.01 | aiksa[LV] | but both of them are in the smae process in backend and have the same event listeners - and intially I saw this in my event listener debug |
| 22:31.41 | DivideBy0 | that recordingfinished was for a different bridge than the one it shows the recorder joining |
| 22:32.50 | DivideBy0 | man, pastebin is really distracting with all the ads and movies, brb, real work for a sec |
| 22:34.48 | aiksa[LV] | basically what happens there - is a call which does two loops through the system; t2-1 -->*--> t2-1 -->*--> t2-1 with some prefix manipulation along the way |
| 22:35.10 | aiksa[LV] | therefore - two Stasis apps; each for each leg. |
| 22:35.22 | aiksa[LV] | _in and _out |
| 22:36.05 | aiksa[LV] | both apps request recording through stasis, + the second one requests additional recording in the middle of the bridge |
| 22:36.48 | aiksa[LV] | I would expect to see three RecordingStarted and three RecordingFinished (or Failed) events among these apps |
| 22:37.01 | aiksa[LV] | right?> |
| 22:37.18 | *** join/#asterisk war9407 (war@static-72-73-18-14.clppva.fios.verizon.net) |
| 22:37.31 | aiksa[LV] | i can paste a bin with both apps being debugged through CLI |
| 22:40.42 | DivideBy0 | I personally use 1 app, so I'm trying to wrap my mind around what you're doing |
| 22:41.19 | *** join/#asterisk fstd (~fstd@unaffiliated/fisted) |
| 22:41.31 | aiksa[LV] | https://0bin.net/paste/C5Xb7xT+bsT-nDSl#kdZOZt22hasnSYVrkztwfmKqL2ihisRNNNp0AnzyWyV |
| 22:41.32 | DivideBy0 | Please paste a debug of ari. It still feels like they're stepping on each other |
| 22:42.07 | DivideBy0 | can you just debug ari in general in case there's another app? |
| 22:44.25 | *** join/#asterisk klow (~textual@c-98-247-49-57.hsd1.wa.comcast.net) |
| 22:44.32 | aiksa[LV] | when I run through one app only I get the same result |
| 22:44.45 | DivideBy0 | with more than 1 app, they will only see events for the channels and bridges they own (or specifically subscribe to), so I still think the bridge creator will see the recording start/stop on the bridge only |
| 22:45.16 | aiksa[LV] | yeah, I know that |
| 22:45.35 | aiksa[LV] | but then: I shouldnt see RecordingFinished, correct? |
| 22:46.05 | aiksa[LV] | If I receive RecordingFinished, this should mean that I have the rights to access the events from this bridge |
| 22:46.17 | aiksa[LV] | and should have received RecordingStarted before |
| 22:47.20 | DivideBy0 | I agree with your logic. I'm still combing through the paste |
| 22:47.29 | *** join/#asterisk ericNL (eric@eyeswideshut.xs4all.nl) |
| 22:47.40 | aiksa[LV] | look at the other paste - it has both of the apps on the debug |
| 22:47.46 | aiksa[LV] | and no adverts |
| 22:47.55 | aiksa[LV] | and nice coloring |
| 22:49.07 | DivideBy0 | I'm looking at 0bin currently |
| 22:49.49 | aiksa[LV] | ok |
| 22:53.45 | DivideBy0 | it looks like you get the recordingfinished when the bridge is destroyed? is smex_out destroying the bridge or stopping the recording? |
| 22:54.28 | DivideBy0 | and you're absolutely sure there are only two stasis apps running on this box? smex_out and smex_in? |
| 22:55.41 | DivideBy0 | just for fun, can you requst a subscribeAll to the events in one of those apps (or a 3rd one) just so you could see all the events system-wide? |
| 22:56.01 | DivideBy0 | fyi: I have to go in about 10 mins |
| 22:56.14 | prauscher | igcewieling1: thank you, that works :) |
| 23:00.52 | aiksa[LV] | DivideBy0: absolutely sure that there are just two apps running |
| 23:02.06 | DivideBy0 | I don't see the bridge created, just destroyed. what creates it? |
| 23:03.50 | aiksa[LV] | I use the brdige created when Stasis_start happens; |
| 23:04.11 | aiksa[LV] | then I add channels to these |
| 23:04.34 | aiksa[LV] | after that request recording |
| 23:07.57 | aiksa[LV] | regarding that subscribeAll - I am now looking how to add that in the library which I am using; |
| 23:08.03 | DivideBy0 | I agree with what you said about seeing recordingfinished should give you recordingstarted |
| 23:08.21 | DivideBy0 | I think you should do a subscribeall and check a ari debug on, not per-app |
| 23:08.32 | DivideBy0 | I have to go, feel free to msg me a link to a new paste of all that |
| 23:08.39 | aiksa[LV] | Thanks |
| 23:08.49 | aiksa[LV] | 14.20 doesnt allow ari set debug on |
| 23:08.59 | aiksa[LV] | without specifying app |
| 23:09.08 | aiksa[LV] | or at least I dont know how to make it |
| 23:09.25 | DivideBy0 | if it's a test system, you can just core set debug 10 or something similar |
| 23:10.23 | *** join/#asterisk sifb (~simon@unaffiliated/sifb) |
| 23:10.37 | DivideBy0 | aiksa[LV]: also #asterisk-ari has more specific discussion too |
| 23:10.46 | DivideBy0 | sorry I'm not more help right now! |
| 23:11.23 | aiksa[LV] | thanks nonetheless |
| 23:11.25 | aiksa[LV] | !! |
| 23:11.56 | *** part/#asterisk cervajs2 (~cervajs2@178.148.broadband4.iol.cz) |
| 23:17.59 | *** join/#asterisk shootbird (~quassel@beepbeep.serverpit.com) |
| 23:19.04 | *** join/#asterisk wonderworld (~ww@ip-176-198-197-145.hsi05.unitymediagroup.de) |
| 23:35.48 | *** join/#asterisk [TK]D-Fender (~joe@64.235.216.2) |
| 23:48.16 | *** join/#asterisk rwb (~Thunderbi@65-183-151-239-dhcp.burlingtontelecom.net) |
| 23:53.27 | *** join/#asterisk rwb (~Thunderbi@65-183-151-239-dhcp.burlingtontelecom.net) |