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

Brian Lindsay <brian.lindsay@genband.com> Tue, 28 September 2010 16:36 UTC

Return-Path: <brian.lindsay@genband.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 92C483A6D6C for <martini@core3.amsl.com>; Tue, 28 Sep 2010 09:36:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.427
X-Spam-Level:
X-Spam-Status: No, score=-6.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 PTAoYh-bcWsa for <martini@core3.amsl.com>; Tue, 28 Sep 2010 09:36:02 -0700 (PDT)
Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 042063A6BA7 for <martini@ietf.org>; Tue, 28 Sep 2010 09:35:57 -0700 (PDT)
Received: from source ([63.149.188.88]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTKIZlSK9Ub7EwfcTcetvpnrmsoGpNioG@postini.com; Tue, 28 Sep 2010 09:36:44 PDT
Received: from owa.genband.com ([172.16.21.97]) by mail.genband.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Sep 2010 11:34:37 -0500
Received: from GBEX02.genband.com (172.16.21.98) by GBEX01.genband.com (172.16.21.91) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 28 Sep 2010 11:34:32 -0500
Received: from GBPLMAIL02.genband.com ([fe80::9455:4039:582f:aee8]) by gbex02.genband.com ([fe80::d970:2fee:a0c2:9f26%15]) with mapi id 14.01.0218.012; Tue, 28 Sep 2010 11:34:32 -0500
From: Brian Lindsay <brian.lindsay@genband.com>
To: "Elwell, John" <john.elwell@siemens-enterprise.com>, "martini@ietf.org" <martini@ietf.org>
Thread-Topic: New text for gin section 7.1.1 first paragraph
Thread-Index: ActeemFTQEqRNqg7RASa/wirvRetywAYZCXQAAD2KYAAAUJcsAAKSymw
Date: Tue, 28 Sep 2010 16:34:31 +0000
Message-ID: <F1A0ED6425368141998E077AC43334E425B8D6F6@gbplmail02.genband.com>
References: <A444A0F8084434499206E78C106220CA01C81C2B32@MCHP058A.global-ad.net> <B1771F0F1F97A8478E2F449EA19CC7C5DA1A7EB3@ESESSCMS0365.eemea.ericsson.se> <A444A0F8084434499206E78C106220CA01C81C2D93@MCHP058A.global-ad.net>
In-Reply-To: <A444A0F8084434499206E78C106220CA01C81C2D93@MCHP058A.global-ad.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [47.128.38.35]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 28 Sep 2010 16:34:37.0462 (UTC) FILETIME=[0A808B60:01CB5F2B]
X-TM-AS-Product-Ver: SMEX-8.0.0.4160-6.500.1024-17672.000
X-TM-AS-Result: No--30.315400-5.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
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: Tue, 28 Sep 2010 16:36:03 -0000

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.

   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