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

Stas Kobzar staskobzar at gmail.com
Wed Aug 26 13:49:04 EST 2020


Hi Mark,

Glad to hear you made it all work! Looks like it was a real challenge.

Good luck,
Stas

On Wed, Aug 26, 2020 at 8:47 AM Mark Allen <mark at allenclan.co.uk> wrote:

> Hi Stas - thanks for getting back to me. That helped me move forward a lot
> - particularly where you included what you see in the Path field - it
> helped to exclude a range of possible causes for the issues I was seeing.
>
> > If you do not have "path" set in your case the problem is probably
> there.
>
> Yes, because of how the "lumps" system works, and because WebRTC phone is
> connecting directly to OpenSIPS server, the incoming REGISTER didn't have a
> path, so to get the path saved in "location" I had to loop back to OpenSIPS
> again (thanks very much Johan De Clercq for filling in that part of the
> jigsaw). That then introduced some other problems that I had to resolve
> (particularly with RTPEngine going crazy looping back on itself and sending
> CPU temperature over 100degC - but that's another story!), but I've now got
> AOR throttling working with the mid-registrar successfully. Still a few
> bits to tweak with my script but it looks like I'm on the home straight.
> Thanks once again for all your help
>
> cheers,
>
> Mark
>
>
>
> On Fri, 21 Aug 2020 at 14:59, Stas Kobzar <staskobzar at gmail.com> wrote:
>
>> Hello Mark,
>>
>> In my case I do have a path in the location record. Here is my example
>> from "ul show" (I changed my real domain and IPs):
>> AOR:: 9170 at example.com
>>                 Contact:: sip:suvp4v56 at 1p6pc0g6m3ml.invalid;transport=ws
>> Q=
>>                         Expires:: 494
>>                         Callid:: i1tmiaipa3l2nvvhmairvu
>>                         Cseq:: 28
>>                         User-agent:: JsSIP 3.5.3
>>                         Path:: <sip:10.0.0.186:8060
>> ;r2=on;lr>,<sip:10.0.0.186:8061;transport=wss;r2=on;lr;received=sip:
>> 10.0.0.213:47326>
>>                         State:: CS_SYNC
>>                         Flags:: 0
>>                         Cflags::
>>                         Socket:: udp:10.0.0.185:5060
>>                         Methods:: 5503
>>                         SIP_instance::
>> <urn:uuid:6d815278-4885-4468-b07b-eca6ab80e2d4>
>>
>> And here is my mysql location record:
>>
>> mysql> select contact, path from locations where username =9170;
>>
>> +------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------+
>> | contact                                        | path
>>
>>                       |
>>
>> +------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------+
>> | sip:suvp4v56 at 1p6pc0g6m3ml.invalid;transport=ws |
>> <sip:199.182.135.186:8060;r2=on;lr>,<sip:199.182.135.186:8061
>> ;transport=wss;r2=on;lr;received=sip:107.179.246.213:47364> |
>>
>> +------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------+
>>
>> If you do not have "path" set in your case the problem is probably there.
>> My lookup is not mid_register but it is close to what you have. I only
>> use parameter "m" to lookup in memory.
>>
>> On Fri, Aug 21, 2020 at 9:19 AM Mark Allen <mark at allenclan.co.uk> wrote:
>>
>>> What am I looking for?
>>>
>>> INVITE from Asterisk to Opensips looks fine. Contact info from
>>> "location" matches that seen in console for web phone.
>>>
>>> Problem seems to be that the address is not recognised as a web socket
>>> rather than a host name. It's not NATed but tried fix_nated_register() and
>>> fix_nated_contact() but it made no difference.
>>>
>>> On Fri, 21 Aug 2020, 13:23 Slava Bendersky via Users, <
>>> users at lists.opensips.org> wrote:
>>>
>>>> Please check contact header.
>>>>
>>>> volga629
>>>>
>>>> ------------------------------
>>>> *From: *"Mark Allen" <mark at allenclan.co.uk>
>>>> *To: *"OpenSIPS users mailling list" <users at lists.opensips.org>
>>>> *Sent: *Friday, August 21, 2020 8:08:18 AM
>>>> *Subject: *Re: [OpenSIPS-Users] 3.1 - Mid_Registrar - AOR throttling
>>>> with        WebRTC failing
>>>>
>>>> I've not received any feedback on this regarding whether or not what
>>>> I'm doing should be working. Trying to find a workaround has just led to a
>>>> number of dead-ends. Can anyone please help me with this?
>>>> We are using mid-registrar with AOR Throttling talking to
>>>> Asterisk/FreePBX. We have OpenSIPS 3.1 running on Debian Buster. For SIP
>>>> phones, physical and softphones, connected on our LAN, all works fine.
>>>> Where we hit problems is with WebRTC phones.
>>>>
>>>> WebRTC phone registers via mid-registrar without a problem. However, a
>>>> call coming from Asterisk (e.g. extension --> extension) fails with an
>>>> error like:
>>>>
>>>>   476 Unresolvable destination
>>>>
>>>> ...and a syslog entry...
>>>>
>>>>   ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri
>>>>   CRITICAL:core:mk_proxy: could not resolve hostname:
>>>> "cfdtugr3cntl.invalid"
>>>>   ERROR:tm:uri2proxy: bad host name in URI
>>>> <sips:11023 at cfdtugr3cntl.invalid;rtcweb-breaker=yes;transport=wss>
>>>>   ERROR:tm:t_forward_nonack: failure to add branches
>>>>
>>>> We can get calls to WebRTC from Asterisk working via OpenSIPS if we are
>>>> only using registration throttling. As this establishes a 1:1 relationship,
>>>> by using add_path_received() we get Asterisk to include a Route which
>>>> bypasses the resolvehost problem. However, with multiple endpoints
>>>> registered to a single OpenSIPS AOR with AOR throttling, this workaround
>>>> obviously won't work. How can I set up OpenSIPS so that we can have
>>>> multiple endpoints, including WebRTC ones, registered to a single OpenSIPS
>>>> AOR and have calls successfully reach the WebRTC phones?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, 3 Aug 2020 at 08:44, Mark Allen <mark at allenclan.co.uk> wrote:
>>>>
>>>>> I don't know if anyone has had a chance to look at my problem but I
>>>>> wonder if at least I could get an opinion on the following:
>>>>> 1 - Should I be seeing the path saved in the appropriate column in the
>>>>> "location" table?
>>>>> 2 - Am I using mid_registrar_save() and mid_registrar_lookup() with
>>>>> path support correctly in my script?
>>>>> 3 - have I correctly understood how to combine WebRTC with
>>>>> mid-registrar module, path, and AOR throttling so that it should work for
>>>>> calls originating from the main registrar?
>>>>>
>>>>> I'm stuck on how to move forward with this
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Mark
>>>>>
>>>>> 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
>>>>>
>>>>> On Thu, 30 Jul 2020 at 09:16, Mark Allen <mark at allenclan.co.uk> wrote:
>>>>>
>>>>>> 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
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200826/f24c9fb7/attachment-0001.html>


More information about the Users mailing list