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

[Martien Huysmans <[e-mail]>]

The email below contain the following statement:

----
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.
----

I think that SIP Connect 1.1 mentions the combination of a user registered at the PBX 
could have a VoiceMail service from the SSP.

I als remember a previous email from Adam where I asked
  Are you saying that the current martini-gin draft supports an 
  architecture where for sip:[e-mail] the presence server 
  resides at the SSP and where the IPPBX would provide voice services?
and Adam replied:  
  It certainly does. It also supports one in which the presence server resides at the PBX. 
  This also true for voicemail, and pretty much any other service typically 
  provided in the network.

So I am left a little bit puzzled, what the architecture supports.

/Martien
 
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Hans Erik van Elburg
Sent: Wednesday, May 05, 2010 4:08 PM
To: Hadriel Kaplan
Cc: [e-mail]
Subject: Re: [martini] draft-kaplan-martini-vermouth-00: reg-event handling for draft-gin and draft-olive

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
_______________________________________________
martini mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/martini