| 00:39.09 | *** join/#asterisk-dev suneye (~atcmmi@121.34.40.242) |
| 00:59.50 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 00:59.50 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 01:33.19 | *** join/#asterisk-dev vtone (~vtone@cpc35-bagu10-2-0-cust138.1-3.cable.virginm.net) |
| 02:05.52 | *** join/#asterisk-dev atcmmi (~atcmmi@119.122.155.54) |
| 04:11.47 | *** join/#asterisk-dev Pullphinger (~Pullphing@c-24-13-69-42.hsd1.il.comcast.net) |
| 05:46.40 | *** join/#asterisk-dev atcmmi (~atcmmi@119.122.155.54) |
| 05:58.42 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.77) |
| 07:17.45 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 09:19.07 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:e9f8:4519:9c17:8662) |
| 09:35.15 | *** join/#asterisk-dev vlad_starkov (~vlad_star@194.154.71.230) |
| 11:58.52 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.44) |
| 13:27.58 | *** join/#asterisk-dev protocoldoug (~doug@unaffiliated/protocoldoug) |
| 13:40.00 | *** join/#asterisk-dev LooserOuting (~LooserOut@ip-176-198-134-194.unitymediagroup.de) |
| 13:41.47 | LooserOuting | hi. it looks like am the assignee of ASTERISK-22790. The ticket is open an i don't know what to do. |
| 13:43.23 | LooserOuting | should i "requst feedback" or "start progress" ? there is already a patch attached. i should mention i am also the reporter. |
| 13:43.27 | file | fixed |
| 13:51.13 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 13:59.11 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-rlwtyyjgvtzqjcjw) |
| 14:26.58 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:26.58 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:30.09 | LooserOuting | so what's next ? waiting for commit ? |
| 14:31.59 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.44) |
| 14:32.12 | file | yes |
| 14:34.37 | LooserOuting | Thank you ! |
| 14:36.34 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-mprbswzwsuuupoqy) |
| 14:45.53 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-mlgjxpxztqugnkkm) |
| 14:45.53 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:53.54 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-blpgzddvtjkjluex) |
| 15:13.28 | *** part/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 15:20.52 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-ayiehdlathduypdd) |
| 15:58.43 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 16:24.42 | *** join/#asterisk-dev opticron (~opticron@pianoben.ch) |
| 16:24.42 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 16:49.08 | *** join/#asterisk-dev protocoldoug (~doug@unaffiliated/protocoldoug) |
| 16:53.54 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.44) |
| 17:00.53 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 17:00.53 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 17:27.50 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:31.47 | mjordan | putnopvut: jrose_atDigium: MWI in ARI |
| 17:32.08 | putnopvut | It shall soon be a thing! |
| 17:32.23 | mjordan | leedm777's wiki page doesn't really specify an implementation, which means whether or not we have mailboxes or simply act as a proxy/pass through is not a concern |
| 17:32.49 | mjordan | what I'm curious about is how the mailboxes would work, particularly with whether or not there is any value in having them be addressable via ARI |
| 17:33.02 | mjordan | that is, other than raising MWI, should I be able to do something with the mailbox? |
| 17:34.16 | putnopvut | I don't really know that there's anything else you'd want to supply at the ARI level, simply because moving too much further starts adding business logic. |
| 17:34.41 | file | yeah... what else would you do with it? |
| 17:36.37 | mjordan | well, let's say I use \record |
| 17:36.54 | mjordan | and I'd like to put that in a 'mailbox' - or associate the StoredRecording with a mailbox |
| 17:37.02 | mjordan | so far, so good - all external logic |
| 17:37.18 | mjordan | but what if I have metadata about the recording that I'd like to associate with the mailbox as well? |
| 17:37.23 | mjordan | this is where I get a bit unsure |
| 17:38.36 | putnopvut | What kind of metadata were you thinking about? |
| 17:38.58 | mjordan | Well, I might have some stored recordings that are 'urgent' |
| 17:39.03 | mjordan | or some that are priority |
| 17:39.26 | mjordan | as I associate them with a mailbox, I may want to tag the name of the recording or alter counts that don't translate directly to MWI |
| 17:39.27 | putnopvut | Well those are recording-specific, not mailbox-specific. |
| 17:40.41 | mjordan | true, other than the concept of different counts, or folder counts |
| 17:41.09 | mjordan | which starts to get very close to the existing functionality in ast_vm_mailbox_snapshot |
| 17:41.21 | putnopvut | The thing about counts is that I envision the external voicemail server being the one that keeps tracks of counts and simply relays to Asterisk what the "new" and "old" counts are for MWI, since that's all Asterisk knows about. |
| 17:41.37 | putnopvut | If any recordings don't fall into that category, then the external application simply doesn't mention it to Asterisk at all. |
| 17:41.49 | mjordan | and so the mailbox only exists as a concept under the hood to survive reloads? |
| 17:42.01 | putnopvut | Pretty much |
| 17:42.08 | mjordan | how do we envision ARI purging a mailbox? |
| 17:42.20 | mjordan | you can implicitly create a mailbox when you get your first MWI notification |
| 17:42.28 | mjordan | but I'm not sure how you destroy it if you've persisted it |
| 17:42.53 | mjordan | assuming AstDB, as you'd need to use something more than in memory storage to survive core restart now |
| 17:42.55 | file | yeah, that's the thing with persisting... maintaining consistent object existence on both sides |
| 17:43.32 | putnopvut | My thoughts are that you have to create and destroy a mailbox the same way you do with a channel or bridge or anything else in ARI. Even though MWI is the only operation on a mailbox, since it is an object, it needs the same sort of treatment. |
| 17:45.00 | mjordan | well, we do have a DELETE in there |
| 17:45.08 | mjordan | hum. |
| 17:45.36 | putnopvut | The thing that's a bit different from the wiki page from what I had envisioned is that the actions take a mailbox name instead of an ID returned when the mailbox is created. |
| 17:45.54 | putnopvut | But that shouldn't make a huge difference when it comes to deleting a mailbox. |
| 17:46.11 | mjordan | putnopvut: make sure you look at leedm777's proposal two |
| 17:46.20 | putnopvut | That's the one I'm looking at. |
| 17:46.22 | mjordan | hm |
| 17:46.31 | putnopvut | <PROTECTED> |
| 17:46.34 | file | links? (to make sure I'm looking at the same thing) |
| 17:46.46 | mjordan | right - so how is that an ID? |
| 17:46.50 | putnopvut | It's not. |
| 17:47.17 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.50) |
| 17:47.20 | putnopvut | The wiki page says a name. I was picturing a similar method to how e.g. bridges operate. |
| 17:47.21 | mjordan | I'm confused about what you're referring to then when you say "I had envisioned is that the actions take a mailbox name instead of an ID returned when the mailbox is created" |
| 17:47.37 | mjordan | ah, that there's an implicit create with mailboxes? |
| 17:47.45 | putnopvut | ARGH, I HATE TALKING ON IRC |
| 17:47.48 | mjordan | lawl |
| 17:47.50 | mjordan | open source! |
| 17:48.01 | putnopvut | OKay, let me spell out what I was trying to say. |
| 17:48.09 | putnopvut | I had envisioned something similar to how bridges operate. |
| 17:48.15 | putnopvut | So you start by posting a new mailbox. |
| 17:48.23 | putnopvut | You then are told an identifier for that mailbox. |
| 17:48.37 | putnopvut | Then that identifier is used for changing the state, getting the state, or deleting the mailbox. |
| 17:48.38 | jrose_atDigium | So you create the bridge with properties without specifying a name. It gives you back an ID. |
| 17:49.00 | file | erm |
| 17:49.05 | putnopvut | In the proposal on the wiki, there is an implicit creation when mailbox state is altered. There is no initial step to create a mailbox and get an ID for it. |
| 17:49.21 | putnopvut | Instead, you just always operate on mailbox names for all commands. |
| 17:49.30 | mjordan | correct. |
| 17:49.34 | file | right. |
| 17:49.38 | putnopvut | I'm not saying that's good or bad. |
| 17:49.48 | mjordan | btw, one problem we will have with our naming syntax is that '@' is a reserved character |
| 17:49.49 | putnopvut | All I was saying was that it was different from what I had envisioned. |
| 17:50.05 | mjordan | URL encoding ftl :-( |
| 17:50.18 | putnopvut | Is '@' required if mailboxes are truly external? |
| 17:50.40 | jrose_atDigium | Perhaps we could supply the name as two arguments? 'extension' @ 'context'? |
| 17:50.42 | putnopvut | Does the MWI stasis API expect a mailbox@context format? |
| 17:50.43 | file | I could see people using it as a method of providing scope |
| 17:50.53 | mjordan | looks |
| 17:51.00 | putnopvut | They could do that with the URL itself. |
| 17:51.09 | putnopvut | mailboxes/office4/mark |
| 17:51.18 | putnopvut | instead of mailboxes/mark@office4 |
| 17:51.22 | file | true |
| 17:51.37 | mjordan | well |
| 17:51.44 | *** join/#asterisk-dev Pullphinger (~Pullphing@c-24-13-69-42.hsd1.il.comcast.net) |
| 17:51.50 | mjordan | putnopvut: the underlying ast_mwi_state data structure expects a mailbox and a context |
| 17:52.07 | mjordan | you could fake it by simply providing the mailbox as the name from ARI, and use 'default' for the context |
| 17:52.37 | mjordan | but that does mean phones have to supply "mailbox@default" when they subscribe, as opposed to "mailbox" |
| 17:53.11 | mjordan | of course, we could just change ast_mwi_create to not require a context and have an ast_mwi_create_explicit |
| 17:53.23 | mjordan | er, keep ast_mwi_create, add an ast_mwi_create_explicit |
| 17:53.35 | mjordan | the uniqueid on the object is what really matters, and is typically composed of the mailbox/context passed in |
| 17:57.41 | mjordan | kharwell: did you see rmudgett's comment on searching by OBJ_SEARCH_KEY using a struct? |
| 17:59.14 | kharwell | mjordan: yeah that's basically what I am doing except using OBJ_SEARCH_OBJ as the flag |
| 18:00.01 | kharwell | mjordan: I guess semantically either could work since I am essentially search on the object type of the container, but I am also matching against string keys |
| 18:01.22 | putnopvut | Well, the problem actually is that device_state_subscriptions_cmp()'s OBJ_SEARCH_KEY method is underdeveloped. It really should be using the same criteria as OBJ_SEARCH_OBJECT for determining a match. |
| 18:03.48 | kharwell | putnopvut: that's true. I originally was thinking I would use the KEY search to do a lookup by just one of the values like device name, but I ended up just using a callback to handle that case when I needed it |
| 18:04.04 | kharwell | I'll change it to make is consistent |
| 18:13.40 | file | ship it like a polaroid picture! |
| 18:20.14 | anonymouz666 | anyone care to see if this backtrace is valid? So I can move forward and open an issue. Asterisk 11.6.0. http://pastebin.com/LGZKN0rn |
| 18:23.11 | mjordan | anonymouz666: do you still have the core file? |
| 18:23.17 | anonymouz666 | yeap |
| 18:23.23 | mjordan | can you open it with gdb? |
| 18:23.34 | anonymouz666 | done |
| 18:23.39 | mjordan | jump to frame 1 |
| 18:24.02 | anonymouz666 | can I paste? |
| 18:24.02 | mjordan | what is ast_channel_tech(bridged) |
| 18:24.04 | mjordan | sure |
| 18:24.15 | mjordan | "print ast_channel_tech(bridged)" |
| 18:24.48 | anonymouz666 | #1 0x00000000004879ef in ast_bridged_channel (chan=0x7f579a1ea5c8) at channel.c:7426 7426 bridged = ast_channel_tech(bridged)->bridged_channel(chan, bridged); |
| 18:25.18 | mjordan | yup, now type the print statement |
| 18:26.47 | anonymouz666 | $1 = {const struct ast_channel_tech *(const struct ast_channel *)} 0x49612d <ast_channel_tech> |
| 18:27.16 | mjordan | k, so that was valid |
| 18:27.50 | mjordan | print ast_channel_tech(bridged)->bridged_channel |
| 18:28.34 | mjordan | hm. That better come back with something non-NULL, or else math stopped working |
| 18:28.52 | mjordan | when you get that, try also "print *ast_channel_tech(bridged)->bridged_channel" |
| 18:29.26 | mjordan | and to double check sanity, what channel types were involved in this bridge? |
| 18:30.03 | anonymouz666 | gdb is returning that: You can't do that without a process to debug. |
| 18:30.12 | anonymouz666 | SIP to SIP call. |
| 18:30.29 | jql | mjordan: I have suffered broken math before. ASTERISK-21316 :( |
| 18:30.30 | LieutPants | [ASTERISK-21316] [Status: Open] Segfault on ast_channel_tech(chan)->send_digit_begin - https://issues.asterisk.org/jira/browse/ASTERISK-21316 |
| 18:33.13 | anonymouz666 | $3 = {const struct ast_channel_tech *(const struct ast_channel *)} 0x49612d <ast_channel_tech> -->> ast_channel_tech |
| 18:43.45 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.50.56.176) |
| 19:02.44 | mjordan | anonymouz666: sorry for the delay. You can file an issue, but I'm not sure what happened in stack frame 0, and it may be very, very hard to reproduce without more information. Do you have a dialplan/sip config that can reproduce the problem? |
| 19:02.49 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.50.56.176) |
| 19:03.40 | mjordan | and that is a good point from jql - it'd be interesting to see if either channel in the bridge at that point is a zombie |
| 19:04.02 | anonymouz666 | it crashes at least one time/day |
| 19:04.06 | anonymouz666 | but I can't reproduce |
| 19:04.50 | jql | anonymouz666: I can give you a version of the fix from my 21316 case if you want to try it out |
| 19:05.16 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 19:05.27 | jql | no warranty offered, of course. heh |
| 19:11.02 | mjordan | anonymouz666: I think a log file when it crashed would be helpful then - a DEBUG one. |
| 19:11.13 | mjordan | that would hopefully show what led up to the crash, so we can understand the circumstances |
| 19:16.14 | anonymouz666 | jql: sure |
| 19:17.06 | jql | I'll leave this http://pastebin.com/DAtza8Nd for you to try. Please still open a ticket in JIRA if it fixes your issue. |
| 19:18.34 | anonymouz666 | alright |
| 19:27.57 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 19:27.57 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 19:44.16 | anonymouz666 | jql: channel.c:7427: warning: initialization discards qualifiers from pointer target type |
| 19:44.37 | anonymouz666 | struct ast_channel_tech *tech = ast_channel_tech(bridged); - 7427 |
| 19:46.34 | mjordan | kharwell: on r403022, you need to also update the Alembic script for the pjsip tables |
| 19:47.11 | kharwell | mjordan: what or where is that? |
| 19:47.24 | mjordan | http://svn.asterisk.org/svn/asterisk/branches/12/contrib/ast-db-manage/config/versions/43956d550a44_add_tables_for_pjsip.py |
| 19:47.35 | mjordan | sorry that got missed in the review, but was looking at the commit and though, 'oh fudge' |
| 19:48.32 | kharwell | mjordan: okay cool thanks I'll look into it |
| 19:51.06 | jql | anonymouz666: ahh, I skipped a const on that. my mistake |
| 19:55.52 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-84-109-18-138.red.bezeqint.net) |
| 19:55.52 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 19:58.32 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.61) |
| 19:58.58 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.61) |
| 20:03.27 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.61) |
| 20:27.13 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.61) |
| 20:31.40 | *** join/#asterisk-dev Vendigroth (41254d61@gateway/web/freenode/ip.65.37.77.97) |
| 21:03.44 | *** join/#asterisk-dev angler (~angler@pdpc/sponsor/digium/angler) |
| 21:26.55 | file | opticron, you can't store path on an endpoint |
| 21:27.52 | file | 1. An endpoint can't be modified without copying and 2. It's generally not an object that is modified and persisted out |
| 21:28.59 | mjordan | file: since it is basically routing information, where would we store that? |
| 21:29.28 | file | you can store it on another object for persistence and associate it |
| 21:30.53 | file | and how does that work if you have multiple contacts? |
| 21:35.31 | mjordan | reading RFC. |
| 21:35.38 | mjordan | https://tools.ietf.org/html/rfc3327 |
| 21:35.42 | mjordan | I think it's associated with an AoR |
| 21:37.44 | file | The registrar then stores this path vector in association with that |
| 21:37.44 | file | <PROTECTED> |
| 21:37.56 | mjordan | yup. |
| 21:38.18 | file | that's what I would expect, at the contact level |
| 21:38.38 | mjordan | well, the RFC is entitled " Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts" |
| 21:39.16 | mjordan | (opticron: you reading this?) |
| 21:41.11 | file | silence in the library |
| 21:44.33 | kharwell | mjordan: do I just need to convert the config names in the add_tables_for_pjsip.py (alembic) file or do I also need to worry with the revision stuff at this time? |
| 21:44.44 | kharwell | mjordan: that file is not generated correct? |
| 21:45.07 | mjordan | it is not generated |
| 21:48.25 | mjordan | I think we could sneak this by in that file, since it isn't released. |
| 21:48.35 | mjordan | Schema changes would generally need a new revision, if I'm thinking things through correctly. |
| 21:49.14 | mjordan | when we do the release for beta2, we're going to need to make sure that we note that this change occurred |
| 21:49.30 | kharwell | yeah I would typically think they would, but since it wasn't officially released I figured we might not need to |
| 21:49.55 | mjordan | I'd say let's sneak it on by and hope we don't get castigated |
| 21:50.15 | kharwell | heh...here's to hoping |
| 21:50.27 | kharwell | where is the best place to note that? |
| 21:50.30 | *** join/#asterisk-dev chazzam (~cmoye@nat/digium/x-xjsczddgxgveoimb) |
| 21:50.46 | mjordan | right now, no where. We typically don't update UPGRADE for differences between beta releases |
| 21:50.55 | mjordan | when I do the release announcement, just make sure you review it ;-) |
| 21:51.21 | kharwell | who's going to remind me to remind you :-) |
| 21:52.19 | mjordan | the system of trust has been broken! |
| 21:52.22 | opticron | file, pong, reading backlog |
| 21:55.09 | opticron | mkay, understood |
| 22:00.54 | *** join/#asterisk-dev serafie1 (~erin@nat/digium/x-vqllqhgtkxgmnnor) |
| 22:25.43 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 22:32.32 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-nlytqcjrxteeuvgy) |
| 22:59.22 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 23:02.00 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 23:27.03 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 23:27.03 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 23:35.53 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.61) |
| 23:40.22 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.61) |