Not Detecting Double-Digit

[lucasklos]

Hello,

I have a problem that VoiceGuide is not detecting correctly number with two or more consecutive digits. I.e. 34567 is detected OK, but 34445 is not detected (in the log file I see 345 or 3445).

This only happens when calling from a phone thru a Cisco PBX. When calling from a softphone everything goes well.

 

Which configuration parameters should I change to get this work properly? Thanks.

[SupportTeam]

Can you please advice more information about your system.

Which version of VoiceGuide are you using?

Are you using a VoIP based system or a a Dialogic card?

How is the VoiceGuide system connected to the Cisco PBX?

[lucasklos]

Sorry about that...

I'm using VoiceGuide v7.

The system is VoIP based and the PBX redirects the calls to our VoiceGuide server.

This are the configuration sections from Config.xml:

 

 

<VoIP_Registration>

<Display>Cisco PBX 1 1055</Display>

<Protocol>SIP</Protocol>

<RegServer>10.57.74.33</RegServer>

<RegClient>1055</RegClient>

<LocalAlias>1055</LocalAlias>

</VoIP_Registration>

 

 

<VoIP_Authentication>

<Display>Cisco PBX 1 1055</Display>

<Realm>10.57.74.33</Realm>

<Identity>sip:1055@10.57.74.33</Identity>

<AuthUsername>1055</AuthUsername>

<AuthPassword>6924</AuthPassword>

</VoIP_Authentication>

 

This is the only extra configuration I added related to the communication between VoiceGuide and the PBX.

Please let me know if you need more information.

Regards.

[SupportTeam]

So looks like this is a VoIP setup.

 

Can you advise what is the model and version of the Cisco PBX? Is it CallManager, or something else?

 

What could be happening here is that at some point of the VoIP connection some device tries to convert the DTMF tones that it hears into "RFC 2833" events, but is not doing a very good job of it, and is tends up treating two closely spaced DTMF tones of same digit as one tone.

Inband to rft2833 conversion can be a bit tricky is a high proportion of VoIP packets on this connection are lost or delayed.

 

We would need to see the WireShark trace capture of a call, along with VoiceGuide's ktTel trace, to be able to confirm what is happening.

 

WireShark can be obtained from www.wireshark.org.

[lucasklos]

Thank you very much for your answer.

 

Attached please find ktel trace and part of a trace file of wireshark.

Please let me know if the wireshark file doesn't help, the system was being used at that time and I couldn't get a clearer.

Also, if you can recomend a filter to use in wireshark capture would be great.

 

Numbers that were not recognized: 21775 and 77777 (they corresponds to the last calls).

 

IP of the machine running VoiceGuide = 10.56.69.54

IP of PBX = 10.56.74.34

 

Thanks!.

logs_trace.zip

[SupportTeam]

Please post the WireShark trace as a .pcap file.

It is not possible the read the text dump that was uploaded.

 

In the WireSharks' Filter text box please use this expression:

 

sip and rtp

 

This will reduce the shown packets to just SIP and RTP packets.

 

And when post of trace indicate what calls we should look at and what key-presses were not recognized.

 

Can you advise what is the model and version of the Cisco PBX? Is it CallManager, or something else?

[SupportTeam]

From the ktTel trace we can see that on the last call the caller first entered 9121 and after being advised that that was an incorrect tone they then entered 29121 which was accepted.

 

 

212754.327 3564 10 r dtmf 9

212755.137 3564 10 r dtmf 1

212755.917 3564 10 r dtmf 2

212756.637 3564 10 r dtmf 1

212757.567 3564 10 r dtmf #

212758.811 2504 10 fn PlayStart(iLineId=10, sFileList=,C:\Program Files\AIMS\AIMS IVR\SoundFiles\213_InvalidPersonalCode.wav,C:\Program Files\AIMS\AIMS IVR\SoundFiles\201_PersonalCode.wav, sXMLOptions=)

 

212805.458 3564 10 r dtmf 2

212806.688 3564 10 r dtmf 9

212807.923 3564 10 r dtmf 1

212809.183 3564 10 r dtmf 2

212810.473 3564 10 r dtmf 1

212811.613 3564 10 r dtmf #

212812.870 2504 10 fn PlayStart(iLineId=10, sFileList=,C:\Program Files\AIMS\AIMS IVR\SoundFiles\202_AssetCode.wav, sXMLOptions=)

 

 

and on a previous call the following kypresses were detected: 175 and then 2175, both of which were incomplete product codes:

 

212555.272 3564 3 r dtmf 1

212556.082 3564 3 r dtmf 7

212557.582 3564 3 r dtmf 5

212558.602 3564 3 r dtmf #

212559.842 2504 3 fn PlayStart(iLineId=3, sFileList=,C:\Program Files\AIMS\AIMS IVR\SoundFiles\213_InvalidPersonalCode.wav

 

212606.644 3564 3 r dtmf 2

212607.724 3564 3 r dtmf 1

212608.594 3564 3 r dtmf 7

212611.024 3564 3 r dtmf 5

212612.254 3564 3 r dtmf #

212613.511 2504 3 fn PlayStart(iLineId=3, sFileList=,C:\Program Files\AIMS\AIMS IVR\SoundFiles\213_InvalidPersonalCode.wav,C:\Program Files\AIMS\AIMS IVR\SoundFiles\201_PersonalCode.wav, sXMLOptions=)

 

So looks like there are general problems with DTMF tone detection on this system, not just with detection of dtmf tones that are the same as the previous tone.

 

 

Would recommend that you test the DTMF tone transmission over this VoIP connection by just using a "Get Numbers module" and setting it to accept a long number string (eg: 40 characters) and then jsut dialing into system and pressing keys like this:

1234567890123456789012345678901234567890

1122334455667788990011223344556677889900

1111222233334444555566667777888899990000

etc.

 

Running a few tests that are desgned to better test DTMT detection will let you better see how the system actually behaves.

 

Some VoIP based systems that have poor quality connections or poorly perform their own DTMF tone detections before passing them to system "RFC2833" events.

In these cases your would need to speak to VoIP service provider (or ensure that VoIP architecture in place guarantees you good VoIP connectivity).

 

 

If posting traces in future please include the vgEngine trace as well.

[lucasklos]

Hello,

The Cisco PBX is Cisco Call Manager.

I will do the test you recomend.

 

Thanks.

[SupportTeam]

This only happens when calling from a phone thru a Cisco PBX. When calling from a softphone everything goes well.

If the problem only occurs on external incoming calls and not on calls made from Cisco extensions, then most likely the problem is caused by your VoIP provider giving you a poor quality VoIP trunk over which the external calls arrive into our system.

[lucasklos]

I'm Sorry, but I couldn't understand your reply.

Just to clarify:

The complete system includes 4 lines, all of them used in a local network. Every incoming call go from the phone to Cisco Callmanager and then to VoiceGuide, except the ones I made for test using SJPhone.

[SupportTeam]

Every incoming call go from the phone to Cisco Callmanager

By 'phone' do you mean a CallManager extension?

Do you use physical Cisco phones for the CallManager extensions or do you use Cisco softphones?

 

If the SJPhone is working fine but calls from Cisco extensions do not work then most likely what is happening is that the Cisco Callmanager is performing its own DTMF tone detections and passing them on as "RFC2833" events - and not doing a good job of it.

 

WireShark traces capturing the problem call will let us see what is happening.