Support

Table of Contents

  1. Support
    1. Failed Sessions
    2. SIP Trace
    3. Media Trace
    4. DNS Lookups
    5. Syslog
    6. Requesting Support
  2. Routing Guide
    1. Logical Architecture
    2. SIP Entities
    3. Supported Signaling
    4. Supported Media
    5. Primitives
    6. Server Location
    7. Configuration Files
    8. NAT Traversal
    9. AAA
    10. End-Point to End-Point
    11. End-Point to PBX
    12. PBX to PBX
    13. End-Point to PSTN
    14. PSTN to End-Point
    15. PBX to PSTN
    16. PSTN to PBX
    17. Call Diversion
    18. Presence
    19. RLS Services
    20. IM using MSRP Relay
    21. IM using MSRP ACM
    22. IM using MSRP ACM and Relay
    23. File Transfer
    24. Emergency Calls
  3. Provisioning Guide
    1. NGNPro Server
    2. NGNPro Clients
    3. Customers
    4. DNS Zones
    5. DNS Records
    6. SIP Domains
    7. SIP Accounts
    8. SIP Aliases
    9. Trusted Peers
    10. ENUM Ranges
    11. ENUM Numbers
    12. Voicemail Accounts
    13. PSTN Routes
    14. PSTN Carriers
    15. PSTN Gateways
    16. PSTN Rules
    17. Emergency Numbers
    18. Email Notifications
  4. Accounting Guide
    1. CDR Generation
    2. CDR Normalization
    3. CDR Search
    4. CDR Export
    5. Fraud Control
    6. Rating Logic
    7. Rating Assignment
    8. Prepaid Accounts
    9. Prepaid Cards

Failed Sessions

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

  1. 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 and give it a name.
  2. 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:
  3. Open a ticket in AG Projects support system (see Requesting support section below) and provide the link to the failed session saved previously.

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: 

/etc/init.d/opensips siptrace-on
/etc/init.d/opensips siptrace-off

http://cdrtool.ag-projects.com/raw-attachment/wiki/WikiStart/CDRTool-SIPtrace.jpg

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

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. http://cdrtool.ag-projects.com/raw-attachment/wiki/WikiStart/CDRTool-MEDIAtrace.jpg

The media trace information is stored by default in opensips.media_sessions.

DNS Lookups

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

Syslog

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

Requesting Support

AG Projects provides support via its trouble-ticketing system available at:  http://support.ag-projects.com. To open a ticket you must have a login account on AG Projects support system. To obtain a login account:

  1. Obtain from AG Projects a support contract, a login account will be created for you.
  2. If you already have a support contract and login account you can  create sub-accounts for your team members. Use the sub-accounts to login and open support tickets.

For each problem reported in the tickets, AG Projects will notify the resolution or work progress to the contact points specified in the ticket. In order to receive quality support, stick to the following rules:

  1. The person that opens the ticket must have understanding about the platform services
  2. The ticket must contain a clear description of the problem, (where, what and when the problem happend) and how it can be reproduced (when possible)
  3. Operator must be able to provide remote access to equipment(s) where the problem occurs
  4. Operator must provide remote hands and eyes at the facility when necessary
  5. A single problem is described in a ticket

Attachments