Hi,
In some scenarios, it happens that a request is received with the following characteristics:
IP xxx.xxx.xxx.xxx:14000 -> server:5060 Via: SIP/2.0/xxx.xxx.xxx.xxx:5060;branch=9hG4bKblah;rport
Normally, we just force_rport() on all incoming requests so that we reply to the real source port of the request, since most endpoints on this installation are NAT'd.
However, occasionally we run into a scenario where an ALG or misconfigured client incorrectly inserts an rport attribute into its topmost Via, and really expects to receive a response at the address/port indicated in the Via (i.e. 5060).
Does Kamailio offer a means of dealing with these on a selective basis? Would refraining from calling force_rport() be enough? Or would it be necessary to set reply_to_via=1 as well, thus breaking symmetrical behaviour for the vast majority of the NAT'd endpoints?
In other words, I'm not 100% clear on the following:
1) What impact does force_rport() have if an 'rport' attribute is sent by the client?
In this case, there should be nothing to "force"; I assume that if the 'rport' attribute is placed by the client, then the proxy will return replies to the source port of the request even if force_rport() is not called, because that's the RFC 3581-compatible thing to do. Right?
2) Does reply_to_via=1 override the behaviour hypothesised in #1?
3) Does reply_to_via=1 override force_rport()?
Thanks!
-- Alex
On Thu, Sep 22, 2016 at 09:58:33AM -0400, Alex Balashov wrote:
Normally, we just force_rport() on all incoming requests so that we reply to the real source port of the request, since most endpoints on this installation are NAT'd.
However, occasionally we run into a scenario where an ALG or misconfigured client incorrectly inserts an rport attribute into its topmost Via, and really expects to receive a response at the address/port indicated in the Via (i.e. 5060).
You can never trust "client" headers/devices IMHO. And I never had problems with force_rport, so logically force_rport overrides anything the "client" sends.
Does Kamailio offer a means of dealing with these on a selective basis? Would refraining from calling force_rport() be enough? Or would it be necessary to set reply_to_via=1 as well, thus breaking symmetrical behaviour for the vast majority of the NAT'd endpoints?
In other words, I'm not 100% clear on the following:
- What impact does force_rport() have if an 'rport' attribute is sent by
the client?
In this case, there should be nothing to "force"; I assume that if the 'rport' attribute is placed by the client, then the proxy will return replies to the source port of the request even if force_rport() is not called, because that's the RFC 3581-compatible thing to do. Right?
force_rport sets the flag FL_FORCE_RPORT, and the helpful comments say the following: * - if the original via contains rport / rport=something or msg->msg_flags * FL_FORCE_RPORT is set (e.g. script force_rport() cmd) rport=src_port * is added (over previous rport / as first via param or after received * if no received was present and received is added too)
and /* check if rport needs to be updated: * - if FL_FORCE_RPORT is set add it (and del. any previous version) * - if via already contains an rport add it and overwrite the previous * rport value if present (if you don't want to overwrite the previous * version remove the comments) */
- Does reply_to_via=1 override the behaviour hypothesised in #1?
- Does reply_to_via=1 override force_rport()?
force_rport seems to override any rport available in via, so reply_to_via has no additional effects.
On 09/22/2016 10:55 AM, Daniel Tryba wrote:
force_rport seems to override any rport available in via, so reply_to_via has no additional effects.
Thanks, that was helpful. But so, if force_rport() is not used, do I need reply_to_via=1 in order to have replies go back to the declared port in the Via rather than the received source port (as would be mandated by the presence of client-injected rport)?
As for trusting client headers, I strongly agree. Unfortunately, sometimes business requirements collide with our philosophies.
Hi Alex, I had the same problem as you and I couldn't find a way to selectively reply to via. What I ended up doing is the following dirty trick... Before a transaction is created for the processed message I do:
if (SOME CONDITION) { remove_hf_value("Via[-1].rport"); msg_apply_changes(); }
For sure it would be better to be able to selectively set the reply_to_via behavior.
Hope this helps.
Cheers,
Federico
On Thu, Sep 22, 2016 at 6:11 PM, Alex Balashov abalashov@evaristesys.com wrote:
On 09/22/2016 10:55 AM, Daniel Tryba wrote:
force_rport seems to override any rport available in via, so reply_to_via
has no additional effects.
Thanks, that was helpful. But so, if force_rport() is not used, do I need reply_to_via=1 in order to have replies go back to the declared port in the Via rather than the received source port (as would be mandated by the presence of client-injected rport)?
As for trusting client headers, I strongly agree. Unfortunately, sometimes business requirements collide with our philosophies.
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-
Alex Balashov -
Daniel Tryba -
Federico Cabiddu