From D.Hancock@CableLabs.com Wed Jan 25 17:14:37 2012 Return-Path: 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 2404E11E808C for ; 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pTjcfgsyAJt for ; Wed, 25 Jan 2012 17:14:34 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id A0F8021F84F8 for ; Wed, 25 Jan 2012 17:14:34 -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 q0Q0lGa3029371; Wed, 25 Jan 2012 18:14:30 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) 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 ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 25 Jan 2012 17:52:10 -0700 From: David Hancock To: "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 X-MS-Has-Attach: X-MS-TNEF-Correlator: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 01:14:37 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F81DF4FC3A3srvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 co= ntacts 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 w= as 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 an= d 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 removed. So basically, an explicit de-registration should not impact bindings establ= ished via GIN, and vice versa. For example, PBX sip:pbx1@sp.com serving 4 E.164 numbers uses GIN to bind i= ts extension AORs to two different contact addresses, thus creating the fol= lowing bindings... 8 GIN bindings... sip:+13035550001@sp.com --> sip:+13035550001@192.158.10.1 sip:+13035550002@sp.com --> sip:+13035550002@192.158.10.1 sip:+13035550003@sp.com --> sip:+13035550003@192.158.10.1 sip:+13035550004@sp.com --> sip:+13035550004@192.158.10.1 sip:+13035550001@sp.com --> sip:+13035550001@192.158.20.1 sip:+13035550002@sp.com --> sip:+13035550002@192.158.20.1 sip:+13035550003@sp.com --> sip:+13035550003@192.158.20.1 sip:+13035550004@sp.com --> sip:+13035550004@192.158.20.1 Plus a UA explicitly registers one of the E.164 numbers to two different co= ntact addresses to create the following additional bindings... 2 explicit bindings... sip:+13035550003@sp.com --> sip:192.158.30.1 sip:+13035550003@sp.com --> sip:192.158.40.1 Now the PBX or UA can use the "*" construct to delete all of their respecti= ve bindings. [1] from the PBX REGISTER sip:sp.com SIP/2.0 To: From: Proxy-Require: gin Require: gin Supported: path Contact: * Expires: 0 [2] from the UA REGISTER sip:sp.com SIP/2.0 To: From: Contact: * Expires: 0 On receiving [1], the SP/registrar removes the 8 GIN bindings without touch= ing 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, th= e registrar behavior is governed by the presence/absence of the "gin" optio= n-tag in the Require header. Question-2 - does the example align with RFC6140? Thanks David Hancock --_000_76AC5FEF83F1E64491446437EA81A61F81DF4FC3A3srvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I have a couple of questions on de-registration a= nd 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…

 

&n= bsp;  The REGISTER-specific Contact header field value of "*"= ; applies to

   all registrations, but = it MUST NOT be used unless the Expires header

&nb= sp;  field is present with a value of "0".=

 

      Us= e of the "*" Contact header field value allows a registering UA

      to remove all bindi= ngs associated with an address-of-record

 &n= bsp;    without knowing their precise values.

 

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

 

On a relate= d topic, RFC 6140 section 5.2 clarifies the interaction between explicit an= d GIN registration with the following text…

 

   Although the SSP treats th=
is registration as a number of discrete
   r=
ows for the purpose of re-targeting incoming requests, the renewal,
   expiration, and removal of these rows is bound t=
o the registered
   contact.  In partic=
ular, this means that REGISTER requests that
 &nb=
sp; attempt to de-register a single AOR that has been implicitly=

   registered MUST NOT remove that AOR from the bulk r=
egistration.  In
   this circumstance, =
the registrar simply acts as if the UA attempted
 =
;  to unregister a contact that wasn't actually registered (e.g., retu=
rn
   the list of presently registered conta=
cts in a success response).  A
   furth=
er implication of this property is that an individual extension<=
/pre>
   that is implicitly registered may also be explicitly=
 registered using
   a normal, non-bulk regi=
stration (subject to SSP policy).  If such a
&nbs=
p;  registration exists, it is refreshed independently of the bulk
   registration and is not removed when the bul=
