Subject: [sipcore] RFC5626 and REGISTER with multiple contacts

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 3 May 2012 12:59:56 +0200

Hello,

can I please get experts' view on the issue below?

Use case:
- the UA contains several applications
- each application is associated with a unique contact
- all contacts of all the applications have the same IP address and port
- the UA registers all contacts of all the applications using a single REGISTER request, as due to the potentially large number of applications it is not feasible to register each contact individually

As long as outbound is NOT used, this works correctly.

Issue:

Once the UA would like to create several registration flows using outbound for reliability, the REGISTER request with multiple contacts sent by the UA can be rejected by the registrar since RFC5626 states:
---------------------------------
Therefore, if the Contact header field contains
   more than one header field value with a non-zero expiration and any
   of these header field values contain a "reg-id" Contact header field
   parameter, the entire registration SHOULD be rejected with a 400 (Bad
   Request) response.  The justification for recommending rejection
   versus making it mandatory is that the receiver is allowed by
   [RFC3261] to squelch (not respond to) excessively malformed or
   malicious messages.
---------------------------------

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?

Thank you for clarification.

Kind regards

Ivo Sedlacek

Ericsson
GF Technology, Terminal Standardization
Sweden
Office: +46 10 711 9382
[email-masked]
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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 3 May 2012 16:01:40 +0200

2012/5/3 Ivo Sedlacek <[email-masked]>:
> 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?

Let me first a question please: what is the purpose of registering
various Contact URI's in the same REGISTER (so an unique To header
AoR) pointing all of them to the same "device"?

This is, if your device registers various bindings for the AoR in the
REGISTER's To header, when that AoR is called your device would
receive the request with parallel forking for each binding. What is
the purpose of that?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 3 May 2012 16:27:20 +0200

Hello,

> This is, if your device registers various bindings for the AoR in the REGISTER's 
> To header, when that AoR is called your device would receive the request with parallel 
> forking for each binding. What is the purpose of that? 

Applications have different capabilities, indicated in the associated contacts using the mechanism in RFC 3840.
The registrar then uses the mechanism in RFC 3841 to choose the correct contact.

Kind regards

Ivo Sedlacek 

Ericsson

-----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Iñaki 
> Baz Castillo 
> Sent: 3. května 2012 16:02 
> To: Ivo Sedlacek 
> Cc: [email-masked] 
> Subject: Re: [sipcore] RFC5626 and REGISTER with multiple contacts 
> 
> > 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? 
> 
> Let me first a question please: what is the purpose of registering various Contact 
> URI's in the same REGISTER (so an unique To header 
> This is, if your device registers various bindings for the AoR in the REGISTER's 
> To header, when that AoR is called your device would receive the request with parallel 
> forking for each binding. What is the purpose of that? 
> 
> -- 
> Iñaki Baz Castillo 
> <[email-masked]> 
> _______________________________________________ 
> sipcore mailing list 
> [email-masked] 
> https://www.ietf.org/mailman/listinfo/sipcore 
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 3 May 2012 16:52:01 +0200

> The registrar then uses the mechanism in RFC 3841 to choose the correct contact.

Thanks. Then I agree that limiting the number of Contact instances in
the REGISTER is an artificial limitation (in case all of them include
the same instance and reg-id parameters).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 3 May 2012 11:37:20 -0400

> From: Ivo Sedlacek [[email-masked]]
> 
> 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.
> 

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

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Thu, 03 May 2012 10:47:23 -0500

> INVITE if there are none.

Some useful information would be lost here though: in the OP's proposed 
configuration, when the UA receives an INVITE, the will have already 
done the RFC3841 matching process, and evidence of that process will 
appear in the request sent to the UA.

With a single Contact URI registered, the UA would have to do the caller 
preferences matching itself to determine which of its internal 
applications to deliver the request to.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [email-masked] | SIP: [email-masked] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 3 May 2012 14:02:52 -0400

> the UA registers all contacts of all the applications using a single REGISTER request, as due to the potentially large number of applications it is not feasible to register each contact individually

If there really is enough applications that registering each one individually is not
feasible, beware that there may be so many that the redirection process can't
handle them properly.

