| 00:00.04 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 00:13.50 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 01:26.34 | *** join/#asterisk-dev stevePearPear (~stevePear@203.126.171.206) |
| 01:43.05 | *** join/#asterisk-dev stevePearPear (~stevePear@203.126.171.206) |
| 02:20.13 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 02:20.13 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:36.07 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 04:54.56 | *** join/#asterisk-dev tm1000 (tm1000@2600:3c00::f03c:91ff:fe6e:6894) |
| 05:16.03 | *** join/#asterisk-dev stevePearPear (~stevePear@180.255.248.214) |
| 05:40.00 | *** join/#asterisk-dev stevePearPear (~stevePear@171.1.1.187) |
| 05:46.30 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 05:46.30 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 06:14.10 | *** join/#asterisk-dev stevePearPear (~stevePear@180.255.248.214) |
| 06:29.14 | *** join/#asterisk-dev stevePearPear (~stevePear@171.207.120.81) |
| 07:02.55 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:6:f80:224:ed74:c499:e4a1:1584) |
| 07:58.42 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:9cf8:e3a3:4ca5:b8ba) |
| 09:40.56 | *** join/#asterisk-dev stevePearPear (~stevePear@14.100.18.180) |
| 11:07.15 | *** join/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 12:00.21 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-iatadhmiklylhrib) |
| 12:04.12 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:23.35 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-mgxwerawjyfhzvyu) |
| 13:23.35 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:42.08 | mjordan | Qwell: ping |
| 13:43.06 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-pbbsjqkdbzveizal) |
| 13:49.55 | *** join/#asterisk-dev Stefan27 (~Stefan27@212.247.4.149) |
| 13:55.34 | jameswf | http://community.freepbx.org/t/ready-to-call-cisco-sales-last-plea/23789 I'll just leave this here |
| 13:58.54 | blitzrage | jameswf: I got bored of that conversation after about 2 posts |
| 13:59.35 | jameswf | may be all that's needed... |
| 14:00.36 | blitzrage | pretty much |
| 14:00.41 | Marquis42 | Yeah the first mistake is trying to use Cisco phones with anything other than CUCM. |
| 14:00.47 | blitzrage | pretty much |
| 14:00.59 | blitzrage | we're doing it (unfortunately) and it's not trivial |
| 14:00.59 | mjordan | OOooo |
| 14:01.02 | mjordan | I know the patch he wants |
| 14:01.05 | mjordan | that things is a monster |
| 14:01.07 | blitzrage | yes |
| 14:01.09 | blitzrage | we're using it |
| 14:01.10 | blitzrage | it's terrible |
| 14:01.11 | Marquis42 | It's awful |
| 14:01.14 | mjordan | yes, yes it is |
| 14:01.21 | file | I like it when people ask why it hasn't been accepted |
| 14:01.24 | blitzrage | it won't forward port past 1.8.14.1 without significant work |
| 14:01.37 | blitzrage | file: do you silently chuckle to yourself? |
| 14:01.40 | Marquis42 | And not only are the new things awful, it does tons of deckchair-shuffling while it's at it which further complicates it unnecessarily. |
| 14:01.44 | file | and then there are people mentioning segfaults and not workingness |
| 14:01.45 | blitzrage | we have a whole separate build for it |
| 14:01.50 | blitzrage | and don't put anyone but cisco people on it |
| 14:02.11 | blitzrage | we had to remove the DND portion of it because it set DND on the device periodically for no apparently reason :) |
| 14:02.23 | blitzrage | (well there was a reason, but I don't remember the analysis) |
| 14:02.50 | Marquis42 | I'm pretty sure it came down to something like "this code is awful". ;) |
| 14:03.01 | blitzrage | yes |
| 14:03.02 | blitzrage | that sounds right |
| 14:03.09 | blitzrage | the patch is huge for apparently little reason |
| 14:03.17 | blitzrage | other than to rename things in SIP to match Cisco terminology |
| 14:03.43 | blitzrage | anyways yea, it "works" but it makes me ragey every time someone in our company mentions Cisco |
| 14:03.46 | file | I'd be interested in seeing what could be done with it in PJSIP land |
| 14:03.49 | file | but meh |
| 14:03.55 | Marquis42 | Mind you, there's some aspect of the code being awful for the simple reason that there are no genuine specs to go off of. So you have to reverse-engineer the interactions between the phones and Asterisk which is, as always, prone to error. |
| 14:03.55 | blitzrage | but meh indeed |
| 14:04.20 | blitzrage | Marquis42: yea, you can tell it was a patch that was built based on his customers requirements and use cases |
| 14:04.33 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:04.33 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:04.38 | blitzrage | "satisfies requirement; moving on!" |
| 14:05.05 | Marquis42 | aye |
| 14:05.25 | blitzrage | anyways, if he is still learning how to read a SIP trace and generally get Asterisk working, this project has zero hope for him. He really should just buy the CUCM |
| 14:05.29 | Marquis42 | Anyway, I think that horse is well and truly dead (or, unfortunately, undead for us). |
| 14:05.32 | blitzrage | it really isn't worth it |
| 14:05.42 | mjordan | Yay, I commented. |
| 14:05.46 | blitzrage | Marquis42: yes, the undead horse |
| 14:05.51 | mjordan | BEAT IT FURTHER |
| 14:05.56 | file | smacks mjordan |
| 14:06.02 | blitzrage | settle down you |
| 14:08.17 | mjordan | well, I did my public outreach for the day. That was exhausting. |
| 14:08.30 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 14:09.01 | jameswf | Should someone just write chan_ocsic forking chan_sipand call it a day, rather than patching it in to chan_sip if it is that nasty |
| 14:09.46 | mjordan | the problem then is that you don't get any of the patches that chan_sip gets. So if someone fixes a bug, you still have to live with it. |
| 14:09.57 | mjordan | The real problem with that patch is that it made a lot of changes that had nothing to do with the Cisco feature |
| 14:10.11 | jameswf | wonders if the lawyers would get mad about ocsic |
| 14:10.16 | mjordan | so getting it through review is next to impossible. It was attempted once, but there were so many ancillary changes that had findings that we never even got to the Cisco features |
| 14:10.48 | mjordan | and then the patch just sort of died. From the issue, it kind of looks like Gareth threw in the towel as well, which means someone else would have to pick it up and get it cleaned up |
| 14:11.46 | mjordan | jameswf: there's no evidence that those features have licensing issues. Comparing it to the Broadsoft ones, there are specific documents that state that those features are proprietary and have licensing restrictions. We would have to probably investigate it if it ever got that close. Dunno, and right now, don't want to know. |
| 14:13.05 | jameswf | With all the money people pay for Asterisk you guys should really be more willing to play with the hornets nest... |
| 14:18.38 | blitzrage | "all the money" :) |
| 14:56.07 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-fjnlcdwkdsekbzmv) |
| 15:04.18 | *** join/#asterisk-dev otherwiseguy (~otherwise@107.188.208.9) |
| 15:13.49 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:13.49 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:21.16 | pabelanger | Is there any way to merge 2 bridges via ARI? |
| 15:21.31 | pabelanger | I see a BridgeMerged event |
| 15:25.23 | file | no |
| 15:26.00 | pabelanger | boo |
| 15:26.38 | file | you could do it yourself, take out of one put into another |
| 15:26.43 | pabelanger | Ya |
| 15:26.46 | pabelanger | that's what I am doing |
| 16:02.12 | sgriepentrog | could you put a local channel across the two bridges? |
| 16:03.04 | file | yes |
| 16:04.12 | sgriepentrog | And it wouldn't be optimized into a single bridge? |
| 16:04.36 | sgriepentrog | Or would it? |
| 16:04.39 | opticron | no |
| 16:04.55 | opticron | stasis bridges don't allow merges |
| 16:05.06 | sgriepentrog | Ahh. Good to know. |
| 16:05.45 | pabelanger | opticron, how come? |
| 16:09.15 | rmudgett | pabelanger: Because you control the life of bridges |
| 16:09.50 | pabelanger | Ya, thats true. |
| 16:10.05 | pabelanger | If you had a merge function in ARI, then asterisk needs to control the bridge |
| 16:13.03 | rmudgett | For that matter stasis does not allow local channel optimization to its bridges since it needs to control the channels. |
| 16:18.44 | file | CONTROL ALL THE THINGS |
| 16:29.43 | rmudgett | Stasis is a micro-manager |
| 16:39.30 | mjordan | putnopvut: oooo - the testsuite on the 32-bit build agent just hit that locking inversion |
| 16:51.53 | putnopvut | mjordan: yay, I guess |
| 16:52.08 | putnopvut | I probably should just go ahead and commit the fix for that. |
| 16:52.27 | mjordan | I'd be down with that. No sense in letting a deadlock linger |
| 16:57.09 | putnopvut | mjordan: committed! |
| 17:06.39 | putnopvut | So the test failure I'm seeing now in the pjsip/basic_calls/two_party/nominal/alice_initiated/alice_hangs_up appears to be translation path related. |
| 17:06.40 | putnopvut | [Aug 22 08:42:32] WARNING[29880][C-00000003] channel.c: Unable to find a codec translation path from (nothing) to (gsm) |
| 17:06.48 | putnopvut | [Aug 22 08:42:32] WARNING[29880][C-00000003] file.c: Unable to open tt-weasels (format (nothing)): Function not implemented |
| 17:06.56 | putnopvut | So...weird. |
| 17:07.13 | putnopvut | But it's not a scheduler frack now. |
| 17:14.40 | file | hrm |
| 17:14.51 | file | before SDP negotiation takes place what do we place on the channel for formats? |
| 17:15.29 | putnopvut | I donut know. |
| 17:15.44 | file | putnopvut, http://www.carlasconfections.com/2013/07/ferrero-rocher-donuts.html |
| 17:18.13 | jsmith | file: Isn't that a bit rich? |
| 17:18.21 | file | jsmith, probably |
| 17:18.33 | malcolmd | jsmith: they're described that way |
| 17:19.38 | mjordan | pabelanger: I was thinking more about your question. The reason why there is a BridgeMerged event is because you can subscribe to bridges you don't own. |
| 17:19.57 | mjordan | So the only time you would see that is if you had subscribed to a 'normal' mixing bridge that was created by Asterisk, and it got merged at some point |
| 17:20.23 | pabelanger | okayh |
| 17:20.25 | pabelanger | okay* |
| 17:20.26 | pabelanger | thanks |
| 17:20.38 | tm1000 | mjordan: âMy personal opinion (and only my personal opinion): That patch is only necessary if you want Cisco specific features in Asterisk. If what you absolutely require is a Cisco experience, then why wouldn't you buy a Cisco product?â <â LOVE IT |
| 17:20.42 | putnopvut | btw, I'd just like to point out that the warnings I printed earlier are from running the 12 branch, so any format changes for 13 are not affecting things. |
| 17:21.05 | mjordan | putnopvut: whoa. Weird. |
| 17:21.26 | putnopvut | Saw this on reddit today: https://github.com/clearvox/asterisk-dialplan-php |
| 17:21.26 | mjordan | tm1000: Probably because it costs 10 grand and the guy wanted someone else to do the work for him for free, but I wasn't going to say that :-) |
| 17:25.11 | putnopvut | I think the problem may be because SDP negotiation is happening in a separate thread from the PBX thread. So answering the channel queues SDP negotiation/application in a separate thread, so when it comes time to play tt-weasels, negotiation/application is not complete yet, meaning formats are not set properly, meaning the test fails. |
| 17:25.22 | putnopvut | But that's what we in the business call a "guess" |
| 17:25.39 | putnopvut | I have not done the necessary work to determine what the deuce is actually happening. |
| 17:26.09 | file | putnopvut, that's what I'd wager on as well |
| 17:28.39 | Juggie | lol funny, like 10 years ago Qwell took a stab at php and asterisk dialplan |
| 17:28.48 | Juggie | but he ran into issues, i dont recall what they were |
| 17:29.01 | Qwell | not I |
| 17:29.19 | Juggie | hmmmm |
| 17:29.24 | Juggie | who was it then, seanbright maybe? |
| 17:29.37 | Juggie | it was on 1.0 or 1.2 |
| 17:29.37 | Qwell | Maybe. He was a PHP developer at one time, IIRC. |
| 17:53.42 | seanbright | PHP and asterisk dialplan? that was not me |
| 17:53.57 | seanbright | Qwell: once a PHP developer, always a PHP developer |
| 17:54.52 | Qwell | s/developer/contributor/? |
| 17:55.04 | seanbright | like 1000 years ago |
| 17:55.14 | Qwell | That's the one I meant. |
| 17:55.21 | seanbright | ah |
| 17:55.38 | seanbright | if you ever used get_meta_tags() in php... you're welcome |
| 18:44.55 | blitzrage | people use php? |
| 18:45.27 | Marquis42 | Unfortunately they still do, yes. |
| 18:45.40 | Marquis42 | I have to admit I'm one of the culprits in years past. |
| 18:46.39 | blitzrage | I've used php certainly |
| 18:46.49 | blitzrage | but not in the last half decade |
| 18:47.50 | Marquis42 | heh |
| 19:09.14 | jsmith | still uses some PHP from time to time... |
| 19:10.08 | pabelanger | I have an old autodialer still running I wrote with PHP |
| 19:10.19 | pabelanger | I think I used zend framework for a lot of it |
| 19:34.58 | blitzrage | wow |
| 19:35.04 | blitzrage | that brings back memories :) |
| 19:35.21 | blitzrage | I could actually "compile" your php code with zend too to make it so you could distribute it as a blob that couldn't be read directly |
| 19:37.13 | pabelanger | there was that |
| 19:37.25 | pabelanger | but it also optimized the code and ran it faster in some cases |
| 19:37.32 | pabelanger | better garbage handlers too |
| 19:44.54 | blitzrage | better than java even? |
| 19:45.30 | Qwell | blitzrage: The C garbage handler is better than Java. |
| 19:47.18 | Marquis42 | Pretty much anything is better than anything Java. ;) |
| 19:47.29 | Marquis42 | Not that I'm prejudiced against java or anything... :D |
| 19:47.33 | blitzrage | I was totallly trolling |
| 20:25.36 | mjordan | opticron: did you commit your rest-api blind transfer bridge patch? |
| 20:25.52 | opticron | I did |
| 20:25.54 | opticron | earlier today |
| 20:26.02 | mjordan | cool. I should have just looked ;-) |
| 20:29.31 | jrose_atDigium | putnopvut: Started on off-nominal tests for RLS lists/presence and ran into my first failure. https://wiki.asterisk.org/wiki/display/AST/Resource+List+Subscription+Test+Plan -- on Off-nominal test 1, not including the Supported: eventlist header still resulted in a 200 OK instead of a 421... where would the code to check the Supported header be? |
| 20:31.23 | *** join/#asterisk-dev otherwiseguy (~otherwise@107.188.208.9) |
| 20:38.59 | wedhorn | anyone know if there's a way to add a format into a specific spot in the preference order? If not, is it something that may be wanted? |
| 20:39.45 | putnopvut | jrose_atDigium: Hm, probably build_resource_tree() would be the place to do it. It's probably best to alter build_resource_tree() to take a parameter indicating if resource lists are supported. So any place that calls build_resource_tree can check for the supported: eventlist before calling build_resource_tree() |
| 21:00.17 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:11.44 | rmudgett | wedhorn: v13 allows that. It is the order you add codecs with the allow= lines. |
| 21:17.33 | wedhorn | rmudgett: I mean other than that, eg, add a codec to the beginning of the preference list |
| 21:18.48 | wedhorn | an example could be, allow=!all,ulaw,alaw in the general section, and then something like, allow_at_beginning=g729 with a result that the order would be g729,ulaw,alaw |
| 21:21.03 | rmudgett | Ok. That is definitely not currently supported. You would need to rebuild the list as allow=!all,g729,ulaw,alaw |
| 21:24.11 | wedhorn | yep, that is what I thought, so the question is, do we want it, it seems like it would be fairly easy to implement |
| 21:47.06 | rmudgett | I'm not sure it's that good of an idea. What if your config is in a database? Ordering would not be possible. |
| 21:48.11 | wedhorn | why not? |
| 21:48.31 | wedhorn | regarding the database |
| 21:49.46 | rmudgett | Pulling the config lines out of the database results unpredictable ordering of the lines. |
| 21:50.20 | rmudgett | This is why the allow lines are comma separated lists |
| 21:50.41 | wedhorn | ah, okay, been pondering further and how about a syntax like : allow=begin,g729 to prepend rather than append |
| 21:51.19 | mjordan | wedhorn: Just curious - why is that needed? Is it simply a convenience mechanism so you don't have to put g729 on all of your allow lists? |
| 21:52.38 | rmudgett | doing an allow=begin,g729 still implies that you have multiple allow= lines |
| 21:52.50 | wedhorn | mjordan: trying to fix up the codec mess in Skinny and have a situation where we can allow/disallow at 3 different levels (general, device and line). Just trying to think through what would be the best way in handling it |
| 21:53.13 | wedhorn | rmudgett: yes, but in different areas, eg, one in general, one for the specific endpoint |
| 21:54.29 | mjordan | wedhorn: generally, I think the way that gets handled in chan_sip (which is the closest example for something else that uses that pattern) is to override the general setting if a device/peer/whatever specifies an allow list |
| 21:54.34 | mjordan | or rather, if I have: |
| 21:54.40 | mjordan | [general] allow=g729 |
| 21:54.46 | mjordan | [device] allow=ulaw |
| 21:54.51 | mjordan | it would result in g729,ulaw |
| 21:54.58 | mjordan | but if I have: |
| 21:55.02 | mjordan | [general] allow=g729 |
| 21:55.10 | mjordan | [device] disallow=all; allow=ulaw |
| 21:55.13 | mjordan | it would only have ulaw |
| 21:55.25 | mjordan | to do what you're thinking about, the disallow would also have to be in the general section |
| 21:57.08 | wedhorn | is confused |
| 21:57.25 | mjordan | runs to pastebin |
| 21:57.30 | wedhorn | not sure I get what you mean by the disallow in the general section |
| 21:58.08 | mjordan | disallows/allows are usually cumulative. |
| 21:58.23 | mjordan | Where a disallow=all negates all previous additions to the format list. |
| 21:58.36 | mjordan | The default is to allow all (which is arguably silly, but oh well) |
| 21:59.04 | mjordan | So: assuming that your devices/lines pull in from the general section, the general section should be the place that disallows all |
| 21:59.06 | wedhorn | yep, okay, I think we may have wires crossed |
| 21:59.12 | mjordan | quite possible! |
| 21:59.44 | mjordan | goes back and re-reads |
| 22:00.00 | wedhorn | I would like something like [general] allow=!all,ulaw,alaw [device] allow=begin,g729 which would result in (g729,ulaw,alaw) |
| 22:00.04 | mjordan | ah. |
| 22:00.10 | mjordan | I had the order backwards. |
| 22:00.41 | mjordan | I'd say it should probably just be a separate option in chan_skinny, if you want it. |
| 22:00.48 | mjordan | allow_prepend=g729 |
| 22:00.51 | mjordan | or something like that |
| 22:01.23 | wedhorn | mjordan: arguably it's easier to implement in format_cap.c (and would then become available to everyone) |
| 22:02.02 | wedhorn | basically I'd need to duplicate a lot of format_cap.c in chan_skinny to handle it their |
| 22:03.18 | mjordan | Hm. |
| 22:03.35 | mjordan | format_cap in 13 already has a way to take a single format and put it at the front of a capability structure. |
| 22:03.47 | mjordan | granted, it's (I think) one or two API calls to do that |
| 22:04.06 | mjordan | I think you're going to find that creating a fool proof syntax for allow will be challenging |
| 22:04.22 | mjordan | Probably worth posting to asterisk-dev when you have a proposal |
| 22:04.33 | wedhorn | yeah, am aware of the syntax issue |
| 22:05.39 | wedhorn | at the moment am considering something like: everything on a line after the begin is prepended in the order presented |
| 22:16.23 | wedhorn | mjordan: where in format_cap can I find the code that puts the format at the front |
| 23:05.31 | *** join/#asterisk-dev terryw (~otherwise@107.188.208.9) |
| 23:09.23 | rmudgett | wedhorn: I think mjordan was thinking of iax2_codec_pref_prepend() which is in chan_iax compatibility code channels/iax2/codec_pref.c. |
| 23:10.23 | wedhorn | rmudgett: thanks, will take a look |
| 23:10.48 | rmudgett | wedhorn: It's chan_iax specific though. |
| 23:11.01 | wedhorn | okay, just collecting ideas at the moment |
| 23:26.11 | file | you can indirectly do it with what is available by constructing a new format cap |
| 23:40.52 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-pbbsjqkdbzveizal) |
| 23:44.52 | wedhorn | file: yeah, forgot about that approach, i've seen that in some of the codec negotiation stuff |
| 23:51.40 | *** join/#asterisk-dev tzafrir (~tzafrir@host-201-73.pubnet.pdx.edu) |
| 23:51.54 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |