Re: [martini] New text for gin section 7.1.1 first paragraph

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

Brian,

The proposed text does have an opt-out provision, i.e., if you provide some other means of assigning a globally routable URI on behalf of a UA behind the PBX. I think an SP that doesn't support GRUU will need to do this anyway. 

Suppose some third party wants to do attended transfer, and the transfer target is a UA behind the PBX. The third party will issue a REFER request with Refer-to that results in an INVITE request targeted at the UA behind the SIP-PBX. So a URI targeting that UA is required. One solution to that is for the SIP-PBX to have provided the UA with a GRUU, based on a template from the SP. Another solution is for the UA to use a local contact URI, which the SP B2BUA maps to a globally routable UA (which is basically pre-GRUU normal practice). Either way, the third party receives a globally routable URI that it can place in Refer-To. In other words, I think the SP will need to do one of the two things the proposed text allows.

John 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Brian Lindsay
> Sent: 28 September 2010 19:46
> To: Paul Kyzivat; Hadriel Kaplan
> Cc: [e-mail]
> Subject: Re: [martini] New text for gin section 7.1.1 first paragraph
> 
> Hi,
> 
>   I agree with Hadriel. It seems to be over-stepping the 
> original focus of Martini to mandate GRUU's in some form 
> (even to the extent of the proposed language), given that the 
> services to be supported between the SIP PBX and the SSP (and 
> the interaction between the SSP and other entities) are out of scope. 
> 
>   Thanks
>      Brian 
> 
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Paul Kyzivat
> Sent: Tuesday, September 28, 2010 2:15 PM
> To: Hadriel Kaplan
> Cc: [e-mail]
> Subject: Re: [martini] New text for gin section 7.1.1 first paragraph
> 
> 
> 
> On 9/28/2010 1:32 PM, Hadriel Kaplan wrote:
> >
> > You can look at it that way, or you can look at it a 
> different way: all GIN is (supposed) to be doing is 
> specifying a means to use REGISTER for bulk contacts - a 
> compressed form of sending unique REGISTER requests per UA.  
> GRUU is not mandatory for REGISTER of a single AoR->contact, 
> ergo it shouldn't be necessary for REGISTER of multiple 
> AoR->contacts.  We're specifying a protocol, not a service 
> profile.  The latter is more the SIP Forum's role, for example.
> 
> Yeah. But if we were starting over I'm pretty certain we'd recognize 
> that UAs often don't have globally routable addresses of 
> their own, and 
> would make GRUU mandatory for registrars. Its only historical 
> precedent 
> that we don't have that. Here we have to opportunity not make that 
> mistake again.
> 
> 	Thanks,
> 	Paul
> 
> > -hadriel
> >
> >
> > On Sep 28, 2010, at 12:55 PM, Paul Kyzivat wrote:
> >
> >>
> >>
> >> On 9/28/2010 12:34 PM, Brian Lindsay wrote:
> >>> Hi John/all,
> >>>
> >>>     Whether support for routing of out-of-dialog requests 
> to a contact is required should depend on the service 
> offering of the SSP. For example, SSP support for an 
> out-of-dialog REFER to a contact URI shouldn't be considered 
> mandatory as discussed previously. As such, I think the text 
> proposed should be conditional based on whether such services 
> are supported by the SSP across it's interfaces.
> >>
> >> This implies that the SSP knows and controls all the 
> services that may
> >> be used with its customers.
> >>
> >> 	Thanks,
> >> 	Paul
> >>
> >>>     Here is some alternate proposed text:
> >>>
> >>>
> >>> "Some services may require that entities, outside the SIP 
> PBX, be able to send out-of-dialog requests to a UA behind a 
> SIP-PBX, using a globally routable contact URI. If an SSP 
> supports such services across the SSP interfaces, the SSP 
> MUST support the public GRUU mechanism described in this 
> section, unless the SSP has other means of providing globally 
> routable contact URIs (e.g., by acting as a B2BUA and 
> performing mapping between SIP-PBX-provided local contact 
> URIs and SSP-provided globally routable contact URIs. In such 
> a case the lifetime of the mapping may depend on the services 
> supported by the SSP)."
> >>>
> >>>
> >>>
> >>>     Regards
> >>>         Brian
> >>>
> >>> -----Original Message-----
> >>> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Elwell, John
> >>> Sent: Tuesday, September 28, 2010 5:52 AM
> >>> To: [e-mail]
> >>> Subject: Re: [martini] New text for gin section 7.1.1 
> first paragraph
> >>>
> >>> Martien has privately indicated to me a certain lack of 
> clarity in the proposed text. In thinking about this again, I 
> haven't got the wording quite right. The bulk registration 
> mechanism doesn't register UAs behind the PBX - it registers 
> contacts for each of the AORs assigned to the PBX. What we 
> are concerned about here is contact URIs for UAs behind the 
> PBX. Those UAs register with the PBX, they do not register 
> using the bulk registration mechanism. So my revised words 
> would be as follows (only the first sentence has changed):
> >>>
> >>> "An SSP needs to provide a means of assigning a globally 
> routable contact URI to a UA behind a SIP-PBX, thereby 
> allowing other entities to address out-of-dialog requests to 
> that UA. To achieve this, an SSP MUST support the public GRUU 
> mechanism described in this section, unless the SSP has other 
> means of providing globally routable contact URIs (e.g., by 
> acting as a B2BUA and performing mapping between 
> SIP-PBX-provided local contact URIs and SSP-provided globally 
> routable contact URIs)."
> >>>
> >>> John
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Elwell, John
> >>>> Sent: 28 September 2010 08:44
> >>>> To: 'Martien Huysmans'
> >>>> Subject: RE: New text for gin section 7.1.1 first paragraph
> >>>>
> >>>> Martien,
> >>>>
> >>>> Yes, in thinking about this again, I haven't got the wording
> >>>> quite right. The bulk registration mechanism doesn't register
> >>>> UAs behind the PBX - it registers contacts for each of the
> >>>> AORs assigned to the PBX. What we are concerned about here is
> >>>> contact URIs for UAs behind the PBX. Those UAs register with
> >>>> the PBX, they do not register using the bulk registration
> >>>> mechanism. So my revised words would be as follows (only the
> >>>> first sentence has changed):
> >>>>
> >>>> "An SSP needs to provide a means of assigning globally
> >>>> routable contact URIs to UAs behind a SIP-PBX, thereby
> >>>> allowing other entities to address out-of-dialog requests to
> >>>> those UAs. To achieve this, an SSP MUST support the public
> >>>> GRUU mechanism described in this section, unless the SSP has
> >>>> other means of providing globally routable contact URIs
> >>>> (e.g., by acting as a B2BUA and performing mapping between
> >>>> SIP-PBX-provided local contact URIs and SSP-provided globally
> >>>> routable contact URIs)."
> >>>>
> >>>> John
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Martien Huysmans [mailto:[e-mail]]
> >>>>> Sent: 28 September 2010 08:13
> >>>>> To: Elwell, John
> >>>>> Subject: RE: New text for gin section 7.1.1 first paragraph
> >>>>>
> >>>>> I find this a difficult sentence to understand. Is UA the
> >>>>> SIP-PBX or the UA behind the SIP-PBX. So I propose to add
> >>>>> "behind a SIP-PBX".
> >>>>>
> >>>>> An SSP needs to provide a means of assigning globally
> >>>>> routable contact URIs to UAs behind a SIP-PBX ...
> >>>>>
> >>>>> Regards Martien
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: [e-mail]
> >>>>> [mailto:[e-mail]] On Behalf Of Elwell, John
> >>>>> Sent: Monday, September 27, 2010 9:30 PM
> >>>>> To: [e-mail]
> >>>>> Subject: [martini] New text for gin section 7.1.1 first 
> paragraph
> >>>>>
> >>>>> As actioned on this evening's call, here is my proposed text:
> >>>>>
> >>>>> "An SSP needs to provide a means of assigning globally
> >>>>> routable contact URIs to UAs that have been registered using
> >>>>> the bulk registration mechanism specified in this document,
> >>>>> thereby allowing other entities to address out-of-dialog
> >>>>> requests to those UAs. To achieve this, an SSP MUST support
> >>>>> the public GRUU mechanism described in this section, unless
> >>>>> the SSP has other means of providing globally routable
> >>>>> contact URIs (e.g., by acting as a B2BUA and performing
> >>>>> mapping between SIP-PBX-provided local contact URIs and
> >>>>> SSP-provided globally routable contact URIs)."
> >>>>>
> >>>>> John
> >>>>> _______________________________________________
> >>>>> martini mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/martini
> >>>>>
> >>> _______________________________________________
> >>> martini mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/martini
> >>> _______________________________________________
> >>> martini mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/martini
> >>>
> >> _______________________________________________
> >> martini mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/martini
> >
> >
> _______________________________________________
> martini mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/martini
> _______________________________________________
> martini mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/martini
>