| 00:01.15 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-yuqlwugaoraslmpi) |
| 00:01.15 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 01:17.58 | *** join/#asterisk-dev mjordan (~mjordan@adsl-98-81-59-18.hsv.bellsouth.net) |
| 01:17.58 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 01:24.52 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 01:24.53 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 01:41.50 | *** join/#asterisk-dev tonyclewis (uid6025@gateway/web/irccloud.com/x-rtsypifvfgqptbsz) |
| 06:35.42 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.36.36) |
| 06:51.04 | *** join/#asterisk-dev Skavin (~kevins@202-180-69-27.me.tranzpeer.net) |
| 07:20.26 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:201b:6b5f:cad1:fe67) |
| 07:29.17 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 10:28.11 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 11:46.05 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 11:46.05 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk |
| 12:14.24 | *** join/#asterisk-dev oron_laptop (~oron_lapt@local.xorcom.com) |
| 12:22.12 | oej | Afternoon folks |
| 12:26.16 | file | hola |
| 12:26.28 | oej | No, Olle. |
| 12:26.35 | oej | O - L - L - E |
| 12:26.39 | file | hola! |
| 12:26.56 | oej | ;-) |
| 12:27.33 | oej | Of course you can test a wiki page. |
| 12:28.18 | oej | Why do you require an endpoint all the time in gulp? |
| 12:29.56 | oej | I do wish we could spend a day or two hashing this stuff out on a whiteboard. Your wiki page confuses me a lot. |
| 12:30.02 | file | because that simplifies the code so you don't need to write stuff to handle defaults everywhere - the defaults are simply another endpoint |
| 12:31.50 | oej | To be honest, I don't understand the structure at all based on this document. |
| 12:32.07 | oej | Sorry. Disclaimer: It's a very confusing day and I'm in general confused. |
| 12:32.53 | file | ok |
| 12:33.50 | oej | Why do you need the confusing type=aor - I think you are making this much too complicated for the users. |
| 12:34.28 | file | because otherwise you lump EVERYTHING into an endpoint, and parts of objects can't be stored without a lot of effort |
| 12:34.55 | file | to make things easier we could add options to automatically create things |
| 12:36.02 | oej | I really think that is too low-level. We need a higher abstraction that makes sense for ASterisk admins. And I do not mean users and peers. |
| 12:36.58 | oej | From reading your document I can't find any benefit as an Asterisk admin. I can just say "O boy, this guy is confused. I never seen anything like this in any SIP device or server". |
| 12:37.04 | oej | Sorry. |
| 12:37.43 | oej | You are doing a lot of good work, but we need to be able to talk about it in ways that normal SIP users understand - as well as un-normal ones like me. |
| 12:37.49 | oej | And I do not get this. |
| 12:38.39 | file | building a higher level on top is fine... but having that influence the core stuff I'm not okay with - there's a lot of flexibility with the way this is done |
| 12:39.07 | file | you can store all of these however you want, cache them differently |
| 12:39.28 | oej | Then please take a moment to tie it together and explain these benefits on the wiki page. |
| 12:39.49 | oej | If you want people involved in the process, you need to have both language, terminology and documents that we understand. |
| 12:40.12 | oej | Otherwise you will just get feedback from your co-workers that has taken the time to understand what goes on in the code. |
| 12:40.30 | oej | And I really want to understand this to give feedback, but this document I totally fail on. |
| 12:40.40 | oej | Sorry, Josh. |
| 12:41.35 | file | okay - so you want it explained why this is better - anything else? |
| 12:41.48 | WIMPy | What page is that? |
| 12:42.07 | file | WIMPy, https://wiki.asterisk.org/wiki/display/~jcolp/Endpoints+and+Location%2C+A+Match+Made+in+Heaven |
| 12:42.18 | oej | There's no connection to objects we know. Dialplan extensions, dialstrings, devices used in hints. |
| 12:42.30 | oej | You need to tie this together with the world we know. |
| 12:43.03 | oej | Is an "endpoint" something we dial, is a "contact" something we can subscribe for status on? Is that a device status or extension status? What maps where? |
| 12:43.21 | file | pubsub doesn't exist yet, so not going there yet |
| 12:43.26 | oej | People have phones, trunks, services they register for. They have a dialplan. YOu are in the middle. |
| 12:43.39 | oej | You are defining the devices for pubsub. |
| 12:44.16 | file | until pubsub is architected I'm not going to potentially put incorrect information out there |
| 12:44.26 | oej | I think it's high time to write up an overview, a roadmap so we understand where the parts fits in. I see a lot of work happening and when I give feedback I commonly get "it's not this part." or "it's coming". |
| 12:44.48 | oej | Ok, that's my feedback. |
| 12:45.19 | oej | Have a dead network to fix. And a stupid firewall to bypass. And a firewall and network manager to bypass. |
| 12:45.22 | WIMPy | I think that's generelly true. |
| 12:46.03 | WIMPy | A common "what's currently going on" would be great. |
| 12:46.11 | file | https://wiki.asterisk.org/wiki/display/AST/New+SIP+channel+driver that has details on the design and a live JIRA view of current issues being worked, plus who is working on them, and within the issue more details |
| 12:47.10 | file | but a more non-task specific roadmap is certainly something that could be done, plus the page could use some updating |
| 12:47.52 | file | and I'll make a point that when development starts if a branch is created that it is marked on the JIRA issue as well |
| 12:48.04 | oej | Well, I don't agree that all cli, FUNCTIONS and apps should remain. In fact, I thnk that is a bad requirement that will lead the wrong way. |
| 12:48.05 | file | I've also copied your feedback re: the wiki page to reviewboard |
| 12:48.42 | oej | thanks |
| 12:52.22 | WIMPy | I guess a little drawing might make things a lot more obvious, but so far that page makes sense to me. |
| 12:52.29 | WIMPy | Or at least I think so :-) |
| 12:52.58 | file | it's really a 10000ft view of how the new SIP stuff operates from a developer/implementation perspective, not really how it is exposed to the user and used there completely |
| 12:53.06 | file | that's how I wrote it at least |
| 12:54.16 | file | WIMPy, would you mind adding a comment about diagram? |
| 12:54.29 | file | https://reviewboard.asterisk.org/r/2435/ |
| 12:55.15 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-nehbjyjhcnrsbrmd) |
| 12:55.17 | WIMPy | I find the outgoing requests a little confusing. First it says it uses the furst contact, but also that you might be able to use all contacts. |
| 12:55.44 | WIMPy | I think you should indicate if that's a choice made at another level or what it is. |
| 12:55.55 | file | k |
| 12:56.41 | WIMPy | The function mentioned seems like you have to do it manually OTOH. |
| 12:56.49 | file | you do |
| 12:56.54 | file | I can clarify that more |
| 12:57.44 | WIMPy | So is the idea to construct a dialstring using that function or will it be an option do dial the first or all contacts? |
| 12:58.02 | file | the function constructs the dial string for you, minus dial options |
| 12:58.17 | file | a Gulp channel is only capable of calling a single destination |
| 12:59.15 | WIMPy | So the contact is an optional part of the dialstring defaulting to the first contact? |
| 12:59.22 | file | yes |
| 13:00.10 | file | if you go for the same behavior of chan_sip then stuff will work like previously, if you want to go down the road of multiple then you (currently) have to use the dialplan function |
| 13:01.03 | file | good feedback, that is an area that is more complicated |
| 13:13.30 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:13.30 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:13.42 | oej | all the contacts for an AOR points to one destination though, right? |
| 13:13.58 | oej | Or can an AOR have contacts for multiple destinations? |
| 13:14.02 | oej | What's the status? |
| 13:14.18 | file | an AOR can have multiple contacts, each contact can be a different destination |
| 13:14.23 | file | and what do you mean status? |
| 13:15.25 | WIMPy | Oh, BTW: What does AOR stand for? |
| 13:15.31 | file | address of record |
| 13:16.03 | WIMPy | I shouldn't have asked. |
| 13:16.15 | WIMPy | That's a confusing name. |
| 13:16.25 | file | it's a SIP term |
| 13:16.28 | putnopvut | It's a standard SIP term |
| 13:16.44 | WIMPy | didn;t come across that so far. |
| 13:16.49 | oej | AOR is a standard SIP term... |
| 13:16.52 | putnopvut | Read RFC 3261 section 10 |
| 13:16.58 | putnopvut | It's sad that I know that off the top of my head |
| 13:17.00 | snuff-home | mm.. anyone skilled in the way of the cisco call manager? |
| 13:18.48 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-qcvhwoktxoajmuzp) |
| 13:18.48 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:19.53 | file | waves to mjordan |
| 13:25.15 | mjordan | waves back |
| 14:12.16 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 14:26.23 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:26.23 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:27.44 | oej | mjordan: thanks for fixing transfer in the same commit |
| 14:27.54 | mjordan | oej: np, thanks for pointing it out :-) |
| 14:38.57 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 14:43.28 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-qcvhwoktxoajmuzp) |
| 14:53.37 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-jorucygnwcuvytqz) |
| 14:53.37 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:22.43 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-144-164.user.veloxzone.com.br) |
| 15:30.50 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 15:30.51 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:41.59 | tzafrir | Could you please look at https://issues.asterisk.org/jira/browse/ASTERISK-21399 ? |
| 15:46.53 | tzafrir | In https://en.wikipedia.org/wiki/RTP_audio_video_profile I see that L16 RTP type is "Linear PCM 16-bit Stereo Audio 1411.2 kbit/s, uncompressed" |
| 15:47.15 | tzafrir | But looking at the actual references, I see that the number of channels and the sample rate is not defined. |
| 15:47.49 | tzafrir | So does this mean that RTP multicast as slin is something that one should not be used? |
| 15:52.40 | tzafrir | s/ones // |
| 17:31.28 | file | jsmith, so are you coming to NB?!? |
| 17:37.24 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 17:37.24 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:04.48 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 18:04.48 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 18:43.10 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 18:43.10 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk |
| 20:29.52 | mjordan | woohoo, I finally got a fish |
| 20:30.55 | Kobaz | yay |
| 20:30.57 | Kobaz | okay so |
| 20:31.00 | Kobaz | ast 11 |
| 20:31.12 | Kobaz | looking for where to add a new bit of data to ast_channel |
| 20:31.17 | Kobaz | i see all the new stringfield stuff |
| 20:31.21 | Kobaz | what about non-strings |
| 20:31.24 | Kobaz | say i want a boolean |
| 20:31.37 | Kobaz | where's all the ast_channel stuff these days, i've been digging and cant find it yet |
| 20:33.39 | mjordan | one question and a comment |
| 20:33.47 | mjordan | first, what do you want to add to ast_channel and why |
| 20:33.55 | mjordan | second, the channel structure was opaquified |
| 20:34.04 | mjordan | so that's now all hidden in channel_internal |
| 20:37.56 | *** part/#asterisk-dev leedm777 (~leedm777@nat/digium/x-todcpxvxzechasna) |
| 20:39.24 | Kobaz | holding status |
| 20:39.33 | Kobaz | boolean 1/0 if the channel is holding |
| 20:39.38 | Kobaz | ...porting my stuff from 1.8 |
| 20:39.42 | Kobaz | unless there's a better way to query that |
| 20:42.01 | mjordan | I suppose you could take advantage of the weirdness that are the upper 16 bits of the channel state. |
| 20:43.05 | mjordan | but otherwise, a boolean field is probably fine. That does seem like it'd be part of the ast_channel. |
| 20:43.20 | mjordan | and not better served by a datastore |
| 20:44.28 | WIMPy | wonders if that's the right time to come up with his request for two new channelstates again. |
| 21:00.23 | Kobaz | WIMPy: which ones? |
| 21:00.34 | Kobaz | mjordan: yeah that sounds like a nice boolean holding yes/no would be nice |
| 21:00.47 | Kobaz | so it would go in channel_internal ? |
| 21:01.49 | WIMPy | 1. disconnected. So that announcements can be played after billing ends which would be essential for correct CDRs and |
| 21:02.18 | WIMPy | 2. one for channels that are UP, but still available for pickup, i.e. in VoiceMail. |
| 21:07.30 | Kobaz | 1.8 |
| 21:07.34 | Kobaz | er werong window |
| 21:07.43 | Kobaz | ah |
| 21:07.48 | Kobaz | WIMPy: sounds good |
| 21:08.24 | Kobaz | so like, with the disconnected state, you're on say a local sip endpoint that's no longer connected to an outside toll line and you're playing a track after the far end hangs up? |
| 21:09.11 | WIMPy | I'm not even sure that's posible with SIP. |
| 21:09.42 | WIMPy | But from the PSTN you will usually get announcements after a disconnect. |
| 21:09.58 | Kobaz | oh yeah |
| 21:10.06 | Kobaz | like if you stay on the line too long after the busy |
| 21:10.23 | WIMPy | If it happens before the call gets connected, you can just forward it as early media. |
| 21:10.42 | WIMPy | But if the call has been connected, you're screwed and so are your CDRs. |
| 21:11.12 | Kobaz | ah |
| 21:12.04 | WIMPy | And I'd prefer to do it the right way round from the dialplan as well. |
| 21:12.28 | WIMPy | Currently you can either have an announcemet or the phone display the cause. |
| 21:22.08 | Kobaz | mjordan: where's this mystical channel_internal data structure? |
| 21:22.25 | mjordan | channel_internal_api.c |
| 21:22.35 | mjordan | that's where ast_channel now lives. It's opaque. |
| 21:22.47 | mjordan | You have to add an accessor to get to your value. |
| 21:30.33 | Kobaz | yeah |
| 21:30.41 | Kobaz | i know that part about the getters setters |
| 21:30.46 | Kobaz | k thanks |
| 21:31.20 | Kobaz | yaaay there's ast_channel |
| 21:42.00 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-todcpxvxzechasna) |
| 22:38.28 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 22:38.28 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 22:50.32 | *** join/#asterisk-dev italorossi (~italoross@187.61.168.117) |
| 23:46.10 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 23:46.10 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |