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

[Paul Kyzivat <[e-mail]>]

(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