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 Worley, 
> Dale R (Dale) 
> Sent: 3. května 2012 17:37 
> To: Ivo Sedlacek; sipcore@ietf.org 
> Subject: Re: [sipcore] RFC5626 and REGISTER with multiple contacts 
> 
> > From: Ivo Sedlacek [ivo.sedlacek@ericsson.com] 
> >  
> > I can understand the reason for rejection where the contacts represent  
> > different UA instances, or have different IP addresses or ports. 
> >  
> > However, the same sip.instance *and* the same IP address and port are  
> > used in each of the contact registered by the REGISTER request in the  
> > case above. I also assume that the reg-id would be the same for each  
> > contact associated with a given flow. 
> >  
> > Is there a reason why REGISTER with multiple contacts, each having the  
> > same sip.instance, the same IP address and port and the same reg-id,  
> > should be rejected? 
> 
> The underlying concept of "SIP Outbound" processing is that the "contact" that is 
> registered is not the contact URI that is provided, but the *flow* which the UA created 
> to the edge proxy -- a request to the AoR is to be routed to the UA by being sent 
> down the specified flow.  Of course, the contact URI will be used as the request-URI, 
> but the request will not be routed based on RFC 3263 processing of the contact URI. 
> 
> 
> An advantage of that concept is that the contact URI provided by the UA does not 
> need to be a URI by which the edge proxy could contact the UA.  And in many practical 
> situations, the UA may not be able to determine a usable contact URI. 

This seems to be OK for the desired use case.

> 
> Within that concept, it is difficult for a UA to use one REGISTER for multiple contacts, 
> because all contacts would necessarily be associated with the same flow, and if they 
> are all reached via the same flow, how are they distinguished?

Each contact is unique, and distinguished by indicated support of capabilities.

> 
> In your architecture, I think the concept is that the physical UA device would demultiplex 
> requests to the various effective UAs based on the request-URI of incoming requests. 
>  Within that context, it seems reasonable that multiple contact URIs could be presented 
> in one Outbound REGISTER.  But I don't think that RFC 5626 envisioned that possibility 
> -- RFC 5626 assumes that each flow originates from only one UA. 

The device acts as SIP UA towards the registrar so the device should have only one sip.instance as according to RFC5626, the sip.instance identifies a specific UA instance.
I.e., the flow originates from only one SIP UA.

> 
> However, looking at the algorithms presented in RFC 5626, it appears to me that if 
> your device sends two different REGISTERs for two different UAs down the *same* flow, 
> the two UAs become registered to the same flow, but with their different contact 
> URIs.  Important 
> point:  This requires that the different UAs use *different* sip.instance values, 
> otherwise the second registration replaces the first registration. 
> 
> And now that you've raised the question, it appears to be reasonable that multiple 
> such contacts could be registered with one REGISTER request; the algorithms in the 
> RFC would handle the situation in the obvious way. 
> 
> One critical thing is that if you want the proxy to treat these various application 
> UAs as distinct UAs, you will have to provide each one with a different sip.instance. 
>  The philosophy of SIP is that the sip.instance is unique to the UA, and no aspect 
> of SIP will ever be designed to "correctly" handle multiple UAs that present the 
> same sip.instance. 

The device acts as SIP UA towards the registrar so the device should have only one sip.instance as according to RFC5626, the sip.instance identifies a specific UA instance.

> 
> Once you give each UA a different sip.instance, each UA has an independent space 
> of reg-ids, as reg-id is only used when it is combined with the sip.instance. 
> 
> However, it would probably be easier to have the device register one contact without 
> any capabilities declaration.  Then, all calls are routed to the device, and its 
> demultiplexer can determine which of the application UAs should receive forks of 
> the INVITE, and reject the INVITE if there are none. 

User can have multiple devices (each having the UA with several applications), registering for the same AoR. 
Without capability declaration the home proxy could not use RFC3841 to determine to which device(s) to forks the request.

> 
> Dale 
> _______________________________________________ 
> sipcore mailing list 
> sipcore@ietf.org 
> https://www.ietf.org/mailman/listinfo/sipcore 
> 