Dale

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 4 May 2012 08:21:38 +0200

Hello,

Please see below.

Kind regards

Ivo Sedlacek 

Ericsson

-----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Worley, 
> Dale R (Dale) 
> Sent: 3. května 2012 17:37 
> To: Ivo Sedlacek; [email-masked] 
> 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.

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 4 May 2012 09:04:13 +0200

Hello,

I agree that if several contacts are registered, the redirection process can become more complicated. However, that is independent of whether a UA registers several times with a single contact, or registers once with multiple contacts.

Based on the feedback received so far, there doesn't seem to be a technical reason why multiple contacts (sharing the same IP address and port, the same sip.instance and the same reg-id) in a single REGISTER would not work with outbound.

Kind regards

Ivo Sedlacek 

Ericsson

-----Original Message-----
From: Worley, Dale R (Dale) [mailto:[email-masked]] 
Sent: 3. května 2012 20:03
To: Ivo Sedlacek; [email-masked]
Subject: RE: RFC5626 and REGISTER with multiple contacts

> the UA registers all contacts of all the applications using a single 
> REGISTER request, as due to the potentially large number of 
> applications it is not feasible to register each contact individually

If there really is enough applications that registering each one individually is not feasible, beware that there may be so many that the redirection process can't handle them properly.

Dale

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 4 May 2012 10:54:19 +0200

> Based on the feedback received so far, there doesn't seem to be a technical reason why multiple contacts (sharing the same IP address and port, the same sip.instance and the same reg-id) in a singl…

I agree, however take into account that if two contacts don't share
the same sip.instance and reg-id (or one of the contacts does not
include those parameters) then the registrar should reject the
request, right? If so, maybe RFC 5626 tries to simplify it by avoiding
such tedious parameters comparison in server side.

Also take into account that the contact IP:port is just "ignored" when
using Outbound (the registrar just matches the contact using the
sip.instance and reg-id params).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 4 May 2012 13:09:50 +0200

Hello,

please see below

Kind regards

Ivo Sedlacek 

Ericsson

-----Original Message-----
> From: Iñaki Baz Castillo [mailto:[email-masked]] 
> Sent: 4. května 2012 10:54 
> To: Ivo Sedlacek 
> Cc: Worley, Dale R (Dale); [email-masked] 
> > Based on the feedback received so far, there doesn't seem to be a technical reason 
> why multiple contacts (sharing the same IP address and port, the same sip.instance 
> and the same reg-id) in a single REGISTER would not work with outbound. 
> 
> I agree, however take into account that if two contacts don't share the same sip.instance 
> and reg-id (or one of the contacts does not include those parameters) then the registrar 
> should reject the request, right? 

That seems OK - at least we see no need to support cases where all contacts in a REGISTER request don't share the same sip.instance and the same reg-id (and the same IP address and port). 

> If so, maybe RFC 5626 tries to simplify it by avoiding 
> Also take into account that the contact IP:port is just "ignored" when using Outbound 
> (the registrar just matches the contact using the sip.instance and reg-id params). 

Exactly, and that is the reason we assume identical IP address and port, because incoming requests are going to be sent to the same IP location no matter which contact is used.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 4 May 2012 13:26:15 +0200

> Exactly, and that is the reason we assume identical IP address and port, because incoming requests are going to be sent to the same IP location no matter which contact is used.

So correct me if I'm wrong but in a previous mail you said that
sending multiple REGISTER with unique Contact works even using
Outbound. Could I know how those REGISTER's Contact headers look? (it
would be useful to see two of them).

I would like to understand why the registrar stores different bindings
when the sip.instance and reg-id are the same. It's not clear for me.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 4 May 2012 14:54:14 +0200

Hello,

please see below.

Kind regards

Ivo Sedlacek 

Ericsson

