reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [repro-devel] Repro and Record Routing

Well the current code is not trying to double record route at all…

 

I vote for merging your branch into main – especially since it was tested at SIPit.

 

Scott

 

From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx]
Sent: Friday, November 23, 2007 12:52 AM
To: Scott Godin
Cc: repro-devel@xxxxxxxxxxxxxxx
Subject: Re: [repro-devel] Repro and Record Routing

 

          I think this is the first of a double record-route, or at least is intended to be. I do agree that using the transport param is not optimal here. Would anyone object if I merged the code from b-Outbound into main? (I finally got a chance to test it at SIPit, and it is much better about Record-Routing properly)

 

Best regards,

Byron Campen



Repro is behaving rather strangely when receiving requests over TCP (or TLS) and forwarding on to a UDP endpoint, when using Record Routing.

 

There is code in response context to add a transport=tcp paraemter to the Record-Route header if the inbound request was received over tcp (the same is true for TLS).  I don't think this behaviour is correct.  I would like to modify repro so that it never automatically adds a transport parameter to the record-route header, based on the following recommendations below from RFC361.  If the user that started repro put a tranport parameter into the -r command line switch (for whatever reason), then it will be used in the Record-route header.

 

Can anyone see any issues with this?

 

Note:  There is also code in the stack (TransportSelector) to do this - that should probably also be cleaned up - however for repro itself this code is superceeded by the record-route logic in repro.

 

Scott

 

 

The URI placed in the Record-Route header field value MUST be a
         SIP or SIPS URI.  This URI MUST contain an lr parameter (see
         Section 19.1.1).  This URI MAY be different for each
         destination the request is forwarded to.  The URI SHOULD NOT
         contain the transport parameter unless the proxy has knowledge
         (such as in a private network) that the next downstream element
         that will be in the path of subsequent requests supports that
         transport.

         The URI this proxy provides will be used by some other element
         to make a routing decision.  This proxy, in general, has no way
         of knowing the capabilities of that element, so it must
         restrict itself to the mandatory elements of a SIP
         implementation: SIP URIs and either the TCP or UDP transports.

_______________________________________________

repro-devel mailing list