Subject: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft

From: "Dawes, Peter, VF-Group" <[email-masked]>
Date: Thu, 1 Mar 2012 17:27:12 +0100

Hi Paul, All,
I support wg adoption of the proxy-feature draft as this kind of solution is needed to allow a network to do the things described in draft-ietf-sipcore-proxy-feature-reqs-03.txt. 

On the question " Since many of us have struggled to  understand the uses of this mechanism, it would be great if those of you who have uses would describe them." do you believe that what is needed is more use cases than those listed in the reqs draft, or a more general idea of the value of a SIP "feature node" indicating its capabilities to other SIP entities, or something else? For me, the use cases in the reqs are sufficient reason to work on the draft.

On the question " One issue that remains fuzzy is distinguishing what is and is not a valid proxy-feature", is the purpose of discussing this validity to define the requirements and procedure for registering such proxy-features with IANA or is it more than that? 

Regards,
Peter 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 01 March 2012 09:09
To: [email-masked]
Cc: [email-masked]
Subject: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft

Hi Paul,
Due to the fact that I got only the *STRONG SUPPORT* feedback from my deployment guys looking on draft-holmberg-sipcore-proxy-feature  and the related use cases. I unfortunately cannot give more details at this point, but I think there will be a general use.
My goal is not use proprietary feature tags.

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: Paul Kyzivat [mailto:[email-masked]]
Gesendet: Dienstag, 28. Februar 2012 15:08
An: Jesske, Roland
Cc: [email-masked]; [email-masked]
Betreff: Re: AW: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft

On 2/28/12 8:06 AM, [email-masked] wrote:
> Not only from 3GPP work also seen form our own use cases I fully support the adoption of the draft as wg document.

Since many of us have struggled to  understand the uses of this mechanism, it would be great if those of you who have uses would describe them.

Are the uses you see ones that would have proprietary feature tags? Or are they of general use that should have a public tag?

        Thanks,
        Paul

> Roland
>
> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im 
> Auftrag von Leis, Peter (NSN - DE/Munich)
> Gesendet: Dienstag, 28. Februar 2012 09:24
> An: ext Paul Kyzivat; SIPCORE
> Betreff: Re: [sipcore] Adoption of
> draft-holmberg-sipcore-proxy-feature as a wgdraft
>
> Hello,
>
> working in 3GPP IMS area, where we need this mechanism, I support adopting the draft as wg document.
>
> Peter
>
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of ext Paul Kyzivat
> Sent: Monday, February 27, 2012 7:12 PM
> To: SIPCORE
> Subject: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as 
> a wgdraft
>
> SIPCORE group:
>
> There has been general agreement on the proxy-feature requirements, so 
> now we have a basis to work on a corresponding mechanism. Robert has 
> agreed that sipcore is the proper place to do this work. The document
> draft-holmberg-sipcore-proxy-feature-04 has been proposed as a mechanism.
>
> I am requesting that discussion begin, on the sipcore list, on the suitability of this draft as a basis for a wg mechanism document that will meet the requirements expressed in draft-ietf-sipcore-proxy-feature-reqs-03.txt.
>
> One issue that remains fuzzy is distinguishing what is and is not a valid proxy-feature. We have a few examples from the use cases, but little clarity beyond that on any guidelines for what would qualify and what would not. However it seems likely that few, if any, of the existing defined feature tags (even those in the sip tree) would be appropriate.
>
> So one thing I will be looking for in the mechanism before it is 
> finalized is a way to resolve this. This might be a set of criteria 
> that
>
> can be applied to any new candidate proxy-feature. Or if that proves impossible to define, then we can fall back on requiring standards action for a feature to be defined. So I encourage discussion of this issue.
>
> (Currently the draft proposes to build on RFC 3840 and its use of the 
> feature-tag definition mechanisms specified in RFC 2506. That 
> registration mechanism has multiple categories of features with 
> differing approval mechanisms for each category. Some require an RFC, 
> some expert review, and some no approval at all. Whether this can be 
> made to work for proxy-features remains to be seen.)
>
>          Thanks,
>          Paul (as co-chair)
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Mar 2012 12:07:57 -0500

> On the question " Since many of us have struggled to  understand the uses of this mechanism, it would be great if those of you who have uses would describe them." do you believe that what is needed…

I think it would be useful to have both more use cases (some that the 
rest of us can relate to), *and* more general explanation of what it 
means for a non-endpoint to have a feature that others need to know about.

I am not saying that this can't proceed without that, but it will be 
more difficult, and without that we might end up with a draft that is 
understood and supported only by those building for IMS.

