Subject: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Oct 2011 11:31:41 -0400

[as co-chair]

Christer submitted draft-ietf-sipcore-proxy-feature-reqs-01 some time 
ago. But there has been *no* discussion on it. There had been a *little* 
discussion on -00, by John, Dale, and Andrew. I think -01 addressed some 
of those comments, but I'm pretty sure it didn't address Andrew's.

Christer would like to finalize this, but I don't think its had enough 
discussion to justify going to WGLC.

Dale and John - woujld would you please check if your concerns have been 
addressed in -01?

Christer - can you please respond to Andrew's comments from
http://www.ietf.org/mail-archive/web/sipcore/current/msg04222.html,
either explaining how they are covered or why they shouldn't be?

Others, please take another look at this - it seems to have fallen off 
the radar screen.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Oct 2011 19:29:54 +0200

Hi, 

>Christer - can you please respond to Andrew's comments from http://www.ietf.org/mail-archive/web/sipcore/current/msg04222.html,

At least Andrew's comment regarding service invocation was discussed in Quebec, and the WG agreed that it outside the scope.

Andrew also had some requirement proposals, and eventhough they are not in the draft in his suggested wording, I think that the current requirements should cover them. But, I hope Andrew will indicate whether that's not the case :)

Regards,

Christer

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 6 Oct 2011 14:29:59 -0400

I think we can improve the wording of REQ-9, which is currently:

   REQ-9: If a SIP entity that does not support the proxy feature/
   capability indication mechanism receives a feature support
   indication, it MUST act as if it hadn't received the indication.

I think the wording is poor in that it is written as a requirement on
proxies that do not support our mechanism.  But of course, we can't
place requirements on devices that do not implement the RFC.

Additionally, we want the feature indication to pass through such
proxies unchanged, which is not stated.

I propose:

   REQ-9:  If a SIP entity that does not support the proxy feature/
   capability indication mechanism receives a feature support
   indication, the baseline SIP rules MUST ensure that the entity will
   act as if it hadn't received the indication.  Additionally, the
   baseline SIP rules MUST ensure that the indication will pass
   through the entity in the same manner and to the same degree as if
   the entity supported the mechanism and desired not to add to or
   remove from the indicated feature support.

The second sentence is a little vague, but it tries to cover many
cases.  For entities that are proxies, it means that the indication
will pass through the proxy transparently.  For entities that are UAs,
I haven't thought through all the possibilities, but there may be some
indications we want a UAC to "absorb" and not copy into the response,
and there may be some indications we want a UAC to "turn around" by
copying into the response.  I've written the second sentence to cover
both cases; a non-supporting UAC must not defeat the feature signaling
mechanism.

I think we all intuitively agree on what REQ-9 is to accomplish, but this
wording makes the meaning clearer.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Oct 2011 14:47:02 -0400

> place requirements on devices that do not implement the RFC.

I'm glad you brought this up - I was about to comment as well.

> proxies unchanged, which is not stated.

Yes. "act as if it hadn't received the indication" could imply that the 
indication would not be passed on.

> both cases; a non-supporting UAC must not defeat the feature signaling

Works for me. We now have it written such that the mechanism only 
applies to proxies, but the language is still good.

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 6 Oct 2011 14:47:33 -0400

> From: Paul Kyzivat [[email-masked]]
> 

I don't think my concerns expressed in
http://www.ietf.org/mail-archive/web/sipcore/current/msg04201.html are
completely taken care of by -01, but I've discussed the remaining
concern in the e-mail I just sent.

Also, looking at
http://www.ietf.org/mail-archive/web/sipcore/current/msg04195.html, I
see the following discussion between John Elwell and Christer (edited
for formatting):

>Christer Holmberg writes:
>> John Elwell writes:
>>> 1) There is a requirement for a proxy to be able to
>>>    indicate support for a capability to other proxies
>>>    in the path of a dialog forming transaction and to
>>>    the two endpoints of that transaction.
>>
>> [JRE] I don't think this makes it clear whether the indication of
>> support is intended to mean:
>> a) there is a proxy somewhere on the path that supports this feature; or
>> b) a particular proxy (as identified somehow) supports this feature.
>> 
>> Section 4 of the draft, although not entirely clear, seems to hint
>> at b) because of the mechanisms it suggests, whereas Robert's
>> text leaves it completely open. I think we need to nail down
>> this aspect of the requirement better.
>
>The intention is b). I'll look how to clarify it.

This seems to discuss the concept that the proxy-feature indication
will not only allow a device in the signaling path to determine the
*availability* of a particular feature in one direction or the other
of the signaling path, but also in some manner identify *which* proxy
provides the feature.

If I am correct, this is related to Andrew's desire that the
indication can tell how to address the providing device directly.

As far as I can tell, draft-ietf-sipcore-proxy-feature-reqs-01 does
not require this sort of identification.  If this is a desired
requirement, we need to add a requirement statement for it.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Oct 2011 22:10:38 +0200

Hi,

>Yes. "act as if it hadn't received the indication" could imply that the indication would not be passed on.
>
>> I propose:
>>
>Works for me. We now have it written such that the mechanism only applies to proxies, but the language is still good.

The suggested text looks fine to me too.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Oct 2011 16:19:10 -0400

> of the signaling path, but also in some manner identify *which* proxy

Certainly the mechanism proposed by Christer had this property.

Christer - do you consider that an essential property, or just something 
incidental to the mechanism? If its essential, then it should be called 
out specifically.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Oct 2011 22:45:34 +0200

Hi, 

>>>>> at b) because of the mechanisms it suggests, whereas Robert's text 
>>>> leaves it completely open. I think we need to nail down this aspect 
>>>> of the requirement better.
>>>

Correct.

>Christer - do you consider that an essential property, or just something incidental to the mechanism? If its essential, then it should be called out specifically.

It is essential. I thought it was clear in the requirements ("It MUST be possible for a SIP proxy to indicate"), but I agree should be explicitly called out.

What about modifying REQ-1 in the following way:

	REQ-1: It MUST be possible for a SIP proxy to indicate, and convey to
   	other SIP entities in the signalling path of a registration request,
   	support of a particular feature/capability <new>by that particular
	SIP proxy</new>.

Similar modificiatons would be done for REQ-2 and REQ-3. I don't think the modification is needed for the other requirements, but please correct me if you disagree.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Oct 2011 22:57:56 +0200

Hi, 

>> Dale and John - woujld would you please check if your concerns have 
>> been addressed in -01?
>
>http://www.ietf.org/mail-archive/web/sipcore/current/msg04201.html are completely taken care of by -01, but I've discussed the remaining concern in the e-mail I just sent.

I did propose a way forward regarding your concerns, and since you didn't come back I thought you were ok with them, and I implemented them :)

Note, though, that REQ-4 in -00 has became REQ-5 in -01, due to the decision (based on comments from Robert) to split REQ-4 into two spearate requirements.

Regards,

Christer

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 6 Oct 2011 17:06:31 -0400

