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

[Hans Erik van Elburg <[e-mail]>]

On Tue, May 4, 2010 at 4:42 PM, Hadriel Kaplan <[e-mail]> wrote:
>
> 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?
>
[HE] Yes you could interpret it like that. But I also think there is
no need for the case where the SSP returns the result, so I would just
suggest to remove that unless there is a use case for which this
information is usefull.

> 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...
>
Yes for normal registrations you may view it like that.

> 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.
>
I do not agree, the location server can together with the location
where the AOR can be reached return information that this is a bulk
contact. That information can be used by the SSP's proxy to apply
proper handling.

> 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.
>
This is a very strange use case, normally you either receive service
from the SSP (centrex scenario) or from the PBX. Mixing those two is
asking for problems. Conflicting service configurations etc. In such a
case the user would rather have two different AOR's.

> 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.
>
The more impportant criterion is if the result that the subscriber
expects is usefull and meaningful. That there will be slight
differences certain behaviours for bulk registrations is completely
OK. And the complexity added is minor really.

/Hans Erik