User`s manual
Table Of Contents
- Mediant 2000 & TP-1610 & TP-260/UNI SIP User’s Manual Version 5.0
- Table of Contents
- List of Figures
- List of Tables
- Notices
- 1. Overview
- 2. Physical Description
- 3. Installation
- 4. Getting Started
- 5. Web Management
- Computer Requirements
- Protection and Security Mechanisms
- Accessing the Embedded Web Server
- Getting Acquainted with the Web Interface
- Protocol Management
- Advanced Configuration
- Status & Diagnostic
- Software Update Menu
- Maintenance
- Logging Off the Embedded Web Server
- 6. Gateway's ini File Configuration
- Secured ini File
- Modifying an ini File
- The ini File Content
- The ini File Structure
- The ini File Example
- Networking Parameters
- System Parameters
- Web and Telnet Parameters
- Security Parameters
- RADIUS Parameters
- SNMP Parameters
- SIP Configuration Parameters
- Voice Mail Parameters
- ISDN and CAS Interworking-Related Parameters
- Number Manipulation and Routing Parameters
- E1/T1 Configuration Parameters
- Channel Parameters
- Configuration Files Parameters
- 7. Using BootP / DHCP
- 8. Telephony Capabilities
- Working with Supplementary Services
- Configuring the DTMF Transport Types
- Fax & Modem Transport Modes
- Event Notification using X-Detect Header
- ThroughPacket™
- Dynamic Jitter Buffer Operation
- Configuring the Gateway’s Alternative Routing (based on Conn
- Call Detail Report
- Supported RADIUS Attributes
- Trunk to Trunk Routing Example
- Proxy or Registrar Registration Example
- SIP Call Flow Example
- SIP Authentication Example
- 9. Networking Capabilities
- 10. Advanced PSTN Configuration
- 11. Advanced System Capabilities
- 12. Special Applications
- 13. Security
- 14. Diagnostics
- 15. SNMP-Based Management
- SNMP Standards and Objects
- Carrier Grade Alarm System
- Cold Start Trap
- Third-Party Performance Monitoring Measurements
- TrunkPack-VoP Series Supported MIBs
- Traps
- SNMP Interface Details
- SNMP Manager Backward Compatibility
- Dual Module Interface
- SNMP NAT Traversal
- SNMP Administrative State Control
- AudioCodes’ Element Management System
- 16. Configuration Files
- Appendix A. Selected Technical Specifications
- Appendix B. Supplied SIP Software Kit
- Appendix C. SIP Compliance Tables
- Appendix D. The BootP/TFTP Configuration Utility
- Appendix E. RTP/RTCP Payload Types and Port Allocation
- Appendix F. RTP Control Protocol Extended Reports (RTCP-XR)
- Appendix G. Accessory Programs and Tools
- Appendix H. Release Reason Mapping
- Appendix I. SNMP Traps
- Appendix J. Installation and Configuration of Apache HTTP Server
- Appendix K. Regulatory Information
SIP User's Manual H. Release Reason Mapping
Version 5.0 379 October 2006
H Release Reason Mapping
This appendix describes the available mapping mechanisms of SIP Responses to Q.850
Release Causes and vice versa.
Table
H-1 and Table H-2 describe the existing mapping of ISDN Release Causes to SIP
Responses. To override this hard-coded mapping and flexibly map SIP Responses to ISDN
Release Causes use the parameters CauseMapISDN2SIP and CauseMapSIP2ISDN
(described in Section
6.14 on page 172), or via the Embedded Web Server (refer to
Section
5.5.5.6 on page 77).
It is also possible to map the less commonly-used SIP Responses to a single default ISDN
Release Cause. Use the parameter DefaultCauseMapISDN2IP (described in Section
6.14
on page 172) to define a default ISDN Cause that is always used except when the
following Release Causes are received: Normal Call Clearing (16), User Busy (17), No
User Responding (18) or No Answer from User (19). This mechanism is only available for
Tel to IP calls.
H.1 Reason Header
The gateway supports the Reason header according to RFC 3326. The Reason header is
used to convey information describing the disconnection cause of a call:
Sending Reason header: If a call is disconnected from the Tel side (ISDN), the
Reason header is set to the received Q.850 cause in the appropriate message (BYE /
CANCEL / final failure response) and sent to the SIP side. If the call is disconnected
because of a SIP reason, the Reason header is set to the appropriate SIP response.
Receiving Reason header: If a call is disconnected from the IP side and the SIP
message includes the Reason header, it is sent to the Tel side according to the
following logic:
• If the Reason header includes a Q.850 cause, it is sent as is.
• If the Reason header includes a SIP response: (1) If the message is a final
response, the response status code is translated to Q.850 format and passed to
ISDN. (2) If the message isn’t a final response, it is translated to a Q.850 cause.
• When the Reason header is received twice (i.e., SIP Reason and Q.850), the
Q.850 takes precedence over the SIP reason and is sent to the Tel side.