Subject: [sipcore] Feature-tags in the Path header field

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Sep 2010 13:17:27 +0200

Hi,

Introduction:
-----------------

3GPP is working on solution which improves the ability to be able to move an ongoing IMS call from an IP based access network to a legacy CS based network without dropping the call.
The solution requires a media anchoring proxy (called ATCF) in the visited network, and a signaling anchoring application server (called SCC AS) in the users home network.

Problem:
------------

The SCC AS, when it receives a REGISTER request from a UA, needs to know whether there is a proxy with ATCF functionaltiy in the registration path. The reason is that the SCC AS can then choose to delegate session handover functionality to the ATCF, which provides advantages related to voice interruption etc.

Possible solution:
-------------------------

During registration the ATCF inserts a Path header field, so a solution to indicate its support of the ATCF functionlaity would be to insert a feature tag in the Path header field.

However, eventhough there is no syntax issue, the usage of feature tags have only been specified for the Contact, Accept-Contact, Reject-Contact and Refer-To header fields.

So, the question is whether there are any reasons why the proxy could not use a feature tag in the Path header field for this. Entities that don't support the feature will simply see it as an unsupported Path header field parameter, and a registrar doing normal feature tag matching shouldn't even look at the Path header field. And, based on the feature tag definitions in RFC3840 and RFC2703, we don't think the usage is necessarily limited to UAs

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Sep 2010 09:03:16 -0400

Christer,

Didn't somebody else already bring this up a few months ago?

IIUC, you are asking if Path can be used with a new parameter without 
any further standards action. Is that right?

If I go back to the definition of Path in 3327, I find that it allows 
multiple parameters of type "rr-param". It doesn't define rr-param, but 
does say the Path header field values must conform to the syntax of the 
Path element from 3261, which defines rr-param as generic-param.

So *syntactically* you can put whatever parameters you want in there, 
and sip parsers should not be troubled. But legalistically, new 
parameters can only be introduced via standards action.

I suspect the problem 3gpp is trying to address may be of more general 
interest. But its hard to decipher from your brief description. Can you 
provide a more complete description of the problem and the proposed 
solution? For instance, diagrams of the signaling and media paths before 
and after the handoff of the call.

	Thanks,
	Paul

On 9/17/2010 7:17 AM, Christer Holmberg wrote:
> Hi,
> Introduction:
> -----------------
> 3GPP is working on solution which improves the ability to be able to
> move an ongoing IMS call from an IP based access network to a legacy CS
> based network without dropping the call.
> The solution requires a media anchoring proxy (called ATCF) in the
> visited network, and a signaling anchoring application server (called
> SCC AS) in the users home network.
> Problem:
> ------------
> The SCC AS, when it receives a REGISTER request from a UA, needs to know
> whether there is a proxy with ATCF functionaltiy in the registration
> path. The reason is that the SCC AS can then choose to delegate session
> handover functionality to the ATCF, which provides advantages related to
> voice interruption etc.
> Possible solution:
> During registration the ATCF inserts a Path header field, so a solution
> to indicate its support of the ATCF functionlaity would be to insert a
> feature tag in the Path header field.
> However, eventhough there is no syntax issue, the usage of feature tags
> have only been specified for the Contact, Accept-Contact, Reject-Contact
> and Refer-To header fields.
> So, the question is whether there are any reasons why the proxy could
> not use a feature tag in the Path header field for this. Entities that
> don't support the feature will simply see it as an unsupported Path
> header field parameter, and a registrar doing normal feature tag
> matching shouldn't even look at the Path header field. And, based on the
> feature tag definitions in RFC3840 and RFC2703, we don't think the usage
> is necessarily limited to UAs
> Regards,
> Christer
>
>
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Sep 2010 15:19:18 +0200

Hi, 

>Didn't somebody else already bring this up a few months ago?

In that case I missed it :)

>IIUC, you are asking if Path can be used with a new parameter 
>without any further standards action. Is that right?

At this point I am asking about the usage of feature tags to indicate proxy features in general.

Whether it would require some standards actions needs to be checked.

>If I go back to the definition of Path in 3327, I find that 
>it allows multiple parameters of type "rr-param". It doesn't 
>define rr-param, but does say the Path header field values 
>must conform to the syntax of the Path element from 3261, 
>which defines rr-param as generic-param.
> 
>So *syntactically* you can put whatever parameters you want 
>in there, and sip parsers should not be troubled. But 
>legalistically, new parameters can only be introduced via 
>standards action.

Correct.

>From a pure syntax perspective it is not a problem.

But, for Contact, A-C, R-C and Refer-To we have defined "feature-param", which in this case would be an explicit usage of "rr-param".

