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

[Paul Kyzivat <[e-mail]>]

On 10/25/13 2:49 PM, Christer Holmberg wrote:
> As a side note, you can also indicate a SIP method as a URI parameter:
>
> sip:[e-mail];method=refer

Yes. But *that* has its own semantics. It means that when you use that 
URI in a request, the method should be REFER. I don't think it is very 
relevant to this discussion.

(I have always had a problem with that one. If I'm planning to send an 
INVITE, but the URI I choose says I should use REFER, my logic probably 
won't work with REFER in place of INVITE.)

	Thanks,
	Paul

> ------------------------------------------------------------------------
> *From:* [e-mail] [[e-mail]] on behalf of
> Christer Holmberg [[e-mail]]
> *Sent:* Friday, 25 October 2013 9:47 PM
> *To:* Paul Kyzivat; Andrew Allen; SIPCORE
> *Subject:* Re: [sipcore] New sipcore draft submission
> draft-allen-sipcore-sip-tree-cap-indicators
>
> Hi,
>
>>> The next revisions will contain more details on what each FCI (as Christer now calls them means).
>>>
>>> If some are not well understood I will remove them from the draft (i.e. drop  the rat holes)
>>>
>>> I think my email exchange with Christer clarifies the other points.
>>>
>>> Does this represent in principle a way forward?
>>
>> Maybe. We'll have to see how it goes.
>>
>> The challenge is, I think, that you want to bring in a bunch of the 3840
>> feature tags, and have them mean something akin to what they do as
>> feature tags when used as FCIs. But there needs to be some way to
>> describe what *each* one means. It's not immediately clear to me how to
>> do that.
>
> As I said in another reply, I think that the FCIs that use the
> +sip.method etc FCIs need to describe how they are used in conjunction.
>
> Example:
>
> Feature-Caps: *;+g.x;+sip.methods="INVITE"
>
> Feature-Caps: *;+g.y;+sip.methods="INVITE"
>
> The FCI specifications for +g.x and +g.y need to describe how they are
> used together with +sip.methods, if there is a relationship.
>
> Otherwise +sip.methods only means that the entity that inserted the FCIs
> support "INVITE".
>
> Regards,
>
> Christer
>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[e-mail]]
>> Sent: Friday, October 25, 2013 10:06 AM
>> To: Andrew Allen; [e-mail]
>> Cc: [e-mail]; [e-mail]; [e-mail]; [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 those  tags.
>>
>> 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]
>>> <[e-mail]>
>>> Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>;
>>> [e-mail] <[e-mail]>;
>>> [e-mail] <[e-mail]>; Paul Kyzivat
>>> <[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]>
>>>> Cc: Richard Barnes ([e-mail]) <[e-mail]>; Adam Roach
>>>> ([e-mail]) <[e-mail]>; Christer Holmberg
>>>> ([e-mail]) <[e-mail]>;
>>>> Mary Barnes ([e-mail]) <[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]) Adam Roach ([e-mail])
>>>>> Christer Holmberg ([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]) Adam Roach
>>>>>> ([e-mail]) Christer Holmberg
>>>>>> ([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]) Gonzalo Camarillo
>>>>>>>> ([e-mail]) Adam Roach ([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 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 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 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
>