> On the question " One issue that remains fuzzy is distinguishing what is and is not a valid proxy-feature", is the purpose of discussing this validity to define the requirements and procedure for r…

That is the reason I ask. And of course it is related to the second part 
of your prior comment.

Lacking a clear definition to distinguish valid proxy-features from 
invalid ones, I can't imagine approving any registration mechanism other 
than standards-action. (Standards-action follows the approach of "I 
can't define it but I know it when I see it". Or you could say that it 
"crowd-sources" the decision.)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Mar 2012 10:03:23 +0100

Hi Paul,

>> I support wg adoption of the proxy-feature draft as this kind of solution is needed to allow a network to do the things 
>>described in draft-ietf-sipcore-proxy-feature-reqs-03.txt.
>
>> On the question " Since many of us have struggled to  understand the uses of this mechanism, it would be great if those of you who have uses would 
>> describe them." do you believe that what is needed is more use cases than those listed in the reqs draft, or a more general idea of the value of a SIP
>> "feature node" indicating its capabilities to other SIP entities, or something else? For me, the use cases in the reqs are sufficient reason to work on the draft.
>
> I think it would be useful to have both more use cases (some that the rest of us can relate to), *and* more general explanation of what it means for 
> a non-endpoint to have a feature that others need to know about.
>
> I am not saying that this can't proceed without that, but it will be more difficult, and without that we might end up with a draft that is understood 
> and supported only by those building for IMS.

What it means for a non-endpoint to have a feature needs to be described in the feature specification. I don't think there is a general explanation, other than "I can do capability X".

The req spec gives short explanations of the 3GPP use-cases. I also believe the 3GPP specs are generally available if one wants more information.

However, there is nothing IMS specific with the mechanism as such, and I believe there are a number of general use-cases. But, I hope we don't expect 3GPP to come up with those.

Some examples, that I have been thinking about myself:

Forking:
----------

This is related to something I have spent quite much time on discussing with customers etc: how to ensure that incoming calls reach the correct device?

When a user registers multiple devices associated with a single AoR, it is often difficult to know/ensure that incoming calls reach an appropriate device. In some cases, the problem could be solved if a UA had additional knowledge about its registrar's forking capabilities (support of RFC 3841 can already be indicated using an option-tag), and may impact on whether the user  is going to register multiple devices in the first place, whether the user is going to generate local ringback tones/anouncements (maybe the registrar can indicate capability of doing it).

Automatic call handling (and other network features):
------------------------------------------------------------------

Informing UAs about whether a network entity has the capability to provide automatic call handling (call forwarding etc), or other features (e.g. the announcement capability mentioned in the forking use-case).

Note that the procedures to actually activate/deactivate/control these features is outside the scope of the proxy-feature mechanism itself, and may even require separate standardization (if e.g. new SIP/SDP information elements are needed) within the scope of another charter and/or WG.

STUN/TURN server information:
---------------------------------------

I haven't thought so much about this, but maybe the mechanism could be used to inform users about STUN/TURN capabilities (STUN/TURN server addresses and/or URIs to use for DNS etc).

Outbound and multiple registration flows:
---------------------------------------------------

When a user creates multiple registration flows, with multiple edge proxies, different edge proxies may have different capabilities, and it may be useful for the UA and/or the registrar to know about them when choosing a flow. Such capabilities could be related e.g. to security, NAT traversal etc.

Also, a registrar could indicate the number of flows it has a capability to handle.

I think the use-cases fulfill the requirements that other entities are not mandated to understand the capabilities. But, if they do, they provide small pieces of building blocks that I believe can improve user experience and session establishment optimization.

I'm sure there are also questions related to these use-cases, and I don't claim to have all the answers. But, I do think it shows that there could also be general use-cases :)

Some other potential use-cases:

PBX:
------

Some people have indicated that the mechanism could be useful to indicate support of PBX capabilities. I haven't studied that so much myself, but maybe those people could provide more information.

Telepresence:
------------------

Also, in CLUE we are discussing the exchange of capabilities between different entities, but I think it's too early to say whether proxy-feature could be useful there (it will depend on the amount of information to be exchanged - and which entities will exchange it). But, it COULD become a valid use-case.

>> On the question " One issue that remains fuzzy is distinguishing what is and is not a valid proxy-feature", is the purpose of discussing this validity to define the 
>> requirements and procedure for registering such proxy-features with IANA or is it more than that?
>
> That is the reason I ask. And of course it is related to the second part of your prior comment.
>
> Lacking a clear definition to distinguish valid proxy-features from invalid ones, I can't imagine approving any registration mechanism other than standards-action. 
>(Standards-action follows the approach of "I can't define it but I know it when I see it". Or you could say that it "crowd-sources" the decision.)

