[kamailio/kamailio] set_contact_alias() issue with clients adding it to their Contact (#2308)
I'm using set_contact_alias() to fix nat registrations, in this case with a Bria client. Somehow Bria learns that I'm using this - probably through the Contact in the 200 OK reply of save(). Bria then adds this to the Contact when replying to incoming INVITE.
After some time, something happens in the network at client side and the connection gets a new port through the router. Bria does not notice and still sends the old alias-parameter with the port not used anymore. When I'm calling handle_ruri_alias(), Kamailio reads this instead of the actual port and the ACK to 200 OK is sent to a port not used anymore.
This can probably be solved by either, in preferred order: - rewrite set_contact_alias() and add_contact_alias() to replace existing alias parameters - regexp remove of alias parameter from Contact of all messages coming from clients - regexp remove of alias parameter from Contact returned by save()
Br, Morten
set_contact_alias() should not be used for registrations, but for requests that are typically forwarded. If you do it on an edge proxy between device and registrar server, then you should use path module and leave the contact unchanged.
If you use it in the registrar server config, then you should replace it with fix_nated_register(), like in the default kamailio.cfg.
Otherwise, if you really want to use it, then in case you have to deal with such UA, then yes, you will have to remove (or replace) the alias parameter in Contact. Probably you can play with the replace/subst functions from textops and if you can't get it, then new C code has to be added. A pull request is of course appreciated.
Thank you for your reply.
Does the manual somewhere state that set_contact_alias() should not be used for REGISTER? Actually, some examples suggest using this instead of fix_nated_contact() - http://www.evaristesys.com/blog/server-side-nat-traversal-with-kamailio-the-...
The reason for using set_contact_alias() instead of fix_nated_contact() is that one client seemed to have an issue with the contact being changed.
I'm actually using in on an edge proxy and already using Path, but I guess I missed setting this on the edge: modparam("path", "use_received", 1)
Fixed it already temp with a subst on the reply for REGISTERs, as you wrote.
Would you please share how you fixed it with subst?
All done on edge proxy. I'm not a regex-pro. It will not work if done locally on the registrar (the node doing the save()).
https://gist.github.com/mtryfoss/9a0811dbc4462b91afe87d7dd5a210e8
@mtryfoss - the set_contact_alias() is indeed for use instead of fix_nated_contact(). But fix_nated_contact() is not for REGISTER, for it the fix_nated_register() should be used. However, fix_nated_register() has to be used only if the registrar server is next to the nat router. If registrar is behind an edge proxy (SBC), the it should work without touching the contact and using the Path module (with `use_received` indeed).
Now, as you noticed, set_contact_alias() may work also for REGISTER, but some UAs don't like it (or use it inappropriately). You are more than welcome to make a pull request to the docs of this function to explain better its purpose based on your experiences.
@mtryfoss: regarding the subst, probably it does the job with ipv4, however in regexp `.` is matching any char, if you want to restrict it to match `.` as a char, one way is to enclose it inside square brackets, like:
``` subst("/;alias=[0-9]+[.][0-9]+[.][0-9]+[.][0-9]+~[0-9]+~[0-9]+//g"); ```
Going to close this one, solutions being found. If someone wants to make a pull request adding a function to cope with this specific case, it is more than welcome!
Closed #2308.
curious on this topic- we use `set_contact_alias()`on our SIP REGISTERs/INVITEs because we can't use the received parameter. we can't use the received parameter because our registrars are setup to accept traffic from two sets of edge proxies. one set of proxies supports the received param, the other set of proxies does not support the received param due to different network conditions. but in any case, our setup works great, `handle_ruri_alias()` should be stripping the contact alias before it reaches the UAC and your edge proxy should be adding the contact alias on each request from the UAC. im wondering if you can share more of your config with me so i can understand how this is happening.
handle_ruri_alias() only handle alias in Request-URI, not the Contact returned by the registrar for REGISTER.
For most phone clients this is not a problem but Bria used that info in subsequent requests. So, when the proxy again doing set_contact_alias() on an INVITE from Bria (already containing an alias), you'll end up with two alias parameters. One of them might be outdated if port/source-ip has changed through NAT since initial registration.
When proxy then calls handle_ruri_alias() the first parameter is handled and removed, and you'll send the one which the proxy actually added back to the client. The ip/port used in the reply might be wrong if the alias Bria added is outdated.
ohhh i understand now. I believe `set_contact_alias()` should _overwrite_ any previous contact alias on the request. have you tried on 5.3 latest? perhaps this should be a setting in nathelper as it would make sense to overwrite it in some cases like this
I've only been testing 5.3.3. Of course, the alias should probably be replaced if it exists rather than append one more without the need for a specific setting/parameter.
I'm not that into Kamailio source and did not have time to get going there when I found the issue, so I fixed it quickly by a regexp replace.
Master branch (upcoming 5.4.0) has now a function to remove parameters from Contact header URI (see siputils module).
https://github.com/kamailio/kamailio/compare/nathelper-set_contact_alias-tri... @mtryfoss i've added support for trimming an already existing alias. I've tested it locally and it works- but can you please test it in your setup? just call the function with "1" param like so `set_contact_alias("1");`
Thanks!
I've lost my staging environment temporarily because of some physical re-location of our servers. I will try to test it when I'm returning from vacation.
-
Daniel-Constantin Mierla -
Emmanuel Schmidbauer
-
mtryfoss
-
pafels