>I suspect the problem 3gpp is trying to address may be of 
>more general interest. But its hard to decipher from your 
>brief description. Can you provide a more complete 
>description of the problem and the proposed solution? For 
>instance, diagrams of the signaling and media paths before 

Well, I was trying to keep the handover description as short as possible, because the intention was not to discuss it. But, for sure I can provide references if people want to read the details.

The idea was to provide some background information to show that there is a problem, to avoid questions like "You have a solution - where is the problem?" :)

I do, however, agree that the possibility to provide proxy features may be of more general interest, and that is also one reason I raised this issue on the list.

Regards,

Christer

> > move an ongoing IMS call from an IP based access network to 
> a legacy 
> > CS based network without dropping the call.
> > The SCC AS, when it receives a REGISTER request from a UA, needs to 
> > know whether there is a proxy with ATCF functionaltiy in the 
> > registration path. The reason is that the SCC AS can then choose to 
> > delegate session handover functionality to the ATCF, which provides 
> > advantages related to voice interruption etc.
> > Possible solution:
> > During registration the ATCF inserts a Path header field, so a 
> > solution to indicate its support of the ATCF functionlaity 
> would be to 
> > insert a feature tag in the Path header field.
> > However, eventhough there is no syntax issue, the usage of feature 
> > tags have only been specified for the Contact, Accept-Contact, 
> > Reject-Contact and Refer-To header fields.
> > matching shouldn't even look at the Path header field. And, 
> based on 
> > the feature tag definitions in RFC3840 and RFC2703, we 
> don't think the 
> > usage is necessarily limited to UAs Regards, Christer
> >
> >
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Sep 2010 09:34:49 -0400

Comments inline.

	Thanks,
	Paul

> In that case I missed it :)

Maybe I have it mixed up with something else. Had to do with media 
capabilities out at the edge upstream of the UA.

> At this point I am asking about the usage of feature tags to indicate proxy features in general.

Oh. I guess I missed the point.
But when feature tags are passed, it is as header parameters.
They have been explicitly defined to be allowed on Contact.
Every header is different in terms of what parameters it permits.

The fact that a parameter is defined for use on one header does not 
automatically usable with any other header. (Unless the two headers 
share some common definition. For instance, if the definition of 
rr-param was extended for Route then I believe Path would automatically 
pick that up as well.)

> But, for Contact, A-C, R-C and Refer-To we have defined "feature-param",

Yes.

> which in this case would be an explicit usage of "rr-param".

I don't follow your logic. How does definition of feature-param for the 
headers that have it relate in any way to rr-param?

> The idea was to provide some background information to show that there is a problem, to avoid questions like "You have a solution - where is the problem?" :)

I'm glad to hear that!

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Sep 2010 17:40:10 +0200

Hi,

>Every header is different in terms of what parameters it permits.

Feature tags as such are not defined for Contact, or only for UA capabilities.

RFC 3840 defines the feature-param parameter for Contact, A-C and R-C.

RFC 4508 defines feature-param for Refer-To.

So, if the idea of carrying feature tags in Path is ok as such, I guess one option would be an RFC which defines feature-param for Path (similar to what 4508 does for Refer-To).

So, the extended Path ABNF may look something like:

Path = "Path" HCOLON path-value *( COMMA path-value )

path-value = name-addr *( SEMI rr-param / feature-param )

(Assuming feature-param fits within the syntax for rr-param)

>The fact that a parameter is defined for use on one header does not automatically usable with any other header. (Unless the two headers
>share some common definition. For instance, if the definition of rr-param was extended for Route then I believe Path would automatically
>pick that up as well.)

I agree, and that's why I sent the e-mail to the list :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Sep 2010 11:52:53 -0400

> I agree, and that's why I sent the e-mail to the list :)

OK. That is something that can be discussed.

ISTM that Path is very similar to Route, and defined to work the same.
So either you define what these things mean for Route, or else you have 
to break the linkage and explain why these are appropriate for Path and 
not Route. Also, if they are appropriate for Path, then perhaps 
Service-Route too.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 17 Sep 2010 20:07:51 +0200

Hi,

>not Route. Also, if they are appropriate for Path, then perhaps

I am not sure about Route, because the value is normally either pre-defined/configured or built based on Record-Route, Path or Serivce-Route. But, I guess we would need to decide whether we allow it also for Record-Route and Service-Route. There is currently no need for it (at least not what I know about), but it would probably be wise to cover all headers if we decide to do something.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Sep 2010 17:59:58 -0400

