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

[Mary Barnes <[e-mail]>]

I just replied to issue #8 on internal retargeting. I think we could
consider this SBC behavior to fall into a similar category. In my
response to #8, I suggested that the indices look the same as if the
proxy retargeted to external entities (e.g., based on a 3xx).
However, this proposal seems to be support Dale's first alternative
where the indices are nested under the same branch, which makes alot
of sense actually.   So, I'll change the text resolving #8 to describe
the behavior in that manner.

However, the text on internal retargeting is in the Proxy section.
Perhaps, we should qualify that section as applicable to Proxies or
intermediaries that support SIP?

Thanks,
Mary.

On Mon, Aug 30, 2010 at 3:40 PM, Paul Kyzivat <[e-mail]> wrote:
>
>
> 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".
>>>>>>
>>>>
>>
>>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>