k registration is
   removed.
 
So basical=
ly, an explicit de-registration should not impact bindings established via =
GIN, and vice versa.
 
For example, PBX sip:pbx=
1@sp.com serving 4 E.164 numbers uses GIN to bind its extension AORs to=
 two different contact addresses, thus creating the following bindings̷=
0;
 
8 GIN bindings…
sip:+13035550=
001@sp.com --> sip:+13035550001@192.158.10.1
sip:+13035550002@sp.com --> sip:+13035550002@192.158.10.1
sip:+13035550003@sp.com --> sip:+1303555000=
3@192.158.10.1
sip:+13035550004@sp.com -=
-> sip:+13035550004@192.158.10.1
 
sip:+13035550001@sp.com --> sip:+1=
3035550001@192.158.20.1
sip:+13035550002=
@sp.com --> sip:+13035550002@192.158.20.1
sip:+13035550003@sp.com --> sip:+13035550003@192.158.20.1
sip:+13035550004@sp.com --> sip:+13035550004@1=
92.158.20.1
 
Plus a UA explicitly registers one of the E.164 numbers to tw=
o different contact addresses to create the following additional bindings&#=
8230;
 
2 explicit bindings…
sip:+=
13035550003@sp.com --> sip:192.158.30.1=
 
sip:+13035550003@sp.com --> sip:192.158.40.1
 
Now the PBX or UA can use the =
"*" construct to=
 delete all of their respective bindings.
 
[1] from the PBX
 &nb=
sp; REGISTER sip:sp.com SIP/2.0
   To: <<=
a href=3D"sip:pbx@sp.com">sip:pbx@sp.com>
 =
;  From: <sip:pbx@sp.com>
   Proxy-Require: gin
 &n=
bsp; Require: gin
   Supported: path
   Contact: *
   Exp=
ires: 0
 
[2] =
from the UA 
   REGISTER sip:sp.com SIP=
/2.0
   To: <sip:+13035550003@sp.com>
   F=
rom: <sip:+13035550003@sp.com>=
;
   Contact: *
 &=
nbsp; Expires: 0
 
=

On receiving [1], the SP/registrar removes the 8 GIN b=
indings 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 th=
e Require header.
 
<=
p class=3DMsoNormal>Question-2 – does the example align with RFC6140?=

 
Thanks
David Hancock
 
 
 
=
 
