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

[Paul Kyzivat <[e-mail]>]

Hadriel Kaplan wrote:
> Ok, it's a rat-hole. :)
> But the point wasn't to stipulate in the draft what an SBC should do, but rather what a UAS might receive and need to be ok with - i.e., "don't expect only one "rc" tagged entry".  If you look at the use-cases draft, a lot of their "rules" for processing involve using entries with "rc" tags, or in relative positions to "rc" tagged ones in certain positions.  Those rules are based on assumptions that are very simplistic, which will not be the case in the wild.

Sure, I think the point that there might be multiple rc entries is a 
good one. It is probably a rat hole to describe how to discover various 
interesting facts given that situation. But you aren't asking for that.

	Thanks,
	Paul

> -hadriel
> 
> On Aug 30, 2010, at 3:49 PM, Paul Kyzivat wrote:
> 
>> [ 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".
>>>>>
>>>
> 
>