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