[reSIProcate] problem with Record-Route in repro and multiple transports
Alan Hawrylyshen
alan at jasomi.com
Sat Oct 1 15:26:04 CDT 2005
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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20051001/687fbe15/attachment.htm>
More information about the resiprocate-devel
mailing list