Folks, I am having an issue with staying connected on external conference calls.Any caller on the UCX50 makes a call into an off campus conference bridge. After a few minutes, we are disconnected from the bridge and then dead air. We are using Grandstream's 41xx FXO gateways.It almost acts like it's a disconnect supervision problem. When I look under the FXO settings I have "Enable Call Supervision" set as the default "No".For "Yes" consult carrier. It just seems to me that these analog to SIP trunks should be set as "Yes"? And in fact that may be the whole issue. Comments PLEASE!!!
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
External Conferencing
- Thread starter ORPG
- Start date
For Granstream gateways, you have to turn off session timers. Otherwise, calls get disconnected after approximately 15 minutes. Look at the UCx Setup section on the following page:
Check if you have
[pre]session-timers=refuse[/pre]
in your SIP trunk used for the Granstream gateway.
Check if you have
[pre]session-timers=refuse[/pre]
in your SIP trunk used for the Granstream gateway.
- Thread starter
- #3
- Thread starter
- #4
Everything was the same as the link showed except "insecure=port" which I changed to "insecure=port,invite". The "session-timer=refuse" was there.
Each trunk did not have "host" nor did it have "deny" or "permit". All of these settings were set up by the vendor about a year ago.
Waiting to see if I have another failed call. Comments please?
Each trunk did not have "host" nor did it have "deny" or "permit". All of these settings were set up by the vendor about a year ago.
Waiting to see if I have another failed call. Comments please?
- Thread starter
- #5
- Thread starter
- #6
Added the "host" IP addresses to both gateways. Same non result.
Here's what's showing on each UCX trunk now:
For trunks 1-4:
host=10.71.26.29
type=peer
dtmfmode=rfc2833
insecure=port,invite
context=from-trunk
qualify=yes
session-timers=refuse
For trunks 5-8
other gateway
host=10.71.26.30
w/same settings
Here's what's showing on each UCX trunk now:
For trunks 1-4:
host=10.71.26.29
type=peer
dtmfmode=rfc2833
insecure=port,invite
context=from-trunk
qualify=yes
session-timers=refuse
For trunks 5-8
other gateway
host=10.71.26.30
w/same settings
- Thread starter
- #7
ucx: ALL OF THE INFORMATION IN THE "PEER" BOX FOR EACH TRUNK IS NOW SET AS PER THE MANUAL.
ON THE DAHDI TRUNKS I ENABLED ;BUSYDETECT=YES AND ;BUSYCOUNT=3 - BOTH WERE DISABLED IN THE DAHDI_CHAN.CONF FILE
GRANDSTREAM GATEWAY QUESTION:
WHAT IS/ARE THE SETTING(S)FOR DISCONNECT SUPERVISION, IF THE TELCO CENTRAL OFFICE HAS "BOTH WAY DISCONNECT"? THE PROBLEM IS THAT WE ARE GETTING DISCONNECTED DURING CONNECTED CALLS ON AN IRREGULAR BASIS.
ON THE DAHDI TRUNKS I ENABLED ;BUSYDETECT=YES AND ;BUSYCOUNT=3 - BOTH WERE DISABLED IN THE DAHDI_CHAN.CONF FILE
GRANDSTREAM GATEWAY QUESTION:
WHAT IS/ARE THE SETTING(S)FOR DISCONNECT SUPERVISION, IF THE TELCO CENTRAL OFFICE HAS "BOTH WAY DISCONNECT"? THE PROBLEM IS THAT WE ARE GETTING DISCONNECTED DURING CONNECTED CALLS ON AN IRREGULAR BASIS.
- Thread starter
- #9
UCXguy, we are opening a software maintenance agreement with EmetroTel this morning through our vendor; but here is the log file from the call that was just dropped.
[2016-11-18 10:42:21] VERBOSE[21790][C-000048d8] pbx.c: == Spawn extension (macro-dialout-trunk, h, 1) exited non-zero on 'UCX/255@255-0'
[2016-11-18 10:42:21] VERBOSE[21790][C-000048d8] app_macro.c: == Spawn extension (macro-dialout-trunk, s, 22) exited non-zero on 'UCX/255@255-0' in macro 'dialout-trunk'
[2016-11-18 10:42:21] VERBOSE[21790][C-000048d8] pbx.c: == Spawn extension (from-internal, 918137690500, 7) exited non-zero on 'UCX/255@255-0'
Comments please?
[2016-11-18 10:42:21] VERBOSE[21790][C-000048d8] pbx.c: == Spawn extension (macro-dialout-trunk, h, 1) exited non-zero on 'UCX/255@255-0'
[2016-11-18 10:42:21] VERBOSE[21790][C-000048d8] app_macro.c: == Spawn extension (macro-dialout-trunk, s, 22) exited non-zero on 'UCX/255@255-0' in macro 'dialout-trunk'
[2016-11-18 10:42:21] VERBOSE[21790][C-000048d8] pbx.c: == Spawn extension (from-internal, 918137690500, 7) exited non-zero on 'UCX/255@255-0'
Comments please?
From this small fragment of the log, there is no way to figure out the reason why the call was disconnected - it just indicates that an outbound call made by the extension 255 was disconnected. E-MetroTel support will look at the logs and possibly temporarily enable additional logging to find out which end disconnected the call and what the reported cause was.
- Thread starter
- #11
ok thanks Big Guy,
[2016-11-18 11:14:45] VERBOSE[21936][C-000048e7] pbx.c: == Spawn extension (macro-dialout-trunk, h, 1) exited non-zero on 'UCX/229@229-0'
[2016-11-18 11:14:45] VERBOSE[21936][C-000048e7] app_macro.c: == Spawn extension (macro-dialout-trunk, s, 22) exited non-zero on 'UCX/229@229-0' in macro 'dialout-trunk'
[2016-11-18 11:14:45] VERBOSE[21936][C-000048e7] pbx.c: == Spawn extension (from-internal, 918008661585, 7) exited non-zero on 'UCX/229@229-0'
[2016-11-18 11:14:50] NOTICE[25783] chan_ucx.c: 10.71.26.27:20056 Warning : received a retransmitted packet : 41B1 (we are at 41B2)
Here's the latest:
Working on the s/w agreement as we speak.
[2016-11-18 11:14:45] VERBOSE[21936][C-000048e7] pbx.c: == Spawn extension (macro-dialout-trunk, h, 1) exited non-zero on 'UCX/229@229-0'
[2016-11-18 11:14:45] VERBOSE[21936][C-000048e7] app_macro.c: == Spawn extension (macro-dialout-trunk, s, 22) exited non-zero on 'UCX/229@229-0' in macro 'dialout-trunk'
[2016-11-18 11:14:45] VERBOSE[21936][C-000048e7] pbx.c: == Spawn extension (from-internal, 918008661585, 7) exited non-zero on 'UCX/229@229-0'
[2016-11-18 11:14:50] NOTICE[25783] chan_ucx.c: 10.71.26.27:20056 Warning : received a retransmitted packet : 41B1 (we are at 41B2)
Here's the latest:
Working on the s/w agreement as we speak.
theislandtech
Technical User
are the ucx extensions that are being dropped have the mic muted?
Might want to take a look at the rtp timers in the sip settings
Might want to take a look at the rtp timers in the sip settings
- Thread starter
- #13
getsomesun1
Technical User
You mention no problems on Dahdi Trunks just the SIP trunks. I assume you are referring to the Pots lines connected to the Grandstream and then the GS is peered to the UCx? If so then I would go with Islandtech's suggestion. I have seen this issue with Public SIP trunks this is why I ask.
- Status