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

[Paul Kyzivat <[e-mail]>]

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