Doing Answer Detection

[F.B.]

Hi,

we have a fresh Installation with the Downloadlinks from your Website.

Configured a SIP Trunk with our Anynode SBC. 

Inbound Call is ok. Sometimes i do not hear the Script. But Inbound is not our priority right now.

 

What doesn´t work:

When we start an Outbound Call the Smartphone Rings. After answering the Call nothing happens. Call Monitor shows "doing Answer Detection". Of course i tryed to say "Hello" and more...

 

Any Idea what the Problem could be here?

 

Thanks

[SupportTeam]

Quote

Inbound Call is ok. Sometimes i do not hear the Script.

If you can't hear the sound file being played then this suggests you have some networking problem that prevents the voice data carrying RTP packets from (sometimes) being delivered to destination.

You should resolve this first.

It's probably the same reason why on outbound calls VoiceGuide can't hear the called person saying 'hello'.

Resolving this will involve looking at your networking setup and using WireShark or similar tools to confirm that RTP packets are being sent out correctly.

 

It's best to do test calls on local network first, with a SIP phone/softphone installed on same network segment as VoiceGuide. This will let you confirm operation of system itself, and you can then debug if RTP packets are being passed though any routers/firewalls/devices that are in the network path.

 

On outbound calls you can also try setting the "Answering Machine" text field to be: DISABLE

This way VoiceGuide will start the "Live Person Answer" script immediately when call is picked up - without waiting for anybody to say "hello" or any voicemail prompt starting to play etc.

see: https://www.voiceguide.com/vghelp/source/html/detectcallanswer.htm

[F.B.]

I made some Tests with Wireshark running. Pcap and Logs attached. Maybe you can analyze them?

Inbound:

1. Call no script playing
2. Call ok 
3. Call ok
4. Call no script playing
5. Call Evaluation block

outbound:
1 - no detection - bye after 12-15 seconds
2 - no call on phone
3 - no detection
4 - no call on phone
5 - no detection - script after 30-35 seconds
6 - no call on phone
7 - Evaluation block

 

Quote

On outbound calls you can also try setting the "Answering Machine" text field to be: DISABLE

I already read about this Option but i can´t find them. Where can i disable the Detection?

 

Thank you!
 

Inbound_Test.pcapng

logs inbound test.zip

Outbound_Test.pcapng

Outbound Test.zip

[SupportTeam]

Looking at inbound calls:

5 calls captured by WireShark:

with 1st call at WireShark's 46.547 second timestamp.

call comes form IP 172.16.0.74 and is answered by Dialogic HMP / VoiceGuide system at IP 192.168.144.31.

We can see that RTP packets are sent from 192.168.144.31 to 172.16.0.74 immediately after answer:

 

and when playing the RTP data in WireShark we can see that Dialogic HMP/VoiceGuide played out the credit card payment demo starting message:

 

so the voice data was sent out on first call.

VoiceGuide completed playing the sound file, then waited about 7 seconds and started transmitting the sound file again - and call was ended when calling party hung up halfway through that second sound file play, almost 21 seconds after starting the call:

 

ktTel trace matches up with above. relevant events logged in ktTel log:

183 033527.813 49144   3   1 ev    GCEV_OFFERED crn=8000001 ()
251 033527.971 49144   3   1 ev    GCEV_ANSWERED crn=8000001 ()
259 033528.019 49144   3   1 ev    GCEV_LISTEN
284 033536.645 49144   2   1 ev    TDX_PLAY (Play Completed)
326 033548.437 49144   3   1 ev    GCEV_DISCONNECTED crn=8000001 q: 3/3
351 033548.479 49144   3   1 ev    GCEV_DROPCALL crn=8000001
358 033548.561 49144   3   1 ev    GCEV_RELEASECALL crn=8000001
362 033548.592 49144   2   1 ev    TDX_PLAY (Play Completed)

 

so you need to figure out why caller did not hear anything on first call.

The RTP packets were sent out - but looks like something along the path has blocked them later on...

 

Note that we can see a "P-Xz-Sipua-Dialog-Identifier" field in the INVITE header, so it looks like you have some border controller type device (Cisco?) that is relaying the SIP/RTP traffic to/from VoiceGuide.

 

The problem is most likely in the way this device at IP 172.16.0.74 passes the RTP voice data traffic. But it could also be some other network device that you have this call traveling through. Looks like something in your network path is not handling the SIP/RTP data traffic well...

Resolving this must be done first. The you can move onto outbound calls - where right now it looks like SIP messages themselves are not being correctly routed out of your system on alternate calls...

 

