Re: [sipcore] RFC5626 and REGISTER with multiple contacts

[Paul Kyzivat <[e-mail]>]

On 5/10/12 8:52 AM, Ivo Sedlacek wrote:

>  > It's clear at this point that what you are trying to do was not
> contemplated by the
>  > combined authors of RFCs 3261, 3841 and 5626. That doesn't mean it
> can't be done,
>  > but there isn't a mechanism that exists today which is fully
> compliant with all of
>  > these RFCs
>
> I can't say that the authors were thinking, and I wasn't involved in the
> IETF work on those RFCs, but at least RFC3261 explicitly says that UA
> can register several Contacts and update its own contact *addresses*.

I can give some insight.

3261 clearly allows one UA to register multiple contacts with differing 
addresses, including ones at addresses different from where the REGISTER 
is originating. I wasn't there when that was worked out - I think it was 
unchanged from 2543 in that regard - before my time. But there are 
examples, and lots of later discussion that support that.

Subsequently there were various discussions of issues that can result 
from that feature. For instance "dueling UAs" that remove each other's 
contacts and substitute their own. But AFAIK there was never any real 
work to "fix" that. (But the reg event package can be used to at least 
detect that it is happening.)

Outbound complicated things because a flow terminates on a particular 
UA, and so it makes no sense to attempt to establish one from a 
different UA. In my recollection there was no discussion at all of 
callerprefs/callee-caps in the discussion of outbound. I think it was 
simply viewed as something orthogonal that need not be considered. And 
of course 3840/3841 predated 5626 and so didn't consider it.

So I agree with Kevin that the feature you are interested in was simply 
never considered. In retrospect perhaps the interactions with 3840/3841 
should have been considered in more depth.

In any case, we are where we are. You can either try to work within the 
specs as they are, or you can propose some change.

	Thanks,
	Paul