How to read Prophecy logging

One of the best ways to troubleshoot any issue is with a fresh log of a single failed call. Rather then scrolling down through lines and lines of logging that wont really mean much, we recommend you start at the bottom of the logs and page up until you stop seeing obvious signs of the call ending or disconnecting. Once you find this last disconection message you can usually look up just a few lines to see what Prophecy is complaining about.

Note: You will see a greater level of information in Premise-based logging versus the hosted logging which has a real-time application debugger. This is because the Premise version of Prophecy exposes you to detailed platform messaging that is abstracted away in the hosted "cloud" environment. While this increase in detail may provide some complexity, it provides you with insight to deploying Prophecy 9 in custom environments.

Typical issues you might see in the logs

RTP timeout

If you see an RTP timeout, or RTP error, this is due 99% of the time to a firewall, or connectivity issue preventing proper RTP transmission. When Prophecy does not hear media or RTP for 10 seconds we assume the call has hung up, was dropped, or something unexpected occurred preventing the flow of media. As such we promptly end the call once this 10 second mark has been reached. Please insure you have Windows firewall disabled and ports 5060-5070 and ports 10,000-20,000 open for UDP traffic. Another very common cause of RTP inactivity timeouts is a commonly deployed feature Voice Activity Detection(VAD). This is used by many VOIP SIP vendors to cut down on bandwidth utilization during periods of silence or inactivity.

Example: During a conversation media is transmitted while users are actively communicating, and during periods of silence in a VAD enabled environment, no media will be transmitted, not even "silence packets."

Prophecy requires that media be transmitted constantly, in the form of silence packets and that VAD be disabled for all deployments. The main reason behind this is that VAD technology is deployed for speech recognition engines where they are listening for start and stop of speech. When VOIP introduced VAD, and ASR/Speech Recognition engine VAD compete for silence detection the results and quality of recognition is severely degraded. As such, a requirement is that all VOIP vendors be deployed with VAD disabled for your "trunk."

Typical situation: If you are calling into your Prophecy install from an external number and you hear a prompt begin to play and then cut off mid playback, this is often due to an RTP timeout. The audio sends, although once we nothing is on the line for 10 seconds, the call is cut.

An excellent tool for finding the root cause of RTP inactivity timeouts is Wireshark, which is covered in great detail here:

Using Wireshark

SIP messages related errors

Many times you can look at the last few SIP messages that will indicate the problem. Typical messages we see include the following. Note that SIP messaging is incredibly important for seeing why an outbound call failed.

SIP 404 Not Found

404 Not Found. This means a resource was not found where Prophecy was told to look. This is often a simple typo in the Routes section of the Management Console. You can look inside this SIP message and it will clearly list what it is unable to find in the URL. When placing outbound calls, this is the most common return for a number that is "bad" ie: a disconnected phone number, no long in service.

SIP 486 Busy Here

This is the most common response from a terminating end-point when the destination is busy for an attempted outbound call.

SIP 480 Temporarily Unavailable

This can happen by the terminating endpoint, because of temporary network congestion, a busy destination, or an otherwise temporarily unreachable destination.

SIP 401 Unauthorized

You will see this when trying to register with a PBX or VOIP Provider. This is usually due to an incorrect Username or Password, or the wrong registration information.

407 Proxy Authentication Required

This message is very common in setups where a Prophecy device is registering against a VOIP provider, or as an extension against a PBX device. In fact, this message appears for every request that initiates an outbound call in a setup that is using SIP registration and also on a timed interval to "make sure you are authorized to make calls." If you are not troubleshooting registration issues, you can safely ignore these messages.

SIP 503 Service Unavailable

503 Services Unavailable is a response we typically get when:

A PBX is configured but offline, or out of ports and unable to process a request from the Prophecy system.
A terminating destination is unavailable most commonly due to overload.
The VoiceXML browser is out of ports and unable to accept calls from the controlling CCXML application, in this case an error message is spoken: "Error starting VoiceXML application: Out of VoiceXML ports."

SIP 603 Decline

This error indicates that a connection was made, but the party does not want to participate. This is often related to a VOIP Provider or PBX registration. Please contact your provider to ensure everything is set up with your account correctly before opening a ticket with our Extreme Support team.

Application Errors

The most common errors you are going to encounter when utilizing the Prophecy platform are application level errors that produce compilation, parse and semantic errors. These errors are obvious and easily observed in the Prophecy Log Viewer which provides a real-time view of logging.

For example the below is listed in bright red in the log viewer and outlined clearly, such as the error below.

===========================

VoiceException:
error.semantic
XML parse error(s) occurred in: http://127.0.0.1:9990/vxml-home.xml?session.callerid=&session.calledid=vxml&session.sessionid=b96f206ba1bd4b77b4c208bf2d6e62d0&session.parentsessionid=a3e5c64fff0f0d26f0faa8cae7602fff

7): The element type "block" must be terminated by the matching end-tag "</block>".

TTS/ASR configuration Errors

The most basic TTS/ASR configuration issue a mapping that is not found by our internal provisioning DNS server.

com.voxeo.gut.exceptions.ResourceNotFoundException: NAPTR query failed [root=prophecy.local., key=en-Fail.TTS.Default.Default.map.0d735b79ef80496fb0909bf0be3e8060, code=NXDOMAIN]

As you can see, an xml:lang declaration had a value of en-FAIL which was not an available resource, and ironically, failed...

VOIP Configuration

When configuring a VOIP vendor it is very common to see this error message when placing calls using the tel: syntax at the application level.

CCX/TBJ002/2009.05.14.10.18.53.719/:db9ff9c34e100874ca5cff57d0bd57ad:-1:1/15/CTA-7cfc1562b6882e0295a73580a4d495c6/Address cannot be formatted (couldn't get a gateway), please check gateways status/configuration: tel:+11231231234

When encountered this caused by neglecting to add a specific dedicated voipgateway for Prophecy to know where the route calls destined to non-SIP destinations.



 <item name="VoipGateway1">  myvoipgateway.com </item>

Complete configuration can be found here:
VOIP Provider Integration

DTMF issues

When interfacing directly with a VOIP provider, often times configuration of your "trunk" will not be done properly on the initial setup and they will fail to properly negotiate RFC2833 for DTMF. Prophecy immediately sees this issue and reports it in the logs. Below is a strong indicator you have a configuration issue upstream of Prophecy and DTMF will fail.



RTP2:Remote party didn't supply supported DTMF codec (will use RFC2833 as default)

Of course, if you're having trouble deciphering anything in your log file which seems a bit "off", simply contact our Support team and we'll be happy to have a look for you!

ANNOTATIONS: EXISTING POSTS

0 posts - click the button below to add a note to this page

Port Conflicts

| TOC

| How to use Wireshark