[sr-dev] why new tcp connection?

Iñaki Baz Castillo ibc at aliax.net
Sat Nov 7 01:58:25 CET 2009


El Sábado, 7 de Noviembre de 2009, Juha Heinanen escribió:
> Klaus Darilion writes:
>  > 2. server
>  > I use the pragmatic, and well working UDP approach. Just call
>  > fix_nated_contact/register also for TCP clients. I never had any issues
>  > with that.
> 
> klaus,
> 
> rather than fixing the contact, would it be better to incldue the received
> ip/port info into the rr header that sr is adding?
> 
> reasoning is that when you fix the contact, say, of incoming invite, the
> ack and bye from the callee has incorrect r-uri, i.e., not the original
> contact of the caller.
> 
> if it would be possible to include the received ip/port info into rr
> header, then sr would know where to send the ack/bye and r-uri would be
> the original one.
> 
> this is similar to what fixing register does, i.e., it stores the
> received ip/port in a field of location table, and invite to this uri
> has the original contact.

I totally agree. But adding this info to Record-Route doesn't like to me. Note 
that RR value is mirrored by the UAS in the 18X/200 response, so the proxy 
should replace the value in RR received from the UAS (source address of UAC) 
with the source address of the UAS. This is a bit annoying as it involves 
rewritting a parameter value.

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

So SR could route based on this RURI parameter and keep the original Contact 
as RURI.




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



More information about the sr-dev mailing list