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

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 10 Nov 2010 04:11:45 -0500

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Christer Holmberg [[email-masked]]

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

It seems to me that no manipulation of the Path header (as seen by the registrar) is useful for solving the problem of building a suitable Service-Route.

There are two cases:  In the first case, the registrar, if it receives an INVITE (for example) is capable of processing it correctly or sending it to some element that can.  In this case, the UA does not need a Service-Route, as it can send the INVITE by the same mechanism that it used to send the REGISTER.

In the second case, where the INVITE must be routed to a different element than the REGISTER, the incoming Path value seen by the registrar is not useful for constructing a suitable Service-Route, because the Path values describe how a request is routed to the registrar, not the service proxy.

Knowing that the Path can be used in the UA-to-registrar direction (as well as the registrar-to-UA direction) tells the UA something that it *already knows*, viz., how to get requests to the registrar.

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 10 Nov 2010 05:42:04 -0500

I think this is somewhat similar to a problem I posed to Christer privately about the proxy-feature draft: "proxies" don't do the same features on all their "sides".  For example, let's assume there was a feature tag for privacy anonymization.  A proxy doesn't always do anonymization for all SIP requests regardless of where they came from - it may only do them for requests being sent out of their domain.  Or another example is a proxy performing location insertion for emergency calls - it only does this for calls from the UA, not for calls to the UA.  Same with call-continuity.  Same with IMS AKA.  Same with SRTP.  Same with outbound.  Same with a lot of "features".  Even in 3gpp, think of all the rules that are split into "terminating" vs. "originating" modes.

So when putting feature tags into a Register's Path header, my concern was that Path was the Proxy->Registrar direction, and it would have to put the features it can perform on that "side" for requests received on that side.  So a UA getting that back will find out stuff that it can't actually use, and not find out stuff it can use.

But I think there're two possible solutions, which also happen to solve the Service-Route problem:
1) We allow a proxy to *insert* a Service-Route in the Register request, with the address of the side facing the UA it received the Register on; and we have the Registrar take this list of received Service-Routes and use it in the Service-Route list it returns in the Register response (plus whatever other ones it needs to).  The UA will thus get this list back, which represent the proxy direction it can actually use.

OR...

2) The proxy inserts a Path header, but is allowed to change its Path header URI (and feature tags) when it sees its own Path/Service-Route header in the Register response, to be its other side/features.

Option 1 is more proxy-ish.  Option 2 is what some SBCs do today and works.  I think option-1 is the more right thing to do, from a purity perspective.

I can write up an I-D on this if people like it - option-1 would update rfc3608, option-2 would update rfc3327.

-hadriel

On Nov 10, 2010, at 4:11 AM, Worley, Dale R (Dale) wrote:

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore