[OpenSIPS-Users] Dispatcher stickyness for external inbound calls
Matthias Kneer
matze at roterruler.de
Mon Dec 9 07:09:01 EST 2019
Hi David,
thank you for the helpful suggestions.
> Having the user register on fs when you have OpenSIPS/kamailio only
> complicates things, not to mention OpenSIPS can take A LOT more
> registers than fs ( on another setup I had around 8k users and
> eventually moved to Kamailio/OpenSIPS as a registrar, this increased
> considerably and OS/K was just fine, barely CPU usage). Your best bet
> is to create your necessary logic for registers on OS/K and use fs
> only for conferences
Unfortunately we do not only require conferences from FreeSWITCH. We
also need
voicemail with MWI, ivr, call - and pickup groups where user can leave
and join on
their own, fax2mail and provisioning.
For most of those features we would have to impelement additional logic
in openSIPS and
FreeSWITCH. This is not really doable for us, we are a pretty small team
and doing SIP / VoIP
stuff is not our main business.
I would love to do less in FS but I think it's easier to only have to
maintain user accounts in one location
and use the out of the box features for the required media services that
are already implemented in FS.
But anyway, your suggestions brought me to a point where I think that
active-passive FreeSWITCH pairs
will work best for us to avoid a lot of additional routing logic. We
then can partition them and add additional
pairs as required.
Best regards,
Matthias
Am 06.12.2019 11:34, schrieb David Villasmil:
> Hello,
>
> I totally misunderstood your question, then.
>
> Still dialplan should be useful. Instead of matching the domain, match
> the $ru and send it where it is supposed to be registered based on the
> dispatcher id.
>
> If the user can only register on one fs, then you’re good for
> registers and conferences.
>
> If the user is allowed to use multiple fs, you need to devise some way
> of figuring out where the conference is taking place (maybe send the
> invite to all the fs The user is allowed to, if you get a not found
> for the dialed number (conference), send it to next one, eventually it
> will find the conference, if it exists.
>
> How I do it is I create the conference on fs with the first user, and
> instruct the second user (via wss and jsip as the user is logged into
> our web page) to call into the conference number and adding a header
> specifying the server id, so that the proxy doesn’t need to do any
> lookups. The proxy looks into the header, translates the header value
> into a IP address, and forward it to the fs server.
>
> Having the user register on fs when you have OpenSIPS/kamailio only
> complicates things, not to mention OpenSIPS can take A LOT more
> registers than fs ( on another setup I had around 8k users and
> eventually moved to Kamailio/OpenSIPS as a registrar, this increased
> considerably and OS/K was just fine, barely CPU usage). Your best bet
> is to create your necessary logic for registers on OS/K and use fs
> only for conferences.
>
> Hope that helps!
>
> David
>
> On Fri, 6 Dec 2019 at 07:17, Matthias Kneer via Users
> <users at lists.opensips.org> wrote:
>
>> Thanks for your reply and the example, David.
>>
>> If I did understand your example correct, it basically solves the
>> issue
>> only for internal calls because of the match for ".*domain*"
>>
>> My main issue is the scenario where I do get a call from the PSTN.
>> Those
>> calls do not contain the corresponding FreeSWITCH domain of an
>> extension, they do only contain the floating IP of my openSIPS
>> systems
>> and the external number which has being called. This means, that I
>> can't
>> match for the domain. This is how an INVITE from the PSTN looks like
>> for me:
>>
>> INVITE sip:+49691234567 at 1.2.3.4:5060 [1] SIP/2.0
>> Via: SIP/2.0/UDP 1.2.3.5:5060;branch=z9hG4bK06Ba5515bda5556f434
>> From: <sip:+491751231231 at 1.2.3.5>;tag=gK06634aaa
>> To: <sip:+49691234567 at 1.2.3.4>
>> Call-ID: 1931912619_117228776 at 1.2.3.5
>> CSeq: 590408 INVITE
>> [...]
>>
>> and this is how an internal INVITE looks for me:
>>
>> INVITE sip:567 at customer1.sip.example.org;transport=TCP SIP/2.0
>> Via: SIP/2.0/TCP
>> 192.168.1.168:32396;branch=z9hG4bK-524287-1---62375638a60d1cee;rport
>> Max-Forwards: 70
>> Contact: <sip:789 at 1.2.2.3:34511 [2];transport=TCP>
>> To: <sip:567 at customer1.sip.example.org>
>> From: <sip:789 at customer1.sip.example.org;transport=TCP>;tag=1b546d48
>> Call-ID: Yr7uhzwS-LFx5hKjB8In7g..
>> CSeq: 1 INVITE
>> [...]
>>
>> What I would need is the related domain within FreeSWITCH of the
>> number
>> +49691234567 so that it will then be sent to the same FS where this
>> device has been registered with its internal extension / where the
>> other
>> conference calls have been sent to. But since the device registers
>> with
>> e.g. 567 at customer1.sip.example.org which does not directly relate to
>>
>> +49691234567 at 1.2.3.4, openSIPS is not aware of the FreeSWITCH where
>> this
>> device was registered / the other conference calls where sent to.
>>
>> A simple logic I was thinking about was something like this:
>>
>> $var(customdom) = $fd
>>
>> if ($rU=~"\+49691234.*") {
>> $var(customdom) = "customer1.sip.example.org [3]"
>> }
>>
>> later backed by a database so that we not have to hardcode this into
>> the
>> routing logic. Would this also be something for the dialplan?
>>
>> Thanks,
>> Matthias
>>
>> Am 05.12.2019 18:02, schrieb David Villasmil:
>>> Hello
>>>
>>> Dialplan is perfect for this.
>>> I did this on kamailio, but it's probably doable porting it.
>>>
>>> It would be something like:
>>>
>>> modparam("dialplan", "db_url", DBURL)
>>>
>>> ...
>>>
>>> route[DISPATCH] {
>>> ...
>>> # Get the attrs field for the matching domain, will store the
>> result
>>> in $var(dispatcher_id)
>>> dp_translate( "1", "$ru", "$var(dispatcher_id)" )
>>>
>>> # Select the group of fs nodes that we want this call to be sent
>> to.
>>> if(!ds_select_dst("$var(dispatcher_id)", "4"))
>>> {
>>> xlog("[DISPATCH]: ds_select_dst FAILED!'\n");
>>> send_reply("404", "No destination");
>>> exit;
>>> }
>>>
>>> xlog("L_DBG", "[DISPATCH]: going to <$ru> via <$du>\n");
>>> t_on_failure("RTF_DISPATCH");
>>> route(RELAY);
>>> }
>>>
>>> Your dialplan table would look like this:
>>>
>>>
>>
>
+----+------+-----+----------+---------------------------+-----------+-----------+----------+-------+
>>> | id | dpid | pr | match_op | match_exp |
>> match_len |
>>> subst_exp | repl_exp | attrs |
>>>
>>
>
+----+------+-----+----------+---------------------------+-----------+-----------+----------+-------+
>>> | 37 | 1 | 100 | 1 | .*domain1* |
>> 0 |
>>> | | 10 |
>>> | 55 | 1 | 100 | 1 | .*domain2* |
>> 0 |
>>> | | 30 |
>>> | 56 | 1 | 100 | 1 | .*domain3* |
>> 0 |
>>> | | 30 |
>>>
>>> and your dispatcher would look like you want to distribute your
>>> traffic:
>>>
>>>
>>
>
+------+-------+-------------------------+-------+----------+----------------------------------+------------------+
>>> | id | setid | destination | flags | priority |
>> attrs
>>> | description |
>>>
>>
>
+------+-------+-------------------------+-------+----------+----------------------------------+------------------+
>>> | 3097 | 10 | sip:1.2.3.1:5080 [4] [1] | 0 |
>> 10 |
>>> | server-01 |
>>> | 3098 | 10 | sip:1.2.3.2:5080 [5] [2] | 0 |
>> 10 |
>>> | server-02 |
>>> | 3110 | 20 | sip:1.2.3.1:5080 [4] [1] | 0 |
>> 10 |
>>> | server-01 |
>>> | 3109 | 20 | sip:1.2.3.2:5080 [5] [2] | 0 |
>> 10 |
>>> | server-02 |
>>> | 3108 | 30 | sip:1.2.3.3:5080 [6] [3] | 0 |
>> 10 |
>>> | server-03 |
>>>
>>> I hope that helps!
>>>
>>> David
>>>
>>> On Thu, 5 Dec 2019 at 15:01, Matthias Kneer via Users
>>> <users at lists.opensips.org> wrote:
>>>
>>>> Hi list,
>>>>
>>>> I'm currently building a HA setup with 2 openSIPS 2.4 instances
>>>> which do share a floating IP through keepalived. They are working
>> as
>>>> 1:1 mid_registrar, gateway to the PSTN and dispatcher for
>> multiple
>>>> FreeSWITCH instances. Those FreeSWITCH instances hold all
>> accounts,
>>>> domains and media services, they also do the RTP part.
>>>>
>>>> Since we are hosting multiple customers on the same FreeSWITCH
>>>> instances, sperated through domains, we'd like to ensure that all
>>>> registrations of a domain stay on the same FreeSWITCH as long
>> this
>>>> instance is reachable. We want this to ensure that conferences,
>> call
>>>> pickups and so on work reliable. It's not very important for us
>> to
>>>> distribute the load evenly since we have no high call /
>> conference
>>>> volume, the goal is more to have the setup as available as
>> possible
>>>> with some sort of loadbalancing and without having to take manual
>>>> action if one of the FreeSWITCHes dies.
>>>>
>>>> To achieve this, our idea was to set modparam("dispatcher",
>>>> "hash_pvar", "$fd") to use the from domain as source for hashing
>> and
>>>> call ds_select_dst with the alg "7":
>>>>
>>>> if (!ds_select_dst("2", "7"))
>>>> {
>>>> xlog("L_ERR", "$ci|end|no servers avaliable");
>>>> sl_send_reply("480", "Temporarily Unavailable");
>>>> exit;
>>>> }
>>>>
>>>> This approach works fine as long as we use it for internal calls
>>>> since those have the from / to domain part properly set. If a
>> call
>>>> arrives from the PSTN openSIPS has no knowledge about the
>> relation
>>>> of the external numbers and internal numbers / domains. Is there
>> a
>>>> smart way to properly route those external calls to the correct
>>>> FreeSWITCH wihtout having openSIPS to access the FreeSWITCH
>> database
>>>> / duplicating the data into the openSIPS database or to run
>>>> FreeSWITCH in active/standby mode?
>>>>
>>>> Best regards,
>>>> Matthias
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>> Links:
>>> ------
>>> [1] http://1.2.3.1:5080
>>> [2] http://1.2.3.2:5080
>>> [3] http://1.2.3.3:5080
>>> _______________________________________________
>>> 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
> --
>
> Regards,
>
> David Villasmil
> email: david.villasmil.work at gmail.com
> phone: +34669448337
>
> Links:
> ------
> [1] http://sip:+49691234567@1.2.3.4:5060
> [2] http://sip:789@1.2.2.3:34511
> [3] http://customer1.sip.example.org
> [4] http://1.2.3.1:5080
> [5] http://1.2.3.2:5080
> [6] http://1.2.3.3:5080
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
More information about the Users
mailing list