-----Original Message-----
> Sent: 4. května 2012 13:26 
> To: Ivo Sedlacek 
> >> Also take into account that the contact IP:port is just "ignored"  
> >> when using Outbound (the registrar just matches the contact using the sip.instance 
> and reg-id params). 
> > 
> > Exactly, and that is the reason we assume identical IP address and port, because 
> incoming requests are going to be sent to the same IP location no matter which contact 
> is used. 
> 
> So correct me if I'm wrong but in a previous mail you said that sending multiple 
> REGISTER with unique Contact works even using Outbound. Could I know how those REGISTER's 
> Contact headers look? (it would be useful to see two of them). 

In our use case, we proposed to have REGISTER with multiple unique contacts which all share the same sip.instance, the same reg-id and the same IP address and port.

Examples of the proposed REGISTERs of UA1:

R1:

REGISTER 
Supported: path, outbound 
Contact: <sip:[email-masked]:5678>;+sip.instance="x";reg-id="1";+FeatureTag1="value1";+FeatureTag3
Contact: <sip:[email-masked]:5678>;+sip.instance="x";reg-id="1";+FeatureTag1="value2";+FeatureTag3;+FeatureTag4

R2:

REGISTER 
Supported: path, outbound 
Contact: <sip:[email-masked]:5678>;+sip.instance="x";reg-id="2";+FeatureTag1="value1";+FeatureTag3
Contact: <sip:[email-masked]:5678>;+sip.instance="x";reg-id="2";+FeatureTag1="value2";+FeatureTag3;+FeatureTag4

> 
> I would like to understand why the registrar stores different bindings when the sip.instance 
> and reg-id are the same. It's not clear for me. 

applications have different capabilities, indicated in the associated contacts using the mechanism in RFC 3840. The home proxy then uses the mechanism in RFC 3841 to choose the correct contact (and correct UA, if multiple UAs have registered for the same AoR).

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Fri, 04 May 2012 10:03:52 -0500

