Trunk SIP FusionPBX and Yeastar TA410

[johneder]

Hello everyone
Some of you have used the Yeastar Ta410 with FusionPBX, I have a FusionPBX in aws but by VPN I want to send the calls. I had no result in doing the trunks
If someone can help me with an idea it will be great
Thank you

 

[nickbh]

I have similar issue of setting up fusionbpx to add ta410 as a gateway. I followed the following instruction from yeastar, but cannot register to fusionpbx:
https://support.yeastar.com/hc/en-us/community/posts/360033776153-Yeastar-Ta410-and-FusionPBX
https://support.yeastar.com/hc/en-u...reePBX-Phone-System-to-Yeastar-TA-FXO-Gateway


I setup the connection in yeastar as a trunk

Trunk Type: Trunk
Account Type: SIP
Provider Name: FusionPBX
Hostname/IP: 10.20.0.18
Domain: 10.20.0.18
User Name:yeastar
Authorization Name: yeastar
Password:

however, I am getting following error/warning in the log file:

2019-09-26 11:39:15.687332 [WARNING] sofia_reg.c:2930 Can't find user [yeastar@10.20.0.18] from 10.50.0.45
You must define a domain called '10.20.0.18' in your directory and add a user with the id="yeastar" attribute
and you must configure your device to use the proper domain in it's authentication credentials.
2019-09-26 11:39:15.687332 [WARNING] sofia_reg.c:1738 SIP auth failure (REGISTER) on sofia profile 'internal' for [yeastar@10.20.0.18] from ip 10.50.0.45

In FusionPBX, I have setup user yeastar in Domain 10.20.0.18

 

[KonradSC]

I'm guessing you will need to register the yeastar as an extension, then write a dialplan step to send calls to that specific extension with a bridge statement. If it's a static IP then it shouldn't be that bad. If it's a dynamic IP, then you will need to lookup the registered extension, extract the IP, then use that IP address variable in the bridge statement. I've done something similar with other registered SIP trunks.

So here is a dialplan step I used for a dynamic registered SIP trunk. The trunk registered with extension 9750 and I'm sending 1234 to the gateway. You will need to adjust this to your needs.

I would run the "sofia_contact" command from fs_cli to get an idea of what your registered extension looks like for your system. You will probably need to adjust the bridge statement for transport, fs_nat, fs_path, etc.

Also note that each "condition field" is a dialplan group. This isn't one long dialplan group.

<extension name="registered_sip_trunk_test" continue="true">
    <condition field="destination_number" expression="^1234$">
        <action application="set" data="called_contact=${sofia_contact(*/9750@${domain_name})}" inline="true"/>
    </condition>
     <condition field="${called_contact}" expression="^.*sofia.*sofia.*$" break="on-true"/>    <condition field="${called_contact}" expression="^.*sip:.*@(\b(?:\d{1,3}\.){3}\d{1,3}\b)" break="never">
        <action application="set" data="called_contact_internal_ip=$1" inline="true"/>
        <anti-action application="set" data="called_contact_internal_ip=unknown" inline="true"/>
    </condition>
    <condition field="${called_contact}" expression="^.*fs_path=sip%3A\d+%40((?:\d{1,3}\.){3}\d{1,3}.*)" break="never">
        <action application="set" data="called_contact_public_ip=$1" inline="true"/>
        <action application="bridge" data="sofia/internal/sip:1234@${called_contact_internal_ip};transport=tcp;fs_nat=yes;fs_path=sip:1234@${called_contact_public_ip}"/>
    </condition>
</extension>

Good luck!

 

[nickbh]

I'm guessing you will need to register the yeastar as an extension, then write a dialplan step to send calls to that specific extension with a bridge statement. If it's a static IP then it shouldn't be that bad. If it's a dynamic IP, then you will need to lookup the registered extension, extract the IP, then use that IP address variable in the bridge statement. I've done something similar with other registered SIP trunks.

So here is a dialplan step I used for a dynamic registered SIP trunk. The trunk registered with extension 9750 and I'm sending 1234 to the gateway. You will need to adjust this to your needs.

I would run the "sofia_contact" command from fs_cli to get an idea of what your registered extension looks like for your system. You will probably need to adjust the bridge statement for transport, fs_nat, fs_path, etc.

Also note that each "condition field" is a dialplan group. This isn't one long dialplan group.

<extension name="registered_sip_trunk_test" continue="true">
    <condition field="destination_number" expression="^1234$">
        <action application="set" data="called_contact=${sofia_contact(*/9750@${domain_name})}" inline="true"/>
    </condition>
     <condition field="${called_contact}" expression="^.*sofia.*sofia.*$" break="on-true"/>    <condition field="${called_contact}" expression="^.*sip:.*@(\b(?:\d{1,3}\.){3}\d{1,3}\b)" break="never">
        <action application="set" data="called_contact_internal_ip=$1" inline="true"/>
        <anti-action application="set" data="called_contact_internal_ip=unknown" inline="true"/>
    </condition>
    <condition field="${called_contact}" expression="^.*fs_path=sip%3A\d+%40((?:\d{1,3}\.){3}\d{1,3}.*)" break="never">
        <action application="set" data="called_contact_public_ip=$1" inline="true"/>
        <action application="bridge" data="sofia/internal/sip:1234@${called_contact_internal_ip};transport=tcp;fs_nat=yes;fs_path=sip:1234@${called_contact_public_ip}"/>
    </condition>
</extension>

Good luck!

Thank you for your suggestion. However, when I added the changes above by creating an extension file in the directory folder and reloadedxml -- it would not show up when i checked the status. So to overcome this, I added the configuration as mentioned in the yeastar's pbx guide, and removed the login/password from the table v_gateways manually and also set the register flag to false.

That is the same behavior that I had in freeswitch. This leads to me to ask, when we add changes to /etc/freeswitch folder. how come it does not load? even after renaming the file by removing the extension .noload

 

[KonradSC]

I see your confusion. The above code example is basically an outbound route added manually in Dialplan -> Dialplan Manager. When you click edit a dialplan rule and click "XML" on the top right, it will display as above. That code is not an extension like in Accounts -> Extensions.

So in the setup I suggested you would go to Accounts -> Extensions, add an extension (like x9750). Then configure the Yeastar to connect to Fusion and register as SIP user 9750. Then you would add something like the above code to create an dialplan entry that says, when you dial 1234, bridge it to 9750.

To answer your question, Fusion is configured to generate XML for Freeswitch dynamically from the database and stored in a cache directory. Static XML files in /etc/freeswitch are not used.

 

[nickbh]

Thank you for your help. I have had multiple things going on and so working on this as my pet project. As soon as I upgraded, I started getting an error that I needed to have a username and password. So I went back and on TA410, I created account/password and used that password to create a gateway on the fusionpbx.

Thanks

This may help someone else