> From: Christer Holmberg [[email-masked]]
> 
> >Christer - do you consider that an essential property, or just
> >something incidental to the mechanism? If its essential, then it
> >should be called out specifically.
> 
> It is essential. I thought it was clear in the requirements ("It MUST
> be possible for a SIP proxy to indicate"), but I agree should be
> explicitly called out.

The text is "It MUST be possible for a SIP proxy to indicate ...
support of ...".  The difficulty lies in the implied subject of the
action "support".  If one said "... to indicate that it supports ...",
it is clear that the indication includes the identify of the proxy
that does the supporting.  If one said "... to indicate that a feature
is supported", it would suggest that the indication did not identify
the proxy that does the supporting.

But in any case, since this is an important requirement we should
state it directly.

> Similar modificiatons would be done for REQ-2 and REQ-3. I don't think
> the modification is needed for the other requirements, but please
> correct me if you disagree.

I'm sure that you want to make the same modification to REQ-2, as this
is a case that is disjoint from the case of REQ-1, the mechanism in
dialog-forming requests may differ from that in REGISTERs.  I don't
think the modification is needed in REQ-3, as that is an additional
requirement on the cases of REQ-1 and REQ-2.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 7 Oct 2011 11:52:56 +0200

Hi, 

>> It is essential. I thought it was clear in the requirements 
>> ("It MUST be possible for a SIP proxy to indicate"), but I agree should be 
>> explicitly called out.
> 
> support of ...".  The difficulty lies in the implied subject 
> of the action "support".  If one said "... to indicate that 
> it supports ...", it is clear that the indication includes 
> the identify of the proxy that does the supporting.  If one 
> said "... to indicate that a feature is supported", it would 
> suggest that the indication did not identify the proxy that 
> does the supporting.
> 
> But in any case, since this is an important requirement we 
> should state it directly.
> 
>>         REQ-1: It MUST be possible for a SIP proxy to 
>>         indicate, and convey to other SIP entities in the signalling path of a 
>>         registration request, support of a particular feature/capability <new>by 
>>         that particular SIP proxy</new>.
>> 
>> Similar modificiatons would be done for REQ-2 and REQ-3. I 
>> don't think the modification is needed for the other requirements, but please 
> I'm sure that you want to make the same modification to 
> REQ-2, as this is a case that is disjoint from the case of 
> REQ-1, the mechanism in dialog-forming requests may differ 
> from that in REGISTERs.  I don't think the modification is 
> needed in REQ-3, as that is an additional requirement on the 
> cases of REQ-1 and REQ-2.

Ok. So, the suggestion is to modify REQ-1 and REQ-2, by appending the new text to the end.

Regards,

Christer

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 7 Oct 2011 13:55:29 -0400

> be possible for a SIP proxy to indicate"), but I agree should be

I've just re-read the use cases (sections 1.1 and following) and none
of them call out the need for this identification facility.  Cases
1.1, 1.2.1, and 1.2.2 only require "... determine whether ...".  Case
1.3 is not clear; the specific requirements of that use case are not
clear.

I believe it would be very helpful to update one or more of the use
cases to show clearly the need for identifying which proxy provides a
feature, or to add a new use case that does so.

Also, use case 1.3 should be edited to clarify the specific
requirements it places on the mechanism.

Also, I think the use cases (sections 1.1 and following) should be
separated from the Introduction and placed into their own section.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Oct 2011 14:22:19 -0400

Inline

> feature, or to add a new use case that does so.

I'm trying to sort out what the concerns are about this.

One might be for some server on the path to determine whether this 
functionality is present upstream from it, or downstream of it. Having 
the feature associated with a particular element in the path is one way 
to accomplish that, maybe the easiest way, but not the only way.

Another is that there is *really* a need to know *which* server has the 
functionality. I can only think of a couple of reasons why:
- there is need to send a request to it
   (which relates to Andrew's earlier proposals)
- there is a need to validate it based on other properties
   of its entry in the route

We should sort out which of these are the real requirements.

	Thanks,
	Paul

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 13 Oct 2011 19:26:49 +0000

On Oct 7, 2011, at 2:22 PM, Paul Kyzivat wrote:

> One might be for some server on the path to determine whether this functionality is present upstream from it, or downstream of it. Having the feature associated with a particular element in the path is one way to accomplish that, maybe the easiest way, but not the only way.
> 
> Another is that there is *really* a need to know *which* server has the functionality. I can only think of a couple of reasons why:

The problem with trying to learn which particular server supports feature X is that the identification of a particular server often doesn't get conveyed beyond the local SIP domain.  SBCs, for example, have a popular feature called "Topology Hiding" which involves removing things like Record-Routes, Via, etc.  Beyond the security/privacy reasons, it's also one of the things that often keep SIP messages small enough to use UDP without fragmentation.

Because of that, even though SBCs could be made to pass on the feature capability information of other servers, I seriously doubt they'd do so by keeping the Record-Routes intact nor even by encrypting the Record-Route URIs.   They'd probably just copy the feature info into the SBC's own contact/record-route/path/whatever.  That would mean (1) you couldn't know which particular server supported that feature, and (2) the feature would only apply for that specific dialog.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Oct 2011 16:03:40 -0400

> Because of that, even though SBCs could be made to pass on the feature capability information of other servers, I seriously doubt they'd do so by keeping the Record-Routes intact nor even by encryp…

Once again we find ourselves designing around the unspecified behavior 
of the SBC. :-(

If the feature is associated with a particular element, and then the 
behavior you describe is applied, the feature would still be at the 
proper place in the revised record-route, which would be sufficient for 
determining if it was upstream or downstream of some other element still 
visible in the record-route. But if its necessary to identify the 
precise server, then the SBC will probably break it.

We probably need to hear what Christer thinks about this. It may turn 
out that all the interesting stuff happens all on one side of an SBC, 
and so doesn't get masked.

	Thanks,
	Paul

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 13 Oct 2011 22:10:30 +0200

2011/10/13 Paul Kyzivat <[email-masked]>:
> Once again we find ourselves designing around the unspecified behavior of
> the SBC. :-(

What is a SBC? I cannot find it into the 200 RFC's related to SIP. :)

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 13 Oct 2011 20:16:17 +0000

Then you haven't read RFC 5853.
:)

-hadriel

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 13 Oct 2011 22:17:04 +0200

> What is a SBC? I cannot find it into the 200 RFC's related to SIP. :)

Sorry, Iñaki, 

There is one.

http://tools.ietf.org/html/rfc5853

/O ;-)

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 13 Oct 2011 22:24:30 +0200

> Then you haven't read RFC 5853.

That's a RFC that talks about devices specified nowhere, instead of
being devices based on a RFC :)

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 13 Oct 2011 20:28:14 +0000

On Oct 13, 2011, at 4:03 PM, Paul Kyzivat wrote:

> Once again we find ourselves designing around the unspecified behavior of the SBC. :-(

That behavior is documented in RFC 5853, section 3.1.1.

But it doesn't really matter.  Forget about it being an SBC - let's just talk about B2BUAs.  A SIP B2BUA is, in its ultimate/full form, the logical end of one SIP scope and the beginning of another.  There is nothing requiring the UAS side of a B2BUA to copy the received set of Record-Routes to the UAC side of itself.  Some do, some don't.

-hadriel

---

From: "Gilad Shaham" <[email-masked]>
Date: Thu, 13 Oct 2011 23:01:24 +0200

Topology hiding which removes the record-route headers inherently means the 
other side does not obtain any information on the network, thus it shouldn't 
be possible to identify which server supports which feature since the 
existence of the server should not indicated in the first place. Requiring 
SBCs to convey the relevant information in their own 
contact/record-route/path makes sense in that scenario. What I'm saying is 
that this may be a non-issue from this RFC perspective even if SBC is 
involved, thus, if I'm right, there no need to design around the SBC 
behavior.

-----Original Message----- 
From: Paul Kyzivat
Sent: Thursday, October 13, 2011 10:03 PM
To: Hadriel Kaplan
Cc: <[email-masked]>
Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs 
WHICH proxy provides the feature

On 10/13/11 3:26 PM, Hadriel Kaplan wrote:
> The problem with trying to learn which particular server supports feature 
> X is that the identification of a particular server often doesn't get 
> conveyed beyond the local SIP domain.  SBCs, for example, have a popular 
> feature called "Topology Hiding" which involves removing things like 
> Record-Routes, Via, etc.  Beyond the security/privacy reasons, it's also 
> one of the things that often keep SIP messages small enough to use UDP 
> without fragmentation.
>
> Because of that, even though SBCs could be made to pass on the feature 
> capability information of other servers, I seriously doubt they'd do so by 
> keeping the Record-Routes intact nor even by encrypting the Record-Route 
> URIs.   They'd probably just copy the feature info into the SBC's own 
> contact/record-route/path/whatever.  That would mean (1) you couldn't know 
> which particular server supported that feature, and (2) the feature would 
> only apply for that specific dialog.

Thanks,
Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Oct 2011 17:06:48 -0400

> But it doesn't really matter.  Forget about it being an SBC - let's just talk about B2BUAs.  A SIP B2BUA is, in its ultimate/full form, the logical end of one SIP scope and the beginning of another…

Actually, as the draft is now written it only applies to proxies.
As long as there are no B2BUAs in the path then its irrelevant.

And for some B2BUAs it doesn't matter. For instance, with a conference 
focus, each connection to the focus in independent. Presumably nobody 
would expect to have this stuff propagate across a focus to the other 
participants.

The place it matters is if there are B2BUAs on the signaling path that 
want to be viewed as roughly equivalent to proxies. From a normative 
perspective they need to behave as UAs, not proxies.

Again, lets see what Christer and others that have a need for this think.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Oct 2011 17:23:33 -0400

On 10/13/11 4:17 PM, Olle E. Johansson wrote:
>> 2011/10/13 Paul Kyzivat<[email-masked]>:

I don't want to get into a pissing match here.
SBCs are a fact of life, like NATs.

But 5853 is not a *specification* of behavior. Its a description of some 
observed behavior based on a limited sample set as of April 2010 or before.

AFAIK it was never intended as something to be used by implementers to 
decide what kinds of usage will and won't work in the presence of SBCs. 
Its been stated many times that the exact behavior of many SBCs is 
highly dependent on configuration by those deploying them in a 
particular network. So what will and won't work depends more upon the 
tastes of your SP than it does on the SBC vendors.

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 14 Oct 2011 15:37:11 -0400

A little consideration of the philosophy of SIP raises warning flags
regarding any feature which carries information regarding *which*
upstream or downstream element performs a particular function, as
opposed to a feature which carries information about *whether* *some*
upstream or downstream element performs a particular function.  On the
whole, SIP does a good job of hiding upstream and downstream
complexities, and its structure tends to prevent implementers from
building horrible code that depends on particular arrangements of
upstream/downstream elements.  The result is a remarkably high level
of interoperability.  In particular, this architecture makes it
possible to build SBCs with a reasonable amount of effort, because an
SBC does not have to pass through any detailed information about "what
is on the other side".

In our situation, we should have a strong bias against a mechanism
that specifies which proxy provides a particular function.  Perhaps
the use cases really do require that, in which case we should provide
that.  But we should examine the use cases very carefully to see if we
can avoid it.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Oct 2011 17:01:29 -0400

I'm refraining from expressing too much of an opinion of what this 
should do, since I'm not the one that feels a need for this. I'm 
focusing on ensuring that we don't do something that violates general 
principles, and that is done well.

So I would really like to hear from those that feel a need to say more 
about what it is they need.

The mechanism Christer proposed *did* specify which proxy has the 
feature. But that doesn't mean its necessary to know that.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 16 Oct 2011 15:41:29 +0200

Hi,

>> But it doesn't really matter.  Forget about it being an SBC 
>> - let's just talk about B2BUAs.  A SIP B2BUA is, in its 
>> ultimate/full form, the logical end of one SIP scope and the 
>> beginning of another.  There is nothing requiring the UAS 
>> side of a B2BUA to copy the received set of Record-Routes to 
>> the UAC side of itself.  Some do, some don't.
> 

It's not as easy as that, I'm afraid.

Many of the B2BUAs out there are "hybrid", i.e. they also contain pure proxy behavior. For example, they may insert themselves in a Record-Route, rather than modifying the Contact.

And, eventhough what Hadriel says is true, SBCs that do topology hiding will have to become more "intelligent", in order not to break services that rely e.g. on information in the Record-Route headers.

Also, there are services that rely on the fact that the Contact always point to the UE.

> And for some B2BUAs it doesn't matter. For instance, with a 
> conference focus, each connection to the focus in 
> independent. Presumably nobody would expect to have this 
> stuff propagate across a focus to the other participants.
> 
> The place it matters is if there are B2BUAs on the signaling 
> path that want to be viewed as roughly equivalent to proxies. 
> From a normative perspective they need to behave as UAs, not proxies.
> 

I've spent the whole week at a 3GPP meeting (where we DO know what an SBC is, btw :), but I'll get back on the use-case/requirement issue asap.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Oct 2011 11:51:07 -0400

On 10/16/11 9:41 AM, Christer Holmberg wrote:
> Many of the B2BUAs out there are "hybrid",
> i.e. they also contain pure proxy behavior.
> For example, they may insert themselves in a Record-Route,
> rather than modifying the Contact.

Well, if proxy-feature is applicable to boxes that are "hybrid" in that 
sense, then either their behavior is only being specified when they are 
acting as a proxy, or else we will need some way to defining their 
relation to this new functionality when they are *not* acting as proxies.

IOW, maybe this spec defines the behavior for a pure proxy, and the new 
work Hadriel is suggesting would be used to specify how a B2BUA would 
behave.

> And, eventhough what Hadriel says is true, SBCs that do topology hiding will have to become more "intelligent", in order not to break services that rely e.g. on information in the Record-Route head…

topology hiding isn't limited to B2BUAs. Proxies can do it too, to a 
limited extent.

But if proxy-feature is to work in the face of topology-hiding, then 
presumably that needs to be kept in mind when working out the mechanism.

> Also, there are services that rely on the fact that the Contact always point to the UE.

Sure. (That's why we have gruu.) But we seem to be getting far afield. 
I'm not certain what relevance that has to this discussion.

> I've spent the whole week at a 3GPP meeting (where we DO know what an SBC is, btw :), but I'll get back on the use-case/requirement issue asap.

Fine. We'll look forward to your clarification after you have a chance 
to get caught up.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Oct 2011 16:56:31 +0000

On Oct 17, 2011, at 11:51 AM, Paul Kyzivat wrote:
> 
> Well, if proxy-feature is applicable to boxes that are "hybrid" in that sense, then either their behavior is only being specified when they are acting as a proxy, or else we will need some way to defining their relation to this new functionality when they are *not* acting as proxies.

Technically, the "features" being indicated are when the Proxy stops behaving as a Proxy and starts behaving as a B2BUA.  They are B2BUA features being indicated by a device while it is performing a Proxy role, to indicate it can behave in a B2BUA role for feature X some time later.

> IOW, maybe this spec defines the behavior for a pure proxy, and the new work Hadriel is suggesting would be used to specify how a B2BUA would behave.

Well... the first deliverable I had in the STRAW charter was this:
1) A document defining the requirements for B2BUAs to identify specific features/capabilities support.

And what I meant by that was in fact based on draft-holmberg-sipcore-proxy-feature-02.
I'm not actually sure why proxy-features is in SIPCORE, but I guess it doesn't matter so I'll remove the deliverable from STRAW.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Oct 2011 13:41:05 -0400

> Technically, the "features" being indicated are when the Proxy stops behaving as a Proxy and starts behaving as a B2BUA.  They are B2BUA features being indicated by a device while it is performing…

Interesting. I guess the use cases Christer has presented do have that 
property. I don't know if we should assume that all do. It is an 
interesting sort of distinction.

> And what I meant by that was in fact based on draft-holmberg-sipcore-proxy-feature-02.

I didn't realize you meant that linkage.

> I'm not actually sure why proxy-features is in SIPCORE, but I guess it doesn't matter so I'll remove the deliverable from STRAW.

IMO its in sipcore because as initially presented (with the mechanism) 
it was a core change.

If it turns out that it would be better addressed in a different WG, *I* 
have no problem handing off responsibility. For instance, if the work 
needs to do some significant work to define what a proxy-feature is, and 
if that is related to a b2bua-feature.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 18 Oct 2011 09:16:13 +0200

Hi,

In draft-holmberg it was quite obvious. It's about an entity, acting as a proxy (ie does not insert Contact), indicating support of features (in Record-Route etc).

So, the question is how to get that into proper requirements text. I hope we are not going to spend too much time on that, because I think it's rather obvious what people want.

>>> Well, if proxy-feature is applicable to boxes that are 
>>> "hybrid" in that sense, then either their behavior is only 
>>> being specified when they are acting as a proxy, or else we 
>>> will need some way to defining their relation to this new 
>>> functionality when they are *not* acting as proxies.
>>
>> Technically, the "features" being indicated are when the 
>> Proxy stops behaving as a Proxy and starts behaving as a 
>> B2BUA.  They are B2BUA features being indicated by a device 
>> while it is performing a Proxy role, to indicate it can 
>> behave in a B2BUA role for feature X some time later.
> 
> Interesting. I guess the use cases Christer has presented do 
> have that property. I don't know if we should assume that all 
> do. It is an interesting sort of distinction.

I do agree that the current use-cases give such indication. It's about entities not being pure proxies, but acting as proxies when it comes to inserting themselves in the signaling path.

I think it is quite clear in draft-holmberg. But, since we are not allowed to talk about protocol mechanisms in the requirements draft, the question is how to write it down in a generic way :)

>>> IOW, maybe this spec defines the behavior for a pure 
>>> proxy, and the new work Hadriel is suggesting would be used 
>>> to specify how a B2BUA would behave.
>>
>> 1) A document defining the requirements for B2BUAs to 
>> identify specific features/capabilities support.
>>
>> I'm not actually sure why proxy-features is in SIPCORE, but 
>> I guess it doesn't matter so I'll remove the deliverable from STRAW.
> 
> IMO its in sipcore because as initially presented (with the 
> mechanism) it was a core change.
> 
> If it turns out that it would be better addressed in a 
> different WG, *I* have no problem handing off responsibility. 
> For instance, if the work needs to do some significant work 
> to define what a proxy-feature is, and if that is related to 
> a b2bua-feature.

Maybe we need to add some wording (separate, or as part of some of the requirements), which clarifies that we are not talking about pure proxies, but about entities that act as proxies (instead of UAs) when they indicate support of features.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 18 Oct 2011 09:20:02 +0200

A small copy paste error. The first "In draft-holmberg it was obvious..." should be removed :)

> "hybrid" in 
> >>> that sense, then either their behavior is only being 
> specified when 
> >>> they are acting as a proxy, or else we will need some way to 
> >>> defining their relation to this new functionality when they are 
> >>> *not* acting as proxies.
> >>
> Proxy stops 
> >> behaving as a Proxy and starts behaving as a B2BUA.  They 
> are B2BUA 
> >> features being indicated by a device while it is 
> performing a Proxy 
> >> role, to indicate it can behave in a B2BUA role for feature X some 
> >> time later.
> > 
> I do agree that the current use-cases give such indication. 
> It's about entities not being pure proxies, but acting as 
> proxies when it comes to inserting themselves in the signaling path.
> 
> I think it is quite clear in draft-holmberg. But, since we 
> are not allowed to talk about protocol mechanisms in the 
> requirements draft, the question is how to write it down in a 
> generic way :)
> 
> proxy, and the 
> >>> new work Hadriel is suggesting would be used to specify 
> how a B2BUA 
> >>> would behave.
> >>
> >> I'm not actually sure why proxy-features is in SIPCORE, 
> but I guess 
> >> it doesn't matter so I'll remove the deliverable from STRAW.
> > 
> different WG, 
> > *I* have no problem handing off responsibility.
> to define 
> > what a proxy-feature is, and if that is related to a b2bua-feature.
> 
> Maybe we need to add some wording (separate, or as part of 
> some of the requirements), which clarifies that we are not 
> talking about pure proxies, but about entities that act as 
> proxies (instead of UAs) when they indicate support of features.
> 
> Regards,
> 
> Christer
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 18 Oct 2011 14:07:06 +0000

> And, eventhough what Hadriel says is true, SBCs that do topology hiding will have to become more "intelligent", in order not to break services that rely e.g. on information in the Record-Route head…

That's not realistic.  The issue here isn't whether or not SBCs can pass through Record-Route headers, or even be implemented as Proxy-B2BUAs.  Of course they can.  In fact, just speaking for my own company's SBCs, I don't even need to change any code or upgrade anything to pass through Record-Routes - you could configure it to do that right now.

The problem is no one in their right mind would do so.  SBC's don't remove Record-Route because they're lazy vendors - on the contrary it would make our lives simpler.  SBCs do it because (1) their customers have security groups who demand it, and (2) it makes things work better.

> Also, there are services that rely on the fact that the Contact always point to the UE.

If by that you mean that there are service that rely on knowing the UE's real IP Address:port of the Contact, that's not true.  I know of only two vendors who actually need to know the UE's real IP Address:port, and dozens of vendors who do not.

If instead you mean that they need to know a unique Contact URI per UE, such that they can use it in an out-of-dialog to reach the same UE for example, that's true but not germane to the issue at hand. (SBC's solve that problem without leaking Record-Routes to UE's - the two issues are not related)

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Oct 2011 12:26:26 +0200

Hi, 

>> And, eventhough what Hadriel says is true, SBCs that do 
>> topology hiding will have to become more "intelligent", in 
>> order not to break services that rely e.g. on information in 
>> the Record-Route headers.
> 
> That's not realistic.  The issue here isn't whether or not 
> SBCs can pass through Record-Route headers, or even be 
> implemented as Proxy-B2BUAs.  Of course they can.  In fact, 
> just speaking for my own company's SBCs, I don't even need to 
> change any code or upgrade anything to pass through 
> Record-Routes - you could configure it to do that right now.
> 
> The problem is no one in their right mind would do so.  SBC's 
> don't remove Record-Route because they're lazy vendors - on 
> the contrary it would make our lives simpler.  SBCs do it 
> because (1) their customers have security groups who demand 
> it, and (2) it makes things work better.

Sure.

But, assuming that the security requirement is to not provide address information, the SBC would have to change that part of the Record-Route, but still pass the capability information - instead of simply removing the whole Record-Route, including information that doesn't need to (or, even shouldn't, because it would break services) be removed.

Of course the SBC (or the one controlling it) can choose to simply remove the whole Record-Route, even if it would not be needed, but I don't think we should have to take that into consideration when working on a protocol mechanism for proxy-feature.

> If by that you mean that there are service that rely on 
> knowing the UE's real IP Address:port of the Contact, that's 
> not true.  I know of only two vendors who actually need to 
> know the UE's real IP Address:port, and dozens of vendors who do not.
> 
> If instead you mean that they need to know a unique Contact 
> URI per UE, such that they can use it in an out-of-dialog to 
> reach the same UE for example, that's true but not germane to 
> the issue at hand. (SBC's solve that problem without leaking 
> Record-Routes to UE's - the two issues are not related)

What I mean is that feature tags in the Contact (no matter whether it contains the real IP address:port of the UE, or some value created by an SBC) describe capabilities of the UE. So, an SBC can not modify the Contact in order to provide information about *its* capabilities. Instead it would provide that information in its Record-Route (assuming it would use the draft-holmberg mechanism).

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 19 Oct 2011 15:13:39 +0000

> But, assuming that the security requirement is to not provide address information, the SBC would have to change that part of the Record-Route, but still pass the capability information - instead of…

I think we might be viewing this new mechanism in different ways.
If this is only about enabling a couple specific features only within a single 3GPP IMS core, or perhaps even with UEs and only their local 3GPP IMS domain, then sure the single IMS operator can try passing through their IMS core's Record-Routes (encrypted or not, whichever) and seeing if there are any issues, fixing everything, etc.

If, on the other hand, this is a generic mechanism that should work across domains - including from an Enterprise to their provider through a transit provider to another provider to another Enterprise, etc. - then what you're talking about isn't feasible.  It's not just about hiding/encrypting the Record-Route URI addresses, it's about making SIP actually work.  The problem with UDP transport is message size, and especially getting SIP responses back.  And one of the side-effects of removing Record-Routes is you decrease the response size and things actually work better. (Some might say it's just delaying the inevitable, but that's another topic… :)

So no, I don't see this as just a security vs. services decision.  I see it as a service vs. service decision as well.
That's not good.

Regardless, there is no use-case that seems to actually need to know *which* particular SIP host supports feature X.  There's only the need to know that *some* host in the dialog can do X.  One could, for example, just put X into the Supported header, or a header like it.

Think about it from a deployment perspective.  Lots of B2BUAs "remove" Record-Routes, not just SBCs.  Do you think it's likely that all B2BUAs across operators be changed to stop removing them so that this new mechanism can work?  Or do you think it's more likely that the B2BUAs be changed to allow just a new header-X or Supported:X through? 

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Oct 2011 12:17:24 -0400

Thanks Christer. This is starting to get at the heart of things.

Now, suppose that an SBC wants to hide some R-Rs that contain 
proxy-features, and it is also going to replace the Contact with a 
unique of of its own construction.

It could conceivably transfer feature tags from the removed R-Rs to its 
own R-R. That could mean combining feature tags from two or more R-Rs 
into a single R-R. Does that work for you? What if two different R-Rs 
had the *same* feature tag, but each with a different value?

Or, would it be ok to transfer the feature tags from the removed R-Rs to 
the new Contact address?

(The above is about the mechanism you had proposed, not the 
requirements. But maybe we need to talk at that level to understand the 
issues.)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Oct 2011 19:19:30 +0200

Hi,

>> But, assuming that the security requirement is to not provide address information, the SBC would have to change that part of the Record-Route, but still pass 
>> the capability information - instead of simply removing the whole Record-Route, including information that doesn't need to (or, even shouldn't, because it 
>> would break services) be removed.
>
> If this is only about enabling a couple specific features only within a single 3GPP IMS core, or perhaps even with UEs and only their local 3GPP IMS domain, 
> then sure the single IMS operator can try passing through their IMS core's Record-Routes (encrypted or not, whichever) and seeing if there are any issues, fixing everything, etc.
>
> If, on the other hand, this is a generic mechanism that should work across domains -

It is.

> including from an Enterprise to their provider through a transit provider to another provider to another Enterprise, etc. - then what you're talking about isn't feasible. 
> It's not just about hiding/encrypting the Record-Route URI addresses, it's about making SIP actually work.  The problem with UDP transport is message size, and 
> especially getting SIP responses back.  And one of the side-effects of removing Record-Routes is you decrease the response size and things actually work better.
> (Some might say it's just delaying the inevitable, but that's another topic… :)

I think SIP messages are becomming too big to leave the UAC over UDP to start with - before any Record-Route has been added :)

>Regardless, there is no use-case that seems to actually need to know *which* particular SIP host supports feature X.  There's only the need to know that *some* host in the dialog can do X.  

Please see my other reply to Paul.

>One could, for example, just put X into the Supported header, or a header like it.

We would need something like Proxy-Supported.

>Think about it from a deployment perspective.  Lots of B2BUAs "remove" Record-Routes, not just SBCs.  Do you think it's likely that all B2BUAs across operators be changed to stop
>removing them so that this new mechanism can work?  Or do you think it's more likely that the B2BUAs be changed to allow just a new header-X or Supported:X through?

To use the words of a person that we both know, representing a big operator: "SBCs will remove and change whatever we tell them to." :)

Seriously, we can always consider a new header field. But, for now I would like to get the requirements settled, so we can start working on the mechanism, and discuss such new header field.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Oct 2011 19:21:18 +0200

Hi,

>into a single R-R. Does that work for you?

It would work in cases where it doesn't matter which proxy provides a feature, or how support of features are spread out between different proxies. For the currently documented (in the drat) use-cases it might work.

Havin said that, there is a new 3GPP use-case, which was agreed last week (it will be described in the next version of the draft), where it is not enough to indicate that features X and Y are supported by SOME entities in the network - it must be possible to indicate that features X and Y are supported by the SAME entity. It doesn't necessarily mean that it must be possible to indicate WHICH entity supports features X and Y, though, just to indicate that X and Y are supported by the same entity. So, having a single R-R header where you just collect and list feature tags taken from multiple R-R headers would not work.

Also, a 3GPP application server can indicate support of services. And, eventhough nothing is currently specified, I think that there very likely could be use-cases where the S-CSCF needs to know WHICH application servers support specific services, and in which order, e.g. to making routing decissions etc.

>Or, would it be ok to transfer the feature tags from the removed R-Rs to the new Contact address?

Not in cases where the Contact is assumed to contain capabilities supported by the UA.

Also remember that, based on previous discussions about draft-holmberg, a feature tag specification would need to specify what the meaning of a feature tag is when used in different header fields, and that meaning could very well be different for Contact and Record-Route - or the feature tag might not even be specified to be used with Contact.

Regards,

Christer

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 19 Oct 2011 14:08:54 -0400

> Having said that, there is a new 3GPP use-case, which was agreed last
> week (it will be described in the next version of the draft), where it
> is not enough to indicate that features X and Y are supported by SOME
> entities in the network - it must be possible to indicate that
> features X and Y are supported by the SAME entity. It doesn't
> necessarily mean that it must be possible to indicate WHICH entity
> supports features X and Y, though, just to indicate that X and Y are
> supported by the same entity. So, having a single R-R header where you
> just collect and list feature tags taken from multiple R-R headers
> would not work.

But you could define a separate feature designation for the
combination.  So a proxy could insert the feature designation
"pirates", or the designation "ninjas", but if it supported both, it
would insert 3 designations, "pirates", "ninjas", and
"pirates-and-ninjas-together".

> Also, a 3GPP application server can indicate support of services. And,
> eventhough nothing is currently specified, I think that there very
> likely could be use-cases where the S-CSCF needs to know WHICH
> application servers support specific services, and in which order,
> e.g. to making routing decissions etc.

Yes, that is what we want to see an example of.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Oct 2011 14:53:49 -0400

The more we ask the more we do tease out unstated requirements. :-)

Its important to identify these in order to justify your preferred 
mechanism over alternatives.

Hadriel has raised the issue of middleboxes that attempt to reduce the 
size of messages to conform to UDP size limits, and the possibility that 
this would break your preferred mechanism. That is not an issue we 
normally address - with the expectation that TCP is used to solve that 
problem.

Maybe we will at some point not only start writing specs for how B2BUAs 
can avoid breaking things, but also how to design new functionality so 
that it is not broken by B2BUAs. But we aren't really set up to do that 
now. So if it is to be addressed, it will probably have to be done 
informally. I won't object to *some* discussion of the issue, but I 
don't see how we could end up with any normative language about it.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 19 Oct 2011 21:02:33 +0000

> We would need something like Proxy-Supported.

They're NOT proxies, but ya the name doesn't matter much.  
How about "Feature-Caps"?  Too obvious? :)

> To use the words of a person that we both know, representing a big operator: "SBCs will remove and change whatever we tell them to." :)

Of course, and then we'll listen to their Ops folks when they call support with problem tickets.  I'd rather avoid that last part.  I see too much Wireshark as is.  Mucking with Record-Route is like playing with fire.

Its kinda like your "Target" URI header idea a few years ago.  It may not be as all-encompassing as History-Info or as elegant as JDR's loose-route, but it would have been easier to implement, safer, and faster.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 19 Oct 2011 21:02:51 +0000

> Havin said that, there is a new 3GPP use-case, which was agreed last week (it will be described in the next version of the draft), where it is not enough to indicate that features X and Y are suppo…

That's easy…
Feature-Caps: foo, bar, foo+bar

> Also, a 3GPP application server can indicate support of services. And, eventhough nothing is currently specified, I think that there very likely could be use-cases where the S-CSCF needs to know WH…

OK, then why would we want to indicate that in a header used for dialog route-sets?

Record-Route has a very specific purpose, to be used for the in-dialog route-set.  And despite all examples in RFCs to the contrary, its URI is frequently an IP:host rather than a hostname.  That's probably because devices want in-dialog requests coming in on the same instance/blade/interface that created the dialog, for a bunch of reasons.  But a feature capability, especially one that would be useful for routing to for all-time, doesn't necessarily have that property.  I.e., it's just as likely you'd want to indicate your whole App-Server system/cluster can do that feature, rather than the particular interface you're using for in-dialog request routing.

As an aside, one wonders how we got along for so many years with just Supported/Required/Proxy-Require option tags which did not need to identify which particular URI supported the option.  ;)

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Oct 2011 14:07:26 +0200

Hi,

> How about "Feature-Caps"?  Too obvious? :)

I would be ok with that :)

>> Havin said that, there is a new 3GPP use-case, which was 
>> agreed last week (it will be described in the next version of 
>> the draft), where it is not enough to indicate that features 
>> X and Y are supported by SOME entities in the network - it 
>> must be possible to indicate that features X and Y are 
>> supported by the SAME entity. It doesn't necessarily mean 
>> that it must be possible to indicate WHICH entity supports 
>> features X and Y, though, just to indicate that X and Y are 
>> supported by the same entity. So, having a single R-R header 
>> where you just collect and list feature tags taken from 
>> multiple R-R headers would not work.
> 
> 
> That's easy...

Correct. The key is being able to use '+', in order to show that features are supported by the same entity.

>> Also, a 3GPP application server can indicate support of 
>> services. And, eventhough nothing is currently specified, I 
>> think that there very likely could be use-cases where the 
>> S-CSCF needs to know WHICH application servers support 
>> specific services, and in which order, e.g. to making routing 
>> decissions etc.
> 
> Record-Route has a very specific purpose, to be used for the 
> in-dialog route-set.  And despite all examples in RFCs to the 
> contrary, its URI is frequently an IP:host rather than a 
> hostname.  That's probably because devices want in-dialog 
> requests coming in on the same instance/blade/interface that 
> created the dialog, for a bunch of reasons.  But a feature 
> capability, especially one that would be useful for routing 
> to for all-time, doesn't necessarily have that property.  
>
> I.e., it's just as likely you'd want to indicate your whole 
> App-Server system/cluster can do that feature, rather than 
> the particular interface you're using for in-dialog request routing.

In the current use-cases, when the feature support is indicated in INVITE/Record-Route, the support only applies to the specific session established. Ie it is NOT a generic capability support indication.

But, as we have discussed before, the feature tag definition needs to define the scope when support of a feature is indicated in INVITE, REGSTER etc.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Oct 2011 14:08:03 +0200

Hi, 

> Its important to identify these in order to justify your 
> preferred mechanism over alternatives.

I am not trying to justify the usage of Record-Route (if that's what you mean by 'preferred mechanism'). 

I am fine e.g. using a new header field (if that's what you mean by 'alternatives'), if people prefer that :)

Regards,

Christer

> >> It could conceivably transfer feature tags from the 
> removed R-Rs to 
> >> its own R-R. That could mean combining feature tags from 
> two or more 
> >> R-Rs into a single R-R. Does that work for you?
> >
> > It would work in cases where it doesn't matter which proxy 
> provides a feature, or how support of features are spread out 
> between different proxies. For the currently documented (in 
> the drat) use-cases it might work.
> >
> > Also remember that, based on previous discussions about 
> draft-holmberg, a feature tag specification would need to 
> specify what the meaning of a feature tag is when used in 
> different header fields, and that meaning could very well be 
> different for Contact and Record-Route - or the feature tag 
> might not even be specified to be used with Contact.
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> >
> >>>> And, eventhough what Hadriel says is true, SBCs that do topology 
> >>>> hiding will have to become more "intelligent", in order not to 
> >>>> break services that rely e.g. on information in the Record-Route 
> >>>> headers.
> >>>
> >>> That's not realistic.  The issue here isn't whether or 
> not SBCs can 
> >>> pass through Record-Route headers, or even be implemented as 
> >>> Proxy-B2BUAs.  Of course they can.  In fact, just speaking for my 
> >>> own company's SBCs, I don't even need to change any code 
> or upgrade 
> >>> anything to pass through Record-Routes - you could 
> configure it to 
> >>> do that right now.
> >>>
> >>> The problem is no one in their right mind would do so.  
> SBC's don't 
> >>> remove Record-Route because they're lazy vendors - on the 
> contrary 
> >>> it would make our lives simpler.  SBCs do it because (1) their 
> >>> customers have security groups who demand it, and (2) it makes 
> >>> things work better.
> >>
> >> Sure.
> >>
> >> But, assuming that the security requirement is to not 
> provide address information, the SBC would have to change 
> that part of the Record-Route, but still pass the capability 
> information - instead of simply removing the whole 
> Record-Route, including information that doesn't need to (or, 
> even shouldn't, because it would break services) be removed.
> >>
> >> Of course the SBC (or the one controlling it) can choose 
> to simply remove the whole Record-Route, even if it would not 
> be needed, but I don't think we should have to take that into 
> consideration when working on a protocol mechanism for proxy-feature.
> >>
> knowing the 
> >>> UE's real IP Address:port of the Contact, that's not 
> true.  I know 
> >>> of only two vendors who actually need to know the UE's real IP 
> >>> Address:port, and dozens of vendors who do not.
> >>>
> >>> If instead you mean that they need to know a unique 
> Contact URI per 
> >>> UE, such that they can use it in an out-of-dialog to 
> reach the same 
> >>> UE for example, that's true but not germane to the issue at hand. 
> >>> (SBC's solve that problem without leaking Record-Routes to UE's - 
> >>> the two issues are not related)
> >>
> >> What I mean is that feature tags in the Contact (no matter 
> whether it contains the real IP address:port of the UE, or 
> some value created by an SBC) describe capabilities of the 
> UE. So, an SBC can not modify the Contact in order to provide 
> information about *its* capabilities. Instead it would 
> provide that information in its Record-Route (assuming it 
> would use the draft-holmberg mechanism).
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >>
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Oct 2011 10:55:09 -0400

> I am fine e.g. using a new header field (if that's what you mean by 'alternatives'), if people prefer that :)

We are making progress, because we can now debate the pros/cons of 
different mechanisms.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Oct 2011 11:06:44 -0400

> Correct. The key is being able to use '+', in order to show that features are supported by the same entity.

I *think* that hadriel had meant that if you wanted to be able to report 
that a single device had both foo and bar, you would define a new 
feature that was the sum of the other two, and then perhaps give it the 
name "foo+bar".

But, if we are defining a new header, I suppose it would indeed be 
possible to define "+" to be an operator indicating that.

> But, as we have discussed before, the feature tag definition needs to define the scope when support of a feature is indicated in INVITE, REGSTER etc.

Do you really mean that feature "foo", when defined in REGISTER could 
have one scope (say, for all usage of the registered contact for the 
duration of the registration), while feature "bar" when defined in 
REGISTER could have some different scope?

That would make it difficult to develop any generalized support for the 
mechanism.

Or did you just mean that the mechanism would specify a particular scope 
for REGISTER, another for INVITE, etc. And then the registration would 
indicate applicability of the specific feature for use in REGISTER, 
INVITE, etc.?

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 20 Oct 2011 17:24:25 +0000

On Oct 20, 2011, at 11:06 AM, Paul Kyzivat wrote:

> I *think* that hadriel had meant that if you wanted to be able to report that a single device had both foo and bar, you would define a new feature that was the sum of the other two, and then perhaps give it the name "foo+bar".

Nope, I actually meant the "foo" and "bar" would be feature tokens, and a "+" between feature tokens would mean you do both features. 

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Oct 2011 19:42:15 +0200

Hi, 

>>>> Havin said that, there is a new 3GPP use-case, which was agreed last 
>>>> week (it will be described in the next version of the draft), where 
>>>> it is not enough to indicate that features X and Y are supported by 
>>>> SOME entities in the network - it must be possible to indicate that 
>>>> supported by the same entity. So, having a single R-R header where 
>>>> you just collect and list feature tags taken from multiple R-R 
>>>> headers would not work.
>>>
>>>
>>> That's easy...
>'
>I *think* that hadriel had meant that if you wanted to be able to report that a single device had both foo and 
>bar, you would define a new feature that was the sum of the other two, and then perhaps give it the name "foo+bar".

I think that would be strange, and I am not sure whether it would work. Assuming we are using feature tags, and have an IANA registry, we 
would have to register every possible feature tag combination, as each combination technically would be a unique feature tag :)

>But, if we are defining a new header, I suppose it would indeed be possible to define "+" to be an 
>operator indicating that.

I would actually suggest that we use the same syntax as we do e.g. for Accept-Contact, where feature tag 
values would be separated by ';' instead of '+'.

So, we would get something like: Feature-Caps: foo, bar, foo;bar

>>>> Also, a 3GPP application server can indicate support of services. 
>>>> And, eventhough nothing is currently specified, I think that there 
>>>> very likely could be use-cases where the S-CSCF needs to know WHICH 
>>> contrary, its URI is frequently an IP:host rather than a hostname.  
>>> That's probably because devices want in-dialog requests coming in on 
>>> the same instance/blade/interface that created the dialog, for a 
>>> bunch of reasons.  But a feature capability, especially one that 
>>> would be useful for routing to for all-time, doesn't necessarily have 
>>> that property.
>>>
>>> App-Server system/cluster can do that feature, rather than the 
>>> particular interface you're using for in-dialog request routing.
>>
>> In the current use-cases, when the feature support is indicated in INVITE/Record-Route, the 
>> support only applies to the specific session established. Ie it is NOT a generic capability 
>> support indication.
>>
>> But, as we have discussed before, the feature tag definition needs to define the scope when 
>> support of a feature is indicated in INVITE, REGSTER etc.
>
> Do you really mean that feature "foo", when defined in REGISTER could have one scope (say, for all 
> usage of the registered contact for the duration of the registration), while feature "bar" when defined 
> in REGISTER could have some different scope?
>
> That would make it difficult to develop any generalized support for the mechanism.

My *personal* preference would be to NOT do that, but instead specify that the scope of a feature tag in REGISTER is always the specific registration.

>Or did you just mean that the mechanism would specify a particular scope for REGISTER, another for INVITE, etc. And 
>then the registration would indicate applicability of the specific feature for use in REGISTER, INVITE, etc.?

That would be my preference, yes.

So, when indicated in INVITE, the feature is only valid for that dialog.

But, the actual USAGE of the feature must of course be described in the feature tag definition, and eventhough the feature is only valid for a specific dialog, there is at least one use-case (see below) where the information is used when establishing another dialog.

Use-case: In one of the use-cases an AS indicates that, for a given dialog, it provides SCC AS functionality. So, eventhough the SCC functionality only applies for that dialog, the information is then used when another dialog is established, in order to do handover for the dialog for which SCC functionality was indicated. 

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Oct 2011 19:42:46 +0200

Hi, 

>> I *think* that hadriel had meant that if you wanted to be able to report that a single device had both foo and bar, 
>> you would define a new feature that was the sum of the other two, and then perhaps give it the name "foo+bar".
>

I commented this in my other reply: instead of "+", I would suggest using ";" instead, similar to Accept-Contact.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Oct 2011 14:22:35 -0400

Inline

> So, we would get something like: Feature-Caps: foo, bar, foo;bar

OK, this was all my misunderstanding. Since the intent is to dynamically 
compose them, the rest is syntactic nits. Using ";" would seem to be a 
path of least resistance.

But I'm still struggling to understand why its necessary to know two 
features are in the same proxy or different proxies.

And in the above, is ordering significant? (Does the example mean that a 
proxy with foo comes before a proxy with bar, which comes before a proxy 
with foo and bar?

And for Hadriel: in your experience dealing with SBC customers, would 
that convey too much topology info, that you might be asked to suppress?

> My *personal* preference would be to NOT do that, but instead specify that the scope of a feature tag in REGISTER is always the specific registration.

OK, good.

> But, the actual USAGE of the feature must of course be described in the feature tag definition, and even though the feature is only valid for a specific dialog, there is at least one use-case (see below) where the information is used when establishing another dialog.
>

I'm not sure I understand. I *think* you are saying that the SCC 
function provides the capability, within the dialog where it is 
indicated, to establish another dialog if this one fails. That doesn't 
seem like a special case to me. Whether that new dialog also has the SCC 
feature is a separate question.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Oct 2011 21:11:35 +0200

Hi, 

>>>>>> Havin said that, there is a new 3GPP use-case, which was agreed 
>>>>>> last week (it will be described in the next version of the draft), 
>>>>>> where it is not enough to indicate that features X and Y are 
>>>>>> supported by SOME entities in the network - it must be possible to 
>>>>>> indicate that features X and Y are supported by the SAME entity. 
>>>>>> It doesn't necessarily mean that it must be possible to indicate 
>>>>>> WHICH entity supports features X and Y, though, just to indicate 
>>>>>> that X and Y are supported by the same entity. So, having a single 
>>>>>> R-R header where you just collect and list feature tags taken from 
>>> I *think* that hadriel had meant that if you wanted to be able to 
>>> report that a single device had both foo and bar, you would define a new feature that was the sum of the other two, and then perhaps give it the name "foo+bar".
>>
>> I think that would be strange, and I am not sure whether it would 
>> work. Assuming we are using feature tags, and have an IANA registry, 
>> we would have to register every possible feature tag combination, as 
>> each combination technically would be a unique feature tag :)
>>
>> I would actually suggest that we use the same syntax as we do e.g. for 
>> Accept-Contact, where feature tag values would be separated by ';' instead of '+'.
>>
>OK, this was all my misunderstanding. Since the intent is to dynamically compose them, the rest is syntactic nits. Using ";" would seem to be a path of least resistance.
>
>But I'm still struggling to understand why its necessary to know two features are in the same proxy or different proxies.

I am going to submit a use-case where it needs to be seen that the features are supported by the same proxy.

>And in the above, is ordering significant? (Does the example mean that a proxy with foo comes before a proxy with bar, which comes before a proxy with foo and bar?

In the current use-cases I think the ordering is not significant, because there is only one "proxy" inserting feature tag(s) in the first place.

But, in general I see no reason why the mechanism would not allow to indicate that features are provided by the same proxy, and that features are listed in order. The mechanism we are discussing allows it, it doesn't really cause much additional complexity, and we would not have to define a new mechanism in future if there comes use-cases where same-proxy and/or order is needed.

>>>>>> very likely could be use-cases where the S-CSCF needs to know 
>>>>>> WHICH application servers support specific services, and in which 
>>>>>> order, e.g. to making routing decissions etc.
>>>>>>
>>>>> That's probably because devices want in-dialog requests coming in 
>>>>> on the same instance/blade/interface that created the dialog, for a 
>>>>> would be useful for routing to for all-time, doesn't necessarily 
>>>>> have that property.
>>>>>
>>>> In the current use-cases, when the feature support is indicated in 
>>>> INVITE/Record-Route, the support only applies to the specific 
>>>> session established. Ie it is NOT a generic capability support indication.
>>>>
>>>> But, as we have discussed before, the feature tag definition needs 
>>>> to define the scope when support of a feature is indicated in INVITE, REGSTER etc.
>>>
>>> duration of the registration), while feature "bar" when defined in REGISTER could have some different scope?
>>>
>>> Or did you just mean that the mechanism would specify a particular 
>>> scope for REGISTER, another for INVITE, etc. And then the registration would indicate applicability of the specific feature for use in REGISTER, INVITE, etc.?
>>
>> But, the actual USAGE of the feature must of course be described in the feature tag definition, and even though 
>> the feature is only valid for a specific dialog, there is at least one use-case (see below) where the 
>> information is used when establishing another dialog.
>>
>> Use-case: In one of the use-cases an AS indicates that, for a given dialog, it provides SCC AS functionality. So, 
>> eventhough the SCC functionality only applies for that dialog, the information is then used when another dialog 
>> is established, in order to do handover for the dialog for which SCC functionality was indicated.
>
> I'm not sure I understand. I *think* you are saying that the SCC function provides the capability, within the dialog 
> where it is indicated, to establish another dialog if this one fails. That doesn't seem like a special case to me. 
> Whether that new dialog also has the SCC feature is a separate question.

The SCC feature tag indicates that, for the specific dialog, the AS provides functionality in order to do handover.

Using that information, the network knows that handover can be provided to the specific session. And, when handover occurs another dialog is then created. So, the other dialog is created based on the fact that SCC functionality is provided for the original dialog, but it does not mean that SCC is provided for the new dialog. SCC is still only provided to the original dialog, and the new dialog is only used to provide the SCC functionaltiy for the original dialog.

So, eventhough a feature only applies to a given dialog, the feature itself can trigger out-of-dialog actions when executed. So, it should be alligned with the scope we've discussed.

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 20 Oct 2011 22:07:03 +0000

On Oct 20, 2011, at 2:22 PM, Paul Kyzivat wrote:
> And for Hadriel: in your experience dealing with SBC customers, would that convey too much topology info, that you might be asked to suppress?

I don't think so.  It doesn't tell you who the nodes are, how many there are, nor where they're at; and from a policy perspective it's easy to add/remove for both blacklist and whitelist policy models.

It's similar to the Supported header.  But the difficulty with the Supported header for all B2BUAs, which we should probably discuss out for this Feature-Caps header, is that B2BUAs can't just blindly pass/copy Supported option-tags through because they wouldn't know if the extension indicated by some random new option-tag would actually work "through" them.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Oct 2011 20:07:17 -0400

> I don't think so.  It doesn't tell you who the nodes are, how many there are, nor where they're at; and from a policy perspective it's easy to add/remove for both blacklist and whitelist policy mod…

It does put a lower bound on the number of proxies are on the path.
If that was an unusually large number it might communicate something.
But in practice maybe it won't be a large number even if there are a lot 
of proxies.

Its also possible that the *pattern" of entries would communicate 
something about the topology of the deployment - perhaps indicate the 
specific equipment being used with some high probability.

I personally don't care. ISTM that topology hiding is carrying paranoia 
to extremes. But obviously some do care.

> It's similar to the Supported header.  But the difficulty with the Supported header for all B2BUAs, which we should probably discuss out for this Feature-Caps header, is that B2BUAs can't just blin…

And the same sorts of difficulties may apply.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Oct 2011 11:21:58 +0200

Hi, 

>>> And for Hadriel: in your experience dealing with SBC 
>>> customers, would that convey too much topology info, that you 
>>> might be asked to suppress?
>>
>> I don't think so.  It doesn't tell you who the nodes are, 
>> how many there are, nor where they're at; and from a policy 
>> perspective it's easy to add/remove for both blacklist and 
>> whitelist policy models.
> 
> But in practice maybe it won't be a large number even if 
> there are a lot of proxies.
> 
> Its also possible that the *pattern" of entries would 
> communicate something about the topology of the deployment - 
> perhaps indicate the specific equipment being used with some 
> high probability.
> 
> I personally don't care. ISTM that topology hiding is 
> carrying paranoia to extremes. But obviously some do care.
>
>> It's similar to the Supported header.  But the difficulty 
>> with the Supported header for all B2BUAs, which we should 
>> probably discuss out for this Feature-Caps header, is that 
>> B2BUAs can't just blindly pass/copy Supported option-tags 
>> through because they wouldn't know if the extension indicated 
>> by some random new option-tag would actually work "through" them.
> 

An SBC can do whatever - and nothing we do can prevent that.

However, my take of this discussion is that a new header would have a bigger chance of "surviving" than e.g. Record-Route, so can I start updating the draft-holmberg draft based on such assumption?

I think we have a pretty good idea on what we want to do, and I think the requirements are in pretty good shape, so I don't it would bring much value in spending much more time on those.

I also know that people will start to implement at least some of the 3GPP use-cases, so also from that perspective I think we need to show the path we're taking (eventhough nobody of course can expect all the details to be settled from day one).

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 21 Oct 2011 09:47:15 +0000

> It does put a lower bound on the number of proxies are on the path.

Nope, just one node could have inserted every capability.  And duplicates could be removed, if the mechanism has them added.

> Its also possible that the *pattern" of entries would communicate something about the topology of the deployment - perhaps indicate the specific equipment being used with some high probability.

If that became a concern their list ordering could be randomized, but it's never been an issue in Supported header. 

> I personally don't care. ISTM that topology hiding is carrying paranoia to extremes. But obviously some do care.

Yeah, there's topology hiding and then there's crazy topology hiding.  Some people even want Max-Forwards reset to 70 simply to hide the number of hops a request went through.

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Oct 2011 13:32:10 +0200

Hi,

I've submitted a new version (-02) of the proxy-feature reqs draft.

It now contains a new use-case (section 1.2.3), where the SCC AS needs to determine that features are supported by the SAME proxy.

Based on that, I've also added a new requirement (new REQ-12), reflecting that.

Regards,

Christer

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 21. lokakuuta 2011 12:22
> To: Paul Kyzivat; Hadriel Kaplan
> Cc: <[email-masked]>
> Subject: Re: [sipcore] 
> draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH 
> proxy provides the feature
> 
> 
> Hi, 
> 
> >>> And for Hadriel: in your experience dealing with SBC customers, 
> >>> would that convey too much topology info, that you might 
> be asked to 
> >>> suppress?
> >>
> >> I don't think so.  It doesn't tell you who the nodes are, how many 
> >> there are, nor where they're at; and from a policy 
> perspective it's 
> >> easy to add/remove for both blacklist and whitelist policy models.
> > 
> > I personally don't care. ISTM that topology hiding is carrying 
> > paranoia to extremes. But obviously some do care.
> >
> >> It's similar to the Supported header.  But the difficulty with the 
> >> Supported header for all B2BUAs, which we should probably 
> discuss out 
> >> for this Feature-Caps header, is that B2BUAs can't just blindly 
> >> pass/copy Supported option-tags through because they 
> wouldn't know if 
> >> the extension indicated by some random new option-tag 
> would actually 
> >> work "through" them.
> > 
> However, my take of this discussion is that a new header 
> would have a bigger chance of "surviving" than e.g. 
> Record-Route, so can I start updating the draft-holmberg 
> draft based on such assumption?
> 
> I think we have a pretty good idea on what we want to do, and 
> I think the requirements are in pretty good shape, so I don't 
> it would bring much value in spending much more time on those.
> 
> I also know that people will start to implement at least some 
> of the 3GPP use-cases, so also from that perspective I think 
> we need to show the path we're taking (eventhough nobody of 
> course can expect all the details to be settled from day one).
> 
> Regards,
> 
> Christer
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Oct 2011 10:17:11 -0400

> I think we have a pretty good idea on what we want to do, and I think the requirements are in pretty good shape, so I don't it would bring much value in spending much more time on those.

You were going to provide a use case for your requirement to detect when 
two features are supported by the same server. I still find that mystifying.

I also think we still should discuss what namespace these "features" 
come from. You had originally proposed that these be feature tags as 
defined in 3840, but with a twist that the meaning of features be 
different for proxies than for UAs. I guess the reason for proposing 
feature tags was that the mechanism for them already exists, and a 
certain similarity of attaching them to a URI.

That was already a bit of a stretch because the semantics were a bit 
different. With the new mechanism being defined its a bit more of a 
stretch. Also, the syntax of values for feature tags is coupled to the 
callerpref matching algorithm. I have heard no suggestion of a matching 
algorithm for proxy features. (Though your concern for detecting the 
shared appearance of multiple features might imply one.)

So, I'd like to see some discussion of the namespace and value space for 
proxy features.

> I also know that people will start to implement at least some of the 3GPP use-cases, so also from that perspective I think we need to show the path we're taking (eventhough nobody of course can exp…

People can start trial implementations whenever they want. Whether they 
are close to a final implementation won't be known until the end.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Fri, 21 Oct 2011 10:30:12 -0500

On 10/19/11 10:13 AM, Hadriel Kaplan wrote:
> The problem with UDP transport is message size, and especially getting SIP responses back.

At some point, I have to imagine that people will start waking up to the 
absurd "don't do that then" quality of this problem. TCP isn't rocket 
science.

/a

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 21 Oct 2011 13:46:25 -0400

> It now contains a new use-case (section 1.2.3), where the SCC AS needs
> to determine that features are supported by the SAME proxy.

I assume that we are abandoning the concept that the mechanism must
specifically identify which proxy supports each feature, since there
is no new requirement for that.

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 22 Oct 2011 04:42:49 +0000

> OK, this was all my misunderstanding. Since the intent is to dynamically compose them, the rest is syntactic nits. Using ";" would seem to be a path of least resistance.

I know we're like waaay in the syntactic nits here, but I don't think just a ";" would be right either.  It made sense in Accept-Contact because the base header value is "*" and every feature-tag is a header parameter.  That not only made sense per the rules of header fields and their parameters, but also made it easier for people who write code that operates on header pieces using those conventions easier. (ie, lets you write header.getParam("foo") without having to also check if it was in the non-param portion)  

Unless you're saying "foo;bar" is not the same as "bar;foo"?

In other words, instead of this:
Feature-Caps: foo
Feature-Caps: foo;bar
Feature-Caps: bar;foo

We should probably do this:
Feature-Caps: *;foo
Feature-Caps: *;foo;bar
Feature-Caps: *;bar;foo

It looks ugly, but it's more logical methinks.

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 22 Oct 2011 17:50:33 +0200

Hi,

>two features are supported by the same server. I still find that mystifying.

See the new version (-03) of the draft.

>certain similarity of attaching them to a URI.

The feature tag concept is not defined in RFC 3840. RFC 3840 defines a SIP specific feature tag syntax, and how SIP UAs use feature tags to indicate capabilities.

The new mechanism would define how SIP "proxies" use feature tag to indicate capabilties.

But, I agree that the semantics may vary depending on whether a UA or a "proxy" inserts the feature tag, and the feature tag specification would have to handle that.

>shared appearance of multiple features might imply one.)

