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

Adam Roach <adam@nostrum.com> Thu, 22 July 2010 20:56 UTC

Return-Path: <adam@nostrum.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 AFF763A68CD for <martini@core3.amsl.com>; Thu, 22 Jul 2010 13:56:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001]
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 r18yhOygtDdA for <martini@core3.amsl.com>; Thu, 22 Jul 2010 13:56:41 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 6609D3A67B1 for <martini@ietf.org>; Thu, 22 Jul 2010 13:56:41 -0700 (PDT)
Received: from 200.98.240.10.in-addr.arpa (mb90736d0.tmodns.net [208.54.7.185]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o6MKurc5088754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jul 2010 15:56:55 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <4C48B090.3040206@nostrum.com>
Date: Thu, 22 Jul 2010 15:56:48 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1
MIME-Version: 1.0
To: David Hancock <D.Hancock@CableLabs.com>
References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl> <76AC5FEF83F1E64491446437EA81A61F7CF4F16563@srvxchg>, <A444A0F8084434499206E78C106220CAECCCC458@MCHP058A.global-ad.net> <76AC5FEF83F1E64491446437EA81A61F7CF4B0488F@srvxchg>
In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CF4B0488F@srvxchg>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 208.54.7.185 is authenticated by a trusted mechanism)
Cc: Bernard Aboba <bernard_aboba@hotmail.com>, "martini@ietf.org" <martini@ietf.org>
Subject: Re: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP"
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: Thu, 22 Jul 2010 20:56:42 -0000

  On 7/22/10 9:02 AM, David Hancock wrote:
> ________________________________________
> From: Elwell, John [john.elwell@siemens-enterprise.com]
> Sent: Thursday, July 22, 2010 1:27 AM
> To: David Hancock; Bernard Aboba; martini@ietf.org
> Subject: RE: [martini] Announcement of MARTINI WG last Call on "Registration for Multiple Phone Numbers in the SIP"
>
>> -----Original Message-----
>> From: martini-bounces@ietf.org
>> [mailto:martini-bounces@ietf.org] On Behalf Of David Hancock
>> Sent: 22 July 2010 00:51
>> To: Bernard Aboba; martini@ietf.org
>> 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).

/a