| 00:27.57 | *** join/#asterisk-dev suneye (~atcmmi@14.127.178.116) |
| 01:46.32 | *** join/#asterisk-dev italoros_ (~italoross@187.61.168.117) |
| 01:48.21 | *** join/#asterisk-dev Ta^3 (~tacvbo@187.191.31.59) |
| 02:39.06 | *** join/#asterisk-dev suneye (~atcmmi@116.7.102.68) |
| 04:12.29 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 05:12.35 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1005) |
| 05:12.36 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 05:32.14 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 05:35.56 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 06:06.08 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1005) |
| 06:06.09 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:32.27 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.36.36) |
| 07:07.18 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1005) |
| 07:07.18 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:22.50 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1005) |
| 07:22.50 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:23.21 | oej | Morning folks |
| 07:35.42 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:6065:45dc:9309:55b) |
| 08:17.22 | *** join/#asterisk-dev hehol (~hehol@217.9.101.222) |
| 10:11.30 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 10:11.31 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 10:44.31 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 10:59.00 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 11:28.36 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 11:28.36 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 12:49.49 | *** join/#asterisk-dev blitzrage (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:49.50 | *** mode/#asterisk-dev [+o blitzrage] by ChanServ |
| 12:55.47 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-anvzrkiokswuyeqn) |
| 13:07.25 | *** join/#asterisk-dev opticron (~opticron@pianoben.ch) |
| 13:07.27 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 13:33.30 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-yjzxbsqkfwjvvmdu) |
| 13:33.30 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:03.36 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:03.36 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:07.17 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-gwnbipdvnogtutdf) |
| 14:07.40 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-gwnbipdvnogtutdf) |
| 14:08.01 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-gwnbipdvnogtutdf) |
| 14:12.42 | *** join/#asterisk-dev dwayne (~dwayne@c-71-207-208-112.hsd1.al.comcast.net) |
| 14:13.19 | *** join/#asterisk-dev Deeewayne (~dwayne@c-71-207-208-112.hsd1.al.comcast.net) |
| 14:13.19 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 14:17.07 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 14:17.07 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 14:18.33 | mjordan | opticron: on r2482, I wasn't trying to suggest that we need to add functionality to Asterisk |
| 14:19.26 | mjordan | opticron: regardless of pjproject's support for key lifetimes/multiple keys/other things, the tests should try and throw bad SRTP offers or SRTP offers with options we don't currently support to make sure Asterisk sends back the right response (and doesn't crash) |
| 14:19.46 | snuff-home | mjordan: in the next 12.. should be posting a decent update to res_sip doco :) |
| 14:19.58 | mjordan | snuff-home: woot :-) |
| 14:21.05 | snuff-home | i might steal some of the stuff written by file on the wiki.. then others can fix my bad info in comments https://wiki.asterisk.org/wiki/display/~jcolp/Endpoints+and+Location%2C+A+Match+Made+in+Heaven |
| 14:21.15 | file | go ahead |
| 14:23.37 | snuff-home | does this look at all true? http://picpaste.com/res_sip-9BYgrU0H.png |
| 14:23.44 | opticron | mjordan, right, *add what I can to the test from these suggestions* |
| 14:24.32 | opticron | I left out "to the test" |
| 14:25.24 | snuff-home | well.. i'm off to bed now.. let me know if that diagram i posted is remotely correct |
| 14:26.22 | snuff-home | *gonerz* |
| 14:27.01 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:27.01 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:26.06 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 15:26.06 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 15:29.01 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 15:29.01 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 15:32.21 | seanbright | can i help with the sip work at all? any low hanging fruit? |
| 15:37.58 | file | ummmm |
| 15:38.08 | file | let's see |
| 15:39.06 | file | https://issues.asterisk.org/jira/issues/?filter=11921 |
| 15:39.16 | seanbright | heh |
| 15:39.18 | file | that's the current issues in JIRA |
| 15:39.24 | seanbright | my god |
| 15:39.26 | seanbright | heh |
| 15:39.54 | seanbright | alrighty, will take a look |
| 15:40.08 | file | towards the bottom is the easier stuff |
| 15:40.55 | file | inband DTMF detection isn't on the list, but should be |
| 15:42.30 | file | seanbright, anything in particular you are interested in? |
| 15:43.05 | seanbright | not really. just want to help where i can. |
| 15:44.43 | file | you should obviously implement CCSS then |
| 15:45.14 | seanbright | obviously |
| 15:45.21 | file | putnopvut, you've got stuff... open... that shouldn't be |
| 15:46.34 | file | seanbright, I'd say inband DTMF detection - that would finish up DTMF support |
| 15:46.43 | seanbright | alrighty |
| 15:46.48 | seanbright | give me 10 minutes |
| 15:47.18 | file | you have 9 |
| 15:48.22 | mjordan | ASTERISK-21057 is the inband dtmf |
| 15:48.23 | LieutPants | [ASTERISK-21057] [Status: Open] [Assigned: kmoore] Bridge API Enhancements - add Stasis-Core events - https://issues.asterisk.org/jira/browse/ASTERISK-21057 |
| 15:48.29 | mjordan | er |
| 15:48.34 | mjordan | ASTERISK-21507 |
| 15:48.34 | LieutPants | [ASTERISK-21507] [Status: Open] New SIP Channel Driver - add progressinband - https://issues.asterisk.org/jira/browse/ASTERISK-21507 |
| 15:48.36 | mjordan | silly fingers |
| 15:48.57 | file | mjordan, progress indications != DTMF |
| 15:49.10 | mjordan | hrm |
| 15:49.25 | mjordan | true. I might have been thinking of combining the two. |
| 15:49.32 | mjordan | goes back to the list |
| 15:50.20 | mjordan | blech. I guess I did miss that |
| 15:52.23 | mjordan | ASTERISK-21501 would be relatively interesting and straight forward (I think!) |
| 15:52.23 | LieutPants | [ASTERISK-21501] [Status: Open] New SIP Channel Driver - add custom INFO support for one touch recording - https://issues.asterisk.org/jira/browse/ASTERISK-21501 |
| 15:54.30 | seanbright | which devices support that feature? |
| 15:55.07 | file | Snom I do believe |
| 15:56.08 | seanbright | roger |
| 15:56.41 | file | no, my name is Josh |
| 16:36.14 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1005) |
| 16:36.14 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:11.17 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 17:11.17 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 17:49.13 | file | hum hum hum |
| 17:50.24 | mjordan | ho ho ho |
| 17:53.46 | WIMPy | Is it x-mas again? |
| 18:03.49 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 18:03.49 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:09.59 | *** join/#asterisk-dev ThunderCock (~jrichards@67.63.142.162) |
| 18:10.23 | ThunderCock | Y'all should name the new chan_sip after me |
| 18:10.35 | ThunderCock | that is all |
| 18:10.38 | *** part/#asterisk-dev ThunderCock (~jrichards@67.63.142.162) |
| 18:13.05 | Qwell | The community has clearly spoken. All in favor of chan_ThunderCock? |
| 18:13.06 | Qwell | >.> |
| 18:14.07 | mjordan | the silence is deafening |
| 18:14.22 | Qwell | silence is acquiescence? |
| 18:14.40 | Qwell | (also, holy spelling, batman) |
| 18:14.42 | file | BANANAS! |
| 18:25.07 | seanbright | so from what i can tell, there is no baked-in way for a res_sip module to "plug in" configuration directives |
| 18:25.20 | Qwell | That's what I said! |
| 18:25.29 | seanbright | zomg |
| 18:25.30 | file | you can't extend an object |
| 18:25.36 | seanbright | roger, roger. |
| 18:25.43 | file | that gets really... complicated |
| 18:26.40 | Qwell | It's going to come up a lot. |
| 18:27.13 | seanbright | endpoint datastores |
| 18:27.18 | file | programatically you *could* do it by storing anything that is not understood by the original object, and then passing it to any others |
| 18:27.18 | seanbright | mother of god... |
| 18:27.21 | file | but you lose object integrity |
| 18:27.51 | file | because the definition of the object itself is not concrete and can change at a whim |
| 18:33.05 | seanbright | explicitly tying the configuration properties to structure members kills the flexibility a bit |
| 18:33.29 | file | you can override it via custom handlers |
| 18:33.35 | seanbright | well then |
| 18:34.20 | file | offers seanbright a duck |
| 18:35.23 | Qwell | So, before I go down this road... There are a lot of manager events that need to be converted to stasis, that don't use any first class objects (channels, bridges, etc). A lot of those events will likely fall under the new "system" topic, so I'll probably create a main/manager_system.c to handle all those. I'm also thinking of creating a generic json blob type, similar to ast_channel_blob, which can be used by lots of things. Thoughts? |
| 18:38.53 | leedm777 | Qwell: Sounds good. |
| 18:39.28 | Qwell | leedm777: my big concern right now would be the function that would basically mirror channel_blob_cb(). That could get ugly, fast. |
| 18:39.31 | leedm777 | My only objection would be that manager_system.c might grow into a big mess of unrelated things. But we should be able to split that up down the road if needed. |
| 18:40.48 | leedm777 | Qwell: So, are you thinking of a message router that routes based on the JSON type field? |
| 18:41.34 | Qwell | Unless you've got a cleaner way. |
| 18:42.29 | Qwell | or maybe I just misunderstand how routers work |
| 18:43.42 | leedm777 | thinking |
| 18:43.59 | Qwell | I think I do misunderstand. The docs say I don't need an ugly if/else, but channel_blob_cb() uses a router, and still has that. |
| 18:44.47 | leedm777 | heh |
| 18:45.03 | Qwell | Or maybe it needs a router router. heh |
| 18:45.12 | leedm777 | Yeah, I don't like where this is going. |
| 18:46.00 | leedm777 | If the messages had different message types (instead of putting a type field in the JSON), there would be one router to rule them all. |
| 18:46.06 | leedm777 | And no ugly if/else blocks. |
| 18:46.51 | leedm777 | Originally, I liked the idea of the JSON blobs being self identifying. But that's turning up some ugly code in several other places. |
| 18:47.12 | Qwell | so, just a bunch of stasis_message_router_add() calls? |
| 18:48.33 | leedm777 | Yeah. And different message types for the different types of messages that could be sent to thesystem topic. |
| 18:48.49 | Qwell | Right, okay. |
| 18:50.36 | leedm777 | But instead of having first class objects associated with the individual message types, there'd be a single blob type they all share. |
| 18:51.01 | leedm777 | opticron mjordan: ^^ thoughts? |
| 18:51.05 | mjordan | I concur. |
| 18:51.21 | mjordan | Qwell: also, I have a manager_system I just made |
| 18:51.36 | mjordan | and jrose already has a generic JSON payload |
| 18:51.46 | mjordan | I'll put this out onto a team branch |
| 18:51.57 | Qwell | hrm |
| 18:52.03 | leedm777 | prepares to watch a merge race |
| 18:52.25 | Qwell | jrose_atDigium: on what review is the generic payload? |
| 18:52.55 | mjordan | Qwell: mjordan/ami-refactorings |
| 18:53.15 | mjordan | also: I made it so all of AMI uses a single message router and forwards all things to a single topic. Otherwise, we'll end up with out of order messages |
| 18:53.16 | jrose_atDigium | I think he means the generic JSON payload. |
| 18:53.41 | mjordan | jrose_atDigium: "has a generic JSON payload" => yes, a payload :-) |
| 18:54.09 | jrose_atDigium | Qwell: https://reviewboard.asterisk.org/r/2481/ |
| 18:54.27 | Qwell | oh, it's already committed. |
| 18:55.34 | mjordan | There is a system topic, and I've added a generic system message that delivers a JSON blob. However, I agree with both you and leedm777 - the message routing based on generic JSON type is hacky |
| 18:59.59 | opticron | concurs that routing on JSON type field is undesirable |
| 19:00.12 | opticron | it has led to at least 2 different ways of handling it |
| 19:00.21 | opticron | the type field |
| 19:00.25 | opticron | one being the if/else stack |
| 19:00.49 | opticron | and the other being a hash table of callbacks associated with the name of the type |
| 19:03.11 | leedm777 | Consensus: routing should be based on the message type. |
| 19:03.22 | opticron | yay! |
| 19:03.23 | jrose_atDigium | Yes, that would be my first instinct anyway. |
| 19:05.12 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 19:05.13 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:06.10 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 19:06.11 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 19:15.28 | mjordan | leedm777: so the question is, do we need a separate message type for each generic message? |
| 19:15.54 | leedm777 | mjordan: yes. At least, I would prefer that to the other options (new/different message router) |
| 19:16.08 | mjordan | hm. The downside there is the inevitable explosion of message type objects. |
| 19:17.02 | jrose_atDigium | Honestly I think that's going to depend on the context. At some level, you can't expect the behavior of how we handle a message not to vary with the contents of the message. |
| 19:17.25 | mjordan | That isn't what I'm implying in the least |
| 19:17.29 | jrose_atDigium | I know |
| 19:18.40 | mjordan | The goal of the generic JSON blob was to not require a payload struct for each message - as there are lots of 'weird' messages. For the most part, that's been successful. However, if you need a message type object for each message, you're pretty close to that point. |
| 19:19.01 | mjordan | leedm777: I wonder if - for AMI - we couldn't just iterate over key value pairs in the JSON |
| 19:19.16 | mjordan | and use a generic handler for things that are just JSON |
| 19:19.24 | leedm777 | mjordan: that assumes that the JSON blob is a flat object. |
| 19:19.28 | mjordan | it does |
| 19:19.56 | mjordan | but so far they all are |
| 19:21.07 | leedm777 | I think that's b/c most of the objects are currently there to support existing AMI messages, which are flat. |
| 19:21.30 | leedm777 | Have a structured data type is a powerful thing. I'd rather not lose that. |
| 19:25.05 | mjordan | I agree, but this feels mostly like an AMI problem - AMI is forcing the proliferation of message types, and it's forcing the sometimes 'interesting' conveyance of data. I'd prefer not to have it force us into a situation we don't want to support, i.e., a whole mess of types that only make sense to it |
| 19:25.50 | mjordan | If we had a field 'this message is AMI-compatible', we could know in a generic parser whether or not that function could create an AMI message directly from it |
| 19:26.55 | leedm777 | mjordan: the message types themselves are very lightweight. What's the problem with having lots of them? just the ceremonial code required for creating them? |
| 19:27.26 | leedm777 | actually, wait, go back. |
| 19:28.06 | leedm777 | What if instead of 'this message is AMI-compatible' there was a single 'this is an AMI message'. |
| 19:28.31 | jrose_atDigium | For things that only currently have one consumer (that being whatever generates AMI events for them) and have no foreseeable need to be consumed elsewhere, I kind of think it might make sense to just stuff them into a generic catch-all message type for AMI stuff. |
| 19:28.34 | leedm777 | I think I see what you're saying. |
| 19:29.53 | leedm777 | chews on it |
| 19:33.48 | leedm777 | Okay. So there's a single ami_event_message_type(), which can be the message type for JSON blobs that have no other purpose than to be sent out as AMI events. |
| 19:34.46 | leedm777 | But for messages that might actually be useful, then we can create a message type for them, so that they can be routed by the message router. |
| 19:35.00 | leedm777 | mjordan: ^^ is that what you're saying? |
| 19:35.28 | mjordan | something along those lines :-) There's multiple ways to get there, but a single message type would be appropriate |
| 19:35.59 | leedm777 | my question is: if an event is that useless, why are we sending it out at all :-P |
| 19:36.03 | mjordan | Initially, there are many things that "only" make sense in AMI, but other people may want to eventually consume their state. It will become something of a judgement call as to how to pull them out from under the AMI message type |
| 19:36.13 | mjordan | leedm777: backwards compatibility. |
| 19:36.21 | leedm777 | pshaw |
| 19:36.35 | mjordan | here's a good example: app_minivm sends out a notification when it has finished pushing out external notifications. app_voicemail does not |
| 19:36.36 | leedm777 | you and your "always thinking of the users" thing |
| 19:36.37 | leedm777 | :-P |
| 19:37.03 | mjordan | does app_minivm need to send that out? Maybe not. But someone put it in there so they could consume it. I can't see it being of use outside of AMI |
| 19:37.21 | leedm777 | And the reason the events go through Stasis at all is b/c of message ordering, right? |
| 19:37.46 | jrose_atDigium | Well, we want to limit calls to directly send manager events to just code that is manager related. |
| 19:38.49 | jrose_atDigium | As opposed to having manager_event calls peppered throughout every module. |
| 19:39.14 | leedm777 | jrose_atDigium: It's still manager specific code, if it's building a ami_event_message |
| 19:40.16 | jrose_atDigium | Arguably this wouldn't be making an AMI event message, it would just be making a stasis message which can be interpreted as an AMI event message by whatever handles that stasis message type. |
| 19:40.30 | jrose_atDigium | It's up to the subscriber to actually turn that into an AMI event. |
| 19:40.49 | opticron | or a res_stasis websocket event as the case may be |
| 19:41.31 | mjordan | leedm777: yes |
| 19:42.01 | mjordan | at this point, the only reason we're doing this is so that you don't get a goofy whatever event before the channel events that caused it |
| 19:43.04 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 19:43.05 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:48.32 | opticron | since we mentioned flatness of the json blobs that tend to accompany messages meant for AMI, Userevent already breaks the capability to be handled in a generic manner (raw manager text embedded in the body key) |
| 19:49.38 | leedm777 | opticron: I don't think we're saying that _everything_ that's going to go out to AMI _has_ to be flat. |
| 19:49.45 | opticron | right |
| 19:49.46 | mjordan | nope |
| 19:50.01 | mjordan | just that if you do provide a flat object, you can post it to the ami_message_type and it will be auto-converted and sent out |
| 19:51.09 | leedm777 | mjordan: but for messages that might have some usefulness outside of AMI, they should have their own message type. |
| 19:52.16 | mjordan | agreed |
| 20:21.07 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 20:28.37 | jsmith | oej, file, putnopvut: Any of you three available for a quick SIP question? |
| 20:28.54 | jsmith | (or anyone else that feels like dipping a toe in the deep dark waters of SIP interop) |
| 20:29.02 | file | I was walking my dog but have returned |
| 20:29.06 | file | what is your question? |
| 20:29.41 | jsmith | I'm trying to get Asterisk to register to an external SIP service -- registrations are failing. I'm able to get it to work by patching Asterisk using the following instructions: http://www.mail-archive.com/sipx-users@list.sipfoundry.org/msg01020.html |
| 20:29.52 | jsmith | Question is -- is Asterisk doing the wrong thing here? |
| 20:30.42 | file | that I can not answer off the top of my head |
| 20:31.42 | jsmith | OK |
| 20:32.00 | jsmith | Looks like I scared off oej :-( |
| 20:33.23 | jsmith | Seems we're generating a new from-tag for each REGISTER request |
| 20:33.49 | file | I know the call id is supposed to be the same, but I don't remember reading that the tag has to be |
| 20:34.42 | jsmith | Someone referenced RFC 3261, section 8.1.3.5. |
| 20:34.46 | jsmith | I guess I should go look that up |
| 20:35.12 | putnopvut | Just got back into the office and catching up on this conersation |
| 20:36.00 | jsmith | Ah, specifically "This new request |
| 20:36.01 | jsmith | <PROTECTED> |
| 20:36.01 | jsmith | <PROTECTED> |
| 20:36.01 | jsmith | <PROTECTED> |
| 20:36.22 | jsmith | putnopvut: No worries -- just looking for another set of eyes on this |
| 20:37.32 | jsmith | thinks that we should have more SHOULDs and more MUSTs in SIP |
| 20:38.01 | *** join/#asterisk-dev saghul_ (~saghul@ip3e830637.speed.planet.nl) |
| 20:38.15 | putnopvut | SHOULD is my least favorite RFC word |
| 20:38.33 | putnopvut | And in close second is RECOMMENDED, only because it's used less. |
| 20:39.13 | mjordan | correct me if I'm wrong, but tags would affect dialogs, whereas this is a REGISTER request |
| 20:39.41 | jsmith | mjordan: Correct, and REGISTERs don't begin a dialog, right? |
| 20:40.30 | *** join/#asterisk-dev alecdavis (~alecdavis@202.36.76.21) |
| 20:40.31 | mjordan | jsmith: no, but I have a feeling that even though this isn't a dialog, we should still be sending a from tag. Since the From header should remain unchanged in a re-transmit, that would imply that it needs to be the same tag (I think) |
| 20:40.47 | putnopvut | But section 8 is general UAS behavior. It doesn't pertain necessarily to dialogs. |
| 20:40.55 | mjordan | right. I'm backtracking now |
| 20:41.03 | putnopvut | So for REGISTER, the recommendation in section 8 should be pertinent |
| 20:41.13 | mjordan | and even non-dialogs have From tags |
| 20:41.19 | jsmith | mjordan: Right... here's what I'm seeing. Asterisk tries to register (initial registration). Server comes back with a 401 auth required. |
| 20:41.37 | putnopvut | I don't think the problem is that we don't include a from-tag. It's that we change it on subsequent retries. |
| 20:41.37 | jsmith | mjordan: We re-attempt the REGISTER with auth, but with a different from-tag. |
| 20:41.54 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 20:41.54 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 20:43.04 | jsmith | The server says something to the effect of "The from-tag in the request I sent the nonce to doesn't match the from-tag on the new request", and denies the registration |
| 20:43.13 | jsmith | putnopvut: That's my understanding as well |
| 20:45.36 | alecdavis | any one care about a BLF stops working forever, well atleast until the phone is reset. |
| 20:45.54 | putnopvut | Well, to be fair to Asterisk, it's only SHOULD strength that we keep the from-tag the same according to 8.1.3.5. |
| 20:46.01 | putnopvut | (See why I hate SHOULD ?) |
| 20:46.35 | jsmith | So, ignore and keep requiring people to patch? Fix? Expose via an option? |
| 20:46.40 | putnopvut | But, if it's really an easy fix like that e-mail implies, we may as well make it to be more compliant since apparently some endpoints will refuse our auth. |
| 20:46.52 | jsmith | It's a one-line removal |
| 20:47.05 | jsmith | is happy to submit a patch |
| 20:47.49 | alecdavis | review2475, fixes the BLF issue. looking for a shipit :) |
| 20:50.21 | mjordan | jsmith: we can reopen the ASTERISK issue |
| 20:50.51 | mjordan | ASTERISK-12117 |
| 20:50.52 | jsmith | mjordan: Ah, is this ASTERISK-12117? |
| 20:50.52 | LieutPants | [ASTERISK-12117] [Status: Reopened] chan_sip creates a new local tag (from-tag) for every register message - https://issues.asterisk.org/jira/browse/ASTERISK-12117 |
| 20:50.53 | jsmith | just found that |
| 20:52.09 | alecdavis | fwiw, at astricon-dev the guy sitting next to me made me aware of 1000's of grandstream's at one of their customers BLF's stop working forever. The reporter of the bug ASTERISK-21677 actually found the issue interlock. it been there since asterisk 1.4 |
| 20:52.10 | LieutPants | [ASTERISK-21677] [Status: Open] NOTIFYs for BLF start queuing up and fail to be sent out - https://issues.asterisk.org/jira/browse/ASTERISK-21677 |
| 20:52.37 | jsmith | mjordan: I've gotta power down the laptop as this plane lands, but I'll try to add more details to that ticket as I'm able |
| 20:53.08 | jsmith | WiFi on airlines is both a blessing and a curse... |
| 20:53.34 | alecdavis | @jsmith: whats with using wifi device on a plane at all? |
| 20:53.39 | mjordan | alecdavis: IIRC, wasn't the change for that (which is needed for compatibility with these phones) essentially because they're non-RFC compliant? I haven't looked at the patch since we talked about it at AstriCon, but I recall it was skirting on the edge |
| 20:54.06 | jsmith | alecdavis: I couldn't sleep :-p |
| 20:54.26 | jsmith | alecdavis: So I figured I'd catch up on my backlog of "I should ask about..." questions for people smarter than myself |
| 20:55.23 | alecdavis | @jsmith, I didn't think wifi was allowed, as it interfers with navigation equipment, definately not here in NZ. |
| 20:55.43 | jsmith | alecdavis: It is here in the USA, as long as the plane is above 10,000 ft |
| 20:56.01 | opticron | anyone having issues hitting origsvn atm? |
| 20:56.20 | file | nope |
| 20:56.26 | opticron | weird |
| 20:56.30 | jsmith | alecdavis: And the internet access is better than what I had at the conference this past week :-( |
| 20:56.55 | jsmith | Catch y'all later... |
| 20:56.55 | opticron | file, from outside the network/vpn? I'm not currently at digium |
| 20:57.14 | file | it is off VPN |
| 20:57.25 | opticron | pokes his webbernets |
| 20:58.07 | opticron | I think I'm going to blame knology border routing problems |
| 20:58.13 | alecdavis | @mjordan, yes the discussion you refer to, is grandstream specific, where the grandstream accepts a uncolicited NOTIFY after a rebbot from a stale subscription. But most of the times the phone has been rebooted would have been because 'a' BLF had stopped working. Which then lead in to the specific 'stale version no' issue on the grandstream. |
| 21:02.01 | alecdavis | @mjordan, review2475 after a failed NOTIFY transaction (due to a network event), removes the subscription, as the RFC says it 'SHOULD'. The phone resubscribes in it's own time, and the BLF magically starts working again. then |
| 21:05.11 | alecdavis | and the reporter has just reported that his devices are not on a LAN but are internet connected, so network outage probability is high. |
| 21:07.18 | alecdavis | the BLF fix, is a simple 1 word change, XMIT_RELIABLE changed to XMIT_CRITICAL, thus the subsription gets removed after it fails. |
| 21:21.02 | mjordan | alecdavis: makes sense to me |
| 21:31.25 | mjordan | leedm777: the more I look at them, the more I think that the really weird events should just be pulled out |
| 21:31.54 | leedm777 | mjordan: pulled out… and put into the trash? |
| 21:32.00 | mjordan | yes |
| 21:32.06 | mjordan | ModuleLoadReport comes to mind |
| 21:32.19 | mjordan | it occurs after dynamic module load, but before fullybooted |
| 21:32.49 | mjordan | which means the odds of catching it are almost non-existent, and it provides load stats that would be better served by an AMI action (if you really cared about the number of dynamic modules we loaded) |
| 21:33.35 | leedm777 | And I bet you get two of them (one for preload, one for normal load) |
| 21:34.24 | leedm777 | The comment is really odd: "If there's a DNS problem in chan_sip, we might not even reach this" |
| 21:34.49 | mjordan | it's very true however... |
| 21:34.57 | mjordan | although obviously written out of frustration :-) |
| 21:35.22 | mjordan | chan_sip during load will try to resolve a DNS hostname. If the DNS never responds, you never get that message |
| 21:35.26 | mjordan | the woes of chan_sip's DNS handling |
| 21:35.39 | mjordan | leedm777: indeed you do get two (if you get them at all) |
| 21:37.36 | mjordan | I see you wrote a wiki page after my 'why do we have a shutdown function' question |
| 21:37.50 | leedm777 | mjordan: yes. yes I did. |
| 21:38.04 | leedm777 | Not the first time the question has come up. |
| 21:38.16 | leedm777 | So I decided it should be the last time I answer it :-) |
| 22:00.23 | leedm777 | mjordan: did we decide to prefix or suffix channel roles in AMI? |
| 22:03.19 | mjordan | prefix |
| 22:03.25 | leedm777 | thx |
| 22:03.27 | mjordan | see the chanspy review |
| 22:04.05 | leedm777 | Actually, that's what I was looking at. |
| 22:04.20 | mjordan | it is in there, right? |
| 22:04.23 | leedm777 | Right. |
| 22:04.25 | mjordan | phew |
| 22:04.52 | leedm777 | Didn't notice the date, so I wasn't sure if it was up to date with the most recent decisions. |
| 22:05.36 | leedm777 | The spec, however, still says "appended with a sequentially increasing integer" :-D |
| 22:10.30 | mjordan | the spec is on my list of things to update this week :-) |
| 22:10.46 | mjordan | I still have to finish up the cluster that is DialEnd versus hangup |
| 22:17.04 | alecdavis | @mjordan, thks, spelling mistakes included :) |
| 22:18.13 | mjordan | alecdavis: for posterity :-) |
| 22:21.14 | alecdavis | @mjordan, regarding notify, how many subscriptions can we have. if a phone is rebooting, it resubscribes, and the subscription lives on, depending on answer, could we exhaust the subscriptions? |
| 22:29.21 | mjordan | alecdavis: There isn't a limit. Eventually, the old subscription's timer would pop and we'd kill it |
| 22:29.45 | mjordan | as far as I can remember there isn't a limit, at any rate. chan_sip sometimes has hidden features |
| 22:34.18 | *** join/#asterisk-dev italorossi (~italoross@187.61.168.117) |
| 22:39.47 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 22:39.47 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 22:48.28 | alecdavis | @wdoekes: you recently comment in email 'I recently patched one of my (opensips) presence servers to *not* expire the subscription after a few unanswered notify's. |
| 22:48.28 | alecdavis | ' |
| 22:50.31 | alecdavis | @wdoekes: that was for review 2475. |
| 22:57.48 | alecdavis | Asterisk's BLF notify system has a network interlock waiting for a response, which if we fail to get a response, the interlock becomes locked (a pendinginvite), with no timeout. The question really is, should we stick to the RFC, which says remove the subscription, or when it fails after 10 retries, clear the pendinginvite. If the device really isn't there the subscribtion will eventually |
| 22:57.49 | alecdavis | timeout and be removed. |
| 23:04.52 | alecdavis | quoting from RFC6665 4.2.2 |
| 23:04.53 | alecdavis | <PROTECTED> |
| 23:04.53 | alecdavis | <PROTECTED> |
| 23:04.53 | alecdavis | <PROTECTED> |
| 23:04.53 | alecdavis | <PROTECTED> |
| 23:04.53 | alecdavis | <PROTECTED> |
| 23:05.05 | WIMPy | Sounds like no driver for that card included. |
| 23:05.10 | WIMPy | oops |
| 23:45.02 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 23:45.02 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
