GotSpeech.NET

Hi all,

I'm experiencing an odd issue with my outbound calling app and was hoping someone could provide me with some info.  I've been having trouble getting busy signal info from my dialogic gateway.  Currently, I'm getting this information, however it's really slow to get back to me, a minute or so typically.  So what's happening is that exactly 1 minute after the first call to a busy number fails, the call is retried.  So for the 3 tries I put in my code to attempt a number, I get 6 actual calls.  I was wondering if OCS might be retrying the call since there is no SIP response for so long?  The retry at exactly 1 minute is suspicious, because my code doesn't retry again for over 2 minutes.  If this is an ocs/speech server thing, is there a way to adjust the timing?

Thanks in advance!
Catie

Are you getting a SIP BUSY HERE back from Dialogic or is it just dropping the call? I’d be curious so see what Wireshark says is going on between the gateway and OCS.

Which dialogic gateway are you using and what type of line are you connected to?

I'm using a DMG1008DNIW gateway connected to 6 digital lines. 

The message I'm getting back as far as I can tell is a 480 Temporarily Unavailable message, and it appears there is a request to retry the call immediately after receiving the Temporary Unavailable message.  The call isn't actually attempted by the gateway for 1 minute after the first try ends.

We've been having a lot of trouble detecting a busy signal on this gateway (multiple calls to the same busy number return different learned tone results).  Right now, I'm dialing 2x as many times as I'd like, but somehow my app still determines correctly that we got a busy signal.  And since it is checking for a SipPeerBusyException, I must somehow be getting a SIP Busy message from somewhere.  Doesn't show up in the wireshark traces that I can see at least.

Thanks,
Catie

OCS lumps a few different SIP codes into the SipPeerBusy:
- Temporarily unavailable (480)
- Busy Here (486)
- Busy Everywhere (600)
- Decline (603)

So the exception you're seeing is okay.

So most common problem with the DMG Digital is the lines being configured incorrectly on the PBX. The DMG uses the phone's display features to determine call progress (tones seem to only be a backup to the display). Often times if this display is delivering unexpected data the DMG will go into a weird state. We've had issues with a Nortel refreshing the time display and it screwing up ANI and DNIS for example.

I would suggest downloading the latest integration guide and ensuring the PBX is configured to the letter.What seems like the most innocuous setting has ended up caused us no end of grief at times.

I cannot believe I am still working on this issue, but I am.  I have been in discussions with the PBX folks at the office we are working out of, Scansource, and Dialogic themselves.  I have stumped the Dialogic guys at this point, and as far as we can all tell, the PBX is configured appropriately. 

From the gateway logs, apparently the PBX is telling them to go On Hook immediately after dialing a busy number for one reason or another.  The gateway then sends back a 480 message which gets Acknowledged.  I'm assuming that means that Speech Server got the message?  My app, however, doesn't get any call status until the 2nd attempt has completed.  Does Speech Server retry calls for you?  I cannot find any setting for this in the Admin Console, but it is the only reason I can think of that a call is tried 2x.

Any ideas?  Anything would be helpful.  Right now, the biggest issue is that busy numbers get called 2x as many times as we'd like, and eats up an extra minute per call attempt, which when we get a lot of users, could turn into a larger problem depending on how many busy calls we encounter.  Thanks in advance.  Let me know if I can provide any more info!

Speech server doesn't automatically try another call.  I suspect the problem is in your retry mechanism.  Try one call to a busy line and track what happens.  Perhaps include some extra logging information in your code.

I have tracked a busy call, and the 480 from the first attempt never makes it all the way back to my application.  It only ever knows about the 480 from the 2nd attempt.  The fail mechanism is the same for no answer calls, and I know those get retried appropriately.

msclaricode:

I have tracked a busy call, and the 480 from the first attempt never makes it all the way back to my application.  It only ever knows about the 480 from the 2nd attempt.  The fail mechanism is the same for no answer calls, and I know those get retried appropriately.

That sounds like it is the Dialogic gateway that is making the second attempt. Have you checked its configuration for something that could be causing this.

I really need to take the time to bring my Dialogic gateway back on line so that I can experiment.

---

Marshall Harrison
Lync MVP
GotSpeech Consulting LLC
Phone: (904) 222-8880
the gotspeech guy

I just checked all settings and the only thing I saw that was suspicious was the "Call Monitor Interval" under VOIP -> General settings as it is set to 60 secs.  However, "Monitor Call Connections" is set to "No", so this setting shouldn't be valid, and it doesn't appear from the description of the setting that it would cause the gateway to dial a second time.  I have sent my settings to the Dialogic folks multiple times, and they haven't mentioned anything, but they also swear the gateway won't do anything it's not told to do.

The dialogic guy we have helping us swears up and down that he is receiving an "On Hook" message from the PBX immediately after finishing dialing the # we know to be busy.  When we unplug a line from the gateway and plug it into a handset and dial the number, a busy signal is heard just fine.  I don't know how this factors in, but definitely seems odd.

What kind of PBX are you attached too?

A Nortel BCM 50 with the lines coming into the gateway configured for the 7324 handset configuration.  Gateway is configured for Norstar.

Additionally, I just got the logs from speech server and looked in the Analytics & Tuning studio.  It only sees 3 sessions, each lasting a minute 14 secs, which is the time it takes for both calls to be made.

Check that the  gateway's Call Connect Mode parameter is set to "OnAnswer".

---

Marshall Harrison
Lync MVP
GotSpeech Consulting LLC
Phone: (904) 222-8880
the gotspeech guy

I know the setting you're talking about, but cannot find it for some reason.  I have the RFC Early Media Support set to "OnDemand", and that is a setting we've played around with a bit.  I think this is pretty much the same setting.