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

["George Foti (LMC)" <George.Foti@ericsson.ca>]

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 yyou need to rewrite RR coming back in
responses.





 Now quoting the SIGCOMP drafr from Gonzala 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.

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
 



> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: Tuesday, October 15, 2002 1:56 PM
> To: 'George Foti (LMC)'; sip@ietf.org
> Subject: RE: [Sip] Record-Route, Path, Service Route, and Multi-Homed
> Prox ies
> 
> 
> 
> > 
> > So what if we needed to do a re-write for SIGCOMP reasons, or 
> > SIP/SIPS reasons. It seems that regarding RR is unavoidable. Rgds/gf
> > 
> 
> Perhaps. Could you make the examples more obvious. I'm apparently
> suffering from a clue deficiency this morning.
> 
> You need to change the record-route header field in response 
> processing
> to allow sigcomp? I would think one might compress the R-R like all
> (other header fields) but I'm currently not cognizant of a situation
> where it would need to be semantically analyzed and changed . . . Of
> course I may just not be particularly cognizant at the 
> moment, if ever.
> 
> --
> 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