Guest joneschik Report post Posted 12/07/2015 05:13 PM Callers are receiving a fast busy signal when they are transferred into the Voiceguide system. We have a Windows 2003 Std server with 4 lines running Voiceguide 7.4.2. We are using Dialogic HMP drivers and use a Cisco VOIP system. I have already determined that there are always lines available when the callers receive the fast busy (we are not using all 4 lines at the same time). I have seen internal users receive a fast busy before however, at this time it seems only to be users who are on the outside of the network calling in who get the fast busy. Can you tell by the logs if this is a problem with Voiceguide or the HMP drivers or something else? its_sysinfo.zip vg logs.zip Share this post Link to post
Guest joneschik Report post Posted 12/07/2015 06:35 PM A busy signal is received when external caller is passed to Voiceguide system and the caller is immediately disconnected when viewed in line status monitor. Internal callers are able to call the same extension and upon entry to Voiceguide, they successfully connect. Sample logs are attached. Trying to determine if this is an issue with the Cisco Voip side or the Voiceguide side. its_sysinfo.zip vg logs.zip Share this post Link to post
SupportTeam Report post Posted 12/07/2015 08:50 PM Attached trace captures 3 incoming calls. 105421.762 6 3 1 state <offered> : cid=4052183122@172.19.100.103 , dnis=11173131@172.19.100.29 105601.840 6 7 2 state <offered> : cid=84052183122@172.19.100.103 , dnis=11173131@172.19.100.29 105858.449 6 10 3 state <offered> : cid=814056501325@172.19.100.103 , dnis=11173131@172.19.100.29 The first call connected fine when answered and the call went right through the whole script. The second and third calls did not connect properly. The incompatibility of 2nd and 3rd calls has occurred on SIP level. WireShark and deeper Dialogic RTF log tracing tracing would be needed here to establish what SIP layer issues involved. All calls have different CallerIDs - but look to be still related to same number that was initially used to make original working call. Was the 1st call an 'internal' call and the 2nd and 3rd calls were 'external' calls? If the first call was 'internal' and 2nd and 3rd calls were 'external' then maybe you should also look into why the CallerIDs seem to be the same number... All the calls have been sent to VoiceGuide from a Cisco system, yes? So really the question is what caused the Cisco system to send these calls in different ways, resulting in some of them being answered and working fine, and some of them not. If you can post WireShark and RTF log debug traces we can then advise on what they show. When doing these traces please capture all 3 ways of sending the call into the system, the differences between them will then be easier to spot. Share this post Link to post
Guest joneschik Report post Posted 12/08/2015 01:06 AM I deleted VG logs and started over so that its clear. The first call from 405-218-3122 was dialed out on an internal Cisco VOIP phone by dialing the following: 3000 and pressing 8 on the keypad which transfers you to Voiceguide. This was success. The second call from 405-218-3122 was dialed out on an internal Cisco VOIP phone by dialing the following: 8, 218-3000 and pressing 8 which transfers you to Voiceguide. This failed. Busy. The third call from 405-218-3126 was dialed out on an internal Cisco VOIP phone by dialing the following: 8, 218-3000 and pressing 8 which transfers you to Voiceguide. This failed. Busy. The fourth call from 405-650-1325 was dialed on an AT&T cell phone by dialing 405-218-3000 then pressing 8 which transfers you to Voiceguide. This failed. Busy. Only calls dialed as coming as "internal" to the LAN was successful. Anything "external" or being routed from "outside" fails. I have attached wireshark capture which shows all 4 calls in succession. Thank you. 1207_CallEvents.zip wireshark vg1.txt Share this post Link to post
SupportTeam Report post Posted 12/08/2015 06:22 AM WireShark shows 1st call is fine, with caller hanging up about 30 seconds after call began. Calls 2, 3 and 4 are hung up by the CISCO device immediately after it acknowledges that it has received the OK from VoiceGuide that VoiceGuide sends to say that it has answered the call. On calls 2, 3 and 4 the Q.850 cause sent by Cisco at disconnect time is "47", which usually indicates some sort of a "Resource Unavailable" error. So looks like there is some issue with this Cisco CUCM setup that results in Cisco disconnecting the call. cisco4calls.zip Share this post Link to post
