Subject: [sipcore] Modification proposal to RFC3841

From: Xavier Marjou <[email-masked]>
Date: Thu, 8 Dec 2011 13:53:48 +0100

Hi,

Together with some colleagues, we would like to propose a modification
to RFC3841 (Caller Preferences for the SIP).

The motivation comes from the fact that the proxy behavior specified
in RFC3841 gives an exaggerated preferential treatment to reach “old”
UAs (i.e. UAs implementing RFC3261 only) to the detriment of “new” UAs
(i.e. UA implementing RFC3261 and RFC3840). As a consequence, when
RFC3841 is used on our SIP proxies, most of the SIP calls (SIP
INVITEs) terminate at an “old” device rather than at a “new” device.
This is unfair for “new” UAs: they make efforts to implement RFC3840
(and generally other new features/rfcs as well) but they will never be
reached.

The thing that happens is the following:
-	An “old” UA sends REGISTER with an “old” Contact (e.g.
Contact:sip:[email-masked])
-	A “new” UA sends a REGISTER with a “new” Contact having a
sip.instance feature parameter (e.g.
Contact:sip:[email-masked];+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
-	A SIP INVITE always arrives at the “old” UA, as its Contact is
“immune” and thus benefits from a greater priority than a Contact
having feature parameters according to RFC3841 rules.

There is thus a need to somehow decrease the priority of “old” UA (ie:
UAs that have no feature parameters), otherwise RFC3841 is useless.

We would there like to propose the following modification to Section
7.2.3 of RFC3841:
   4. If the Contact URI has no "methods" feature parameter, the feature tag
   methods="INVITE,OPTIONS,BYE,CANCEL,ACK" SHOULD be appended to
   the list.

What do you think ?

Cheers,
Xavier

PS: here is a more detailed example of a typical problem encountered
when a proxy in the network supports RFC3841.
RFC3841 creates a side-effect. The presence of the +sip.instance
feature tag modifies the proxy behavior although no preference has
been expressed by the caller.

Case I.

1) Bob registers two contact addresses for his AoR:
Contact:sip:[email-masked] and Contact:sip:[email-masked]
2) Alice calls Bob’s AoR. The INVITE request does not include any
Feature Preference or Request Handling Preference.
3) Bob’s proxy applies RFC3841 procedures. As it does not find any
explicit preference it extracts implicit preferences from the request
as specified in RFC3841 Clause 7.2.2. It then behaves as if it had
received the INVITE request with Accept-Contact: *;method=
«INVITE»;require
4) Bob’s proxy retrieves the two contact addresses. As c1 and c2 have
no feature parameters, they are said to be immune to caller preference
processing and are removed from the target set temporarily.
5) At the end both contacts are back in the target set with the same
Qa score of 1.
6) Bob’s proxy forks the request in parallel towards both targets.

Case II.

1) Bob registers two contact addresses for his AoR:
Contact:sip:[email-masked];+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
and Contact:sip:[email-masked]
2) Alice calls Bob’s AoR. The INVITE request does not include any
Feature Preference or Request Handling Preference.
3) Bob’s proxy applies RFC3841 procedures. As it does not find any
explicit preference it extracts implicit preferences from the request
as specified in RFC3841 Clause 7.2.2. It then behaves as if it had
received the INVITE request with Accept-Contact: *;method=
«INVITE»;require
4) Bob’s proxy retrieves the two contact addresses. As c2 has no
feature parameters, it is said to be immune to caller preference
processing and is removed from the target set temporarily. The
+sip.instance feature parameter is used to create a contact predicate
for c1.
5) At the end the The Qa score for c1 is 0 and c2 is put back in the
target set with a Qa score of 1.
6) Bob’s proxy forwards the request to contact c2 first. And then
sequentially to contact c1.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Dec 2011 23:59:38 +0800

As co-chair, but also as one of the authors of 3841:

The issue raised here is subtle. The entire contact selection and 
prioritization scheme was already nearly incomprehensible. (I'm not 
proud of that, but I was a newbie at the time.)

I don't have information about existing implementations, and typical 
usage of those implementations. I would like to see several (ideally 
three or more) who have worked on, or used, callerpref implementations, 
be involved in discussions. If you fall into that category, please speak 
up.

Others, who haven't delved into this subject are also welcome, but 
engaging meaningfully in the discussion will involve careful study of 
3840/3841.

	Thanks,
	Paul

On 12/8/11 8:53 PM, Xavier Marjou wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 8 Dec 2011 12:27:44 -0500

> From: Xavier Marjou [[email-masked]]
> 

That doesn't solve the problem well, unfortunately.  Consider your
Case II, but with the incoming request being SUBSCRIBE (or MESSAGE).
Since the second contact has an implicit
'methods="INVITE,OPTIONS,BYE,CANCEL,ACK"' and the request has an
implicit '(sip.methods=SUBSCRIBE)' *with the reqire flag*, the
SUBSCRIBE could never be delivered to the second contact even if the
first contact was nonresponsibe.

Part of the problem is that the logic of RFC 3841 assumes that if a UA
registers a contact with any feature parameters, the UA understands
and is implementing RFC 3841, and specifically, will include feature
parameters that describe all of its features.  In particular, that it
will include a 'methods' feature parameter.  But the reality is that
most UAs that include a +sip.instance parameter are doing so to
implement GRUU and/or SIP Outbound, and logic should not assume that
they support *no* methods.

