El Sábado, 7 de Noviembre de 2009, Juha Heinanen escribió:
Klaus Darilion writes:
- 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@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.