Re: [martini] draft-kaplan-martini-vermouth-00: reg-event handling for draft-gin and draft-olive

["Elwell, John" <[e-mail]>]

Hadriel,

I am concerned that it is somewhat counter-intuitive from a subscriber point of view to have to put in a special parameter to get to the PBX. I am not sure how the reg-event package is used in practice, but suppose some presence-like application is using reg-event to see whether any device is currently registered for a user. It is not aware that +12345 is behind a PBX, so it subscribes to reg-event at +12345, without any special parameter, gets back the contact sip:+12345@192.168.0.8, and concludes yes, there is a device present. Yet behind the PBX, there may be no device registered against +12345.

John


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Hadriel Kaplan
> Sent: 04 May 2010 15:43
> To: Hans Erik van Elburg
> Cc: [e-mail]
> Subject: Re: [martini] draft-kaplan-martini-vermouth-00: 
> reg-event handling for draft-gin and draft-olive
> 
> 
> Hi Hans Erik,
> I _think_ what you're saying is: for the case where a 
> SUBSCRIBE is targeted to an AoR the PBX implicitly registered 
> for, it should be routed to the PBX; and for the case where 
> we want the SSP to process it itself, we should define a new 
> target syntax, such as the "bnc" param I use in the draft.  
> In other words, swap those two cases in the draft from a 
> target URI perspective.
> 
> Correct?
> 
> Obviously that's also a reasonable way to go, but I'd like to 
> make that an open issue/decision for WG consensus.
> 
> Personally I prefer it the way in the current vermouth draft: 
> a SUBSCRIBE targeted to the AoR gets processed by the SSP 
> just like any other, while a SUBSCRIBE to the AoR with a URI 
> param of "bnc" gets routed to the PBX.
> 
> My reasoning is as follows:
> Currently, for any "normal" Registration model, a SUBSCRIBE 
> targeted to the AoR gets processed by the SSP.  In effect, 
> the combination of that target URI and the "reg" event 
> package indicator are used as a resource identifier for 
> getting the SSP's registration state of that AoR.  So...
> 
> 1) Currently, since the SUBSCRIBE's target URI looks like any 
> other AoR of the SSP, *any* proxy in the SSP can make a 
> simple routing decision to send all SUBSCRIBEs for reg-event 
> to a specific app server which handles reg-event, without 
> knowing what "type" of AoR the target URI refers to.  If we 
> make SUBSCRIBEs for implicitly registered AoRs route 
> differently, without some specific indication in the 
> SUBSCRIBE, then that's no longer as simple a thing to do.
> 
> 2) It really is possible for the SSP to support multiple 
> contacts for any AoR in the set of implicitly registered 
> AoRs.  It's not common of course, but I could see an SSP 
> wanting to offer their customers to Register one or more of 
> those same numbers for home-office or traveling users.  Those 
> users really will be Registered in the SSP, not the PBX.  And 
> the SSP really will have legitimate, "normal" registration 
> state for that same AoR which is also Registered implicitly 
> by the PBX.  So for that case the SUBSCRIBE being routed 
> differently than normal is really screwed up.
> 
> 3) Personally, I think in hindsight it was a mistake to have 
> SUBSCRIBEs for a target URI route differently than any other 
> request for that same target URI, and route differently for 
> different event packages.  That ship has sailed, obviously, 
> and all kinds of method-specific and header-specific routing 
> occurs in the real world - but it would be nice not to add 
> yet more complexity by having different routing for a 
> combination of {method + event + AoR-type}.  It's not a huge 
> deal, since we're already down that rabbit hole, but still it 
> would be nice.
> 
> -hadriel
> 
> 
> > -----Original Message-----
> > From: Hans Erik van Elburg [mailto:[e-mail]]
> > Sent: Tuesday, May 04, 2010 1:04 AM
> > To: Hadriel Kaplan
> > Cc: [e-mail]
> > Subject: Re: [martini] draft-kaplan-martini-vermouth-00: reg-event
> > handling for draft-gin and draft-olive
> > 
> > Hi Hadriel,
> > 
> > Having thought about this a bit more, I do think that the what would
> > suffice is having the following usages:
> > 
> >   5.    Subscribing for Registration State Resources
> >       5.1.   Subscribing to AoRs
> > Where it is in fact "Subscribing to state in the IP-PBX".
> > 
> >       5.2.   Subscribing for all implicitly registered 
> AoRs..........8
> > As is.
> > 
> > As 5.1 is usefull for other UA's the result will not 
> surprise them and
> > it will be usefull information.
> > 5.2 is useful for the PBX to monitor its own registration state.
> > 
> > Then there is no need for SUBSCRIBES with awkward bnc parameters.
> > I know this violates the principle that this is a normal 
> registration,
> > but that is because it is not a normal registration.
> > 
> > Curious if you think this could be a way forward.
> > 
> > /Hans Erik van Elburg
> > 
> > On Mon, May 3, 2010 at 11:43 PM, Hans Erik van Elburg
> > <[e-mail]> wrote:
> > > There is some valid ideas in this and with some work it 
> could be made
> > > to work with several different mechanisms. This does not 
> have to be
> > > gin specific.
> > >
> > > Some issues/questions:
> > > - the use of the bnc tag to address the AOR behind the PBX seems
> > > counterintuitive, as one is in fact in this case 
> addressing a normal
> > > registration...
> > > - the use of a special tag to mint subscription requests 
> to address
> > > the AOR behind the PBX assumes knowledge at the 
> subscriber about the
> > > AOR's terminating arrangement. This is in general 
> problematic. As such
> > > arrangement should be possible to be freely changed by 
> the receiving
> > > company, without notifying potential originators. Not to 
> mention the
> > > security issues with revealing the connection topology.
> > > - can there be more range parameters?
> > > - can the range parameter be injected at any place in a 
> string or only
> > > at the end of the user part?
> > > - regarding 5.4 open issue, yes bulk AOR's are only short hand
> > > representation of ranges registered. They themselves are not
> > > registered and should not be used as AOR's themselves and 
> therefore
> > > section 5.4 should be removed. And some statement should be made
> > > somewhere that bulk AOR's can not be used as normal 
> AOR's. In IMS we
> > > call this wildcarded PUI and those can only be used to 
> match distinct
> > > PUI's with, same here maybe it is better to talk about wildcarded
> > > AOR's as it expresses this property better.
> > > - statements (for ex. 5.1) like "Any internal 
> optimization performed
> > > by the SSP location-service database for handling 
> Bulk-AoRs MUST NOT
> > > change this external behavior. " Are not referring to the 
> SUBSCRIBE
> > > mechanism and therefore inappropriate repetition of an 
> opinion in this
> > > draft ;-)
> > > - Appendix A: While I have no problem with simplifying 
> the pattern, to
> > > enable less configuration errors and complaince with RFC3261. You
> > > bring back here the issue of automatically detecting provisioning
> > > mismatches by the PBX. Is this based on something you have seen in
> > > practice? Why would this be an issue at all? Even in the 
> simplified
> > > case I don not think that an IP-PBX can conclude anything 
> when it has
> > > knowledge about the full generated set of AOR's. It 
> suffices to match
> > > each configured AOR with the patterns returned.
> > >
> > > /Hans Erik van Elburg
> > >
> > > On Mon, May 3, 2010 at 9:27 PM, Hadriel Kaplan 
> <[e-mail]>
> > wrote:
> > >>
> > >> Howdy,
> > >> I have submitted a new draft strawman proposal for 
> reg-event which
> > tries to accomplish the following:
> > >> 1) Gives reg-event for open-numbering-plans
> > >> 2) Subscribes for AoRs *in* the PBX, vs. just SSP's
> > >> 3) Subscribes for all implicitly registered AoRs (e.g., 
> so PBX can
> > check it)
> > >> 4) Creates an acronym for Vermouth
> > >>
> > >> Any comments/flames welcomed.
> > >>
> > >> -hadriel
> > >>
> > >>
> > >> A New Internet-Draft is available from the on-line 
> Internet-Drafts
> > directories.
> > >>
> > >>        Title           : SIP MARTINI Variant of 
> 'Event-package for
> > Registrations' for Managed Open-ended Username Target 
> Handling (VERMOUTH)
> > >>        Author(s)       : H. Kaplan, et al.
> > >>        Filename        : draft-kaplan-martini-vermouth-00.txt
> > >>        Pages           : 19
> > >>        Date            : 2010-05-03
> > >>
> > >> The Martini Working Group is defining a mechanism for 
> SIP IP-PBX type
> > devices to REGISTER and obtain SIP service for E.164-based 
> Address of
> > Records, in [draft-gin].  Another draft [draft-olive] 
> proposes the same
> > for non-E.164-based AoRs.  This document defines a variant of the
> > Registration Event-package [reg-event] for open-ended AoRs 
> for either
> > mechanisms, using a wildcard syntax and specific target 
> handling rules.
> > >>
> > >> A URL for this Internet-Draft is:
> > >> 
> http://www.ietf.org/internet-drafts/draft-kaplan-martini-vermouth-
> > 00.txt
> > >>
> > >> Internet-Drafts are also available by anonymous FTP at:
> > >> ftp://ftp.ietf.org/internet-drafts/
> > >>
> > >> Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> > >>
> > >>
> > >> _______________________________________________
> > >> martini mailing list
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/martini
> > >>
> > >
> _______________________________________________
> martini mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/martini
>