Re: [reSIProcate] problem with Record-Route in repro and multiple transports
Inline.
On Saturday 01 October 2005 19:39, Jason Fischl wrote:
> Consider this case where useragents are using UDP to talk to their
> respective proxies but the proxies are communicating over TLS.
>
[...]
>
> 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.
I would prefer the second solution. Allthough I do not have a real reason.
But who fills the Via header? At the same level the RR should be filled.
> 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.
There is a third possible solution.
> 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.
3) Insert two RR headers. The first RR header is filled with the
host/port/transport from where the request was received. The second header is
left with the unknown fields, which will be filled later (solution 2 from
above). If the same tripple is used when sending the request, the second RR
header can be removed.
Otherwise the outgoing request will contain two RR headers with different
triplets. This has the advantage that it can be handled stateless for all
future replies and mid-dialog requests, and it also works easily with
multiple network interfaces (e.g. in different networks).
Nils