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

[Christer Holmberg <[e-mail]>]

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