Can Hear Played Sound Files On Local Voip Calls OK,

[SupportTeam]

gjalil wrote:

 

You know that I work with VoIP, my master telephony service is a 3COM NBX-V3000 system, in there are one E1 digital line card for incomming calls from the PSTN. For transfer the calls(internal / external) I use the 3com dial plan.

 

When I test the IVR from my extension (local area network) the IVR receive the call and begins to run the Script, I can hear the wav files, make querys to the database and finish the call very well.

 

But when I test making an external call (from PSTN) the IVR receive the call transferred from 3com and the script begins to run but I can't hear the wav file. If I press the buttons in the telephone the IVR receive the DTMF tones and I can query the database and execute all the script very well. The problem is that I can't hear the wav files

 

Can You help me?

[SupportTeam]

If VoiceGuide is sending out the RTP with sound data to the 3COM (this can be confirmed using WireShark) then it looks like it's the 3COM that is not functioning correctly in converting the RTP stream over and playing it on the E1 channel.

 

A good test would be to stop VG and use a softphone (eg SJPhone) on the same server to answer the incoming calls. If you still cannot hear what is said over the softphone then you can demonstrate this easily to 3COM.

 

If you find that using any of the softphones does result in a connections where both parties can hear each other then please make a capture of the WireShark traces for both the softphone connection and the HMP/VG connection and post them here.

 

[gjalil]

I test with the SJPhone in the IVR Server (The IVR is stopped).

1. I make an internal call and can hear the voice in both sides. It's OK.

2. I make a call from PSTN and the caller can hear my voice too. It's OK.

 

The problem is when the IVR is started. The calls from the PSTN can't hear the wav files from the IVR.

 

I send You the WireShark traces that I get from the IVR Server. I can't get traces from the PSTN, that E1 card is installed into the NBX chassis and the NBX system runs under VxWorks, I can't install another software in that device.

 

If You can show me how to get traces in that system, I tray it.

 

[SupportTeam]

We would only need the WireShark traces from the PC on which the IVR is installed.

 

Run a WireShark trace during the PSTN call answered by the IVR. Have IVR play something and have caller say something and press some DTMF tones.

 

Then stop IVR and run another WireShark trace during a PSTN call answered by SJPhone. Makes sure both parties speak to each other during the call and each presses some DTMF tones.

 

Please post both traces here. Post the entire trace, not an extract from it.

[SupportTeam]

gjalil wrote:

 

I send to You the WireShark traces.

 

In this traces I make 2 calls, the first is internal call, in this case the caller can hear the wav files from the IVR.

 

The second call is from PSTN, in this case the caller can’t hear the wav files.

 

 

In both calls I press 4 and before I press 0 and 9 in the telephone keypad.

 

[SupportTeam]

Please also make a WireShark trace during a PSTN call answered by SJPhone.

 

In the traces supplied so far all the calls seem to originate from same IP address (192.168.1.1). I would expect calls form 3COM to have a different IP source then calls from a test softphone. Why are the IPs the same?

 

Or is the internal call not a direct softphone call, but is in fact still going through the 3COM?

[SupportTeam]

Looking closer at the trace we can see that both calls were made through the 3COM. But that 3COM behaves differently when the call arrives on the external E1 instead of the internal call.

 

Looks like on external call the 3COM is doing a "RE-INVITE", instead of setting up a call using a single INVITE.

 

HMP is now responding with a "Status-Line: SIP/2.0 488 Not Acceptable Here" error.

 

Trace shows the 3COM is not ending a call in response to the 488 error, and it is still sending and RTP stream, but looks like internally the 3COM is not connecting the voice path as the RTP stream contains silence.

 

Are there any options available on the 3COM which you think may make it stop using the second INVITE if the call it has comes from the external E1 line? You can probably pass this question onto 3COM support.

 

Is 084170262 the external phone number from where the call is made?

 

 

 

INVITE from first call:

 

From: "Gonzalo Jalil"<sip:1398@192.168.1.1>;tag=1199837025

Call-Id: 0A1199837025B0C@192.168.1.110

Contact: "3ComCallProcessor"<sip:3ComCallProcessor@192.168.1.1:5060;transport=UDP>

P-Asserted-Identity: "Gonzalo Jalil"<sip:1398@192.168.1.1>

 

INVITEs from second call:

 

From: "Mensajeria SIP"<sip:7999@192.168.1.1>;tag=1199837048

Call-Id: 0A1199837048B0C@192.168.1.110

Contact: "3ComCallProcessor"<sip:3ComCallProcessor@192.168.1.1:5060;transport=UDP>

P-Asserted-Identity: "Mensajeria SIP"<sip:7999@192.168.1.1>

 

From: "Mensajeria SIP"<sip:7999@192.168.1.1>;tag=1199837048

Call-Id: 0A1199837048B0C@192.168.1.110

Contact: "3ComCallProcessor"<sip:3ComCallProcessor@192.168.1.1:5060;transport=UDP>

P-Asserted-Identity: "e1 - 7254 - SETEL"<sip:084170262@192.168.1.1>

 

SIP messages extract attached.

3COM_Invites.zip

[SupportTeam]

We will also look into this on our side to see if we can have VoiceGuide/HMP accept this REINVITE message.

 

To get this done we would need to get the trace of the external E1 PSTN call answered by SJPhone.

 

 

[gjalil]

Good morning Support,

 

Recently I download the las VG Setup (VoiceGuide_7.0.4_reinvite.exe).

I'm going to install and make test with this and send the new traces making internal and external calls and in the IVR server running the SJphone.

 

I will send an email for You when I send the WireShark traces and the VG Log Files, approximately in 30 minutes.

 

 

About the previews questions.

My 3com server IP address is 192.168.1.1, the E1 line card is 192.168.1.3, My 3com telephone IP address is 130.40.13.87 and the IVR IP address is 192.168.1.100.

 

I make calls from the telephone IP address and from the telephone number that You found in the traces.

 

The callerID is in the 3COM CDR, but in the VG CDR only show the IP Address of the 3com, this is not important and maybe I will make another topic Forum another day, the most important is enable the IVR from the PSTN in my VoIP infrastructure.

 

Thanks.

[gjalil]

I send to You the traces, but something rare happens. I have two IP Telephones, 130.40.xxx.xxx and 130.1.xxx.xxx, from 130.1.xxx.xxx I can hear the wav files but from 130.40.xxx.xxx I cannot hear anything.

 

From E1 line card I cannot hear anything too but this is in the same subnet of the 3com system.

 

In the email I wrote all the detail comments and the traces / log files.

 

Thanks for help.

[gjalil]

I make a new test.

 

The problem is not routes or switch configuration.

I put in the same switch the 3com central 192.168.1.1, 3com E1 line card 192.168.1.3, IVR 192.168.1.110.

 

I make calls from the PSTN (E1 to IVR) and cannot hear nothing.

[SupportTeam]

gjalil wrote:

 

I installed the VoiceGuide_7.0.4_reinvite.exe and extract the WireShark traces of the following tests:

 

1. AudioSJphone.pcap: Sjphone enabled in the server and make calls from the telehone 3com (130.40.13.46) and external call to E1 line card.

In both cases the caller can hear my voice.

2. AudioIVR_cant_hear_both.pcap: VG enabled in the server and make calls from the telehone 3com (130.40.13.46) and external call to E1 line card.

In both cases the caller cannot hear the wav files.

3. AudioIVR_cant_hear_E1.pcap: VG enabled in the server and make calls from the telehone 3com (130.1.24.62) and external call to E1 line card.

With telephone 3com I can hear the wav files, but from E1 line card I cannot hear the wav files.

 

In the attached file there are the VG log files.

 

[SupportTeam]

The call setup for all calls now looks fine. No errors are seen.

 

When looking at the AudioIVR_cant_hear_both.pcap trace we can using WireShark see that the RTP streams for both directions were established on both calls and voice data was carried by those RTP streams at all times. These streams can be played back using WireShark (menu: Statistics->VoIP Calls)

We can also see that on the E1 call when the touch tone key was pressed the sound files that was played was changed, suggesting that the IVR responded to the tone and jumped to the next module. This seems to be confirmed by the corresponding VG traces. You should also be able to confirm using the VG Line Status Monitor that VG detects the tones and goes to next module etc.

 

So the voice sems to be sent out OK from IVR but there is a problems somewhere along the way as we cannot hear when calling from external E1 or one of the handsets...

 

As we have an example of calls working form one 3COM phone and not working from another 3COM phone we though it may be best to try to resolve this first and see if this may cast light on what is happening here.

 

We compared the SIP traces from the two 3COM telephones - the one that works fine:

 

From: "Gonzalo Jalil"<sip:1398@192.168.1.1>;tag=1199894298

 

and one that does not work:

 

From: "de Computo Centro"<sip:1102@192.168.1.1>;tag=1199893387

 

The SIP traces on both calls have identical options selected and confirmed and we can see that VoiceGuide/HMP is sending the voice RTP signal on both calls.

The only difference is the end phones are on different subnets (as you describe). (trace extracts attached)

 

Have you tried moving the non working phone to be on the same subnet as the working one (130.1.x.x)?

 

It is a bit hard to see what information is arriving at the non-working phone as we cannot do a WireShark trace. Is it possible to register SJPhone (or XLite etc) as an extension with the 3COM? That way we could do a WireShark trace or SIP/RTP both at the IVR and at the SJPhone used to make the call and we can better pinpoint where the voice path is getting cut off...

 

AudioIVR.zip

[SupportTeam]

Another thing that we noticed when looking though the traces is that for calls coming from the 3COM the 3COM is not sending any "Session Description Protocol" (SDP) information in the original INVITE message.

 

