[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