| 01:20.57 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 01:20.57 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 01:35.52 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.158) |
| 01:44.57 | *** join/#asterisk-dev spditner (~simon@206-248-134-100.dsl.teksavvy.com) |
| 03:21.08 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 03:21.09 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 03:28.54 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 03:28.55 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 03:36.51 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.240) |
| 04:37.22 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.190) |
| 06:39.09 | *** join/#asterisk-dev vlad_starkov (~vlad_star@212.44.137.202) |
| 06:42.01 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@195.239.220.131) |
| 06:52.27 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.61.47) |
| 07:03.08 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:5c1a:8782:b0d6:2a87) |
| 08:24.26 | *** join/#asterisk-dev sgimeno (~sgimeno@163.117.206.10) |
| 08:35.27 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.239.220.131) |
| 11:02.38 | *** join/#asterisk-dev oron (~oron_lapt@local.xorcom.com) |
| 11:28.01 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 11:28.08 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 11:28.08 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 11:31.16 | *** join/#asterisk-dev Devon__ (~Devon_@63.214.236.169) |
| 11:40.29 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.172) |
| 11:40.48 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-kkpwhuvhnmknzbpv) |
| 11:52.19 | *** join/#asterisk-dev suneye (~atcmmi@119.122.153.217) |
| 12:17.00 | *** join/#asterisk-dev Marquis42 (~mrbmw@c-68-43-92-199.hsd1.mi.comcast.net) |
| 12:38.47 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-tksczegomknwqzfv) |
| 12:38.48 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:44.14 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.61.47) |
| 12:49.06 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 13:05.18 | *** join/#asterisk-dev jsmith (~jsmith@fedora/jsmith) |
| 13:05.18 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 13:07.44 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.168) |
| 13:12.14 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 13:12.15 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 13:21.41 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:21.41 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:41.51 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:5c1a:8782:b0d6:2a87) |
| 13:44.10 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:44.10 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:44.28 | file | putnopvut, I've a question |
| 13:44.42 | putnopvut | file: go right ahead! |
| 13:45.05 | file | putnopvut, ASTERISK-22024 specifically From header handling... the logic doesn't look right to me in res_sip_callerid |
| 13:45.13 | file | when it comes to modifying outgoing |
| 13:47.33 | putnopvut | file: yeah that looks wrong. |
| 13:48.31 | putnopvut | The trust_id_outbound should only affect outgoing Identification if it's been marked private. You shouldn't need to trust outbound ID *and* have non-private identification. |
| 13:48.53 | file | that's what I thought! |
| 13:49.52 | putnopvut | I think the only change needed is to change the && to || after the trust_id_outbound check. |
| 13:50.29 | file | GCC might complain |
| 13:50.31 | putnopvut | Also, that if is messed up because it's checking the name's privacy twice and not the number's privacy at all |
| 13:50.35 | file | yeah |
| 13:50.39 | putnopvut | Yeah I think I'd need some extra parens |
| 13:50.43 | file | yup |
| 13:51.05 | putnopvut | I'll go ahead and commit it and ask Rusty to retest with the revision I commit it in. |
| 14:02.22 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.193) |
| 14:21.59 | *** join/#asterisk-dev dwayne (~dwayne@c-71-207-208-112.hsd1.al.comcast.net) |
| 14:31.44 | putnopvut | mjordan: I can reliably trigger an assertion in CDR code in trunk right now by performing an AMI redirect. http://ur1.ca/ekk73 |
| 14:32.23 | putnopvut | What you have there is that Alice calls Bob. Then AMI redirects Bob to Carol. It appears that when Carol answers, a FRACK message appears. |
| 14:35.25 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.193) |
| 14:36.32 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-nbhhtzaqhpcgxeck) |
| 14:36.39 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-nbhhtzaqhpcgxeck) |
| 14:36.47 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-nbhhtzaqhpcgxeck) |
| 14:49.21 | Marquis42 | leedm777: So going back to my websocket issue you helped me with on Friday, it's definitely a load order issue. If I unload res_stasis_http* manually and then load them again, it works fine. |
| 14:53.41 | mjordan | putnopvut: phooey. |
| 14:53.56 | putnopvut | mjordan: sorry :-/ |
| 14:54.10 | leedm777 | Marquis42: What's strange is that res_http_websocket is being loaded first, which is the correct load order. |
| 14:54.44 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:54.44 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:54.49 | mjordan | did carol dial bob? |
| 14:55.10 | mjordan | er |
| 14:55.11 | mjordan | no. |
| 14:55.13 | putnopvut | no |
| 14:56.12 | Marquis42 | leedm777: Right, that's what I saw on Friday. Let me double-check that I didn't get that wrong, though. |
| 14:56.16 | mjordan | Odd. I'll have to look at the Stasis messages. For some reason we thought carol dialed bob - which seems wrongish - and then when the dial completes, we think bob dials carol |
| 15:00.17 | Marquis42 | leedm777: Does res_stasis.so need to load before res_stasis_http.so? |
| 15:00.34 | leedm777 | checking |
| 15:01.56 | leedm777 | Marquis42: No. But both need to be loaded before the other res_stasis_http_*.so modules are loaded. |
| 15:03.28 | Marquis42 | oic... Well then there's our problem I think. At least some of the res_stasis_http_* are loading before res_stasis.so |
| 15:03.49 | Marquis42 | Or wait, I'm reading this wrong. |
| 15:04.05 | Marquis42 | Sorry, just res_stasis_*.so not res_stasis_http_*.so |
| 15:15.37 | Marquis42 | leedm777: OK, so if I use a preload => res_http_websocket.so in my modules.conf it works. |
| 15:27.38 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:10.41 | Qwell | res_http_websocket + global symbols == bad |
| 16:10.51 | Qwell | Because it uses optional API. Things are really screwy. |
| 16:18.11 | leedm777 | Qwell: care to elaborate? Do you mean global symbols in res_http_websocket, or in a different module? |
| 16:19.13 | Qwell | I don't recall exactly - I just remember there being silliness when I was working on pjsip websockets stuff. I think it was a module that exported global symbols, using a module that used optional API. |
| 16:21.25 | leedm777 | It's probably that you have to set the priority properly. Optional API resolves symbols at load time, and anything that exports global symbols is loaded in a first pass by Asterisk. |
| 16:22.35 | Qwell | no, the priorities were right |
| 16:26.16 | leedm777 | well then. |
| 16:29.46 | Qwell | maybe a load vs start thing. modules are loaded in no particular order. It's start, where the order matters. |
| 16:31.00 | Qwell | s/matters/is taken into account/ |
| 16:33.45 | leedm777 | Qwell: I've been thinking about that. I wonder if the optional API should check the symbol on every call, instead of just when the module loads. |
| 16:47.12 | *** join/#asterisk-dev vlad_starkov (~vlad_star@87.117.139.75) |
| 17:03.47 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 17:03.48 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 17:26.03 | Qwell | leedm777: I'm getting a 404 from this. Am I doing it wrong still? wscat -s stasis -c "ws://localhost:8088/stasis/events?app=MyApp" |
| 17:26.57 | Qwell | I suspect I've got the wrong sub-protocol, maybe? |
| 17:27.05 | Marquis42 | subprotocol should be ari |
| 17:27.19 | Marquis42 | Also, how are you authenticating? |
| 17:27.20 | Qwell | still a 404 |
| 17:27.54 | Qwell | it read as though auth was only for swagger-ui... |
| 17:27.56 | Qwell | looks |
| 17:28.24 | Marquis42 | auth is required. You need to do either Basic HTTP auth or add api_key=username:password as a parameter |
| 17:29.36 | leedm777 | Qwell: URL changed to ws://localhost:8088/ari/events, plus everything Marquis42 said |
| 17:29.54 | Qwell | ari/events ? |
| 17:29.56 | Marquis42 | Oh, heh, didn't see that in the URL. Good catch leedm777. :) |
| 17:29.58 | Marquis42 | Yup |
| 17:30.02 | leedm777 | Yes. |
| 17:30.25 | file | it's almost as if Marquis42 has been playing with it... |
| 17:30.32 | Marquis42 | ikr? ;) |
| 17:30.40 | Qwell | Was the email wrong? It says /stasis/events/ |
| 17:31.08 | Marquis42 | It does say that, and it may or may not have been correct at that time. But it's definitely wrong now. :) |
| 17:31.08 | leedm777 | yeah, email was wrong. |
| 17:31.20 | leedm777 | Will send out correction. |
| 17:31.25 | Qwell | wscat -s ari -c "ws://localhost:8088/ari/events?api_key=admin:admin&app=MyApp" |
| 17:31.30 | Qwell | still a 404 there |
| 17:32.02 | Marquis42 | I assume the username/pass is correct for what's defined in ari.conf? |
| 17:32.10 | Qwell | http://pastebin.com/zbSP31ZP |
| 17:32.15 | leedm777 | Auth errors would be a 401 or 403 |
| 17:32.33 | leedm777 | 404 means the resource wasn't found |
| 17:32.40 | Marquis42 | Doesn't the user need to be defined as [user-admin]? |
| 17:32.44 | leedm777 | Qwell: What does module show like res_stasis_http give you? |
| 17:33.29 | Qwell | Not Running... |
| 17:33.32 | Qwell | *CLI> [Jul 8 12:32:38] ERROR[11698]: config_options.c:458 process_category: Could not find config type for category 'admin' in 'ari.conf' |
| 17:33.46 | Marquis42 | Right, see my comment above. |
| 17:33.47 | leedm777 | Yeah; change [admin] to [user-admin] |
| 17:33.59 | Qwell | context names can't matter |
| 17:34.00 | Qwell | that's bad |
| 17:34.47 | leedm777 | Qwell: then how do you determine what sort of context it is? |
| 17:34.51 | Qwell | That fixed it though. |
| 17:40.08 | Qwell | type=user |
| 17:40.22 | seanbright | the same way res_sip does i'd imagine |
| 17:40.29 | Qwell | seanbright: res_sip uses sorcery |
| 17:40.37 | Qwell | That's how confbridge does it though. |
| 17:40.41 | seanbright | ah |
| 17:40.55 | file | yeah, res_sip uses the same approach but sorcery provides an easy facility to do it for you |
| 17:41.05 | putnopvut | Qwell: I wouldn't go so far as to say context names mattering is "bad" but it's not typically how we do it in Asterisk. |
| 17:41.16 | putnopvut | You can get a lecture from Richard about that some time :) |
| 17:44.38 | leedm777 | discovers matchfield in the config framework |
| 17:45.03 | file | leedm777, achievement unlocked |
| 17:49.18 | *** join/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 17:50.01 | hexanol | is it possible for a channel driver to do a native bridge with a channel of a different type |
| 17:50.21 | hexanol | for example, would it be possible to do a native bridge between the chan_sip and chan_skinny channel drivers |
| 17:51.11 | file | it depends on the underlying media transport in use, in that case yes - both are using RTP so at the very least they could likely do a local native bridge |
| 17:51.26 | file | if you can redirect media in Skinny like you can in SIP, then a remote would also be possible |
| 17:51.37 | hexanol | ok, so the core does allow to do a native bridge between channels of different technology ? |
| 17:51.49 | file | the core doesn't enforce that restriction |
| 17:51.58 | hexanol | (I was looking a bit at the doxygen documentation and it didn't seem to clear; did not check the code in details as for now) |
| 17:52.16 | hexanol | ok |
| 17:52.45 | hexanol | and then, depending on which channel is the "inbound channel", i.e. the one who started the pbx thread |
| 17:52.57 | hexanol | the core will either call the .bridge function of chan_sip or chan_skinny driver ? |
| 17:53.10 | file | the bridge function has to be the same |
| 17:53.21 | file | in the case of RTP using channel drivers, it is |
| 17:53.42 | hexanol | ok |
| 17:56.23 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 17:56.24 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 18:04.16 | *** join/#asterisk-dev tonyclewis (uid6025@gateway/web/irccloud.com/x-xexiacvesvxxyixe) |
| 18:05.52 | *** join/#asterisk-dev GameGamer43 (uid5533@gateway/web/irccloud.com/x-cpranlfeerrxiquz) |
| 18:14.49 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 18:14.49 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 18:21.23 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.189) |
| 18:31.41 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.189) |
| 19:27.19 | *** join/#asterisk-dev zerohalo (~zerohalo@c-174-62-142-83.hsd1.ma.comcast.net) |
| 20:33.44 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.234) |
| 20:40.48 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 20:40.48 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 21:29.38 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:34.54 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.234) |
| 22:06.44 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 22:06.44 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 22:35.52 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.252) |
| 23:36.36 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.119) |
| 23:39.38 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 23:39.38 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |