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

Andrew Allen <> Mon, 25 July 2011 16:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 213B611E807A for <>; Mon, 25 Jul 2011 09:59:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.089
X-Spam-Status: No, score=-5.089 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ab0KlYG1wHxH for <>; Mon, 25 Jul 2011 09:59:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 21D7921F888A for <>; Mon, 25 Jul 2011 09:59:48 -0700 (PDT)
X-AuditID: 0a41282f-b7b83ae000001e85-f8-4e2d9d6fc4c4
Received: from ( []) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by (SBG) with SMTP id BD.8D.07813.F6D9D2E4; Mon, 25 Jul 2011 16:44:32 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 25 Jul 2011 12:44:41 -0400
Received: from ([fe80::c47b:e609:558:1b44]) by ([fe80::c8f6:ae2e:c42b:3614%21]) with mapi id 14.01.0289.001; Mon, 25 Jul 2011 11:44:40 -0500
From: Andrew Allen <>
To: Christer Holmberg <>, "SIPCORE (Session Initiation Protocol Core) WG" <>
Thread-Topic: [sipcore] Draft submission: draft-ietf-sipcore-proxy-feature-reqs-00
Thread-Index: AcwvF0LKQFT7YaPITgGrkOCX9bk2pwbzoJQw
Importance: high
X-Priority: 1
Date: Mon, 25 Jul 2011 16:44:39 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-CA, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD23015972XMB105ADSrimnet_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCKsWRmVeSWpSXmKPExsXC5ShmplswV9fP4NJ6LosLMw8zWnz9sYnN gcnj19erbB5LlvxkCmCKamC0SczLyy9JLElVSEktTrZV8klNT8xRCCjKLEtMrlRwySxOzknM zE0tUlLITLFVMlFSKMhJTE7NTc0rsVVKLChIzUtRsuNSwAA2QGWZeQqpecn5KZl56bZKnsH+ uhYWppa6hkp2ukgg4R93xp3bHewFr14xVlzc0cTYwHj1DGMXIyeHhICJxJQfP1khbDGJC/fW s3UxcnEICfQwSRw70gBWJCSwlFFiSbc9RGILo8Tn7/dYQBJsAsoSy3/PACsSEaiRmHf4FzuI LSwQLLG5fQM7RDxE4u33M8wQtpHE2WefwWxOAQGJX+2zWCA280pMmXsSrJ5FQFVi6t4PQDM5 OHgF3CQWvkyFuCFcomX2ZnaI1giJ/fuXs4HYjAKyErvPXmcCsZkFxCVuPZnPBDFSQGLJnvPM ELaoxMvH/6CeVJRY1PmdEaI+V2LpY4jzeQUEJU7OfMICsUtaYsfJNYwTGCVmIRk7C0nLLCQt EHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRWjYG5GsYGZQXJesl5RZq5eXmrJJkZwitLQ 38HYt1frEKMAB6MSD++vmbp+QqyJZcWVuYcYJTiYlUR4O52BQrwpiZVVqUX58UWlOanFhxhd gQE3kVmKOzkfmD7zSuKNDQxwc5TEeW2VVfyEBNKBaTI7NbUgtQhmDhMHp1QDo8jPDSYLjq5Z 0KEpmKbOEVV6pP3pCX1F27UFV2Wf/PrAuU5p99eK8GM51RXnVOalbzCVchMr2H9acmeEk3HI L6XYCjXRyN0Sq2Zbi3T3TjHeo5j54a2i7NptizY7T1ljpdNd4+nzyqxo89Hyj4L3xa8t47JO /THftOTpj4bnb2WbcvniF59yUmIpzkg01GIuKk4EAFq4d7F3AwAA
Subject: Re: [sipcore] Draft submission: draft-ietf-sipcore-proxy-feature-reqs-00
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Jul 2011 16:59:53 -0000

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.


From: [] 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


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:



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.