= --_000_76AC5FEF83F1E64491446437EA81A61F81DF4FC3A3srvxchg_-- From pkyzivat@alum.mit.edu Wed Jan 25 19:33:40 2012 Return-Path: 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 8B92A11E80DE for ; Wed, 25 Jan 2012 19:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.614 X-Spam-Level: X-Spam-Status: No, score=-2.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599] 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 TT1OgSS-LIhV for ; Wed, 25 Jan 2012 19:33:39 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7A53511E80CD for ; Wed, 25 Jan 2012 19:33:39 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta07.westchester.pa.mail.comcast.net with comcast id S3Tz1i0030ldTLk573ZfuJ; Thu, 26 Jan 2012 03:33:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta04.westchester.pa.mail.comcast.net with comcast id S3Za1i02007duvL3Q3Zdha; Thu, 26 Jan 2012 03:33:39 +0000 Message-ID: <4F20C98F.4020704@alum.mit.edu> Date: Wed, 25 Jan 2012 22:33:35 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: David Hancock References: <76AC5FEF83F1E64491446437EA81A61F81DF4FC3A3@srvxchg> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F81DF4FC3A3@srvxchg> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "martini@ietf.org" Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 03:33:40 -0000 David, ISTM that deregistering "*" should deregister everything - gin or not, for multiple reasons: - what you propose would make it cumbersome to remove everything. - what you propose misuses the gin option. Requiring an option only requires that the recipient support the option. It doesn't in and of itself alter any behavior. Something else in the message should do that. - I can't see any downside to doing so But this is a somewhat non-obvious subject, so I would like to see some other opinions. Thanks, Paul On 1/25/12 7:52 PM, David Hancock wrote: > 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 > > removed. > > 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@192.158.10.1 > > sip:+13035550002@sp.com --> sip:+13035550002@192.158.10.1 > > sip:+13035550003@sp.com --> sip:+13035550003@192.158.10.1 > > sip:+13035550004@sp.com --> sip:+13035550004@192.158.10.1 > > sip:+13035550001@sp.com --> sip:+13035550001@192.158.20.1 > > sip:+13035550002@sp.com --> sip:+13035550002@192.158.20.1 > > sip:+13035550003@sp.com --> sip:+13035550003@192.158.20.1 > > sip:+13035550004@sp.com --> sip:+13035550004@192.158.20.1 > > 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:192.158.30.1 > > sip:+13035550003@sp.com --> sip:192.158.40.1 > > 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: > > From: > > Proxy-Require: gin > > Require: gin > > Supported: path > > Contact: * > > Expires: 0 > > [2] from the UA > > REGISTER sip:sp.com SIP/2.0 > > To: > > From: > > 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? > > Thanks > > David Hancock > From D.Hancock@CableLabs.com Thu Jan 26 07:49:37 2012 Return-Path: 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 9EBD421F85E3 for ; Thu, 26 Jan 2012 07:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.744 X-Spam-Level: X-Spam-Status: No, score=0.744 tagged_above=-999 required=5 tests=[AWL=1.208, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 GCCWOu1wuwG7 for ; Thu, 26 Jan 2012 07:49:36 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9F13721F85D4 for ; Thu, 26 Jan 2012 07:49:36 -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 q0QFnX7J031079; Thu, 26 Jan 2012 08:49:33 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Thu, 26 Jan 2012 08:49:33 -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; Thu, 26 Jan 2012 08:49:34 -0700 From: David Hancock To: Paul Kyzivat Date: Thu, 26 Jan 2012 08:49:33 -0700 Thread-Topic: De-registration and GIN Thread-Index: Aczb20wtWnekupg9TpiVSM07m7/MBwAY4rZI Message-ID: <76AC5FEF83F1E64491446437EA81A61F81DF5C7E7B@srvxchg> References: <76AC5FEF83F1E64491446437EA81A61F81DF4FC3A3@srvxchg>, <4F20C98F.4020704@alum.mit.edu> In-Reply-To: <4F20C98F.4020704@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: "martini@ietf.org" Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 15:49:37 -0000 Paul, Good points. =20 In the example I was trying to extend the following RFC6140 requirement to = the de-register "*" case... "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." But I had forgotten that requiring an option in itself doesn't change behav= ior, and in the case of GIN it's the presence of the "bnc" URI parameter th= at tells the registrar to do the special GIN processing. So yes, that is a = problem in my example. If the "*" removes everything, then it does mean that an explicit de-regist= ration using "*" could remove a AOR-->contact row that was established usin= g GIN. Presumaly the deleted row would be added back in on the next GIN ref= resh.=20 Would appreciate hearing other comments/thoughts on this. Thanks David ________________________________________ From: Paul Kyzivat [pkyzivat@alum.mit.edu] Sent: Wednesday, January 25, 2012 8:33 PM To: David Hancock Cc: martini@ietf.org Subject: Re: De-registration and GIN David, ISTM that deregistering "*" should deregister everything - gin or not, for multiple reasons: - what you propose would make it cumbersome to remove everything. - what you propose misuses the gin option. Requiring an option only requires that the recipient support the option. It doesn't in and of itself alter any behavior. Something else in the message should do that. - I can't see any downside to doing so But this is a somewhat non-obvious subject, so I would like to see some other opinions. Thanks, Paul On 1/25/12 7:52 PM, David Hancock wrote: > I have a couple of questions on de-registration and GIN. > > RFC 3261 Section 10.2.2 =93Removing Bindings=94 provides a way to remove = all > contacts bound to a registered AOR. > > Here=92s the text=85 > > 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=85 > > 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., retu= rn > > the list of presently registered contacts in a success response). = A > > further implication of this property is that an individual extensio= n > > that is implicitly registered may also be explicitly registered usi= ng > > 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 > > removed. > > 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=85 > > 8 GIN bindings=85 > > sip:+13035550001@sp.com --> sip:+13035550001@192.158.10.1 > > sip:+13035550002@sp.com --> sip:+13035550002@192.158.10.1 > > sip:+13035550003@sp.com --> sip:+13035550003@192.158.10.1 > > sip:+13035550004@sp.com --> sip:+13035550004@192.158.10.1 > > sip:+13035550001@sp.com --> sip:+13035550001@192.158.20.1 > > sip:+13035550002@sp.com --> sip:+13035550002@192.158.20.1 > > sip:+13035550003@sp.com --> sip:+13035550003@192.158.20.1 > > sip:+13035550004@sp.com --> sip:+13035550004@192.158.20.1 > > Plus a UA explicitly registers one of the E.164 numbers to two different > contact addresses to create the following additional bindings=85 > > 2 explicit bindings=85 > > sip:+13035550003@sp.com --> sip:192.158.30.1 > > sip:+13035550003@sp.com --> sip:192.158.40.1 > > 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: > > From: > > Proxy-Require: gin > > Require: gin > > Supported: path > > Contact: * > > Expires: 0 > > [2] from the UA > > REGISTER sip:sp.com SIP/2.0 > > To: > > From: > > 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=92t 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 =96 does the example align with RFC6140? > > Thanks > > David Hancock >= From pkyzivat@alum.mit.edu Thu Jan 26 08:49:50 2012 Return-Path: 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 7B4B621F864C for ; Thu, 26 Jan 2012 08:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599] 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 wkJdiFYBDhv0 for ; Thu, 26 Jan 2012 08:49:49 -0800 (PST) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id 61F6021F8616 for ; Thu, 26 Jan 2012 08:49:49 -0800 (PST) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta10.westchester.pa.mail.comcast.net with comcast id SGBG1i0060mv7h05AGppXK; Thu, 26 Jan 2012 16:49:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta11.westchester.pa.mail.comcast.net with comcast id SGpo1i02R07duvL3XGppko; Thu, 26 Jan 2012 16:49:49 +0000 Message-ID: <4F21842B.3070100@alum.mit.edu> Date: Thu, 26 Jan 2012 11:49:47 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: David Hancock References: <76AC5FEF83F1E64491446437EA81A61F81DF4FC3A3@srvxchg>, <4F20C98F.4020704@alum.mit.edu> <76AC5FEF83F1E64491446437EA81A61F81DF5C7E7B@srvxchg> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F81DF5C7E7B@srvxchg> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "martini@ietf.org" Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 16:49:50 -0000 On 1/26/12 10:49 AM, David Hancock wrote: > Paul, > > Good points. > > In the example I was trying to extend the following RFC6140 requirement to the de-register "*" case... > > "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." > > But I had forgotten that requiring an option in itself doesn't change behavior, and in the case of GIN it's the presence of the "bnc" URI parameter that tells the registrar to do the special GIN processing. So yes, that is a problem in my example. > > If the "*" removes everything, then it does mean that an explicit de-registration using "*" could remove a AOR-->contact row that was established using GIN. Presumaly the deleted row would be added back in on the next GIN refresh. You can think of it as removing the bnc entries rather than the aors implicitly registered by them. The potential conflict between this wildcard registration and registration refresh was there before gin, and isn't substantially different with it: - If there is only one entity doing registration, and it is the one that uses the wildcard deregistration, then it presumably knows what it is doing, and won't refresh registrations it doesn't want. - When there are multiple entities doing registration there is the potential for them to get into a fight, removing each other's registrations, either explicitly or via the * mechanism. Perhaps its easier to "accidentally" remove something you shouldn't using *, but its possible even without that. We can't really legislate against stupid behavior. If we really wanted to "fix" this then I think we would need to introduce some notion of "ownership" of registrations that could resolve to the differing UAs that are doing registration to the same AOR. That would be complex, and I'm not inclined to go there. Thanks, Paul > Would appreciate hearing other comments/thoughts on this. > > Thanks > David > > ________________________________________ > From: Paul Kyzivat [pkyzivat@alum.mit.edu] > Sent: Wednesday, January 25, 2012 8:33 PM > To: David Hancock > Cc: martini@ietf.org > Subject: Re: De-registration and GIN > > David, > > ISTM that deregistering "*" should deregister everything - gin or not, > for multiple reasons: > > - what you propose would make it cumbersome to remove everything. > - what you propose misuses the gin option. Requiring an option only > requires that the recipient support the option. It doesn't in and of > itself alter any behavior. Something else in the message should do > that. > - I can't see any downside to doing so > > But this is a somewhat non-obvious subject, so I would like to see some > other opinions. > > Thanks, > Paul > > On 1/25/12 7:52 PM, David Hancock wrote: >> 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 >> >> removed. >> >> 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@192.158.10.1 >> >> sip:+13035550002@sp.com --> sip:+13035550002@192.158.10.1 >> >> sip:+13035550003@sp.com --> sip:+13035550003@192.158.10.1 >> >> sip:+13035550004@sp.com --> sip:+13035550004@192.158.10.1 >> >> sip:+13035550001@sp.com --> sip:+13035550001@192.158.20.1 >> >> sip:+13035550002@sp.com --> sip:+13035550002@192.158.20.1 >> >> sip:+13035550003@sp.com --> sip:+13035550003@192.158.20.1 >> >> sip:+13035550004@sp.com --> sip:+13035550004@192.158.20.1 >> >> 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:192.158.30.1 >> >> sip:+13035550003@sp.com --> sip:192.158.40.1 >> >> 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: >> >> From: >> >> Proxy-Require: gin >> >> Require: gin >> >> Supported: path >> >> Contact: * >> >> Expires: 0 >> >> [2] from the UA >> >> REGISTER sip:sp.com SIP/2.0 >> >> To: >> >> From: >> >> 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? >> >> Thanks >> >> David Hancock >> From D.Hancock@CableLabs.com Mon Jan 30 23:10:34 2012 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 To: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 07:10:34 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F81DF5C7E84srvxchg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 s= hould return the full list of contact addresses that were bound to the impl= icitly registered AORs? Or, should it return only the contact address that = was specified in the REGISTER Contact header field? I think the later behav= ior is correct. For example, say a SIP-PBX registers to 2 different contact addresses. Firs= t, the SIP-PBX identified in the To: header field of [1] registers to the C= ontact address identified in [1]. Response [2] contains the single register= ed contact address, even though the multiple implicitly registered AORs wer= e 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: [2] <--200OK -- To: sip:pbx1@sp.com Contact: PBX registers 2nd time to a different contact address... [3] --REGISTER--> To: sip:pbx1@sp.com Contact: [4] <--200OK -- To: sip:pbx1@sp.com Contact: , Would appreciate your input on a) is the above example correct, and b) do w= e need an errata to RFC6140 to clarify this case? Thanks David --_000_76AC5FEF83F1E64491446437EA81A61F81DF5C7E84srvxchg_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Another= GIN question...
 