So the voice codec options to use on the voice path are not specified at call setup. And then the SDP in the OK response sent back from VoiceGuide/HMP to 3COM does not contain a codec list or selection either (SJPhone ignores the fact that no codecs were provided by 3COM and instead suggests it's own list)

 

We will need to look into if we can make HMP ignore the fact that no SDP is sent and instead propose it's own codec options in the "OK" response's SDP field (like SJPhone does) - which the 3COM could then select in the ACK response (a sit does with SJPhone)...

 

Looks like all the devices that we use in our testing send SDP during the initial SIP INVITE message, so not sending the SDP is a bit unusual. Maybe you could ask 3COM if there is a way to change 3COM config so that it sends SDP info in the initial IVITE message?

 

[SupportTeam]

The sending of SDP in the INVITE message is called "Fast Start" and awaiting for SDP to be returned in the OK is called "Slow Start" or "Delayed Offer". There may be a setting in the 3COM to select for "Fast Start" to be used. "Fast Start" is usually the default on modern equipment.

 

"Slow Start" is supported by HMP on outbound calls, but we would need to check why HMP appears not to respond to "Slow Start" inbound calls by including the codec list in the SDP returned in "OK".

[gjalil]

The truth is that I do not want to waste time asking to 3com about integrations with third party software because I know that the answer will be that not give support when working with third party. Without comments...

 

------------------

 

I make changes in the IVR configuration, now I use the VoIPRegistration section in the Config.xml so the IVR is registered like an extension in Asterisk, the extension number is 2731. The incoming calls from the E1 line card(3com) are transfered to this extension.

 

E1 -> 3com -> Asterisk -> IVR

 

192.168.1.1 3comNBX

192.168.1.3 E1 line card

130.2.12.101 Asterisk Server

130.2.12.102 IVR Server

 

Now the IVR work very well, when the incoming call from the PSTN is transfered to extension 2731 the IVR server receive the call and begin to run the Script, the caller can hear the wav files, the IVR catch the DTMF tones, but the IVR begins to receive duplicate DTMFs. In the test I always press 0910375617, but the IVR repeat the digits, the problem is when I use the function Get Number. For example, in the log files You can see the following data:

 

0910375617

09910375617

091037556177

0910375617

0910375617

0910375617

0910375617

09103775617

 

But in the WireShark traces You can see that there is not repeat DTMF tones.

The WireShark traces was sent by email.

 

What is happening?

 

Please help me, I think this is the last issue, I need to release this IVR to the customers.

 

Thanks.

[SupportTeam]

Supplied traces show the duplicate DTMFs are reported by the HMP layer, and IVR just reacts to what is reported by the HMP.

From the WireShark traces we can see that right now on this system the HMP sees the DTMF tones arrive in 2 ways: as audible 'Inband' tones and as RFC2883 messages.

Looking at the WireShark's voice recording received by the HMP on the second call, we can see that the duplicated 9 does seem like a separate short tone which is present on the line about 300-400ms after the first DTMF 9 tone ended. The second DTMF tone was there for close to 100ms - long enough to be considered a valid tone.

But we do not see such duplicates on the 3rd call, and in both cases the duplicate DTMFs arrive 200ms after the first report.

The RFC2883 messages seen in the trace do not duplicate the DTMF tones, so a resolution would be to ensure that the audible Inband tones are not sent and that the DTMF tones are only sent using RFC2883.

Suggest looking into whether the 3COM or Asterisk can 'clamp' the DTM tones - to ensure that only the RFC2883 messages are received by the HMP, and no audible Inband tones are played.

We have also set some HMP options within the new version of VoiceGuide available from here: [old link removed] Please update to this newest version and see if this maybe fixes the occasional duplication of tones.

Getting the tones to be clamped before arriving at the IVR would be best.


2nd call:

ktTel (HMP)

210454.505 1020 006 CtEventProcess (from store) idx=53, iDev=6, lEvtType=134, pEvtData=0x71524e8, lEvtDataLen=4, (store: evinque=0, maxever=2)
210454.505 1020 006 metaevent: cclibid=0x0, crn=0x0, evtdatap=0x65886e0, evtdev=0x6, evtlen=0x4, evttype=0x86, extevtdatap=0x0, flags=0x0, linedev=0x0, magicno=0xbad012fb, rfu1=0x0, usrattr=0x0 (usrattr=hli)
210454.505 1020 006 ev TDX_CST (CST Event Received)
210454.505 1020 006 TDX_CST DE_DIGITS data=57 [9], SpeedVolKeyControlsUsed=0
210454.505 1020 007 raise ev dtmf 9
210454.755 1020 006 CtEventProcess (from store) idx=54, iDev=6, lEvtType=134, pEvtData=0x7152518, lEvtDataLen=4, (store: evinque=0, maxever=2)
210454.755 1020 006 metaevent: cclibid=0x0, crn=0x0, evtdatap=0x65886e0, evtdev=0x6, evtlen=0x4, evttype=0x86, extevtdatap=0x0, flags=0x0, linedev=0x0, magicno=0xbad012fb, rfu1=0x0, usrattr=0x0 (usrattr=hli)
210454.755 1020 006 ev TDX_CST (CST Event Received)
210454.755 1020 006 TDX_CST DE_DIGITS data=57 [9], SpeedVolKeyControlsUsed=0
210454.755 1020 007 raise ev dtmf 9

VG

210454.505 9 7 ev dtmf 9 (0,57,0)
210454.505 9 7 ScriptEventCode 9, code=57, state=1301
210454.505 9 7 LsGetNbrsRxDigits 9,9
210454.505 9 7 state [Pedir Cedula] Number Input 09
210454.505 9 7 path {09} not found
210454.505 9 7 timer set 6 EV_TIMEOUT_ENTERDATA
210454.755 9 7 ev dtmf 9 (0,57,0)
210454.755 9 7 ScriptEventCode 9, code=57, state=1301
210454.755 9 7 LsGetNbrsRxDigits 9,9
210454.755 9 7 state [Pedir Cedula] Number Input 099


3rd call:

210533.693 1020 009 CtEventProcess (from store) idx=81, iDev=9, lEvtType=134, pEvtData=0x7152a28, lEvtDataLen=4, (store: evinque=0, maxever=2)
210533.693 1020 009 metaevent: cclibid=0x0, crn=0x0, evtdatap=0x65886e0, evtdev=0x9, evtlen=0x4, evttype=0x86, extevtdatap=0x0, flags=0x0, linedev=0x0, magicno=0xbad012fb, rfu1=0x0, usrattr=0x0 (usrattr=hli)
210533.693 1020 009 ev TDX_CST (CST Event Received)
210533.693 1020 009 TDX_CST DE_DIGITS data=53 [5], SpeedVolKeyControlsUsed=0
210533.693 1020 010 raise ev dtmf 5
210533.896 1020 009 CtEventProcess (from store) idx=82, iDev=9, lEvtType=134, pEvtData=0x7152a58, lEvtDataLen=4, (store: evinque=0, maxever=2)
210533.896 1020 009 metaevent: cclibid=0x0, crn=0x0, evtdatap=0x65886e0, evtdev=0x9, evtlen=0x4, evttype=0x86, extevtdatap=0x0, flags=0x0, linedev=0x0, magicno=0xbad012fb, rfu1=0x0, usrattr=0x0 (usrattr=hli)
210533.896 1020 009 ev TDX_CST (CST Event Received)
210533.896 1020 009 TDX_CST DE_DIGITS data=53 [5], SpeedVolKeyControlsUsed=0
210533.896 1020 010 raise ev dtmf 5
210534.380 1020 009 CtEventProcess (from store) idx=83, iDev=9, lEvtType=134, pEvtData=0x7152a88, lEvtDataLen=4, (store: evinque=0, maxever=2)
210534.380 1020 009 metaevent: cclibid=0x0, crn=0x0, evtdatap=0x65886e0, evtdev=0x9, evtlen=0x4, evttype=0x86, extevtdatap=0x0, flags=0x0, linedev=0x0, magicno=0xbad012fb, rfu1=0x0, usrattr=0x0 (usrattr=hli)
210534.380 1020 009 ev TDX_CST (CST Event Received)
210534.380 1020 009 TDX_CST DE_DIGITS data=54 [6], SpeedVolKeyControlsUsed=0
210534.380 1020 010 raise ev dtmf 6
210536.115 1020 009 CtEventProcess (from store) idx=84, iDev=9, lEvtType=134, pEvtData=0x7152ab8, lEvtDataLen=4, (store: evinque=0, maxever=2)
210536.115 1020 009 metaevent: cclibid=0x0, crn=0x0, evtdatap=0x65886e0, evtdev=0x9, evtlen=0x4, evttype=0x86, extevtdatap=0x0, flags=0x0, linedev=0x0, magicno=0xbad012fb, rfu1=0x0, usrattr=0x0 (usrattr=hli)
210536.115 1020 009 ev TDX_CST (CST Event Received)
210536.115 1020 009 TDX_CST DE_DIGITS data=49 [1], SpeedVolKeyControlsUsed=0
210536.115 1020 010 raise ev dtmf 1
210537.146 1020 009 CtEventProcess (from store) idx=85, iDev=9, lEvtType=134, pEvtData=0x7152ae8, lEvtDataLen=4, (store: evinque=0, maxever=2)
210537.146 1020 009 metaevent: cclibid=0x0, crn=0x0, evtdatap=0x65886e0, evtdev=0x9, evtlen=0x4, evttype=0x86, extevtdatap=0x0, flags=0x0, linedev=0x0, magicno=0xbad012fb, rfu1=0x0, usrattr=0x0 (usrattr=hli)
210537.146 1020 009 ev TDX_CST (CST Event Received)
210537.146 1020 009 TDX_CST DE_DIGITS data=55 [7], SpeedVolKeyControlsUsed=0
210537.146 1020 010 raise ev dtmf 7
210537.349 1020 009 CtEventProcess (from store) idx=86, iDev=9, lEvtType=134, pEvtData=0x7152b18, lEvtDataLen=4, (store: evinque=0, maxever=2)
210537.349 1020 009 metaevent: cclibid=0x0, crn=0x0, evtdatap=0x65886e0, evtdev=0x9, evtlen=0x4, evttype=0x86, extevtdatap=0x0, flags=0x0, linedev=0x0, magicno=0xbad012fb, rfu1=0x0, usrattr=0x0 (usrattr=hli)
210537.349 1020 009 ev TDX_CST (CST Event Received)
210537.349 1020 009 TDX_CST DE_DIGITS data=55 [7], SpeedVolKeyControlsUsed=0
210537.349 1020 010 raise ev dtmf 7
210538.255 1020 009 CtEventProcess (from store) idx=87, iDev=9, lEvtType=134, pEvtData=0x7152b48, lEvtDataLen=4, (store: evinque=0, maxever=2)
210538.255 1020 009 metaevent: cclibid=0x0, crn=0x0, evtdatap=0x65886e0, evtdev=0x9, evtlen=0x4, evttype=0x86, extevtdatap=0x0, flags=0x0, linedev=0x0, magicno=0xbad012fb, rfu1=0x0, usrattr=0x0 (usrattr=hli)
210538.255 1020 009 ev TDX_CST (CST Event Received)
210538.255 1020 009 TDX_CST DE_DIGITS data=35 [#], SpeedVolKeyControlsUsed=0
210538.255 1020 010 raise ev dtmf #


210533.693 9 10 ev dtmf 5 (0,53,0)
210533.693 9 10 ScriptEventCode 5, code=53, state=1301
210533.693 9 10 LsGetNbrsRxDigits 5,5
210533.693 9 10 state [Pedir Cedula] Number Input 0910375
210533.693 9 10 path {0910375} not found
210533.693 9 10 timer set 6 EV_TIMEOUT_ENTERDATA
210533.896 9 10 ev dtmf 5 (0,53,0)
210533.896 9 10 ScriptEventCode 5, code=53, state=1301
210533.896 9 10 LsGetNbrsRxDigits 5,5
210533.896 9 10 state [Pedir Cedula] Number Input 09103755
210533.896 9 10 path {09103755} not found
210533.896 9 10 timer set 6 EV_TIMEOUT_ENTERDATA
210534.380 9 10 ev dtmf 6 (0,54,0)
210534.380 9 10 ScriptEventCode 6, code=54, state=1301
210534.380 9 10 LsGetNbrsRxDigits 6,6
210534.380 9 10 state [Pedir Cedula] Number Input 091037556
210534.380 9 10 path {091037556} not found
210534.380 9 10 timer set 6 EV_TIMEOUT_ENTERDATA
210536.115 9 10 ev dtmf 1 (0,49,0)
210536.115 9 10 ScriptEventCode 1, code=49, state=1301
210536.115 9 10 LsGetNbrsRxDigits 1,1
210536.115 9 10 state [Pedir Cedula] Number Input 0910375561
210536.115 9 10 path {0910375561} not found
210536.115 9 10 timer set 6 EV_TIMEOUT_ENTERDATA
210537.146 9 10 ev dtmf 7 (0,55,0)
210537.146 9 10 ScriptEventCode 7, code=55, state=1301
210537.146 9 10 LsGetNbrsRxDigits 7,7
210537.146 9 10 state [Pedir Cedula] Number Input 09103755617
210537.146 9 10 path {09103755617} not found
210537.146 9 10 timer set 6 EV_TIMEOUT_ENTERDATA
210537.349 9 10 ev dtmf 7 (0,55,0)
210537.349 9 10 ScriptEventCode 7, code=55, state=1301
210537.349 9 10 LsGetNbrsRxDigits 7,7
210537.349 9 10 state [Pedir Cedula] Number Input 091037556177
210537.349 9 10 path {091037556177} not found
210537.349 9 10 timer set 6 EV_TIMEOUT_ENTERDATA
210538.255 9 10 ev dtmf # (0,35,0)

[gjalil]

I downloaded and installed the last distribution file, but one of 7 tests has an error.

 

I'm goin to tray to follow that You suggest, review in asterisk or 3com how

send only the RFC2883 messages to HMP server.

 

Otherwise, I'm goin to release the IVR tomorrow. But I noticed that always at the next day the incoming calls appears in the Line Status, but not execute the script. In the log files show "AnswerTheCall: Evaluation time expired".

 

We bought license for 4 lines and follow the instructions to activate in the License Manager.

 

What is the matter?

I attached the log files.

 

Thanks.

0111_1045_vgEngine.txt

0111_ktTel.txt

[SupportTeam]

In the vgEngine traces we can see:

 

210026.742 5 no license file C:\Program Files\VoiceGuide\userinfo.lic

210026.805 5 reg , lines: 30 id: | [removed]

 

So looks like the license was not applied. If license was applied the userinfo.lic file would be created by the VG License Manager.

Please apply the license again and confirm the userinfo.lic is created.

The "reg" line in vgEngine trace still does not confirm the license type and number of lines then email the created userinfo.lic file to sales@voiceguide.com

 

Alternatives to E1 -> 3com -> Asterisk -> IVR system setup may be to just attach the IVR to 3COM's Analog or E1 interfaces directly. This would require purchasing Dialogic Cards for the interface.

[SupportTeam]

The version of VoiceGuide v7 available for download from our WWW now has some changes which we are advised should let HMP correctly negotiate codecs on "Slow Start" VoIP calls as well.

 

If you are going to try this new version to connect directly to 3COM (without going through Asterisk) the please post the VG and WireShark traces of the calls here and we can confirm is the codec negotiation is now done correctly on 3COM's "Slow Start" VoIP calls.

 

[gjalil]

Hi Support,

 

I make new tests with the last distribution file (download from the website), I send an email with the logs and traces.

There are 2 tests:

 

1. ThroughAsterisk: Config.xml modified with VOIP_Registration information.

2. Through3COM: default Config.xml.

 

In both cases I make 3 calls and always press the numer 123456789 with the pound key at the end:

 

1. From internal number (3com telephone)

2. From external telephone (PSTN/E1)

3. From external telephone (PSTN/E1)

 

Only when the call came from PSTN through 3COM the caller can't hear the wav files.

[SupportTeam]

We looked at the WireShark traces and can see that still no codec negotiation was made on the "Slow-Start" calls from 3COM.

 

We will try to find some hardware which does "Slow-Start" calls to try to replicate this in on our labs.

 

Dialogic response was that HMP does support incoming Slow Start calls, and from information provided from them VoiceGuide is doing what is required of it to enable HMP's handling of Slow Start calls. Once we setup a Slow Start scenario in our labs we should be able to try various combinations and see what works.

 

Traces showed that all DTMF tones on all calls were detected correctly.

[gjalil]

According to understand there are two ways to configure the IVR in VOIP Mode(HMP Software):

 

1. SIP Direct, without fill the VOIP_registration section in Config.xml

2. SIP Proxy, fill the VOIP_registration section in Config.xml

 

I believe that SIP Direct is more simple and more natural, because in 3com I only create a Trusted SIP Trunk with the IVR IP address, and the incoming calls are transfered to this trunk. This work very well with internal calls, but from PSTN the caller can't hear anything. You are working in this issue.

 

With SIP Proxy I need to create an extension in Asterisk and into Config.XML fill the registration section. The incoming calls are transfered to Asterisk extension so the IVR answer. This work very well, internal and external calls, always the caller can hear the wav files, but from PSTN the IVR receive duplicated DTMF tones (rfc2833 and inband). I don't know how block the inband signal (the incoming data is valid for 3com and asterisk), but maybe You can create one parameter into VG.ini and the VG will work only with one type of signal. I don't know if this is possible or maybe there is a better way to resolve this problem.

 

I tray to register the IVR with one 3com extension but all the attemps failed.

 

My unique intention is release my IVR to the customers and either option is valid for me. I admit that Your are focused to resolve this problem and always answer any question, so please consider another option to resolve my problem.

 

I take another traces only with the IVR registered in Asterisk. I make three calls: two external and one internal. The problem is duplicate DTMF in VG. In the external calls the caller pressed 0918859992, in the internal call the caller pressed 123456789.

 

I send to You and email with the traces and log files.

 

Thanks and very grateful for Your help.

 

[SupportTeam]

I tray to register the IVR with one 3com extension but all the attemps failed.

Can you please post the WireShark Trace capturing the attempted registration.

 

Direct SIP is a better and simpler option, but maybe if VG is registered as an extension then 3COM may use a "Fast Start" when sending calls to it (?).

 

The last WireShark trace provided had 6 calls. 4 had inband DTMF on them a 2 did not, so I assume that fist 2 calls arrived through E1, and next 2 calls were made from internal extension and were still routed though Asterisk, and last 2 calls cam from direct SIP call without using Asterisk routing.(?)

 

On fisrst 4 calls we see duplicates, and on last 2 calls where no inband DTMF was sent we see no duplicates:

 

192026.188 9 3 state [Get Client ID] Number Input 0099118888559999922

192105.797 9 7 state [Get Client ID] Number Input 00991188885599999922

192130.976 9 10 state [Get Client ID] Number Input 1223456789

192154.617 9 13 state [Get Client ID] Number Input 1234456789

192209.148 9 3 state [Get Client ID] Number Input 123456789

192224.320 9 7 state [Get Client ID] Number Input 123456789

 

We went back to the previous trace (ThroughAsterisk.pcap) and confirmed that no duplicates were present in the two E1 calls that went through Asterisk (ie. they had Inband DTMF as well as RFC2883):

112030.450 9 7 state [Get Client ID] Number Input 123456789

112100.262 9 10 state [Get Client ID] Number Input 123456789

 

But looks like we were just lucky with those two calls then...

 

It is interesting that we can see two calls that arrived on the E1 that had no duplicates, and then we have two other calls that arrived on the E1 on which almost every DTMF is duplicated...

Any ideas on what was different between those two tests?

 

We will now try to find some hardware which can do SlowStart as well as send both Inband and RFC2883 DTMF at the same time and we'll try to figure this out.

 

[gjalil]

I send the traces trying to register in 3com from IVR and XLite. The XLite was registered, the IVR don't.

 

 

About the last Asterisk traces, I forgot to tell You that I make calls from 3 different phisical telephones: conventional telephone, celular phone and internal ipphone. Every caller make 2 calls.

 

Conventional phone(from E1) hear the wav file and press 0918859992

Celular phone(from E1) hear the wav file and press 123456789

Internal ipphone(internal network) hear the wav file and press 123456789

 

The four fisrt calls arrived from E1, seams to be that the conventional and celular phones calls are no treated in the same way. We hope that 99% of incoming calls will make from conventional phone.

 

It is interesting that we can see two calls that arrived on the E1 that had no duplicates, and then we have two other calls that arrived on the E1 on which almost every DTMF is duplicated...

Any ideas on what was different between those two tests?

 

The only thing that I do was update the VG version.

I'm goin to return one version and make the same tests.

 

[gjalil]

I send You new traces with IVR registered in Asterisk. I make 6 calls with the DTMF tones 123456789:

 

Conventional telephone through E1.

Celular telephone through E1.

Internal SIP Phone through internal network.

 

 

It is interesting that we can see two calls that arrived on the E1 that had no duplicates, and then we have two other calls that arrived on the E1 on which almost every DTMF is duplicated...

Any ideas on what was different between those two tests?

 

In the Conventional telephone the DTMF tones are duplicated every time, but from celular telephone duplicate occasionally depending on how quickly I press the keypad. In the internal call never are DTMF duplicated (slowly or quickly).

 

Is not problem about the VG version, simply when the call is made from cellular phone and press the keypad slowly the VG receive very well the DTMF tones, but if I press quickly the keypad occasionally the VG receive duplicated DTMFs.

 

The problem is that 99% of incoming calls goin to be from conventional telephones.

 

[gjalil]

Dear Support,

 

My problem with DTMF tones and Sound Files was solved!!!

 

The solution was upgrade to Asterisk 1.4, My IVR is registered like an extension in asterisk, and all the incoming calls from 3com are transferred to asterisk extension(IVR) and there is no problem with audio and dtmf tones.

 

Unfortunately I can't hear Sound files when the incoming call are transferred from 3com directly to IVR, so I use Asterisk as a gateway and the problem was solved.

 

 

Thanks again.

 

Best regards.

[SupportTeam]

Thank you for letting us know how you were able to resolve this problem.

 

If you ever have some spare time could you please post a WireShark trace capturing the call which originally arrived on E1? This would let us see how the current call setup and RTP messages differ from the previous ones on this system and help to better answer similar questions in the future.