| 00:11.46 | *** join/#asterisk-dev Fwny (~potato@CPE602ad078701a-CM602ad0787017.cpe.net.cable.rogers.com) |
| 00:31.21 | X-Rob | wedhorn: I match if the call to be dialed starts with PJSIP, and if it does, I use the results of PJSIP_DIAL_CONTACTS. |
| 00:33.40 | *** join/#asterisk-dev mjordan (~matt@75.76.55.191) |
| 00:33.40 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 00:34.34 | wedhorn | X-Rob: thanks, was more interested in the underlying philosophy rather than any practical implementation. I think it was a post of yours that made me aware of this in the first place |
| 00:35.09 | mjordan | we are not set up to handle 20 F in AL |
| 00:35.20 | X-Rob | There's no F in AL. |
| 00:35.28 | X-Rob | .. ok that was a lame joke |
| 00:35.31 | X-Rob | ignore me. |
| 00:35.32 | mjordan | I laughed |
| 00:36.28 | mjordan | protip: single pane windows are an effective medium for heat transfer |
| 00:58.38 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 01:19.19 | *** join/#asterisk-dev dfighter (~someone@arcemu/staff/dfighter) |
| 01:19.50 | *** join/#asterisk-dev ehsjoar (~jonas@c-24-9-87-13.hsd1.co.comcast.net) |
| 01:32.42 | *** join/#asterisk-dev roderickm (~roderickm@99-124-89-102.lightspeed.dctral.sbcglobal.net) |
| 05:25.13 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.6) |
| 05:56.51 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.6) |
| 05:57.28 | *** join/#asterisk-dev vlad_starkov (~vlad_star@91.206.59.135) |
| 06:34.12 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:437:ce01:2677:3ff:fe8f:2730) |
| 07:00.29 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.158) |
| 08:18.18 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.218.175.34) |
| 08:23.11 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@195.218.175.34) |
| 08:41.08 | *** join/#asterisk-dev hehol (~Adium@2a01:198:71d:0:181d:3eb4:6344:b664) |
| 09:11.22 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 09:16.18 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.218.175.34) |
| 09:28.50 | *** join/#asterisk-dev oej (~Adium@h217-27-188-82.cust.tyfon.se) |
| 09:28.50 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:37.04 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 10:18.08 | *** join/#asterisk-dev Jacke (~jacke@iam.ss7.pl) |
| 10:19.59 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.218.175.34) |
| 10:57.45 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:a482:957f:a71b:947d) |
| 11:32.25 | *** join/#asterisk-dev roderickm (~roderickm@99-124-89-102.lightspeed.dctral.sbcglobal.net) |
| 11:42.42 | *** join/#asterisk-dev oej (~Adium@h217-27-188-82.cust.tyfon.se) |
| 11:42.43 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:47.07 | *** join/#asterisk-dev przemoc (~przemoc@unaffiliated/przemoc) |
| 11:54.49 | przemoc | hello. I have questions regarding Asterisk 12/12. In wiki we can read that "Due to the scope of Asterisk 12, the project will be altering the "no new features in release branches" policy for this version only." Do you expect any nice improvements that won't meet criteria outlined in https://wiki.asterisk.org/wiki/display/AST/Software+Configuration+Management+Policies? Is assumption that 13 won't differ substantially from 12 true? How ... |
| 11:54.55 | przemoc | ... safe it would be to depend upon trunk instead of 12? Are there any disruptive changes planned? Or would it be better to depend on branch 12 till 13 will be created? |
| 11:55.07 | przemoc | s/12\/12/12\/13/ |
| 11:55.33 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.211) |
| 11:56.36 | file | I wouldn't depend on it, trunk is trunk. It also depends on how disruptive you mean. |
| 12:08.40 | przemoc | from quick grepping git log's output (after 21 hours of conversion) I've seen that trunk had some things broken when new APIs were introduced (like bridging API) and fixed some time later. |
| 12:11.16 | przemoc | or maybe it was something different than bridging API, not sure now... anyway, from reading the log I got the impression that Asterisk's features were sometimes reduced to be fixed sometime later. |
| 12:14.19 | przemoc | watching git log is maybe not the best view into the development process, but do Asterisk devs use branches for bigger changes so that their merged to trunk only when feature is ready. |
| 12:14.34 | przemoc | s/their/they're/ |
| 12:14.48 | przemoc | s/\.$/?/ |
| 12:14.51 | file | yes. |
| 12:15.11 | przemoc | so theoretically trunk should be stable all the time, right? |
| 12:15.37 | file | stable is relative, it is not used/tested as much by people |
| 12:15.53 | coreyf1513 | przemoc: things are merged to trunk when they are ready for trunk. that is not the same as ready for production |
| 12:18.15 | przemoc | ok, so allow me to repeat here the question I asked on #asterisk |
| 12:18.48 | przemoc | I have a question regarding development/release cycle for Asterisk 13 LTS. Feature freeze is exepected in July. Is it a point when the branch for 13 will be created? First release is expected in October. Will it be the first official Asterisk 13 release? Looking at 12 I've seen the branch created in late August, after feature freeze and much before first release. |
| 12:19.24 | file | I can't answer when it'll happen because it depends on the future |
| 12:20.00 | przemoc | ok, but maybe you can answer what happened during 12? |
| 12:20.18 | *** join/#asterisk-dev elred_ (~elred_@unaffiliated/elred-/x-5010831) |
| 12:20.47 | przemoc | I'm asking about the process, not the exact dates here |
| 12:21.54 | file | https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions that describes expected dates |
| 12:23.25 | przemoc | I read that already. I still don't know when 13 branch is expected to be created. That's why I'm asking about how it went with 12. |
| 12:24.13 | file | I do not remember. |
| 12:25.57 | file | 12 was a bit of an anomaly too because we did so much work |
| 12:28.13 | przemoc | ok. so normally, is new branch created around feature freeze (July)? |
| 12:32.08 | file | przemoc, I would suggest waiting for mjordan to appear in a bit |
| 12:36.04 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 12:53.45 | *** join/#asterisk-dev mjordan (~matt@75.76.55.191) |
| 12:53.45 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:53.57 | file | tada! |
| 12:54.13 | file | mjordan, can you help przemoc with when we branch new versions/releases/etc? |
| 12:54.34 | mjordan | ? |
| 12:54.57 | przemoc | I want to get some information regarding development process within Asterisk. |
| 12:55.25 | mjordan | what questions do you have specifically? |
| 12:56.03 | mjordan | Most of our policies/procedures are documented (in some fashion) on wiki.asterisk.org |
| 12:56.13 | przemoc | I had a few, some of them were more or less answered, but not all of them. |
| 12:56.18 | mjordan | I'm the first to admit that they need a bit of TLC |
| 12:56.45 | mjordan | ask away! I'll give it a shot at least |
| 12:56.46 | przemoc | I don't see information about when branch for release is created. |
| 12:56.54 | przemoc | I mean branch in svn, like 13 |
| 12:56.55 | mjordan | ah. |
| 12:57.07 | mjordan | That's somewhat arbitrary, actually. It occurs after feature freeze, but there is no set date |
| 12:57.35 | mjordan | typically it occurs when feature freeze hits and all patches that are well reviewed that were put up for review before feature freeze have been merged |
| 12:57.48 | mjordan | You can see the feature freeze date here: https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions |
| 12:58.02 | mjordan | 3rd Wednesday of July, on a yearly basis |
| 12:58.18 | przemoc | yeah, I checked it already. But I looked at 12 and it wasn't matching. |
| 12:58.29 | przemoc | branch for 12 was created in late August |
| 12:59.20 | mjordan | yup! We try to be flexible. In this case, a *lot* happened in 12, and we asked (and received) some extra time to clean everything up |
| 12:59.21 | mjordan | http://wap.sineapps.com/news.php?rssid=2752 |
| 12:59.21 | przemoc | but file explained, that 12 was special and had its anomalies |
| 12:59.34 | mjordan | policies are good, but policies that make you do bad things are not |
| 12:59.42 | mjordan | policies are there to guide, not constrain. |
| 12:59.48 | mjordan | (That's my philosophy, at any rate) |
| 12:59.50 | przemoc | I agree wholeheartedly |
| 13:00.17 | mjordan | we try hard to follow everything we write down, and when we bend the rules, we try to make sure everyone is okay with and knows why |
| 13:00.18 | przemoc | ok, so branching is shortly after feature freeze if anything goes well, one may say |
| 13:00.22 | mjordan | yup |
| 13:01.56 | przemoc | let me reask some questions that I asked here before you joined, just to get another view (maybe same, maybe differing) on matters |
| 13:02.09 | mjordan | hopes he gives the same answers as file |
| 13:02.24 | file | grins |
| 13:02.36 | file | I defer to mjordan in such matters regardless :P |
| 13:02.41 | mjordan | crap. |
| 13:02.55 | mjordan | looks for someone to blame |
| 13:03.08 | mjordan | quick! I need a fall guy! |
| 13:03.10 | przemoc | In wiki we can read that "Due to the scope of Asterisk 12, the project will be altering the "no new features in release branches" policy for this version only." Do you expect any nice improvements that won't meet criteria outlined in https://wiki.asterisk.org/wiki/display/AST/Software+Configuration+Management+Policies? Is assumption that 13 won't differ substantially from 12 true? How safe it would be to depend upon trunk instead of ... |
| 13:03.16 | przemoc | ... 12? Are there any disruptive changes planned? Or would it be better to depend on branch 12 till 13 will be created? |
| 13:03.22 | mjordan | heh |
| 13:03.37 | mjordan | so yes, I expect that some nice improvements will be made that will go into trunk instead of 12 |
| 13:04.42 | mjordan | the features that are allowed under that policy have to be made in relation to the purpose of 12, that is, a new SIP stack and improved APIs. That is, admittedly, inherently subjective - so when there is major doubt, we're going to roll things in trunk. This is one of those times when it's a good idea to remember why we made that policy |
| 13:05.00 | mjordan | if what is being added is needed for people to continue their engineering effort on top of 12, then it should be considered for 12 |
| 13:05.20 | mjordan | if, however, it is a nice new feature or improvement but isn't critical for someone to continue developing on 12, it should be considered for trunk |
| 13:05.35 | mjordan | 12, by it's nature, is a bit of a moving target - but I'd like that to be as painless as possible still |
| 13:06.01 | mjordan | as far as disruptive changes are concerned, that depends on what you mean by disruptive. If you're using 12, you'll want to make sure you read all of the release notes :-) |
| 13:06.22 | mjordan | I would view 13 as the refined version of 12 |
| 13:06.49 | przemoc | I see. regarding improvements: Can you name such of them already? Roadmap is quite vague at least I would say... |
| 13:07.08 | mjordan | Well, smallish features don't go on the roadmap |
| 13:07.40 | mjordan | A few new features have been added to ConfBridge |
| 13:07.50 | mjordan | A new channel variable for the Directory application |
| 13:08.03 | mjordan | basically, things that make people's lives a bit nicer, but no, nothing large yet. |
| 13:08.11 | mjordan | On the roadmap, you can see file's media work |
| 13:08.20 | mjordan | which is to improve performance |
| 13:09.42 | mjordan | But the roadmap is, admittedly, in progress. The goal of 13 is to round out the SIP work and the APIs, and stabilize the version for a LTS release. Currently, no one has proposed a major feature to the SIP work, although some have been talked about |
| 13:09.43 | przemoc | I don't see anything mentioning file's media work on the roadmap, or I'm looking at the wrong page. |
| 13:10.06 | mjordan | It's a subpage off of here: |
| 13:10.06 | mjordan | https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Projects |
| 13:10.14 | mjordan | major project get their own page :-) |
| 13:10.17 | mjordan | projects |
| 13:10.36 | mjordan | that's still a bit in draft form; I have a lot of tests to add to it |
| 13:11.13 | przemoc | Ok, I suggest adding links to these Projects pages from Roadmap page in future. |
| 13:11.27 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 13:13.56 | mjordan | You may also want to look at the notes from AstriDevCon. Admittedly, they are notes - but a lot of what we are going to do gets hashed out at that conference |
| 13:13.56 | mjordan | https://wiki.asterisk.org/wiki/display/AST/AstriDevCon+2013 |
| 13:14.27 | przemoc | media format rewrite doesn't seem like minor thing. anyone working around format/codec stuff will have to pay attention to changes regarding it, because switching to 13 may not be painless after all. ;) |
| 13:15.03 | mjordan | it isn't minor, but the performance impact is major. Hence the need to do it. (Also why we're testing the crap out of it) |
| 13:17.29 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:17.50 | przemoc | Damn, it may be nice thing from user PoV, but less nice from dev PoV that would depend on 12 for now. is any work started on it already? is there any rouch ETA for having it in trunk? |
| 13:19.03 | file | there is a branch with some of the design implemented but nothing within the core has been transitioned to it |
| 13:19.41 | mjordan | and this gets back to that age old question: do you risk perturbing the existing users of 12, or do you go with trunk? Not sure yet. |
| 13:19.58 | mjordan | I'm sure it will be a lively discussion on the -dev list when it comes time to cross that bridge. |
| 13:20.10 | file | mjordan, SQUIRREL! |
| 13:20.17 | mjordan | exactly |
| 13:20.55 | *** join/#asterisk-dev protocoldoug (~doug@unaffiliated/protocoldoug) |
| 13:23.02 | przemoc | 13 is LTS, so there is some temptation to aim for it. What a pity that this media format rewrire didn't happen in 12 already. ;) |
| 13:23.27 | mjordan | heh |
| 13:23.35 | mjordan | only so many developers, only so much time |
| 13:23.42 | file | I can't work 24 hours a day. |
| 13:23.47 | przemoc | we all know this problem |
| 13:23.48 | mjordan | file: I demand 20 |
| 13:23.51 | przemoc | :) |
| 13:23.59 | mjordan | bbiab |
| 13:24.01 | file | mjordan, SQUIRREL! |
| 13:24.01 | *** part/#asterisk-dev mjordan (~matt@75.76.55.191) |
| 13:25.41 | przemoc | Ok, I know a bit more now. Wasn't fast enough only to thank mjordan for this friendly and informative chat here. |
| 13:36.24 | file | Friday! yay! |
| 13:44.45 | *** join/#asterisk-dev dfighter (~someone@arcemu/staff/dfighter) |
| 13:46.10 | *** join/#asterisk-dev thecardsmith (~doug@unaffiliated/protocoldoug) |
| 13:57.46 | *** join/#asterisk-dev dwayne (~dwayne@c-71-207-208-112.hsd1.al.comcast.net) |
| 13:59.35 | *** join/#asterisk-dev chazzam (~chazz@donutokyo.info) |
| 14:02.37 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 14:25.46 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:25.46 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:46.47 | *** join/#asterisk-dev ehsjoar (~jonas@c-24-9-87-13.hsd1.co.comcast.net) |
| 14:52.29 | *** join/#asterisk-dev scouture (~scouture@unaffiliated/scouture) |
| 15:03.09 | leedm777 | danjenkins: so, about those wiki update scripts. |
| 15:03.17 | danjenkins | indeed |
| 15:03.27 | danjenkins | so should they ever talk to thw iki do you think |
| 15:03.42 | leedm777 | The answer is 'it depends' |
| 15:03.47 | danjenkins | and if they do need to, to do formatting, should there be an anon user that can do it but not update the wiki |
| 15:04.07 | leedm777 | there are actually three scripts there. |
| 15:04.22 | *** join/#asterisk-dev mjordan (~matt@nat/digium/x-uauzctcoujxcfeyt) |
| 15:04.22 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:04.29 | danjenkins | which would be fine, but as soon as i see credentials and it trying to talk to the wiki, i dont want to screw anything up |
| 15:04.31 | leedm777 | There's our original astxml2wiki script, which is an old pile of Python that's been hacked through the ages. |
| 15:04.40 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:04.40 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:05.03 | leedm777 | There's the publish-rest-api.py, which is a newer pile of python that's only bee hacked for a few months. |
| 15:05.18 | danjenkins | which is the thing that actually does the talking to the api ? |
| 15:05.21 | leedm777 | And then there's the publish script which wraps up both of them. |
| 15:05.30 | danjenkins | yes |
| 15:05.55 | leedm777 | danjenkins: they both do. when you run the publish script, it tries to generate docs for both the rest API and the XML docs. |
| 15:06.40 | danjenkins | but i dont see anything in astxml2wiki.py that talks to confluence |
| 15:07.31 | danjenkins | looks like rest-api has nothing to do with the ari |
| 15:07.39 | leedm777 | danjenkins: self.s = Server(self.args['server']) |
| 15:07.40 | danjenkins | and it just talks to confluence |
| 15:07.46 | danjenkins | oohhhh ok |
| 15:07.49 | leedm777 | ^^ builds an XML-RPC client for talking to confluence. |
| 15:07.50 | danjenkins | got you |
| 15:08.24 | leedm777 | Yeah, they work differently. |
| 15:08.28 | danjenkins | i see now |
| 15:08.56 | leedm777 | The ARI wiki docs are generated when you run 'make ari-stubs' |
| 15:09.16 | *** join/#asterisk-dev otherwiseguy (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 15:09.28 | leedm777 | So the publish-rest-api just needs to publish the generate wiki files. |
| 15:09.49 | danjenkins | ah right ok |
| 15:09.53 | leedm777 | But astxml2wiki does the dual job of 1) converting the XML doc to wiki format and 2) publishing that to Confluence. |
| 15:10.15 | danjenkins | so i want to change the AMI event page generation |
| 15:10.36 | leedm777 | That's in astxml2wiki.py (and the corresponding astxml2wiki.xslt) |
| 15:11.02 | danjenkins | but whats stopping joe bloggs contributing to this without fear of doing damage to the wiki |
| 15:11.02 | leedm777 | And you're better off calling astxml2wiki directly, so you can pass in the --debug flag |
| 15:11.26 | danjenkins | is if we make publish accept and pass on debug |
| 15:11.53 | danjenkins | and also get an anon wiki user which can talk to the converter but not publish |
| 15:12.13 | danjenkins | OR none of the above and i could just use astxml2wiki or whatever directly and put in my patch that i care about |
| 15:12.20 | danjenkins | ;) |
| 15:12.31 | *** join/#asterisk-dev scouture (~scouture@unaffiliated/scouture) |
| 15:13.37 | leedm777 | The publish script is really there just so the CI server has a single script to run to update all of the docs. |
| 15:14.39 | leedm777 | If you want to test your changes, just run the publish-rest-api or astxml2wiki scripts individually, with the --diff or --debug flags. |
| 15:14.54 | danjenkins | ok, ill do that |
| 15:15.34 | leedm777 | If you use --diff, it won't update anything on the wiki. |
| 15:17.10 | danjenkins | :D thanks leedm777 |
| 15:17.17 | danjenkins | this is all going on the README |
| 15:17.17 | leedm777 | Any time. |
| 15:18.45 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-xhidpjjnzwgnkzcf) |
| 15:22.23 | danjenkins | woohoo its compiling asterisk - it got further! |
| 15:46.09 | scouture | hey guys. could anyone take a quick look at https://issues.asterisk.org/jira/browse/ASTERISK-18411 and suggest how we go about troubleshooting the issue (compile flag, tool, etc.)? the issue is easily reproducible in a development environment, so it's really just a matter of being able to figure out what Asterisk is doing when it happens. |
| 15:48.17 | scouture | also.. even though 'affected version' says 1.8.5.0, we're seeing the same issue under 11.7.0. |
| 15:49.52 | putnopvut | scouture: Hi Sebastien! Unfortunately, aside from debug logs I don't know of any other options that would help pinpoint the problem. The comment about being able to reproduce by performing a reload is a huge help though. |
| 15:51.04 | mjordan | realtime queue members :-( |
| 15:51.24 | file | mjordan, something that never should have existed |
| 15:51.35 | mjordan | file: or at least, not implemented the way that it was |
| 15:51.51 | putnopvut | Well, I don't think that's the core issue here. He's using a state interface that is a hint in the dialplan, and that's what's reporting incorrectly |
| 15:52.11 | putnopvut | Or maybe that is the issue. I don't know actually. |
| 15:52.33 | mjordan | I suspect it is a problem with RealTime |
| 15:53.04 | mjordan | FreePBX uses Local channel members and performs a lot of reloads... if this was happening with non-RealTime members, I'd imagine it'd be getting a lot more traffic |
| 15:53.45 | scouture | mjordan: do you know if it uses the local channel's state, or an underlying hint state as the agent's state? |
| 15:53.52 | scouture | (in FreePBX, that is) |
| 15:54.10 | mjordan | I'm not sure, unfortunately |
| 15:54.22 | mjordan | tm1000 or Gamegamer43 would most likely know :-) |
| 15:57.05 | scouture | I guess I could try to see if we're seeing the same issue when using the Local channel's state in Realtime, as well as using an hint state_interface when the member is added dynamically through the CLI |
| 15:57.22 | scouture | that would narrow it down a bit |
| 15:58.03 | GameGamer43 | I'm pretty sure it's using hint states |
| 16:06.20 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:a482:957f:a71b:947d) |
| 16:22.04 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:22.21 | *** part/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 16:29.12 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 16:29.12 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 16:42.15 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 16:48.13 | *** join/#asterisk-dev elred_ (~elred_@unaffiliated/elred-/x-5010831) |
| 16:58.09 | *** join/#asterisk-dev JeffC_NN (~jcollell@mail.nownerd.com) |
| 17:09.33 | file | mjordan, I'm torn on my original format_cap proposal |
| 17:11.00 | file | specifically because if we get to the point where we allow multiple formats with the same underlying codec it complicates things |
| 17:13.24 | mjordan | file: are there any codecs that do that? |
| 17:13.29 | sgriepentrog | file: when building sdp, just eliminate duplicate media codes? |
| 17:13.32 | file | H264 |
| 17:14.24 | file | that's sort of a problem right now... if we get an SDP offer with multiple H264 (with differing attributes) we only accept one |
| 17:21.03 | pabelanger | Have we consider using an SDP library over writing our own parsers? |
| 17:21.30 | *** join/#asterisk-dev basssie90 (~basssie90@5ED2711E.cm-7-3b.dynamic.ziggo.nl) |
| 17:21.33 | file | chan_pjsip does, but that has nothing to do with the problem |
| 17:21.38 | pabelanger | ok |
| 17:21.47 | pabelanger | that's what I figured |
| 17:25.51 | mjordan | file: I think we want to draw the line at multiple media streams of the same type. Not that it wouldn't be cool, but that feels like Asterisk 14 kinda work |
| 17:26.10 | file | it's not multiple media streams |
| 17:26.27 | mjordan | single stream, multiple H264 formats? |
| 17:26.29 | file | it's one video stream, but multiple H264 codecs with differing attributes |
| 17:26.33 | mjordan | ah |
| 17:26.53 | file | that's what I don't want to box myself into a corner with... as I'd like to eventually fix that |
| 17:27.16 | skrusty | is there an rss feed for dev announcements? |
| 17:27.26 | mjordan | skrusty: what kind of announcements? |
| 17:27.33 | datachomper | this is file https://www.clearlycanadian.com/images/home/bottles-small.jpg |
| 17:27.34 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.48) |
| 17:27.36 | file | hum, I could still use the vector off the codec id but make a primitive internal linked list |
| 17:27.45 | skrusty | releases etc, anything considered of general value? :) |
| 17:27.47 | file | datachomper, I remember that stuff! |
| 17:27.53 | mjordan | file: yeah, I don't see any way around making the codec have a 1 to n relationship with formats |
| 17:28.10 | mjordan | skrusty: releases have an RSS feed off of the news section on asterisk.org |
| 17:28.16 | skrusty | hmm |
| 17:28.19 | mjordan | skrusty: And there are RSS feeds for any of the Atlassian services |
| 17:28.24 | mjordan | but most things are just sent to the -dev list |
| 17:28.28 | skrusty | yeah |
| 17:28.35 | file | I also have a Twitter account, AsteriskDev, where I post relevant stuff |
| 17:29.22 | skrusty | as it's friday, and i am bored, i was doing a little experiment with rss aggregation, trying to make a better news site for asterisk: http://asterisktimes.xdev.net |
| 17:30.23 | file | mjordan, I was iffy about that but I take it back... I can wrap the formats in a struct with packetization, and still use a vector for preference order |
| 17:30.52 | file | for almost all cases it'll be a direct index into the array |
| 17:36.43 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.48) |
| 17:37.12 | *** join/#asterisk-dev vlad_starkov (~vlad_star@91.206.59.134) |
| 17:37.32 | mjordan | skrusty: pretty |
| 17:38.06 | mjordan | looks like you got the digium blog and the news announcements... |
| 17:38.13 | file | very pretty indeed |
| 17:54.23 | *** join/#asterisk-dev scouture (~scouture@unaffiliated/scouture) |
| 18:20.26 | tm1000 | mjordan: ping |
| 18:22.00 | tm1000 | file: ping (actually need you) |
| 18:22.13 | file | tm1000, hi |
| 18:22.33 | tm1000 | file: So in PJSIP, there is no such thing as a registration string? |
| 18:22.38 | file | there isn't |
| 18:22.42 | tm1000 | ok. |
| 18:22.53 | file | it's encapsulated in a registration object |
| 18:23.23 | tm1000 | so we have a question from a former form user, they had a registration string whereas they had to also attach their DID to the registration string |
| 18:23.54 | file | use contact_user=<name/DID> |
| 18:24.43 | tm1000 | file: what if they have multiple |
| 18:24.52 | tm1000 | <name/DID>,<name/DID>,<name/DID>,<name/DID>? |
| 18:25.01 | tm1000 | (multiple DIDs) |
| 18:25.01 | file | you can only specify one contact user |
| 18:25.12 | file | you can have multiple outgoing registrations, though |
| 18:25.24 | file | each with a different named section and different contact_user |
| 18:25.38 | *** join/#asterisk-dev Pullphinger (~Pullphing@c-24-13-69-42.hsd1.il.comcast.net) |
| 18:26.33 | tm1000 | file: roger |
| 18:26.39 | tm1000 | file: makes sense |
| 18:27.19 | file | errr did I set the timer for my muffins... *goes to check* |
| 18:28.28 | file | the answer is yes |
| 18:30.04 | mjordan | file: what kind of muffins? |
| 18:30.10 | mjordan | inquiring minds want to know |
| 18:30.36 | file | 6 chocolate chip, 6 blueberry |
| 18:30.42 | file | ...and I put sprinkles in them too |
| 18:32.02 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 18:38.43 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.4) |
| 18:57.12 | *** join/#asterisk-dev Gugge (gugge@kriminel.dk) |
| 19:07.43 | *** join/#asterisk-dev serafie1 (~erin@nat/digium/x-aviuksoxwpkgjvfu) |
| 19:08.19 | skrusty | mjordan: yeah, trying to source more material, but not just letting it pass through, im moderating it |
| 19:08.44 | skrusty | so if you know any "interesting" sources of annoucements etc, then let me know |
| 19:11.14 | skrusty | going to expose theagigallery as an rss feed too, as i want to extend that to include ARI projects, thought it might be a good starting point for a public resource of ARI projects |
| 19:28.20 | *** join/#asterisk-dev ehsjoar (~jonas@c-24-9-87-13.hsd1.co.comcast.net) |
| 19:32.45 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 19:41.42 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.11) |
| 19:45.46 | *** join/#asterisk-dev Gugge (gugge@kriminel.dk) |
| 20:14.51 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-xtcpvnbdtzgdlegm) |
| 20:39.15 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 20:40.36 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.182) |
| 20:49.55 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:437:ce01:3e97:eff:fe14:ef66) |
| 21:07.03 | *** part/#asterisk-dev ehsjoar (~jonas@c-24-9-87-13.hsd1.co.comcast.net) |
| 21:07.12 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 21:08.49 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 21:25.44 | *** join/#asterisk-dev ehsjoar (~jonas@c-24-9-87-13.hsd1.co.comcast.net) |
| 21:40.44 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.218) |
| 22:00.01 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 22:15.10 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 22:15.14 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 22:15.54 | mjordan | file: you around? |
| 22:16.21 | file | now I am |
| 22:19.03 | file | yup yup, all done |
| 22:20.06 | mjordan | mulling over various things. Say we have Alice and Bob talking, where Bob has multiple contacts registered to its AoR |
| 22:20.22 | mjordan | Alice decides to transfer Bob to Charlie |
| 22:20.54 | mjordan | In the REFER request sent to Charlie, what URI is placed in the Refer-To field? |
| 22:22.08 | file | in what context are you talking... Asterisk? SIP? |
| 22:22.13 | mjordan | Asterisk |
| 22:22.26 | file | a REFER isn't sent to Charlie |
| 22:22.38 | file | Alice sends a REFER to Asterisk with a URI for an extension in the dialplan |
| 22:22.47 | mjordan | ah. |
| 22:23.38 | mjordan | The Refer-To would still have to reference the URI for Bob |
| 22:23.44 | file | in the case of SIP the URI would be to the AOR, which would then fork to the various devices |
| 22:24.51 | mjordan | Hm. |
| 22:25.09 | mjordan | I would have thought you would have to put the URI for the current contact |
| 22:25.36 | mjordan | or at least, you'd want to in order to avoid the forking |
| 22:26.51 | file | I don't know what you mean by current contact |
| 22:27.48 | mjordan | If Alice is talking to Bob, then there is a dialog between Asterisk and Bob that was established to some contact on the AoR for Bob |
| 22:27.59 | file | sure |
| 22:28.10 | skrusty | evening |
| 22:28.55 | mjordan | so if Alice sends a REFER request to Asterisk with a Refer-To header that contains a URI for Bob's AoR, that would be insufficient to address which contact's URI was actually used for the channel |
| 22:30.13 | file | the Refer-To is for saying where to go |
| 22:31.27 | file | the REFER is in the dialog |
| 22:36.48 | putnopvut | The thing about URIs in Refer-To headers is that we don't perform AoR lookups. We look in the dialplan for the destination. It's up to the dialplan code to determine where to ultimately send the transferred call. |
| 22:38.04 | putnopvut | So if Alice and Bob are talking and Alice sends a REFER with Refer-to: sip:charlie@some_ip, then we'll look for extension "charlie" in Alice's context in the dialplan. It's then up to the dialplan to dial one or more of Charlie's contacts, or not to even dial Charlie at all for whatever reason. |
| 22:38.25 | mjordan | gotchya. |
| 22:39.04 | putnopvut | Now, there is a way for Asterisk to send an outbound REFER. |
| 22:39.38 | putnopvut | If Alice is talking to Bob through Asterisk, then Alice places Bob on hold and starts talking to Charlie *not* through Asterisk, then Alice will send a REFER to Asterisk, referencing a dialog that Asterisk does not know about. |
| 22:39.59 | putnopvut | Because Asterisk doesn't know about the dialog, Asterisk will route the call to the dialplan based on the URI in the Refer-To header. |
| 22:40.38 | putnopvut | If that call ends up making a SIP call (both chan_sip and chan_pjsip operate this way), then when Asterisk makes the outbound call, Asterisk will include a Replaces header referencing the dialog from the Refer-To header from earlier. |
| 22:40.40 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.248) |
| 22:40.47 | putnopvut | It's kind of brittle to be quite honest. |
| 22:41.07 | putnopvut | And now that I think about it, Asterisk didn't send an outbound REFER, so nevermind! |
| 22:41.16 | putnopvut | It sent an INVITE with replaces. |
| 22:41.30 | putnopvut | I got them mixed up. |
| 22:42.36 | gtjoseph | back to mjordan's original question though... Bob's end of things doesn't get touched through all of this right? |
| 22:43.03 | gtjoseph | Whatever contact was in use is still in use. |
| 22:43.17 | mjordan | gtjoseph: correct, no one gets a BYE |
| 22:43.22 | mjordan | unless someone actually hangs up |
| 22:44.03 | gtjoseph | So thaty's why it doesn't matter how many contacts Bob has, yes? |
| 22:44.20 | mjordan | file: putnopvut: trolling through RFCs and ran across GRUUs. Since they address (partly) the issue of providing a globally unique URI - in large part to resolve multiple contact URIs on an AoR - I was curious how we handled it |
| 22:44.55 | *** join/#asterisk-dev ehsjoar (~jonas@c-24-9-87-13.hsd1.co.comcast.net) |
| 22:45.04 | *** part/#asterisk-dev ehsjoar (~jonas@c-24-9-87-13.hsd1.co.comcast.net) |
| 22:45.09 | putnopvut | We handle it by leaving it up to the dialplan writer. |
| 22:45.14 | mjordan | yup |
| 22:45.19 | mjordan | gtjoseph: we in large part get away with it because we're a B2BUA and Asterisk's dialplan sits between the Refer-To and Charlie |
| 22:45.56 | gtjoseph | Yep, makes sense. I was just scratching my head at the beginning. |
| 22:45.58 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 22:46.34 | file | reads backlog |
| 22:47.04 | file | yes. |
| 22:47.58 | file | gives mjordan some sweet potato fries |
| 22:48.27 | mjordan | tasty. |
| 22:49.28 | file | I'm actually out, now that I think about it |
| 23:08.20 | file | moo. |
| 23:20.40 | *** part/#asterisk-dev mjordan (~matt@nat/digium/x-uauzctcoujxcfeyt) |
| 23:33.13 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-xhidpjjnzwgnkzcf) |
| 23:40.37 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.41) |
| 23:47.55 | *** join/#asterisk-dev ehsjoar (~jonas@c-24-9-87-13.hsd1.co.comcast.net) |
| 23:48.36 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 23:54.51 | *** join/#asterisk-dev ehsjoar (~jonas@c-24-9-87-13.hsd1.co.comcast.net) |
