Loading Profile...
Callers could not dial into my show on 10/28 8pm
I hosted a show tonight 8pm 10/28. There was a fast busy signal when trying to dial in. It kept my guest who I was to interview from calling in. I personally had to call 2 times before getting in. Several other listeners had the same problem.
What hapened? Also what can I do to get my scheduled guests on, if this happens again. I am not feeling comfortable having other guests on, if they cannot call in for their interview. Please advise and thank you.
Also there was an intermittent problem with unmuting the callers. It didn't work for 5-10 minutes and then it did work for 5-10 minutes, etc.
Healing Path with Alice McCall
What hapened? Also what can I do to get my scheduled guests on, if this happens again. I am not feeling comfortable having other guests on, if they cannot call in for their interview. Please advise and thank you.
Also there was an intermittent problem with unmuting the callers. It didn't work for 5-10 minutes and then it did work for 5-10 minutes, etc.
Healing Path with Alice McCall
I’m frustrated
1
person has this problem
I have this problem, too!
Tell me when someone solves it.
The more people who report this problem, the more it gets noticed.
The more people who report this problem, the more it gets noticed.
The company marked this problem solved.
Create a customer community for your own organization
Plans starting at $19/month
-
Inappropriate?Alice (and many others),
We had numerous reports of callers receiving "fast busy" signals or "all circuits busy" messages last night (October 28, 2008) between 9:00 PM and 10:00 PM. We were alerted to this problem almost instantly. I myself did about 50 test calls during the period and found that the calls were blocked about 90% of the time (very bad), so there absolutely was a problem.
However, we don't yet know why. At the peak, only 40% of TalkShoe's phone ports were in use and our "trunk reports" show that no calls were blocked at the point where they connect to the conferencing bridge. Instead, it appears that calls to 724-444-7444 were being blocked in distant telephone networks, near the points of call origination. There are mechanisms in the telephony infrastructure to do this, specifically something called a "hard to reach" response that is designed to push overloads back to the originating callers. This was put in place by telcos years ago to handle the numerous radio call-in contests, concert ticket sales, etc., that tend to overload the telephone system. However, we know of no reason why that would have happened to TalkShoe last night between 9:00 PM and 10:00 PM.
We're working closely with our telephone company partner and our conferencing bridge provider to investigate and will report back. FYI, this has not been a frequent problem but I do remember being in California last October 28th (same date) and having the same thing happen when I tried to call TalkShoe from there. Maybe it's due to the impending arrival of Halloween. ;-)
Seriously, we'll get to the bottom of this and report back.
I’m unsure
The company says
this solves the problem
-
Inappropriate?After deep investigation today in tandem with our partners, we believe that this problem has been resolved. For those who like details, here they are from one of the engineers:
"Most all ports on the bridge’s PSTN LIF (1-11) were configured for no signaling instead of wink start. Strangely the first 16 channels on the first T1 were OK, but the rest were not. If the DMS tried to use these channels it would have seen no wink back from the end equipment. I fixed it now."
"We think this problem was a direct result of some of the problems experienced during the upgrade [on 10/16/08]. The configuration was rebuilt from scratch in an attempt to fix the bridge post-upgrade, and configuration of these ports was missed by a ‘Configure All’ action at the MC. I double-confirmed the configuration of all T1s and channels is correct now."
"I also pulled the bridge logs for yesterday and had a look at the time period 21:00-22:00. All T1s on the bridge were receiving calls during this time period EXCEPT: 1-11-2 through 1-11-8, for the reason I explained above.
"If the switch couldn’t deliver calls to 1-11-2 through 1-11-8 (T1s 26-32), [then it might not] try to deliver to the T1s assigned to the 9001 rollover? If the answer is no, then ... this was the only problem." That would have blocked all other spare ports from being used.
I’m happy