There are already a number of requirements regarding the capability indication, e.g. that it must not be assumed that other entities support it etc. I think it's quite difficult to say much more about the specific feature itself. There are different types of feature-tags defined for UAs. Also, in 3GPP, at least one of the feature-tag (using to indicate support of alerting SRVCC) is used both by UAs and proxies.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Mar 2012 11:55:34 -0400

> What it means for a non-endpoint to have a feature needs to be described in the feature specification. I don't think there is a general explanation, other than "I can do capability X".

Clearly it is the responsibility of each feature spec to describe what 
it means for a non-endpoint to have that particular feature.

*Maybe* some added examples will be enough, but I keep hoping for a general

> However, there is nothing IMS specific with the mechanism as such, and I believe there are a number of general use-cases. But, I hope we don't expect 3GPP to come up with those.

Not necessarily. Now that this is a wg draft we can ask for inputs from 
others. I would like to see that result in identification of more 
general capabilities.

> Some examples, that I have been thinking about myself:

These seem like a good starting point for identifying some.

	Thanks,
	Paul

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 15 Mar 2012 16:57:54 +0000

Hi Christer,

Even though the title is proxy-feature, this specification applies information for both proxy and B2BUA. My doubt is whether this feature-tag applies for UA whose Contact header field  URI represents another SIP entity.

Thanks
Partha

>Behalf Of Christer Holmberg
>Sent: Thursday, March 15, 2012 2:33 PM
>To: Paul Kyzivat; Dawes, Peter, VF-Group
>Cc: [email-masked]
>>> I support wg adoption of the proxy-feature draft as this kind of
>>>solution is needed to allow a network to do the things described in
>draft-ietf-sipcore-proxy-feature-reqs-03.txt.
>>
>>> On the question " Since many of us have struggled to  understand the
>>> uses of this mechanism, it would be great if those of you who have
>>> uses would describe them." do you believe that what is needed is more
>use cases than those listed in the reqs draft, or a more general idea of
>the value of a SIP "feature node" indicating its capabilities to other
>SIP entities, or something else? For me, the use cases in the reqs are
>sufficient reason to work on the draft.
>>
>What it means for a non-endpoint to have a feature needs to be described
>in the feature specification. I don't think there is a general
>explanation, other than "I can do capability X".
>
>The req spec gives short explanations of the 3GPP use-cases. I also
>believe the 3GPP specs are generally available if one wants more
>information.
>
>However, there is nothing IMS specific with the mechanism as such, and I
>believe there are a number of general use-cases. But, I hope we don't
>expect 3GPP to come up with those.
>
>This is related to something I have spent quite much time on discussing
>with customers etc: how to ensure that incoming calls reach the correct
>device?
>
>When a user registers multiple devices associated with a single AoR, it
>is often difficult to know/ensure that incoming calls reach an
>appropriate device. In some cases, the problem could be solved if a UA
>had additional knowledge about its registrar's forking capabilities
>(support of RFC 3841 can already be indicated using an option-tag), and
>may impact on whether the user  is going to register multiple devices in
>the first place, whether the user is going to generate local ringback
>tones/anouncements (maybe the registrar can indicate capability of doing
>it).
>
>
>Informing UAs about whether a network entity has the capability to
>provide automatic call handling (call forwarding etc), or other features
>(e.g. the announcement capability mentioned in the forking use-case).
>
>Note that the procedures to actually activate/deactivate/control these
>features is outside the scope of the proxy-feature mechanism itself, and
>may even require separate standardization (if e.g. new SIP/SDP
>information elements are needed) within the scope of another charter
>and/or WG.
>
>
>I haven't thought so much about this, but maybe the mechanism could be
>used to inform users about STUN/TURN capabilities (STUN/TURN server
>addresses and/or URIs to use for DNS etc).
>
>
>
>When a user creates multiple registration flows, with multiple edge
>proxies, different edge proxies may have different capabilities, and it
>may be useful for the UA and/or the registrar to know about them when
>choosing a flow. Such capabilities could be related e.g. to security,
>NAT traversal etc.
>
>I think the use-cases fulfill the requirements that other entities are
>not mandated to understand the capabilities. But, if they do, they
>provide small pieces of building blocks that I believe can improve user
>experience and session establishment optimization.
>
>I'm sure there are also questions related to these use-cases, and I
>don't claim to have all the answers. But, I do think it shows that there
>could also be general use-cases :)
>
>
>
>Some people have indicated that the mechanism could be useful to
>indicate support of PBX capabilities. I haven't studied that so much
>myself, but maybe those people could provide more information.
>
>
>Telepresence:
>------------------
>
>Also, in CLUE we are discussing the exchange of capabilities between
>different entities, but I think it's too early to say whether proxy-
>feature could be useful there (it will depend on the amount of
>information to be exchanged - and which entities will exchange it). But,
>it COULD become a valid use-case.
>
>
>>> On the question " One issue that remains fuzzy is distinguishing what
>>> is and is not a valid proxy-feature", is the purpose of discussing
>this validity to define the requirements and procedure for registering
>such proxy-features with IANA or is it more than that?
>>
>than standards-action.
>>(Standards-action follows the approach of "I can't define it but I know
>>it when I see it". Or you could say that it "crowd-sources" the
>>decision.)
>
>There are already a number of requirements regarding the capability
>indication, e.g. that it must not be assumed that other entities support
>it etc. I think it's quite difficult to say much more about the specific
>feature itself. There are different types of feature-tags defined for
>UAs. Also, in 3GPP, at least one of the feature-tag (using to indicate
>support of alerting SRVCC) is used both by UAs and proxies.
>
>Regards,
>
>Christer
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Mar 2012 20:34:08 +0100

