Always restart freeswitch to use a phone number to the conference bridge

[Joseph Flagiello]

Hi, I configured a phone number to the conference bridge. The problem is that I have to restart freeswith with the command ‘systemctl restart freeswitch’ very often otherwise I don't get the calls.

In particular if a call is made when the conference has not started, the answering machine answers with instructions but after then it will not be possible to receive subsequent calls if freeswitch is not restarted.

How is this problem solved? Is it normal or I did something wrong?

[Fred Dixon]

Hi Joseph,

Can you share your configuration changes to FreeSWITCH. 

 

 https://docs.bigbluebutton.org/2.2/customize.html#add-a-phone-number-to-the-conference-bridge

Regards,... Fred

--
You received this message because you are subscribed to the Google Groups "BigBlueButton-Setup" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-s...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bigbluebutton-setup/ff29b2fa-0b60-476a-89ad-468a98dee788n%40googlegroups.com.

--

BigBlueButton Developer

http://bigbluebutton.org/

Like BigBlueButton?  Tweet us at @bigbluebutton

[Joseph Flagiello]

Hi Fred, thank you for your reply and congratulations on your valuable work. The SIP call works very well and therefore I think the configuration is quite correct. The only serious problem is that after each call I have to restart with 'systemctl restart freeswitch'  to continue receiving calls, otherwise it doesn't work.

As soon as I restart it works very well again. Thanks

My SIP Provider:

Username: 0742123456
Password: 123-456-789
Server: voip.eutelia.it
Proxy server SIP: voip.eutelia.it:5060
Server STUN: stun.voip.eutelia.it:3478

This is my configuration:

/opt/freeswitch/conf/sip_profiles/external/YOUR-PROVIDER.xml:

<include>

  <gateway name="EUTELIA">

    <param name="proxy" value="voip.eutelia.it:5060"/>

    <param name="username" value="0742123456"/>

    <param name="password" value="123-456-789"/>

    <param name="extension" value="1234567890"/>

    <param name="register" value="true"/>

    <param name="context" value="public"/>

  </gateway>

</include>

/opt/freeswitch/conf/dialplan/public/my_provider.xml:

<extension name="from_my_provider">

 <condition field="destination_number" expression="^1234567890">

   <action application="answer"/>

   <action application="sleep" data="1000"/>

   <action application="play_and_get_digits" data="5 5 3 7000 # conference/conf-pin.wav ivr/ivr-that_was_an_invalid_entry.wav pin \d+"/>

   <!-- Uncomment the following block if you want to mask the phone number in the list of participants. -->

   <!-- Instead of `01711233121` it will then show `xxx-xxx-3121`. -->

   <!--

   <action application="set_profile_var" data="caller_id_name=${regex(${caller_id_name}|^.*(.{4})$|xxx-xxx-%1)}"/>

   -->

   <action application="transfer" data="SEND_TO_CONFERENCE XML public"/>

 </condition>

</extension>

<extension name="check_if_conference_active">

 <condition field="${conference ${pin} list}" expression="/sofia/g" />

 <condition field="destination_number" expression="^SEND_TO_CONFERENCE$">

   <action application="set" data="bbb_authorized=true"/>

   <action application="transfer" data="${pin} XML default"/>

 </condition>

</extension>

[sd...@distancelearning.cloud]

So,  your gateway registration in freeswitch is not staying registered.

Its starts registered. 

 

Try in fs_cli> sofia status

 

You should see errors in logs when it tries to register every few minutes, as to what the exact reason is.

 

Its possible to just send traffic from your ISP directly to port 5060 UDP, and not need to have to register in freeswitch.  Actually registering to your ISP can be dangerous.  Since a hacked server, could attempt to make outbound calls from freeswitch and run up some telco bills if outbound international calling is configured with your ISP.   That’s why there are some many sip attempts on a server if the port if left wide open.

 

Regards,

Stephen

To view this discussion on the web visit https://groups.google.com/d/msgid/bigbluebutton-setup/e72cabf3-6cce-44bf-a549-969cc139bd3bn%40googlegroups.com.

[Joseph Flagiello]

Hi, the problem is not solved.

I share my log.

In the first screen you can see that the service is working correctly, even after a few calls made every few seconds, the service after a sleep restarts on call. 

But if the next call is after a longer time like 2 minutes the service after a sleep does not communicate anything anymore because it probably does not wake up.

