Hi Bobby,
what you could do is to store into "fixed" contact the original IP and
port, so that you can restore he original contact in sequential requests.
like you received sip:foo@ip_1:port_1 -> fixing to
sip:foo@ip_2:port_2;xip=ip_1;xport=ip_1
See:
http://www.opensips.org/html/docs/modules/1.7.x/nathelper.html#id250346
(take a look at params)
and when you receive an RURI like
sip:foo@ip_2:port_2;xip=ip_1;xport=ip_1 you move current IP and port
into DURI and upload xip and xport into URI.
Regards,
Bogdan
On 08/19/2011 07:28 AM, Bobby Smith wrote:
All,
Setup is this:
Softswitch --> OpenSIPS Proxy/Registrar --> UAC
INVITE sip:username@uac_ip:port is sent to uac via lookup on the
location table:
---> INVITE sip:[email protected]:5063 <http://sip:[email protected]:5063> (but
destination port from UA's contact is really 7063).
R-R us
Contact: <sip:did@softswitchip:port>
<-------- 200 OK
via them
Contact: <sip:[email protected]:5063 <http://sip:[email protected]:5063>>, which
is rewritten to sip:[email protected]:7063 <http://sip:[email protected]:7063>
because of fix_nated_contact called
-----------> ACK sip:[email protected]:7063 <http://sip:[email protected]: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:[email protected]:5073 <http://sip:[email protected]:5073>
ruri = sip:[email protected]:5063 <http://sip:[email protected]: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
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 19th of September 2011
OpenSIPS solutions and "know-how"
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