> I am not sure about Route, because the value is normally either pre-defined/configured or built based on Record-Route, Path or Serivce-Route. But, I guess we would need to decide whether we allow i…

Well, IIUC, the point is to encode some features of a particular 
middlebox, for the benefit of its neighbors. Route (from R-R or 
otherwise) and Path both are used in similar ways. ISTM there is at 
least a reasonable chance that the functionality might apply to either.

In any case, right now the semantics of the values in the Path header 
are linked in the spec to those of the Route header. If you propose to 
make a change so that is no longer true, then you need to be very clear 
about that - its a bigger change to Path. (And Path isn't just for 3gpp, 
I think others use it too.)

Also, there is a need to specify what it *means* for a feature tag to be 
on a Path header field (or a Route header field). I know you have a 
particular use case in mind, but you can't just specify that. So far, 
features are properties of UAs, and have some relation to what might 
happen if you address a request to that for processing. What would it 
mean for a middle box? (E.g. What is the significance if some Path 
header has an "is_focus" feature tag?)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 18 Sep 2010 00:37:14 +0200

Hi Paul,

>> I am not sure about Route, because the value is normally either pre-defined/configured or built based on Record-Route, Path or Serivce-Route. But, I guess we would need to decide whether we allow it also for Record-Route and Service-Route. There is currently no 
>>need for it (at least not what I know about), but it would probably be wise to cover all headers if we decide to do something.
>

Yes, but my point was that a middlebox would probably insert the feature tag in R-R, rather than Route. But, those are details that would have to be sorted out, if we choose to work on this.

>are linked in the spec to those of the Route header.

Well, the "ob" parameter has different semantics depending on whether it's in Path or Route.

>If you propose to make a change so that is no longer true, then you need to be very clear

Yes, we for sure would need to sort those things out.

>particular use case in mind, but you can't just specify that.

In general I think we can only talk about "indicating support of feature", but the meaning of a specific feature tag would have to be specified in the associated feature specification. That is the case even for UAs, I believe.

>So far, features are properties of UAs, and have some relation to what might
>happen if you address a request to that for processing. 

I am not sure I agree that a feature is only a property of a UA. Where is that defined?

I DO agree, though, that within the SIP community we have so far only looked at functions related to UA features, so my question is whether there is interest to go beyond UAs.

>What would it mean for a middle box? (E.g. What is the significance if some Path header has an "is_focus" feature tag?)

The feature specification would need to define in which headers the feature tag has any meaning, and what the meaning is. Many features are probably only valid for a UAs.

But, again, there will for sure be details that have to be sorted out. I guess what we first need to decide is whether this is something we would be interested in working with in the first place.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Sep 2010 13:04:14 +0200

Hi,

I've submitted a draft, which extends the rr-param rule, allowing proxies to indicate supported features using feature tags in Path, Record-Route etc.

The draft can also be found at: http://users.piuha.net/cholmber/drafts/draft-holmberg-sipcore-proxy-feature-00.txt

As I indicated earlier on the list, and as you can read in the draft, there is a 3GPP use-case where we believe the mechanism could be used. But, there is nothing 3GPP specific about the mechanism as such.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Sep 2010 10:46:57 -0400

[as chair]

To all sipcore participants:

Christer has been looking for a way to accomplish a particular function 
that 3gpp wants. This proposal seems a plausible way to do that. But it 
is of necessity defining a more general mechanism.

I'd really appreciate comments from others (including people in no way 
involved with 3gpp) regarding this mechanism. For instance, do you 
consider the semantics to be well defined? Do you see need for more 
about security implications?

How many would find this useful to have?

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 27 Sep 2010 17:11:54 +0200

One issue that Paul hasn't raised is what happens if there are two or more Path, Service-Route or Record-Route entries declaring a particular feature. Or two or more entries, some but not all of which declare a particular feature. For the application that Christer has in mind, I would imagine it doesn't matter - the most important thing is that at least one entry declares the feature of interest. However, if we try to generalise the mechanism, such issues might become important.

I do not have an opinion on whether this is a good thing to do or not - just trying to understand the implications.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 27 September 2010 15:47
> To: Christer Holmberg
> Cc: [email-masked]
> Subject: Re: [sipcore] Draft new: 
> draft-holmberg-sipcore-proxy-feature [was: Feature-tags in 
> the Path header field]
> 
> [as chair]
> 
> > I've submitted a draft, which extends the rr-param rule, 
> allowing proxies to indicate supported features using feature 
> tags in Path, Record-Route etc.
> >
> > The draft can also be found at: 
> http://users.piuha.net/cholmber/drafts/draft-holmberg-sipcore-
> proxy-feature-00.txt
> >
> > As I indicated earlier on the list, and as you can read in 
> the draft, there is a 3GPP use-case where we believe the 
> mechanism could be used. But, there is nothing 3GPP specific 
> about the mechanism as such.
> >
> > Regards,
> >
> > Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 27 Sep 2010 19:28:41 +0200