I am not sure I understand how the syntax is coupled to the callerpref maching mechanism.

And, even if it is, I see no reason why we can't use the same syntax for proxies - even if we would not use them for matching.

>>So, I'd like to see some discussion of the namespace and value space for proxy features.

I personally see no reason why feature tags wouldn't work, and why we would need to define a new way of indicating feature support.

>> I also know that people will start to implement at least some of the 3GPP use-cases, so also from that perspective I think we 
>> need to show the path we're taking (eventhough nobody of course can expect all the details to be settled from day one).
>

SDOs, currently mainly 3GPP, are also defining features using the mechanism.

Anyway, my point is that I personally think we are at a stage where we can start work on the protocol mechanism. Of course there will be lots of details that we have to sort out along the road, but that is part of our normal work in IETF :)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 22 Oct 2011 17:50:39 +0200

Hi,

>is no new requirement for that.

Yes.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 22 Oct 2011 17:52:37 +0200

Hi,

>I know we're like waaay in the syntactic nits here, but I don't think just a ";" would be right either.  It made sense in Accept-Contact because the base header value is "*" and every
>feature-tag is a header parameter.  That not only made sense per the rules of header fields and their parameters, but also made it easier for people who write code that operates 
>on header pieces using those conventions easier. (ie, lets you write header.getParam("foo") without having to also check if it was in the non-param portion)
>

I am not saying that.

>It looks ugly, but it's more logical methinks.

I don't see why that would be needed. UAs don't do that when indicating capabilities in Contact either.

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 22 Oct 2011 16:32:44 +0000

> I don't see why that would be needed. UAs don't do that when indicating capabilities in Contact either.

Because in the Contact they're already _always_ header-parameters.

