[sr-dev] why new tcp connection?

[Andrei Pelinescu-Onciul]

On Nov 07, 2009 at 08:38, Juha Heinanen <jh at tutpro.com> wrote:
> I?aki Baz Castillo writes:
> 
>  > I would suggest to add a ";received=SOURCE_IP:SOURCE_PORT" to the
>  > Contact URI (not to the header). In this way the in-dialog requests
>  > from the caller/callee would look like:
>  > 
>  >   BYE
>  >   sip:alice at PRIVATE_IP:PRIVATE_PORT;received=SOURCE_IP:SOURCE_PORT
>  >   SIP/2.0
> 
> inaki,
> 
> sound ok to me.  if other people don't find any problems with this,
> should we write a new version of fix_nated_contact that adds the param
> to contact uri or just try to use existing scripting means (remove
> contact hf, add a new modified one)?

fix_nated_register() does just that in nathelper(s): it adds
 a received="uri" parameter to the contacts of a REGISTER, where uri
 looks like:
 sip:src_ip:src_port;[transport=...;]dstip=local_ip:local_port .

We would only need to change the function name from fix_nated_register()
to fix_contacts().

> 
>  > So SR could route based on this RURI parameter and keep the original
>  > Contact as RURI.
> 
> i haven't checked if it would be possible to do that in the script
> (extract and remove received param from r-uri and set $du) or would a
> new function need to be written for that too.

I have somewhere a function that does just that (using the above
format). I used it a long time ago for load balancing (IIRC lb added
received="..." to nated contacts when forwarding to the proxies behind
it and removed "received" from r-uri, set the proper send socket based
on dstip and the destination based on the received=uri when forwarding a
message from a proxy to the outside world).
I can create a new module for it (if it's  not already in one of them).


Andrei