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

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Wed, 29 September 2010 14:27 UTC

Return-Path: <keith.drage@alcatel-lucent.com>
X-Original-To: martini@core3.amsl.com
Delivered-To: martini@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B78CB3A6B36 for <martini@core3.amsl.com>; Wed, 29 Sep 2010 07:27:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.004
X-Spam-Level:
X-Spam-Status: No, score=-103.004 tagged_above=-999 required=5 tests=[AWL=-0.755, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bw+v9tUh7rT for <martini@core3.amsl.com>; Wed, 29 Sep 2010 07:27:27 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 4EE0C3A6A9A for <martini@ietf.org>; Wed, 29 Sep 2010 07:27:26 -0700 (PDT)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o8TERnvD002251 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 29 Sep 2010 16:28:05 +0200
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 29 Sep 2010 16:27:47 +0200
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
Date: Wed, 29 Sep 2010 16:27:45 +0200
Thread-Topic: [martini] New text for gin section 7.1.1 first paragraph
Thread-Index: ActfMys6JivDKYOUQSa0eXMhqMBF1wAruRWg
Message-ID: <EDC0A1AE77C57744B664A310A0B23AE2173A6937@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
References: <A444A0F8084434499206E78C106220CA01C81C2B32@MCHP058A.global-ad.net> <B1771F0F1F97A8478E2F449EA19CC7C5DA1A7EB3@ESESSCMS0365.eemea.ericsson.se> <A444A0F8084434499206E78C106220CA01C81C2D93@MCHP058A.global-ad.net> <F1A0ED6425368141998E077AC43334E425B8D6F6@gbplmail02.genband.com> <4CA21DF2.5080709@cisco.com> <DD8DA2BD-997C-420F-965F-98D9EEC7C6E9@acmepacket.com>
In-Reply-To: <DD8DA2BD-997C-420F-965F-98D9EEC7C6E9@acmepacket.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80
Cc: "martini@ietf.org" <martini@ietf.org>
Subject: Re: [martini] New text for gin section 7.1.1 first paragraph
X-BeenThere: martini@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/martini>
List-Post: <mailto:martini@ietf.org>
List-Help: <mailto:martini-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Sep 2010 14:27:28 -0000

I disagree.

In my view MARTINI is not defining a real registrar behaviour. The real registrar for the URI is in the PBX. What MARTINI is defining is some substitute behaviour (that happens to use a registrar in the SSP) for normal SIP routeing in order to reach the real registrar, WITH ALL THE INFORMATION the real registrar needs to do its job. Normal SIP routing does this. MARTINI should not provide a mechanism where suddenly you have a means of opting out of doing this.

regards

Keith 

> -----Original Message-----
> From: martini-bounces@ietf.org 
> [mailto:martini-bounces@ietf.org] On Behalf Of Hadriel Kaplan
> Sent: Tuesday, September 28, 2010 6:33 PM
> To: Paul Kyzivat
> Cc: martini@ietf.org
> Subject: Re: [martini] New text for gin section 7.1.1 first paragraph
> 
> 
> 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.
> 
> -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: martini-bounces@ietf.org 
> [mailto:martini-bounces@ietf.org] On 
> >> Behalf Of Elwell, John
> >> Sent: Tuesday, September 28, 2010 5:52 AM
> >> To: martini@ietf.org
> >> 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:martien.huysmans@ericsson.com]
> >>>> 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: martini-bounces@ietf.org
> >>>> [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John
> >>>> Sent: Monday, September 27, 2010 9:30 PM
> >>>> To: martini@ietf.org
> >>>> 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
> >>>> martini@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/martini
> >>>> 
> >> _______________________________________________
> >> martini mailing list
> >> martini@ietf.org
> >> https://www.ietf.org/mailman/listinfo/martini
> >> _______________________________________________
> >> martini mailing list
> >> martini@ietf.org
> >> https://www.ietf.org/mailman/listinfo/martini
> >> 
> > _______________________________________________
> > martini mailing list
> > martini@ietf.org
> > https://www.ietf.org/mailman/listinfo/martini
> 
> _______________________________________________
> martini mailing list
> martini@ietf.org
> https://www.ietf.org/mailman/listinfo/martini
>