Section 10.3 of RFC 3261 = says that the 200OK response to a REGISTER request MUST return all cur= rent bindings in the Contact header field.
 
Here's the text...=
 

     8.  The registrar r= eturns a 200 (OK) response.  The response MUST

   &n= bsp;     contain Contact header field values enumerating all current

   &n= bsp;     bindings.  Each Contac= t value MUST feature an "expires"

   &n= bsp;     parameter indicating its expiration interval chosen by the

   &n= bsp;     registrar.  The respon= se 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 bo= und to the implicitly registered AORs? Or, should it return only the contact address that was specified in the R= EGISTER 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 mul= tiple 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 &= nbsp;           &nbs= p;            &= nbsp;   SP-SSE

 --------- = ;            &n= bsp;            = ;     --------

 PBX registers 1st time...

 [1] --REGISTER-->

    &n= bsp;   To: sip:pbx1@sp.com

        Conta= ct: <sip:10.10.10.1;bnc>

 

 [2] <--200OK --

    &n= bsp;     To: sip:pbx1@sp.com

    &n= bsp;     Contact: <sip:10.10.10.10;bnc>

 

 PBX registers 2nd time to a different contact ad= dress...

 [3] --REGISTER-->

    &n= bsp;   To: sip:pbx1@sp.com

    &n= bsp;   Contact: <sip:192.168.2.1;bnc>

 

 [4] <--200OK --

    &n= bsp;     To: sip:pbx1@sp.com

    &n= bsp;     Contact: <sip:192.168.2.1;bnc>, <sip:10.10.10.10;bnc>

 
