nathelper: port add_contact_alias() and handle_ruri_alias() #3769
Conversation
|
Any updates here? No progress has been made in the last 30 days, marking as stale. |
Those are slightly better version of the fix_nated_contact()
originating from Kamailio.
The problem with fix_nated_contact() is that it could cause
RURI for in-dialog requests contain a different IP address as
compared to the Contact in the initial INVITE.
Most endpoints are fine with that, however tere are some,
notably MS Teams, which would reject such request with:
SIP/2.0 500 Internal Server Error
Reason: Q.850;cause=47;text="76a7afc3-d033-4988-9000-f70b41e4db1b;RURI in request has invalid FQDN value"
The full exchange when using fix_nated_contact() is as follows:
UA->OpenSIPS (initial INVITE):
opensips[42757]: RECEIVED message from 10.2.80.32:5060:
INVITE sip:[...]
Contact: <sip:[...]@10.2.80.22:5060>
^^^^^^^^^^
OpenSIPS->UA:
SIP/2.0 100 Giving it a try
SIP/2.0 200 OK
UA->OpenSIPS:
ACK sip:[...]
OpenSIPS->UA (re-INVITE):
opensips[42759]: SENDING message to 10.2.80.32:5060:
INVITE sip:[...]@10.2.80.32:5060 SIP/2.0
^^^^^^^^^^
UA->OpenSIPS:
SIP/2.0 500 Internal Server Error
sobomax
force-pushed
the
pr_contact_alias
branch
from
931b356 to
13b7504
Compare
|
Hi @sobomax , thanks for the contribution here. Here are some first thoughts:
The benefit of these new functions is (as far as I can understand) to simplify a bit the scripting IF you do NOT WANT to use dialog support. Otherwise, it may complicate even more the scripting, as the user has to use more functions. Maybe we can add a new flag to fix_nated_contact(), in order to add this new param ? And we can use the "maddr" param (standard) which is automatically recognized by OpenSIPS (in routing RURI) for overriding the actual RURI domain/port |
|
I might have said something wrong in the above comment - the |
|
Hey @bogdan-iancu thanks for a review. Well to answer some of your remarks:
Bottom line this works and solves our (and probably someone else's problems). Last but not least is that we have already started deploying it into production, so some quite non-negligible effort went into validation and testing. Wholistically at this stage of SIP vs NAT it's clear to me that there will be no "one fits all" NAT handling logic, so this mechanism in my view is another useful tool in that growing toolbox. If someone comes up next week with a more elegant solution using RR or anything else not involving switching into a full dialog-stateful mode we might be interested to test that. But I cannot promise even that, let alone reworking and re-testing already perfectly functional solution. Thanks for understanding. |
2 participants
Summary
Port
add_contact_alias()andhandle_ruri_alias()functionsDetails
Those are slightly better version of the
fix_nated_contact()originating from Kamailio.The problem with
fix_nated_contact()is that it could cause RURI for in-dialog requests contain a different IP address as compared to the Contact in the initial INVITE.Most endpoints are fine with that, however tere are some, notably MS Teams, which would reject such request with:
The full exchange when using
fix_nated_contact()is as follows:UA->OpenSIPS (initial INVITE):
OpenSIPS->UA:
UA->OpenSIPS:
OpenSIPS->UA (re-INVITE):
UA->OpenSIPS:
Solution
Use
add_contact_alias()in the INVITE/200 OK paths andhandle_ruri_alias()in in-dialog request path.UA->OpenSIPS (initial INVITE):
OpenSIPS->UA:
OpenSIPS->B2BUA (initial INVITE):
B2BUA->OpenSIPS (re-INVITE):
OpenSIPS->UA (re-INVITE):
Compatibility
Should not be any if used correctly. Special test case for the voiptests has been created and will be enabled once the change is merged into the opensips/master.