Re: [sipcore] RFC5626 and REGISTER with multiple contacts

["Worley, Dale R (Dale)" <[e-mail]>]

> From: Ivo Sedlacek [[e-mail]]
> 
> 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.

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?

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.

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.

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.

Dale