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

From: "sipcore issue tracker" <[email-masked]>
Date: Mon, 30 Aug 2010 18:24:32 -0000

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

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/sipcore/trac/ticket/9>
sipcore <http://tools.ietf.org/sipcore/>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Aug 2010 14:38:34 -0400

[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

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 30 Aug 2010 15:29:27 -0400

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:[email-masked]>
History-Info: <sip:[email-masked]>;rc
History-Info: <sip:[email-masked]>;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:[email-masked]>
History-Info: <sip:[email-masked]>;rc
History-Info: <sip:[email-masked]>;rc

Right?

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Aug 2010 15:49:35 -0400

[ as individual ]

> History-Info: <sip:[email-masked]>;rc

!!! 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

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 30 Aug 2010 16:29:53 -0400

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.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Aug 2010 16:40:19 -0400

> 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 t…

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