Re: [sipcore] RFC5626 and REGISTER with multiple contacts

Hello,

please see below.

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: 8. května 2012 17:46 
> To: sipcore@ietf.org 
> Subject: Re: [sipcore] RFC5626 and REGISTER with multiple contacts 
> 
> On 5/8/12 11:07 AM, Kevin P. Fleming wrote: 
> > On 05/08/2012 09:44 AM, Paul Kyzivat wrote: 
> >> Its also true that registering multiple contacts means that forked  
> >> call attempts may reach more than one of the instances. This is a bit  
> >> inefficient and will require care to provide a reasonable user  
> >> experience. 

When outbound is used and the contacts have the same sip.instance, then incoming INVITE will be forked to the UA only __once__ (unless flow fails with 430).
------------
7.  Authoritative Proxy Procedures: Forwarding Requests

   When a proxy uses the location service to look up a registration
   binding and then proxies a request to a particular contact, it
   selects a contact to use normally, with a few additional rules:

   o  The proxy MUST NOT populate the target set with more than one
      contact with the same AOR and instance-id at a time.
...
   o  If the proxy receives a final response from a branch other than a
      408 (Request Timeout) or a 430 (Flow Failed) response, the proxy
      MUST NOT forward the same request to another target representing
      the same AOR and instance-id.  The targeted instance has already
      provided its response. 
------------

However, when outbound is used and the contacts have different sip.instance values (and representing several UAs in the device), then incoming INVITE can be forked to the devices __several times__. Moreover, given that each UA is different, I guess 2nd and later forking of the incoming INVITE will not be rejected with 482 (Loop Detected) response (as in section 8.2.2.2 of RFC 3261) as each UA sees the INVITE request for the 1st time. That could cause user experience issues.

> > 
> > If a registrar supported multiple Contact URIs for a single AoR with  
> > the same sip.instance value, wouldn't this still be true? If a proxy  
> > does 
> > RFC3841 processing to select candidates to send a request to, and more  
> > than one candidate matches, the request would still be forked, wouldn't it? 
> 
> Its hard to assess what might happen if we relaxed some rule - we would need to work 
> out all the details of the change. Certainly it would be possible to define it that 
> way. 

RFC5626 states that only one delivery (unless flow fails) is attempted to contacts with the same AOR and instance-id - see exceprt above.

> 
> My point is that you can do it today, legally, but with these consequences. 
> 
> If we were to make a change I would think we would try to make it in such a way as 
> to minimize the negative consequences. 
> 
> 	Thanks, 
> 	Paul 
> _______________________________________________ 
> sipcore mailing list 
> sipcore@ietf.org 
> https://www.ietf.org/mailman/listinfo/sipcore 
> 