mid-registrar: Ability to customize the "%40" string in "AoR throttling" mode

[JeffreyVIP]

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.

loadmodule "mid_registrar.so"
modparam("mid_registrar", "mode", 2) /* 0 = mirror / 1 = ct / 2 = AoR */
modparam("mid_registrar", "outgoing_expires", 7200)
modparam("mid_registrar", "contact_id_param", "ctid")
modparam("mid_registrar", "tcp_persistent_flag", "TCP_PERSIST_REGISTRATIONS")

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:

T 192.168.254.190:59962 -> 172.31.33.17:5060 [AP]
REGISTER sip:192.168.20.20;transport=tcp SIP/2.0.
Via: SIP/2.0/TCP 192.168.254.190:59962;rport;branch=z9hG4bKPjvIj7Ea8qFnT0RjefphVVn2w459Lt6lqP;alias.
Route: <sip:172.31.33.17;transport=tcp;lr>.
Max-Forwards: 70.
From: "Jeff" <sip:1020@192.168.20.20>;tag=eO9dhGB3bAn1.mnH0Behh7E9M7iLCHXN.
To: "Jeff" <sip:1020@192.168.20.20>.
Call-ID: g6e8DJ7O-I2ui7sjraO6jNqkJaxY091H.
CSeq: 13151 REGISTER.
User-Agent: Telephone 1.5.2.
Supported: outbound, path.
Contact: "Jeff" <sip:1020@192.168.254.190:59962;transport=TCP;ob>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000c9e85e7b>".
Expires: 300.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS.
Content-Length:  0.

mid_register module output registrer request:

U 172.31.33.17:5060 -> 192.168.20.20:5060
REGISTER sip:192.168.20.20:5060 SIP/2.0.
Via: SIP/2.0/UDP 172.31.33.17:5060;branch=z9hG4bK0aba.d56f73e.0;i=a17b8884.
Via: SIP/2.0/TCP 192.168.254.190:59962;received=192.168.254.190;rport=59962;branch=z9hG4bKPjvIj7Ea8qFnT0RjefphVVn2w459Lt6lqP;alias.
Max-Forwards: 69.
From: "Jeff" <sip:1020@192.168.20.20>;tag=eO9dhGB3bAn1.mnH0Behh7E9M7iLCHXN.
To: "Jeff" <sip:1020@192.168.20.20>.
Call-ID: g6e8DJ7O-I2ui7sjraO6jNqkJaxY091H.
CSeq: 13151 REGISTER.
User-Agent: Telephone 1.5.2.
Supported: outbound, path.
Contact: <sip:1020%40192.168.20.20@172.31.33.17:5060>.
Expires: 7200.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS.
Content-Length:  0.

[liviuchircu]

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.

[JeffreyVIP]

@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 '@'.

[liviuchircu]

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.

[JeffreyVIP]

@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.

[liviuchircu]

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 ".".

[JeffreyVIP]

Thanks, looking forward to the feature request, please merge the patch to v3.1 branch if you can.

[volga629-1]

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);
                }

[liviuchircu]

@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).

[volga629-1]

That will be huge script overhaul for 3.2 with triple under scores

[liviuchircu]

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?

[volga629-1]

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)");

[liviuchircu]

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.

[volga629-1]

Ok great that doable, thank you for clarification. I will add to our config as comment.

[liviuchircu]

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!