[sr-dev] why new tcp connection?

[Iñaki Baz Castillo]

El Sábado, 7 de Noviembre de 2009, Juha Heinanen escribió:
> 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)?

It would be great. However I would like to ensure that no broken UA outthere 
would remove the Contact URI params when generating an in-dialog request. I 
expect this doesn't occur as it's the same behavior as when using SIP TCP 
(UA's Contact URI has ";transport=tcp" and this param is present in RURI of 
in-dialog request from UAS). It should work :)


>  > 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.

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.

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

- Extract the RURI ";received" param.
- If it exists then set $du with it.
- If not leave $du unset.

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.



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>


Hummm, so perhaps playing with Record-Route wourl be better as each RR is just 
inspected by the proxy adding it...

Comments?


-- 
Iñaki Baz Castillo <ibc at aliax.net>