RE: [Sip] Record-Route, Path, Service Route, and Multi-Homed Prox ies

["Dean Willis" <dean.willis@softarmor.com>]

Excellent response. Thanks, George!


> -----Original Message-----
> From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] 
> Sent: Tuesday, October 15, 2002 1:21 PM
> To: 'Dean Willis'; George Foti (LMC); sip@ietf.org
> Subject: RE: [Sip] Record-Route, Path, Service Route, and 
> Multi-Homed Prox ies
> 
> 
> Quoting RFC 3261, step 4 section 16.6 
> 
>          In a similar fashion, a proxy that receives a request
>          over TLS, but generates a request without a SIPS URI in the
>          Request-URI or topmost Route header field value 
> (after the post
>          processing of bullet 6), MUST insert a Record-Route header
>          field that is not a SIPS URI.
> 
>          A proxy at a security perimeter must remain on the perimeter
>          throughout the dialog.
> 
>          If the URI placed in the Record-Route header field 
> needs to be
>          rewritten when it passes back through in a response, the URI
>          MUST be distinct enough to locate at that time.  (The request
>          may spiral through this proxy, resulting in more than one
>          Record-Route header field value being added).  Item 8 of
>          Section 16.7 recommends a mechanism to make the URI
>          sufficiently distinct.
> 
> 
> Doesnt the above imply that if you come in a proxy over TLS 
> and leave without TLS and you RR that you need to rewrite RR 
> coming back in responses.
> 

Or that you have two RR entries -- one sips on the secure side, one sip
on the not-secure side. It's effectively like being dual-homed, even on
a single interface. Good catch, this will need to be made clear.

> 
> 
>  Now quoting the SIGCOMP drafr from Gonzalo revision 01
> 
>  5) Sending a Response to a Client
> 
>    A response is sent to the host in the sent-by parameter of the Via
>    header field. If the topmost Via header field contains the 
> parameter
>    comp=sigcomp, the response SHOULD be compressed. Otherwise, the
>    response MUST NOT be compressed.
> 
>    A proxy performing Record-Route inspects the Record-Route header
>    field in the response and the Contact header field in the request
>    that triggered this response (see example in Section 8). 
> It looks for
>    the URI of the next upstream (closer to the user agent 
> client) hop in
>    the route set. If this URI contains the parameter comp=sigcomp, the
>    proxy SHOULD add comp=sigcomp to its entry in the 
> Record-Route header
>    field. If this URI does not contain the parameter comp=sigcomp, the
>    proxy SHOULD remove comp=sigcomp (if it is present) from 
> its entry in
>    the Record-Route header field.
> 
> The above implies that we may to need to do rewrite of RR in 
> the response.

Hmm. Could this be accounted for by having "in" and "out" RR heaader
field values as proposed for sips and network adaptation? The one on the
compressed side would list sigcomp, the other one wouldn't. Gonzalo,
what do you think?
 
> So how do we deal with all the cases, will a proxy have to 
> include both addresses in the RR as well. It was not clear to 
> me from your initial e-mail on the topic. Rgds/gf

Good catch. On first thought, I THINK all of these cases can be dealt
with the same way -- by listing separate "in" and "out" Record-Route
header field values whenever they're not the same.

Proposed Rule: When a proxy Record-Routes and the route entering the
proxy differs (name, type, or parameters) from the route exiting the
proxy, the proxy should insert a record-route header field value for
each.

Other people probably know more. People?

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip