Subject: [martini] De-registration and GIN

From: David Hancock <[email-masked]>
Date: Wed, 25 Jan 2012 17:52:08 -0700

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:[email-masked] 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:[email-masked] --> sip:[email-masked]
sip:[email-masked] --> sip:[email-masked]
sip:[email-masked] --> sip:[email-masked]
sip:[email-masked] --> sip:[email-masked]

sip:[email-masked] --> sip:[email-masked]
sip:[email-masked] --> sip:[email-masked]
sip:[email-masked] --> sip:[email-masked]
sip:[email-masked] --> sip:[email-masked]

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:[email-masked] --> sip:192.158.30.1
sip:[email-masked] --> 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: <sip:[email-masked]>

   From: <sip:[email-masked]>

   Proxy-Require: gin

   Require: gin

   Supported: path

   Contact: *

   Expires: 0

[2] from the UA

   REGISTER sip:sp.com SIP/2.0

   To: <sip:[email-masked]>

   From: <sip:[email-masked]>

   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: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Jan 2012 22:33:35 -0500

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:
> RFC 3261 Section 10.2.2 “Removing Bindings” provides a way to remove all
> contacts bound to a registered AOR.
>
> Here’s the text…
>
> 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…
>
> For example, PBX sip:[email-masked] 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…
>
> 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…
>
>       To:<sip:[email-masked]>
>       From:<sip:[email-masked]>
>       To:<sip:[email-masked]>
>
>       From:<sip:[email-masked]>
>
>       Contact: *
>
>       Expires: 0
>
> 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: David Hancock <[email-masked]>
Date: Thu, 26 Jan 2012 08:49:33 -0700

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. 

Would appreciate hearing other comments/thoughts on this.

Thanks
David

________________________________________
From: Paul Kyzivat [[email-masked]]
Sent: Wednesday, January 25, 2012 8:33 PM
To: David Hancock
Cc: [email-masked]
Subject: Re: De-registration and GIN

David,

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jan 2012 11:49:47 -0500

> 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…

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