Hi,

> Even though the title is proxy-feature, this specification applies information for both proxy and B2BUA. 

Correct. We have discussed that earlier, and we may have to change to name to avoid confusion.

> My doubt is whether this feature-tag applies for UA whose Contact header field  URI represents another > SIP entity.

Correct, if you by UA refer to an end device (not a B2BUA, or somthing similar). I am not aware of a case where an end device would use a Contact header field that represents another entity.

Regards,

Christer

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Fri, 16 Mar 2012 06:24:46 +0000

Christer,

Thanks for the clarification about proxy terminology change.

UA is not required to be end-point and it shall be SIP-any protocol (PSTN, H.323, RTCWeb) gateway. I asked this query as there should be no difference in UAC behavior between B2BUA and UA. 

Thanks
Partha

>From: Christer Holmberg [mailto:[email-masked]]
>Sent: Friday, March 16, 2012 1:04 AM
>To: Ravindran, Parthasarathi; Paul Kyzivat; Dawes, Peter, VF-Group
>Cc: [email-masked]
>Subject: RE: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature
>as a wgdraft
>
>Hi,
>
>> My doubt is whether this feature-tag applies for UA whose Contact
>header field  URI represents another > SIP entity.
>
>Correct, if you by UA refer to an end device (not a B2BUA, or somthing
>similar). I am not aware of a case where an end device would use a
>Contact header field that represents another entity.
>
>Regards,
>
>Christer
>
>
>>use cases than those listed in the reqs draft, or a more general idea
>>of the value of a SIP "feature node" indicating its capabilities to
>>other SIP entities, or something else? For me, the use cases in the
>>reqs are sufficient reason to work on the draft.
>>>
>>What it means for a non-endpoint to have a feature needs to be
>>described in the feature specification. I don't think there is a
>>general explanation, other than "I can do capability X".
>>
>>However, there is nothing IMS specific with the mechanism as such, and
>>I believe there are a number of general use-cases. But, I hope we don't
>>may impact on whether the user  is going to register multiple devices
>>in the first place, whether the user is going to generate local
>>ringback tones/anouncements (maybe the registrar can indicate
>>capability of doing it).
>>
>>
>>provide automatic call handling (call forwarding etc), or other
>>features (e.g. the announcement capability mentioned in the forking
>use-case).
>>
>>features is outside the scope of the proxy-feature mechanism itself,
>>and may even require separate standardization (if e.g. new SIP/SDP
>>don't claim to have all the answers. But, I do think it shows that
>>there could also be general use-cases :)
>>
>>
>>
>>information to be exchanged - and which entities will exchange it).
>>But, it COULD become a valid use-case.
>>
>>
>>>> On the question " One issue that remains fuzzy is distinguishing
>>>> what is and is not a valid proxy-feature", is the purpose of
>>>> discussing
>>invalid ones, I can't imagine approving any registration mechanism
>>other than standards-action.
>>>(Standards-action follows the approach of "I can't define it but I
>>>know it when I see it". Or you could say that it "crowd-sources" the
>>>decision.)
>>
>>indication, e.g. that it must not be assumed that other entities
>>support it etc. I think it's quite difficult to say much more about the
>>specific feature itself. There are different types of feature-tags
>>defined for UAs. Also, in 3GPP, at least one of the feature-tag (using
>>to indicate support of alerting SRVCC) is used both by UAs and proxies.
>>
>>Regards,
>>
>>Christer
>>
>>
>>