[OpenSIPS-Users] Issues with RURI port VS contact port when ACK is relayed back to UA

[Bobby Smith]

All,

Setup is this:

Softswitch --> OpenSIPS Proxy/Registrar --> UAC

INVITE sip:username at uac_ip:port is sent to uac via lookup on the location
table:

---> INVITE sip:user at foo.com:5063 (but destination port from UA's contact is
really 7063).
R-R us
Contact:  <sip:did at softswitchip:port>

<--------  200 OK
via them
Contact: <sip:user at foo.com:5063>, which is rewritten to
sip:user at foh.com:7063 because of fix_nated_contact called


-----------> ACK sip:user at bar.com:7063 (sent to ua at 7063).
              R-R us

The problem is the UAC tosses out the request because it doesn't match it as
the RURI port is wrong, even though it was sent to the right place.

My question is:

If I call loose route on this without fixing up the IP, it would be relayed
to the private_ip:port pair of the UA.
If I do another lookup, the RURI is preserved with the port 7063 but sent to
the right place (in this case 7063, but the request is thrown out).

What I want to achieve is on the ACK:

duri = sip:user at bar.com:5073
ruri = sip:user at foo.com:5063


The initial INVITE packet has the correct duri/ruri combo, but because I
call fix_nated_contact, the softswitch rewrites the RURI (as it's supposed
to) with the Contact Header info, and opensips relays this back to the UAC
with that information.

Is there a simple convention to set the duri to be the correct destination
via lr or via doing another location lookup (hackish I guess, but even this
doesn't work for me), while preserving the RURI on the initial invite?  If i
don't rewrite the contact header, the packet is relayed back to the private
IP and seems to break NAT.

If I do another user lookup, the ruri is rewritten.  This is a phone that
doesn't exactly support RFC 3261 (a Cisco 79XX with SIP 8.0 firmware), and
doesn't support received processing.


Thanks,
BobbyS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110819/5bb5c03c/attachment-0001.htm>