[martini] De-registration and GIN

David Hancock <D.Hancock@CableLabs.com> Thu, 26 January 2012 01:14 UTC

Return-Path: <D.Hancock@CableLabs.com>
X-Original-To: martini@ietfa.amsl.com
Delivered-To: martini@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2404E11E808C for <martini@ietfa.amsl.com>; Wed, 25 Jan 2012 17:14:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.952
X-Spam-Level: *
X-Spam-Status: No, score=1.952 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 2pTjcfgsyAJt for <martini@ietfa.amsl.com>; Wed, 25 Jan 2012 17:14:34 -0800 (PST)
Received: from ondar.cablelabs.com (ondar.cablelabs.com []) by ietfa.amsl.com (Postfix) with ESMTP id A0F8021F84F8 for <martini@ietf.org>; Wed, 25 Jan 2012 17:14:34 -0800 (PST)
Received: from kyzyl.cablelabs.com (kyzyl []) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q0Q0lGa3029371; Wed, 25 Jan 2012 18:14:30 -0700
Received: from srvxchg.cablelabs.com ( by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 25 Jan 2012 17:47:16 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com)
Received: from srvxchg.cablelabs.com ([]) by srvxchg ([]) with mapi; Wed, 25 Jan 2012 17:52:10 -0700
From: David Hancock <D.Hancock@CableLabs.com>
To: "martini@ietf.org" <martini@ietf.org>
Date: Wed, 25 Jan 2012 17:52:08 -0700
Thread-Topic: De-registration and GIN
Thread-Index: AczbxLfaKJfVsQSET0e1QqFeASCF6g==
Message-ID: <76AC5FEF83F1E64491446437EA81A61F81DF4FC3A3@srvxchg>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_76AC5FEF83F1E64491446437EA81A61F81DF4FC3A3srvxchg_"
MIME-Version: 1.0
X-Approved: ondar
Subject: [martini] De-registration and GIN
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: Thu, 26 Jan 2012 01:14:37 -0000

I have a couple of questions on de-registration and GIN.

RFC 3261 Section 10.2.2 "Removing Bindings" provides a way to remove all contacts bound to a registered AOR.

Here's the text...

   The REGISTER-specific Contact header field value of "*" applies to
   all registrations, but it MUST NOT be used unless the Expires header
   field is present with a value of "0".

      Use of the "*" Contact header field value allows a registering UA
      to remove all bindings associated with an address-of-record
      without knowing their precise values.

Question-1: How is this procedure applied when the AOR-to-contact binding was established using GIN (RFC 6140)? Does the sending PBX include "bnc" in the Contact header? I assume it does not, since "bnc" is a URI parameter and there is no actual contact URI in this case.

On a related topic, RFC 6140 section 5.2 clarifies the interaction between explicit and GIN registration with the following text...

   Although the SSP treats this registration as a number of discrete

   rows for the purpose of re-targeting incoming requests, the renewal,

   expiration, and removal of these rows is bound to the registered

   contact.  In particular, this means that REGISTER requests that

   attempt to de-register a single AOR that has been implicitly

   registered MUST NOT remove that AOR from the bulk registration.  In

   this circumstance, the registrar simply acts as if the UA attempted

   to unregister a contact that wasn't actually registered (e.g., return

   the list of presently registered contacts in a success response).  A

   further implication of this property is that an individual extension

   that is implicitly registered may also be explicitly registered using

   a normal, non-bulk registration (subject to SSP policy).  If such a

   registration exists, it is refreshed independently of the bulk

   registration and is not removed when the bulk registration is


So basically, an explicit de-registration should not impact bindings established via GIN, and vice versa.

For example, PBX sip:pbx1@sp.com serving 4 E.164 numbers uses GIN to bind its extension AORs to two different contact addresses, thus creating the following bindings...

8 GIN bindings...
sip:+13035550001@sp.com --> sip:+13035550001@
sip:+13035550002@sp.com --> sip:+13035550002@
sip:+13035550003@sp.com --> sip:+13035550003@
sip:+13035550004@sp.com --> sip:+13035550004@

sip:+13035550001@sp.com --> sip:+13035550001@
sip:+13035550002@sp.com --> sip:+13035550002@
sip:+13035550003@sp.com --> sip:+13035550003@
sip:+13035550004@sp.com --> sip:+13035550004@

Plus a UA explicitly registers one of the E.164 numbers to two different contact addresses to create the following additional bindings...

2 explicit bindings...
sip:+13035550003@sp.com --> sip:
sip:+13035550003@sp.com --> sip:

Now the PBX or UA can use the "*" construct to delete all of their respective bindings.

[1] from the PBX

   REGISTER sip:sp.com SIP/2.0

   To: <sip:pbx@sp.com>

   From: <sip:pbx@sp.com>

   Proxy-Require: gin

   Require: gin

   Supported: path

   Contact: *

   Expires: 0

[2] from the UA

   REGISTER sip:sp.com SIP/2.0

   To: <sip:+13035550003@sp.com>

   From: <sip:+13035550003@sp.com>

   Contact: *

   Expires: 0

On receiving [1], the SP/registrar removes the 8 GIN bindings without touching the explicit bindings.
On receiving [2], the SP/registrar removes the 2 explicit bindings without touching the GIN bindings.

Since the Contact header doesn't contain a "bnc" parameter in this case, the registrar behavior is governed by the presence/absence of the "gin" option-tag in the Require header.

Question-2 - does the example align with RFC6140?

David Hancock