[OpenSIPS-Users] 3.1 - Mid_Registrar - AOR throttling with WebRTC failing

[Mark Allen]

We are working on a test setup, hoping to move to a production system in
mid-August. We want to use mid-registrar AOR throttling. Users will connect
through OpenSIPS using a combination of SIP and WebRTC endpoints,
registering to an extension on an Asterisk main-registrar...

              +----------+
<SIP>    ---> |          |      +----------+
<SIP>    ---> | OpenSIPS | ---> | Asterisk |
<WebRTC> ---> |          |      +----------+
              +----------+

Multiple SIP phones (hardware or softphones) registering via an OpenSIPS
3.1 mid_registration AOR is working fine. A call to the extension number on
Asterisk results in all mid-registered SIP extensions ringing and when one
answers, the other devices register a missed call. So far, so good.

With 3.0 - we had a problem with WebRTC "phones" (even when just using
mid_registrar in "mirroring" mode). Webphone could register and call other
phones without a problem. However, calls to the WebPhone failed - there was
a problem with the WebSocket addressing giving "476 Unresolvable
destination" when the call originates from the main registrar - e.g. one
extension calling another. The /var/log/syslog entry said...

  ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri
  CRITICAL:core:mk_proxy: could not resolve hostname: "4xp44jxl0qq0.invalid"
  ERROR:tm:uri2proxy: bad host name in URI <sips:11001 at
4xp44jxl0qq0.invalid;rtcweb-breaker=yes;transport=wss>
  ERROR:tm:t_forward_nonack: failure to add branches

Stas Kobar gave me a way to resolve this -
http://lists.opensips.org/pipermail/users/2020-July/043443.html  As we were
using 3.0, I used the "path" module and  "add_path_received()" to handle
this for WebRTC. This worked for a single device registered to an address.
However, as far as I could see, using "path" effectively bypassed the
"contact" address held in the OpenSIPS "location" table so it didn't work
for AOR throttling.

I was hoping that, with mid_registrar on 3.1 baking in path support, I
could just use "mid_registrar_save('location','p0v')" to store the WebRTC
destination path in the "location" table. Then, with a call to the WebRTC
endpoint from the main registrar, "mid_registrar_lookup('location')" would
use the stored path from the "location" table to send traffic on to the
WebRTC phone and it would work fine with AOR throttling. However, that's
not happening, and looking at the "location" table, no path seems to
be being stored.

If I register a WebRTC "phone" first, the path is included on the
registration SIP message sent from OpenSIPS to Asterisk. If I then register
additional SIP phones on OpenSIPS, AOR throttling works, because, when the
call originates from Asterisk it includes the "route" HF that points to the
WebRTC destination. However, if a SIP phone registers first, Asterisk
doesn't get the WebRTC path, so calls fail to reach the WebRTC destination
because it tries to use the first registered SIP phone's path.

So - 2 questions really...

1 - Can I use AOR throttling with WebRTC (I can't guarantee that the WebRTC
endpoint will be the first to register or that there will only be one
WebRTC endpoint)

2 - If the answer to 1 is yes, what am I doing wrong?

Relevant code snippets...

loadmodule "mid_registrar.so"
modparam("mid_registrar", "mode", 2) /* 0 = mirror / 1 = ct / 2 = AoR */
modparam("mid_registrar", "outgoing_expires", 3600)

add_path_received();
$avp(returncode) = mid_registrar_save("location","p0v");
switch ($avp(returncode)) {
    case 1:
        route(resolve_registrar);
        $ru = "sip:" + $avp(main_registrar) + ":5060";
        t_on_failure("1");
        t_relay();
        break;
    case 2:
        break;
    default:
}

if (!mid_registrar_lookup("location")) {
    t_reply(404, "Not Found");
    exit;
}


NB - route(resolve_registrar) sets the variable $avp(main_registrar) to the
IP address of the Asterisk server
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200730/b313e029/attachment.html>