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

[Brian Lindsay <[e-mail]>]

Hi John,

   For the attended transfer example you point out, depending on how the SSP chooses to implement transfer, you might never see an actual out-of-dialog INVITE targeted to the SIP PBX UA contact (e.g. the baseline SIP Connect 1.1 mechanism for example would use 3PCC). How the SSP implements services and interacts with 3rd party entities shouldn't be of concern to the GIN draft.

   It seems like the attempt is to mandate broader behavior on the SSP than is required to support the actual GIN mechanism.  

   Thanks
       Brian   


-----Original Message-----
From: Elwell, John [mailto:[e-mail]] 
Sent: Tuesday, September 28, 2010 3:51 PM
To: Brian Lindsay; Paul Kyzivat; Hadriel Kaplan
Cc: [e-mail]
Subject: RE: [martini] New text for gin section 7.1.1 first paragraph

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
>