> applications have different capabilities, indicated in the associated contacts using the mechanism in RFC 3840. The home proxy then uses the mechanism in RFC 3841 to choose the correct contact (and…

You are using a non-SIP term here, 'applications'. Contact URIs aren't 
bound to an AoR for applications, they are bound for SIP UAs. Each 
Contact header you provide in a REGISTER request represents a distinct 
SIP UA. If you want your individual applications (with differing 
capabilities) to be selected by a proxy/registrar, even if they all 
physically reside in the same endpoint, they will need different 
sip.instance values because they are separate UAs.

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 4 May 2012 11:28:54 -0400

> [...]
> 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.
> 

I don't think you get the point.  If you want to implement this scheme
within SIP, you have to consider how your stuff fits within the SIP
conceputal schema.  The entity which has a contact is a User Agent,
and each User Agent has a distinct sip.instance.  If you want to
register several contacts, each contact *is* a distinct User Agent,
regardless of the fact that they are contained within one physical
device and use the same IP address.

If you want the proxy/redirector to treat these various contacts as
different for the purpose of call routing, then they *must* have
different sip.instances.  Partly, this is because that's how the
algorithms of RFC 5626 work (the registration table entries are
indexed solely by AoR, sip.instance, and reg-id), and also because
that's the way SIP people *think*, meaning that SIP will *never* be
changed so that two contacts with the same sip.instance will be
provided with different call routing.

Dale

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 4 May 2012 18:09:25 +0200

> Contact: <sip:[email-masked]:5678>;+sip.instance="x";reg-id="1";+FeatureTag1="value2";+FeatureTag3;+FeatureTag4

Those two Contacts match the same *UA* since both provide the same
sip.instance. In my opinion, if you send two separate REGISTER (each
one with one of those two Contacts) the Outbound registrar will
discard the first one. So IMHO "things should not work" even if you
send separate REGISTER for each Contact.

It makes sense. A SIP UA (i.e. a SIP app in my smartphone) has an
unique sip.instace. First it's registered fom my home WiFi network but
then I leave my home and my mobile connects via 3G to Internet. So the
SIP app sends a new REGISTER indicating the same sip.instance but a
different Contact SIP URI (i.e. different IP). The registrar server
matches such a Contact using the sip.instance (and reg-id) and MUST
replace the previous one sent from my home WiFi network. That is the
purpose of Outbound in fact.

Said that, IMHO it's useless that you set different SIP URI usernames
in each Contact header since Contact matching in the registrar just
considers the sip.instace and reg-id Contact parameters. With this in
mind, a REGISTER with multiple Contact headers providing the same
sip.instance is useless and/or invalid.

> applications have different capabilities, indicated in the associated contacts using the mechanism in RFC 3840. The home proxy then uses the mechanism in RFC 3841 to choose the correct contact (and…

As said by others in this thread, the problem is that the Contact in
REGISTER request registers a binding for a specific UA, and the UA is
represented by a single sip.instance (and the Contact SIP URI is
useless when using Outbound). Also, RFC 3840 talks about "UA's
capabilities", not about "capabilities for different applications
running within the same UA".

So I consider that your scenario is not RFC 5626 compliant. Instead
what you need is an extension to Outbound, something like "Supported:
multi-outbound" in which the Contact header includes a new param
"multi-id=N", and the registrar should store as different bindings
those having the same +sip.instance, same reg-id and different
multi-id parameters. Unfortunately such a specification does not
exist.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Ivo Sedlacek <[email-masked]>
Date: Mon, 7 May 2012 14:06:26 +0200

Hello,

To Kevin's statement: 
> Each Contact header you provide in a REGISTER request represents a distinct SIP UA.

To Dale's statement: 
> If you want to register several contacts, each contact *is* a distinct User Agent, regardless of the fact that they are contained within one physical device and use the same IP address.

When reading RFC3261, I was not able to find any text stating that a SIP UA can have only a single contact. Quite the opposite, RFC3261 states that UA can register several Contacts and update its own contact addresses:
--------------------------------------------------
10.2.1 Adding Bindings
...
   The REGISTER request sent to a registrar includes the contact
   address(es) to which SIP requests for the address-of-record should be
   forwarded. 
...
Typically, a UA
   only updates its own contact addresses. 
...
--------------------------------------------------

To Kevin's statement: 
> If you want your individual applications 
> (with differing 
> capabilities) to be selected by a proxy/registrar, even if they all physically reside 
> in the same endpoint, they will need different sip.instance values because they are 
> separate UAs. 

I have not found any statement that when outbound is used, each contact of a UA must be the same. Can you please point me to such text in RFC5626?

Moreover, when outbound is used, each contact is different due to reg-id even if UA is monolithic. Given Kevin's statement above, each such contact would have to have different sip.instance which defeats the purpose of the outbound.

Moreover, Inaki stated that contacts can differ even for the same sip.instance:
> First it's registered fom my home WiFi network but then I leave my home and my mobile connects via 3G to Internet. So the SIP app sends a new REGISTER indicating the same sip.instance but a different Contact SIP URI (i.e. different IP).

To Kevin's statement: 
> You are using a non-SIP term here, 'applications'.

True. It was only used to describe the use-case. All the 'applications' in the UA bind to the same SIP stack. The fact that the SIP stack assigns a unique contact for each application is an implementation issue, and does in my opinion not break any SIP specification.

To Inaki:
> Said that, IMHO it's useless that you set different SIP URI usernames in each Contact header since Contact matching in the registrar just considers the sip.instace and reg-id Contact parameters. 
> With this in mind, a REGISTER with multiple Contact headers providing the same sip.instance is useless and/or invalid.

Disagree. Several contacts enable expressing user agent capabilities which cannot be expressed in single contact. See the example in the other mail. 

Kind regards

Ivo Sedlacek 

Ericsson

-----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Kevin 
> P. Fleming 
> Sent: 4. května 2012 17:04 
> To: [email-masked] 
> > applications have different capabilities, indicated in the associated contacts 
> using the mechanism in RFC 3840. The home proxy then uses the mechanism in RFC 3841 
> to choose the correct contact (and correct UA, if multiple UAs have registered for 
> the same AoR). 
> 
> You are using a non-SIP term here, 'applications'. Contact URIs aren't bound to an 
> AoR for applications, they are bound for SIP UAs. Each Contact header you provide 
> in a REGISTER request represents a distinct SIP UA. If you want your individual applications 
> (with differing 
> capabilities) to be selected by a proxy/registrar, even if they all physically reside 
> in the same endpoint, they will need different sip.instance values because they are 
> separate UAs. 
> 
> -- 
> Kevin P. Fleming 
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com 
> & www.asterisk.org _______________________________________________ 
> sipcore mailing list 
> [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 May 2012 10:17:50 -0400

I have always tended to think of a UA being distinguished by the contact 
address. But 3261 is not so clear on this point. And there are certainly 
some cases where that criterion doesn't make sense - e.g. a UA that is 
dual homed for redundancy or accessibility.

But the instance id gives a really tangible way to distinguish one UA 
from another among those that use them.

	Thanks,
	Paul

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 7 May 2012 19:50:25 +0200

> When reading RFC3261, I was not able to find any text stating that a SIP UA can have only a single contact. Quite the opposite, RFC3261 states that UA can register several Contacts and update its o…

Right, it could occur that the same UA register a UDP and a TCP binding.

>> First it's registered fom my home WiFi network but then I leave my home and my mobile connects via 3G to Internet. So the SIP app sends a new REGISTER indicating the same sip.instance but a differ…

Yes, but all those Contact SIP URIs point to the same UA so to the
same instance, that's the purpose of Outbound.

> Disagree. Several contacts enable expressing user agent capabilities which cannot be expressed in single contact. See the example in the other mail.

But user agent capabilities mean *UA* capabilities, and a UA is
represented by a single and unique sip.instance.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Ivo Sedlacek <[email-masked]>
Date: Tue, 8 May 2012 12:56:26 +0200

Hello,

To Paul's comment:
> I have always tended to think of a UA being distinguished by the 
> contact address.
>
> But 3261 is not so clear on this point. And there are certainly some 
> cases where that criterion doesn't make sense - e.g. a UA that is dual 
> homed for redundancy or accessibility.

Agree.

> from another among those that use them.

Agree.

To Inaki's comment:
> But user agent capabilities mean *UA* capabilities, and a UA is represented by a single and unique sip.instance.

In some cases it is not even possible to express the UA capabilities by single Contact. E.g.

Contact: <sip:address:port>;+sip.instance="x";+sip.duplex="full";+sip.audio
Contact: <sip:address:port>;+sip.instance="x";+sip.duplex="receive-only";+sip.audio;+sip.video

Kind regards

Ivo Sedlacek 

Ericsson

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 7. května 2012 16:18
To: [email-masked]
Subject: Re: [sipcore] RFC5626 and REGISTER with multiple contacts

I have always tended to think of a UA being distinguished by the contact address. But 3261 is not so clear on this point. And there are certainly some cases where that criterion doesn't make sense - e.g. a UA that is dual homed for redundancy or accessibility.

But the instance id gives a really tangible way to distinguish one UA from another among those that use them.

	Thanks,
	Paul

On 5/7/12 8:06 AM, Ivo Sedlacek wrote:
>> If you want your individual applications (with differing
> GF Technology, Terminal Standardization Sweden
> Office: +46 10 711 9382
> This communication is confidential. We only send and receive email on 
> the basis of the term set out at www.ericsson.com/email_disclaimer
>
>
>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Kevin P. Fleming
>> using the mechanism in RFC 3840. The home proxy then uses the 
>> mechanism in RFC 3841 to choose the correct contact (and correct UA, 
>> if multiple UAs have registered for the same AoR).
>>
>> You are using a non-SIP term here, 'applications'. Contact URIs 
>> aren't bound to an AoR for applications, they are bound for SIP UAs. 
>> Each Contact header you provide in a REGISTER request represents a 
>> distinct SIP UA. If you want your individual applications (with 
>> differing
>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at 
>> www.digium.com &  www.asterisk.org

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 8 May 2012 13:19:39 +0200

> Contact: <sip:address:port>;+sip.instance="x";+sip.duplex="receive-only";+sip.audio;+sip.video

IMHO those two Contacts are expressing different capabilities for the
same *UA* (same sip-instance) so they make no sense.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Ivo Sedlacek <[email-masked]>
Date: Tue, 8 May 2012 13:51:39 +0200

Hello,

please see below.

Kind regards

Ivo Sedlacek 

Ericsson

-----Original Message-----
> Sent: 8. května 2012 13:20 
> To: Ivo Sedlacek 
> Cc: Paul Kyzivat; [email-masked] 
> > Contact:  
> > <sip:address:port>;+sip.instance="x";+sip.duplex="full";+sip.audio 
> > Contact:  
> > <sip:address:port>;+sip.instance="x";+sip.duplex="receive-only";+sip.a 
> > udio;+sip.video 
> 
> IMHO those two Contacts are expressing different capabilities for the same *UA* (same 
> sip-instance) so they make no sense. 

The Contacts represent different combinations of supported capabilities in the UA. Scope of support of a capability can be dependent on what other capabilities are supported.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 8 May 2012 14:04:42 +0200

> The Contacts represent different combinations of supported capabilities in the UA. Scope of support of a capability can be dependent on what other capabilities are supported.

Honestly I don't understand it. I try to see it simple, and for me the
above two Contact are expressing contradictory capabilities for the
same UA (sip.instance) since the first one announces
+sip.duplex="full" while the second one announces
+sip.duplex="receive-only", and both Contact announce capabilities for
the same UA.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Ivo Sedlacek <[email-masked]>
Date: Tue, 8 May 2012 14:22:57 +0200

Hello,

please see below.

Kind regards

Ivo Sedlacek 

Ericsson

-----Original Message-----
> Sent: 8. května 2012 14:05 
> To: Ivo Sedlacek 
> > The Contacts represent different combinations of supported capabilities in the 
> UA. Scope of support of a capability can be dependent on what other capabilities 
> are supported. 
> 
> Honestly I don't understand it. I try to see it simple, and for me the above two 
> Contact are expressing contradictory capabilities for the same UA (sip.instance) 
> since the first one announces 

The UA is reachable using two contacts, each having different capabilities.
At the first contact, the UA has capability to handle full duplex audio. E.g. normal voice call.
At the second contact, the UA has capability to receive-only audio and video. E.g. TV broadcast.

Please note that neither of the contacts of the UA support full duplex audio and video.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 May 2012 09:44:17 -0400

I understand Ivo's point here - AFAIK there is no better way to indicate 
mutually exclusive capabilities.

	Thanks,
	Paul

On 5/8/12 8:22 AM, Ivo Sedlacek wrote:
>> 2012/5/8 Ivo Sedlacek<[email-masked]>:
>>>>> Contact:

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 8 May 2012 15:56:06 +0200

> mutually exclusive capabilities.

ok, so then it's seems more an issue in RFC 3840/3841, am I right?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 May 2012 10:08:06 -0400

On 5/8/12 9:56 AM, Iñaki Baz Castillo wrote:
> 2012/5/8 Paul Kyzivat<[email-masked]>:

It could be viewed that way - its a limitation.
Clearly you *can* work around the limitation in the way Ivo has shown. 
But that has consequences of its own. But its far from clear that it is 
enough of a problem to motivate seeking a better solution.

	Thanks,
	Paul

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 08 May 2012 09:30:29 -0500

> enough of a problem to motivate seeking a better solution.

Another workaround would be for the endpoint that embeds multiple UAs 
(in SIP terminology) with mutually exclusive sets of capabilities to 
just REGISTER multiple distinct Contact URIs, including sip.instance 
values and all other necessary parameters.

As previously discussed in this thread, RFC5626 may state that this is 
not supported, but nobody has indicated any reason why it wouldn't work. 
Registering multiple contacts with the *same* sip.instance value is 
known to be likely not to work with various registrars.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 May 2012 10:44:40 -0400

> known to be likely not to work with various registrars.

The cleanest way would be to register with two different contact 
addresses and two distinct instance ids. Then you really are registering 
distinct UAs with differing capabilities. This is entirely legal. But in 
the case of outbound it seems that it requires separate REGISTER 
messages, which is inconvenient.

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.

	Thanks,
	Paul

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 08 May 2012 10:07:36 -0500

> inefficient and will require care to provide a reasonable user experience.

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?

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 May 2012 11:46:06 -0400

> 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.

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

---

From: Ivo Sedlacek <[email-masked]>
Date: Wed, 9 May 2012 13:49:48 +0200

Hello,

please see below.

Kind regards

Ivo Sedlacek 

Ericsson

-----Original Message-----
> Sent: 8. května 2012 17:46 
> To: [email-masked] 
> >> Its also true that registering multiple contacts means that forked  
> >> call attempts may reach more than one of the instances. This is a bit  

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 
> 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.

> 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

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Wed, 09 May 2012 09:27:12 -0500

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

That's correct, because as Inaki posted previously, the RFC is covering 
the case where a UA registers multiple contacts using different 
transports/addresses/etc. that reach the *same* UA. In that case, the 
proxy only needs to send the request using one of those Contact URIs, 
because they are all the same UA.

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 and doesn't also 
result in requests being forked to your applications.

With that said, though, you've stated previously that your applications 
have mutually exclusive capability sets; if that's the case, and you 
registered Contact URIs for each of them, then a proxy following RFC3841 
rules would only select the *one* that is compatible with the caller's 
preferences. The others would be dropped from the candidate set before 
the request was forwarded, and no forking would occur, even if the 
registered URIs all had distinct sip.instance values.

If that's not true, then it appears that the underlying problem is that 
RFC3840 capability specifications aren't expressive enough to describe 
your UA's capabilities. You need both conjunctive and disjunctive logic, 
and grouping.

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 10 May 2012 14:52:23 +0200

Please see below.

Kind regards

Ivo Sedlacek

Ericsson

-----Original Message-----
> Sent: 9. května 2012 16:27
> To: [email-masked]
> > RFC5626 states that only one delivery (unless flow fails) is attempted to contacts
> with the same AOR and instance-id - see exceprt above.
>
> That's correct, because as Inaki posted previously, the RFC is covering the case
> where a UA registers multiple contacts using different transports/addresses/etc.
> that reach the *same* UA.

No problem there.

The original question of this thread was regarding single UA, using Outbound, where each REGISTER can contain multiple contacts, each having the same sip.instance, the same IP address and port and the same reg-id.

> In that case, the proxy only needs to send the request
> using one of those Contact URIs, because they are all the same UA.

That is the expected behavior.

> 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*.

> and doesn't also result in requests being forked to your applications.

As long as UA uses the same sip.instance on all contacts, RFC5626 guarantees that.

> With that said, though, you've stated previously that your applications have mutually
> exclusive capability sets; if that's the case, and you registered Contact URIs for
> each of them, then a proxy following RFC3841 rules would only select the *one* that
> is compatible with the caller's preferences. The others would be dropped from the
> candidate set before the request was forwarded, and no forking would occur, even
> if the registered URIs all had distinct sip.instance values.

Maybe it could be done that way (I haven't studied it). But, again, we don't consider the contacts being part of different UAs, and we have yet found no reason why using the same instance-id for each contact would not work.

Also, due to the characteristics of the instance-id (being able to survive reboots etc), it could very likely be based on some hardware identifier/parameter, in which case it would be very difficult to use different ones.

> If that's not true, then it appears that the underlying problem is that RFC3840 capability
> specifications aren't expressive enough to describe your UA's capabilities. You need
> both conjunctive and disjunctive logic, and grouping.

Using RFC3840, this can be expressed by a UA using multiple contacts.

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 10 May 2012 18:32:17 +0200

I am sorry, there was a typo in the mail below. Corrected now. Kind regards Ivo Sedlacek

-------------------------------------------------------------------------------------------------------------

Please see below.

Kind regards

Ivo Sedlacek

Ericsson

-----Original Message-----
> From: [email-masked] [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Kevin
> P. Fleming

No problem there.

> but there isn't a mechanism that exists today which is fully compliant with all of

I can't say what 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*.

> https://www.ietf.org/mailman/listinfo/sipcore <https://www.ietf.org/mailman/listinfo/sipcore>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 May 2012 15:34:57 -0400

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

> contemplated by the
> 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

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 11 May 2012 17:10:35 +0200

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

-----Original Message-----
> Sent: 10. května 2012 21:35 
> To: [email-masked] 
> > 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