Closed JeffreyVIP closed 3 years ago
Hi, you are using AoR throttling mode 2
, so the mid-registrar won't work with ;ctid=
parameters anymore, since it generates a single, custom Contact to advertise to the downstream registrar.
You can read more info about the available modes in the "mode" modparam docs or general section.
@liviuchircu Thanks for the quick response, but I don't care about contact_id_param module paramter. More important, there is issue when FreeSWITCH makes lookup with the mid-register processed Contact Header. Maybe it is due to double @ character in the Contact Header, one encoded to '%40', another as '@'.
If FreeSWITCH has issues parsing "%40"
(which is perfectly legal, SIP-wise), then try switching the mid-registrar to mode 1
, which will change the advertised contacts. If you aren't doing a lot of parallel forking, you are barely trading off anything by doing so, anyway.
@liviuchircu
FreeSWITCH can parsing "%40", and regards 1020 as directory number and "192.168.20.20@172.31.33.17" as host part, and failed in host DNS resolution, that's the root cause.
Contact: sip:1020%40192.168.20.20@172.31.33.17:5060.
This has been confirmed by tcpdump on FreeSWITCH host, filtering DNS packets.
Unfortunately, we do lots of parallel forking for each extension, desk phone, softphone on PC and mobile phone.
Thanks, understood. I have repackaged this issue into a feature request. Maybe the "%40" should be avoided completely, in favour of something more straight-forward, such as "--"
or "."
.
Thanks, looking forward to the feature request, please merge the patch to v3.1 branch if you can.
The problem that it will break existing systems setup. Our system is rely on on %40. Muliti domain routing is depend on it. If path header properly supplied to freeswitch there no issues with %40. That issue #1109 with transport=udp is resolve the issue. That what we use as work around.
mid_registrar_save("location","p1");
switch ($retcode) {
case 1:
# Work arround for github issue #1109
$avp(path_hdr) = "<" + "sip" + ":" + $fU + "@" + "my ip" + ":" + "5060" + ";" + "transport" + "=" + "udp" + ">";
append_hf("Path: $avp(path_hdr)\r\n");
break;
case 2:
xlog("[MID_REGISTER] [$rm] REGISTER has been absorbed!\n");
break;
default:
xlog("L_ERR", "mid-registrar error!\n");
send_reply(500, "Server Internal Error 2");
}
# Validating if user actually saved in db
if(is_registered("location",$fu)) {
xlog("User has bening saved in db dumping saved messages");
route(MSG_DUMP);
}
@volga629-1 the fix is almost ready. When backported to 3.1
, maybe one idea is to change the default value of the "@"
escaping sequence to %40
, so existing systems are unaffected. Starting from 3.2
, the default will be ___
(tripple underscore).
That will be huge script overhaul for 3.2 with triple under scores
I'm not sure I completely follow. So you have some kind of route
which tells you that a R-URI username received from FreeSWITCH is a mid-registrar advertised contact (in reality, the softphone-side AoR, but hex-encoded) or not?
Yes you correct, all contact headers toward freeswitch is encoded with %40 format like this Also script contain places where we test against %40 to accommodate proper routing.
OPTIONS sip:9999%40mydomain@opensips_ip:5060 SIP/2.0
Routing example
if($rU=~"%40") {
$var(store_hash) = "data_set";
$var(user) = $(rU{s.select,0,%});
$var(domain) = $(rU{s.select,1,%}{s.substr,2,0});
$var(store_key) = "ua" + "_" + $var(user) + "_" + $var(domain);
cache_raw_query("redis:ua-trns-grp","HGET $var(store_hash) $var(store_key)","$avp(ua_orig_trns)");
Ok, so starting from 3.2
, you will have to change "___"
back to "%40"
, using the following setting:
modparam("mid_registrar", "at_escape_str", "%40")
I think it's more than fine! And this way, we gain flexibility when interop'ing with all kinds of main-registrar software.
Ok great that doable, thank you for clarification. I will add to our config as comment.
Hi, folks!
The at_escape_str
mid-registrar modparam is now available on master
and I've silently backported it to 3.1
as well, to help everyone having these integration issues with other software.
So @volga629-1: there is no need to change anything, the default value is best to remain %40
, since the backend should NOT canonicalize the Contact URI and de-escape it (there is no RFC mention of this procedure).
And, for @JeffreyVIP: please update to latest 3.1
and set the at_escape_str
to whatever string you see fit for your system. The problem should go away after doing so.
If you run into any problems, please re-open the issue. Cheers!
Hi Team
Git commit id: 3f58031efb18a995ac1b660abf295a47338b1b63, latest v3.1 branch.
It seems contact header is wrongly handled in mid_register module, and contact_id_param module parameter has no effect.
Original: Contact: "Jeff" sip:1020@192.168.254.190:59962;transport=TCP;ob;reg-id=1;+sip.instance="".
Processed: Contact: sip:1020%40192.168.20.20@172.31.33.17:5060.
is it about @ character encoding to %40 ?
Full original registrer request:
mid_register module output registrer request: