[sipcore] Proxy feature tag use-case: capability to use Path header field information in both directions

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 22 October 2010 11:35 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F9853A680D for <sipcore@core3.amsl.com>; Fri, 22 Oct 2010 04:35:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.049
X-Spam-Level:
X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2i5vcefZHQd for <sipcore@core3.amsl.com>; Fri, 22 Oct 2010 04:35:54 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 58CED3A686A for <sipcore@ietf.org>; Fri, 22 Oct 2010 04:35:53 -0700 (PDT)
X-AuditID: c1b4fb39-b7b54ae000003464-12-4cc177793141
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id AA.FB.13412.A7771CC4; Fri, 22 Oct 2010 13:37:30 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Fri, 22 Oct 2010 13:37:29 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "sipcore@ietf.org" <sipcore@ietf.org>
Date: Fri, 22 Oct 2010 13:37:28 +0200
Thread-Topic: Proxy feature tag use-case: capability to use Path header field information in both directions
Thread-Index: Actx3YGO+cBNKGQcR3CDz5aaOmQMSA==
Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502E8A90B@ESESSCMS0356.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A058502E8A90BESESSCMS0356eem_"
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: [sipcore] Proxy feature tag use-case: capability to use Path header field information in both directions
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Oct 2010 11:35:55 -0000

Hi,

PROBLEM:
-----------------

Many of you may remember the discussions we've had every now and then regarding issues of building a Service-Route.

The RFC recommends against intermediaries inserting themselves in the Service-Route of the REGISTER response.

In addition, the registrar cannot assume that the Path header(s) received in the REGISTER request can be used by the registrar to build the Service-Route, so often the only instane in the Service-Route is the registrar itself.

In addition, the UA cannot assume that the Path header(s) received in the REGISTER response can be used to build a route for initial dialog or stand-alone SIP requests. The reasons is that Path by definition only provides routing information for the registrar-to-UA direction.

So, today, if initial dialog or stand-alone SIP requests are to be routed via specific intermediaries, it has to be done by configuration, since neither the Service-Route or Path can be used to build the route.


POSSIBLE SOLUTION:
-----------------------------------

Some years ago Jonathan wrote a draft (http://tools.ietf.org/id/draft-rosenberg-sip-route-construct-02.txt), which made it possible to indicate that a Path header value can be used for routing in both directions, ie the registrar could insert it in the Service-Route, or the UA can use it to build a route.

At one point I agreed to take over the work with the draft, but for various reasons it never moved forward.

Recently, there has been some discussions that this would be another use-case for draft-holmberg-sipcore-proxy-features: proxies could add a feature tag to Path, indicating a capability to receive request from both directions using the Path information. The Path could then be used to genereate Service-Route or request route.

Comments?

Regards,

Christer