[reSIProcate] problem with Record-Route in repro and multiple transports

[Jason Fischl]

Consider this case where useragents are using UDP to talk to their
respective proxies but the proxies are communicating over TLS.

Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
|--------------->| | |
| UDP | INVITE F2 | |
| |--------------->| INVITE F3 |
| | TLS |--------------->|
| | | UDP |
| | | |
| | | 200 F4 |
| | 200 F5 |<---------------|
| |<---------------| UDP |
| 200 F6 | TLS | |
|<---------------| | |
| UDP | | |
| | | |
| ACK F7 | | |
|--------------->| | |
| UDP | | |
| | ACK F8 | |
| |--------------->| |
| | TLS | |
| | | ACK F9 |
| | |--------------->|
| | | UDP |

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20051001/76056701/attachment.htm>