| 00:21.58 | *** join/#asterisk-dev suneye (~atcmmi@119.122.152.6) |
| 00:31.17 | *** join/#asterisk-dev italorossi (~italoross@ec2-54-232-199-58.sa-east-1.compute.amazonaws.com) |
| 02:37.25 | *** join/#asterisk-dev italoros_ (~italoross@187.61.168.117) |
| 04:18.42 | *** join/#asterisk-dev italorossi (~italoross@187.61.168.117) |
| 05:07.17 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 05:07.17 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 05:36.17 | *** join/#asterisk-dev bulkorok (~chatzilla@gw1.pinguin.ag) |
| 05:55.01 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 05:55.02 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:18.41 | *** join/#asterisk-dev suneye (~atcmmi@119.122.152.185) |
| 06:38.55 | oej | Good morning folks |
| 07:12.55 | hwt | JunK-Y: every time, as long as you have a 183 (with SDP) before the final response. |
| 07:30.46 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1006) |
| 07:30.46 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:25.05 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 09:25.05 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 10:49.01 | *** join/#asterisk-dev italorossi (~italoross@187.61.168.117) |
| 11:22.48 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 11:22.48 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 11:25.40 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 12:06.25 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 12:20.51 | *** part/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 12:49.43 | oej | He knew I was trying to reach him... |
| 12:56.11 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-ldymjejqqrwfetrx) |
| 13:18.30 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 13:18.31 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 13:30.20 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-ciecuxhugifbldgf) |
| 13:30.20 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:57.18 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-whzvkhksqwzryhsu) |
| 13:57.19 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:57.19 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:57.33 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-whzvkhksqwzryhsu) |
| 13:57.51 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-whzvkhksqwzryhsu) |
| 13:59.07 | snuff-home | ooh's at new opera with chromium engine.. least they ported the best things over.. mouse gestures by default + their speeddial.. |
| 13:59.59 | file | <3 gestures |
| 14:00.24 | oej | mjordan: Time for some brainstorming? |
| 14:00.52 | snuff-home | my attempt @ cli commands/manager versions is coming along.. slowly.. have a question though. |
| 14:01.01 | oej | or putnopvut? |
| 14:01.44 | snuff-home | what is a 'struct ast_sip_domain' |
| 14:02.09 | oej | I wonder why a SIP specific struct is named ast_ at all? |
| 14:02.25 | oej | ast_ should be reserved for the core api. |
| 14:02.59 | putnopvut | ast_ is used for anything globally reachable. (there are exceptions, such as aco_ and ao2_) |
| 14:03.18 | oej | Is the sip domain now global? |
| 14:03.19 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 14:03.19 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 14:03.57 | file | the functions are globally exported, and the structures in the SIP specific global headers |
| 14:03.58 | snuff-home | as i was saying.. what is 'ast_sip_domain'.. i can find ast_sip_domain_alias .. but no ast_sip_domain.. tis confusing me |
| 14:04.20 | putnopvut | snuff-home: I think that structure might not actually exist. Where did you see it referenced? An old wiki page? |
| 14:04.24 | file | snuff-home, it's from when the structures were initially defined long ago - it hasn't been cleaned up so some stuff still exists that isn't presently relevant |
| 14:04.34 | snuff-home | in ast_sip_endpoint.. |
| 14:04.39 | snuff-home | aka res_sip.h |
| 14:04.46 | putnopvut | ooh, even better :) |
| 14:05.00 | snuff-home | most others have domain as just a stringfield |
| 14:05.59 | snuff-home | (at least ast_sip_transport).. |
| 14:05.59 | putnopvut | Yeah, it probably would be best if we just nixed that pointer for now. |
| 14:06.25 | oej | So how do you handle domains in the gulp channel driver? |
| 14:06.41 | snuff-home | at least i'm not loosing my mind.. did a grep over whole tree.. only 1 ever use of ast_sip_domain |
| 14:07.17 | snuff-home | forgot that you can do a struct like that and get no errors |
| 14:07.50 | file | the domain is part of the unique identifier for endpoints and can be expressed in any object name, with the ability to create aliases |
| 14:08.00 | putnopvut | oej: currently domains are used during endpoint lookup. A string of "user@domain" can be used to uniquely identify an endpoint. |
| 14:08.52 | seanbright | question about chan_pjsip: from reading the -dev list it seems that i shouldn't use chan_pjsip in production until asterisk 13. is that documented someone so the community at large knows that? |
| 14:09.00 | seanbright | somewhere* |
| 14:09.25 | snuff-home | its off by default |
| 14:09.33 | putnopvut | seanbright: currently it's documented on the mailing list :) |
| 14:10.02 | putnopvut | seanbright: but in all honesty, I wouldn't expect any sort of official documentation that says "don't use this" |
| 14:10.10 | seanbright | putnopvut: ah. ok. |
| 14:10.25 | seanbright | but based on my understanding it won't be stable for production use? |
| 14:10.28 | seanbright | or am i confused? |
| 14:10.49 | snuff-home | i would certianly be 'testing' it |
| 14:10.51 | putnopvut | We won't know about stability until people start reporting during the beta |
| 14:11.43 | seanbright | ah. roger that. |
| 14:11.45 | snuff-home | there is course all the 'other' changes happening in 12.. not just new sip module.. |
| 14:14.19 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 14:18.21 | snuff-home | -1 for new chrome based opera.. no tab grouping yet |
| 14:19.40 | oej | seanbright: "stable for production use" is something we avoided setting as a status from the project |
| 14:20.05 | oej | seanbright: It all depends on the situation. 1.8 is slowly getting stable enough for production use on my customer sites |
| 14:20.21 | oej | Experience says it takes time. |
| 14:20.28 | seanbright | oej: do you think you'll have it stable for production in asterisk 13? |
| 14:20.30 | seanbright | i really want to use it |
| 14:20.44 | oej | seanbright: Then go ahead and use it as soon as possible! |
| 14:21.01 | oej | If you use it, report issues and help us developers it will get stable for you much, much faster. |
| 14:21.15 | seanbright | that's great news |
| 14:21.19 | seanbright | thanks for all your hard work! |
| 14:21.37 | oej | Stability doesn't come by sitting in a corner doing development - it comes by getting people to test it. We will do everything we can to get people to run it yesterday... |
| 14:23.39 | seanbright | trust me, i know how much hard work you are putting into it |
| 14:23.41 | snuff-home | hopefully end of week i can post 1st attempt at cli for pjsip transports/endpoints/aors |
| 14:23.46 | seanbright | the community is appreciative |
| 14:25.18 | putnopvut | amen to that |
| 14:32.33 | seanbright | gah... finally catching up on the commit list and i'm now realizing i've misplaced my praise |
| 14:32.42 | seanbright | putnopvut: file: nice work guys! |
| 14:33.53 | mjordan | seanbright: hey now, you wrote one touch recording |
| 14:33.58 | mjordan | seanbright: that was pretty awesome |
| 14:34.03 | mjordan | with tests! |
| 14:34.16 | seanbright | so true |
| 14:34.25 | seanbright | feels good to contribute |
| 14:34.30 | file | kharwell has also done stuff, snuff-home has helped, angler with some tests |
| 14:35.32 | seanbright | it's going to be awesome |
| 14:36.07 | file | oh and that Qwell guy |
| 14:36.17 | seanbright | no one likes him |
| 14:36.29 | seanbright | except for me |
| 15:01.05 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 15:01.05 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 15:19.45 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:19.46 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:33.32 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:46.00 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 15:46.00 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 15:52.05 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 15:52.05 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:25.06 | file | kharwell, I approve of your SIPosity |
| 16:28.52 | kharwell | file: speaking of which, regarding sip qualify - if I observe contacts and say when one is added what is the best way to get the associated endpoint in order to send the options request? |
| 16:29.24 | file | why do you need the endpoint? |
| 16:30.07 | kharwell | I thought I needed an endpoint in order to send a request? |
| 16:30.23 | file | you want to send the qualify to the contact |
| 16:30.44 | kharwell | right so just to the uri |
| 16:30.53 | file | aye |
| 16:31.16 | file | if we don't have a way then there should be one |
| 16:32.17 | kharwell | I'll have to dig around. I was looking at ast_sip_create_request which needs an endpoint or dlg, but also accepted a uri. It won't work for what I need to do |
| 16:33.09 | file | nods |
| 16:34.32 | kharwell | unless I modify it to do a null check on the endpoint for an out of dialog request. That would just skip the selector lookup portion |
| 16:34.59 | file | aye |
| 16:43.48 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 17:36.36 | *** join/#asterisk-dev bklang (~bklang@coquette.alkaloid.net) |
| 17:37.22 | bklang | mjordan: In reading https://wiki.asterisk.org/wiki/display/AST/AMI+1.4+Specification I don't see any specification for valid names for header keys. ANy comment on that? Currently we allow some strange stuff, like key names with spaces |
| 17:38.28 | Qwell | More than [a-zA-Z0-9_-] would be scary. |
| 17:39.54 | bklang | agreed, but stranger things have happened with AMI :) |
| 17:41.10 | bklang | I can't recall seeing any keys with spaces in them, but I don't know if we support this out of an abundance of caution or because someone encountered one once |
| 17:43.01 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:48.00 | mjordan | Hrm. |
| 17:48.15 | mjordan | bklang: when do you allow headers with spaces in them? |
| 17:49.05 | bklang | in AMI Events and Responses |
| 17:49.25 | bklang | Response: Success\r\nExample Header: FooBar\r\n\r\n |
| 17:52.08 | *** join/#asterisk-dev GameGamer43 (uid5533@gateway/web/irccloud.com/x-egwrjtykwgsaomzg) |
| 17:53.45 | bklang | Also, fun fact: initial tests show that we've sped up parsing AMI in Adhearsion by 1640% by switching from Ragel to Regexes. Apparently the Ruby generated by Ragel is *crazy* inefficient. |
| 17:55.27 | *** join/#asterisk-dev tonyclewis (uid6025@gateway/web/irccloud.com/x-inkpdbwyonbujezi) |
| 18:12.44 | leifmadsen | pabelanger: ASTERISK-21828 |
| 18:12.44 | LieutPants | [ASTERISK-21828] [Status: Triage] [patch] app_meetme.so hints load as Unavailable instead of Idle on start up - https://issues.asterisk.org/jira/browse/ASTERISK-21828 |
| 18:12.47 | leifmadsen | fyi |
| 18:13.23 | leifmadsen | that bastard |
| 18:13.40 | Juggie | he does that a lot :) |
| 18:13.52 | leifmadsen | ya, someone needs bip or znc :) |
| 18:14.04 | leifmadsen | Juggie: if you have it setup, you should just give us accounts :) |
| 18:14.06 | Juggie | and its not like he doesnt have linux servers either :P |
| 18:14.23 | Juggie | if you want |
| 18:15.17 | leifmadsen | well the servers aren't the issue :) |
| 18:15.20 | leifmadsen | it's the setting up another application |
| 18:15.24 | leifmadsen | I have a server at Q9 too |
| 18:16.18 | Juggie | the app is the easy part, you just need to configure znc with your nick, channels, irc server, etc |
| 18:16.26 | Juggie | but there is a wizard for that |
| 18:16.40 | mjordan | bklang: sorry, switching between things. The parsing shouldn't care about a space in general, since the key/value pair is ':' delineated. I'd hope client libraries parse it out correctly, but I'd say it's probably safest to not use ' ' in things. I'd probably prefer changing any spaced headers to CamelCase in 12 just to make things nicer. |
| 18:16.46 | mjordan | Also, nice to hear about performance there :-) |
| 18:17.46 | bklang | mjordan: the problem is that there are Results:Follows responses that may contain colons. So it becomes very subjective whether a particular line of response is a Response:Follows body or a heaer |
| 18:17.50 | bklang | header |
| 18:23.34 | *** join/#asterisk-dev Arman (~howlader@117.18.231.50) |
| 18:23.49 | leifmadsen | https://reviewboard.asterisk.org/r/2569/ <-- simple one line review -- not sure the implications on meetme with the change, but seems to work |
| 18:31.23 | mjordan | bklang: which follows responses have colons in the key/value pairs? |
| 18:31.41 | mjordan | although I'd go a bit further to say that the first ':' delineates the key from the value. |
| 18:31.47 | mjordan | (silly AMI syntax) |
| 18:31.55 | bklang | hm, I'm not sure I'm saying this clearly |
| 18:31.59 | bklang | let me find an example |
| 18:33.12 | Qwell | Action: Command |
| 18:33.17 | Qwell | Command: IAX2 show peer <bob> |
| 18:34.09 | Qwell | Response: Follows |
| 18:34.09 | Qwell | <PROTECTED> |
| 18:34.09 | Qwell | etc |
| 18:34.15 | bklang | yep |
| 18:34.20 | bklang | here's one I found: |
| 18:34.22 | bklang | Response: Follows |
| 18:34.22 | bklang | Privilege: Command |
| 18:34.22 | bklang | ActionID: abc123 |
| 18:34.22 | bklang | Number of entries: 0 |
| 18:34.24 | bklang | --END COMMAND-- |
| 18:34.27 | mjordan | sighs |
| 18:34.46 | mjordan | I despise CLI over AMI. |
| 18:34.59 | bklang | if it were URL or otherwise encoded it would be find |
| 18:35.05 | mjordan | We probably need something in there that says everything after a Response: Follows is fair game. |
| 18:35.18 | bklang | the problem is that Response: Follows is not currently always the last header |
| 18:35.18 | mjordan | that worked out great with AsyncAGI :-P |
| 18:35.48 | mjordan | I'll take a closer look at that and come up with something. We modified the ChanVariable nomenclature to not be so wonky, we probably should do something about that as well |
| 18:36.40 | bklang | also, unfortunately we need CLI over AMI in some cases. Like the ConfBridge case where there is a command to kick all non-marked participatns that is not otherwise accessible over AMI |
| 18:36.51 | mjordan | I'd prefer to make an AMI command |
| 18:36.56 | bklang | I would too |
| 18:37.02 | bklang | but it wasn't in Asterisk 1.8 |
| 18:37.17 | mjordan | wow. Living dangerously - ConfBridge pre-10 |
| 18:37.25 | mjordan | bklang: got a list of things you still use CLI commands for? |
| 18:37.37 | bklang | mjordan: it tends to be app-specific but I'll look around |
| 18:37.53 | bklang | I don't believe we do anything with the CLI in the framework core |
| 18:38.07 | mjordan | k. If there's a gap somewhere, I'd prefer to fill it |
| 18:38.19 | bklang | mjordan: also, what problems were there with AsyncAGI responses being URL-encoded? |
| 18:38.30 | bklang | the only thing I remember is the bogus CommandID, but that wasn't an encoding problem |
| 18:38.53 | mjordan | bklang: I wouldn't say it's a problem so much as it's a deterrence to some. People certainly complain about it. |
| 18:39.05 | mjordan | just the fact that they have to unencode it :-) |
| 18:39.15 | bklang | I struggle to understand that complaint |
| 18:39.31 | bklang | or perhaps feel sympathy for it :) |
| 18:39.39 | file | putnopvut, the callerid module is working like a dream |
| 18:40.30 | putnopvut | file: cool beans yo |
| 18:57.49 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 19:10.33 | *** join/#asterisk-dev jameswf (~james@unaffiliated/jameswf-home) |
| 19:11.04 | jameswf | off the top of your heads, have there been any bugs related to ignoring gains? |
| 19:12.25 | file | leifmadsen, erm |
| 19:12.38 | file | leifmadsen, isn't that change a lie? |
| 19:12.53 | leifmadsen | hard to say ;) |
| 19:13.25 | file | hum hum hum |
| 20:12.39 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 20:12.39 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 21:04.01 | Juggie | should possibly be an option to treat dynamic meetme as avail when unknown |
| 21:04.07 | Juggie | but it is indeed 'hard to say' :) |
| 21:12.01 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 21:12.02 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:37.19 | leifmadsen | file: sorry, got pulled into a few meetings |
| 21:37.29 | leifmadsen | file: not sure what you meant by "that change is a lie" |
| 21:37.33 | leifmadsen | it might be :) |
| 21:39.12 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 21:54.37 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-voxbaajribfekwbj) |
| 23:01.19 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 23:01.19 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 23:05.52 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 23:05.52 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 23:17.39 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-ciecuxhugifbldgf) |
| 23:31.43 | *** join/#asterisk-dev snuff-work (~snuffy@110.144.188.126) |
| 23:31.43 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:49.04 | WIMPy | r389378 did indeed break somethign for me, but rather unexpected. Reading the message I'd expected chan_lcr to break, but that still works. |
| 23:49.46 | WIMPy | However I get one-way audio on some sip to sip calls where Asterisk has to transcode. |