Hi John and Paul,

>One issue that Paul hasn't raised is what happens if there are two or more Path, Service-Route or Record-Route entries declaring a particular feature. Or two or more entries, some but not all of which declare a particular feature. For the application that Christer has in >mind, I would imagine it doesn't matter - the most important thing is that at least one entry declares the feature of interest. However, if we try to generalise the mechanism, such issues might become important.

You raise a good point.

In my opinion multiple support indications should be covered by the feature specification, because I don't think it is possible to define a genral behavior.

I can add text about that in the draft.

>Christer has been looking for a way to accomplish a
>particular function that 3gpp wants. This proposal seems a plausible way to do
>that. But it is of necessity defining a more general mechanism.
>
>I'd really appreciate comments from others (including people
>in no way involved with 3gpp) regarding this mechanism. For instance, do you

I am pretty sure there will be more text added, if we decide to initiate the work on this.

Regards,

Christer

---

From: Peter Musgrave <[email-masked]>
Date: Mon, 27 Sep 2010 19:14:53 -0400

Hi,

I read the draft and I think the semantics are ok (although John's
point about multiple proxies with these tags is a good one).

One use which occurred to me - but which is no doubt controversial  -
is whether a proxy/B2B which is an SBC could provide a feature tag
indicating it is an SBC - so that UAs which register and call through
it could skip adding ICE candidates. (My point is merely that I
suspect other uses for this capability will be found - even if you
think this  particular idea is mis-guided).

Regards,

Peter Musgrave

On Mon, Sep 27, 2010 at 10:46 AM, Paul Kyzivat <[email-masked]> wrote:
> Christer has been looking for a way to accomplish a particular function that
> 3gpp wants. This proposal seems a plausible way to do that. But it is of
> necessity defining a more general mechanism.
>
> involved with 3gpp) regarding this mechanism. For instance, do you consider
> the semantics to be well defined? Do you see need for more about security
> implications?
>
>> I've submitted a draft, which extends the rr-param rule, allowing proxies
>> to indicate supported features using feature tags in Path, Record-Route etc.
>>
>> http://users.piuha.net/cholmber/drafts/draft-holmberg-sipcore-proxy-feature-00.txt
>>
>> As I indicated earlier on the list, and as you can read in the draft,
>> there is a 3GPP use-case where we believe the mechanism could be used. But,
>> there is nothing 3GPP specific about the mechanism as such.
>>
>> Regards,
>>
>> Christer
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 28 Sep 2010 10:29:28 -0400

> think this  particular idea is mis-guided).

Right, that particular idea is mis-guided. :)

What you'd really do for that is indicate whether or not the b2bua supports ICE (since some SBC's do, and some don't, indicating you're an SBC doesn't help).  

There already is a feature tag for ICE ("sip.ice"), but such a thing would break immediately - since ICE is a new thing, legacy SBC's wouldn't know to say they don't do it, and there is no "!(feature-tag)" anyway; and the UA doesn't know whether it's talking through SBC's or plain proxies to begin with, and if they're plain proxies they wouldn't say anything about ice ever... so the UA can never guess this right.  If it gets back "sip.ice" then it knows for that one hop that said so it's ok, but it knows nothing about the rest.  

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 28 Sep 2010 11:03:53 -0400

Part of me feels like this makes a lot of sense, because indicating proxy capabilities in a Path/Rec-route is similar to Contact, and it would be nice to be able to indicate some capabilities.  

The other part of me thinks "what the heck capabilities can a *PROXY* possibly have"?  A B2BUA would have lots, sure.  But not a real Proxy.  (and frankly every 3GPP "proxy" is a B2BUA in all but name)  So if we're talking about B2BUA's indicating capabilities, I've got some comments but I'll send them separately.

But for this service continuity use in particular: I don't know why 3gpp's bothering to go this route - the ATCF/P-CSCF/whatever is a B2BUA.  It can change the Contact, so have it insert the feature tag in the Contact of the REGISTER, and delete it in the response.  Problem solved.

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 28 Sep 2010 18:30:47 +0200

Hi,

