Re: [martini] De-registration and GIN

[Paul Kyzivat <[e-mail]>]

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 [[e-mail]]
> Sent: Wednesday, January 25, 2012 8:33 PM
> To: David Hancock
> Cc: [e-mail]
> 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:[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
>>