Would appreciate your inp= ut on a) is the above example correct, and b) do we need an errat= a to RFC6140 to clarify this case?
 
Thanks
David
 
--_000_76AC5FEF83F1E64491446437EA81A61F81DF5C7E84srvxchg_-- From pkyzivat@alum.mit.edu Tue Jan 31 06:17:45 2012 Return-Path: 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 E3C9B21F851D for ; Tue, 31 Jan 2012 06:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] 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 1MtH1SU65DwA for ; Tue, 31 Jan 2012 06:17:45 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE4621F851C for ; Tue, 31 Jan 2012 06:17:43 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by QMTA11.westchester.pa.mail.comcast.net with comcast id UDbV1i00227AodY5BEHkSM; Tue, 31 Jan 2012 14:17:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id UEHk1i00K07duvL3fEHkf1; Tue, 31 Jan 2012 14:17:44 +0000 Message-ID: <4F27F806.2020805@alum.mit.edu> Date: Tue, 31 Jan 2012 09:17:42 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: martini@ietf.org References: <76AC5FEF83F1E64491446437EA81A61F81DF5C7E84@srvxchg> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F81DF5C7E84@srvxchg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 14:17:46 -0000 On 1/31/12 2:07 AM, David Hancock wrote: > 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. I agree, for at least two reasons: - the list of implicitly registered AORs can be arbitrarily large, and so infeasible to return - based on our prior discussion, its necessary to have the actual registered contacts in order to deregister them. This is one way to get them. > 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-PBXSP-SSE > > ----------------- > > PBX registers 1st time... > > [1] --REGISTER--> > > To: sip:pbx1@sp.com > > Contact: > > [2] <--200OK -- > > To: sip:pbx1@sp.com > > Contact: > > PBX registers 2nd time to a different contact address... > > [3] --REGISTER--> > > To: sip:pbx1@sp.com > > Contact: > > [4] <--200OK -- > > To: sip:pbx1@sp.com > > Contact: , > > Would appreciate your input on a) is the above example correct, and b) > do we need an errata to RFC6140 to clarify this case? I'd like to hear what others have to say before deciding this. Thanks, Paul > Thanks > David > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From D.Hancock@CableLabs.com Tue Jan 31 06:35:31 2012 Return-Path: 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 4BD6521F8611 for ; Tue, 31 Jan 2012 06:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.06 X-Spam-Level: X-Spam-Status: No, score=-0.06 tagged_above=-999 required=5 tests=[AWL=0.402, 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 bzxQxaHB9lQd for ; Tue, 31 Jan 2012 06:35:30 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFB521F8610 for ; Tue, 31 Jan 2012 06:35: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 q0VEZTg1030761 for ; Tue, 31 Jan 2012 07:35:29 -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 07:35:29 -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 07:35:29 -0700 From: David Hancock To: "martini@ietf.org" Date: Tue, 31 Jan 2012 07:35:29 -0700 Thread-Topic: CORRECTED SUBJECT LINE: GIN Registration Question Thread-Index: AQHM4CWU+arXbfkBTUmwdykh4AmIVQ== Message-ID: <76AC5FEF83F1E64491446437EA81A61F81DF5C7E86@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_76AC5FEF83F1E64491446437EA81A61F81DF5C7E86srvxchg_" MIME-Version: 1.0 X-Approved: ondar Subject: [martini] CORRECTED SUBJECT LINE: GIN Registration Question X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 14:35:31 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F81DF5C7E86srvxchg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 s= hould return the full list of contact addresses that were bound to the impl= icitly registered AORs? Or, should it return only the contact address that = was specified in the REGISTER Contact header field? I think the later behav= ior is correct. For example, say a SIP-PBX registers to 2 different contact addresses. Firs= t, the SIP-PBX identified in the To: header field of [1] registers to the C= ontact address identified in [1]. Response [2] contains the single register= ed contact address, even though the multiple implicitly registered AORs wer= e 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: [2] <--200OK -- To: sip:pbx1@sp.com Contact: PBX registers 2nd time to a different contact address... [3] --REGISTER--> To: sip:pbx1@sp.com Contact: [4] <--200OK -- To: sip:pbx1@sp.com Contact: , Would appreciate your input on a) is the above example correct, and b) do w= e need an errata to RFC6140 to clarify this case? Thanks David --_000_76AC5FEF83F1E64491446437EA81A61F81DF5C7E86srvxchg_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Another= GIN question...
 
