Re: [sipcore] RFC5626 and REGISTER with multiple contacts

Hello,

Of course, there are things that would be good to clarify, and maybe provide more guidance and consideration upon (e.g. the "SHOULD reject REGISTER with multiple contacts" statement in RFC 5626).

However, my understanding of this discussion is that the current specs do allow me to do what I want, so I see no need to change anything :)

Kind regards

Ivo Sedlacek 

Ericsson
GF Technology, Terminal Standardization
Sweden
Office: +46 10 711 9382
ivo.sedlacek@ericsson.com
www.ericsson.com

This communication is confidential. We only send and receive email on the basis of the term set out at www.ericsson.com/email_disclaimer

-----Original Message-----
> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul 
> Kyzivat 
> Sent: 10. května 2012 21:35 
> To: sipcore@ietf.org 
> Subject: Re: [sipcore] RFC5626 and REGISTER with multiple contacts 
> 
> 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 
> _______________________________________________ 
> sipcore mailing list 
> sipcore@ietf.org 
> https://www.ietf.org/mailman/listinfo/sipcore 
> 