Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators

From: Paul Kyzivat <[email-masked]>
Date: Thu, 24 Oct 2013 13:35:55 -0400

Andrew,

This draft troubles me. It takes feature-caps in exactly the direction 
that I found most concerning about that mechanism in the first place.

The draft partitions the existing media feature tags into two sets - 
those that would be useful as feature-capability-indicators, and those 
that aren't. But I see no explanation of the criteria used to make this 
distinction, nor can I think of one.

For the ones that you have requested feature capability indicators, I 
cannot figure out what using them would mean. For example, when I see 
isFocus on a Contact header I know I am in a conference, and that I can 
subscribe to the conference event package at the contact URI. If I see 
isFocus in a Feature-Caps header, what does it mean? What can I do once 
I know this?

Section 5.14 of this draft says:

       This Feature-capability indicator indicates that the intermediary
       is a conference server, also known as a focus, and is capable of
       mixing together the media for all calls to the same URI.
...
          Examples of typical use: A conference bridge indicating that it
          is a conference bridge and is capable of acting as a conference
          focus for this session.

Note that Feature-Caps doesn't indicate which entity has this 
capability, only that something does. And since this would presumably 
only be used if it wasn't the UAC of the request, sending a subscribe to 
the contact address of the UAC wouldn't make sense.

If there is a conference bridge in the signaling path, then I would 
expect it to be the UAC.

As another example, consider section 5.1:

       Descrition:
       This Feature-capability indicator indicates that the intermediary
       supports audio as a streaming media type.
...
          Examples of typical use: An IP PBX indicating that it is
          capable of accepting and initiating sessions with audio as a
          streaming media type.

This definition *implies* an assumption about the working environment - 
one that AFAIK is new. It implies that you need to know that 
intermediaries support a media type before you can use it. Would it be 
bad if there were no intermediaries, and so none indicated this? What if 
some intermediary *did* indicate support, but some other doesn't, but 
doesn't indicate that it doesn't?

Bottom line: how would the presence or absence of this feature tag 
affect subsequent usage?

I could go on, but this is enough for now.

	Thanks,
	Paul

On 10/22/13 3:44 AM, Andrew Allen wrote:
> Adam, Paul, Richard, Gonzalo
>
> I have submitted a new draft to sipcore  to register a number of feature
> capability indicators in the SIP tree (based upon some of the existing
> SIP media feature tags). The draft can be found at:
>
> http://www.ietf.org/id/draft-allen-sipcore-sip-tree-cap-indicators-00.txt
>
> Since there will not be a sipcore session at IETF#88  can we have an
> offline discussion on how to progress this draft (which hopefully is
> fairly straightforward as it just registers feature capabilities
> indicators with IANA). I wouldn’t want to have to wait until March next
> year for a decision on progressing this.
>
> Andrew
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute
> non-public information. Any use of this information by anyone other than
> the intended recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender and delete
> this information from your system. Use, dissemination, distribution, or
> reproduction of this transmission by unintended recipients is not
> authorized and may be unlawful.

---

From: Andrew Allen <[email-masked]>
Date: Thu, 24 Oct 2013 18:14:51 +0000

Paul

Thanks for reviewing the draft already and giving me early feedback.

