Re: [sipcore] Draft submission: draft-ietf-sipcore-proxy-feature-reqs-00

[Andrew Allen <[e-mail]>]

Christer and all

I have reviewed the requirements draft and I think it is a good start but I don't think all the use cases and requirements have yet been captured.

On January 21st 2011 I sent an email containing some additional use cases (including some non IMS ones) to the SIPCORE list. These are not captured in the new draft and there hasn't yet been any discussion as to why they are not also use cases and requirements to meet for proxy feature. The relevant content of my earlier email is repeated below:

-------------------------------------------------------------------------------------------------------------------------------------------------

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 to the above earlier requirements I have the following additional input for consideration:


If an SBC or other intermediary can identify to a UA its presence on the route of a request and a URI that related request need to be routed via then the UA could know that related out of dialog requests need to be routed via that SBC (or intermediary) by including that URI in a route header. Then the SBC (or intermediary) can do whatever messing of the header fields it needs to do to make that request (such as a REFER) be aligned with the original values in the related request that the SBC (or intermediary) messed with so that it works when it gets to the far end. I think this can help address the issues that SBC and other intermediaries cause for things like REFER and GRUU where they monkey with things breaking end to end interoperability.



I think that as well as the feature tag itself it also needs to be possible to include a contact URI associated with the feature tag so that a request can be addressed to or routed via the intermediary that supports the feature. Originally it was thought that the URI in the R-R, Route, Path or S-R header could be used for that but it has been pointed out there are issues with that because the URI may not be valid in both directions, also it may be messed with by middleboxes, might be in local IP address space or simply not directly reachable from the UA. Such a thing I think can deal with the directionality problem.



I also I have seen people defining feature tags with values that are URIs or telephone numbers etc because they need a way to transport the URI that is used to contact the intermediary. This is in my view an abuse of feature tags as the value of the feature tag does not identify a capability but instead identifies a URI that can be used to contact the entity in order to invoke the feature. However it seems clear that there is a need for an intermediary to be able to provide a contact URI (outside of all the constraints that the existing routing URI has) that another UA can use to route a request to that intermediary.



I think from the above the following additional requirements also need to be considered:


1.       It MUST be possible for an intermediary to indicate a contact URI associated with the indicated feature that can be used as a contact address (i.e placed in the Request-URI) in order to contact the entity in order to provide the feature or perform some functionality that is part of the feature.

2.       It MUST be possible for an intermediary to indicate multiple features and to indicate different contact URIs for different features.

3.       The contact URI should be routable from the intended consumer of the feature even when the routing URI is not globally routable (e.g because it is behind a firewall, is private IP address space, obfuscated by an SBC etc)

4.       It MUST be possible for the contact URI to contain any absolute URI (not just a SIP URI e.g TEL, URN etc).

5.       IT MUST be possible for an intermediary to indicate that out of dialog requests related to this dialog need to be routed via the URI of the intermediary.

Apologies for submitting this right before the WG discussion. I think this is very useful work but we need to fully nail down and discuss all the use cases and requirements.

Andrew

From: [e-mail] [mailto:[e-mail]] On Behalf Of Christer Holmberg
Sent: Monday, June 20, 2011 1:57 AM
To: SIPCORE (Session Initiation Protocol Core) WG
Subject: [sipcore] Draft submission: draft-ietf-sipcore-proxy-feature-reqs-00


Hi,

I've submitted a requirements draft for proxy-feature (draft-ietf-sipcore-proxy-feature-reqs-00).

Based on discussions with the ADs and WG chairs, the draft only contains requirements. Based on e-mail discussions and off-line comments, I've also added a number of requirements.

The idea is to first agree on the requirements, and then focus on the solution.

Until the draft appears in IETF, it can also be found at:

http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-proxy-feature-reqs-00.txt

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.