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@1.2.3.4:5060 SIP/2.0
Via: SIP/2.0/UDP 1.2.3.5:5060;branch=z9hG4bK06Ba5515bda5556f434
From: <sip:+491751231231@1.2.3.5>;tag=gK06634aaa
To: <sip:+49691234567@1.2.3.4>
Call-ID: 1931912619_117228776@1.2.3.5
CSeq: 590408 INVITE
[...]

and this is how an internal INVITE looks for me:

INVITE sip:5...@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@1.2.2.3:34511;transport=TCP>
To: <sip:5...@customer1.sip.example.org>
From: <sip:7...@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. 5...@customer1.sip.example.org which does not directly relate to +49691234567@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"
}

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 [1]        |     0 |       10 |
 | server-01        |
| 3098 |    10 | sip:1.2.3.2:5080 [2]        |     0 |       10 |
 | server-02        |
| 3110 |    20 | sip:1.2.3.1:5080 [1]        |     0 |       10 |
 | server-01        |
| 3109 |    20 | sip:1.2.3.2:5080 [2]        |     0 |       10 |
 | server-02        |
| 3108 |    30 | sip:1.2.3.3:5080 [3]        |     0 |       10 |
 | server-03        |

I hope that helps!

David

On Thu, 5 Dec 2019 at 15:01, Matthias Kneer via Users
<users@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@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@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to