I.e., this:
   Contact: sip:[email-masked];audio;actor="msg-taker";methods="INVITE";video;q=0.3

The base value of the header field is the URI "sip:[email-masked]", whereas all the capabilities are parameters of the Contact header field, some with param values, some just the param names/tokens.

Doing "Feature-Caps: foo;bar" would mean the header base value would be "foo" whereas "bar" would be a header param, while "Feature-Caps: bar;foo" would mean the base value would be "bar" while the param is "foo".  Thus they wouldn't compare equally from a SIP comparison operation perspective, even though semantically we mean them to be the same.

But here's also a good reason: if we ever did need to extend Feature-Caps to indicate which node supported the feature, we could change the "*" value to be a URI or addr-spec.  So you can think of the "*" as the current header value meaning *one or more nodes* in this SIP message routing path support the Feature-Caps extension mechanism with the parameters of this header, whereas if we do a URI/addr-spec later it means *this specific node* in this SIP message routing path supports the Feature-Caps extension mechanism with the parameters of this header.

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 23 Oct 2011 10:52:13 +0200

Hi Hadriel,

>The base value of the header field is the URI "sip:[email-masked]", whereas all the capabilities are parameters of the Contact header field, 
>some with param values, some just the param names/tokens.
>
>Doing "Feature-Caps: foo;bar" would mean the header base value would be "foo" whereas "bar" would be a header param, while "Feature-Caps: bar;foo" 
>would mean the base value would be "bar" while the param is "foo".  Thus they wouldn't compare equally from a SIP comparison operation perspective, even 
>though semantically we mean them to be the same.

Aaah... now I understand what you mean. I guess you are right.

>But here's also a good reason: if we ever did need to extend Feature-Caps to indicate which node supported the feature, we could change the "*" value 
>to be a URI or addr-spec.  So you can think of the "*" as the current header value meaning *one or more nodes* in this SIP message routing path support
>the Feature-Caps extension mechanism with the parameters of this header, whereas if we do a URI/addr-spec later it means *this specific node* in this SIP 
>message routing path supports the Feature-Caps extension mechanism with the parameters of this header.

Sounds like a good idea.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Oct 2011 15:22:35 +0200

Hi,

Another very good advantage of using a new header field would be that we will could solve the directionality issue, ie whether a supported feature only applies towards downstream entities, upstream entities, or both.

The problem with Record-Route is that the header fields, including all values, are copied from the request into the response by the UAS.

But, with a new header field it would be possible to use it independently in requests and responses, as the header would NOT be copied from the request intot the response.

Ie a "proxy" could indicate support of features in SIP requests and/or SIP responses, depending on in which direction the support indication applies.

Regards,

Christer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 25 Oct 2011 15:52:20 +0200

I assume we are still talking about a URI parameter, i.e. the data relates primarily to the URI in which it is attached, rather than to the header field in which it appears.

I guess if we invented a new header field to carry such URIs, two questions would have to be answered:

1)	What happens if the new URI parameter is still attached to one of the old header fields, e.g. an implementation receives a Record-Route header field with the new URI parameter indicating supported features attached to it.

2)	We have existing URI parameters attached to existing header fields. For example "sigcomp-id". What does a recipient do when it receives these existing URI parameters attached to URIs in the new header field.

Regards

Keith

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Christer Holmberg
> Sent: 25 October 2011 14:23
> To: <[email-masked]>
> Subject: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - New header
> field and direction
> 
> 
> Hi,
> 
> Another very good advantage of using a new header field would be that we
> will could solve the directionality issue, ie whether a supported feature
> only applies towards downstream entities, upstream entities, or both.
> 
> The problem with Record-Route is that the header fields, including all
> values, are copied from the request into the response by the UAS.
> 
> But, with a new header field it would be possible to use it independently
> in requests and responses, as the header would NOT be copied from the
> request intot the response.
> 
> Ie a "proxy" could indicate support of features in SIP requests and/or SIP
> responses, depending on in which direction the support indication applies.
> 
> Regards,
> 
> Christer
> 
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Oct 2011 10:12:42 -0400

In my reply I was assuming that this new header contained no URI - every 
field contains one or more feature caps.

I realize that is inconsistent with what was done in 3841. The history 
of 3841 was that Accept-Contact originally allowed an optional URI, 
which was matched against candidate contacts. Eventually the draft 
evolved to where we abandoned that, but retained the header syntax, but 
only in the wildcard form, not with an explicit URI.

We can argue the pros/cons of following the syntax of Accept-Contact if 
you wish.

But using "+" as a separator won't work if we are using the feature tag 
notation used in 3840. Some of those tags contain a leading "+" character.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Oct 2011 10:17:18 -0400

> I assume we are still talking about a URI parameter, i.e. the data relates primarily to the URI in which it is attached, rather than to the header field in which it appears.

I don't think so. AFAIK we are talking about a header field parameter. 
That is what the feature tags on Contact and Accept-Contact are, and 
those have been used as the analogy.

	Thanks,
	Paul

>> To:<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Oct 2011 21:47:36 +0200

Hi,

>We can argue the pros/cons of following the syntax of Accept-Contact if

I have no problem using the RFC 3840 syntax.

But, as Hadriel indicated in another e-mail, maybe it would be a good idea to allow an URI, instead of "*", IF there will be a future use-case where one would need to indicate WHICH proxy provides the feature(s).

Correct.

Regards,

Christer

l

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Oct 2011 21:16:17 -0400

> But, as Hadriel indicated in another e-mail, maybe it would be a good idea to allow an URI, instead of "*", IF there will be a future use-case where one would need to indicate WHICH proxy provides…

I am very reluctant to define this as allowing a URI without also doing 
the work of defining precisely what the presence of the URI means, how 
it may be used, etc.

I suspect arriving at that definition might be contentious.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 Oct 2011 08:54:38 +0200

Hi, 

>>> In my reply I was assuming that this new header contained no URI - 
>>> every field contains one or more feature caps.
>>>
>>> I realize that is inconsistent with what was done in 3841. The 
>>> history of 3841 was that Accept-Contact originally allowed an 
>>> optional URI, which was matched against candidate contacts. 
>>> Eventually the draft evolved to where we abandoned that, 
>>> but retained the header syntax, but only in the wildcard form, not with 
>>> an explicit URI.
>>>
>>> We can argue the pros/cons of following the syntax of 
>>> Accept-Contact if you wish.
>>
>> But, as Hadriel indicated in another e-mail, maybe it would 
>> be a good idea to allow an URI, instead of "*", IF there will 
>> be a future use-case where one would need to indicate WHICH 
>> proxy provides the feature(s).
> 
> I am very reluctant to define this as allowing a URI without 
> also doing the work of defining precisely what the presence 
> of the URI means, how it may be used, etc.

In most cases I think it would be used simply as some kind of an identifier, e.g. if there is a need to identity in which domain a feature is provided, rather than something used for routing. 

Also, we would need to say that one MUST NOT the URI e.g. to route in-dialog requests, or otherwise modify the dialog route set, eventhough the URI value of course may be identical to a URI in a Record-Route.

I do agree that we need to do a little more thinking about it, but I don't think we should exclude the possibility at this point :)

Regards,

Christer

> >> But using "+" as a separator won't work if we are using 
> the feature 
> >> tag notation used in 3840. Some of those tags contain a 
> leading "+" character.
> >
> > Correct.
> >
> > Regards,
> >
> > Christer
> >
> >
> > l
> >
> >>>> I would actually suggest that we use the same syntax as 
> we do e.g. 
> >>>> for Accept-Contact, where feature tag values would be 
> separated by ';' instead of '+'.
> >>>>
> >>> OK, this was all my misunderstanding. Since the intent is 
> to dynamically compose them, the rest is syntactic nits. 
> Using ";" would seem to be a path of least resistance.
> >>
> >> I know we're like waaay in the syntactic nits here, but I 
> don't think 
> >> just a ";" would be right either.  It made sense in Accept-Contact 
> >> because the base header value is "*" and every feature-tag is a 
> >> header parameter.  That not only made sense per the rules 
> of header 
> >> fields and their parameters, but also made it easier for 
> people who 
> >> write code that operates on header pieces using those conventions 
> >> easier. (ie, lets you write header.getParam("foo") without 
> having to 
> >> also check if it was in the non-param portion)
> >>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Oct 2011 08:50:47 -0400

> Also, we would need to say that one MUST NOT the URI e.g. to route in-dialog requests, or otherwise modify the dialog route set, eventhough the URI value of course may be identical to a URI in a Re…

Yes, that is the issue - what does it mean and how it (may / may not) be 
used.

> I do agree that we need to do a little more thinking about it, but I don't think we should exclude the possibility at this point :)

I'm just saying that including it will at least draw out the discussions 
further.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 Oct 2011 19:27:32 +0200

Hi,

> Yes, that is the issue - what does it mean and how it (may / may not) be used.
>
> I'm just saying that including it will at least draw out the discussions further.

Yes.

However, I did had some discussions about whether "*" is an appropriate value (in the common case where a URI is not needed). 

AFAIK, for Accept-Contact "*" means "any URI", but I don't think that we are saying that "anyone supports the feature".

Instead we are talking more about "no URI", meaning that "someone supports the feature". So, instead of re-defining the meaning of "*" when used in Feature-Caps, maybe e.g. a "-" value would be more appropriate?

Example:

Feature-Caps: -;foo;bar

On a high level, however, I haven't heard any objections of using a new header field (on the contrary, our discusions seem to more and more point in the direction towards a new header field), so my suggestion is that we make a working assumption of using a new header field. 

I will then submit a draft accordingly, and we can start sorting out the details and issues (including those we have already been discussing).

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Oct 2011 14:50:51 -0400

> AFAIK, for Accept-Contact "*" means "any URI", but I don't think that we are saying that "anyone supports the feature".

At one time "*" meant "any URI". But it was changed so that "*" is the 
only value you can use there - there is no URI matching based on that 
value - so it doesn't really mean anything in that context.

There is precedent for the "*" meaning "any URI" from the Contact in 
REGISTER. So it plausible to assume it should mean the same in other 
similar usages.

> Instead we are talking more about "no URI", meaning that "someone supports the feature". So, instead of re-defining the meaning of "*" when used in Feature-Caps, maybe e.g. a "-" value would be mor…

If you are simply looking for a syntactic mechanism, I would suggest 
simply leaving the field empty, as in

   Feature-Caps: ;foo;bar

But that doesn't address what it means if there *is* a URI.
Either the intent is to assign a real meaning now, or to future-proof 
the syntax against a future extension that defines it.

There is some work to do even if the goal is only to future-proof it. 
Syntactically it will need to allow a optional URI, which is easy to 
define. Semantically it will need to specify that nothing conforming to 
"this" spec may put a value there, and that anything interpreting such a 
header that *does* have a value will ignore the URI. Then a future 
extension would be free to define both the conditions for including the 
URI, and the appropriate interpretation of it, but would have to account 
for those following the older spec that would ignore it.

> On a high level, however, I haven't heard any objections of using a new header field (on the contrary, our discusions seem to more and more point in the direction towards a new header field), so my…

I have no objection to that change.
It avoids the complexities that come with overloading 
Record-Route/Route/etc.

