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

[Christer Holmberg <[e-mail]>]

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