The logic of RFC 3841 holds that if an (implicit or explicit)
Accept-Contacts demands a particular value for a particular feature, a
UA will be downgraded if it does not declare a value for that feature.
The exemption is that if the UA provided *no* feature parameters, than
it will not be downgraded.  Rather the logic should (IMHO) not
downgrade the contact unless it provides an incompatible value for the
feature (unless there was an explicit 'require' flag).

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Dec 2011 13:41:03 -0500

> they support *no* methods.

An interesting observation. Of course those other uses for feature tags 
didn't exist when 3841 was written.

In retrospect, we should perhaps have called out in outbound and gruu 
that use of those made it mandatory to implement 3841.

> feature (unless there was an explicit 'require' flag).

I'll defer commenting on this. I always have to go back and study the 
complete algorithm again before drawing any conclusions, and that gives 
me a headache.

My feeling is that the most straightforward way to deal with this is for 
those that are having trouble to get each UA to register with all of its 
callerprefs, rather than introducing new defaulting.

	Thanks,
	Paul

---

From: Xavier Marjou <[email-masked]>
Date: Fri, 9 Dec 2011 16:16:08 +0100

> first contact was nonresponsibe.

Hi Dale,

The proposal is not to add methods="INVITE,OPTIONS,BYE,CANCEL,ACK" to the
list of Contact URI having no parameters at all.
The proposal is to add methods="INVITE,OPTIONS,BYE,CANCEL,ACK" to the list
of Contact URI having no "methods" parameters.
So in the example with the SUBSCRIBE message, the proposal does work : both
Contact URIs have no "methods" param when being processed by the proposed
treatment 7.2.3.#4 , thus each one will have
methods="INVITE,OPTIONS,BYE,CANCEL,ACK" added into its related list, and
they will thus end-up with the same priority.

Cheers,
Xavier

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 9 Dec 2011 16:31:08 +0100

One point I'd offer is that the proposal is making the assumption that all existing UAs not implementing RFC 3841 essentially implement the INVITE method, and are prepared to receive and process such INVITE requests.

As far as I am aware, it is perfectly possible that an implementation only provide the REGISTER method, and for example SUBSCRIBE and PUBLISH. The proposal above would require all such devices used in a multi-terminal situation to implement RFC 3841 in order to avoid receiving INVITE requests not intended for them.

Regards

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xavier Marjou
Sent: 09 December 2011 15:16
To: Worley, Dale R (Dale)
Cc: SIPCORE
Subject: Re: [sipcore] Modification proposal to RFC3841

On Thu, Dec 8, 2011 at 6:27 PM, Worley, Dale R (Dale) <[email-masked]<mailto:[email-masked]>> wrote:
> From: Xavier Marjou [[email-masked]<mailto:[email-masked]>]
>

Hi Dale,

The proposal is not to add methods="INVITE,OPTIONS,BYE,CANCEL,ACK" to the list of Contact URI having no parameters at all.
The proposal is to add methods="INVITE,OPTIONS,BYE,CANCEL,ACK" to the list of Contact URI having no "methods" parameters.
So in the example with the SUBSCRIBE message, the proposal does work : both Contact URIs have no "methods" param when being processed by the proposed treatment 7.2.3.#4 , thus each one will have methods="INVITE,OPTIONS,BYE,CANCEL,ACK" added into its related list, and they will thus end-up with the same priority.

Cheers,
Xavier

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 10 Dec 2011 01:01:57 +0000

On Dec 9, 2011, at 10:16 AM, Xavier Marjou wrote:

> On Thu, Dec 8, 2011 at 6:27 PM, Worley, Dale R (Dale) <[email-masked]> wrote:

That won't solve the problem.  Ultimately you're guessing that UA-2 only supports those methods, so if you guess wrong, it will break.  For example, how do you know neither UAs support the MESSAGE method?

It would be better to use an implicit 'methods="*"' concept.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 10 Dec 2011 01:19:19 +0000

On Dec 8, 2011, at 1:41 PM, Paul Kyzivat wrote:

> In retrospect, we should perhaps have called out in outbound and gruu that use of those made it mandatory to implement 3841.

That would have made it a lot harder to deploy outbound.  We've successfully convinced some providers to deploy outbound's instance param and get their Registrar and UAs to do it, but I doubt we could have convinced them to do full 3841.

I wonder if we should not have had the instance id be a feature tag to begin with.  It's not a feature preference.

> I'll defer commenting on this. I always have to go back and study the complete algorithm again before drawing any conclusions, and that gives me a headache.
> 
> My feeling is that the most straightforward way to deal with this is for those that are having trouble to get each UA to register with all of its callerprefs, rather than introducing new defaulting.

Changing existing UAs is really really hard, in many ways.  Changing the rules of RFC 3841 with an update/extension and changing the deployed proxies is easier, afaict.

ISTM that Dale has it right: the logic should be if you don't explicitly indicate a given feature-tag, it's essentially unknown whether you do/don't support it, and requests should be routed to you as if you did.  Or if we really want to preserve the property of implicitly unsupported, then we'll have to update 3841 to exempt "sip.instance", "sip.message" and "sip.ice".

-hadriel