7 Nov
2009
7 Nov
'09
6:28 a.m.
El Sábado, 7 de Noviembre de 2009, Juha Heinanen escribió:
Klaus Darilion writes:
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@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(a)aliax.net>
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.