>Part of me feels like this makes a lot of sense, because indicating 
>proxy capabilities in a Path/Rec-route is similar to Contact, and it would be nice to be able to indicate some capabilities.
>
>The other part of me thinks "what the heck capabilities can a *PROXY* 
>possibly have"?  A B2BUA would have lots, sure.  But not a real Proxy.  
>(and frankly every 3GPP "proxy" is a B2BUA in all but name)  So if we're talking about B2BUA's indicating capabilities, I've got 
>some comments but I'll send them separately.

Well, we are talking about entities inserting Path and/or Record-Route. Sure, some of them might not be "pure" proxies.

>But for this service continuity use in particular: I don't know why 
>3gpp's bothering to go this route - the ATCF/P-CSCF/whatever is a 
>B2BUA.  It can change the Contact, so have it insert the feature tag in the Contact of the REGISTER, and delete it in the response.
>Problem solved.

While the ATCF need not be a "pure" proxy, it is not supposed to modify the dialog identifiers. Without going into details, ATCF 
acting as B2BUA and changing the dialog identifier would raise a number of issues related to functions like inter UE transfer, access 
transfer etc. 

Also note that ATCF adding a feature tag into the Contact header field in REGISTER request would also cause reg event package 
NOTIFY to contain the added feature tag. The UE receiving the reg event package NOTIFY would be quite confused as its contact 
address would have additional feature tags. Parsing and modifying the XML is not desired.

Regards,

Christer

if UE supports multiple registrations and registers over two different access networks and subscribes to reg event package over each registration, then the UE will get the NOTIFYies over both registrations. 
ATCF will however be involved only in the registration over the GPRS/EPS access networks.
Let alone that it would mean quite a lot of XML parsing and assembling.

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 28 Sep 2010 13:26:29 -0400

> acting as B2BUA and changing the dialog identifier would raise a number of issues related to functions like inter UE transfer, access 

What dialog identifiers?  We're talking about a Contact of a REGISTER, no?

> address would have additional feature tags. Parsing and modifying the XML is not desired.

Don't bother keeping it that way then.  This is already a private network thing to begin with, so specify that the S-CSCF treats that 3gpp.svcc thing of a REGISTER as the network-inserted indication that it is, rather than as opaque UE capabilities (ie, so it won't show up in XML stuff, because it won't be stored in the UE's normal Registered feature tags set in the databases).  Or are you worried about a case of the REGISTER going to another domain (like through a Visited to a Home domain)?

-hadriel

---

From: "Leis, Peter (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 29 Sep 2010 09:33:25 +0200

See below

> > Also note that ATCF adding a feature tag into the Contact header
> field in REGISTER request would also cause reg event package
> > NOTIFY to contain the added feature tag. The UE receiving the reg
> event package NOTIFY would be quite confused as its contact
> > address would have additional feature tags. Parsing and modifying
the
> XML is not desired.
> >>
> >>
> 
> Don't bother keeping it that way then.  This is already a private
> network thing to begin with, so specify that the S-CSCF treats that
> 3gpp.svcc thing of a REGISTER as the network-inserted indication that
> it is, rather than as opaque UE capabilities (ie, so it won't show up
> in XML stuff, because it won't be stored in the UE's normal Registered
> feature tags set in the databases).  Or are you worried about a case
of
> the REGISTER going to another domain (like through a Visited to a Home
> domain)?

Yes, the entity (ATCF) indicating its capabilites may reside in the
visited network, while S-CSCF is in the home. So you may end up in a
situation where the S-CSCF does not understand the semantics of
"3gpp.svcc" appended to the Contact. So the tag would end up in the
"normal" registered feature tags of the UE.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 29 Sep 2010 13:47:12 +0200

Hi,

>>of the REGISTER going to another domain (like through a Visited to a Home
>>domain)?
>

Peter is correct.

Also, the registered Contact represents the UE and the capabilities it supports - even in 3GPP :)  In my opinion it has been like that from day one, and a change to that would not be accepted.

And, I think it would be very strange for IETF to tell 3GPP to do such change, instead of using a more SIP- and IETF "friendly" and standardized mechanism.

Regards,

Christer

---

From: "Leis, Peter (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 30 Sep 2010 11:20:17 +0200

I do find such a mechanism useful.

regards
Peter

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of ext Paul Kyzivat
> Sent: Monday, September 27, 2010 4:47 PM
> To: Christer Holmberg
> Cc: [email-masked]
> Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature
> [was: Feature-tags in the Path header field]
> 
> [as chair]
> 
> > I've submitted a draft, which extends the rr-param rule, allowing
> proxies to indicate supported features using feature tags in Path,
> Record-Route etc.
> >
> there is a 3GPP use-case where we believe the mechanism could be used.
> But, there is nothing 3GPP specific about the mechanism as such.
> >
> > Regards,
> >
> > Christer