Section 10.3 of RFC 3261 = says that the 200OK response to a REGISTER request MUST return all cur= rent bindings in the Contact header field.
 
Here's the text...=
 

     8.  The registrar r= eturns a 200 (OK) response.  The response MUST

         contain Contact header field values enumerating all current

         bindings.  Each Contact value MUST feature an &quo= t;expires"

         parameter indicating its expiration interval chosen by the

         registrar.  The response SHOULD include a Date hea= der field.

 

What does this mean for GIN registration? Does it mean that = the registrar should return the full list of contact addresses that were bo= und to the implicitly registered AORs? Or, should it return only the contact address that was specified in the R= EGISTER 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 mul= tiple 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      = ;            &n= bsp;           SP-SSE

 ---------     &nb= sp;            =              --------

 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 ad= dress...

 [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 inp= ut on a) is the above example correct, and b) do we need an errat= a to RFC6140 to clarify this case?
 
Thanks
David
 
--_000_76AC5FEF83F1E64491446437EA81A61F81DF5C7E86srvxchg_-- From adam@nostrum.com Tue Jan 31 10:47:15 2012 Return-Path: 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 40CB621F847B for ; Tue, 31 Jan 2012 10:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 aWUE8nxSj7G8 for ; Tue, 31 Jan 2012 10:47:14 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 09C4F11E811E for ; Tue, 31 Jan 2012 10:47:09 -0800 (PST) Received: from hydra-en0.roach.at (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q0VIl6RD032555 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 31 Jan 2012 12:47:07 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4F283729.8060008@nostrum.com> Date: Tue, 31 Jan 2012 12:47:05 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Paul Kyzivat References: <76AC5FEF83F1E64491446437EA81A61F81DF5C7E84@srvxchg> <4F27F806.2020805@alum.mit.edu> In-Reply-To: <4F27F806.2020805@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 18:47:15 -0000 On 1/31/12 08:17, Jan 31, Paul Kyzivat wrote: > On 1/31/12 2:07 AM, David Hancock wrote: >> 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. > > I agree, for at least two reasons: > > - the list of implicitly registered AORs can be arbitrarily large, > and so infeasible to return > > - based on our prior discussion, its necessary to have the actual > registered contacts in order to deregister them. This is one way > to get them. Paul is correct. >> >> [1] --REGISTER--> >> >> To: sip:pbx1@sp.com >> >> Contact: >> >> [2] <--200OK -- >> >> To: sip:pbx1@sp.com >> >> Contact: >> >> PBX registers 2nd time to a different contact address... >> >> [3] --REGISTER--> >> >> To: sip:pbx1@sp.com >> >> Contact: >> >> [4] <--200OK -- >> >> To: sip:pbx1@sp.com >> >> Contact: , >> >> Would appreciate your input on a) is the above example correct, and b) >> do we need an errata to RFC6140 to clarify this case? > > I'd like to hear what others have to say before deciding this. Yes, the example is correct. I haven't looked at the GIN RFC closely enough to determine whether an erratum is warranted. /a