| Looks to me like the most same-spirit and portable solution is to have the TS fill in the fields. I think using a FQDN will reduce our interoperability with systems that don't quite get TLS. I also think there is still some hand-waving to get the FQDN solution to 'just work', no?
Alan On 1-Oct-05, at 13:39 , Jason Fischl wrote: Alice <-> Proxy 1 - over UDP
Proxy 1 <-> Proxy 2 - over TLS
Proxy 2 <-> Bob - over UDP
The problem occurs because at the time that repro inserts its Record-Route
header it does not know which transport will be used by the resip stack to send
to Bob. In fact this can change as a result of failures with no communication
back to repro (the TU). I see a few possibilities:
1) Have repro insert a FQDN for outbound requests in the Record-Route
header. Which FQDN to use may need to be decided based on how the next hop was
determined.
2) Allow repro to leave the host/port/transport unspecified in the Record-Route
and let the TransportSelector in the stack decide what to insert based on which
transport was actually used. This could change within a single transaction if
the transport changes due to failures.
There is a second problem related to the opposite direction. A different
Record-Route header needs to be used in the 200 response (F5) than in the INVITE
(F2) since the hop from Proxy 1 to Proxy 2 needs to use TLS. Again, there are
two possible solutions that come to mind.
1) Have repro modify the FQDN in the 200 (F5) to insert a different FQDN than
was used in INVITE (F3). This one should resolve to use TLS instead of UDP.
2) Have repro mark the Record-Route in 200 (F5) such that it will be filled in
by the stack's TransportSelector based on the actual transport used.
|