My responses below inline (prepended with [AA).

Andrew

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Thursday, October 24, 2013 1:36 PM
To: Andrew Allen
Cc: SIPCORE
Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators

Andrew,

This draft troubles me. It takes feature-caps in exactly the direction that I found most concerning about that mechanism in the first place.

The draft partitions the existing media feature tags into two sets - those that would be useful as feature-capability-indicators, and those that aren't. But I see no explanation of the criteria used to make this distinction, nor can I think of one.

[AA] I based this decision on the following criteria: If a feature tag was potentially at all useful for an intermediary to indicate it then include it in the registry. The ones not included are either directly associated with the user (intermediaries are not  directly associated with the user) or would only ever have one value (e.g automata).  I am not sure that every feature-capability indicator proposed to be registered is actually useful but then I don't think every media feature tag registered by RFC 3840 is either (I doubt very much if there are implementation using the sip.application or sip.control feature tags). I don't think RFC 3840 goes into a lot of details justifying every registered media feature tag and specifying the details of how they would be used either.  I am willing to remove any feature-capability indicators that are really controversial except that I think we definitely need sip.extensions, sip.methods and sip.events. There is a significant overhead to writing and progressing internet drafts so my view is lets register all that might be remotely useful in the same document (provided they don't become rat holes!).

For the ones that you have requested feature capability indicators, I cannot figure out what using them would mean. For example, when I see isFocus on a Contact header I know I am in a conference, and that I can subscribe to the conference event package at the contact URI. If I see isFocus in a Feature-Caps header, what does it mean? What can I do once I know this?

[AA] the presence of isfocus in a Feature-Caps header field means that a UA can initiate a conference by sending a REFER request to the intermediary to invite another user and create a multi user conference from the 1-1 session. I don't think this is really much different semantically than the situation of a 3 party call after a participant leaves. The focus is the place I send requests to add participants and where I subscribe to the conference event package - in this the semantic is the same.

Note that Feature-Caps doesn't indicate which entity has this capability, only that something does. And since this would presumably only be used if it wasn't the UAC of the request, sending a subscribe to the contact address of the UAC wouldn't make sense.

[AA] Yes the GRUU of the intermediary would be needed but I think this can be application specific and so this would be included in a feature tag registered in the global tree as stated in the draft "RFC 6809 [1] provides that addresses of intermediaries can be communicated as a value of an associated feature-capability indicator so it would be appropriate to define feature capability indicators as part of the global tree to communicate the GRUU of the intermediary and hence this is outside the scope of this document."  - RFC 6809 states " If additional data about a supported feature needs to be conveyed, such  as the address of the SIP entity that indicated support of the feature, then the feature definition needs to define a way to convey that information as a value of the associated feature-capability indicator." However I think the SIP specific capability indicators such as methods, extensions and events should appropriately be registered in the SIP tree not as proprietary indicators in the global tree.

If there is a conference bridge in the signaling path, then I would expect it to be the UAC.

[AA] Although a "standard" way to invoke a conference is to send a REFER to the other UAs to invite them to the conference focus,  in many deployments a scenario exists where a call involves an IP-PBX or Telephony Application Server (TAS) that can act as a focus for the conference. A participant of a call can then create a conference by sending a REFER request in dialog to the IP-PBX or TAS to use 3PCC to  Invite other users to a conference. Reasons for this are 
1. Not all UAs support REFER, 
2. Many SBCs reject REFER requests going outside domains because of the potential for charging fraud (referring to a premium rate number etc) 
3. A User receiving a REFER and then using an INVITE to join the conference may be charged for initiating  the call when the scenario is that the initiator of the conference should be charged. 
Problem is how to achieve the same behavior without dialog reuse which has been deprecated by RFC 6665?

       Descrition:

This definition *implies* an assumption about the working environment - one that AFAIK is new. It implies that you need to know that intermediaries support a media type before you can use it. Would it be bad if there were no intermediaries, and so none indicated this? What if some intermediary *did* indicate support, but some other doesn't, but doesn't indicate that it doesn't?

Bottom line: how would the presence or absence of this feature tag affect subsequent usage?

[AA] The absence of the streaming types does not indicate that the intermediary does not support the media type and SDP offer answer will ultimately determine what can or cannot be used if another session is initiated involving the intermediary. However the presence of the media type in a Feature-caps header field does explictly confirm that the intermediary does support the media type and in the scenario where a UA has a choice of multiple intermediaries it could use for a conference it might choose to use the one that explicitly indicates it supports the media types the UA wants to use. As I stated already I don't care that much about these streaming media types.

	Thanks,
	Paul

On 10/22/13 3:44 AM, Andrew Allen wrote:
> I have submitted a new draft to sipcore  to register a number of 
> feature capability indicators in the SIP tree (based upon some of the 
> existing SIP media feature tags). The draft can be found at:
>
> indicators with IANA). I wouldn't want to have to wait until March 
> next year for a decision on progressing this.
>
> Andrew
>
> non-public information. Any use of this information by anyone other 
> than the intended recipient is prohibited. If you have received this 
> transmission in error, please immediately reply to the sender and 
> delete this information from your system. Use, dissemination, 
> distribution, or reproduction of this transmission by unintended 
> recipients is not authorized and may be unlawful.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.