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

[Paul Kyzivat <[e-mail]>]

On 10/25/13 4:38 PM, Andrew Allen wrote:
>
> In my view the basic premise of Feature-Caps is that an entity on the route is indicating that it supports a particular capability. Indicating support for features by other entities is rather problematic. I suppose a service proxy on the route could also indicate features supported by other physical servers that it has responsibility for that are not hosted physically by it.

It was also a basic premise of feature-caps that it didn't specify the 
address of the thing reporting the capabilities.

The explanation at the time was that it wasn't necessary - that it was 
only necessary that there was something on the path that had those 
capabilities.

> I agree with Christer that if an entity needs to support multiple sets of features that do not all apply to the same server then it should do so in separate Feature-Caps header fields with only the features that are all hosted by the same entity being included in the same Feature-Caps header field.
>
> I think entities advertising features that they are not responsible for and have nothing to do with is bogus.

I agree with that.

Then what does it mean for something on the path to insert an FCI 
containing a URI? That seems ok as long as you don't infer that other 
FCIs with it apply to the thing with that URI.

	Thanks,
	Paul

> Andrew
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Paul Kyzivat
> Sent: Friday, October 25, 2013 4:28 PM
> To: Christer Holmberg; [e-mail]
> Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators
>
> Inline.
>
> On 10/25/13 2:57 PM, Christer Holmberg wrote:
>> Hi,
>>
>> ....
>>
>>>> /Example:/
>>>>
>>>> I support the find-Paul feature, and I insert a FCI:
>>>>
>>>>       Feature-Caps: *, +g.find-paul="sip:[e-mail]"
>>>>
>>>> Now, in this case the address does NOT point to my entity, but to
>>>> Paul's entity. My entity supports a feature, which provides Paul's address.
>>>>
>>>> So, if the FCI says:
>>>>
>>>>       Feature-Caps: *,
>>>> +g.find-paul="sip:[e-mail]";+sip.methods="invite"
>>>>
>>>> ...it doesn't automatically mean that I can contact Paul using INVITE.
>>>> By default it means that MY entity supports the INVITE method -
>>>> which from the find-paul feature perspective is useless information.
>>>>
>>>> So, in the FCI specification for +g.find-paul, I would have to
>>>> explictily describe how the FCI works in conjunction with other
>>>> FCIs. I would have to explicitly say that, when used together
>>>> +sip.methods, the
>>>> +sip.methods indicates which SIP methods I can use to contact Paul
>>>> (using the address provide in the +g.find-paul FCI).
>>>
>>> So far I agree.
>>>
>>> But suppose there is also a find-christer FCI. So we have:
>>>
>>> Feature-Caps: *
>>>     ;+g.find-paul="sip:[e-mail]"
>>>     ;+g.find-paul="sip:[e-mail]"
>>>     ;+sip.methods="invite"
>>>
>>> And both find-paul and find-christer want to define the use of other
>>> FCIs. Then things start to become ambiguous.
>>>
>>> Should the description of find-paul specify what other FCIs "pertain"
>>> to it? Or should the description of sip.methods specify what FCI(s)
>>> provide the address at which it applies? Or both? What if paul and
>>> christer support different methods?
>>
>> In that case you would need to have two different Feature-Caps header
>> fields:
>>
>>       Feature-Caps:
>> *;+g.find-paul="sip:[e-mail]";+sip.methods="invite"
>>       Feature-Caps:
>> *;+g.find-paul="sip:[e-mail]";+sip.methods="message"
>
> That seemingly solves the problem, but if the same entity inserts them both then its a questionable use of Feature-caps isn't it?
>
>> In your example you had two instances of the same FCI (is that even
>> allowed?),
>
> I did? find-paul and find-christer are two different FCIs.
> (But that sort of naming will be troublesome for the registry and for the expert who has to approve entries in it.:-)
>
>    but there could also have been a case with two different
>> FCIs, both using +sip.methods, in which case you may have to put them
>> into separate Feature-Caps header fields.
>>
>> These things would have to be clearly specified.
>
> Very definitely.
>
> 	Thanks,
> 	Paul
>
>> Regards,
>>
>> Christer
>>
>>
>>> Section 5.3.8 in RFC 6809 also says:
>>>
>>>       "If there is additional information about the feature-capability
>>>          indicator, it is recommended to describe such information.  It can
>>>          include, for example, *names of related feature-capability
>>> indicators*."
>>>
>>> So, in your case, I think the +g.3gpp.see_trans FCI specifiction
>>> would have to specify how the FCI is used in conjuntion with other
>>> FCIs, including the +sip.method FCI.
>>>
>>> Something like: "When the session transfer request is sent to the
>>> address indicated by the FCI value, the +sip.method FCI indicates
>>> which SIP methods can be used."
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>>
>>> *From*: Christer Holmberg [mailto:[e-mail]]
>>> *Sent*: Friday, October 25, 2013 12:01 PM Central Standard Time
>>> *To*: Andrew Allen; Paul Kyzivat <[e-mail]>; Gonzalo
>>> Camarillo <[e-mail]>
>>> *Cc*: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>;
>>> [e-mail] <[e-mail]>
>>> *Subject*: RE: New sipcore draft submission
>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>
>>> Hi,
>>>
>>>> I think we can have an FCI
>>>
>>>>
>>>
>>>> Feature-Caps: *;+g.3ggp.sess_trans="sip:[e-mail];gr"
>>>
>>>>
>>>
>>>> Indicating that the entity supports 3GPP session transfer and the
>>>> address where you send the session transfer request is
>>>> sip:[e-mail];gr <mailto:[e-mail];gr>
>>>
>>> Correct. The FCI itself indicates support of session transfer
>>> feature, and the FCI value indicates the address associatd with the feature.
>>>
>>>> Also if I have:
>>>
>>>>
>>>
>>>> Feature-Caps: *;+g.3ggp.sess_trans=sip:[e-mail];gr;
>>>> +sip.extensions="replaces, tdialog";
>>> +sip.methods="invite, refer, bye, options, update, prack"
>>>
>>>>
>>>
>>>> This means the entity supports 3GPP session transfer and the address where you send the session transfer request is  sip:[e-mail];gr <mailto:[e-mail];gr>...
>>>
>>> Correct.
>>>
>>>> ...supports the replaces and target dialog extensions and supports the following methods - invite, refer, bye, options, update, prack.
>>>
>>> Technically, what it means is that there is *AN* entity which
>>> supports the features listed above, and the address is where you are
>>> to send the session transfer request in order to trigger the 3GPP
>>> session transfer feature.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>> *From:*Christer Holmberg [mailto:[e-mail]]
>>> *Sent:* Friday, October 25, 2013 10:25 AM
>>> *To:* Paul Kyzivat; Andrew Allen; Gonzalo Camarillo
>>> *Cc:* [e-mail]; [e-mail]; [e-mail]
>>> *Subject:* RE: New sipcore draft submission
>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>
>>> Hi,
>>>
>>> As Paul said, if one needs to provide address information associated
>>> with a FCI, the address information cannot be a FCI of its own. It
>>> needs to be a value of the FCI for which it is associated.
>>>
>>> Something like:
>>>
>>> Feature-Caps: *;+audio="sip:[e-mail]"
>>>
>>> (Also note that the "+" sign is mandatory for all FCIs - no matter
>>> which registry tree they belong to)
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>> ---------------------------------------------------------------------
>>> ---
>>>
>>> *From:*Paul Kyzivat [[e-mail]]
>>> *Sent:* Friday, 25 October 2013 5:06 PM
>>> *To:* Andrew Allen; Gonzalo Camarillo
>>> *Cc:* [e-mail] <mailto:[e-mail]>; [e-mail]
>>> <mailto:[e-mail]>; Christer Holmberg;
>>> [e-mail] <mailto:[e-mail]>
>>> *Subject:* Re: New sipcore draft submission
>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>
>>> Andrew,
>>>
>>> (I see this is still on the private thread. I'll reply here, but this
>>> exchange should probably be reposted to the sipcore list as part of
>>> the public discussion of the draft.)
>>>
>>> On 10/24/13 10:41 PM, Andrew Allen wrote:
>>>>
>>>> Paul
>>>>
>>>> I am happy to do a revision with more details on the semantics of the capability indicators. However I don't think it should be held to a very much higher bar than the details in RFC 3840 and the other media feature tag RFCs regarding the meaning of thosetags.
>>>
>>> Keep in mind that the driving force for the definition of feature
>>> tags in 3840 was in support of callerprefs (3841). So the context for
>>> the use of feature tags was that they would be placed on Contacts in
>>> REGISTER requests. So you can interpret the definitions in that
>>> context: that a request sent to an AOR using callerprefs can affect
>>> the choice of which device the request goes to according to the
>>> capabilities it wants. In that context audio, video, isfocus all make sense.
>>>
>>> Their use on Contacts in dialogs was derivative to that: because
>>> callerpref support is optional, there is no guarantee that the device
>>> you reach via callerprefs will have the capabilities you requested.
>>> So the values in the contact help confirm what you got.
>>>
>>> Of course they have since been used other ways. And the descriptions
>>> of them don't necessarily reflect that. IMO that is a defect due to
>>> the evolution of use.
>>>
>>> I'm looking for the same sort of context for use with the feature-caps.
>>>
>>> In private discussion you indicated to me that you expected the
>>> feature caps to be grouped - with one of them giving the URI of the
>>> device that the other tags apply to. I guess this would end up looking something like:
>>>
>>>      Feature-Caps: *;g.uri="sip:[e-mail]";audio
>>>      Feature-Caps: *;g.uri="sip:[e-mail]";audio;video;isfocus
>>>      Feature-Caps: *;g.uri="sip:[e-mail]";text
>>>
>>> (I'm making up g.uri for the example.)
>>>
>>> And then presumably somebody on the signaling path will "shop" in the
>>> feature caps for the capabilities it wants, and then send a request
>>> to that URI, with the expectation that the UA responding will have
>>> those capabilities.
>>>
>>>> The semantics should be no different than those of  the corresponding existing media  feature tag if it is present in the Contact header.
>>>
>>> Note that 6809 says:
>>>
>>>       When a SIP entity receives a SIP request, or response, that contains
>>>       one or more Feature-Caps header fields, the feature-capability
>>>       indicators in the header field inform the entity about the features
>>>       and capabilities supported by entities in the SIP message signaling
>>>       path.  The procedure by which features and capabilities are invoked
>>>       are outside the scope of this specification and MUST be described by
>>>       individual feature-capability indicator specifications.
>>>
>>>       A Feature-Caps header field value cannot convey the address of the
>>>       SIP entity that inserted the Feature-Caps header field.  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.
>>>
>>> This was discussed at length while that RFC was under consideration.
>>> Yet the definitions of the tags in *this* draft don't specify that.
>>>
>>>> The registration templates currently reference the RFC 3840 and the other RFCs that define the other media feature tags that correspond to these feature capability indicators.
>>>
>>> And those definitions were written to be understood in the context of
>>> 3840/3841. They make sense in that context, but not in *this* context.
>>>
>>>           Thanks,
>>>           Paul
>>>
>>>> But if more explicit detail is required then I can add some more text  or alternatively remove the less important ones if they are going to become rat holes. The ones I regard as really important and urgent are sip.methods, sip.extensions and sip.events  the  meaning of which I think should be quite clear.
>>>>
>>>> Andrew
>>>>
>>>> ----- Original Message -----
>>>> From: Paul Kyzivat [mailto:[e-mail]]
>>>> Sent: Thursday, October 24, 2013 04:44 PM Central Standard Time
>>>> To: Andrew Allen;[e-mail]
>>>> <mailto:[e-mail]>
>>> <[e-mail]
>>> <mailto:[e-mail]>>
>>>> Cc:[e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>;
>>> [e-mail] <mailto:[e-mail]> <[e-mail]
>>> <mailto:[e-mail]>>; [e-mail]
>>> <mailto:[e-mail]>
>>> <[e-mail]
>>> <mailto:[e-mail]>>; [e-mail]
>>> <mailto:[e-mail]> <[e-mail]
>>> <mailto:[e-mail]>>; Paul Kyzivat
>>> <[e-mail] <mailto:[e-mail]>>
>>>> Subject: Re: New sipcore draft submission
>>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>>
>>>> On 10/24/13 4:07 PM, Andrew Allen wrote:
>>>>>
>>>>> Paul
>>>>>
>>>>> Ok
>>>>>
>>>>> So we are basically where I thought we were at when I submitted the draft.
>>>>>
>>>>> Maybe you, Adam, Gonzalo, Richard, Christer and I (plus anyone else who indicates interest) can have some offline discussion in Vancouver on whether and how to progress this.
>>>>
>>>> As I indicated again on the sipcore list, I found the that the draft
>>>> didn't explain nearly enough to allow meaningful use of these.
>>>> I know you replied, and I will continue the conversation there.
>>>> But I will be opposed to these until and unless the draft (and
>>>> notably the descriptions of the tags) are clear about how one could
>>>> figure out what can do in the presence of the tags that one couldn't
>>>> do without them. AND, that the behavior that suggests doesn't
>>>> "break" sip. (E.g., by advocating a new and incompatible way to do
>>>> something.)
>>>>
>>>> We can continue this on the sipcore list.
>>>>
>>>>         Thanks,
>>>>         Paul
>>>>
>>>>> Andrew
>>>>>
>>>>> ----- Original Message -----
>>>>> From: Paul Kyzivat [mailto:[e-mail]]
>>>>> Sent: Thursday, October 24, 2013 02:54 PM Central Standard Time
>>>>> To: Andrew Allen; Gonzalo Camarillo <[e-mail]
>>>>> <mailto:[e-mail]>>
>>>>> Cc: Richard Barnes ([e-mail] <mailto:[e-mail]>) <[e-mail]
>>>>> <mailto:[e-mail]>>; Adam
>>> Roach ([e-mail] <mailto:[e-mail]>) <[e-mail]
>>> <mailto:[e-mail]>>; Christer Holmberg
>>> ([e-mail]
>>> <mailto:[e-mail]>)
>>> <[e-mail]
>>> <mailto:[e-mail]>>; Mary Barnes
>>> ([e-mail] <mailto:[e-mail]>) <
>>> [e-mail] <mailto:[e-mail]>>
>>>>> Subject: Re: New sipcore draft submission
>>>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>>>
>>>>> On 10/24/13 2:17 PM, Andrew Allen wrote:
>>>>>> Paul
>>>>>>
>>>>>> That is fine. Although Mary in her reply to me seemed to indicate maybe there was a possibility to use some of the DISPATCH spare time for a SIPCORE session for this. Is that a possibility?
>>>>>>
>>>>>> I already replied to your post
>>>>>
>>>>> I discussed that with Adam. We decided we can't set a precedent to
>>>>> spin up a session to discuss a draft that hasn't had substantial
>>>>> (any) list discussion.
>>>>>
>>>>> But list discussion is always welcome.
>>>>>
>>>>>        Sorry,
>>>>>        Paul
>>>>>
>>>>>> Andrew
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Paul Kyzivat [mailto:[e-mail]]
>>>>>> Sent: Thursday, October 24, 2013 1:31 PM
>>>>>> To: Andrew Allen; Gonzalo Camarillo
>>>>>> Cc: Richard Barnes ([e-mail] <mailto:[e-mail]>); Adam Roach
>>>>>> ([e-mail]
>>> <mailto:[e-mail]>); Christer Holmberg
>>> ([e-mail]
>>> <mailto:[e-mail]>)
>>>>>> Subject: Re: New sipcore draft submission
>>>>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>>>>
>>>>>> Andrew,
>>>>>>
>>>>>> I spoke with Mary about it, and we concluded that dispatch isn't right for this. (In addition to being clearly sipcore, it didn't meet the deadline for dispatch.) I was wrong to encourage you that way.
>>>>>>
>>>>>> So no official live discussion in Vancouver. (But informal
>>>>>> discussion
>>>>>> fine.)
>>>>>>
>>>>>> I'll resend my private comments to the sipcore list to kickstart some discussion there.
>>>>>>
>>>>>>       Thanks,
>>>>>>       Paul
>>>>>>
>>>>>> On 10/24/13 1:01 PM, Andrew Allen wrote:
>>>>>>> I just emailed Mary asking for agenda time. Should I cancel that request?
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Gonzalo Camarillo [mailto:[e-mail]]
>>>>>>> Sent: Thursday, October 24, 2013 1:00 PM
>>>>>>> To: Paul Kyzivat
>>>>>>> Cc: Andrew Allen; Richard Barnes ([e-mail]
>>>>>>> <mailto:[e-mail]>); Adam Roach ([e-mail]
>>>>>>> <mailto:[e-mail]>); Christer Holmberg
>>> ([e-mail]
>>> <mailto:[e-mail]>)
>>>>>>> Subject: Re: New sipcore draft submission
>>>>>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>>>>>
>>>>>>> Hi Paul,
>>>>>>>
>>>>>>> given that you think this belongs to SIPCORE, I do not see the need to run it through DISPATCH. Please, start technical discussions on the draft on the SIPCORE list.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Gonzalo
>>>>>>>
>>>>>>> On 22/10/2013 9:11 PM, Paul Kyzivat wrote:
>>>>>>>> On 10/22/13 1:00 PM, Andrew Allen wrote:
>>>>>>>>> Paul
>>>>>>>>>
>>>>>>>>> Thanks for reviewing the draft already and giving me early feedback.
>>>>>>>>>
>>>>>>>>> My responses below inline (prepended with [AA).
>>>>>>>>>
>>>>>>>>> Can I ask the ADs to determine ASAP if this needs to go to
>>>>>>>>> DISPATCH first or not. As outlined below my view is that it is
>>>>>>>>> unnecessary for every little thing to go to DISPATCH as this
>>>>>>>>> just creates additional delay and overhead. If it is to be
>>>>>>>>> discussed in DISPATCH then I definitely would want agenda time atIETF#88 for this.
>>>>>>>>
>>>>>>>> Having now seen Andrew's responses to my initial questions, I
>>>>>>>> think this
>>>>>>>> *needs* to be carefully considered by sipcore. IMO this has the
>>>>>>>> potential to create a dialect of sip that is incompatible with
>>>>>>>> normal usage. (Maybe IMS has already done that. But this will
>>>>>>>> make it
>>>>>>>> worse.)
>>>>>>>>
>>>>>>>> But if there is a desire to discuss it publicly in Vancouver
>>>>>>>> then dispatch is the opportunity and so some discussion on the
>>>>>>>> dispatch list in advance of that would be appropriate.
>>>>>>>>
>>>>>>>> I'll defer to the ADs on this.
>>>>>>>>
>>>>>>>> More inline.
>>>>>>>>
>>>>>>>>> Andrew
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Paul Kyzivat [mailto:[e-mail]]
>>>>>>>>> Sent: Tuesday, October 22, 2013 10:33 AM
>>>>>>>>> To: Andrew Allen; Richard Barnes ([e-mail]
>>>>>>>>> <mailto:[e-mail]>); Gonzalo Camarillo
>>>>>>>>> ([e-mail]
>>>>>>>>> <mailto:[e-mail]>);
>>> Adam Roach ([e-mail] <mailto:[e-mail]>)
>>>>>>>>> Subject: Re: New sipcore draft submission
>>>>>>>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>>>>>>>
>>>>>>>>> Andrew,
>>>>>>>>>
>>>>>>>>> On a legalistic note, its questionable to me whether this kind
>>>>>>>>> of action falls within the scope of sipcore. OTOH, among
>>>>>>>>> existing wgs, sipcore is probably the best suited to discuss
>>>>>>>>> the proposal. We could take it to DISPATCH. I think DISPATCH
>>>>>>>>> has extra time in its agenda for Vancouver, so that might be
>>>>>>>>> one option for you. But then I don't know where dispatch would
>>>>>>>>> dispatch it. It may be that AD sponsored is the best way to go.
>>>>>>>>>
>>>>>>>>> [AA] It seemed to me that sipcore was the right place. This
>>>>>>>>> draft registers feature-capability indicators in a registry
>>>>>>>>> that was created by a sipcore RFC (RFC 6809). You could in my
>>>>>>>>> view make an argument that this should even have been done as part of RFC 6809.
>>>>>>>>
>>>>>>>> If this was just a matter of registering some new feature caps
>>>>>>>> that were not controversial, then I don't think sipcore needs to be involved.
>>>>>>>>
>>>>>>>> But as I mentioned above, I do consider these controversial.
>>>>>>>>
>>>>>>>>> Discussing it now on the dispatch list would be a good start
>>>>>>>>> toward discussing it at the dispatch session.
>>>>>>>>>
>>>>>>>>> [AA] Can I ask the ADs to determine if this needs to go to
>>>>>>>>> DISPATCH first or not. My view is that it is unnecessary for
>>>>>>>>> every little thing to go to DISPATCH as this just creates additional delay and overhead.
>>>>>>>>> This just registers some indicators in an existing IANA
>>>>>>>>> registry and is not (or should not be IMHO) a major project.
>>>>>>>>
>>>>>>>> To me this is a matter of whether you want to be opportunistic.
>>>>>>>> If this went to dispatch I would now recommend that it be
>>>>>>>> dispatched to sipcore. So its a matter of whether you want to
>>>>>>>> talk about it in the dispatch meeting.
>>>>>>>>
>>>>>>>>> Regarding substance, this draft troubles me. It takes
>>>>>>>>> feature-caps in exactly the direction that I found most
>>>>>>>>> concerning about the mechanism in the first place.
>>>>>>>>>
>>>>>>>>> Your 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 of ever 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 controversial except that I think we definitely need sip.extensions, sip.methods and sip.events.
>>>>>>>>> There is a significant overhead to writing an
>>>>>>>> d progressing internet drafts so my view is lets register all
>>>>>>>> that might be remotely useful in the same document.
>>>>>>>>
>>>>>>>> The judgement of "useful" is reasonable. But I still can't
>>>>>>>> discern what the use is from the iana registration descriptions.
>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> [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.
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>> consider this 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 indicator
>>>>>>>> s in the global tree.
>>>>>>>>
>>>>>>>> So you have defined a sip tree feature tag that is only useful
>>>>>>>> in conjunction with another feature tag from the global tree.
>>>>>>>> And the description of this feature tag doesn't even mention that.
>>>>>>>>
>>>>>>>> And this all implies a completely non-standard call model -
>>>>>>>> doing conferencing in a way inconsistent with RFC 4579.
>>>>>>>>
>>>>>>>> ISTM that if 4579 doesn't work for you then you should be back
>>>>>>>> proposing extensions/revisions to it.
>>>>>>>>
>>>>>>>>> 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,
>>>>>>>>
>>>>>>>> So you are saying the intermediary isn't a focus (its a B2BUA),
>>>>>>>> but it *could become* a focus.
>>>>>>>>
>>>>>>>> The concept that a dialog may contain intermediaries that can be
>>>>>>>> addressed to do stuff is not part of any sip standard that I am
>>>>>>>> aware of. I don't care too much as long as the "stuff" is
>>>>>>>> application stuff that is outside the scope of sip. But when it
>>>>>>>> is alternative ways to do stuff that sip supports, then I get upset.
>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>> 4. No need to obtain and distribute conference URIs.
>>>>>>>>> Problem is how to achieve the same behavior without dialog
>>>>>>>>> reuse which has been deprecated by RFC 6665?
>>>>>>>>
>>>>>>>> Then maybe the problem needs to be brought up, and a standard
>>>>>>>> solution proposed, rather than simply enabling a proprietary mechanism.
>>>>>>>>
>>>>>>>>> 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?
>>>>>>>>>
>>>>>>>>> [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.
>>>>>>>>
>>>>>>>> So the UA will be able to discover that *some* intermediary
>>>>>>>> supports media it is interested in. And it can tell that *some*
>>>>>>>> intermediary says it is a focus. It doesn't know if they are the same intermediary.
>>>>>>>>
>>>>>>>> And then via some other feature tag it obtains the URI of *some*
>>>>>>>> intermediary on the signaling path. Or maybe it gets more than
>>>>>>>> one of these.
>>>>>>>>
>>>>>>>> It then makes a leap of faith and conflates all those things, to
>>>>>>>> determine that the URI identifies a focus that supports this media type.
>>>>>>>>
>>>>>>>> Even then, exactly what does that mean? It may or may not mean
>>>>>>>> that it supports mixing that media type in a conference.
>>>>>>>>
>>>>>>>>> As I stated already I don't care that much about these
>>>>>>>>> streaming media types.
>>>>>>>>
>>>>>>>>> I could go on, but this is enough for now.
>>>>>>>>>
>>>>>>>>> [AA] My motivation for this is that currently 3GPP are updating
>>>>>>>>> their specifications to use RFC 6665 instead of RFC 3265.
>>>>>>>>
>>>>>>>>> 3GPP has a lot of dialog reuse with SUBSCRIBE and REFER with
>>>>>>>>> intermediaries accepting the REFER or SUBSCRIBE request rather
>>>>>>>>> than forwarding it all the way to the remote UA.
>>>>>>>>
>>>>>>>> And 6665 deprecates dial reuse in most of those cases.
>>>>>>>> Without dialog reuse, the intermediaries don't get an
>>>>>>>> opportunity to intercept those.
>>>>>>>>
>>>>>>>>> In order to know that an intermediary supports the target
>>>>>>>>> dialog mechanism  needed for a REFER request sent outside the
>>>>>>>>> dialog to work we need sip.extensions as a feature-capability
>>>>>>>>> indicator. In order to know that the needed event package is
>>>>>>>>> supported by the intermediary so we can SUBSCROBE outside the
>>>>>>>>> dialog to an intermediary we need sip.events as a feature-capability indicator.
>>>>>>>>
>>>>>>>> Then I think you should be back here with a problem statement
>>>>>>>> and a request for how to get sip to solve it.
>>>>>>>>
>>>>>>>> And you should touch base with Christer on this. He may have a
>>>>>>>> different opinion on the relevance of feature-caps as a solution.
>>>>>>>>
>>>>>>>>          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.
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------
>>>>>>>>> -----
>>>>>>>>> - 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> -----------------------------------------------------------------
>>>>>>> ---- 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 informationby 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
>>>>>> informationby 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 informationby
>>>>> 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 informationby
>>>> 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.
>>> ---------------------------------------------------------------------
>>> 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.
>>>
>>>
>>> _______________________________________________
>>> sipcore mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>
>>
>> _______________________________________________
>> sipcore mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
> ---------------------------------------------------------------------
> 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.
>
>