[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.
> 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
Iñaki Baz Castillo <ibc at aliax.net>
More information about the sr-dev