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

[Paul Kyzivat <[e-mail]>]

[ as individual ]

Hadriel Kaplan wrote:
> 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:[e-mail]>
> 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:[e-mail]>
> History-Info: <sip:[e-mail]>;rc
> History-Info: <sip:bar@192.168.1.2>;rc
> 
> Right?

!!! RAT HOLE ALERT !!!

I think we are going to get into serious trouble if we start discussing 
how an SBC should behave WRT HI.

Given their frequent use to do topology hiding, I would expect to see 
lots of entries to be removed, or altered. In *this* case the UAS is on 
the side the SBC is protecting, so maybe it would all still be there, 
but its hard to predict what some hypothetical SBC will do.

	Thanks,
	Paul

> -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".
>>>
> 
>