[martini] pkyzivat@alum.mit.edu; adam@nostrum.com; HKaplan@acmepacket.com; g.russell@cablelabs.com

David Hancock <D.Hancock@CableLabs.com> Tue, 31 January 2012 07:10 UTC

Return-Path: <D.Hancock@CableLabs.com>
X-Original-To: martini@ietfa.amsl.com
Delivered-To: martini@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D0321F8748 for <martini@ietfa.amsl.com>; Mon, 30 Jan 2012 23:10:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.141
X-Spam-Level:
X-Spam-Status: No, score=0.141 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRI2ADi71Uib for <martini@ietfa.amsl.com>; Mon, 30 Jan 2012 23:10:31 -0800 (PST)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAEC21F873C for <martini@ietf.org>; Mon, 30 Jan 2012 23:10:30 -0800 (PST)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q0V77dKt030911 for <martini@ietf.org>; Tue, 31 Jan 2012 00:07:40 -0700
Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 31 Jan 2012 00:07:39 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com)
Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 31 Jan 2012 00:07:39 -0700
From: David Hancock <D.Hancock@CableLabs.com>
To: "martini@ietf.org" <martini@ietf.org>
Date: Tue, 31 Jan 2012 00:07:38 -0700
Thread-Topic: pkyzivat@alum.mit.edu; adam@nostrum.com; HKaplan@acmepacket.com; g.russell@cablelabs.com
Thread-Index: AQHM3+cDjKN5JFxtME6mIXfEreYFXQ==
Message-ID: <76AC5FEF83F1E64491446437EA81A61F81DF5C7E84@srvxchg>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_76AC5FEF83F1E64491446437EA81A61F81DF5C7E84srvxchg_"
MIME-Version: 1.0
X-Approved: ondar
Subject: [martini] pkyzivat@alum.mit.edu; adam@nostrum.com; HKaplan@acmepacket.com; g.russell@cablelabs.com
X-BeenThere: martini@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 31 Jan 2012 07:10:34 -0000

Another GIN question...

Section 10.3 of RFC 3261 says that the 200OK response to a REGISTER request MUST return all current bindings in the Contact header field.

Here's the text...


     8.  The registrar returns a 200 (OK) response.  The response MUST

         contain Contact header field values enumerating all current

         bindings.  Each Contact value MUST feature an "expires"

         parameter indicating its expiration interval chosen by the

         registrar.  The response SHOULD include a Date header field.



What does this mean for GIN registration? Does it mean that the registrar should return the full list of contact addresses that were bound to the implicitly registered AORs? Or, should it return only the contact address that was specified in the REGISTER Contact header field? I think the later behavior is correct.



For example, say a SIP-PBX registers to 2 different contact addresses. First, the SIP-PBX identified in the To: header field of [1] registers to the Contact address identified in [1]. Response [2] contains the single registered contact address, even though the multiple implicitly registered AORs were bound to multiple contacts. Then, the same PBX registers to a 2nd contact address in [3]. Response [4] now shows two contact addresses; one for each of the currently registered bindings for the SIP-PBX.



 SIP-PBX                              SP-SSE

 ---------                               --------

 PBX registers 1st time...

 [1] --REGISTER-->

        To: sip:pbx1@sp.com

        Contact: <sip:10.10.10.1;bnc>



 [2] <--200OK --

          To: sip:pbx1@sp.com

          Contact: <sip:10.10.10.10;bnc>



 PBX registers 2nd time to a different contact address...

 [3] --REGISTER-->

        To: sip:pbx1@sp.com

        Contact: <sip:192.168.2.1;bnc>



 [4] <--200OK --

          To: sip:pbx1@sp.com

          Contact: <sip:192.168.2.1;bnc>, <sip:10.10.10.10;bnc>


Would appreciate your input on a) is the above example correct, and b) do we need an errata to RFC6140 to clarify this case?

Thanks
David