[sr-dev] why new tcp connection?

[Juha Heinanen]

Iñaki Baz Castillo writes:

 > AFAIK $du is never (until now I mean) set when processing an
 > in-dialog request 
 > as we rely on previous modifications performed on Contact URI address.
 > With this proposal it would be required that during in-dialog processing the 
 > $du would be set with the value of ";received" param in RURI.

yes.

 > Of course this param just exist in case of a NATted client so dealing
 > manually with it means:

why only nated?  this whole thread started as why two tcp connections
are needed to an ua.  so the parameter would also be added when request
arrives from non-nated tcp ua so that future requests on this dialog
back to ua could be made to use the existing tcp connection.

one thing to note is that the parameter needs to be added also to
in-dialog requests that have contact header.

 > I would prefer a new nathelper exported function:
 > 
 > "nat_check_received()"
 > 
 > If ";received" param exists it set $du and returns 1.
 > If not, $du is not set and returns 0.

i would prefer to leave setting if du to the script.  it is not a good
idea to embed too much functionality to functions.  so there should be a
function or transformation to remove extract and remove the received
parameter in addition of one that inserts the received parameter.

 > However I would like to check how it works in this scenario:
 > 
 >   UA1 --(NAT)-- Proxy1 ----- Proxy2 --(NAT)-- UA2
 > 
 > 
 > - UA1 sends INVITE (private address in headers).
 > 
 > - Proxy1 adds ";received" to Contact URI"
 >   Contact: <sip:ua1 at PRIVATE_UA1;received=PUBLIC_UA1>
 > 
 > - Proxy 2 checks NAT. It shouldn't inspect the Contact URI !!! or if so, it 
 > should also take into account the existance of "received" param!!! (first 
 > problem). If not, Proxy2 would also add its own ";received" param:
 >   Contact: <sip:ua1 at PRIVATE_UA1;received=PUBLIC_UA1;received=PROXY1>

i don't see a problem here.  proxy should only check nat on requests
that it receives from UAs, not from other proxies, because it should be
other proxies' job to take care of their own UAs.

-- juha