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

["Andrew Allen" <[e-mail]>]

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:

 

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.

 

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.
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.

 

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

 

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.

 

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.