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

[<[e-mail]>]

I support the work. From my side we can start the work on Christer's draft.

Roland

> -----Ursprüngliche Nachricht-----
> Von: [e-mail]
> [mailto:[e-mail]] Im Auftrag von Christer Holmberg
> Gesendet: Samstag, 22. Januar 2011 10:32
> An: Paul Kyzivat; [e-mail]
> Betreff: 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
>