in the second screen you can see that after sleep there is no more activity even if I try to call

[sd...@distancelearning.cloud]

From last week.  Did you try below?

 

Try in fs_cli> sofia status

You should see errors in logs when it tries to register every few minutes, as to what the exact reason is.

 Regards,

Stephen

 

 

From: bigbluebu...@googlegroups.com <bigbluebu...@googlegroups.com> On Behalf Of Joseph Flagiello
Sent: Saturday, January 2, 2021 11:06 AM
To: BigBlueButton-Setup <bigbluebu...@googlegroups.com>
Subject: Re: [bigbluebutton-setup] Always restart freeswitch to use a phone number to the conference bridge

 

Hi, the problem is not solved.

I share my log.

In the first screen you can see that the service is working correctly, even after a few calls made every few seconds, the service after a sleep restarts on call. 

But if the next call is after a longer time like 2 minutes the service after a sleep does not communicate anything anymore because it probably does not wake up.

in the second screen you can see that after sleep there is no more activity even if I try to call

To view this discussion on the web visit https://groups.google.com/d/msgid/bigbluebutton-setup/53ba61cd-ab3c-47b6-822f-9610a6e74039n%40googlegroups.com.

[Joseph Flagiello]

Hi, yes this is the Sofia state register.

There are no mistakes.

I activate freeswitch with the command 'systemctl restart freeswitch' and try a call and it works fine; if the next call has passed a long time (about 2 minutes) it does not wake up from sleep (image n. 1) and to have this service I have to activate freeswitch again with the command 'systemctl restart freeswitch'.

If, on the other hand, the next call is immediately following the previous one (about 60 seconds) it wakes up from the stop state and works fine without issuing the 'systemctl restart freeswitch' command again (image n. 2)

Image n. 1

Image n. 2

Thanks Stephen

[Lorenz Schori]

Hi,

On Mon, 4 Jan 2021 04:20:18 -0800 (PST)
Joseph Flagiello <joseph.f...@gmail.com> wrote:

> If, on the other hand, the next call is immediately following the
> previous one (about 60 seconds) it wakes up from the stop state and
> works fine without issuing the 'systemctl restart freeswitch' command
> again (image n. 2)

This sounds like the VoIP provider is loosing the ability to signal an
incoming call after a certain amount of time. Is your BBB/FreeSWITCH
behind a NAT?

Cheers,
Lorenz

[Joseph Flagiello]

Hi Lorenz, Freeswith isn't behind NAT.

It is in the same server of BBB in a VPS.

Thanks

--
You received this message because you are subscribed to a topic in the Google Groups "BigBlueButton-Setup" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bigbluebutton-setup/FakXckK1zrw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bigbluebutton-s...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bigbluebutton-setup/20210104151346.31c9e427%40bonemachine.

[Lorenz Schori]

Hi Joseph,

On Mon, 4 Jan 2021 15:31:05 +0100
Joseph Flagiello <joseph.f...@gmail.com> wrote:

> Hi Lorenz, Freeswith isn't behind NAT.
> It is in the same server of BBB in a VPS.

Still it looks to me that some stateful firewall is observing the SIP
registration and is adding a state for the UDP flow whenever FreeSWITCH
is starting up. But it seems to kill the state after the 2 minute
timeout unless there is some traffic in that flow.

You have two options:
* Try to track down which firewall is causing that (ufw/iptables on the
host or something around the VPS)
* Try to convince FreeSWITCH to periodically send some traffic via SIP.
I assume that this could be done with the `ping` gateway parameter:
https://freeswitch.org/confluence/display/FREESWITCH/Sofia+Configuration+Files#SofiaConfigurationFiles-Gateway

E.g.: Something like this:

/opt/freeswitch/conf/sip_profiles/external/YOUR-PROVIDER.xml:

<include>
<gateway name="EUTELIA">

...
<param name="ping" value="30"/>
<param name="ping-max" value="3" />
</gateway>
</include>

Cheers,
Lorenz

[Joseph Flagiello]

Hi Lorenz, it seems to me that it is solved by adding:

<include>

  <gateway name = "EUTELIA">

    ...

    <param name = "ping" value = "30" />

    <param name = "ping-max" value = "3" />

  </gateway>

</include>

to /opt/freeswitch/conf/sip_profiles/external/YOUR-PROVIDER.xml

Thanks Lorenz for your advice