> I will then submit a draft accordingly, and we can start sorting out the details and issues (including those we have already been discussing).

ok.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 Oct 2011 21:58:58 +0200

Hi,

>REGISTER. So it plausible to assume it should mean the same in other

I was going to mention the Contact usage also, but it seems like I forgot.

> simply leaving the field empty, as in

Ok. I don't have any strong opinion, as long as there is no confusion of the meaning.

> for those following the older spec that would ignore it.

An easy approach could be the following:

We specify that a URI is informative, and *ONLY* indicates the entity, or the domain, that supports the feature(s). Nothing more, nothing less :)

(I believe there could e.g. be roaming/interconnect/transit scenarios where it would be useful to know in which domain a feature is supported.)

But, any additional information, which only applies to a specific feature tag(s), would have to be defined and provided as a feature tag parameter.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Oct 2011 16:27:07 -0400

> But, any additional information, which only applies to a specific feature tag(s), would have to be defined and provided as a feature tag parameter.

I find the above a bad idea.

First, there is a question of whether this is an arbitrary URI, or 
always a sip URI. For an arbitrary URI it is very obscure. For now I'll 
assume its only a sip/sips URI.

Its very weird to say "here is a sip URI, but its only significance is 
in the domain. It strongly encourages people to do more with it.

And defining its significance on a per-feature-tag basis creates a heap 
of confusion. (For feature foo you can get info by subscribing to an 
event package, for feature bar you can send data to it with MESSAGE, for 
feature baz you can meaningfully send an INVITE.) And its more confusing 
when you associate multiple features with the same URI.

If you want to parameterize features, then I think you are better off to 
do so by defining the values they can take on.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Oct 2011 16:44:54 -0400

> The feature tag concept is not defined in RFC 3840. RFC 3840 defines a SIP specific feature tag syntax, and how SIP UAs use feature tags to indicate capabilities.

Yes, 3840 borrowed the underlying feature tag mechanism and registry.
(IMO it was a poor fit, but its too late to argue over it.)
For practical purposes the registry of sip features is distinct. (They 
all start with "sip." except for some grandfathered ones.)
And as you say, the syntax for representing them is modified.

All of this was built around the need to provide a way of "matching" 
preferences against capabilities.

> The new mechanism would define how SIP "proxies" use feature tag to indicate capabilties.

AFAIK you have no intent to extend 3841 to do matching on 
proxy-features. (Or do you?)

If not, there is no need for a representation that supports the matching 
mechanics of 3841. (Which is already far too arcane.)

> But, I agree that the semantics may vary depending on whether a UA or a "proxy" inserts the feature tag, and the feature tag specification would have to handle that.

If we use the existing feature tag registry for this new use, either the 
namespace will need to be changed (e.g. use something other than "sip." 
as a prefix), or else feature tag specifications that follow 3840 will 
only apply to UAs, and those that follow this new draft will only apply 
to proxies, or will contain separate sub-specifications for UA and proxy 
behavior. So in reality there will be different namespaces for UAs and 
proxies. And in practice there will probably be distinct names as well.

So the only advantage of using the feature tag type and registry is to 
avoid defining a new registry.

> I am not sure I understand how the syntax is coupled to the callerpref maching mechanism.

See above. The syntax of values is defined so that it can be mapped onto 
feature tag predicates, so that those can be used to define matching in 
3841.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 Oct 2011 22:49:12 +0200

Hi,

> in the domain. It strongly encourages people to do more with it.

I didn't mean that it's only significant within the domain. I meant that the URI informs which domain supports the features.

> And defining its significance on a per-feature-tag basis creates a heap of confusion.
>
> (For feature foo you can get info by subscribing to an event package, for feature bar you can send data to it with MESSAGE, for
> feature baz you can meaningfully send an INVITE.) And its more confusing when you associate multiple features with the same URI.

I agree. 

I was more thinking about whether operator policies etc could be based on in which domain features are supported, but that feature tag specifications MUST NOT define any additional feature tag specific meaning (e.g. whether it can be used for sending a MESSAGE requests). As you also suggest below, such information would have to be provided using feature tag parameters.

> If you want to parameterize features, then I think you are better off to do so by defining the values they can take on.

I totally agree. The URI would only provide general information about the entity/domain that indicated support of the features, but it would not provide any additional feature specific information.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 Oct 2011 12:09:35 +0200

Hi,

I've submitted a new version (-03) of draft-holmberg-sipcore-proxy-feature, which suggests a solution based on the proxy feature requirements.

The MAJOR CHANGE, based on the list discussions, is that the mechanism now uses a new header field, Feature-Caps, rather than existing header fields (Record-Route, Path etc).

I did not include the "SIP-URI alternative" at this point.

We will also have to think about the "proxy" terminology, as it has been indicated that entities using the mechanism might not be pure proxies. But, I don't think that should prevent us from moving forward the the mechanism as such.

Thanks to everyone who has provided feedback and input!

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Oct 2011 20:46:40 +0000

Howdy,
I've read this latest draft and I propose we make this a WG item.  I believe there has been strong consensus for this work, from even last year, but also from the following email thread from the SIPCORE Chairs asking for WG consensus:
http://www.ietf.org/mail-archive/web/sipcore/current/msg04104.html

If this needs a new charter milestone, then I propose a new milestone be added for:
"A mechanism to indicate proxy/B2BUA capabilities to both endpoints and other proxies/B2BUAs in the path of a SIP REGISTER transaction or a dialog-forming transaction".

There may be some nits/details to argue over in the draft, but I think we can do that as a WG draft/item.

As often asked for by WG Chairs when considering new milestones: I also volunteer to spend time/effort in contributing to the work item, and helping the authors by providing text if needed.

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 29 Oct 2011 17:19:58 +0200

Hi,

> As often asked for by WG Chairs when considering new milestones: I also volunteer to spend time/effort in contributing to the work item, and helping the authors by providing text if needed.

I have talked to Hadriel, and he will actually become co-author of the document :)

Regards,

Christer

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 29 Oct 2011 10:22:30 -0600

This started as something for a proxy to indicate what type of  things it could support that could show up in a Proxy-Require and allow a given proxy to indicate to downstream things an additional Proxy-Require level requirement. I thought that sounded like a reasonable idea but we needed to nail down the details of what we were actually talking about. 

Since then it has slowly morphed into the type of DWIM vs DWIS mechanism that I thought we agreed we did not to do. Keep in mind any UA can act as an embedded proxy and this looks like the feature scheme that I thought was the roughly the core of the DWIM vs DWIS argument. 

Anyways, for any mechanisms of this sort, I will be strongly apposed unless the registration mechanism for new tags, features, options or whatever you call them is the same as it is for sip option tags. I have spoken at the mic several times in favor of  what Christer was presenting but it always had that property. This does not and I am strongly opposed to it. Given the previous conversation were in the other context, whatever consensus they may or may not have had does not seem to apply here. If the goal is simply to change what is required to register option tags, I'd be happy to have that conversation.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 31 Oct 2011 17:06:45 +0000

> Anyways, for any mechanisms of this sort, I will be strongly apposed unless the registration mechanism for new tags, features, options or whatever you call them is the same as it is for sip option…

Currently the draft mechanism is indicating RFC-3840-type feature-tags.  As such yes new values require RFCs published through IETF Consensus (IESG approval), as opposed to standards track RFCs as required for option-tags.  I believe as a WG-draft we can choose whether tokens put into a new header are actual feature-tags, or some new "capability-tags" with higher RFC approval status required.  And of course we can say what semantics such new capability-tags RFCs must define and be constrained to.  I don't think any of those things prevent us from making it a WG draft do they?  I thought being a WG draft just meant the WG accepted the goal as a milestone, had enough people willing to work on it, and thought the general direction of the draft's solution was right.

With regards to option-tags:
It was my understanding that we keep option-tags under tighter control because they (1) can be used in Require/Proxy-Require and thus break SIP-level interop badly if they're not thought through very carefully, and (2) are sometimes used for extensions to the SIP protocol/machinery itself, such as 100rel.

The level of RFC required for option-tags was not due to DWIM vs. DWIS as far as I know.  IIRC, the DWIM vs. DWIS problem we've talked about before was when a option-tag is used to not only indicate support for an extension, but actual use of it for the current SIP Request it happens to be in.  And that problem happens for RFC 3840 feature-tags as well; for example if someone defines a feature-tag "Foo" that means something more than just "I can do Foo", but instead uses it to be "I will do Foo now" or "I am doing Foo" or "You must do Foo".

Clearly feature-tag values cannot be used in Require/Proxy-Require; and I don't believe feature-tag values extend the SIP protocol, or else we should immediately update the RFC 3840's IANA tree to require standards track RFCs. 

Are you worried that people will create new feature-tag values that they then require be supported in their domain for SIP to work?  Are you worried that people will create new feature-tags which indicate extensions of the SIP protocol itself?

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 31 Oct 2011 13:46:05 -0400

> Currently the draft mechanism is indicating RFC-3840-type feature-tags.  As such yes new values require RFCs published through IETF Consensus (IESG approval), as opposed to standards track RFCs as…

Actually, its possible to define feature tags without any standards 
action. See section 3.1.3 of RFC 2506. (It allows feature tags beginning 
with "u." followed by a URI.)

Its my impression that this is one of the things that 3gpp likes about 
feature tags - they can define new ones without an ietf standards action.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 31 Oct 2011 19:36:00 +0100

Hi,

>> Since then it has slowly morphed into the type of DWIM vs DWIS mechanism that I thought we agreed we did not to do. Keep in mind any UA can
>> act as an embedded proxy and this looks like the feature scheme that I thought was the roughly the core of the DWIM vs DWIS argument.
>>
>> Anyways, for any mechanisms of this sort, I will be strongly apposed unless the registration mechanism for new tags, features, options or whatever
>> you call them is the same as it is for sip option tags. I have spoken at the mic several times in favor of  what Christer was presenting but it always had 
>> that property. This does not and I am strongly opposed to it. Given the previous conversation were in the other context, whatever consensus they
>> may or may not have had does not seem to apply here. If the goal is simply to change what is required to register option tags, I'd be happy to have that conversation.
>
> Currently the draft mechanism is indicating RFC-3840-type feature-tags.  As such yes new values require RFCs published through IETF Consensus (IESG approval), as 
> opposed to standards track RFCs as required for option-tags.  I believe as a WG-draft we can choose whether tokens put into a new header are actual feature-tags,
> or some new "capability-tags" with higher RFC approval status required.  And of course we can say what semantics such new capability-tags RFCs must define and be
> constrained to.  I don't think any of those things prevent us from making it a WG draft do they?  I thought being a WG draft just meant the WG accepted the goal as a
> milestone, had enough people willing to work on it, and thought the general direction of the draft's solution was right.
>

There are no 3GPP defined feature tags beginning with "u", and as far as I know 3GPP has (or, is in the progress of) registered all their feature tags with IANA.

And, as you also indicated, we can specify what information a feature tag specification, and its associated IANA registration, needs to contain.

Also, if you look at the use-cases behind this work, I think feature tags are very appropriate. We are talking about feature indications ("I can do this"). And, we are not talking about extensions to the SIP protocol, in
which case I agree option-tags probably would be more suitable.

Regards,

Christer