Re: [sipcore] #9: What should an SBC do when it resolves registered contacts?

Hadriel Kaplan <HKaplan@acmepacket.com> Mon, 30 August 2010 19:28 UTC

From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Paul Kyzivat <pkyzivat@cisco.com>
Date: Mon, 30 Aug 2010 15:29:27 -0400
Thread-Topic: [sipcore] #9: What should an SBC do when it resolves registered contacts?
Thread-Index: ActIeamAsaeQSM6ySLO7C3pCKwDwUA==
Message-ID: <1C71FA27-29FA-41D4-90D2-FCECB4C8FEE7@acmepacket.com>
References: <064.095bc2caaa02e01e9bc1234e3c8941af@tools.ietf.org> <4C7BFAAA.4000409@cisco.com>
In-Reply-To: <4C7BFAAA.4000409@cisco.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "sipcore@ietf.org" <sipcore@ietf.org>, sipcore issue tracker <trac@tools.ietf.org>
Subject: Re: [sipcore] #9: What should an SBC do when it resolves registered contacts?
Precedence: list

Right, but the subtle difference is that in the SBC case what the UAS wants to find is the AoR it registered for, which is (probably) the first non-"rc" entry prior to the series of "rc" entries at the end.  Like this:
History-Info: <sip:john.smith@ssp.com>
History-Info: <sip:foo@10.1.1.1>;rc
History-Info: <sip:bar@192.168.1.2>;rc

Whereas in a chain of AoR's, it would be looking for the one it registered which *is* "rc" tagged, like this:
History-Info: <sip:jsmith@ssp.co.uk>
History-Info: <sip:john.smith@ssp.com>;rc
History-Info: <sip:bar@192.168.1.2>;rc

Right?

-hadriel

On Aug 30, 2010, at 2:38 PM, Paul Kyzivat wrote:

> [as individual]
> 
> Note that an SBC is not required to get this behavior.
> It can happen any time somebody REGISTERs a contact address that happens 
> to be an AOR serviced by another registrar. While AFAIK this is not a 
> frequent occurrence in the wild, its certainly possible and permitted.
> 
> 	Thanks,
> 	Paul
> 
> sipcore issue tracker wrote:
>> #9: What should an SBC do when it resolves registered contacts?
>> ------------------------------------+---------------------------------------
>> Reporter:  hkaplan@…               |       Owner:            
>>     Type:  enhancement             |      Status:  new       
>> Priority:  minor                   |   Milestone:  milestone1
>> Component:  rfc4244bis              |     Version:  2.0       
>> Severity:  In WG Last Call         |    Keywords:            
>> ------------------------------------+---------------------------------------
>> In many deployments, SBC's perform a registration caching model, whereby
>> they have a local registration cache which is used to replace request-
>> uri's for routing to endpoints.  The UA registers to the SBC using contact
>> URI X, and the SBC sends contact URI Y to the full Registrar; so when a
>> request to Y comes to the SBC, it replaces it with X.
>> 
>> Under that model, do we expect the SBC to add an H-I of type "rc"?  If so,
>> for the same fork branch, there will be two "rc" entries, one for Y and
>> one for X. (if the SBC doesn't simply remove the Y entry)
>> 
>> Therefore, I think there should be some text to make it clear that
>> receiving a H-I list with multiple "rc" entries for the same branch tree
>> is ok.  For example, receiving a index 1.1 of "rc" followed by a 1.1.1 of
>> "rc", and maybe even a 1.1.1.1 of "rc".
>>

[sipcore] #9: What should an SBC do when it resol… sipcore issue tracker
Re: [sipcore] #9: What should an SBC do when it r… Paul Kyzivat
Re: [sipcore] #9: What should an SBC do when it r… Hadriel Kaplan
Re: [sipcore] #9: What should an SBC do when it r… Paul Kyzivat
Re: [sipcore] #9: What should an SBC do when it r… Hadriel Kaplan
Re: [sipcore] #9: What should an SBC do when it r… Paul Kyzivat
Re: [sipcore] #9: What should an SBC do when it r… Mary Barnes