Re: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP"

[David Hancock <[e-mail]>]

Comments at the end...

> -----Original Message-----
> From: Adam Roach [mailto:[e-mail]]
> Sent: Thursday, July 22, 2010 2:57 PM
> To: David Hancock
> Cc: Elwell, John; Bernard Aboba; [e-mail]
> Subject: Re: [martini] Announcement of MARTINI WG last Call on
> "Registration for Multiple Phone Numbers in the SIP"
> 
>   On 7/22/10 9:02 AM, David Hancock wrote:
> > ________________________________________
> > From: Elwell, John [[e-mail]]
> > Sent: Thursday, July 22, 2010 1:27 AM
> > To: David Hancock; Bernard Aboba; [e-mail]
> > Subject: RE: [martini] Announcement of MARTINI WG last Call on
> "Registration for Multiple Phone Numbers in the SIP"
> >
> >> -----Original Message-----
> >> From: [e-mail]
> >> [mailto:[e-mail]] On Behalf Of David Hancock
> >> Sent: 22 July 2010 00:51
> >> To: Bernard Aboba; [e-mail]
> >> Subject: Re: [martini] Announcement of MARTINI WG last Call
> >> on "Registration for Multiple Phone Numbers in the SIP"
> >>
> >> I've reviewed the document and think it is ready for
> >> consideration, pending resolution of the issues described below.
> >>
> >> These issues all have to do with subscribing to reg-event.
> >>
> >> --------------------------------------------------------------
> >> Issue-1:
> >> Section 7.7.2 says...
> >>     If the SSP receives a SUBSCRIBE request for the registration event
> >>     package with a Request-URI that indicates a contact registered via
> >>     the "Bulk Number Contact" mechanism defined in this document, then
> >>     the SSP MUST proxy that SUBSCRIBE to the SIP-PBX in the
> >> same way that
> >>     is would proxy an INVITE bound for that AOR, unless the SSP has and
> >>     can maintain a copy of complete, accurate, and up-to-date
> >> information
> >>     from the SIP-PBX (e.g., through an active back-end subscription).
> >>
> >> How does the SSP handle the SUBSCRIBE to reg-event for an
> >> enterprise user when the SIP-PBX isn't registered? My
> >> understanding of RFC3680 is that if the target user of a
> >> reg-event SUBSCRIBE isn't registered, then the reg-event
> >> subscriber receives a NOTIFY indicating "user not
> >> registered". The subscribe dialog remains active, and if/when
> >> the target user subsequently registers, the reg-event
> >> subscriber receives another NOTIFY containing the
> >> registration data. Would this same process be followed when
> >> the reg-event subscription is to an AOR owned by the SIP-PBX,
> >> and if yes, how does the SSP make that happen?
> > [JRE] Wouldn't the SSP return a 480 response to the SUBSCRIBE request if
> it can't deliver it?
> >
> > [dch] Yes, that would be one way to handle it, although not so friendly
> to the reg-event subscriber. Since for "normal" registrations the SSP
> registrar/proxy doesn't send a 480 response when the target user isn't
> registered, it might be useful if the draft covered this case.
> 
> Well, we don't mandate reg event at the moment (although John has opened
> a ticket on this subject), so mandating that the SSP support it would be
> something quite new. Now, it probably has value to say that the SSP can
> answer the subscription as long as the PBX isn't registered. But I don't
> think we need to mandate any particular behavior.
> 
> Remember, we're defining protocols here, not architectures. We want to
> enable certain behaviors without limiting them or mandating them --
> unless doing so is require for interoperability.
> 
> > If we take this approach where the SSP treats these SUBSCRIBEs like any
> request to be delivered to the SIP-PBX, then what happens to reg-event
> subscriptions to the SIP-PBX when the PBX transitions from registered to
> not-registered? Would they simply expire?
> 
> See RFC 3265, section 3.3.5 (or, for more clarity, rfc3265bis, section
> 4.4.2).
> 

[dch] Interesting.  Your idea being (I assume) that that this mechanism could be used to pass the reg-event subscription back and forth between the SSP network and the SIP-PBX, based on whether the PBX itself is registered or not.  I'm sensitive to your concern about not over-mandating what can be left to implementation. But I think an informative sentence or two on this would be very useful. 

Thanks
David

> /a