| 00:01.05 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 00:10.30 | gtjoseph | file: still there? got a sec for an AMI question in kharwell's absence? |
| 00:10.57 | file | sure, although AMI is not my specialty |
| 00:11.34 | gtjoseph | it's a policy question really... is there an expectation that a field will not appear more than once in an event? Example... |
| 00:11.58 | gtjoseph | what if there were multiple 'Contact' fields in an AorDetail |
| 00:12.07 | file | yes, there is that expectation |
| 00:12.08 | gtjoseph | would that break the design? |
| 00:12.20 | gtjoseph | crap |
| 00:13.09 | sgriepentrog | you can number them sequentially, like Contact1, Contact2, ... |
| 00:13.35 | file | yeah and the a field to say how many |
| 00:13.45 | file | geez I am missing letters today |
| 00:13.46 | gtjoseph | not without difficulty since it would have to be generic |
| 00:15.12 | gtjoseph | it's a long story having to do with sorcery_objectset_create, the AST_SORCERY function, and objects with multiple occurances of the same field |
| 00:15.22 | gtjoseph | i'll write something up for the list |
| 00:28.52 | *** join/#asterisk-dev roderickm (~roderickm@99-124-89-102.lightspeed.dctral.sbcglobal.net) |
| 00:40.26 | *** join/#asterisk-dev vtone_ (~vtone@cpc35-bagu10-2-0-cust138.1-3.cable.virginm.net) |
| 00:43.27 | *** join/#asterisk-dev vtone (~vtone@cpc35-bagu10-2-0-cust138.1-3.cable.virginm.net) |
| 01:53.38 | *** join/#asterisk-dev vlad_starkov (~vlad_star@78.182.78.71) |
| 02:03.04 | *** join/#asterisk-dev vtone (~vtone@cpc35-bagu10-2-0-cust138.1-3.cable.virginm.net) |
| 02:27.47 | *** join/#asterisk-dev vtone (~vtone@cpc35-bagu10-2-0-cust138.1-3.cable.virginm.net) |
| 02:45.37 | *** join/#asterisk-dev vtone (~vtone@cpc35-bagu10-2-0-cust138.1-3.cable.virginm.net) |
| 03:53.35 | *** join/#asterisk-dev vlad_starkov (~vlad_star@78.182.78.71) |
| 04:39.26 | *** join/#asterisk-dev mjordan (~matt@nat/digium/x-chyzjvgygrdtebfi) |
| 04:39.26 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 05:24.50 | *** join/#asterisk-dev vtone (~vtone@cpc35-bagu10-2-0-cust138.1-3.cable.virginm.net) |
| 05:53.30 | *** join/#asterisk-dev vlad_starkov (~vlad_star@78.182.78.71) |
| 06:56.05 | *** join/#asterisk-dev vlad_starkov (~vlad_star@78.182.78.71) |
| 07:33.42 | *** join/#asterisk-dev vlad_starkov (~vlad_star@78.182.78.71) |
| 07:37.54 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 07:38.09 | *** join/#asterisk-dev vlad_starkov (~vlad_star@78.182.78.71) |
| 08:16.43 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:e06e:6572:f435:a8fb) |
| 08:53.36 | *** join/#asterisk-dev vlad_starkov (~vlad_star@78.182.78.71) |
| 08:55.40 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:55.40 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:30.26 | *** join/#asterisk-dev vlad_starkov (~vlad_star@78.182.78.71) |
| 09:47.14 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 10:00.52 | *** join/#asterisk-dev vtone (~vtone@cpc35-bagu10-2-0-cust138.1-3.cable.virginm.net) |
| 10:01.50 | *** join/#asterisk-dev vtone (~vtone@cpc35-bagu10-2-0-cust138.1-3.cable.virginm.net) |
| 11:31.32 | *** join/#asterisk-dev vlad_starkov (~vlad_star@78.182.78.71) |
| 11:55.14 | *** join/#asterisk-dev vlad_starkov (~vlad_star@78.182.78.71) |
| 12:02.09 | *** join/#asterisk-dev vlad_starkov (~vlad_star@78.182.78.71) |
| 12:13.45 | *** join/#asterisk-dev kesselklopfer79 (~kesselklo@astaro.starface.de) |
| 12:32.42 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-81-186.user.veloxzone.com.br) |
| 12:35.33 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 13:04.15 | *** join/#asterisk-dev vlad_starkov (~vlad_star@78.182.78.71) |
| 13:28.00 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 13:31.54 | *** join/#asterisk-dev protocoldoug (~doug@unaffiliated/protocoldoug) |
| 13:55.32 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:57.52 | *** join/#asterisk-dev roderickm (~roderickm@99-124-89-102.lightspeed.dctral.sbcglobal.net) |
| 14:03.10 | *** join/#asterisk-dev mjordan (~matt@75.76.55.191) |
| 14:03.10 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:04.40 | *** join/#asterisk-dev vlad_starkov (~vlad_star@78.182.78.71) |
| 14:29.18 | *** join/#asterisk-dev mjordan (~matt@75.76.55.191) |
| 14:29.18 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:29.54 | *** join/#asterisk-dev mjordan (~matt@nat/digium/x-vsmhbqtzzqqujfwd) |
| 14:30.09 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:32.10 | mjordan | file: is there any reason why a Referred-By header would be handled during a SIP 'blind' transfer, but not a SIP 'attended' transfer? |
| 14:32.38 | file | nothing immediately springs to mind |
| 14:32.55 | file | I'd ask putnopvut though |
| 14:40.35 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:40.36 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:46.23 | file | putnopvut, as mjordan asked before you joined: is there any reason why a Referred-By header would be handled during a SIP 'blind' transfer, but not a SIP 'attended' transfer? |
| 14:46.41 | putnopvut | file: Yes |
| 14:46.53 | mjordan | not that we do much with it, we just use it to set a channel variable |
| 14:47.08 | mjordan | putnopvut: since the header can be in the REFER request in either scenario, how come? |
| 14:48.09 | putnopvut | The Referred-By header is a header in the REFER request. It's "duty" is to be copied into the subsequent INVITE that we send to the transfer target. When we do an attended transfer, we don't send an INVITE with replaces after the REFER. The INVITE we send to the transfer target is sent before we have even received a REFER. |
| 14:48.45 | putnopvut | So in a local attended transfer, the Referred-By header has no value since it comes after we're calling the transfer target. |
| 14:48.53 | putnopvut | In a non-local attended transfer, though, it could be used. |
| 14:49.38 | mjordan | putnopvut: we don't actually use the SIPREFERREDBYHDR channel variable in the outbound INVITE |
| 14:49.58 | mjordan | right now, the only thing that happens is we set that channel variable to the URI in the header |
| 14:50.53 | putnopvut | In a blind transfer or non-local attended transfer, we should be adding a Referred-By header in the INVITE we send as a result of the REFER. |
| 14:51.04 | mjordan | k, I'll file something for that |
| 14:51.39 | putnopvut | At least by having it in a channel variable, it becomes possible for a dialplan writer to add the header themselves if they feel the need. |
| 14:51.56 | putnopvut | But we shouldn't be relying on dialplan writers to know the ins and outs of transfer protocols. |
| 14:56.42 | *** join/#asterisk-dev vlad_starkov (~vlad_star@78.182.78.71) |
| 14:57.17 | mjordan | agreed |
| 14:57.33 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 14:58.56 | *** join/#asterisk-dev vlad_starkov (~vlad_star@78.182.78.71) |
| 15:01.52 | *** join/#asterisk-dev roderickm (~roderickm@99-124-89-102.lightspeed.dctral.sbcglobal.net) |
| 15:08.13 | mjordan | putnopvut: how is the external_replaces extension expected to be constructed to support a remote attended transfer? Right now, if we detect that the dialog being replaced is remote, we do a sip blind transfer to that extension. What would a dialplan writer have to do in that extension to complete the transfer? |
| 15:12.34 | mjordan | pops off for just a second |
| 15:19.15 | *** join/#asterisk-dev vlad_starkov (~vlad_star@78.182.78.71) |
| 15:21.55 | *** join/#asterisk-dev sliske_ (~sliske@2607:f0b0:1:6044:58d2:ccc6:17ba:de73) |
| 15:22.18 | putnopvut | mjordan: The dialplan writer is supposed to just have to route the call where he wishes for it to go. The idea is that when the INVITE is sent out, it should have a Replaces header in it so that the transfer will actually complete properly. It's a pretty brittle system to be honest. |
| 15:23.07 | file | extremely |
| 15:28.20 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-xlxsvnosfwyczajn) |
| 15:49.25 | mjordan | I'm not entirely against brittle |
| 15:49.38 | mjordan | particularly when there isn't much of an alternative |
| 15:50.02 | mjordan | I'll get some issues together to test/document it. The problem right now is that if you were looking to support external attended transfers, there isn't much to tell you what you have to do |
| 15:51.11 | *** join/#asterisk-dev dfighter (~someone@arcemu/staff/dfighter) |
| 16:03.48 | *** join/#asterisk-dev newtonr (~newtonr@173-17-135-67.client.mchsi.com) |
| 16:03.48 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 16:07.30 | *** part/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 16:09.01 | *** join/#asterisk-dev roderickm (~roderickm@99-124-89-102.lightspeed.dctral.sbcglobal.net) |
| 16:14.47 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 16:25.13 | *** join/#asterisk-dev otherwiseguy (~otherwise@172.56.11.6) |
| 16:38.14 | mjordan | putnopvut: During a SIP attended transfer, when Alice completes the attended transfer via the REFER request with Replaces, does Asterisk send an INVITE with Replaces to the transfer target, the transfer destination, or both? |
| 16:40.12 | putnopvut | mjordan: is this a remote attended transfer you're referring to/ |
| 16:40.13 | putnopvut | ? |
| 16:41.05 | mjordan | putnopvut: no, local. I would suspect that Asterisk would send the INVITE w/ Replaces to the transfer destination, but I could be wrong |
| 16:41.21 | putnopvut | Asterisk doesn't send an INVITE with replaces at all in that situation. |
| 16:42.08 | mjordan | right, it wouldn't need to as both the transfered/transfer target channels are bridged to the transferer. It can just move the channels around. |
| 16:42.11 | putnopvut | If Alice and Bob are bridged in Asterisk, and Bob transfers Alice to Carol, then when Bob sends the REFER, Asterisk just takes Alice off hold and bridges Alice and Carol without any SIP signaling. |
| 16:42.55 | mjordan | Reconciling RFCs with Asterisk can make things tricky. |
| 16:43.06 | putnopvut | Yes. |
| 16:43.36 | putnopvut | In most call flow diagrams, there's not a single box that Alice, Bob, and Carol are talking through. |
| 16:43.40 | mjordan | ugh. If we got an INVITE w/ Replaces, that'd be because we were one of the legs of someone else's external transfer |
| 16:43.46 | putnopvut | Yes. |
| 16:43.51 | mjordan | do not like. |
| 16:44.41 | putnopvut | Just a sec. I need to go investigate a potentially icy A/C unit. |
| 16:44.53 | mjordan | god speed |
| 16:45.05 | file | hammer. |
| 16:45.22 | file | (my heat pump has some dents) |
| 16:45.34 | Qwell | file: You need to invest in a rubber mallet. |
| 16:45.46 | file | Qwell, ineffective |
| 16:45.58 | Qwell | There are no problems that cannot be solved with a rubber mallet. |
| 16:46.17 | file | Qwell, what about the dent in my can? |
| 16:47.54 | mjordan | file: pound it the other direction |
| 16:48.49 | Qwell | ^^^ |
| 16:49.00 | file | violence! |
| 16:49.03 | mjordan | Anecdote. I once worked with a rather talented if somewhat deranged developer in a small office. He had a hate/hate relationship with a large scale office printer - one of the behemoths. It would routinely break, and he would, of course, be called every time it broke (I somehow avoided it) |
| 16:49.44 | mjordan | The first time, he called the manufacturer of the printer. About 1000 bucks later, it was "fixed", but it was quite the expense to justify, particularly when it then broke again two weeks later. |
| 16:50.02 | mjordan | The next time it broke, he went into a fit of rage on it. Just kicked the everliving shit out of it. |
| 16:50.09 | mjordan | It started working. |
| 16:50.34 | mjordan | He Fonzied the printer. From there on out, everytime it broke, he'd calmly walk out, kick it several times, and walk back to his office. Usually worked. |
| 16:51.04 | file | makes sense |
| 16:59.30 | putnopvut | I'm back. |
| 17:00.53 | putnopvut | So yeah, if we get an INVITE with replaces, we are indeed a leg of someone else's external transfer. We essentially treat it the same as receiving a REFER for a blind transfer. |
| 17:07.31 | *** join/#asterisk-dev vlad_starkov (~vlad_star@78.182.78.71) |
| 17:09.46 | mjordan | In the remote attended transfer scenarios, I'm guessing that we use the external_transfer extension because the Refer-To header may reference a SIP URI that does not correspond to an extension in Asterisk |
| 17:11.20 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 17:11.20 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 17:16.18 | tm1000 | newtonr: ping |
| 17:16.24 | tm1000 | or mjordan ping |
| 17:18.40 | newtonr | howdy! |
| 17:18.43 | newtonr | i think mjordan just left for lunch |
| 17:18.51 | tm1000 | newtonr: you are actually better |
| 17:18.55 | tm1000 | newtonr: for this question |
| 17:18.59 | tm1000 | newtonr: can I pm you |
| 17:19.00 | newtonr | lol |
| 17:19.02 | newtonr | sure! |
| 17:31.52 | *** join/#asterisk-dev sliske_ (~sliske_@2001:4800:780e:510:6c33:9987:ff05:245f) |
| 18:09.14 | *** join/#asterisk-dev chazzam (~chazz@donutokyo.info) |
| 18:52.05 | *** join/#asterisk-dev vlad_starkov (~vlad_star@78.182.78.71) |
| 19:15.19 | *** join/#asterisk-dev vlad_starkov (~vlad_star@78.182.78.71) |
| 19:19.13 | *** join/#asterisk-dev thecardsmith (~doug@unaffiliated/protocoldoug) |
| 19:22.09 | *** join/#asterisk-dev vlad_starkov (~vlad_star@78.182.78.71) |
| 19:34.05 | *** join/#asterisk-dev vlad_starkov (~vlad_star@78.182.78.71) |
| 19:40.27 | *** join/#asterisk-dev protocoldoug (~doug@unaffiliated/protocoldoug) |
| 19:43.56 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 19:48.56 | *** join/#asterisk-dev roderickm (~roderickm@99-124-89-102.lightspeed.dctral.sbcglobal.net) |
| 20:04.37 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:2c2:3801:2677:3ff:fe8f:2730) |
| 20:21.22 | *** join/#asterisk-dev vlad_starkov (~vlad_star@78.182.78.71) |
| 20:37.05 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 20:37.05 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:52.41 | *** join/#asterisk-dev vlad_starkov (~vlad_star@78.182.78.71) |
| 21:06.25 | mjordan | file: putnopvut: Bouncing back to a completely different topic - publish support and outbound subscription support |
| 21:06.39 | putnopvut | let's discuss! |
| 21:06.47 | mjordan | If we went ahead and finished the implementation, I can think of two ways to configure it |
| 21:07.02 | mjordan | (1) We do something similar to outbound-registration, where it's basically it's own separate "thing" |
| 21:07.41 | *** join/#asterisk-dev vlad_starkov (~vlad_star@78.182.78.71) |
| 21:07.53 | mjordan | (2) We have a very small configuration block or configuration entry that says "create an outbound subscription", or "publish to this thing", but instead we defer to some endpoint configuration that defines the authentication/who we subscribe/publish to |
| 21:07.58 | mjordan | for example |
| 21:08.24 | mjordan | for publication, the AoRs entry could have an entry called "publish_to_this = foo", where foo is some other endpoint |
| 21:08.40 | mjordan | mailboxes associated with that AoR would then be published to that endpoint |
| 21:09.00 | mjordan | as well as extension state for channels created for the endpoint associated with that AoR |
| 21:10.17 | mjordan | since an endpoint already defines an outbound_auth entry, if the PUBLISH request needs to be authenticated, it would use the authentication for the endpoint that it published to |
| 21:10.43 | mjordan | and, if we needed to publish to multiple endpoints, we would just have multiple configuration entries (or a comma delineated list) |
| 21:11.02 | mjordan | for outbound subscription, the concept is similar - defer to the endpoint all that we can for outbound_auth, transport, proxy, and the like |
| 21:11.20 | mjordan | and instead have a small configuration block that says "I'm an outbound subscription, and I want to know about these items" |
| 21:11.41 | mjordan | Endpoints would then just have an outbound_subscription entry |
| 21:15.29 | mjordan | silence... |
| 21:16.07 | putnopvut | yes, I'm digesting |
| 21:16.11 | file | same |
| 21:17.39 | mjordan | if you can tell, I'm not a fan of (1). Having to re-define transport, outbound_auth, proxy, and a bunch of other information when it is already defined for an endpoint is meh. I'm okay with that for outbound registrations - as registrations feel a bit "different" - but I can't think of many times where something that has state about an event package isn't something that wouldn't also be an endpoint |
| 21:20.24 | putnopvut | My problem is that to me anyway, it feels a bit off to be configuring a publish_to_this on an AOR in particular. To me, what seems more natural is having an endpoint option that says publish_these_events=simple-message-summary,presence or the like. |
| 21:20.40 | mjordan | I'd be fine with it being an endpoint option |
| 21:20.52 | mjordan | I went with AoR because that's where you configure mailboxes that are solicited |
| 21:21.28 | mjordan | It feels more nature to publish something that already maintains subscription state, as opposed to unsolicited MWI where the state of the mailbox feels only more loosely associated with the endpoint |
| 21:21.37 | mjordan | s/nature/natural |
| 21:21.44 | putnopvut | Right, to understand the rationale behind that, you need to remember that endpoints and AORs are not always a 1-to-1 relationship. Basically, we're saying that anyone that subscribes for simple-message-summary at that AOR gets these mailbox states. |
| 21:22.14 | putnopvut | mailboxes are configured on the AOR because inbound requests will subscribe to that AOR. |
| 21:22.29 | mjordan | right. So if it's an endpoint option, I would expect that for all AoRs that it has, it would publish all of them |
| 21:22.37 | putnopvut | Correct. |
| 21:22.57 | mjordan | this would also keep the outbound_subscribe/publish_to_that_guy options on the endpoint, which I think is better as well |
| 21:23.04 | putnopvut | From my view, having AoR options referring to endpoints seems "backwards". Endpoints have AORs and AORs have contacts. |
| 21:23.11 | mjordan | works for me |
| 21:24.38 | *** join/#asterisk-dev kharwell (~kharwell@107-205-84-6.lightspeed.brhmal.sbcglobal.net) |
| 21:32.42 | file | nods |
| 21:33.17 | mjordan | kicking around the idea of RLS, I'm thinking that would, however, be its own object |
| 21:36.35 | mjordan | which would mean that it would also be able to be published to endpoints. Still thinking about that however. |
| 21:36.54 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-cftxrshhmqcisjnr) |
| 21:37.05 | *** join/#asterisk-dev jrose_atHome (~Jon@24.96.125.235) |
| 21:54.15 | *** join/#asterisk-dev roderickm (~roderickm@99-124-89-102.lightspeed.dctral.sbcglobal.net) |
| 22:07.38 | *** join/#asterisk-dev vlad_starkov (~vlad_star@78.182.78.71) |
| 22:45.48 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 22:46.42 | *** join/#asterisk-dev vtone_ (~vtone@cpc35-bagu10-2-0-cust138.1-3.cable.virginm.net) |
| 23:09.24 | *** join/#asterisk-dev vlad_starkov (~vlad_star@78.182.78.71) |
| 23:10.44 | *** join/#asterisk-dev sgriepentrog (~sgriepent@2602:306:bdc4:84e0:225:d3ff:fe44:4944) |
| 23:22.46 | *** join/#asterisk-dev vtone (~vtone@cpc35-bagu10-2-0-cust138.1-3.cable.virginm.net) |