Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature

["Elwell, John" <[e-mail]>]

Well, if everyone says they won't perform a feature because somebody else is going to do it, that seems like a recipe for not having the feature performed at all. There would need to be some rules on which entity performs the feature and which entities do not perform the feature. I am not sure this was clear from the draft.

John 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Christer Holmberg
> Sent: 22 January 2011 09:32
> To: Paul Kyzivat; [e-mail]
> Subject: Re: [sipcore] Draft new version: 
> draft-holmberg-sipcore-proxy-feature
> 
> 
> Hi Paul,
> 
> The idea is that each feature specification defines what 
> indicating support of a feature means - in the same way it is 
> done for UAs.
> 
> For example, just because a proxy indicate support of a 
> feature, it doesn't automatically mean that others will 
> address requests towards that proxy. It may for example mean 
> that another entity, when it sees the feature tag, does not 
> trigger some action.
> 
> I am sure there are things in the draft than can be 
> clarified, including the 3GPP use-cases, but I think it would 
> be useful to know (for me personally, and for 3GPP that wants 
> to use the mechanism) whether the WG is willing to start this 
> work. Nobody has objected to the work as such (you even say 
> yourself that it might be useful :), and all questions and 
> issues that have been raised will of course have to be solved 
> (like we always do).
> 
> Regards,
> 
> Christer
> 
> 
> 
> ________________________________________
> From: [e-mail] [[e-mail]] On 
> Behalf Of Paul Kyzivat [[e-mail]]
> Sent: Saturday, January 22, 2011 3:00 AM
> To: [e-mail]
> Subject: Re: [sipcore] Draft new        version:        
> draft-holmberg-sipcore-proxy-feature
> 
> (speaking as an individual)
> 
> Inline...
> 
> 
> 
> On 1/21/2011 5:25 PM, Andrew Allen wrote:
> > I have reviewed this draft and basically I am supportive of the
> > objective of this work.
> >
> > I think the current use cases are very specific and the 
> problem itself
> > is even more general.
> >
> > I think the general requirement is that it is useful for 
> UAs and other
> > intermediaries to be able to detect the presence of an 
> intermediary on
> > the path of a registration or the route of a dialog when that
> > intermediary provides some feature or service and be able 
> to identify
> > the URI of that intermediary in order to be able to address 
> requests to
> > it . In addition to the 3GPP specific use cases currently 
> in the draft I
> > think there are others including:
> 
> A major thing that is lacking here is any explanation of what 
> it *means*
> for an intermediary to "offer a feature" - what sorts of 
> features those
> are, and how one might avail oneself of them.
> 
> In the case of callerprefs/callee caps and currently defined, the
> intermediary is a proxy that does address translation based on a
> registrar. One knows that the way to avail themselves of the 
> features is
> to send a request to an AOR with registrations and use callerprefs to
> request routing to a device with those features.
> 
> Or, one might learn about capabilities because they are returned
> attached to a contact in a dialog, and then one avails oneself of the
> capabilities by sending a subsequent request to that contact.
> 
> Now maybe this draft implies no more - that the capabilities are ones
> that I can get access to by sending a request to the address I find in
> the Route header. But of course its not normal to send a request with
> the R-URI being an address taken from a Route header.
> 
> I think this is the usual thing - there is a framework within 
> which this
> makes sense, but its defined in IMS. And as usual, the 
> inclination is to
> say: please say more than that you want this to use in some 
> unspecified
> way with IMS.
> 
>         Thanks,
>         Paul
> 
> > Dealing with call feature interactions
> >
> > In a deployment where different intermediaries provide 
> different call
> > features it is sometimes necessary to be able to detect that another
> > intermediary has invoked a particular feature as that may 
> mean that a
> > particular feature should not be invoked or should be 
> invoked in a way
> > that takes account of the invocation of the feature by the other
> > intermediary in order to prevent conflicts between 
> different call features.
> 
> So in this case it is not about detecting *capabilities* that might be
> used, but rather about detecting behavior that is already 
> being applied?
> 
> > Detecting the presence of a SIP PBX
> >
> > SIP PBXs may be present in a network and may provide call 
> features and
> > other services on behalf of the UA. In some cases the UA may need to
> > address requests to the PBX to invoke some features or services.
> 
> This is more what I was getting at. But its not clear to me what the
> model is for "addressing requests to the PBX to invoke some 
> features or
> services".
> 
> > Although presence of the PBX could be indicated using 
> configuration this
> > isn't really effective when there are mobile UAs moving between
> > enterprise networks that have PBXs and public networks that don't.
> >
> > Detecting the presence of a telephony application server.
> >
> > In 3GPP IMS Multimedia Telephony Service (MMTel) there is a 
> Telephony
> > Application Server (TAS) that provides call features on 
> behalf of the
> > UA. However not all 3GPP networks will necessarily deploy 
> MMTel so it is
> > necessary that a UA be able to identify that a TAS is 
> involved in the
> > call and be able to send requests such as REFER to the TAS 
> in order to
> > perform functions like call transfer. Having the TAS always act as a
> > full B2BUA and overwrite the Contact is not a good solution 
> as this will
> > cause the loss of the GRUUs of the far end UAs.
> 
> This begs some higher level model of the possible components 
> in a system
> and their potential relationships to one another. I realize IMS has
> this, that doesn't help in defining this in the ietf context. We are
> starting to have such things in the work that was done in BLISS. But I
> don't know if that is similar. And of course a bunch of ietf folk
> believe that IMS has it all wrong.
> 
> > In addition since the same intermediary may perform 
> multiple features or
> > services it is useful for the URI that is provided to identify the
> > related call feature or service so that when the UA 
> addresses a request
> > to the intermediary the intermediary knows what feature or 
> service the
> > request is related to.
> >
> > Some detailed comments:
> >
> > Section 6
> >
> > NOTE: If a route set is built using Path, Record-Route or Service-
> >
> > Route header fields, any inserted feature tag will be 
> copied into the
> >
> > associated Route header fields, together with other header field
> >
> > parameters. This specification does not define any specific meaning
> >
> > of the feature tags present in Route header fields in such cases.
> >
> > I think the meaning of the feature tag in the Route header 
> is the same
> > it means that the entity whose URI is on the Route supports 
> the feature
> 
> Yes. Those other headers only exist to form Routes. I would think that
> it is presence on the Route that would matter, except in cases where
> presence on Record-Route leads something along the way to 
> block the call.
> 
> > Section 7
> >
> > I think the direction issue may need more work. It would I think be
> > useful to indicate the directionality.
> >
> > I believe that SIPCORE should adopt this and work on a solution.
> 
> I hear you. Lets see what others have to say.
> 
>         Thanks,
>         Paul
> 
> > Andrew
> >
> > *From:*[e-mail] 
> [mailto:[e-mail]] *On
> > Behalf Of *Christer Holmberg
> > *Sent:* Tuesday, December 07, 2010 7:38 AM
> > *To:* [e-mail]
> > *Subject:* [sipcore] Draft new version: 
> draft-holmberg-sipcore-proxy-feature
> >
> > Hi,
> >
> > I've submitted a new version of the proxy-feature draft.
> >
> > It now contains more use-cases, for which the usage of the 
> draft have
> > been discussed in 3GPP.
> >
> > In the examples there is also some wording about why the 
> usage of the
> > Contact header field is not seen as appropriate.
> >
> > I have added some text about the "direction" of capabilities.
> >
> > Regards,
> >
> > Christer
> >
> > 
> ---------------------------------------------------------------------
> > 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
>