Recommend speaking to the network administrators who are configuring the devices on your network through which the VoIP calls travel. Show them this post and the .pcapng files captured on your network that show that sound data is sent out.

If you have any devices in your network path that try to further manage SIP traffic (like what some border controllers do), then you should look closely at how well that works on those devices or if any setting can be changed on those devices that would resolve the issue. Otherwise you may want to consider turning off those devices' SIP-level management functionality and just rely on basic IP routing to ensure that SIP and RTP traffic is routed correctly.

[SupportTeam]

Quote

I already read about this Option but i can´t find them. Where can i disable the Detection?

Are you loading outgoing calls using the Outbound Call loader app ?

In the Outbound Call loader app the Answering Machine script/sound/action is set on the "Scripts" page. Please see below:

 

 

 

[F.B.]

Hi,

 

i got a reply from our Phone Company. They looked at a  Trace where no Sound/Script was playing on the Phone.

1.: Voiceguide sends "Busy here" to an Option Packet after INVITE. I think this is because we use the Evaluation Version? This is maybe a Problem for the SBC.                                                              There is also no trying and ringing Packet. But this is apperently no Problem for the SBC.

 2.: Our Session Border Controller asks for Payload on Port 20753. But Voiceguide sends to Port 20752. Is there a negotiation Problem?

3.: The Frame Rate should be 20 ms. Voiceguide sends with 10 ms. 

 

I send you the same Trace as our Phone Company got.

Thank you.

 

test.pcapng

[SupportTeam]

Quote

1.: Voiceguide sends "Busy here" to an Option Packet after INVITE. I think this is because we use the Evaluation Version?

This is most likely because you are running a 1 line evaluation license from Dialogic HMP.

Note that the OPTIONS message sent before the INVITE is being responded to:

and it's only the OPTIONS messages sent 6 seconds after call answer that are being replied to with a "486 Busy Here" - while that one evaluation channel is busy on an active call, and the system is not able to accept any new calls:

 

 

Quote

There is also no trying and ringing Packet. But this is apperently no Problem for the SBC.  

The "100 Trying" and "180 Ringing" are optional messages. And in cases where system answers call immediately they are unnecessary - so the Dialogic HMP just immediately sends the "200 OK" to indicate call is answered.

 

Quote

2.: Our Session Border Controller asks for Payload on Port 20753. But Voiceguide sends to Port 20752. Is there a negotiation Problem?

Traditionally RTP was sent on even numbered ports only.

original RFC2327 https://www.ietf.org/rfc/rfc2327.txt : at bottom of page 18: "For RTP compliance it should be an even number."

RFC4566 https://www.ietf.org/rfc/rfc4566.txt  and RFC8866 https://www.ietf.org/rfc/rfc8866.txt don't have that recommendation anymore, but for backward compatibility many SIP devices stick to using even ports for RTP and next-up odd port for RTCP.

Recommend asking whoever is configuring this SBC to get it configured so that it uses even numbered ports when specifying it's RTP ports...

This could be as simple as setting the start of the allowed RTP port range to be an even number, and then setting a "RTP UDP Port Spacing” type setting to be an even number as well, but it depends on device.

Looks like the Dialogic HMP is set to adhere to follow the old RFC recommendations of using the even RTP port numbers only, and just ignores the lats bit in the port number - dropping back to an even number in cases where odd number is specified...

Quote

The Frame Rate should be 20 ms. Voiceguide sends with 10 ms.

Looking at the INVITE and OK responses it does not look like any particular packet size was requested by either side. VoiceGuide / Dialogic HMP defaults to 10ms as this setting minimizes time delays between the two parties.

[F.B.]

So finally we could get it to work. Our SBC has an Option for the Port Problem.

But there was one more thing: I installed with the Option a-Law. Our SBC allowed both Options. Voiceguide was still sending with u-Law and we answered with a-Law. SBC is now on a-Low only. Now we have a working Answer Detection and the Frame Rate is at expected 20 ms.

 

One more Question: We use the System with SIP Trunk. Is there a Way to configure the From Header? So we can choose our outgoing Number?

Currently only the IP is transmitted in the from header.

[SupportTeam]

Quote

Is there a Way to configure the From Header? So we can choose our outgoing Number?

 

Please see: https://www.voiceguide.com/vghelp/source/html/dial_voip.htm

from that page:

Quote

The CallerID ("From:" field) on outgoing calls can be specified using the <CallerID> tag in the call's Options, in this format:

<CallerID>accountnumber@voipprovider</CallerID>

 

You can also set other custom headers on outgoing calls. See towards the bottom of that page.