Re: [repro-devel] Repro and Record Routing
Ok, I'll try and get that merged in sometime next week. I'll need to give it one more inspection to make sure we're up to date with outbound-11.
Best regards, Byron Campen 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 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)
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. 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. _______________________________________________
|
Attachment:
smime.p7s
Description: S/MIME cryptographic signature