Documentation

h1. Obtaining/Requesting support

AG Projects provides support via its ticketing system available at: http://support.ag-projects.com

To open a ticket you must have a login account on AG Projects support system. You need a support contract from AG Projects before opening a ticket. If you already have a support contract and login account you can " create sub-accounts for your team members":https://mdns.sipthor.net/provisioning_mdns.phtml?1=1&service=customers%40sipthor&showAddForm=1.. Use the sub-accounts to login and open support tickets. The Operator must be able to provide remote access to equipment(s) where the problem occur and must provide remote hands and eyes at the facility when necessary.

The person that opens the ticket must have good understanding about how the platform works.

h2. How to Open a Ticket

In order to receive prompt and accurate support from AG Projects, please describe a single problem per ticket. Do not mix multiple problems in one ticket.

The ticket must contain minimum the following information:

# *What* is the problem, describe it as accurately as you can

# *Where* the problem occurs - specify the SIP Account, Internet Address, URL or the hostname of the machine that exhibit the problem. In case of failed calls, please specify the Call Id, see the Failed Calls section below

# *When* the problem happened, the date and time, if the problem is still in progress and how it can be reproduced (when possible)

To speed up the process, please paste relevant information from the syslog of the machine where the problem occurs.

h2. Failed Calls

If you have a problem with failed SIP sessions through the platform follow this procedure:

# Find the call detail record (a.k.a. CDR) of the failed session in CDRTool application. The CDR contains the SIP Call Id and links to the SIP trace and media trace of the session. Save the CDRTool query by giving it a name in the results screen.

# Locate the SIP session in /var/log/syslog of each machine involved (SIP Proxy, Call Control, Media Proxy, CDRTool rating engine). To locate the lines in syslog belonging to a session you can use grep command and the SIP Call Id learnt above as search key. Read the syslog above and below the found log lines they usually provide clues about the failure reason. Example:

# Open a ticket in AG Projects support system (see Requesting support section above) and provide the link to the failed session saved previously.

!cdrtool-call-search.png!

!cdrtool-search-results.png!

h2. SIP Trace

Each successful CDR has a SIP trace associated with it. The trace is available by clicking on the CDR id in the result screen of CDRTool search.

SIP trace can be turned on and off by controlling OpenSIPS:

<pre>

/etc/init.d/opensips siptrace-on

/etc/init.d/opensips siptrace-off

</pre>

!cdrtool-sip-trace.png!

The trace information is stored by default in opensips.sip_trace table.

h2. Media Trace

Each successful SIP session has information about the RTP media associated with it. The trace is available by clicking on the CDR id in the result screen of CDRTool search. 

The media trace information is stored in opensips.media_sessions MySQL table of each node. Purging this table is a disc-access intensive during which the server will act slower than normal, a purge operation must be done during a maintenance window with no traffic. Do not purge the file using an sql query that selects by date, such query will take long time to execute on a large table, during such query the server cannot access the database anymore.

!cdrtool-media-trace.png!

h2. DNS Lookups

Use dig command in a UNIX console to check if the DNS servers part of the platform are responding to queries.

h2. Syslog

All platform software log relevant messages to /var/log/syslog and optional additional files. Please always monitor these files when searching or troubleshooting a problem.

h2. Network Sniffers

If the problem is not captured by the high-level tools described above use:

# ngrep 

# tcpdump

to isolate the network traffic in question.