Re: [martini] De-registration and GIN

[Paul Kyzivat <[e-mail]>]

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:[e-mail] 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:[e-mail] --> sip:[phone]@192.158.10.1
>
> sip:[e-mail] --> sip:[phone]@192.158.10.1
>
> sip:[e-mail] --> sip:[phone]@192.158.10.1
>
> sip:[e-mail] --> sip:[phone]@192.158.10.1
>
> sip:[e-mail] --> sip:[phone]@192.158.20.1
>
> sip:[e-mail] --> sip:[phone]@192.158.20.1
>
> sip:[e-mail] --> sip:[phone]@192.158.20.1
>
> sip:[e-mail] --> sip:[phone]@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:[e-mail] --> sip:192.158.30.1
>
> sip:[e-mail] --> 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:[e-mail]>
>
>       From:<sip:[e-mail]>
>
>       Proxy-Require: gin
>
>       Require: gin
>
>       Supported: path
>
>       Contact: *
>
>       Expires: 0
>
> [2] from the UA
>
>       REGISTER sip:sp.com SIP/2.0
>
>       To:<sip:[e-mail]>
>
>       From:<sip:[e-mail]>
>
>       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
>