Subject: Re: [sipcore] SigComp and Service-Route

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 May 2010 21:51:24 +0200

Hi,

Any comments on this? It is going to be discussed at the 3GPP meeting next week, so some guidance from the WG would be useful, I think.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Christer Holmberg [[email-masked]]
Sent: Thursday, April 29, 2010 8:37 PM
To: SIPCORE
Subject: [sipcore] SigComp and Service-Route

Hi,

I appologize if the following issue have been discussed and solved before.

When reading RFC 5049 (Sigcomp), the UA figures out whether the outbound
proxy supports sigcomp by looking at outbound proxie's entry in the
Service-Route in the REGISTER response.

My questions are:

1. How can the UA ensure that the outbound proxy will be listed in the
Service-Route in the first place? RFC 3608 (Service-Route) does not
mandate the registrar to insert any intermediaries in the Service-Route,
e.g based on Path. It's all based on local policy.

2. Even if the registrar would build the Service-Route based on Path,
how does it know that the Path address/port values will be
usable/routable in the UA-towards-registrar direction (Path is supposed
to be used in the registrar-towards-UA direction)? This is similar to
the Record-Route problem, and intermediaries with different network
addresses/ports per direction would have to insert "double Path".

I guess the outbound proxy could insert itself in the Service-Route, but
that is not described anywhere in RFC 5049, and it is also a SHOULD NOT
in RFC 3608.

Regards,

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

---

From: Adam Roach <[email-masked]>
Date: Thu, 13 May 2010 10:33:15 -0500

Christer:

Sorry for the slow response. Some responses inline.

> e.g based on Path. It's all based on local policy.

Service-Route is the means by which the network conveys the proxies that 
the UA needs to use when accessing the network. I think there's an 
assumption in certain networks -- like IMS -- that the registrar will, 
as a matter of policy, copy the Path into the Service-Route.

Strictly speaking, though, even that's not necessary for the UA to 
ensure traversal of a specific first-hop proxy. Service-Route specifies 
a minimal set of proxies to be traversed, not an exhaustive and 
restrictive set of proxies. There is nothing in the Service-Route 
mechanism that prevents the UA from inserting a specific outbound proxy 
in all of its requests.

So, trivially, if the UA discovers that a SigComp-supporting proxy isn't 
the first hop in the Service-Route returned by the network, it makes a 
local decision to send all requests through one that does. (Recall that 
support of SigComp by the first proxy in the Service-Route set can be 
determined by casual inspection: if the URL has a ";comp=sigcomp" 
parameter, it supports SigComp; otherwise, it does not.)

> addresses/ports per direction would have to insert "double Path".

If this mechanism is used, and if the outbound proxy presents different 
address spaces towards the UA than it does towards the registrar, then 
the outbound proxy will need to take some extraordinary measures to 
ensure that everything works smoothly. Inserting a "Double-Path" would 
be one approach.

> that is not described anywhere in RFC 5049, and it is also a SHOULD NOT

That approach is congruent to the "change the Record-Route" mechanism 
that 3261 originally described for multihomed proxies. If you'll recall, 
we determined this approach to be problematic enough that we issued a 
correction -- RFC5658 -- that basically says "don't do that."

If you're operating in a network that, as a matter of policy, reflects 
the Path back in a Service-Route, then I think the "Double-Path" 
approach is really what you want to do for multi-homed outbound proxies. 
And, even if you're not, doing a "Double-Path" doesn't cause any issues.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 May 2010 14:46:54 +0200

Hi Adam, 

>>1. How can the UA ensure that the outbound proxy will be 
>>listed in the Service-Route in the first place? RFC 3608 (Service-Route) does not 
>>mandate the registrar to insert any intermediaries in the 
>>Service-Route, e.g based on Path. It's all based on local policy.    
> 
>Service-Route is the means by which the network conveys the 
>proxies that the UA needs to use when accessing the network. 
>I think there's an assumption in certain networks -- like IMS 
>-- that the registrar will, as a matter of policy, copy the 
>Path into the Service-Route.

That is not correct - at least not for IMS.

Especially in roaming scenarios, where the P-CSCF (outbound proxy) and S-CSCF (registrar) are in different networks, no such assumption can be made.

>Strictly speaking, though, even that's not necessary for the 
>UA to ensure traversal of a specific first-hop proxy. 
>Service-Route specifies a minimal set of proxies to be 
>traversed, not an exhaustive and restrictive set of proxies. 
>There is nothing in the Service-Route mechanism that prevents 
>the UA from inserting a specific outbound proxy in all of its 
>requests.

Correct. An IMS UE for example inserts a P-CSCF (the network may also insert IBCFs) in its requests no matter what the Service-Route contains.

But, the problem is that the UE would need to get a Service-Route including the P-CSCF, in order to get the "comp" parameter.

>So, trivially, if the UA discovers that a SigComp-supporting 
>proxy isn't the first hop in the Service-Route returned by 
>the network, it makes a local decision to send all requests 
>through one that does. (Recall that support of SigComp by the 
>first proxy in the Service-Route set can be determined by 
>casual inspection: if the URL has a ";comp=sigcomp" 

Correct. The problem is that so far the P-CSCF is unable to get ";comp=sigcomp" inserted into the Service-Route, since the P-CSCF cannot be sure that the S-CSCF will insert it.

>>usable/routable in the UA-towards-registrar direction (Path is 
>>supposed to be used in the registrar-towards-UA direction)? This is 
>>similar to the Record-Route problem, and intermediaries 
>>with different network addresses/ports per direction would have to insert 
>>"double Path".
>>    
> 
>If this mechanism is used, and if the outbound proxy presents 
>different address spaces towards the UA than it does towards 
>the registrar, then the outbound proxy will need to take some 
>extraordinary measures to ensure that everything works 
>smoothly. Inserting a "Double-Path" would be one approach.
>
>>I guess the outbound proxy could insert itself in the Service-Route, 
>>but that is not described anywhere in RFC 5049, and it is also a 
>>SHOULD NOT in RFC 3608.
>>    
> 
>That approach is congruent to the "change the Record-Route" 
>mechanism that 3261 originally described for multihomed 
>proxies. If you'll recall, we determined this approach to be 
>problematic enough that we issued a correction -- RFC5658 -- 
>that basically says "don't do that."
> 
>If you're operating in a network that, as a matter of policy, 
>reflects the Path back in a Service-Route, then I think the 
>"Double-Path" approach is really what you want to do for multi-homed 
>outbound proxies. 

Yes. The problem is that the registrar would need to know that the P-CSCF (and and any other intermediate inserting Path) has used "Double-Path", in order to "safely" building the Service-Route based on the path. It may be possible to configure within a single network, but more difficult in roaming scenarios.

Some years ago, Jonathan worked on a draft which was related to this:

http://tools.ietf.org/id/draft-rosenberg-sip-route-construct-02.txt

He did not have time to continue, and said I could take it over if I want to, but I never did it either.

Regards,

Christer