PSTN Gateway

The PSTN Gateway product provides a PSTN gateway complex for VoIP applications.

A PDF version of this document is available here.

Optranex 248 PSTN Gateway

Optranex 248 PSTN Gateway Field Trial Plan of Record

About This Manual

This is Edition 7.20141001, last updated 2014-10-25, of The Optranex 248 PSTN Gateway Field Trial Plan of Record, for Version 1.1 release 7.20141001 of the OpenSS7 package.

List of Examples

Example 6.1: IAM received by Optranex 248 in Successful PSTN to SIP Call
Example 6.2: IAM for IAM to INVITE Translation Example
Example 6.3: IAM received for Successful PSTN to SIP Call Example
Example 6.4: IAM received for Unsuccessful PSTN to SIP Call Example
Example 6.5: IAM sent for Successful SIP to PSTN Call
Example 6.6: IAM sent for Successful SIP to PSTN Call Example
Example 6.7: IAM received for Successful ENUM PSTN to SIP Call
Example 6.8: Example BIND9 configuration file (named.conf.local)
Example 6.9: Example BIND9 zone file
Example 6.10: Example BIND9 zone file

List of Messages

Message 6.1: Optranex 248 INVITE generated from IAM in Successful PSTN to SIP Call
Message 6.2: Carrier Proxy INVITE in Successful PSTN to SIP Call
Message 6.3: 100 Trying Response from C-SCP for Successful PSTN to SIP Call
Message 6.4: 305 Use Proxy from C-SCP for Successful PSTN to SIP Call
Message 6.5: Optranex 248 ACK Request for Successful PSTN to SIP Call
Message 6.6: Optranex 248 INVITE from IAM for Successful PSTN to SIP Call Example
Message 6.7: 305 Use Proxy Response for Successful PSTN to SIP Call – Explicity Proxy
Message 6.8: 305 Use Proxy Response for Successful PSTN to SIP Call – DNS SRV Approach
Message 6.9: 305 Use Proxy Response for Successful PSTN to SIP Call – I-ENUM Query Approach
Message 6.10: 305 Use Proxy Response for Successful PSTN to SIP Call – CNAM Query Approach
Message 6.11: INVITE generated for Successful PSTN to SIP Call Example
Message 6.12: INVITE forwarded in Successful PSTN to SIP Call Example
Message 6.13: 100 Trying Response in Successful PSTN to SIP Call Example
Message 6.14: 305 Use Proxy Response in Successful PSTN to SIP Call Example
Message 6.15: ACK Request in Successful PSTN to SIP Call Example
Message 6.16: Customer Proxy INVITE for Successful PSTN to SIP Call Example
Message 6.17: 305 Use Proxy Response for Successful PSTN to SIP Call Example
Message 6.18: Unallocated Destination Number Caused Treatment
Message 6.19: Unallocated Destination Number Caused Treatment
Message 6.20: Number Changed Caused Treatment – 404 Not Found Response
Message 6.21: Number Changed Caused Treatment – 301 Moved Permanently Response
Message 6.22: Invalid Number Format Caused Treatment
Message 6.23: Network Out-of-order Caused Treatment
Message 6.24: Temporary Failure Caused Treatment
Message 6.25: Switching Equipment Congestion Caused Treatment
Message 6.26: Misrouted Call to Ported Number Caused Treatment
Message 6.27: Number Not Found Caused Treatment
Message 6.28: Optranex 248 INVITE for Unsuccessful PSTN to SIP Call Example
Message 6.29: Carrier Proxy INVITE for Unsuccessful PSTN to SIP Call Example
Message 6.30: Carrier Proxy 100 Trying for Unsuccessful PSTN to SIP Call Example
Message 6.31: C-SCP 404 Not Found Response for Unsuccessful PSTN to SIP Call Example
Message 6.32: Carrier Proxy 404 Not Found Response for Unsuccessful PSTN to SIP Call Example
Message 6.33: Optranex 248 ACK for Unsuccessful PSTN to SIP Call Example
Message 6.34: Carrier Proxy ACK for Unsuccessful PSTN to SIP Call Example
Message 6.35: UA INVITE for Successful SIP to PSTN Call
Message 6.36: Customer Proxy 100 Trying Response for Successful SIP to PSTN Call
Message 6.37: Customer Proxy INVITE for Successful SIP to PSTN Call
Message 6.38: Carrier Proxy C-SCP INVITE for Successful SIP to PSTN Call
Message 6.39: Optranex 248 100 Trying Response for Successful SIP to PSTN Call
Message 6.40: C-SCP 100 Trying Response for Successful SIP to PSTN Call
Message 6.41: C-SCP 302 Moved Temporarily Response for Successful SIP to PSTN Call
Message 6.42: Carrier Proxy ACK for Successful SIP to PSTN Call
Message 6.43: Carrier Proxy retargetted INVITE for Success SIP to PSTN Call
Message 6.44: 302 Moved Temporarily Response for SIP to PSTN Call Example
Message 6.45: Q.850 Cause Value to SIP Response Mapping Example
Message 6.46: ANSI Cause Value to SIP Response Mapping Example
Message 6.47: ENUM Customer INVITE for Successful PSTN to SIP Call

Executive Overview

This document provides a Field Trial Plan of Record for the Optranex 248 PSTN Gateway. The initial and primary purposes of this equipment is to provide a scalable, carrier-grade platform for interconnecting VoIP backbone networks to the PSTN using SS7.

The OpenSS7 Project

The OpenSS7 Project is an open source software project that has developed many protocol components within the SS7, SIGTRAN, ISDN and VoIP protocol stacks. Intellectual property rights for the OpenSS7 Project are held by OpenSS7 Corporation. All OpenSS7 Project software is eventually licensed under the GNU Affero General Public License Version 3. OpenSS7 Corporation also provide commercial licensing of OpenSS7 Project software under terms less restrictive than the AGPLv3.

The OpenSS7 Carrier VoIP Switch

OpenSS7 can provide VoIP gateway capabilities in a high-performance, low-cost, small-footprint platform leaveraging the GNU/Linux operating system distributions and tools, and utilizing low-cost commodity, or high-quality standardized hardware.

For details on platform applications, see Application Architecture and Network Architecture.

Open Source Software

The OpenSS7 Project leverages the widespread use of GNU/Linux operation systems, distributions, and FSF tools such as ‘autoconf’ and RPM. For example, this document was formatted for PDF, HTML, info and plain text using the GNU texinfo system, ‘autoconf’, and the TeX formatting system.

The open source model avoids proprietary lock-in and permits in-house or outsourced development. All source code is available for use and modification by the end customer. All build tools, documentation and associated resources are generally available. The availability of the source code and complete documentation eases problem resolution and can offer upgrades and fixes even in advance of client problem reports.

For details on software solutions, see Protocol Architecture and Software Architecture.

Commodity Hardware

By best utilizing commodity PC or standardized CompactPCI hardware, OpenSS7 makes available the highest performance platforms available on the market at back-to-school prices. When carrier-grade and large scale is not essential, 3GHz Pentium class servers in hardened rack mount chassis can be used at a fraction of the cost, and yet outperform, other solutions. Where carrier-grade is necessary, embedded Linux on standardized PICMG 2.16 NEBS compliant chassis make for a higher cost, but more reliable alternative.

For details on hardware solutions, see Platform Architecture and Hardware Architecture.

Rapid Development

The OpenSS7 Project has already developed protocol components completing the SS7 and SIGTRAN signaling stacks including MTP Level 2 and Level 3, ISUP, SCCP, TCAP; and SCTP, M2PA, M2UA, M3UA, SUA and TUA. Development of a Carrier VoIP Switch to meet initial field requirements needs only the development of some intermediate and auxillary modules.

For details on scheduling, see Logistics.

An Evolving Solution

The OpenSS7 Project is evolving to support more protocol stacks including ISDN and VoIP.

Conclusions

In summary, an OpenSS7 Carrier VoIP Switch an excellent application of the OpenSS7 SS7 and VoIP stacks and can be provided at a affordable price on short time-lines, while offering an evolution path for future deployment applications.

Brian Bidulock The OpenSS7 Project

Preface

Document Information

Abstract

This document provides a Field Trial Plan of Record for the Optranex 248 PSTN Gateway.

Objective

The objective of this document is to provide a Field Trial Plan of Record for the deployment of the low cost, high-performance, Optranex 248 PSTN Gateway using OpenSS7 protocol components, software, and compatible systems and hardware.

Intent

The intent of this document is to act as a Field Trial Plan of Record for an project for an Field Trial Plan of Record. As a Field Trial Plan of Record, this document discusses components and systems which are not necessarily complete. OpenSS7 Corporation is under no obligation to provide any software, system or feature listed herein.

Audience

This document is intended for a technical audience. The reaser should be familiar with most most 3GPP, ETSI, ITU-T and ANSI, SS7, IMS, H.323, H.225, H.245, as well as IETF drafts and RFCS for RTP, SIP, SIP-T, MEGACO, MGCP, and SIGTRAN protocols.

Revisions

Take care that you are working with a current version of this document: you will not be notified of updates. To ensure that you are working with a current version, contact the Author, or check The OpenSS7 Project website for a current version.

Version Control

$Log: pgw.texi,v $
Revision 1.1.2.3  2011-02-07 02:21:36  brian
- updated manuals

Revision 1.1.2.2  2010-03-10 08:42:18  brian
- added Optranex files

Revision 1.1.2.1  2010-02-22 14:25:51  brian
- added new documentation files

ISO 9000 Compliance

Only the TeX, texinfo, or roff source for this document is controlled. An opaque (printed or postscript) version of this document is an UNCONTROLLED VERSION.

Disclaimer

OpenSS7 Corporation, Monavacon Limited and Optranex Incoporated disclaim all warranties with regard to this documentation including all implied warranties of merchantability, fitness for a particular purpose, non-infringement, or title; that the contents of the document are suitable for any purpose, or that the implementation of such contents will not infringe on any third party patents, copyrights, trademarks or other rights.. In no event shall OpenSS7 Corporation, Monavacon Limited, nor Optranex Incorporated be liable for any direct, indirect, special or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in an action of contract, negligence or other tortious action, arising out of or in connection with any use of this document or the performance or implementation of the contents thereof.

OpenSS7 Corporation reserves the right to revise this software and documentation for any reason, including but not limited to, conformity with standards promulgated by various agencies, utilization of advances in the state of the technical arts, or the reflection of changes in the design of any techniques, or procedures embodied, described, or referred to herein. OpenSS7 Corporation is under no obligation to provide any feature listed herein.

Document Organization

This document is organized as follows:

Introduction: Introduction to the Optranex 248 PSTN Gateway application.
Application Architecture: The application requirements and architecture.
Solution Architecture: The solution architecture for the application.
Network Architecture: The network architecture for the application.
Reference Architecture: The reference architecture for the application.
System Architecture: The architecture of the Optranex 248 PSTN Gateway system.
Platform Architecture: The architecture of the Optranex 248 PSTN Gateway platform.
Management Architecture: The architecture of the Optranex 248 PSTN Gateway management.
Protocol Architecture: The protocol architecture supporting the application.
Software Architecture: The software architecture supporting the protocol stack and application.
Hardware Architecture: The hardware architecture supporting the protocol stack and application.
Logistics: Project logistics for completion of the VoIP GW application.
Programmatic Interfaces: Programmatic interfaces to selected protocol components.
Platform Sizing: Detailed platform sizing considerations.
Index: Index of concepts.

1 Introduction

This document provides a Field Trial Plan of Record for a patform to provide scalable Optranex 248 PSTN Gateway capabilities. The primary driver for the Optranex 248 PSTN Gateway is to provide a system capable of interconnecting a SIP VoIP backbone to the PSTN using SS7. This document provide a Field Trial Plan of Record for a trial system to provide this capability at a number of scale points.

The proposal utilizes, where possible, existing OpenSS7 protocol stack components and provides a development plan for components that are specific to the Optranex 248 PSTN Gateway initial requirements.

This document discusses the resulting software configuration that will be put in place on the production system, the platform configuration for the production system, and a network configuration for deployment. Also discussed is an overview of the project management logistics for successful completion over the course of this development project.

It is intended that the document be a “living” document, that is updated over the course of this development project.

1.1 The Optranex 248 PSTN Gateway

This project provides an Optranex 248 PSTN Gateway platform that provides interconnection to the PSTN using SS7 ISUP trunks and is capable of routing calls to and from the PSTN and a VoIP backbone network using SIP-T, ITU-T Q.1912.5 and 3GPP TS 29.163 signaling and RTP transport.

1.2 Project Drivers

The lead purpose of the Optranex 248 PSTN Gateway is to provide PSTN interconnection to an existing VoIP backbone and deployment infrastructure that lacks same.

1.2.1 Project Objectives

The objectives that Optranex Incorporated wishes to acheive during the trial are as follows:

Validation of correct implementation of the Optranex 248 switch hardware, firmware and software drivers. This will be acheived by exchanging channel data with the AT&T interconnection using aggregated DS-3 over SONET.
Validation of correct fail-over using 1:1 APS on the Optranex 248 switch hardware, firmware and software drivers. This will be achieved by completing hardware fail-over between cards on the redundant Optranex 248 switch platforms.
Demonstration of the maximum handling capacity of the Optranex 248 switch. The Optranex 248 switch is capable of connecting 2 x OC-48s for a total of 96 DS-3s (approximately 64,000 channels) in a redundant configuration. In simplex configuration, each server is capable of 96 DS-3s for a maximum simplex configuration of 192 DS-3s (approximately 128,000 channels). This will be acheived by loading the platforms to their maximum channel handling capacity and then performing voice quality assessment on a number of channels.
Demonstrate standard (RFC 4666) M3UA operation with the SS7 signaling network.
Demonstrate standard (ANSI T1.113-2000) ISUP operation with the SS7 signaling network.
Demonstrate standard (RFC 3621) SIP operation with the SIP network.
Demonstrate basic SIP to ISUP interworking operation according to SIP-T (RFC 3398), ITU-T Q.1912.5 and 3GPP TS 29.163 Release 9.

1.3 Scope

Because of early deployment drivers yet requirements for scale, the Optranex 248 PSTN Gateway platform is constructed using hardened PC telephony hardware in a NEBS 3/ETSI compliant chassis providing carrier-grade serviciablity and reliability. Non-carrier-grade platforms utilizing commodity PC hardware for lower scale or lower reliability installations are possible.

1.3.1 Phases

The longer term project is broken into the following phases:

Phase 1 ¹ The initial phase of the project is: intended to provide the capabilities of the Optranex 248 PSTN Gateway for PSTN to VoIP backbone tandem for H.323.
Phase 2: The second phase of the project adds tandem gateway capabilities for SIP-T.
Phase 3: The third phase of the project adds network service capabilities.
Phase 4: The fourth phase of the project adds softswitch capabilities.
Phase 5: The fifth phase of the project completes a VoIP (NGN) switch.

Although some reference is made to capabilities supporting other phases, Phase 1 and Phase 2 are the focus of this document.

1.3.2 Gates

Each phase of the project consists of seven gates. The seven gates are defined as follows:

Gate 0 — Concept: Gate 0 is passed when the initial concept has been elucidated and work is begun on a High-Level Design. This is an internal OpenSS7 gate.
Gate 1 — High Level Design: Gate 1 is passed when the high-level design has been reviewed to the satisfaction of the consumers of the project. This is an external review gate. OpenSS7 internally passes this gate once the High-Level Design has been published and work is begun on a detailed design.²
Gate 2 — Detailed Design: Gate 2 is passed when the detailed design has been reviewed to the satisfaction of the consumers of the project and the developers on the project. This is an external as well as an internal review gate. OpenSS7 passes this gate once the Detailed Design has been published and work base begin on development and implementation of the design.³ Passing this gate moves from the design stage to the development stage of the project.
Gate 3 — Development and Implementation: Gate 3 is passed when the software and systems development and implementation to the detailed design is complete and testing has begun. This is an internal review gate. OpenSS7 internally passes this gate when software is code complete and hardware has been installed for testing.
Gate 4 — System Test: Gate 4 is passed once the product implementation meets all internal ad hoc and formal conformance test suites and internal testing is complete. This is an internal review gate. OpenSS7 passes this gate internally once conformance testing is complete. Passing this gate moves from the development stage to the support stage of the project.
Gate 5 — Acceptance Test: Gate 5 is passed once the product implementation has passed external Gamma client acceptance testing. This is an external review gate. OpenSS7 passes this gate internally once participation in external acceptance testing is complete.
Gate 6 — Project Complete: Gate 6 is passed once all support obligations for the product implementation have been discharged. This is an internal review gate. OpenSS7 passes this gate once support agreements have terminated.

For more details on Gate scheduling for Phase 1 and Phase 2 of the VoIP GW project, see Logistics.

2 Application Architecture

The Optranex 248 PSTN Gateway is intended to provide high performance and high density PSTN to VoIP backbone gateway adding SS7 interconnection capability to an existing or back-end VoIP network.

2.1 Application Requirements

Application requirements have been broken into 5 phases using the timeboxing approach.

2.1.1 Phase 1 Requirements

Phase 1 requirements provide a VoIP gateway capability that will connect an existing H.323 VoIP network to the PSTN using SS7 ISUP trunks.

Integral Media Gateway for RTP/RTCP to G.703/G.704 G.711 A- and mu-law.
Integral Signaling Gateway for SS7 ISUP and SS7 TCAP.
Local Number Portability.
Lawful Intercept.

Integral Media Gateway Controller for H.323
Integral Back End functions for H.323.
Integral H.323 Gatekeeper.

2.1.2 Phase 2 Requirements

Phase 2 requirements provide SIP-T capabilities.

Integral Media Gateway Controller for SIP-T.
Integral Back End functions for SIP-T.
Integral SIP redirect/proxy server.

2.1.3 Phase 3 Requirements

Phase 3 requirements provide network service capabilities.

ENUM support.
AAA support.
EAP authentication.
External PLMN authentication.
GSM MSC/VLR capabilities.
ETSI Tiphon 4 interworking.
ISDN support on E interface.

2.1.4 Phase 4 Requirements

Phase 4 requirements expose internal interfaces to provide softswitch capabilities.

J Interface (SIGTRAN) exposed.
N Interface (MGCP, H.248/MEGACO) exposed.

2.1.5 Phase 5 Requirements

Phase 5 requirements complete full VoIP (NGN) switching.

Support for directly attached H.323, SIP and MGCP IP Phone terminals.
Full RAS support for internal H.323 gatekeeper and SIP proxy server.
Full class 5 residential/business feature set.

3 Solution Architecture

Although the functions of Media Gateway Controller, Media Gateway and Signaling Gateway have been decomposed, and in the past these functional groups have been implemented on separate physical platforms, modern compute capacity and densities permit these functions to be integrated into a single physical platform without limitation. Open standard interfaces are utilized internal to the platform to permit a decomposed model to be split out and to permit 3GPP IMS CN compatibility as well as ETSI Tiphon Version 4 and Multi-Services Forum Version 3 compatibility.

3.1 Optranex 248 PSTN Gateway Deployment

In light of the foregoing, the solution architecture takes the form of an integrated PSTN Gateway capable of providing a number of functional groups in the traditional models. The Optranex 248 PSTN Gateway integrates the following functional groups while still permitting standard interfaces to be exposed for maximum deployment flexibility:

Integral Media Gateway Controller for SIP-T.
Integral Media Gateway for RTP/RTCP to PDH G.703/704 G.711 conversion.
Integral Signaling Gateway for SS7 ISUP, TCAP and ISDN signaling conversion.
Integral Redirect/Proxy server for SIP-T.

3.2 Distinguishing Features

The primary distinguishing feature of the Optranex 248 switch is extreme reduction of the following:

capital expense (3 orders of magnitude);
power consumption (2 orders of magnitude);
footprint (2 orders of magnitude);
closed and proprietary software (erradicated);
cost per channel (3 orders of magnitude).

3.2.1 Capital Expense Reduction

The capital expense reduction from competing solutions (Telcobridges) is approximately $500,000 (1 x OC-48 worth of OC-3 traffic), reduced to $5,000 (1 x OC-48) for the Optranex 248 switch. This is 2 orders of magnitude lower than competing solutions. Capital expense reduction from current popular solutions (Genband) is approximately $2,500,000 (1 x OC-48 worth of traffic), reduced to $5000 (1 x OC-48) for the Optranex 248 switch. This is 3 orders of magnitude lower than current popular solutions.

3.2.2 Power Consuption Reduction

The power consuption reduction is from 50 kWatt for competing and popular solutions to less than 1 kWatt for the Optranex 248 switch. Power consumption is 2 orders of magnitude lower than competing solutions.

3.2.3 Footprint Reduction

The footprint reduction is from 2 full 7’ bays (48 U) to 2 x 1U x 20" deep chassis. This is 2 orders of magnitude reduction in footprint.

3.2.4 Closed and Proprietary Software Reduction

Whereas competing solutions provide some open-source software, the Optranex 248 switch is completed implemented with open and open-source software.

3.2.5 Cost per Channel Reduction

Cost per channel reduction over approaches used by FreeSwitch, Asterisk, OpenPBX and others is from approximately $4.64 to $5.65 a channel, to $0.008. This is approximately 3 orders of magnitude reduction in per-channel costs.⁴

3.3 Call Flows

This section provides some illustrative application call flows:⁵

4 Network Architecture

The network architecture is illustrated in Figure 1.

Figure 1. Network Architecture

The network architecture consists of the following major components:

Customer SIP Network — A customer SIP network containing SIP UAs for originating and terminating calls. Each UA is associated with at least one NANP telephone number assigned to the customer SIP network.
Customer SIP Proxy — An inbound and outbound SIP proxy used to pass calls to a Voice Peering Proxy (perhaps coexistent with the customer SIP proxy) and a PSTN GW.
Voice Peering Proxy — A voice peering fabric proxy based on Carrier ENUM capable of determining whether outbound calls are destined for a Voice Peering fabric or the PSTN GW.
The purpose of a voice peering SIP proxy is to perform Carrier ENUM for the purposes of routing customer calls to a voice peering fabric or network for PSTN bypass. As there is no initial requirement for voice peering, this proxy is not shown in Figure 1. Nevertheless, this proxy might be coexistent with the customer SIP proxy or the carrier proxy.
Carrier Proxy — A telephony routing SIP proxy capable of Carrier ENUM or interaction with the C-SCP. This proxy might be coexistent with the C-SCP or an Optranex 248 gateway switch.
The purpose of the carrier SIP proxy is to perform analysis and routing in conjunction with the C-SCP platform when necessary and determine to which of a number of Optranex 248 gateway switches to route the call. Traffic estimates for 200 DS3sa requires the use of at least two Optranex 248 gateway switches.
C-SCP Platform — The Converged-SCP platform capable of number portability dips and the interworking with the carrier proxy as described in this document.
Router/Firewall — An Internet Protocol Router/Firewall for the purpose of IP connectivity between the elements in the IP domain.
Optranex 248 Gateway Switch — The Optranex 248 gateway switch(es) connecting the IP and CS domains.
SONET ADM — SONET Add-Drop Multiplexer(s) providing SONET connectivity between each Optranex 248 switch and the PSTN.
Public Switched Telephone Network — The PSTN consisting of Lata and Carrier access tandems for outbound and egress traffic.

In Figure 1, the Optranex 248 switch acts as a set of implicitly registered telephone subscriber User Agents towards the customer SIP proxies, and as an originating, terminating or tandem local switch to the PSTN.

4.1 Ethernet Connections

As illustrated in Figure 5, Ethernet connectivity of the Optranex 248 switch will consist of four separate 1000BaseT Ethernet interfaces per server chassis for a total of eight separate 1000BaseT connections. These 1000baseT Network Interface connections are RJ-45 connectors that should be interconnected using Category 6 cable.⁶

These 1000BaseT physical network interfaces will be used to support a number of separate subnetworks impressed on VLANs: one VLAN dedicated to each subnetwork.

In addition to the 1000BaseT ports described above, each server chassis has a single 100baseT port dedicated to an on-board Remote Management Module (RMM). This is also illustrated in Figure 5. The 100baseT network interface connections are RJ-45 connectors that should be interconnected using Category 5 cable.⁷

These 100BaseT physical network interfaces do not require VLANs and may, instead, be connected on a dedicated non-VLAN subnetwork.

Figure 5. Ethernet Network Interfaces

IEEE 802.1q prioritization will be used for prioritizing traffic on the various VLANs. The priority of the various VLANs from lowest to highest are as follows:

public Internet traffic;
test-bed RTP traffic;
test-bed SIP traffic;
test-bed SIGTRAN M3UA traffic;
customer RTP traffic;
customer SIP traffic;
SIGTRAN M3UA traffic;
management traffic.

IP Address Requirements

The IP address requirements for the Optranex 248 are as follows:

Eight IP addresses (one for each 1000baseT port on each server chassis) assigned to the subnetwork on VLAN1 for public Internet access. These IP addresses must be able to address the public internet for software download and installation. These IP addresses can operate through a NAT to reach the public internet. Connection to the internet can be made intermittent or temporary for the purposes of security.
Eight IP addresses (one for each 1000baseT port on each server chassis) assigned to the subnetwork on VLAN2 for test-bed RTP traffic. These IP addresses need only adddress each other.
Eight IP addresses (one for each 1000baseT port on each server chassis) assigned to the subnetwork on VLAN3 for test-bed SIP traffic. These IP addresses need only address each other.
Eight IP addresses (one for each 1000baseT port on each server chassis) assigned to the subnetwork on VLAN4 for test-bed M3UA traffic. These IP addresses need only address each other.
Eight IP addresses (one for each 1000baseT port on each server chassis) assigned to the subnetwork on VLAN5 for customer RTP traffic. These IP addresses must be directly addressable from customer SIP networks (proxies or SBCs) and must be able to directly address customer SIP networks (proxies or SBCs).
Eight IP addresses (one for each 1000baseT port on each server chassis) assigned to the subnetwork on VLAN6 for customer SIP traffic. These IP addresses must be directly addressable from the carrier proxy (C-SCP) and must be able to directly address the carrier proxy (C-SCP). (These IP addresses might also need to directly address (and be addressed by) customer proxies.)
Eight IP addresses (one for each 1000baseT port on each server chassis) assigned to the subnetwork on VLAN7 for SIGTRAN M3UA traffic. These IP addresses must be directly addressable to and from the SIGTRAN Signaling Gateways.
Ten IP addresses (one for each 1000baseT port, and one for each 100baseT port, on each sever chassis) with the eight (8) 1000baseT ports assigned to the subnetwork on VLAN8, and the two (2) 100baseT ports connected on a non-VLAN segment (but to the same subnetwork as VLAN8), for management traffic. This VLAN is expected to carry DNS traffic, NTP traffic, SNMP traffic, Remote Management Traffic, and SSH access from remote locations. These IP addresses must be able to address DNS and NTP servers. Also, some form of remote SSH or other access to the Remote Management Modules and login to the server chassis is required.

I would prefer if these addresses were not statically defined, but were acquited using DHCP and populated in DNS through either static or dynamic-DNS assignment from DHCP.

Traffic Requirements

The traffic requirements for each VLAN is listed in Table T-6, and detailed in the sections that follow:

Table T-6. Traffic Requirements

RTP Traffic Calculations

Each G.711 circuit can pass 8000 octets per second or 64 kbps. With a 10 millisecond packetization on AVT RTP G.711 PCMU, the RTP payload is 80 octets. With a 30 millisecond packetization on AVT RTP G.711 PCMU, the RTP payload is 240 octets. Each RTP has the following overheads:

18	octets	Ethernet packet overheads.
4	octets	VLAN packet overheads.
20	octets	IPv4 header overheads.
8	octets	UDP header overheads.
12	octets	RTP header overheads.
62	octets	Total overheads.

The packet size for 10ms packets with 80 octet payload is 142 octets or 1,136 bits. 10ms packets are generated 100 times per second per direction per channel, or 113,600 bits per second per direction. The efficiency of the 10ms RTP packet is approximately 56%. A DS3 of 672 channels requires a bandwidth of 76.3392 Mbps (in each direction) of 10ms RTP G.711 packets.

The packet size for 30ms packets with 240 octet payload is 302 octets or 2,416 bits. 30ms packets are generated 33-1/3 times per second per direction per channel, or 80,533 bits per second per direction. The efficiency of the RTP packet is approximately 80%. A DS3 of 672 channels requires a bandwidth of 54.1185 Mbps (in each direction) of 30ms RTP G.711 packets.

4.1.1 Internet Ethernet Traffic

The Optranex 248 switch requires (temporary or permanent) connectivity to the public Internet for the purpose of downloading software loads and performing software upgrades. This is the lowest priority traffic. It is recommended that this traffic be performed using a VLAN dedicated to public Internet access. This VLAN should have a gateway that may be used as a default gateway and that provides NAT/Firewall access to the public Internet. It is anticipated that this connectivity to the public Internet will be used largely for installation and upgrade procedures only. As such, it can be temporary.

4.1.2 Test-Bed RTP Ethernet Traffic

The requirement for test-bed RTP Ethernet traffic is illustrated in Figure 7.

Figure 7. Test-Bed RTP Ethernet Traffic

For the trial, during performance and capacity testing, it will be necessary to pass a significant amount of test-bed RTP traffic between load generators and also intra-switch traffic between the two server chassis making up the Optranex 248 switch. The primary purpose of test-bed RTP traffic is to accept traffic from load generators and voice quality assessment equipment.

It is recommended that Test-Bed RTP connectivity be performed using a VLAN dedicated to RTP traffic between the test-bed network and the Optranex 248 switch. Separate IPv4 IP addresses for each of the network connections in each of the server chassis of the Optranex 248 switch should be allocated on this dedicated VLAN subnetwork. All network interfaces of each Optranex 248 service should be connected to this VLAN.

Four IP addresses per server chassis (total 8 IP addresses) on the test-bed RTP VLAN is required due to the number of RTP ports that are required. 64,512 channels requires 129,024 UDP ports, which, when spaced 2 apart (for RTCP), and consuming half of the available UDP port space, requires 8 IP addresses in a load-sharing configuration such as is used for performance testing. In an active-standby arrangement, each server would require 8 IP addresses of its own on this VLAN, and would also require 10G Ethernet connectivity.

For example, if VLAN 001 is used for Test-Bed RTP traffic, and Class C subnetwork 192.168.1.0/24 is associated with VLAN 001, the A-side of the Optranex 248 platform could be assigned IP addresses 192.168.1.10, .11, .12 and .13 on VLAN 001, and the B-side of the Optranex 248 switch could be assigned IP addresses 192.168.1.20, .21, .22 and .23. This configuration is illustrated in Figure 7.

For maximum capacity performance testing, switches and routers on the Test-Bed RTP VLAN must be capable of passing 64,512 channels of G.711 RTP with 10 millisecond and 30 millisecond packetization. A 10 millisecond packetization consists of 80 octets of RTP AVT payload every 10 milliseconds for 64,512 channels full duplex or 2 x 6,451,200 packets per second. A 30 millisecond packetization consists of 240 octets of RTP AVT payload every 30 milliseconds for 64,512 channels full-duplex or 2 x 2,150,400 packets per second. Each RTP packet on the VLAN has 18 octets of Ethernet overhead, 4 octets of VLAN overhead, 20 octets of IPv4 overhead, 8 octets of UDP overhead, and 12 octets of RTP overhead, for a total of 62 octets of overhead. At 10 millisecond packetization that is 62 octets of overhead and 80 octets of payload at 2 x 6,451,200 packets per second or 14.65712 Gbps. At 30 millisecond packetization that is 62 octets of overhead and 240 octets of payload at 2 x 2,150,400 packets per second or 10.39073 Gbps. 4 x 1000baseT network connections are capable of 8 Gbps full duplex maximum: therefore, it will be possible to test 2 x 32,256 channels (2 x OC-48) or 2 x 7.32856 Gbps at 10ms packetization or 2 x 5.195365 Gpbs at 30ms packetization during capacity testing. A single OC-48 (2.488 Mbps) SFP loop-back cable will be provided to permit 32,256 channels of loopback (2 x 64,512 channels) for capacity performance testing.

4.1.3 Test-Bed SIP Ethernet Traffic

For the trial, a test-bed SIP proxy and test-bed SIP softphones will also be connected on the same VLAN as the customer proxies.

For capacity performance testing, this VLAN must be capable of processing a maximum of 64,512 simultaneous calls, consisting of 3 minute average holding time. This consists of a maximum of 64,512 calls every 3 minutes, or 360 calls per second, which is on the order of 12 megabits per second of SIP signaling.

4.1.4 Test-Bed SIGTRAN M3UA Ethernet Traffic

It is recommended that test-bed SIGTRAN M3UA connection be performed using a VLAN dedicated to communications between the A- and B-side of the Optranex 248 switch. Separate IPv4 IP addresses for each of the server chassis of the Optranex 248 switch should be allocated on this dedicated VLAN subnetwork. Router connectivity between the Optranex 248 switch servers should be restricted to the MAC and IPv4 IP addresses of those servers. PoE or GRE may be used between the router and Optranex 248 switch servers to simplify firewall designs for, and further isolate, this traffic.

4.1.4.1 Test-Bed SIGTRAN M3UA Network Configuration

SCTP Multihoming is (RFC 4960) is necessary to provide path and network interface redundancy for SIGTRAN M3UA. However, SCTP Multihoming does not function properly through a NAT. This problem can be side-stepped using SCTP-aware NAT (doesn’t really exist yet in standard form) or by using LT2P, PoE, GRE or other point-to-point route encapsulation for establishing direct IP connections through the edge router.

As the IP addresses of the A- and B-side of the Optranex 248 platform for test-bed SIGTRAN M3UA traffic may be wholly within a private IP network, route encapsulation is not necessary. (For the normal case, see ‘SIGTRAN M3UA Network Configuration’.)

4.1.4.2 Test-Bed SIGTRAN M3UA AS Configuration

The Optranex 248 switch servers will be configured as two M3UA IP Server Processes (IPSPs) serving seperate Application Server(s). There will be one Application Server for each of the A- and B-side of the Optranex 248 platform. Application Servers will be configured simplex (in standby or loadshare traffic modes).

Signaling Point Codes

The Optranex 248 switch will require two small-network experimental SS7 signaling point codes for loop-back trunk configuration for capacity and performance testing. Four point codes will be initially selected from the highest available point code block in ANSI Signaling Point Code Block listing, Table B3/T1.111.8. The ANSI point code block assignments are listed in Table T-3.

Table T-3. ANSI Point Code Block Assignments

This point code will permit 4 trunk groups for testing to be configured:

Table T-4. Loop-Around Trunk Group Assignment

These point codes will not be addressable from the public SS7 network and will only by addressable internally. Also, the trunk groups at the ends of which these signaling point codes are assigned will not terminate nor transit the PSTN, but will be configured as loop-around trunks between the A- and B-Side of the Optranex 248 switch. See ‘Test-Bed Copper OC-48 Loop Back’.

4.1.4.3 Test-Bed SIGTRAN M3UA Traffic Requirements

Sufficient bandwidth between the side of the Optranex 248 gateway switch for SIGTRAN M3UA is required for proper test operation. For performance testing capacity, SONET connectivity consists of 2 OC-12 and 1 OC-48 of test traffic, for a total of 72 DS3s. With average 3-minute holding times, expected average call attempt traffic will be (72 x 672)/180 or 268 calls per second. A typical ISUP call averages 5 messages with an average of 28 octets per message. Adding SIGTRAN M3UA overheads⁸ yeilds an average of 106 octets per message. At 268 calls per second, this totals a mere 227,264 bits per second.

Nevertheless, it is important that this traffic be given priority over less important flows (such as RTP traffic).

4.1.5 Test-Bed DNS Ethernet Traffic

4.1.6 Customer RTP Ethernet Traffic

It is recommended that Customer RTP connectivity be performed using a VLAN dedicated to RTP traffic between the customer networks and the Optranex 248 switch. Separate IPv4 IP addresses for each of the 1000baseT network interfaces on each of the server chassis⁹ of the Optranex 248 switch should be allocated on this dedicated VLAN subnetwork. All four 1000baseT network interfaces on each Optranex 248 server chassis should be attached to this VLAN subnetwork.

Although, for the trail, the amount of traffic is significantly lower than the maximum capacity of the Optranex 248 switch, IP addresses should be allocated and network connections attached in accordance with the maximum capacity configuration of the switch. This avoids making disruptive modifications at a later date due to growth of the live platform.

Figure 9. Customer RTP Ethernet Traffic

Therefore, four IPv4 IP addresses per server chassis (total 8 IP addresses) on the customer RTP VLAN is required due to the number of RTP ports that are required in a maximum configuration. In a maximum configuration, 64,512 channels requires 129,024 UDP ports, which, when spaced 2 apart (for RTCP), and consuming half of the available UDP port space for a given IP address, requires 8 IPv4 IP addresses in a load-sharing configuration such as is used for performance testing. In an active-standby arrangement, the active server assumes all 8 IP addresses (using IP takeover if necessary) on this VLAN, and would also require 10GE connectivity.

For example, if VLAN 003 is used for Customer RTP traffic, and Class C subnetwork 192.168.3.0/24 is associated with VLAN 003, the A-side of the Optranex 248 platform could be assigned IPv4 IP addresses 192.168.3.10, .11, .12 and .13; the B-side, 192.168.3.20, .21, .22 and .23. This configuration is illustrated in Figure 9.

For the trial, during normal operation (no capacity performance testing in effect), this VLAN must be capable of passing approximately 2016 channels of G.711 RTP PCMU with 10 millisecond and 30 millisecond packetization. A 10 millisecond packetization consists of 80 octets of RTP AVT payload every 10 milliseconds for 2,016 channels full-duplex or 2 x 201,600 packets per second. A 30 millisecond packetization consists of 240 octets of RTP AVT payload every 30 milliseconds for 2,016 channels full-duplex or 2 x 67,200 packets per second. Each RTP packet on the VLAN has 18 octets of Ethernet overhead, 4 octets of VLAN overhead, 20 octets of IPv4 overhead, 8 octets of UDP overhead, and 12 octets of RTP overhead, for a total of 62 octets of overhead. At 10 millisecond packetization that is 62 octets of overhead and 80 octets of payload at 2 x 201,600 packets per second or 458.0353 Mbps. At 30 millisecond packetization that is 62 octets of overhead and 240 octets of payload at 2 x 67,200 packets per second or 324.7104 Mbps.¹⁰

4.1.7 Customer SIP Ethernet Traffic

It is recommended that Carrier Proxy SIP connectivity be performed using a VLAN dedicated to SIP signaling between the carrier proxy and the Optranex 248 switch.¹¹ Separate IPv4 IP addresses for each of the server chassis of the Optranex 248 switch should be allocated on this dedicated VLAN subnetwork. Two 1000baseT network interfaces on each server chassis should be attached to this VLAN subnetwork. Network interfaces distinct from those used for C-SCP connection should be used.

For the trial, this VLAN must be capable of processing a maximum of approximately 2000 simultaneous channels of traffic, consisting of 3 minute average holding time calls. This consists of a maximum of approximately 2000 calls every three minutes or 12 calls per second, which is on the order of a megabit per second of traffic.¹²

4.1.8 SIGTRAN M3UA Ethernet Traffic

It is recommended that SIGTRAN M3UA connection be performed using a VLAN dedicated to communications between the Optranex 248 switch and the PSTN SS7 network. Separate IPv4 IP addresses for each of the server chassis of the Optranex 248 should be allocated on this dedicated VLAN subnetwork. Router connectivity between the Optranex 248 switch servers and the SIGTRAN M3UA signaling gateway(s) should be restricted to the MAC and IPv4 IP addresses of those servers. PoE or GRE may be used between the router and Optranex 248 switch servers to simplify firewall designs for, and further isolate, this traffic.

4.1.8.1 SIGTRAN M3UA Network Configuration

SCTP Multihoming (RFC 4960) is necessary to provide path and network interface redundancy for SIGTRAN M3UA. However, SCTP Multihoming does not function properly through a NAT. This problem can be side-stepped using SCTP-aware NAT (doesn’t really exist yet in a standard form) or by using L2TP, PoE, GRE or other point-to-point route encapsulation for establishing direct IP connections through the edge router.

If Signaling Gateway (SG) IP addresses are within a private network, direct addressing is possible. If the SG IP addresses are in a public network or VPN external to the private network to which the Optranex 248 is attached, route encapsulation to allow the Optranex 248 to assign direct IP addresses allocated from the external network.

An additional requirement for the trial is that all SCTP addresses must be IPv4 addresses.

4.1.8.2 SIGTRAN M3UA AS Configuration

The Optranex 248 switch servers will be configured as two M3UA Application Server Processes (ASPs) serving the same Application Server(s). There will be one Application Server for each of the SS7 Signaling Point Codes assigned to the Optranex 248 switch. Applications Servers should be configurable at the SG in either standby or loadshare traffic modes.

Signaling Point Codes

The Optranex 248 switch will have at least one SS7 point code allocated across both A- and B-side server chassis.

4.1.8.3 SIGTRAN M3UA Traffic Requirements

Sufficient bandwidth between the Optranex 248 gateway switch and the SIGTRAN M3UA signaling gateways is required for proper operation. For the trial, SONET connectivity consists of OC-12 SONET connections; however, only 3 DS3s worth of traffic is initially provided. With average 3-minute holding times, expected average call attempt traffic will be (3 x 672)/180 or 12 calls per second. A typical ISUP call averages 5 messages with an average of 28 octets per message. Adding SIGTRAN M3UA overheads¹³ yeilds an average of 106 octets per message. At 12 calls per second, this totals a mere 10,176 bits per second.

Nevertheless, it is important that this traffic be given priority over less important flows (such as RTP traffic).

4.1.9 DNS Ethernet Traffic

4.1.10 Management Ethernet Traffic

It is recommended that management connectivity be performed using a VLAN dedicated to communications between management stations and the Optranex 248 switch. Separate IPv4 IP address for each server chassis of the Optranex 248 should be allocated on this dedicated VLAN subnetwork. All four 1000baseT network interfaces on each server chassis should be attached to this VLAN subnetwork. Separate IPv4 IP addresses for integrated management of the servers and management of the application should be provided. Management traffic is expected to be insignificant in terms of bandwidth.

4.1.10.1 DNS Ethernet Traffic

The Optranex 248 requires access to DNS for both internal and external hosts to be able to resolve domain names.

4.1.10.2 NTP Ethernet Traffic

The Optranex 248 requires a permanently available NTP (Network Time Protocol) source to synchronize the time-of-day clocks between the platforms and to the network. Should the NTP source be temporarily unavailable, the A- and B-sides of the platform will attempt to synchronize to each other with the A-side as master and the B-side as slave. A network NTP source can be provided using any (or all) of the standard methods: unicast request/response, multicast source, broadcast source. It is preferred that all methods operate on the Management VLAN.

Management stations and monitoring devices should be synchronized to the same time source as the Optranex 248 platform.

4.2 SONET/SDH Connections

The SONET/SDH network connections are illustrated at the top of Figure 6.

Figure 6. SONET/SDH Network Interfaces

There are two primary SONET/SDH connections:

One PSTN Aggregated DS3 over SONET OC-12 connection to the PSTN for carrying live customer traffic and PSTN test traffic during the trial.
One copper SFP loopback connection for the purpose of capacity performance testing.

4.2.1 PSTN Aggregated DS3 over SONET

The primary traffic-bearing SONET/SDH connection for the trial consists of an OC-12 connection which will initially connect 3 aggregated DS3s (a maximum of 2016 channels). These trunks will be organized into trunk groups and assigned a number that will also be assigned (for trunk groups containing outgoing and two-way trunk members) in the C-SCP platform. It is recommended that the OC-12 connection to the interconnect ADM be completed as a 1:1 APS connection where the working OC-12 is connected to one of the two server chassis in the Optranex 248 switch, and the protect OC-12 is connected to the other of the two server chassis in the Optranex 248 switch.

4.2.1.1 Synchronization

The Optranex 248 card contains a stratum 3 clock with accuracy for OC-192 operation. It is expected that aggregated DS3’s are network synchronized to the SONET network or to a stratum 3 clock. If this is not the case, positive and negative pointer adjustment compensation on the Synchronous Payload Envelope for each aggregated DS-3 will be required.¹⁴ The system side of the OC-48 framer on the Optranex 248 card is frame-locked to the line side. Line-side timing can be derived from the SONET network received line signal or can be taken from the on-board stratum 3 clock.

When not connected to the SONET network, and for performance or capacity testing only, the A-side of the Optranex 248 chassis can be configured to take its syncrhonization from the local stratum 3 clock; and the B-side of the Optranex 248 chassis can be configured to take its timing from the receive SONET line.

When connected to the SONET network, both the A- and B-sides of the Optranex 248 gateway switch should be configured to take their timing directly from the SONET receive line, with a fallback to the local stratum 3 clock (and a possible further fall back to DPLL hold).

4.2.2 Test-Bed Copper OC-48 Loop Back

For the purpose of capacity and performance testing, an additional SONET/SDH connection will be simulated using an SFP copper loopback cable capable of 2.488 Gbps operation. One end of this cable is attached to the A-side of the Optranex 248 platform; the other, to the B-side. This connection will be capable of passing 32,256 channels between the A- and B-sides of the Optranex 248 for capacity and performance testing.

4.2.3 Trunk Group Configuration

4.2.3.1 Controlling Exchange

It must be identified whether the Optranex 248 or the remote exchange is the controlling exchange on all two-way trunks.

4.2.3.2 Circuit Management Groups

Circuit management groups will need to be identified. It needs to be specified whether circuit groups align with T1 circuit groups embedded in the aggregated DS3 or, if multiplexing or transmuxing is performed between the aggregated DS3 and the remote switches, the circuit group assignments.

4.2.3.3 Continuity Testing

It must be identified, for all trunks (whether one-way incoming, one-way outgoing, or two-way), whether automatic continuity testing is required and on what basis continuity testing is required (i.e. none, statistical, periodic). The period must be identified if periodic.

For calls terminating on the Optranex 248, for trial, I would prefer to skip the continuity check procedures. If this is permitted under interconnect agreement, I would prefer to release the call with cause value 41 (Temporary Failure) on all terminating calls with automatic continuity request in the IAM. This may increase the signaling load, particularly if (as AT&T does sometimes) continuity testing is performed on every call. If interconnect agreements require, the Optranex 248 will be configured for proper installation of loopback on incoming automatic continuity request calls, and for automatic continuity rechecks. The requirements for the interconnect agreement need to be identified.

For calls originating from the Optranex 248 (and dual-siezure), for trial, I would prefer to skip the continuity check procedures. First preference is to suppress continuity check for all outgoing circuits. As a second preference, should interconnect agreements require continuity checks on outgoing calls, again only for trial, I would prefer to blindly indicate successful COT when the procedures are invoked. The purpose of this is to initially avoid the need to implement the required digital filtering for continuity tone positive and negative detection. Because generation of COT tone is a less onerous requirement, COT tone can be generated but detection blindly accepted. For trial it needs to be identified as to whether full continuity testing

For outgoing calls I would be prefer to skip per-call continuity testing, for trial, and only configure for management initiated continuity tests for circuit turn-up.

If continuity testing is required periodically on outgoing calls under interconnect agreement, I would prefer to blindly indicate successful continuity test.

release the call with cause value 41 (Temporary Failure);
install a loopback (vs. hi-lo);
allow the test to fail.

Also, for continuity tests on calls terminating to the Optranex 248, I would prefer, for the purposes of trial, a loopback arrangement.

4.2.4 Test Lines

For the purpose of test calls providing the capability of voice path quality assessment, a number of test lines will be necessary. Test line terminations will be required on, or via, interconnect switches on the PSTN. Test line terminations will also be provided on the Optranex 248 switch. Test lines include

100	balance and noise test termination (type 100 test line) (balanced-termination)
101	test board communication (type 101 test line)
102	milliwatt test (type 102 test line) (milliwatt)
103	supervisory and signaling test circuit (type 103 test line) (not with SS7)
104	transmission measuring and noise checking (type 104 test line) (silent-termination)
105	automatic transmission measuring test (type 105 test line)
106	spare
107	data transmission test (type 107 test line)
108	digital circuit loopback test (type 108 test line) (loopback)
109	echo canceller test (type 109 test line)

5 Reference Architecture

There are several reference architectures to which the solution architecture applies, as follows:

IETF SIP Architecture
Multiservices Switching Forum Release 1, 2 and 3 Architectures
ETSI Tiphon Release 4 Architecture
ITU-T TR.45 Architecture
3GPP Release 9 IMS Architecture

Of these, by far the most important is the 3GPP Release 9 IMS Architecture as described in 3GPP TS 23.002 V9.2.0 (2009-12): the 3GPP Release 9 IMS Architecture encompasses portions of the ITU-T TR.45 Architecture as it subsumes ITU-T Recommendation Q.1912.5; the ETSI TIPHON Release 4 Architecture has fallen asside for the 3GPP Release 9 IMS Architecture; the Multiservices Switching Form Release 3 Architecture defers to the 3GPP Release 9 IMS Architecture for all of the non-legacy components; and, the IETF SIP Architecture is antiquated for telephony.

The 3GPP Release 9 IMS Architecture¹⁵ consists of four or five elements of interest, and about as many interfaces of interest, in the current discussions:

MRFC: The MRFC is the Media Resource Function Controller. This function in the solution architecture is provided primarily by the Optranex 248 switch.
MRFP: The MRFP is the Media Resource Function Processor. This function in the solution architecture is provided primarily by the Optranex 248 switch.
MGCF: The MGCF is the Media Gateway Controller Function. This function in the solution architecture is provided primarily by the Optranex 248 switch.
MGF: The MGF is the Media Gateway Function. This function in the solution architecture is provided primarily by the Optranex 248 switch.
BGCF: The BGCF is the Breakout Gateway Controller Function. This function in the solution architecture is provided primarily by the customer proxy but partially by the C-SCP platform.
I-CSCF: The I-CSCF is the Interrogating Call Services Control Function. This function in the solution architecture is provided primarily by the customer proxy but partially by the C-SCP platform.
S-CSCF: The S-CSCF is the Serving Call Services Control Function. This function in the solution architecture is provided by the customer proxy.

Mn Interface (MGCF to MGW)

The Mn reference point describes the interfaces between the MGCF and IMS-MGW in the IMS. It has the following properties:

full compliance with the H.248 standard functions for IMS—PSTN/PLMN interworking;
flexible connection handling that allows support of different call models and different media processing pruposes not restricted to H.232 usage;
open architecture where extensions/Packages definition work on the interface may be carried out;
dynamic sharing of IMS-MGW physical node resources (a physical IMS-MGW can be partitioned into logically separate virtual MGWs/domains consisting of a set of statically allocated terminations);
dynamic sharing of transmission resources between the domains as the IMS-MGW controls bearers and manage resources according to the H.248 protocols and functions for IMS.

The Mn reference point is internal to the Optranex 248 switch and is, therefore, not exposed.

Mg Interface (MGCF to CSCF)

The Mg reference point allows the MGCF to forward incoming session signaling (from the circuit switched network) to the CSCF for the purpose of interworking with circuit switched networks. The protocol used for the Mg reference point is SIP (as defined by RFC 3261, other relevant RFCs, and additional enhancements introduced to support 3GPP’s needs).

Mr Interface (S-CSCF to MRFC)

The Mr reference point allows interaction between an S-CSCF and an MRFC. The protocol used for the Mr reference point is SIP (as defined in RFC 3261, other relevant RFCs, and additional enhancements introducted to support 3GPP’s needs).

Mp Interface (MRFC to MRFP)

The Mp reference point allows an MRFC to control media stream resources provided by an MRF. The Mp reference point has the following properties:

full compliance with the H.248 standard; and,
open architecture where extensions (packages) definition work on the interface may be carried out.

The Mp reference point is internal to the Optranex 248 switch and is, therefore, not exposed.

Mj Interface (BGCF to MGCF)

The Mj reference point allows the Breakout Gateway Control Function to exchange session signaling messages with the Media Gateway Control Function for the purpose of interworking to the circuit-switched networks, or for transit networks. The Mj reference point is based on external specifications (i.e. SIP).

6 Protocol Architecture

6.1 C-SCP Interworking Call Flows

The following sections provide interworking call flows between the Optranex 248 switch and the C-SCP platform.

6.2 Calls from PSTN to SIP

Calls from the PSTN terminating on the SIP network that are processed by the Optranex 248 switch and further processed by the C-SCP platform are illustrated in Figure 2.

Figure 2. Calls from PSTN to SIP

Point (1) in Figure 2.

A call is originated and terminates from the PSTN on the Optranex 248 switch. An ISUP IAM is received by the Optranex 248 switch. For an example of the IAM, see Example 6.1.

`FCI`	`number translated`
`CgPN`	NSN, 222-333-4444, presentation-restricted
`CdPN`	NSN, 777-666-5555
`JIP`	830-660
`GAP`	ported number, NSN, 999-666-5555
`GAP`	dialed number, NSN, 444-444-4444, presentation-allowed
`GAP`	additional user provided number - not verified, NSN, 666-666-6666, presentation-allowed
`GN`	calling name, name available/unknown, ‘`"Joe"`’, presentation-allowed
`GN`	original called name, name available/unknown, ‘`"Sue"`’, presentation-allowed
`CPC`	ordinary subscriber
`OLI`	ANI 0

Example 6.1: IAM received by Optranex 248 in Successful PSTN to SIP Call

Point (2) in Figure 2.

The information from the received IAM is translated to a SIP INVITE message and the INVITE is sent to the Carrier Proxy.

Calls coming from the PSTN will have information translated from the IAM to a SIP INVITE and the INVITE will be sent to the Carrier Proxy for number analysis and customer proxy selection or treatment.

All fields in the INVITE (Request-URI, To, From, P-Asserted-Identity, and P-Requested-Identity) will have a tel URI formatted number.

The INVITE corresponding to the above IAM is listed in Message 6.1.

INVITE tel:+19996665555;npdi;rn=+17776665555 SIP/2.0
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001
Max-Forwards: 33
From: "Joe" <tel:+16666666666>;tag=7643kals
To: "Sue" <tel:+14444444444>
Call-ID: 4Fde34wkd11wsGFDs3@gw1.heramax.com
CSeq: 1 INVITE
Contact: <sip:gw1@heramax.com:5060;transport=udp>
P-Asserted-Identity: Joe
 <tel:+12223334444;cpc=ordinary;oli=00;rn=+1830660
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>
Privacy: id
Content-Type: application/sdp
Content-Length: 134

v=0
o=GW 2890844527 2890844527 IN IP4 gw1.heramax.com
s=-
c=IN IP4 gw1.heramax.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Message 6.1: Optranex 248 INVITE generated from IAM in Successful PSTN to SIP Call

For more detail concerning the mapping of ISUP parameters to the outgoing INVITE method, see ‘Translation of IAM to INVITE’ and ‘Example IAM to INVITE Translation’.

Point (3) in Figure 2.

The Carrier Proxy forwards the INVITE as a stateful proxy to the C-SCP.

INVITE tel:+19996665555;npdi;rn=+17776665555 SIP/2.0
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-AAAAAA
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.10
Max-Forwards: 32
From: "Joe" <tel:+16666666666>;tag=7643kals
To: "Sue" <tel:+14444444444>
Call-ID: 4Fde34wkd11wsGFDs3@gw1.heramax.com
CSeq: 1 INVITE
Contact: <sip:gw1@heramax.com:5060;transport=udp>
P-Asserted-Identity: Joe
 <tel:+12223334444;cpc=ordinary;oli=00;rn=+1830660
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>
Privacy: id
Content-Type: application/sdp
Content-Length: 134

v=0
o=GW 2890844527 2890844527 IN IP4 gw1.heramax.com
s=-
c=IN IP4 gw1.heramax.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Message 6.2: Carrier Proxy INVITE in Successful PSTN to SIP Call

Point (4) in Figure 2.

If the C-SCP platform expects that it will take longer that 200 milliseconds to respond to an INVITE with a 3xx, 4xx or 5xx response, it should send a 100 Trying message in response to the INVITE. Should the C-SCP platform delay in responding to the INVITE, the Optranex 248 or Carrier Proxy might cancel the INVITE with a CANCEL request for the dialog (should the call be released on the ISUP side before the response is received). The C-SCP platform is expected to acknowledge the CANCEL request and not further respond to the corresponding INVITE.

SIP/2.0 100 Trying
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-AAAAAA;received=192.168.9.30
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.10
From: "Joe" <tel:+16666666666>;tag=XX
To: "Sue" <tel:+14444444444>;tag=YY
Call-ID: 4Fde34wkd11wsGFDs3@gw1.heramax.com
CSeq: 1 INVITE
Content-Length: 0

Message 6.3: 100 Trying Response from C-SCP for Successful PSTN to SIP Call

Point (5) in Figure 2.

The C-SCP platform will analyze the information and either return a 305 Use Proxy message directing the Carrier Proxy to send the call to a customer proxy, or will return a 4xx or 5xx message indicating an error with a Reason header indicating the Q.850 or ANSI cause value according to the logic outlined later under unsuccessful call flows.

The C-SCP platform, for successful calls, sends a 305 Use Proxy message in response to the Carrier Proxy with the customer proxy to which to forward the call in the Contact header. The procedure for analyzing the received INVITE is detailed in ‘Extracting Information from the INVITE’.

An example using DNS SRV entries is as follows:

SIP/2.0 305 Use Proxy
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-AAAAAA;received=192.168.9.30
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.10
From: "Joe" <tel:+16666666666>;tag=7643kals
To: "Sue" <tel:+14444444444>;tag=YY
Call-ID: 4Fde34wkd11wsGFDs3@gw1.heramax.com
CSeq: 1 INVITE
Contact: "Sue Zy" <sip:sue@customer1.com>
P-Asserted-Identity: Joe Bloe
 <tel:+12223334444;cpc=ordinary;oli=00;rn=+1830660
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>
Privacy: id
Content-Length: 0

Message 6.4: 305 Use Proxy from C-SCP for Successful PSTN to SIP Call

For other mechanisms for distributing calls over customer proxies, see ‘305 Use Proxy Response’.

Point (6) in Figure 2.

The Carrier Proxy acknowledges the response with an ACK message.

ACK sip:tellingua@heramax.com SIP/2.0
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-AAAAAA.1
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.10
Max-Forwards: 70
From: "Joe" <tel:+16666666666>;tag=7643kals
To: "Sue" <tel:+14444444444>;tag=YY
Call-ID: 4Fde34wkd11wsGFDs3@gw1.heramax.com
CSeq: 1 ACK
Content-Length: 0

Message 6.5: Optranex 248 ACK Request for Successful PSTN to SIP Call

Point (7) in Figure 2.
Information from the 305 Use Proxy response from the C-SCP platform (primarily the Contact headers) is used to formulate a new INVITE message that is then sent to the customer proxy. For more details, see ‘Processing of the 305 Use Proxy Reponse’.
Point (8) in Figure 2.
The customer proxy then forwards the INVITE message within the customer’s SIP network.

Additional actions beyond point (8) in Figure 2 are in accordance with 3GPP TS 29.163 V9.0.0 (2009-12) and the interactions between the MGCF and I-CSCF or S-CSCF as desribed in 3GPP TS 24.229 V9.2.0 (2009-12) and do not further involve the C-SCP platform.

6.2.1 Translation of IAM to INVITE

The translation from the IAM to the INVITE at the Optranex 248 switch, sent to the Carrier Proxy will be in accordance with 3GPP TS 29.163 V9.0.0 (2009-12) 7.2.3.2.2., summarized and with additional features as follows:

6.2.1.1 B Number

The Request-URI and To field will always contain the non-ported or ported called number.

INVITE tel:+19996665555 SIP/2.0
To: <tel:+19996665555>
...

If the IAM Forward Call Indicators indicates number translated the npdi parameter will be added to the Request-URI (but not the To header).

INVITE tel:+19996665555;npdi SIP/2.0
To: <tel:+19996665555>
...

If the IAM Generic Address Parameter parameter contains a ported number it will be the number in the To header and the Request-URI. The Called Party Number (which in this case is the LRN) will be added to the Request-URI (but not the To header) in the rn parameter field.¹⁶

INVITE tel:+19996665555;npdi;rn=+17776665555 SIP/2.0
To: <tel:+19996665555>
...

If the IAM Generic Name parameter is present and contains a original called name that is presentation-allowed, it will be used in the display-name portion of the To field. If the name is not available, the display-name ‘"Unavailable"’ will be used instead.¹⁷

INVITE tel:+19996665555;npdi;rn=+17776665555 SIP/2.0
To: "Joe" <tel:+19996665555>
...

6.2.1.2 A Number

If the Calling Party Number is not present, or the Calling Party Number is presentation-restricted, and there is no Generic Address Parameter additional user provided number, the From header will contain:

From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=XXX

If the Calling Party Number is present, but is presentation-restricted, the ‘"id"’ token will be added to a Privacy header.

Privacy: id

If the Calling Party Number is present and is presentation-allowed, or there is a Generic Address Parameter additional user provided number that is presentation-allowed, the From header will contain the tel URL formatted number:

From: <tel:+14443332222>;tag=XXX

If there is a Calling Party Number present (whether presentation-allowed or presentation-restricted, as long as it is network-provided and verified, it will be placed in the P-Asserted-Identity header. This behaviour is consistent with that described for the MGCF in 3GPP TS 29.163 7.2.3.2.2.

P-Asserted-Identity: <tel:+14443332222>

Otherwise, if no network-provided or verified Calling Party Number is present, the P-Asserted-Identity header will contain the invalid number (000-000-0000).¹⁸

P-Asserted-Identity: <tel:+10000000000>

If a Jurisdiction Information Parameter parameter is present in the IAM, it will be added in the rn field of the P-Asserted-Identity header (but not the From header). This behaviour is consistent with RFC 3325 and RFC 4694.¹⁹

P-Asserted-Identity: <tel:+10000000000;rn=+1860660>

The incoming trunk group will always be placed in the P-Asserted-Identity header (but not the From header) and can be used to determine the Jurisdiction Information Parameter if one is present. This behaviour is consistent with RFC 3325 and RFC 4904.

P-Asserted-Identity: <tel:+10000000000;rn=+1860660;trgp=7654321>

If there is a Calling Party Category parameter in the IAM, it will be added to the P-Asserted-Identity (but not the From header) in the cpc parameter. This behaviour is consistent with that described for the MGCF in 3GPP TS 29.163 Annex C.2.²⁰

P-Asserted-Identity:
 <tel:+14443332222;cpc=ordinary;oli=00;rn=+1860660
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>

If there is an Originating Line Information parameter in the IAM, it will be added to the P-Asserted-Identity (but not the From header) in the oli parameter. This behaviour is consistent with that described for the MGCF in 3GPP TS 29.163 Annex H.2.²¹

P-Asserted-Identity:
 <tel:+14443332222;cpc=ordinary;oli=00;rn=+1860660
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>

If there is a Generic Name parameter in the IAM containing the calling name (ISUP method) and it is presentation-allowed, it will be used as the display-name of both the From and P-Asserted-Identity URIs. When it is presentation-restricted it will only be used for the P-Asserted-Identity URI and privacy will be elevated to ‘user’. If the name is not available, the display-name ‘"Unavailable"’ will be used. This behavior is consistent with that described for the MGCF in 3GPP TS 29.163.²²

From: Unavailable <sip:anonymous@anonymous.invalid>;tag=XXX
P-Asserted-Identity: Unavailable
 <tel:+14443332222;cpc=ordinary;oli=00;rn=+1860660
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>
Privacy: id

From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=XXX
P-Asserted-Identity: Joe
 <tel:+14443332222;cpc=ordinary;oli=00;rn=+1860660
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>
Privacy: user

6.2.1.3 Charging Information

Charging information from the received IAM will be translated to a P-Charge-Info header added to the resulting INVITE in accordance with draft-york-sipping-p-charge-info-07 with the following considerations:

draft-york-sipping-p-charge-info-07 shows only sip URIs (and crude ones without a user=phone parameter); however, the ABNF syntax of the P-Charge-Info header allows an addr-spec to be included in the header. The Optranex 248 platform will always place a tel URI in the P-Charge-Info header.

Whenever a P-Charge-Info header is included in the resulting INVITE, the incoming trunk group will always be placed in the P-Charge-Info header (in addition to the P-Asserted-Identity header in the tgrp parameter of the tel URI. This placement of the tgrp parameter in a tel URI is in accordance with RFC 4904. This incoming trunk group can be used to determine a Jurisdiction Information Parameter when one was not present in the received IAM and none was assigned to the incoming trunk group at the Optranex 248.

If there is a Charge Number parameter present in the receive IAM, a P-Charge-Info header will be added to the resulting INVITE in accordance with draft-york-sipping-p-charge-info-07. The address digits (when present) of the Charge Number will be provided in the telephone-subscriber portion of a tel URI in the P-Charge-Info header. When address digits are not present in the Charge Number parameter (because the nature-of-address value indicates that no address is provided) either the Calling Party Number or Called Party Number parameter will be used as the source of the address digits. An npi parameter will be added to the header with the value ISDN in accordance with draft-york-sipping-p-charge-info-07. A noa parameter will also be added to the header with the nature-of-address value contained in the Charge Number parameter, also in accordance with draft-york-sipping-p-charge-info-07. Because a Originating Line Information parameter must also be present whenever a Charge Number is present in a received ANSI IAM, the Originating Line Information parameter will be added to the tel URI in the P-Charge-Info header (in addition to the P-Asserted-Identity header). This use of the oli parameter in a tel URI is in accordance with 3GPP TS 29.163 and draft-patel-dispatch-cpc-oli-parameter-02.

P-Charge-Info: <tel:+13333333333;oli=00
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>;npi=ISDN;noa=3

If there is an Originating Line Information parameter present in the received IAM, but no Charge Number, the Calling Party Number will instead be used to populate the telephone-subscriber portion of the tel URI in the P-Charge-Info header in accordance with ANSI T1.113/2000.²³ A npi parameter will also be added to the P-Charge-Info header with the value ISDN. No noa parameter will be added to the P-Charge-Info header. This addition of the npi and noa parameters is in accordance with draft-york-sipping-p-charge-info-07. For example:

P-Charge-Info: <tel:+12223334444;oli=00
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>;npi=ISDN

If a Jurisdiction Information Parameter is also present in the received IAM, or a Jurisdiction Information Parameter value is associated with the incoming trunk group, it will be added as a rn parameter in the tel URI of any P-Charge-Info header (in addition to the P-Asserted-Identity header). This use of the rn parameter to represent JIP in tel URIs associated with the origination is in accordance with RFC 4694.

P-Charge-Info: <tel:+12223334444;oli=00;rn=+1830660
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>;npi=ISDN

6.2.1.4 Example IAM to INVITE Translation

For this example the IAM has the contents shown in Example 6.2.

`FCI`	`number translated`
`CgPN`	NSN, 222-333-4444, presentation-restricted
`CdPN`	NSN, 777-666-5555
`JIP`	830-660
`GAP`	ported number, NSN, 999-666-5555
`GAP`	dialed number, NSN, 444-444-4444, presentation-allowed
`GAP`	additional user provided number - not verified, NSN, 666-666-6666, presentation-allowed
`GN`	calling name, name available/unknown, ‘`"Joe"`’, presentation-allowed
`GN`	original called name, name available/unknown, ‘`"Sue"`’, presentation-allowed
`CPC`	ordinary subscriber
`OLI`	ANI 0

Example 6.2: IAM for IAM to INVITE Translation Example

The INVITE corresponding to the IAM in Example 6.2 is shown in Message 6.6.

INVITE tel:+999666555;npdi;rn=+17776665555 SIP/2.0
Via: SIP/2.0/UDP sip:gw1.heramax.com:5060;branch=z9hG4bK-000001
Max-Forwards: 33
From: Joe <tel:+16666666666>;tag=7643kals
To: Sue <tel:+4444444444>
CSeq: 1 INVITE
Call-ID: 4Fde34wkd11wsGFDs3@gw1.heramax.com
Contact: <sip:+16666666666
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com
 @gw1.heramax.com;user=phone>
P-Asserted-Identity: Joe
 <tel:+12223334444;cpc=ordinary;oli=00;rn=+1830660
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>
Privacy: id
P-Charge-Info: <tel:+12223334444;oli=00;rn=+1830660
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>;npi=ISDN
Content-Type: application/sdp
Content-Length: 134

v=0
o=GW 2890844527 2890844527 IN IP4 gw1.heramax.com
s=-
c=IN IPV4 gw1.heramax.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Message 6.6: Optranex 248 INVITE from IAM for Successful PSTN to SIP Call Example

Notes for Message 6.6:

Request-URI
The telephone-subscriber portion of the Request-URI contains the ported number from the GAP parameter. The npdi parameter is present in the Request-URI indicating that the number was dipped by the originator, and the rn parameter is present in the Request-URI and contains the local routing number.
Max-Forwards
The value of the Max-Forwards header is calculated by applying a weighting factor to the ISUP Hop Counter parameter.
From
The display-name portion of the From header contains the presentation-allowed calling name from the Generic Name ISUP parameter. The telephone-subscriber portion of the From header contains the presentation-allowed additional user provided number from the Generic Address Parameter ISUP parameter.
To
The display-name portion of the To header contains the presentation-allowed original called name from the Generic Name ISUP parameter. The telephone-subscriber portion of the To header contains the presentation-allowed dialled number from the Generic Address Parameter ISUP parameter.
P-Asserted-Identity
The display-name portion of the P-Asserted-Identity header contains the presentation-allowed calling name from the Generic Name ISUP parameter. The telephone-subscriber portion of the P-Asserted-Identity header contains the presentation-restricted calling pary number from the Calling Party Number ISUP parameter.
Privacy
The Privacy header contains the id token because the telephone-subscriber portion of the P-Asserted-Identity header is presentation-restricted. The privacy level is set to id insted of user because the display-name portion of the P-Asserted-Identity header is presentation-allowed.
P-Charge-Info
The P-Charge-Info header is added to the message because an Originating Line Information parameter is present in the received IAM. The telephone-subscriber portion of the tel URI in the header is taken from the Calling Party Number because a Charge Number does not appear in the IAM. The oli and tgrp parameter in the tel URI in the P-Charge-Info is always populated by the Optranex 248. Because a Jurisdiction Information Parameter is present in the received IAM, a rn parameter is populated in the tel URI. The npi header parameter has the value ISDN because the numbering plan of the Calling Party Number is E.164.
SDP
The SDP specification for the call is calculated by mapping the incoming ISUP circuit from the CS domain to a fixed IP address (host name) and RTP port number on the IMS CN side. The remainder of the specification is for PCM mu-law 8000 samples per second audio (speech).

6.2.2 Processing of Calls Terminating from the PSTN

The requirements for C-SCP processing of the INVITE from the Carrier Proxy for calls terminating from the PSTN are described in this subsection.

6.2.2.1 Extracting Information from the INVITE

The C-SCP platform should largely ignore the From and To headers in the INVITE (except, of course, for the tag parameter).

For information concerning the termination of the call (B Number), the C-SCP platform should examine the Request-URI instead of the To header of the INVITE.

For information concerning the originator (A Number) of the call, the C-SCP platform should examine the P-Asserted-Identity header instead of the From header of the INVITE.

For information concerning the charging (Charge Information) of the call, the C-SCP platform should examine the P-Charge-Info header instead of the From header of the INVITE.

The C-SCP platform should determine the called party parameters (B number) from the Request-URI of the INVITE. The minimum information that will be present in the Request-URI will be the Called Party Number. The most information that will be in the Request-URI will be the Called Party Number, number translated (NP dip) indication and Local Routing Number. The called party name may also be present in the display-name field of the To header. See Table T-1 for details.

Table T-1. Request-URI Parameter Mapping

The C-SCP platform should determine the calling party parameters (A number) from the P-Asserted-Identity header of the INVITE. The minimum information present will be the incoming trunk group number. The most information present will be the calling name, calling number, calling party’s category, originating line information, jurisdiction information parameter and incoming trunk group number. See Table T-2 for details.

Table T-2. P-Asserted-Identity Parameter Mapping

The C-SCP platform should determine the charging information from the P-Charge-Info header of the INVITE. The minimum information present (when the header is present) will be the charge number, originating line information, and incoming trunk group number. The most information present will be the charge number, originating line informaation, incoming trunk group number, numbering plan indicator and nature of address indicator value. See Table T-5 for details.

Table T-5. P-Charge-Info Parameter Mapping

6.2.2.2 305 Use Proxy Response

Using the B number parameters in the Request-URI of the INVITE as listed in Table T-1, (and possibly using the A number parameters in the P-Asserted-Identity header as listed in Table T-2, and perhaps the charge information parameter in the P-Charge-Info header as listed in Table T-5), the C-SCP platform should determine the customer proxy (or proxies) to which to route the call and return them in a 305 Use Proxy or 303 Proxy Redirect response to the INVITE.

The Contact header(s) contained in the 305 Use Proxy or 303 Proxy Redirect response must be formatted as sip URIs.

A possible response to the example above is shown in Message 6.7.

SIP/2.0 305 Use Proxy
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-AAAAAA;received=192.168.9.30
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.10
From: "Joe" <tel:+16666666666>;tag=XX
To: "Sue" <tel:+14444444444>;tag=YY
Call-ID: 111222@gw1.heramax.com
CSeq: 1 INVITE
Contact: <sip:+19996665555@sansay1.customer1.com;user=phone>
Contact: <sip:+19996665555@sansay2.customer2.com;user=phone>
P-Asserted-Identity: Joe
 <tel:+12223334444;cpc=ordinary;oli=00;rn=+1830660
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>
Privacy: id
P-Charge-Info: <tel:+12223334444;oli=00;rn=+1830660
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>;npi=ISDN
Content-Length: 0

Message 6.7: 305 Use Proxy Response for Successful PSTN to SIP Call – Explicity Proxy

Depending on preferred network configuration, the C-SCP can either directly address customer proxies in the Contact headers of the 305 Use Proxy or 303 Proxy Redirect response (as shown in Message 6.7), or can use sip DNS SRV records for the domain by specifiying the general domain, as shown in Message 6.8.

SIP/2.0 305 Use Proxy
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-AAAAAA;received=192.168.9.30
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.10
From: "Joe" <tel:+16666666666>;tag=XX
To: "Sue" <tel:+14444444444>;tag=YY
Call-ID: 111222@gw1.heramax.com
CSeq: 1 INVITE
Contact: <sip:+19996665555@customer1.com;user=phone>
P-Asserted-Identity: Joe
 <tel:+12223334444;cpc=ordinary;oli=00;rn=+1830660
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>
Privacy: id
P-Charge-Info: <tel:+12223334444;oli=00;rn=+1830660
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>;npi=ISDN
Content-Length: 0

Message 6.8: 305 Use Proxy Response for Successful PSTN to SIP Call – DNS SRV Approach

The C-SCP may also do an ENUM query to determine the user within the customer domain similar to that shown in Message 6.9.

Note that in this approach, the Contact header no longer contains a tel URI formatted user-info portion in the sip URI, but contains an actual sip user name. Note that this will affect the Request-URI in the INVITE message ultimately launched to the Customer Proxy, but, in accordance with RFC 3261, the To field will remain unaltered.

SIP/2.0 305 Use Proxy
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-AAAAAA;received=192.168.9.30
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.10
From: "Joe" <tel:+16666666666>;tag=XX
To: "Sue" <tel:+14444444444>;tag=YY
Call-ID: 111222@gw1.heramax.com
CSeq: 1 INVITE
Contact: <sip:sue@customer1.com>
P-Asserted-Identity: Joe
 <tel:+12223334444;cpc=ordinary;oli=00;rn=+1830660
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>
Privacy: id
P-Charge-Info: <tel:+12223334444;oli=00;rn=+1830660
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>;npi=ISDN
Content-Length: 0

Message 6.9: 305 Use Proxy Response for Successful PSTN to SIP Call – I-ENUM Query Approach

As an option, the C-SCP may also query a CNAM database and determine the calling name for the Calling Party Number and alter the P-Asserted-Identity to reflect the calling party name, as shown in Message 6.10.

SIP/2.0 305 Use Proxy
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-AAAAAA;received=192.168.9.30
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.10
From: "Joe" <tel:+16666666666>;tag=XX
To: "Sue" <tel:+14444444444>;tag=YY
Call-ID: 111222@gw1.heramax.com
CSeq: 1 INVITE
Contact: <sip:sue@customer1.com>
P-Asserted-Identity: Joe Bloe
 <tel:+12223334444;cpc=ordinary;oli=00;rn=+1830660
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>
Privacy: id
P-Charge-Info: <tel:+12223334444;oli=00;rn=+1830660
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>;npi=ISDN
Content-Length: 0

Message 6.10: 305 Use Proxy Response for Successful PSTN to SIP Call – CNAM Query Approach

6.2.2.3 Processing of the 305 Use Proxy Reponse

The Carrier Proxy switch may adjust the To and From fields on the INVITE sent to the customer proxy. The To header may be adjusted from information in the Contact header of the 305 Use Proxy response; the From header may be adjusted from information in the P-Asserted-Identity header of the 305 Use Proxy response.

The values in the Contact header or headers consistitute the entire target set for the gateway. Acting as a proxy, the Carrier Proxy selects members in the target set and for each performs the following (in accordance with draft-ietf-speermint-srv-naptr-use-06, RFC 2915 and RFC 2782):

A DNS NAPTR query is performed on the domain name portion of the sip URI. If there are records in the result, the ‘_sip._udp.*’ record is selected. Otherwise, if there are no records in the result, a new name is generated by concatentating ‘_sip._udp.’ and the domain name.
A DNS SRV query is performed on the name resulting from the previous step. If there are records in the result, a record is selected according to the rules of DNS SRV entries. Otherwise, the original domain name portion of the sip URI selected as the new name.
If the result from the previous step is an A or AAAA RR, this step is skipped and the IP address is used to address the INVITE to the customer proxy. If the result from the previous step is a name, a DNS QUERY query is performed on the name.

6.2.2.4 Example of a Successful Call from PSTN to SIP

Refer to Figure 2 for the messages exchanged that correspond with the numbers below.

Point (1) in Figure 2.

A call is generated within the PSTN and terminates on the Optranex 248 switch. The Optranex 248 switch receives an IAM message, which, in this example, contains the parameters shown in Example 6.3.

`FCI`	`number translated`
`CgPN`	NSN, 222-333-4444, presentation-restricted
`CdPN`	NSN, 777-666-5555
`JIP`	830-660
`GAP`	ported number, NSN, 999-666-5555
`GAP`	dialed number, NSN, 444-444-4444, presentation-allowed
`GAP`	additional user provided number - not verified, NSN, 666-666-6666, presentation-allowed
`GN`	calling name, name available/unknown, ‘`"Joe"`’, presentation-allowed
`GN`	original called name, name available/unknown, ‘`"Sue"`’, presentation-allowed
`CPC`	ordinary subscriber
`OLI`	ANI 0

Example 6.3: IAM received for Successful PSTN to SIP Call Example

Point (2) in Figure 2.

The Optranex 248 switch uses the information from the received IAM to generate an INVITE message which is sent to the Carrier Proxy. The INVITE corresponding to the IAM shown in Example 6.3 is shown in Message 6.11.

INVITE tel:+19996665555;npdi;rn=+17776665555 SIP/2.0
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001
From: "Joe" <tel:+16666666666>;tag=XX
To: "Sue" <tel:+14444444444>
Call-ID: 111222@gw1.heramax.com
CSeq: 1 INVITE
Contact: <sip:+16666666666
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com
 @gw1.heramax.com:5060;user=phone>
Max-Forwards: 33
P-Asserted-Identity: Joe
 <tel:+12223334444;cpc=ordinary;oli=00;rn=+1830660
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>
Privacy: id
P-Charge-Info: <tel:+12223334444;oli=00;rn=+1830660
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>;npi=ISDN
Content-Type: application/sdp
Content-Length: 134

v=0
o=GW 2890844527 2890844527 IN IP4 gw1.heramax.com
s=-
c=IN IP4 gw1.heramax.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Message 6.11: INVITE generated for Successful PSTN to SIP Call Example

Point (3) in Figure 2.

The Carrier Proxy forwards the INVITE message to the C-SCP for processing.

INVITE tel:+19996665555;npdi;rn=+17776665555 SIP/2.0
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-AAAAAA
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.10
Max-Forwards: 32
From: "Joe" <tel:+16666666666>;tag=7643kals
To: "Sue" <tel:+14444444444>
Call-ID: 4Fde34wkd11wsGFDs3@gw1.heramax.com
CSeq: 1 INVITE
Contact: <sip:gw1@heramax.com:5060;transport=udp>
P-Asserted-Identity: Joe
 <tel:+12223334444;cpc=ordinary;oli=00;rn=+1830660
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>
Privacy: id
Content-Type: application/sdp
Content-Length: 134

v=0
o=GW 2890844527 2890844527 IN IP4 gw1.heramax.com
s=-
c=IN IP4 gw1.heramax.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Message 6.12: INVITE forwarded in Successful PSTN to SIP Call Example

Point (4) in Figure 2.

In this example, the C-SCP platform determines that it might not respond to the INVITE message within 200 milliseconds and so sends a 100 Trying message as shown in Message 6.13.

SIP/2.0 100 Trying
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-AAAAAA;received=192.168.9.30
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.10
From: "Joe" <tel:+16666666666>;tag=XX
To: "Sue" <tel:+14444444444>;tag=YY
Call-ID: 111222@gw1.heramax.com
CSeq: 1 INVITE
Content-Length: 0

Message 6.13: 100 Trying Response in Successful PSTN to SIP Call Example

Point (5) in Figure 2.

The C-SCP platform must perform the processing described in this document (see ‘Processing of Calls Terminating from the PSTN’) and, when the call is successful, return a 305 Use Proxy message contianing the customer proxy or proxies to which to redirect the call.

SIP/2.0 305 Use Proxy
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-AAAAAA;received=192.168.9.30
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.10
From: "Joe" <tel:+16666666666>;tag=XX
To: "Sue" <tel:+14444444444>;tag=YY
Call-ID: 111222@gw1.heramax.com
CSeq: 1 INVITE
Contact: <sip:sue@customer1.com>
P-Asserted-Identity: Joe Bloe
 <tel:+12223334444;cpc=ordinary;oli=00;rn=+1830660
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>
Privacy: id
P-Charge-Info: <tel:+12223334444;oli=00;rn=+1830660
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>;npi=ISDN
Content-Length: 0

Message 6.14: 305 Use Proxy Response in Successful PSTN to SIP Call Example

Note that in Message 6.14, the Contact header is translated with an I-ENUM query to the actual sip address of the termination and uses the generic domain usable in the NAPTR and SRV entry approach.

Point (6) in Figure 2.

The Carrier Proxy switch acknowledges the 305 Use Proxy response with an ACK request as shown in Message 6.15.

ACK sip:anonymous@gw1.heramax.com SIP/2.0
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-AAAAAA
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.10
From: "Joe" <tel:+16666666666>;tag=XX
To: "Sue" <tel:+14444444444>;tag=YY
Call-ID: 111222@gw1.heramax.com
CSeq: 1 ACK
Contact: <sip:+16666666666
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com
 @gw1.heramax.com:5060;user=phone;transport=udp>
Content-Length: 0

Message 6.15: ACK Request in Successful PSTN to SIP Call Example

Point (7) in Figure 2.

The Carrier Proxy switch generates an INVITE message toward the specified customer proxy. The customer proxy is not within the MGCF trust domain and, therefore, all privacy fields are stripped. The INVITE message is shown in Message 6.16.

INVITE sip:sue@customer1.com SIP/2.0
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001
From: "Joe" <tel:+16666666666>;tag=XXX
To: "Sue" <tel:+14444444444>
Call-ID: 111223@gw1.heramax.com
CSeq: 1 INVITE
Contact: <sip:+16666666666
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com
 @gw1.heramax.com:5060;user=phone;transport=udp>
Max-Forwards: 33
Content-Type: application/sdp
Content-Length: 134

v=0
o=GW 2890844527 2890844527 IN IP4 gw1.heramax.com
s=-
c=IN IP4 gw1.heramax.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Message 6.16: Customer Proxy INVITE for Successful PSTN to SIP Call Example

Point (8) in Figure 2 and beyond.
The C-SCP platform is no longer involved in the call. Interaction between the Carrier Proxy and the customer proxy is in accordance with the exchange between the MGCF and I-CSCF or S-CSCF in 3GPP TS 24.229 and 3GPP TS 29.163 (and RFCs called out by these specification) with minor variations for US networks.

6.2.3 Treatment of PSTN Originated Calls at the C-SCP Platform

Because the Optranex 248 switch is not populated with subscriber data²⁴ and, therefore, cannot perform number analysis, and also because the Optranex 248 switch does not perform LNP dips,²⁵ the C-SCP must perform part of the normal ISUP processing and distinguish to the Optranex 248 switch various digit analysis failures so that the Optranex 248 switch can apply the necessary treatment of the call. This can in some cases be peformed with a selection of a response code to the INVITE sent to the C-SCP platform, in other cases must be distinguished using the Reason header.²⁶

Figure 4. Treatment of PSTN Calls

The basic call flow for a unsuccessful (treated) call terminating from the PSTN is illustrated in Figure 4. The key features of the call flow are as follows:

Point (1) in Figure 4.
The PSTN has generated a call that terminates on the Optranex 248, and an IAM is launched from the PSTN to the Optranex 248. An example of the IAM is shown in Example 6.4.
Point (2) in Figure 4.
The Optranex 248 translates the information from the received IAM to a SIP INVITE and sends it to the Carrier Proxy platform for processing. The translation of the information from the received IAM into the sent SIP INVITE was detailed previously in ‘Translation of IAM to INVITE’. An example of the INVITE is shown in Message 6.28.
Point (3) in Figure 4.
The Carrier Proxy forwards the INVITE to the C-SCP for further processing. An example of the INVITE message is shown in Message 6.29.
Point (4) in Figure 4.
As the Carrier Proxy has forwarded the INVITE message and is no longer in control of when a response will be made, the Carrier Proxy responds with a 100 Trying message to the Optranex 248. An example of the INVITE message is shown in Message 6.30.

Should the Carrier Proxy delay in responding to the INVITE, the Optranex 248 might cancel the INVITE with a CANCEL request for the dialog (should the call be released before a response is forthcoming). In the event of a CANCEL request and not further respond to the corresponding INVITE.
Point (5) in Figure 4.
If the C-SCP platform expects that it will take longer that 200 milliseconds to respond to an INVITE with a 3xx, 4xx or 5xx response, it should send a 100 Trying message in response to the INVITE.

Should the C-SCP platform delay in responding to the INVITE, the Optranex 248 might cancel the INVITE with a CANCEL request for the dialog (should the call be released before a response is forthcoming). In the event of a CANCEL, the Carrier Proxy and C-SCP platform are expected to acknowledge the CANCEL request and not further respond to the corresponding INVITE. An example of the 100 Trying message is shown in Message 6.13.
Point (6) in Figure 4.
The C-SCP platform analyzes the information in the received INVITE message and determines that treatment is necessary and sends a 4xx or 5xx response. The specific logic that the C-SCP platform uses to determine this, and the specific response chosen, is detailed later in ‘Treatment of PSTN Calls’. An example of a 404 message is shown in Message 6.31.
Point (7) in Figure 4.
The Carrier Proxy returns the 4xx or 5xx response to the Optranex 248 gateway switch. An example of a 404 message is shown in Message 6.32.
Point (8) in Figure 4.
The Optranex 248 switch, upon receiving the 4xx or 5xx response, acknowledges that response by sending a ACK message to the Carrier Proxy in a acknowledgement. An example of the ACK message is shown in Message 6.33.
Point (9) in Figure 4.
The Carrier Proxy, upon receiving the ACK from the Optranex 248 gateway switch, propagates the ACK message to the C-SCP. An example of the ACK message is shown in Message 6.34.
Point (10) in Figure 4.
The Optranex 248 switch releases both the RTP and channel resources associated with the incoming call and issues an ISUP REL message to the previous PSTN switch with the appropriate cause value (from the Reason header of the received 4xx or 5xx response).
Point (11) in Figure 4.
The previous PSTN switch acknowledges the release with an ISUP RLC message.

6.2.3.1 Treatment of PSTN Calls

At point (6) in Figure 4, the C-SCP platform should examine the B Number information present in the Request-URI per Table T-1 (and possibly A number information present in the P-Asserted-Identity per Table T-2) of the INVITE and take exception in accordance with 3GPP TS 29.163, ITU-T Q.1912.5 and RFC 3326 as detailed below.

When the destination number (telephone-subscriber portion of the Request-URI) exists and is allocated to a customer, the C-SCP formulates a 305 Use Proxy response and places the customer proxy (or proxies) in the Contact header of the 305 Use Proxy response as discussed earlier. An example is repeated in Message 6.17.

SIP/2.0 305 Use Proxy
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-AAAAAA;received=182.168.9.30
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.10
From: "Joe" <tel:+16666666666>;tag=XX
To: "Sue" <tel:+14444444444>;tag=YY
Call-ID: 111222@gw1.heramax.com
CSeq: 1 INVITE
Contact: <sip:sue@customer1.com>
P-Asserted-Identity: Joe Bloe
 <tel:+12223334444;cpc=ordinary;oli=00;rn=+1830660
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>
Privacy: id
P-Charge-Info: <tel:+12223334444;oli=00;rn=+1830660
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>
Content-Length: 0

Message 6.17: 305 Use Proxy Response for Successful PSTN to SIP Call Example

Unallocated (unassigned) number

When a dipped non-ported number is not found (that is, there is a npdi parameter in the Request-URI but no rn parameter, and the telephone-subscriber portion of the Request-URI is not allocated to a customer) the C-SCP platform should respond with a 404 Not Found response with Reason headers as shown in Message 6.18.

SIP/2.0 404 Not Found
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-AAAAAA;received=182.168.9.30
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.10
From: "Joe" <tel:+16666666666>;tag=XX
To: "Sue" <tel:+14444444444>;tag=YY
Call-ID: 111222@gw1.heramax.com
CSeq: 1 INVITE
Reason: Q.850 ;cause=1 ;text="unallocated (unassigned) number"
Content-Length: 0

Message 6.18: Unallocated Destination Number Caused Treatment

Note that the ANSI field in the Reason header is an extension to RFC 3326 and draft-jesske-dispatch-reason-in-responses-01. This field is used in the same fashion as Q.850 fields, with the exception that the cause values correspond to ANSI cause values defined in ANSI T1.113/2000.

When a non-dipped or dipped-non-ported number (telephone-subscriber portion of the Request-URI) is within a number block allocated to the customer but has no subscriber assigned, the C-SCP platform should respond with a 404 Not Found response with Reason headers as shown in Message 6.19.

SIP/2.0 404 Not Found
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-AAAAAA;received=182.168.9.30
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.10
From: "Joe" <tel:+16666666666>;tag=XX
To: "Sue" <tel:+14444444444>;tag=YY
Call-ID: 111222@gw1.heramax.com
CSeq: 1 INVITE
Reason: Q.850 ;cause=1 ;text="unallocated (unassigned) number"
Content-Length: 0

Message 6.19: Unallocated Destination Number Caused Treatment

No route to destination

Send special information tone

Misdialled trunk prefix

User busy

Subscriber absent

Call rejected

Number changed

If the number (telephone-subscriber portion of the Request-URI) has been changed and redirect is in force, the C-SCP should respond with a 404 Not Found response with Reason headers as shown in Message 6.20.

SIP/2.0 404 Not Found
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-AAAAAA;received=182.168.9.30
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.10
From: "Joe" <tel:+16666666666>;tag=XX
To: "Sue" <tel:+14444444444>;tag=YY
Call-ID: 111222@gw1.heramax.com
CSeq: 1 INVITE
Reason: Q.850 ;cause=22 ;text="number changed"
Content-Length: 0

Message 6.20: Number Changed Caused Treatment – 404 Not Found Response

or, alternately if automatic redirect is to be performed, a 301 Moved Permanently response with Reason headers as shown in Message 6.21.

SIP/2.0 301 Moved Permanently
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-AAAAAA;received=182.168.9.30
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.10
From: "Joe" <tel:+16666666666>;tag=XX
To: "Sue" <tel:+14444444444>;tag=YY
Call-ID: 111222@gw1.heramax.com
CSeq: 1 INVITE
Contact: <tel:+19998887777>
Reason: Q.850 ;cause=22 ;text="number changed"
Content-Length: 0

Message 6.21: Number Changed Caused Treatment – 301 Moved Permanently Response

where ‘999-888-7777’ is the new number.

Redirect to new destination

Destination out of order

Invalid number format (address incomplete)

If the destination number format (telephone-subscriber portion of the Request-URI) is invalid (e.g. the number is an international rather than national number), the C-SCP should respond with a 484 Address Incomplete response with Reason headers as shown in Message 6.22.

SIP/2.0 484 Address Incomplete
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-AAAAAA;received=182.168.9.30
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.10
From: "Joe" <tel:+16666666666>;tag=XX
To: "Sue" <tel:+14444444444>;tag=YY
Call-ID: 111222@gw1.heramax.com
CSeq: 1 INVITE
Reason: Q.850 ;cause=28 ;text="invalid number format (address incomplete)"
Content-Length: 0

Message 6.22: Invalid Number Format Caused Treatment

Normal, unspecified

No circuit/channel available

Network out of order

Should the network be out of order the C-SCP platform should return a 500 Server Internal Error response with Reason headers as shown in Message 6.23.

SIP/2.0 500 Server Internal Error
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-AAAAAA;received=182.168.9.30
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.10
From: "Joe" <tel:+16666666666>;tag=XX
To: "Sue" <tel:+14444444444>;tag=YY
Call-ID: 111222@gw1.heramax.com
CSeq: 1 INVITE
Reason: Q.850 ;cause=38 ;text="network out of order"
Content-Length: 0

Message 6.23: Network Out-of-order Caused Treatment

Temporary failure

Should a temporary failure occur in the C-SCP platform, either associated with the platform or this specific dialog, it should return a 500 Server Internal Error response with Reason headers as shown in Message 6.24.

SIP/2.0 500 Server Internal Error
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-AAAAAA;received=182.168.9.30
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.10
From: "Joe" <tel:+16666666666>;tag=XX
To: "Sue" <tel:+14444444444>;tag=YY
Call-ID: 111222@gw1.heramax.com
CSeq: 1 INVITE
Reason: Q.850 ;cause=41 ;text="temporary failure"
Content-Length: 0

Message 6.24: Temporary Failure Caused Treatment

Switching equipment congestion

Should the Tel-Lingu platform be experiencing congestion, it should return a 500 Server Internal Error response with Reason headers as shown in Message 6.25.

SIP/2.0 500 Server Internal Error
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-AAAAAA;received=182.168.9.30
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.10
From: "Joe" <tel:+16666666666>;tag=XX
To: "Sue" <tel:+14444444444>;tag=YY
Call-ID: 111222@gw1.heramax.com
CSeq: 1 INVITE
Reason: Q.850 ;cause=42 ;text="switching equipment congestion"
Content-Length: 0

Message 6.25: Switching Equipment Congestion Caused Treatment

Resource unavailable, unspecified

Misrouted call to a ported number

When a dipped ported number is not found (that is, there is a npdi and rn parameter in the Request-URI, but the telephone-subscriber portion of the Request-URI is not allocated to a customer) the C-SCP platform should send a 404 Not Found response with Reason headers as shown in Message 6.26.

SIP/2.0 404 Not Found
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-AAAAAA;received=182.168.9.30
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.10
From: "Joe" <tel:+16666666666>;tag=XX
To: "Sue" <tel:+14444444444>;tag=YY
Call-ID: 111222@gw1.heramax.com
CSeq: 1 INVITE
Reason: ANSI ;cause=26 ;text="misrouted call to a ported number"
Reason: Q.805 ;cause=14 ;text="QoR: ported number"
Content-Length: 0

Message 6.26: Misrouted Call to Ported Number Caused Treatment

Number portability Query on Release – number not found

When a non-dipped number (telephone-subscriber portion of the Request-URI with no npdi parameter in the Request-URI) is found to be ported out, the response should be a 404 Not Found response with Reason headers as shown in Message 6.27.

SIP/2.0 404 Not Found
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-AAAAAA;received=182.168.9.30
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.10
From: "Joe" <tel:+16666666666>;tag=XX
To: "Sue" <tel:+14444444444>;tag=YY
Call-ID: 111222@gw1.heramax.com
CSeq: 1 INVITE
Reason: ANSI ;cause=27 ;text="NP QoR - number not found"
Reason: Q.850 ;cause=14 ;text="QoR: ported number"
Content-Length: 0

Message 6.27: Number Not Found Caused Treatment

6.2.3.2 Example of an Unsuccessful Call from PSTN to SIP

Refer to Figure 2 for the messages exchanged that correspond with the numbers below.

Point (1) in Figure 2.

A call is generated by the PSTN and an IAM is sent to the Optranex 248 as the terminating switch. The IAM for this example contains the information shown in Example 6.4.

`FCI`	`number translated`
`CgPN`	NSN, 222-333-4444, presentation-restricted
`CdPN`	NSN, 777-666-5555
`JIP`	830-660
`GAP`	ported number, NSN, 999-666-5555
`GAP`	dialed number, NSN, 444-444-4444, presentation-allowed
`GAP`	additional user provided number - not verified, NSN, 666-666-6666, presentation-allowed
`GN`	calling name, name available/unknown, ‘`"Joe"`’, presentation-allowed
`GN`	original called name, name available/unknown, ‘`"Sue"`’, presentation-allowed
`CPC`	ordinary subscriber
`OLI`	ANI 0

Example 6.4: IAM received for Unsuccessful PSTN to SIP Call Example

For the purpose of this example, the LRN present in the CdPN (777-666-5555) is a correct LRN for the Optranex 248, however, the ported number (999-666-5555) is no longer ported here and has been ported out.

Point (2) in Figure 2.

The Optranex 248 translates the incoming IAM to a SIP INVITE and sends it to the Carrier Proxy for processing.

INVITE tel:+19996665555;npdi;rn=+17776665555 SIP/2.0
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001
From: "Joe" <tel:+16666666666>;tag=XXX
To: "Sue" <tel:+14444444444>
Call-ID: 111222@gw1.heramax.com
CSeq: 1 INVITE
Contact: <sip:+16666666666
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com
 @gw1.heramax.com:5060;user=phone;transport=udp>
Max-Forwards: 33
P-Asserted-Identity: Joe
 <tel:+12223334444;cpc=ordinary;oli=00;rn=+1830660
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>
Privacy: id
P-Charge-Info: <tel:+12223334444;oli=00;rn=+1830660
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>
Content-Type: application/sdp
Content-Length: 134

v=0
o=GW 2890844527 2890844527 IN IP4 gw1.heramax.com
s=-
c=IN IP4 gw1.heramax.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Message 6.28: Optranex 248 INVITE for Unsuccessful PSTN to SIP Call Example

Notes:

The tel URI in the Request-URI contains the termination number. In this case, the number is ported and was translated as indicated by the npdi parameter, and the LRN associated with the ported number is provided in the rn parameter.
The From and To header contain the additional user provided calling number and the dialed number from the IAM.
The Contact header provides only displayable information about the originator.
The Max-Forwards header value is calculated by applying a weighting factor to the received ISUP Hop Counter parameter.
The P-Asserted-Identity header provides private infomration about the originator, including the calling party number, calling party’s cagetory, originating line information, jurisdiction information parameter, incoming trunk group and terminating gateway switch.
the P-Charge-Info header provides the private information about the originator, including the charge number, calling party’s category, originating line information, jurisdiction information parameter, incoming trunk group and terminating gateway switch.
The trunk-context parameter, in the various headers in which it appears, contains the hostname associated with the specific Optranex 248 gateway switch that received the call. The tgrp parameter is only meaningful within the context of this gateway switch.

Point (3) in Figure 2.

The Carrier Proxy forwards the INVITE to the C-SCP for further processing.

INVITE tel:+19996665555;npdi;rn=+17776665555 SIP/2.0
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z8hG4bK-AAAAAA
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.10
From: "Joe" <tel:+16666666666>;tag=XXX
To: "Sue" <tel:+14444444444>
Call-ID: 111222@gw1.heramax.com
CSeq: 1 INVITE
Contact: <sip:+16666666666
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com
 @gw1.heramax.com:5060;user=phone;transport=udp>
Max-Forwards: 32
P-Asserted-Identity: Joe
 <tel:+12223334444;cpc=ordinary;oli=00;rn=+1830660
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>
Privacy: id
P-Charge-Info: <tel:+12223334444;oli=00;rn=+1830660
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com>
Content-Type: application/sdp
Content-Length: 134

v=0
o=GW 2890844527 2890844527 IN IP4 gw1.heramax.com
s=-
c=IN IP4 gw1.heramax.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Message 6.29: Carrier Proxy INVITE for Unsuccessful PSTN to SIP Call Example

Note that the INVITE message forwarded is not altered from the INVITE message received with the exception of the header fields which must be altered for proxy behaviour in accordance with RFC 3261.

Point (4) in Figure 2.

The Carrier Proxy, because it has forwarded the INVITE message and cannot determine when it will receive a response, responds to the incoming invite with a 100 Trying message.

SIP/2.0 100 Trying
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-AAAAAA;received=192.168.9.30
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.10
From: "Joe" <tel:+16666666666>;tag=XX
To: "Sue" <tel:+14444444444>;tag=YY
Call-ID: 111222@gw1.heramax.com
CSeq: 1 INVITE
Content-Length: 0

Message 6.30: Carrier Proxy 100 Trying for Unsuccessful PSTN to SIP Call Example

Point (5) in Figure 2.
The C-SCP platform determines that it will respond in sufficient time and skips sending a 100 Trying message.

Point (6) in Figure 2.

The C-SCP looks up the destination number (999-666-5555) and determines that the number does not belong to a customer. Because the Request-URI contains a npdi indication, as well as a rn routing number, it surmizes that the call to the ported number has been misrouted. So, it responds with a 404 Not Found response and includes the Reason header with cause values appropriate for a misrouted call to a ported number.

SIP/2.0 404 Not Found
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z8hG4bK-AAAAAA;received=192.168.9.30
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.10
From: "Joe" <tel:+16666666666>;tag=XX
To: "Sue" <tel:+14444444444>;tag=YY
Call-ID: 111222@gw1.heramax.com
CSeq: 1 INVITE
Reason: ANSI ;cause=26 ;text="misrouted call to a ported number"
Reason: Q.805 ;cause=14 ;text="QoR: ported number"
Content-Length: 0

Message 6.31: C-SCP 404 Not Found Response for Unsuccessful PSTN to SIP Call Example

Point (7) in the Figure 2.

The Carrier Proxy, upon receiving the 4xx or 5xx response, forwards the response to the Optranex 248 gateway switch.

SIP/2.0 404 Not Found
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.10
From: "Joe" <tel:+16666666666>;tag=XX
To: "Sue" <tel:+14444444444>;tag=YY
Call-ID: 111222@gw1.heramax.com
CSeq: 1 INVITE
Reason: ANSI ;cause=26 ;text="misrouted call to a ported number"
Reason: Q.805 ;cause=14 ;text="QoR: ported number"
Content-Length: 0

Message 6.32: Carrier Proxy 404 Not Found Response for Unsuccessful PSTN to SIP Call Example

Point (8) in the Figure 2.

Upon receiving the 404 Not Found response, the Optranex 248 switch acknowledges receipt of the 4xx message.

ACK sip:anonymous@gw1.heramax.com SIP/2.0
Via: SIP/2.0/UDP gw1.heraax.com:5060;branch=z9hG4bK-000001
From: "Joe" <tel:+16666666666>;tag=XX
To: "Sue" <tel:+14444444444>;tag=YY
Call-ID: 111222@gw1.heramax.com
CSeq: 1 ACK
Content-Length: 0

Message 6.33: Optranex 248 ACK for Unsuccessful PSTN to SIP Call Example

Point (9) in the Figure 2.

The Carrier Proxy, upon receiving the ACK from the Optranex 248, forwards the request to the C-SCP.

ACK sip:anonymous@gw1.heramax.com SIP/2.0
Via: SIP/2.0/UDP cp.heraax.com:5060;branch=z9hG4bK-AAAAAA
Via: SIP/2.0/UDP gw1.heraax.com:5060;branch=z9hG4bK-000001;received=192.168.9.10
From: "Joe" <tel:+16666666666>;tag=XX
To: "Sue" <tel:+14444444444>;tag=YY
Call-ID: 111222@gw1.heramax.com
CSeq: 1 ACK
Content-Length: 0

Message 6.34: Carrier Proxy ACK for Unsuccessful PSTN to SIP Call Example

Point (10) in the Figure 2.
While acknowledging the receipt of the 404 Not Found response, the Optranex 248 switch formulates an ISUP REL message and includes cause value 26 ("misrouted call to a ported number") and releases the call setup.

Note that the release cause is taken directly from the Reason headers of the received 404 Not Found response. The ANSI release cause is used in preferrence to any Q.850 release cause present. When no release cause is present (neither Reason header field is present), the release cause indicating failure beyond an interworking point will be used. Also note that the location of the cause will be beyond and interworking point.
Point (11) in the Figure 2.
The originating PSTN switch completes the release of the call by sending a RLC message to the Optranex 248 switch.

6.3 Calls from SIP to PSTN

Calls from SIP (IMS CN) to the PSTN (CS Domain) are illustrated in Figure 3.

Figure 3. Calls from SIP to PSTN

Call flows shown in blue (between the Carrier Proxy and the C-SCP) are now transparent to both the Customer Proxy and the Optranex 248 gateway switch and are no longer specified by this document (neither the Customer Proxy nor the Optranex 248 gateway switch need to know that the C-SCP exists.

Point (1) in Figure 3.

A user agent (UA) in a customer SIP network initiates a call and launches an INVITE message to the customer’s outgoing SIP proxy. An example of an INVITE message is shown in Message 6.35.

INVITE sip:+19725552222@ss1.customer1.com;user=phone SIP/2.0
Via: SIP/2.0/UDP client.customer1.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:+13145551111@ss1.customer1.com;user=phone>
 ;tag=0fxced76sl
To: Bob <sip:+19725552222@ss1.customer1.com;user=phone>
Call-ID: 2xTb9vxSit55XU7p8@customer1.com
CSeq: 1 INVITE
Contact: <sip:alice@client.customer1.com;transport=udp>
Proxy-Authorization: Digest username="alice", realm="customer1.com",
 nonce="dc3a5ab25302aa931904ba7d88fa1cf5", opaque="",
 uri="sip:+19725552222@ss1.customer1.com;user=phone",
 response="ccdca50cb091d587421457305d097458c"
Content-Type: application/sdp
Content-Length: 154

v=0
o=alice 2890844526 2890844526 IN IP4 client.customer1.com
s=-
c=IN IP4 client.customer1.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Message 6.35: UA INVITE for Successful SIP to PSTN Call

Point (2) in Figure 3.

The customer’s outgoing SIP proxy acknowledges receipt of the INVITE with a 100 Trying response. An example of the response is shown in Message 6.36.

SIP/2.0 100 Trying
Via: SIP/2.0/UDP client.customer1.com:5060;branch=z9hG4bK74bf9
 ;received=192.0.2.101
From: Alice <sip:+13145551111@ss1.customer1.com;user=phone>
 ;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.customer1.com;user=phone>
Call-ID: 2xTb9vxSit55XU7p8@customer1.com
CSeq: 1 INVITE
Content-Length: 0

Message 6.36: Customer Proxy 100 Trying Response for Successful SIP to PSTN Call

Point (3) in Figure 3.

The customer’s outgoing SIP proxy determines that the call is to be sent to the PSTN and forwards the INVITE message to the Carrier Proxy. In performing this function, the customer’s outgoing SIP proxy is performing the I-CSCF (Interrogating Call Services Control Function) of the 3GPP IMS architecture and the Carrier Proxy is acting in the role of the BGCF (Breakout Gateway Control Function).

INVITE sip:+19725552222@cp.heramax.com;user=phone SIP/2.0
Via: SIP/2.0/UDP ss1.customer1.com:5060;branch=z9hG4bK2d4790.1
Via: SIP/2.0/UDP client.customer1.com:5060;branch=z9hG4bK74bf9;received=192.0.2.101
Max-Forwards: 69
Record-Route: <sip:ss1.customer1.com;lr>
From: Alice <sip:+13145551111@ss1.customer1.com;user=phone>
 ;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.customer1.com;user=phone>
Call-ID: 2xTb9vxSit55XU7p8@customer1.com
CSeq: 1 INVITE
Contact: <sip:alice@client.customer1.com;transport=udp>
Content-Type: application/sdp
Content-Length: 154

v=0
o=alice 2890844526 2890844526 IN IP4 client.customer1.com
s=-
c=IN IP4 client.customer1.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Message 6.37: Customer Proxy INVITE for Successful SIP to PSTN Call

Point (4) in Figure 3.

The Carrier Proxy forwards the INVITE message received from the customer’s outgoing SIP proxy to the C-SCP platform for authorization and route selection. Calls coming from the SIP network will have the INVITE from the customer SIP proxy forwarded directly to the C-SCP platform without the need for additional processing at the Carrier Proxy.

When the customer’s outgoing SIP proxy is not considered part of the Carrier Proxy’s trust network, the Carrier Proxy strips all trust headers from the INVITE before forwarding the information on to the C-SCP. When the customer’s outgoing SIP proxy is considered part of the Carrier Proxy’s trust network, the Carrier Proxy proxies the INVITE message to the C-SCP (without modifying any non-proxy headers or fields).

INVITE sip:+19725552222@telingua.heramax.com;user=phone SIP/2.0
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-000001
Via: SIP/2.0/UDP ss1.customer1.com:5060;branch=z9hG4bK2d4790.1;received=192.0.2.111
Via: SIP/2.0/UDP client.customer1.com:5060;branch=z9hG4bK74bf9;received=192.0.2.101
Max-Forwards: 68
Record-Route: <sip:ss1.customer1.com;lr>
From: Alice <sip:+13145551111@ss1.customer1.com;user=phone>
 ;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.customer1.com;user=phone>
Call-ID: 2xTb9vxSit55XU7p8@customer1.com
CSeq: 1 INVITE
Contact: <sip:alice@client.customer1.com;transport=udp>
Content-Type: application/sdp
Content-Length: 154

v=0
o=alice 2890844526 2890844526 IN IP4 client.customer1.com
s=-
c=IN IP4 client.customer1.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Message 6.38: Carrier Proxy C-SCP INVITE for Successful SIP to PSTN Call

Point (5) in Figure 3.

The Carrier Proxy optionally (at some point when it determines that a retransmission of an INVITE might occur before a response is issued, not necessarily at the point shown) issues a 100 Trying message to the customer proxy.

SIP/2.0 100 Trying
Via: SIP/2.0/UDP ss1.customer1.com:5060;branch=z9hG4bK2d4790.1;received=192.0.2.111
Via: SIP/2.0/UDP client.customer1.com:5060;branch=z9hG4bK74bf9;received=192.0.2.101
From: Alice <sip:+13145551111@ss1.customer1.com;user=phone>
 ;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.customer1.com;user=phone>
Call-ID: 2xTb9vxSit55XU7p8@customer1.com
CSeq: 1 INVITE
Content-Length: 0

Message 6.39: Optranex 248 100 Trying Response for Successful SIP to PSTN Call

Point (6) in Figure 3.

The C-SCP platform acknowledges receipt of the INVITE with a 100 Trying response.

SIP/2.0 100 Trying
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.30
Via: SIP/2.0/UDP ss1.customer1.com:5060;branch=z9hG4bK2d4790.1;received=192.0.2.111
Via: SIP/2.0/UDP client.customer1.com:5060;branch=z9hG4bK74bf9;received=192.0.2.101
From: Alice <sip:+13145551111@ss1.customer1.com;user=phone>
 ;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.customer1.com;user=phone>
Call-ID: 2xTb9vxSit55XU7p8@customer1.com
CSeq: 1 INVITE
Content-Length: 0

Message 6.40: C-SCP 100 Trying Response for Successful SIP to PSTN Call

Point (7) in Figure 3.

The C-SCP platform determines that the client is authorized to connect to the PSTN and populates route information in the Contact headers of a 302 Moved Temporarily response. In performing this function the C-SCP platform performs the role of a BGCF (Breakout Gateway Control Function) in the 3GPP TS 23.002 architecture.

The C-SCP platform must implement the dial plan. I would suggest that the Sansay proxies and customer SIP phones be configured to send tel URL formatted numbers or tel URL formatted numbers in a sip URI²⁷ in the To, From and the Request-URI fields. Otherwise the C-SCP platform must be able to accept any of the possible URI variations.²⁸

Should the C-SCP platform discover a difficulty with the addr-spec in a sip URI or telephone-subscriber in a tel URL, the plaform can respond to the INVITE with a normal 4xx or 5xx response which will be relayed back to the customer proxy.

To direct the call to the telephone network, the C-SCP should formulate a 302 Moved Temporarily response and place the destination number parameters and route information in the Contact headers present in the message.

The Contact header should be formatted as a SIP URI so that the identity of the selected gateway can be provided to the Carrier Proxy.

For example:

SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.30
Via: SIP/2.0/UDP ss1.customer1.com:5060;branch=z9hG4bK2d4790.1;received=192.0.2.111
Via: SIP/2.0/UDP client.customer1.com:5060;branch=z9hG4bK74bf9;received=192.0.2.101
From: Alice <sip:+13145551111@ss1.customer1.com;user=phone>
 ;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.customer1.com;user=phone>
Contact: Bob <sip:+19725552222;npdi
 ;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com@gw1.heramax.com>
 ;user=phone
Contact: Bob <sip:+19725552222;npdi
 ;tgrp=EDTNAB01DS1;trunk-context=gw2.heramax.com@gw2.heramax.com>
 ;user=phone
Call-ID: 2xTb9vxSit55XU7p8@customer1.com
P-Asserted-Identity: Alice <tel:+13145551111;cpc=ordinary;oli=00;rn=+1830660>
Privacy: none
CSeq: 1 INVITE
Content-Length: 0

Message 6.41: C-SCP 302 Moved Temporarily Response for Successful SIP to PSTN Call

Notes:

The Contact headers in the 302 Moved Temporarily response must be formatted as a sip URI (so that the resulting INVITE message will be forwarded to the correct Optranex 248 gateway switch).
The Contact headers in the 302 Moved Temporarily response must contain the dip indicator, npdi, and, when the number is a ported number, must contain the LRN in the rn parameter.
Each Contact header in the 302 Moved Temporarily response must contain trunk-context and tgrp parameters indicating the domain name of the specific Optranex 248 gateway switch selected and the trunk group (route) to use on that switch. The domain name portion of the sip URI must also contain the domain name of the same Optranex 248 gateway switch.
The P-Asserted-Identity header, if any, in the 302 Moved Temporarily response must be formatted as a tel URI.
A P-Asserted-Identity header must be included if the calling party number or calling party’s category is to be included in the resulting IAM.
The P-Charge-Info header, if any, in the 302 Moved Temporarily response must be formatted as a tel URI.
A P-Charge-Info header must be included if the charge number, originating line information, or jurisdiction information parameter is to be included in the resulting IAM.
Any Privacy header included in the 302 Moved Temporarily response will be used to control the presentation of the calling party number and calling name (ISUP CNAM method). A setting of id or higher protects the calling party number; user or higher protects the calling name.

Point (8) in Figure 3.

The Carrier Proxy acknowledges receipt of the 302 Moved Temporarily response with an ACK message.

ACK sip:tellingua@customer1.com SIP/2.0
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-000001
Via: SIP/2.0/UDP ss1.customer1.com:5060;branch=z9hG4bK2d4790.1;received=192.0.2.111
Via: SIP/2.0/UDP client.customer1.com:5060;branch=z9hG4bK74bf9;received=192.0.2.101
Max-Forwards: 70
Route: <sip:gw1.heramax.com;lr>
From: Alice <sip:+13145551111@ss1.customer1.com;user=phone>
 ;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.customer1.com;user=phone>
 ;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@customer1.com
CSeq: 1 ACK

Message 6.42: Carrier Proxy ACK for Successful SIP to PSTN Call

Point (9) in Figure 3.

The Carrier Proxy adds the contents of the Contact header into its target set and issues an INVITE message to the first target.

INVITE sip:+19725552222;npdi;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com\
 @gw1.heramax.com;user=phone SIP/2.0
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-000001
Via: SIP/2.0/UDP ss1.customer1.com:5060;branch=z9hG4bK2d4790.1;received=192.0.2.111
Via: SIP/2.0/UDP client.customer1.com:5060;branch=z9hG4bK74bf9;received=192.0.2.101
Max-Forwards: 67
Record-Route: <sip:ss1.customer1.com;lr>
From: Alice <sip:+13145551111@ss1.customer1.com;user=phone>
 ;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.customer1.com;user=phone>
Call-ID: 2xTb9vxSit55XU7p8@customer1.com
CSeq: 1 INVITE
Contact: <sip:alice@client.customer1.com;transport=udp>
P-Asserted-Identity: Alice <tel:+13145551111;cpc=ordinary;oli=00;rn=+1830660>
Privacy: none
Content-Type: application/sdp
Content-Length: 154

v=0
o=alice 2890844526 2890844526 IN IP4 client.customer1.com
s=-
c=IN IP4 client.customer1.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Message 6.43: Carrier Proxy retargetted INVITE for Success SIP to PSTN Call

Notes:

The Request-URI contains the sip URI exactly as returned in the 302 Moved Temporarily response Contact header in accordance with RFC 3261.
The P-Asserted-Identity, P-Charge-Info and Privacy headers are taken directly from the 302 Moved Temporarily response. This is consistent with proxy behaviour.

Point (10) in Figure 3.

The Optranex 248 translates the incoming INVITE message and the headers to formulate an IAM which is sent to the PSTN.

The INVITE and headers received by the Optranex 248 platform is mapped to an IAM message as detailed in ‘Translation of INVITE to IAM’. This process results in the IAM shown in Example 6.5, which is sent to the SS7 network.

`FCI`	`number translated`
`CgPN`	NSN, 314-555-1111, presentation-allowed
`CdPN`	NSN, 972-555-2222
`JIP`	830-660
`GN`	calling name, name available/unknown, ‘`"Alice"`’, presentation-allowed
`GN`	original called name, name available/unknown, ‘`"Bob"`’, presentation-allowed
`CPC`	ordinary subscriber
`OLI`	ANI 0

Example 6.5: IAM sent for Successful SIP to PSTN Call

After this point, the Carrier Proxy platform is no longer necessarily in the message exchange which follows along according to RFC 3261, RFC 3666, RFC 3372, ITU-T Q.1912.5 and 3GPP TS 29.163.²⁹

6.3.1 Translation of INVITE to IAM

Fields from the received INVITE are mapped to the outgoing IAM parameter by the Optranex 248 as follows:

If the trunk-context parameter in the Request-URI does not correspond to the receiving Optranex 248 platform, a 502 Bad Gateway response will be returned and no IAM will be generated.
The translated IAM will be sent on the trunk group specified with the tgrp parameter of the Request-URI. If all trunks are busy in the trunk group, a 503 Service Unavailable response will be generated so that the Carrier Proxy can try the next route. When all routes are busy, the Carrier Proxy will issue treatment toward the SIP proxy (e.g. 503 Service Unavailable).
If the Request-URI header has npdi parameter set in the tel URI formatted user-info portion of the Request-URI in accordance with RFC 4694, the number translated bit will be set in the Forward Call Indicators of the IAM.
The telephone-subscriber from the tel URI of the Request-URI (or if a rn parameter is present, the contents of the rn parameter) will be used to populate the Called Party Number of the IAM. This is consistent with the behavior of the MGCF described in 3GPP TS 29.163 7.2.3.1.2A and RFC 4694.
If the rn parameter exists in the Request-URI user-info tel URI portion, the telephone-subscriber part of the tel URI will be used to populate the ported number in a Generic Address Parameter in the IAM. This is consistent with the behavior of the MGCF described in 3GPP TS 29.163 7.2.3.1.2A and RFC 4694.
If the cic parameter exists in the Request-URI tel URI in accordance with RFC 4694, the value of this parameter will be used to populate a Carrier Identification parameter in the outgoing IAM.
If the dai parameter exists in the Request-URI tel URI in accordance with draft-yu-tel-dai-08, the value of this parameter will be used to populate the Carrier Selection Information parameter in the outgoing IAM.
If there is a recognized telephone-subscriber portion in the To header and it does not correspond to the Called Party Number, a "dialled number" Generic Address Parameter will be added to the outgoing IAM.
If there is a display-name portion in the To header and the ISUP CNAM method is marked on the trunk group, a "original called name" Generic Name parameter that is presentation-allowed will be added to the outgoing IAM.
If a cpc parameter exists in the P-Asserted-Identity header, a Calling Party Category parameter will be included in the IAM with the value indicated. This behaviour is consistent with that described for the MGCF in 3GPP TS 29.163 Annex C.1.³⁰
If a oli parameter exists in the P-Charge-Info or P-Asserted-Identity header; an Originating Line Information parameter will be included in the IAM with the value indicated. This behaviour is consistent with that described for the MGCF in 3GPP TS 29.163 Annex H.1.³¹
If an rn parameter exists in the P-Charge-Info or P-Asserted-Identity header, it will be used to populate the Jurisdiction Information Parameter in the outgoing IAM. This behaviour is consistent with RFC 4694.³²
If a valid telephone-subscriber number is present in the P-Charge-Info header, and it is different from the Calling Party Number when the noa parm is 1, 2, 3 or absent, or, it is different from the Called Party Number when the noa parm is 5, 6 or 7, it will be used in the Charge Number parameter in the outgoing IAM. When a npi or noa parameter is also present in the P-Charge-Info header, the numbering-plan-indicator and nature-of-address in the Charge Number parameter will be populated accordingly. This behaviour is consistent with that described in draft-york-sipping-p-charge-info-07.
If a valid telephone-subscriber number is present in the P-Asserted-Identity header, it will be used in the Calling Party Number parameter of the outgoing IAM. If a Privacy header exists and is set to ‘id’ (or wider scope), the Calling Party Number will be marked presentation-restricted; otherwise, it will be marked presentation-allowed.
If a display-name exists in the P-Asserted-Identity header and the trunk is configured for ISUP CNAM method, the display-name will be placed in a calling name Generic Name parameter in the outgoing IAM. If a Privacy header exists and is set to ‘user’ (or wider scope), the Generic Name will be marked presentation-restricted; otherwise, it will be marked, presentation-allowed.
If there is a recognized telephone-subscriber portion in the From header, and it is different from that of the P-Asserted-Identity header, an "additional user provided number - not verified" Generic Address Parameter will be placed in the outgoing IAM with presentation-allowed.
If there is a display-name portion in the From header, and the outgoing trunk is marked for ISUP CNAM, a "calling name" Generic Name parameter will be placed in the outgoing IAM marked presentation-allowed (if one is not already present).

6.3.1.1 Example of INVITE to IAM Translation

So, for the SIP INVITE message last presented, and repeated in Message 6.44,

INVITE sip:+19725552222;npdi;tgrp=EDTNAB01DS1;trunk-context=gw1.heramax.com\
 @gw1.heramax.com;user=phone SIP/2.0
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-000001
Via: SIP/2.0/UDP ss1.customer1.com:5060;branch=z9hG4bK2d4790.1;received=192.0.2.111
Via: SIP/2.0/UDP client.customer1.com:5060;branch=z9hG4bK74bf9;received=192.0.2.101
Max-Forwards: 67
Record-Route: <sip:ss1.customer1.com;lr>
From: Alice <sip:+13145551111@ss1.customer1.com;user=phone>
 ;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.customer1.com;user=phone>
Call-ID: 2xTb9vxSit55XU7p8@customer1.com
CSeq: 1 INVITE
Contact: <sip:alice@client.customer1.com;transport=udp>
P-Asserted-Identity: Alice <tel:+13145551111;cpc=ordinary;oli=00;rn=+1830660>
Privacy: none
Content-Type: application/sdp
Content-Length: 154

v=0
o=alice 2890844526 2890844526 IN IP4 client.customer1.com
s=-
c=IN IP4 client.customer1.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Message 6.44: 302 Moved Temporarily Response for SIP to PSTN Call Example

the outgoing IAM would be as shown in Example 6.6.

`FCI`	`number translated`
`CdPN`	NSN, 999-888-7777
`CgPN`	NSN, 222-333-4444, presentation-restricted
`GAP`	ported number, NSN, 999-666-5555
`GAP`	dialed number, NSN, 444-444-4444, presentation-allowed
`GAP`	additional user provided number - not verified, NSN, 666-666-6666, presentation-allowed
`JIP`	830-660
`CPC`	ordinary subscriber
`OLI`	ANI 0
`GN`	calling name, "Joe", presentation-allowed
`GN`	called name, "Sue", presentation-allowed

Example 6.6: IAM sent for Successful SIP to PSTN Call Example

6.3.2 Processing of Calls Terminating on the PSTN

For calls terminating on the PSTN, the Carrier Proxy is responsible for controlling interactions with the C-SCP. In conjunction with the C-SCP, the Carrier Proxy is responsible for formatting a SIP INVITE message toward the Optranex 248 that contains information apporpriate for the SIP to ISUP interworking.

The functions of the Carrier Proxy in its interaction with the Customer Proxy and Optranex 248 does not need to deviate from the basic stateless or stateful transaction behaviour described in RFC 3261. As such, any popular commercial or open-source implementation of a SIP proxy server can be used to perform this function. Nevertheless, the specific interaction between the Carrier Proxy and the C-SCP is implementation and network specific and does not really need to conform to a standard.

The steps involved are as follows:

Forwarding the initial SIP INVITE, received by the Carrier Proxy to the C-SCP platform. This is detailed in ‘Forwarding the Initial SIP INVITE’.
Extracting information from the forwarded SIP INVITE at the C-SCP platform. This is detailed in ‘Extracting Information from the SIP INVITE’.
Generating a 302 Moved Temporarily response at the C-SCP and processing the response at the Carrier Proxy. This is detailed in ‘302-Moved-Temporarily Response’.
Generating the SIP INVITE message sent to the Optranex 248 gateway switch at the Carrier Proxy. This is detailed in ‘Generating the Gateway INVITE’.

A complete example is provided in ‘Example of a Successful Call from SIP to PSTN’.

6.3.2.1 Forwarding the Initial SIP INVITE

When the Carrier Proxy receives a SIP INVITE message from a Customer Proxy, it determines whether the call is to be forwarded to the PSTN, on whether some other action is to be performed on the nascent session. This determination could include querying a Carrier ENUM database, or some other mechanism. Upon deciding that the calls is to be forwarded to the PSTN through a Optranex 248 gateway switch, the Carrier Proxy processing the message and forwards a SIP INVITE message to the C-SCP. In processing the received INVITE message and formulating a SIP INVITE message to send to the C-SCP, the Carrier Proxy should perform all of the actions necessary for trust domains, particularly with regards to P-Requested-Identity, P-Asserted-Identity, P-Charge-Info and Privacy fields. That is, any untrusted private headers received from the Customer Proxy should be stripped unless the customer proxy is within the same trust domain as the Carrier Proxy.

Examples are provided in SIP to PSTN Example Point 3, for Point (3) and (4) in Figure 3.

6.3.2.2 Extracting Information from the SIP INVITE

Examples are provided in SIP to PSTN Example Point 5, for Point (5) and (6) in Figure 3.

6.3.2.3 302-Moved-Temporarily Response

Formulating the 302-Moved-Temporarily Response

Examples are provided in SIP to PSTN Example Point 6, for Point (6) and (7) in Figure 3.

Processing the 302-Moved-Temporarily Response

Examples are provided in SIP to PSTN Example Point 8, for Point (8) and (9) in Figure 3.

6.3.3 Generating the Gateway INVITE

The Carrier Proxy is responsible for analyzing information from the received 302 Moved Temporarily response, incorporating that information into the target set for the session and formulating a SIP INVITE message to the first of the indicated gateways (as indicated by the Contact headers in the 302 Moved Temporarily response). When formulating the INVITE message, the Carrier Proxy should take the actions described in RFC 3261 with the following additional considerations:

Examples are provided in SIP to PSTN Example Point 9, for Point (9) in Figure 3.

The Carrier Proxy should not return the 302 Moved Temporarily response message received from the C-SCP back to the Customer Proxy for processing, but must process the response itself.
The Carrier Proxy must not fork the target set resulting from the 302 Moved Temporarily response message.
Any P-Asserted-Identity, Privacy, and P-Charge-Info headers present in the 302 Moved Temporarily response message or to be added by the Carrier Proxy should be forwarded to the Optranex 248 platform.

6.3.3.1 Example of a Successful Call from SIP to PSTN

Point (1) in Figure 3.
A SIP INVITE message is launched by a UA in the cutomer SIP network initiating a session with the Customer Proxy.

The precise format of this message is not specified by this dcoument, but, however, is envisioned to be similar to the following:
Point (2) in Figure 3.
The Customer Proxy optionally responds with a 100 Trying message.
Point (3) in Figure 3.
The Customer Proxy determines that the session is to be established within the heramax.com network and forwards the message to the Carrier Proxy. In forwarding the INVITE to the Carrier Proxy, the Customer Proxy should utilize DNS NAPTR and SRV entries to provide redundancy between images of the Carrier Proxy. Also note that the Carrier Proxy can easily support UDP, TCP and SCTP, both with and without TLS by utilizing software such as SER or OpenSIPS.³³
Point (4) in Figure 3.
The Carrier Proxy determines that the call is destined toward the PSTN and forwards a header-filtered INVITE message to the C-SCP.

The precise format of this message is no longer specified by this document, but, however, was envisioned to be similar to the following:
Point (5) in Figure 3.
The Carrier Proxy optionally responds with a 100 Trying message to suppress retransmission of the INVITE.
Point (6) in Figure 3.
The C-SCP optionally responds with a 100 Trying message to suppress retransmission of the INVITE.
Point (7) in Figure 3.
The C-SCP processes the received INIVTE and formulates a 302 Moved Temporarily response.

The precise format of this message is no longer specified by this document, but, however, was envisioned to be similar to the following:
Point (8) in Figure 3.
The Carrier Proxy acknowledges the 302 Moved Temporarily response.
Point (9) in Figure 3.
The Carrier Proxy formulates a branch INVITE message from the original INVITE message received from the Customer Proxy and the 302 Moved Temporarily response formulated by the C-SCP and sends the INVITE message to the appropriate target within the current target set defined by the 302 Moved Temporarily response message.
Point (10) in Figure 3.
The selected Optranex 248 gateway switch receives the INVITE message from the Carrier Proxy and generates a corresponding ISUP IAM message which is sent to the SS7 network.
Point (11) in Figure 3.
The Optranex 248 optionally response with a 100 Trying message.
Remainder oF Session
The remainder of the session establishment is according to normal SIP to ISUP conversion mechanisms (SIP-T, Q.1912.5, 3GPP TS 29.163). The Carrier Proxy can decide at the time that it issues the INVITE message to the Optranex 248 platform whether it wishes to continue receiving requests or not.

6.3.4 Treatment of SIP Originating Calls

6.3.4.1 Treatment of SIP Calls

Q.850 Cause Values

The mapping of Q.850 cause values returned in an ACM or REL message to SIP responses is illustrated: for the normal class of cause values, in Table T-18; resource unavailable class, Table T-19; service or option not available class, Table T-20.³⁴ These Q.850 cause vaules will be mapped to the corresponding SIP response listed in the tables. SIP 4xx or 5xx response, CANCEL or BYE message will include the Reason header that contains the Q.850 cause value. An example is provided in Message 6.45.

Table T-18. Q.850 Cause Value to SIP Response Mapping - Normal Class

Table T-19. Q.850 Cause Value to SIP Response Mapping - Resource Unavailable Class

Table T-20. Q.850 Cause Value to SIP Response Mapping - Service or Option Not Available Class

SIP/2.0 500 Server Internal Error
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.30
Via: SIP/2.0/UDP ss1.customer1.com:5060;branch=z9hG4bK2d4790.1;received=192.0.2.111
Via: SIP/2.0/UDP client.customer1.com:5060;branch=z9hG4bK74bf9;received=192.0.2.101
From: Alice <sip:+13145551111@ss1.customer1.com;user=phone>
 ;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.customer1.com;user=phone>
Call-ID: 2xTb9vxSit55XU7p8@customer1.com
CSeq: 1 INVITE
Reason: Q.850 ;cause=34 ;text="resource unavailable"
Reason: SIP ;cause=500 ;text="server internal error"
Content-Length: 0

Message 6.45: Q.850 Cause Value to SIP Response Mapping Example

ANSI Cause Values

The mapping of ANSI cause values returned in an ACM or REL message to SIP responses is illustrated: for the normal class of cause values, in Table T-21; resource unavailable class, Table T-22; service or option not available class, Table T-23.³⁵ These ANSI cause values will be mapped to the corresponding SIP response listed in the tables. The SIP 4xx or 5xx response, CANCEL or BYE message will include the Reason header that contains the ANSI cause value, as well as a Q.850 Reason header that contains the corresponding Q.850 cause value. An example is provided in Message 6.46.

Table T-21. ANSI Cause Value to SIP Response Mapping - Normal Class

Table T-22. ANSI Cause Value to SIP Response Mapping - Resource Unavailable Class

Table T-23. ANSI Cause Value to SIP Response Mapping - Service or Option Not Available Class

SIP/2.0 500 Server Internal Error
Via: SIP/2.0/UDP cp.heramax.com:5060;branch=z9hG4bK-000001;received=192.168.9.30
Via: SIP/2.0/UDP ss1.customer1.com:5060;branch=z9hG4bK2d4790.1;received=192.0.2.111
Via: SIP/2.0/UDP client.customer1.com:5060;branch=z9hG4bK74bf9;received=192.0.2.101
From: Alice <sip:+13145551111@ss1.customer1.com;user=phone>
 ;tag=9fxced76sl
To: Bob <sip:+19725552222@ss1.customer1.com;user=phone>
Call-ID: 2xTb9vxSit55XU7p8@customer1.com
CSeq: 1 INVITE
Reason: Q.850 ;cause=1 ;text="unallocated (unassigned) number"
Reason: SIP ;cause=404 ;text="not found"
Content-Length: 0

Message 6.46: ANSI Cause Value to SIP Response Mapping Example

6.3.4.2 Examples of Unsuccessful Calls from SIP to PSTN

6.4 ENUM Calls from PSTN to SIP

A viable option to using the C-SCP platform for calls terminating on the SIP network from the PSTN is to use an I-ENUM or P-ENUM DNS server hierarchy. In this approach, rather than using the C-SCP platform as a redirect server, the Optranex 248 directly queries an ENUM database (e.g. bind9, powerdns). Either a host in the internal network provides a dedicated DNS server, or the Optranex 248 platform acts as a primary DNS server and delegates to ENUM servers maintained by (or on behalf of) the Customer.

Advantages of this arrangement over the 305 Use Proxy or 303 Proxy Redirect approach with the C-SCP platform are as follows:

ENUM provides distributed management of mapping from terminating number to sip URI through delegation. Customer records can be delegated to the customer.
ENUM provides for local caching of transformations at the Optranex 248. Local cacheing of results using the 305 Use Proxy or 303 Proxy Redirect is not possible. A 302 Moved Temporarily message instead of a 305 Use Proxy or 303 Proxy Redirect could be used to provide caching using the Expires header or the expires parameter in the Contact headers in the 302 Moved Temporarily response, however, this mechanism provides no real help with the management of caching as does the ENUM DNS-based approach.
ENUM provides for IXFR (incremental zone transfers) which would allow the Optranex 248 to slave off of the external distributed (even customer managed) ENUM servers and permit per-call lookups to be local to the Optranex 248.
If the DNS SRV approach is used to distribute calls over like customer proxies for redundancy, a DNS query will be required per call anyway. See draft-ietf-speermint-srv-naptr-use-06.
The Optranex 248 does not appear to need to know any of the information on the C-SCP platform for the purpose of terminating calls: it just needs to know the sip URI associated with the B Number and the results of a lookup attempt.

6.4.1 ENUM Call Flows from PSTN to SIP

6.4.1.1 Successful ENUM Call Flow from PSTN to SIP

A successful ENUM call flow from the PSTN to SIP is illustrated in Figure 10.

Figure 10. Successful ENUM Calls from PSTN to SIP

Point (1) in Figure 10.

A call terminating from the PSTN to the Optranex 248 switch begins with the receipt of an ANSI ISUP IAM message. For example, see Example 6.7.

`FCI`	`number translated`
`CgPN`	NSN, 222-333-4444, presentation-restricted
`CdPN`	NSN, 777-666-5555
`JIP`	830-660
`GAP`	ported number, NSN, 999-666-5555
`GAP`	dialed number, NSN, 444-444-4444, presentation-allowed
`GAP`	additional user provided number - not verified, NSN, 666-666-6666, presentation-allowed
`GN`	calling name, name available/unknown, ‘`"Joe"`’, presentation-allowed
`GN`	original called name, name available/unknown, ‘`"Sue"`’, presentation-allowed
`CPC`	ordinary subscriber
`OLI`	ANI 0

Example 6.7: IAM received for Successful ENUM PSTN to SIP Call

Point (2) in Figure 10.
The Optranex 248 uses the Called Party Number and potentially the ported number in a Generic Address Parameter to initiate an ENUM lookup. In the worst case scenario, a DNS NAPTR query is sent to an root ENUM server. The query is, for example:
```
5.5.5.5.6.6.6.9.9.9.e164.arpa
```
Note that this query and response are not required if either the Optranex 248 has a cached result for the query, or accepts zone transfers from the master or customer ENUM database.
Point (3) in Figure 10.
The root ENUM server performs a lookup which either results in a sip URI or an error response. If an error response is returned, the Optranex 248 can immediately release the call using an ANSI ISUP REL message with the appropriate cause value. When a successful response is received, the Optranex 248 selects those NAPTR RRs that support E2U resolution service. For example:
```
$ORIGIN 5.5.5.5.6.6.6.9.9.9.e164.arpa.
NAPTR 10 100 "u" "E2U+pstn:tel"
"!^.*$!sip:sue@customer1.com!".
```
Note that this query and response are not required if either the Optranex 248 has a cached result for the query, or accepts zone transfers from the master or customer ENUM database.
Point (4) in Figure 10.
If a sip URI is returned with a domain name portion that does not correspond to an A pointer; a DNS NAPTR lookup is performed to determine the precise host for this query in accordance with RFC 2915. This permits the DNS NAPTR and SRV mechanism to be used to distribute calls over redundant incoming customer proxies in accordance with RFC 2782. In this example, the target of the DNS NAPTR query is:
```
customer1.com
```
Note that this query and response are not required if either the Optranex 248 has a cached result for the query, accepts zone transfers from the master or customer DNS database, or the sip URI contains a host portion that resolves to an A pointer or a known host to IP address mapping at the Optranex 248 (e.g. /etc/hosts entry).
Point (5) in Figure 10.
In response to the DNS NAPTR query, the root DNS server responds with series of "s" substitutions. In this example, the zone records might look like:
```
IN NAPTR  50 50 "s" "SIPS+D2T" "" _sips._tcp.customer1.com
IN NAPTR  90 50 "s" "SIP+D2T"  "" _sip._tcp.customer1.com
IN NAPTR 100 50 "s" "SIP+D2U"  "" _sip._udp.customer1.com
```
Note that this query and response are not required if either the Optranex 248 has a cached result for the query, accepts zone transfers from the master or customer DNS database, or the sip URI contains a host portion that resolves to an A pointer or a known host to IP address mapping at the Optranex 248 (e.g. /etc/hosts entry).
Point (6) in Figure 10.
The Optranex 248 selects a target from the response to the NAPTR DNS query on the target domain and generates a DNS SRV query on the service target. In this example, the Optranex 248 only supports UDP and therefore selects the entry:
```
_sip._udp.customer1.com
```
If the previous DNS NAPTR lookup results in no records, a normal DNS SRV lookup for ‘_sip._udp.customer1.com’ is performed instead.

Note that the caching period on NAPTR SRV entries is typically 1 to 12 hours permitting for infrequent refresh of the information. Should the customer DNS (or authoritative DNS) be configured for zone transfers to the Optranex 248, the interval can be extended indefinitely.
Point (7) in Figure 10.
The response to the DNS SRV contains either a DNS A record or AAAA record, or does not (e.g. it contains a CNAME record). If the response contains an A or AAAA record, the IP address of the record is used directly. Otherwise, RFC 2782 is followed and and A record results. In this example assume that a CNAME record results as follows:
```
$ORIGIN customer1.com
_sip._udp SRV 0 1 5060 proxy1.customer1.com
_sip._udp SRV 0 1 5060 proxy2.customer1.com
```
Note that the caching period on SRV entries is typically on the order of days permitting for very infrequent refresh of the information. Should the customer DNS (or authoritative DNS) be configured for zone transfers to the Optranex 248, the interval can be extended indefinitely.
Point (8) in Figure 10.
When there is no A nor AAAA record in the response to the DNS SRV query, the procedures of RFC 2782 are followed to select a record look up an A or AAAA record from, for example, a CNAME record. In this example, the target of the DNS query is the CNAME from the SRV response:
```
proxy1.customer1.com
```
Note that if no records were returned to the previous DNS SRV request, a normal A request would be made on just domain target ‘customer1.com’.

Note that caching period on A records can be days causing very infrequent lookups of the information.
Point (9) in Figure 10.
The response on the query to the specific customer proxy will result (when successful) an an A or AAAA record which can then be used as the IP address of the proxy.
```
$ORIGIN customer1.com
proxy1 A 172.30.79.10
proxy2 A 172.30.79.11
```

Point (10) in Figure 10.

The Optranex 248, using the results from the NAPTR and SRV lookups (whether cached, slaved or remote), formulates an INVITE to the sip URI resulting from the lookup and directs it at the customer’s incoming proxy (indicated in the sip URI or DNS SRV result from the lookup).

INVITE sip:sue@customer1.com SIP/2.0
Via: SIP/2.0/UDP gw1.heramax.com:5060;branch=z9hG4bK-000001
From: "Joe" <tel:+16666666666>;tag=XXX
To: "Sue" <tel:+14444444444>
Call-ID: 111223@gw1.heramax.com
CSeq: 1 INVITE
Contact: <sip:+16666666666@gw1.heramax.com:5060;user=phone;transport=udp>
Max-Forwards: 33
Content-Type: application/sdp
Content-Length: 134

v=0
o=GW 2890844527 2890844527 IN IP4 gw1.heramax.com
s=-
c=IN IP4 gw1.heramax.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Message 6.47: ENUM Customer INVITE for Successful PSTN to SIP Call

Point (11) in Figure 10.
The customer proxy determines the location of the destination UA and fowards the INVITE using RFC 3261 procedures.
Point (12) in Figure 10.
A 100 Trying is potentially returned and the call completes or is treated according to RFC 3261 procedures.
Point (13) in Figure 10.
A 100 Trying is potentially returned from the UA and the call completes or is treated according to RFC 3261 procedures.

The ENUM call flow has the significant advantage that, with proper ENUM and DNS management, the majority of calls will not have to query outside the Optranex 248. With 64,512 circuits at an average 3 minute holding time, the resulting 360 calls per second can avoid 4 message exchanges with the network per call. Also, terminating calls do not rely upon the availability of an external box. If the root ENUM/DNS server should go down, cached and slaved results in the ENUM/DNS server local to the Optranex 248 can be used. As incremental zone transfers might stop during a root or customer ENUM/DNS server outage, some calls terminating from the PSTN might be directed to an incorrect customer proxy; however, the customer proxy will be able to treat those calls and return appropriate error codes to the Optranex 248 for releasing the call with the proper cause values back to the PSTN.

Example BIND9 Zone Files

An example of a bind9 configuration file is illustrated in Example 6.8.

acl good_sources { 192.168.0.0/24; };

options {
	...
	also-notify	{ 192.168.0.10; 192.168.0.11; };
	allow-query	{ localhost; good_sources; };
	allow-transfer	{ localhost; good_sources; };
	allow-recursion	{ localhost; good_sources; };
	...
};

...

zone "1.e164.heramax.com" IN {
	type master;
	file "/etc/bind/db.1.e164.heramax.com";
	allow-query { any; };
	allow-transfer { good_sources; };
	notify yes;
	also-notify { 192.168.0.10; 192.168.0.11; };
	zone-statistics yes;
	
};

Example 6.8: Example BIND9 configuration file (named.conf.local)

An example of a bind9 zone file is illustrated in Example 6.9.

$TTL 86400
$ORIGIN heramax.com.
@ IN SOA ns.heramax.com. root.ns.heramax.com. (
	2009013000
	28800
	14400
	3600000
	86400 )
NS  ns.heramax.com.
IN NAPTR  50 50 "s" "SIPS+D2T" "" _sips._tcp.heramax.com.
IN NAPTR  90 50 "s" "SIP+D2T" "" _sip._tcp.heramax.com.
IN NAPTR  90 50 "s" "SIP+D2U" "" _sip._udp.heramax.com.
_sips._tcp SRV 0 1 5060 gw1.heramax.com.
_sips._tcp SRV 0 1 5060 gw2.heramax.com.
_sip._tcp  SRV 0 1 5060 gw1.heramax.com.
_sip._tcp  SRV 0 1 5060 gw2.heramax.com.
_sip._udp  SRV 0 1 5060 gw1.heramax.com.
_sip._udp  SRV 0 1 5060 gw2.heramax.com.
gw1 IN A 192.168.0.10.
gw2 IN A 192.168.0.11.

Example 6.9: Example BIND9 zone file

An example of a bind9 zone file is illustrated in Example 6.10.

$ORIGIN 1.e164.heramax.com.
@ IN SOA ns.heramax.com. root.ns.heramax.com. (
	2009013000
	28800
	14400
	3600000
	86400 )
NS  ns.heramax.com.
1.1.0.9.4.0.8.7 3600 IN NAPTR 100 10 "u" \
	"E2U+sip" "!^(.*)$!sip:\\1@openss7.net!" .
1.1.0.9.4.0.8.7 3600 IN NAPTR 100 10 "u" \
	"E2U+pstn:tel" "!^(.*)$!tel:\\1;npdi;phone-context=openss7!" .

Example 6.10: Example BIND9 zone file

6.4.1.2 Unsuccessful ENUM Call Flow from PSTN to SIP

When the ENUM call flow from PSTN to SIP is unsuccessful, it can be treated in four locations:

At the Optranex 248 as a result of a local NAPTR or SRV lookup that is cached or slaved. When an error result is returned to either of the DNS lookups, the error result can be mapped onto ANSI ISUP Cause values in the REL message.
In contrast to the C-SCP redirect server approach, where it is not possible for the Optranex 248 to treat the call immediately from local data, the ENUM/DNS approach permits this. Although calls that go to treatment by far the minority of calls, this saves additional delay and additional trunk holding times after seizure.
At the ENUM/DNS root server as a result of a local NAPTR or SRV lookup. When an error result is returned to either of the
At the Customer Proxy as a result of proxy operation.
At the Customer UA.

6.5 ENUM Calls from SIP to PSTN

A viable option to using the C-SCP platform for analyzing and routing calls terminating on the PSTN from the SIP network is to use the same I-ENUM or P-ENUM DNS server hierarchy presented in ENUM Calls from PSTN to SIP. In this approach, rather than using the C-SCP platform as a redirect server, the Optranex 248 directly queries an ENUM database (e.g. bind9, powerdns). Either a host in the internal network provides a dedicated DNS server, or the Optranex 248 platform acts as a primary DNS server and delegates to ENUM servers maintained by (or on behalf of) the Customer.

Advantages of this arrangement over the 302 Moved Temporarily approach with the C-SCP platform are as follows:

ENUM provides distributed management of mapping from terminating number to sip URI through delegation. Customer records can be delegated to the customer.
ENUM provides for local caching of transformations at the Optranex 248. Local cacheing of results using the 302 Moved Temporarily Expires header or the expires parameter in the Contact headers in the 302 Moved Temporarily response, however, this mechanism provides no real help with the management of caching as does the ENUM DNS-based approach.
ENUM provides for IXFR (incremental zone transfers) which would allow the Optranex 248 to slave off of the external distributed (even customer managed) ENUM servers and permit per-call lookups to be local to the Optranex 248.

6.5.1 ENUM Call Flow from SIP to PSTN

The SIP phone within the customer network generates an INVITE message toward the customer proxy.
The customer proxy authenticates the SIP phone user and determines that the call is to be routed via the Optranex 248 gateway switch and forwards the INVITE.
The Optranex 248 gateway switch receives the INVITE and initiates call processing consisting of the following steps:
1. The format of the From, P-Requested-Identity, P-Asserted-Identity, To and Request-URI headers are examined for proper format.
2. After determining a proper E.164 number associated with the originator, the number is used to perform an ENUM lookup. The gateway examines the response for ‘E2U+pstn:tel’ and ‘E2U+SIP’ records. The ‘E2U+SIP’ response record is examined to ensure that the domain portion of the sip URI contains a inbound customer proxy that corresponds to the outbound customer proxy from which the INVITE message was received (authorization and verification). The phone-context parameter in the ‘E2U+pstn:tel’ record is used to establish the originating class of service (MTA), and any rn in the tel URI can be used to establish the JIP. The cpc and oli can be used to provide charging information. The tel URI may also contain a P-Charge-Info header substitutions which can contain a billing (charge) number. (When the oli is incuded without a header substitution, the calling number is used by default by ANSI ISUP as the charge number.)
3. After determining a proper E.164 number associated with the termination, the number is used to perform an ENUM number portability lookup. The resulting ‘E2U+pstn:tel’ record contains the number portability dip indicator and the routing number (if applicable).
4. After routing the destination number (whether called number or local routing number), the gateway performs an I-ENUM lookup on the destination number and obtains a ‘E2U+pstn:tel’ record containng the terminating MTA and OCN in the phone-context parameter. This value is used to establish the terminating class of service (MTA, OCN).
5. Having established the originating class of service and the terminating class of service, a P-ENUM lookup is performed on a screening ENUM tree for the destination number. The ‘E2U+pstn:tel’ record in the response can contain a tsn (Transit Network Selector) parameter or a tgrp and trunk-context parameter. These parameter are used to establish the outgoing trunk group associated with the transit network.
Finally, the Optranex 248 gateway switch formulates an ANSI ISUP IAM and launches it toward the selected transit network on the selected trunk group. The rest of the call completes as normal.

This arrangement provides for the option of placing a voice-peering proxy between the customer proxy and the gateway. This proxy can perform its own I-ENUM lookups for the voice peering exchange and route SIP calls over the voice peering fabric, only passing calls to the gateway when the voice peering fabric is not available. Also, when multiple gateways are involved, the proxy can select the appropriate gateway using any number of factors. When this proxy performs a number portability dip, it can include the npdi and possibly rn in the Request-URI so that the gateway does not have to redip for NP. Also, if a P-ENUM dip is also performed (for access restrictions and verification on the originator, or for the termination), a P-Asserted-Identity field and the Request-URI forwarded to the gateway can contain the associated parameters and the enumdi parameter indicating that another P-ENUM dip is not required.

As a fall-back for the NP ENUM dip, the gateway can launch an SS7 LNP dip or perform the 302 Moved Temporarily proceedure with the C-SCP when necessary.

6.5.1.1 ENUM Tables (DNS Zones)

The following ENUM trees are required by the Optranex 248 gateway to implement the call flow as described above:

P-ENUM base tree providing ‘E2U+SIP’ entries for calls terminating to customer SIP networks from the PSTN (used also in the reverse direction for verification and authorization), and ‘E2U+pstn:tel’ entries for establishing the phone-context, rn, oli, cpc and P-Charge-Info header substitutions for call origination through the gateway.
NP ENUM tree providing ‘E2U+pstn:tel’ entries for number portability with npdi and rn parameters as required.
P-ENUM tree partitioned by originating class of service (MTA) providing ‘E2U+pstn:tel’ entries providing phone-context, tns, trgrp and trunk-context parameters for routing.

P-ENUM Tree

*.e164.heramax.com (base ENUM tree)
*.[mta2].[mta1].e164.heramax.com (screening ENUM tree)

NP ENUM Tree

*.e164.arpa (user ENUM tree)

7 Software Architecture

The software architecture of the Optranex 248 switch contains select components of the OpenSS7 STREAMS and Signaling Protocol Stacks. Also included are the Optranex Incorporated firmware and software drivers for the Optranex 248.

7.1 General Software Architecture

The software architecture of the Optranex 248 switch uses primarily the protocol and media processing componets of the OpenSS7 Project. Additional components include the sofia-SIP SIP stack and the OpenNMS net-snmp SNMP agent framework. The software architecture is decomposed into the following major components:

The Signaling Stack provides the ISUP/SIGTRAN signaling functions for use by the Optranex 248 switch (see Signaling Stack).
The Media Stack provides the SONET/SDH and RTP media handling functions as well as the integrated media gateway functions of the Optranex 248 switch (see Media Stack).
The Application Subsystem provides the sofia-SIP SIP stack and SIP-ISUP interworking functionality (see Application Subsystem).
The Management Subsystem provides the active net-snmp SNMP agents required to configure, measure, monitor, alarm and manage the signaling and media stacks in the Optranex 248 (see Management Subsystem).

7.1.1 Signaling Stack

An overview of the signaling stack is illustrated in Figure 12.

Figure 12. Signaling Stack

The signaling stack consists of the following primary subsystems:

An ISUP driver (see ISUP Driver).
The SIGTRAN stack providing SS7 connectivity for the ISUP driver (see SIGTRAN Stack).

7.1.1.1 ISUP Driver

As illustrated in Figure 12, the ISUP Driver consists of a monolithic pseudo-device multiplexing driver, /dev/isup, that implements the ISDN User Part of the SS7 stack in accordance with ITU-T Recommendation Q.764 and ANSI T1.113/2000 as well as several other variants. The driver is responsible for performing ISUP signaling for the Optranex 248 switch. The upper service interface is the Call Control Interface (CCI) developed by OpenSS7 and documented in the CCI specification. The lower service interface is the Message Transfer Part Interface (MTPI) which is capable of connecting both to OpenSS7’s traditional SS7 stack implementation of MTP as well as OpenSS7’s SIGTRAN M3UA stack, in a transparent fashion.

The ISUP Driver provides management streams for use by the active SNMP agent that is responsible for configuring, measuring, monitoring and maintaining ISUP signaling.

7.1.1.2 SIGTRAN Stack

As illustrated in Figure 12, the SIGTRAN Stack consists of a sequence of pseudo-device and multiplexing drivers that provide all of the SIGTRAN connectivity for the signaling stack.

M3UA Driver

The M3UA Driver is the OpenSS7 STREAMS implementation of the AS-side of the M3UA protocol as specified in RFC 4666. Two AS are implemented, one for communications with an SG in the SS7 network; another for A-side/B-side communications between ISUP drivers on the duplicated platforms. The driver provides a Message Transfer Part Interface (MTPI) at its upper service interface which is OpenSS7’s implementation of the Q.704/ANSI T1.111.4 service primitive interface. The driver provides a Network Provider Interface (NTPI) at its lower service interface for communications with the underlying SCTP Driver.

The driver provides management streams for use by the active SIGTRAN SNMP agent that is responsible for configuration, measurements, monitoring, auditing and controlling M3UA using the OpenSS7 enterprise MIB for M3UA.

SCTP Driver

The SCTP Driver is the OpenSS7 STREAMS implementation of SCTP. This is a high-performance concurrent multipath transfer driver that implements RFC 4960. The driver provides either a Network Provider Interface (NPI) or Transport Provider Interface (TPI) at its upper service interface.

Configuration and management of the driver is peformed by the active M3UA SNMP agent.

7.1.2 Media Stack

An overview of the media stack is illustrated in Figure 11.

Figure 11. Media Stack

The media stack consists of the following primary subsystems:

A Media Gateway Driver that is responsible for the overall media gateway functions (see Media Gateway Driver).
A TDM Stack consisting of a sequence of components that provide for the TDM portions of the media gateway functions (see TDM Stack).
A Ephemeral Stack consisting of a sequence of components that provide for the Ephemeral portions of the media gateway functions (see Ephemeral Stack).

These primary subsystems are described in the sections that follow. All subsystems, with the exception of the Optranex 248 SONET/SDH Driver are licensed under the GNU Affero General Public License and the GNU General Public License. The Optranex 248 SONET/SDH Driver is distributed under a proprietary license and is protected by pending patents.

7.1.2.1 Media Gateway Driver

As illustrated in Figure 11, the Media Gateway Driver, /dev/mg, is responsible for performing all MG functions and marshalling media samples between the TDM Stack and the Ephemeral Stack. Control of the media gateway is performed using the Media Gateway Interface (MGI).³⁶ The MGI performs a full set of MG functions using a STREAMS based service primitive interface. The MG functions provided are equivalent to those provided by ITU-T Recommendation H.248. In particular, the MGI is capable of the following:

— forming media connections between TDM and ephemeral media streams
— playing tones and announcements
— generating DTMF digits
— applying loopbacks for continuity testing
— continuity tone
— milliwatt
— silent termination
— balanced termination
— ringback patterns
— busy patterns (T60)
— reorder patterns (T120)
— receiver off hook patterns (ROH)
— bong tone

The Media Gateway Driver provides for control of the MG functions using the MGI. The driver also provides management streams for use by a user-space active SNMP agent that is capable of measuring, monitoring, auditing and maintaining the media gateway functions using OpenSS7 enterprise MIBs.

7.1.2.2 TDM Stack

As illustrated in Figure 11, the TDM Stack consists of a sequence of device and pseudo-device multiplexing drivers that provide all of the TDM connectivity for the media gateway.

Software Switching Matrix Multiplexing Driver

The Software Switching Matrix Multiplexing Driver, /dev/matrix, is responsible for performing channel switching between the TDM interface components and the Media Gateway Driver. The major purpose of this module is software TDM switching. Not all channels associated with the TDM interfaces are necessarily under the control of the media stack: some channels may be switched to other modules and drivers by the matrix driver. For example, if some channels are used for traditional SS7 connectivity, they would be mapped to a different stream on the upper service interface that would connect into the bottom of the OpenSS7 traditional SS7 stack.

SONET/SDH Multiplex Driver

The SONET/SDH Multiplex Driver, /dev/smux, is responsible for extracting TDM spans from one or more SONET/SDH synchronous payload envelopes. This is performed by extracting spans from VT1.5 or VT2 virtual tributaries within the SPE, or by extracting an demultiplexing DS3 or E2 payloads into their constituent T1 or E1 spans (i.e. 3:1 multiplexing). It is also responsible for monitoring segment, path and span carrier conditions. The upper service interface is a Multiplex Interface (MXI) referenced to G.704. The lower service interface is also a Multiplex Interface (MXI); however, the lower service interface is referenced to SONET/SDH (i.e. synchronous payload envelopes instead of T1 or E1 frames).

This driver also provides for management streams that are used to measure, monitor, audit and maintain the SONET/SDH segment and path, as well the constituent DS3, E2, T1 and E1 facilities. A user-space active SNMP agent is responsible for configuration and management using this stream.

SONET/SDH Driver

The SONET/SDH Driver, /dev/on248, is the device driver for the Optranex 248 SONET/SDH interface card. This driver is primarily responsible for marshalling SONET/SDH synchronous payload envelopes to and from the optics. Note that not all SPE are necessarily mapped into the /dev/smux driver: some SPE (possibly concatenated STS or VC) may be mapped to other upper service interfaces that are used for PPP over SONET or GFP for passing IP or Ethernet to or from the synchronous network.

This driver also provides for management streams that are used to measure, monitor, audit and maintain the SONET/SDH segment and path, as well as the performance of hardware devices (such as measurements and management of the optical interface modules, lasers and automatic protection switching).

7.1.2.3 Ephemeral Stack

As illustrated in Figure 11, the Ephemeral Stack consists of a sequence of pseudo-device drivers and multiplexing drivers that provide all of the ephemeral (RTP) connectivity for the media gateway.

RTP Driver

The RTP Driver is responsible for marshalling media samples to and from the /dev/mg driver using the Channel Interface (CHI) provided on the upper service interface. These samples are inserted into or extracted from RTP packets in accordance with the codecs specified to it by the /dev/mg driver. This driver also performs all necessary jitter buffering and monitors for loss of RTP connectivity.

The driver also provides for management streams that are used to measure, monitor, audit and maintain the RTP connections.

UDP Driver

The UDP Driver is responsible for passing RTP packets to and from the network. This component uses the OpenSS7 high performance UDP driver that interfaces directly with the Linux IP subsystem.

7.1.3 Application Subsystem

The relationship between the application and the signaling and media stacks is illustrated in Figure 14.

Figure 14. Application Subsystem

The Application Subsystem consists primarily of a Linux application process that utilizes the sofia-SIP framework for performing SIP signaling; the CCI interface provided by the OpenSS7 Signaling Stack for performing ISUP signaling; and the MGI interface provided by the OpenSS7 Media Stack for media gateway control.

The interworking between SIP and ISUP that is performed by the application subsystem consisting of the CCI interface to the ISUP stack, MGI interface to the media gateway functions, and interface for SIP signaling is detailed in SIP to ISUP Interworking.

Separate application programs and processes will be provided for circuit maintenance and test calls for ISUP. These applications will open streams on the ISUP driver that are dedicated to use for test and maintenance.

The test call program will permit test calls from the PSTN to terminate on the Optranex 248. The test call program receives all CCI interface connection indications (corresponding to IAM messages) that initiate test calls. The called party number will be examined to determine the test line function that is being invoked and utilize the MGI interface to peform the necessary actions to implement the test call.

The circuit maintenance program will peform continutity test functions that are a normal part of regular calls, as well as continuity test functions that are invoked by remote maintenance. The CCI interface is used for delivery of maintenance primitives and the MGI interface is used by the program to effect continuity test functions.

7.1.4 Management Subsystem

The relationship between management and the signaling and media stacks is illustrated in Figure 15.

Figure 15. Management Subsystem

The Management Subsystem consists of a number of active SNMP agents implemented using the net-snmp framework. The agents utilize management streams from the OpenSS7 Signaling Stack and Media Stack to perform their functions. The SNMP agents use the self-documenting OpenSS7 enterprise MIBs.

In addition, the STREAMS framework provides management streams and an active SNMP agent that provides for the management of the STREAMS framework itself using the OpenSS7 enterprise STREAMS MIB.

For more information on the management architecture, see Management Architecture.

7.2 SIP to ISUP Interworking

This section specifies the interworking of SIP to ISUP signaling. This interworking is internal to the Optranex 248. The overall SIP to ISUP interworking is illustrated in Figure 14.

The OpenSS7 ISUP stack and Call Control Interface (CCI) are used for interworking ISUP calls with SIP. The Optranex 248 uses the sofia-SIP stack, developed by Nokia, for processing of SIP signaling. The nta module is used for interworking concurrent SIP calls with ISUP calls. A purpose-developed interworking function exits at the control nexus between the sofia-SIP and OpenSS7 ISUP stacks.

OpenSS7 ISUP Stack

The OpenSS7 ISUP stack is illustrated in Figure 11 and interactions between the interworking function and the OpenSS7 ISUP stack are illustrated in Figure 14. The OpenSS7 ISUP stack is a STREAMS application and API developed by the OpenSS7 Project and released under the GNU Affero General Public License.

The OpenSS7 ISUP stack is a STREAMS application and API that consists primarily of a call control API user that passes primitives to the ISUP stack using formatted ‘C’ language structures which are written to a STREAMS file descriptor using putmsg(2s). Primitives are read from the ISUP stack by reading primitives formatted as ‘C’ language structures which are read from a STREAMS file descriptor using getmsg(2s). The first field of each primitive contains a primitive type which corresponds to a defined primitive for the interface. The remaining members of the ‘C’ language structure are specific to the primitive indicated in the first field. In this way, the interface and API consists of a fully asynchronous message passing mechanism, where the sequence of primitives issued to and received from the interface are constrained only by the interface definition. The interface definition used by the OpenSS7 ISDN, H.323, ISUP and BICC stack components is the Call Control Interface.

Nokia sofia-SIP Libraries

The sofia-SIP libraries are illustrated in Figure 14. The sofia-SIP libraries are a set of ‘C’ language libraries developed by Nokia and released under the GNU Lesser General Public License Version 2.1.³⁷

The Nokia sofia-SIP stack provides a module (subsystem) which is called the Nokia Transaction Agent or nta for short. The nta is a transaction engine, event loop and callback dispatch mechanism for building SIP applications. The libraries provide SIP and SDP message parsing and encoding, TCP and UDP socket event loops, the ability to hook additional file descriptors into the event loop, basic timers and SIP transaction state machine components.

SIP-ISUP Interworking Function

The SIP to ISUP interworking function is illustrated in Figure 14. The SIP to ISUP interworking function is written within the scope of a sofia-SIP nta application. The interworking function uses the event loop and dispatch mechanisms of the su module of the sofia-SIP libraries. As with any other event loop based library, some mechanism is provided to permit the callback of a function one typical select(2) or poll(2s) events.³⁸ Because the OpenSS7 ISUP stack is based on a STREAMS interface whose file descriptors support the entire range of functionality of poll(2s), including that of STREAMS, it is very easy to simply install the ISUP file descriptor with a pollfd structure using the su_root_register() function in sofia-SIP.

The interworking function will open three streams (file descriptors resulting from a open(2s) call on device /dev/streams/isup) for processing call control. One stream will be bound (with the CC_BIND_REQ primitive after opening) as a listening streams with the cc_setup_ind field of the CC_BIND_REQ set to a positive non-zero integer. A second stream will be bound with the cc_setup_ind field of the CC_BIND_REQ set to zero. A third stream will be bound with the cc_setup_ind field of the CC_BIND_REQ set to zero. All three streams will be bound to an ISUP address with signaling point scope, ISUP_SCOPE_SP using the signaling point code of the Optranex 248 switch. All incoming call indications will then be received on the first stream. All outgoing call requests will be sent on the second stream. All incoming call indication received on the first stream will be accepted on the third stream. The resulting three file descriptors will each be installed into the sofia-SIP event loop using the su_root_register() and su_root_eventmask() functions. Three separate callback functions will be associated with each stream.

The SIP-ISUP interworking function should have two major modes of operation: on conforming to RFC 3398 and another conforming to ITU-T Recommendation Q.1912.5. These operation modes differ primarily in the cause values and response codes returned under various circumstances. For the Dallas and Seattle trials, RFC 3398 is preferred initially.

7.2.1 Interworking Calls from SIP to PSTN

All calls from SIP to PSTN are initiated upon the receipt of an INVITE message at the sofia-SIP stack. The interworking function establishes an nta call leg to establish a transaction. CCI primitives sent to and received from the ISUP stack will be issued and received on the second ISUP stream described above. CCI primitives issued to the ISUP stack will be issued from the nta message callbacks. CCI primitives will be received on the installed callback for the second ISUP stream.

7.2.1.1 Mapping SIP INVITE to ISUP IAM

Upon receiving a INVITE message at the sofia-SIP stack beginning a transaction, the interworking function establishes a nta call leg and transaction, and prepares a CC_SETUP_REQ primitive. The interworking function assigns a cc_user_ref to identify the call with the ISUP stack. The cc_call_type will either be CC_CALL_TYPE_SPEECH or CC_CALL_TYPE_3_1kHZ_AUDIO. The cc_call_flags will contain a logical OR of the following flags:

ISUP_NCI_ONE_SATELLITE_CCT

ISUP_NCI_TWO_SATELLITE_CCT

The ISUP_NCI_ON_SATELLITE_CCT flag is set in accordance with Q.1912.5 indicating that there is one satellite in the circuit.

ISUP_NCI_CONT_CHECK_REQUIRED

This flag is set or not set depending upon the continuity check requirements of the interconnect. Typically, continuity checks (ISUP_NCI_CONT_CHECK_REQUIRED) are performed on one in ‘N’ calls, where ‘N’ is typically ‘10’.

Because the Dallas trial will not initially perform continuity checks on outgoing circuits (continuity checks will be performed, instead, as part of maintenance turn-up of each circuit), this flag will not initially be set. Later, a mechanism will be required for determining on which outgoing calls to set this flag. The determination may be based on an outgoing trunk group basis.

ISUP_NCI_CONT_CHECK_PREVIOUS

As the previous circuit is not an ISUP circuit (the call is from the SIP network), this flag will not be set.

ISUP_NCI_OG_ECHO_CONTROL_DEVICE

Initially this flag will not be set. When echo suppression is included in the implementation, this flag will be set to indicate that an outgoing echo control device is included in the circuit.

ISUP_FCI_INTERNATIONAL_CALL

For the trial, all calls will be national and this flage will not be set.

ISUP_FCI_PASS_ALONG_E2E_METHOD_AVAILABLE

ISUP_FCI_SCCP_E2E_METHOD_AVAILABLE

Neither of these flags will be set.

ISUP_FCI_INTERWORKING_ENCOUNTERED

This flag is set to indicate that interworking has been encountered on the call (the call is not SS7 end-to-end). In US domestic networks this normally means that an MF or analog trunk or non-SS7 trunk is in the call path.

ISUP_FCI_E2E_INFORMATION_AVAILABLE

This flag will not be set.

ISUP_FCI_ISDN_USER_PART_ALL_THE_WAY

This flag will not be set.

ISUP_FCI_ORIGINATING_ACCESS_ISDN

This flag will not be set.

ISUP_FCI_SCCP_CLNS_METHOD_AVAILABLE

ISUP_FCI_SCCP_CONS_METHOD_AVAILABLE

ISUP_FCI_SCCP_ALL_METHODS_AVAILABLE

None of these flags will be set.

ISUP_FCI_NUMBER_TRANSLATED

When the Request-URI contains a npdi parameter indicating that the called number has been dippled, this flag will be set.

ISUP_FCI_QUERY_ON_RELEASE

This flag is not set.

ISUP_CPC_SUBSCRIBER_ORDINARY

The default calling party’s category. When the cpc parameter is present in the P-Asserted-Identity of the INVITE, the value of the cpc parameter³⁹ will be used to generate the flags with the mapping as follows:

`unknown`	0	`ISUP_CPC_UNKNOWN`
`operator`	1	`ISUP_CPC_OPERATOR_FRENCH`	‘`fr`’
`operator`	2	`ISUP_CPC_OPERATOR_ENGLISH`	‘`en`’
`operator`	3	`ISUP_CPC_OPERATOR_GERMAN`	‘`de`’
`operator`	4	`ISUP_CPC_OPERATOR_RUSSIAN`	‘`ru`’
`operator`	5	`ISUP_CPC_OPERATOR_SPANISH`	‘`es`’
	6	`ISUP_CPC_OPERATOR_LANGUAGE_6`
	7	`ISUP_CPC_OPERATOR_LANGUAGE_7`
	8	`ISUP_CPC_OPERATOR_LANGUAGE_8`
	9	`ISUP_CPC_OPERATOR_CODE_9`
`ordinary`	10	`ISUP_CPC_SUBSCRIBER_ORDINARY`
	11	`ISUP_CPC_SUBSCRIBER_PRIORITY`
	12	`ISUP_CPC_VOICE_BAND_DATA`
`test`	13	`ISUP_CPC_TEST_CALL`
	14	`ISUP_CPC_SPARE`
`payphone`	15	`ISUP_CPC_PAYPHONE`
`mobile-hplmn`
`mobile_vplmn`

Note that the Language header will be used to identify the language of the operator.

Called Party Number

The subscriber-number portion of the tel URL or user-info portion of the sip URL, or the value of the rn parameter when present, will be converted to a called party number and included in the cc_cdpn_length and cc_cdpn_offset fields of the CC_SETUP_REQ. The octets of the called party number must conform to the format described in ANSI T1.113.3/3.6. That is: one bit indicating whether the number of address signals is odd (1) or even (0); 7 bits indicating that the number is a national (significant) number (0000011); 3 bits providing the numbering plan indicator is E.164 (001); an even or odd number of nibble-wide address signals; and, when the number of address signals is odd, a filler (0000).

Trunk Group

The cc_addr_length and cc_addr_offset will contain an isup_addr structure. The scope field will be set to ISUP_SCOPE_TG to indicate that a trunk group is selected; the id field will be set to the trunk group number; and the cic field will be set to zero (0) to indicate that a circuit is to be automatically selected wtihin the specified trunk group.

Optional Parameters

The cc_opt_length and cc_opt_offset fields in the CC_SETUP_REQ will contain optional parameters encoded according to ISUP formats and codes. This field contains a list of optional paramters consisting of a one-octet parameter tag, a one-octet parameter length, and then a sequence of octets indicated by the parameter length containing the value of the parameter. The list must be terminated with an end-of-optional-parameters parameter.

Optional parameters of a CCI primitive must be formatted precisely as they occur in the optional parameters list of an ISUP message. This optional parameter list consists of a sequence of parameters terminated by an end-of-optional-parameters parameter. Each parameter in the list consists of a single octet specifying the parameter type, followed by another single octet specifying the number of the octets contained in the parameter value, followed by the octet(s) of the parameter value. The end-of-optional-parameters parameter consists of one or two zero octets. When optional parameters are not specified, the optional parameters can be of zero length and no end-of-optional-parameters parameter need appear.

The following optional parameters are populated in the CC_SETUP_REQ primitive based on the information available in the Request-URI and various headers of the received INVITE.

Ported Number

If the rn parameter exists in Request-URI user-info tel URI portion, the telephone-subscriber part of the tel URI will be used to populate a Generic Address Parameter in the optional parameters. The Generic Address Parameter has a tag value of 192; one octet indicating "ported number" (11000000); one bit odd (1) or even (0) indicator; seven bits indicating national (significant) number (0000011); 3 bits indicating E.164 numbering (001); 2 bits indicating presentation restriction indicator (00); an even or odd number of nibble-wide address signals; and, when the number of address signals is odd, a filler (0000).

Carrier Identification

If the cic parameter exists in the Request-URI tel URI in accordance with RFC 4694, the value of this parameter will be use to populate a Carrier Identification parameter in the optional parameters. The Carrier Identification parameter has a tag value of 197; 3 bits indicating national network identification (010); 4 bits indicating either a 3-digit (0001) or 4-digit (0010) carrier identification; and 3 or 4 nibble-wide address signals; and, when 3 address signals is provided, a filler (0000).

Carrier Selection

If the dai parameter exists int he Request-URI tel URI in accordance with draft-yu-tel-dai-08, the value of this parameter will be used to populate a Carrier Selection parameter in the optional parameters. The Carrier Selection paramter has a tag value of 238; and 8 bits indicating the carrier selection. The mapping from values of the dai parameter int he Request-URI to Carrer Selection parameter values is as follows:

`no-ind`	00000000	no indication (default)
`presub`	00000001	selected carrier identification presubscribed and not input by calling party
`presub-da`	00000010	seelcted carrier identification presubscribed and input by calling party
`presub-da-unkwn`	00000011	selected carrier identification presubscribed, input by calling party undetermined
`da`	00000100	selected carrier identification not presubscribed and input by calling party
`presub-unkwn-da`	00000101	selected carrier identification presubscription unknown, input by calling party

Other values of the dai parameter described in draft-yu-tel-dai-08 are not permitted.

Dialed Number

If there is a recognized telephone-subscriber portion in the To header and it does not correspond to the Called Party Number or Ported Number, a "dialed number" Generic Address Parameter will be added to the optional parameters. The Generic Address Parameter has a tag value of 192; one octet indicating "dialed number" (00000000); one bit odd (1) or even (0) indicator; seven bits indicating national (significant) number (0000011); 3 bits indicating E.164 numbering (001); 2 bits indicating presentation restriction indicator - presentation allowed (00); an even or odd number of nibble-wide address signals; and, when the number of address signals is odd, a filler (0000).

Original Called Name

If there is a display-name portion in the To header and the ISUP CNAM method is marked on the trunk group, an "original called name" Generic Name parameter that is presentation-allowed will be added to the optional-parameters. The Generic Name parameter has a tag value of 199; two bits indicating presentation restriction set to presentation-allowed (00); one bit indicating availability as available (0); three bits indicating "original called name" (010); and up to 15 IA5 encoded characters.

Note that this parameter is not normally used in US networks, but is in Canadian and other networks.

Calling Party’s Category

If a cpc parameter exists in the P-Asserted-Identity header, the value of the calling party parameter in the cc_call_flags will be set as indicated previously.

Originating Line Information

If a oli parameter exists in the P-Charge-Info or P-Asserted-Identity header, an Originating Line Information parameter will be added to the optional parameters. The Originating Line Information parameter has a tag value of 234, and contains 8 bits having the value of the oli parameter. Only values in the range from 0x00 to 0x63 are valid (see ANSI T1.113.3/Annex C).

Jurisdiction Information

If a rn parameter exists in the P-Charge-Info or P-Asserted-Identity header, a Jurisdiction Information Parameter will be added to the optional parameters of the CC_SETUP_REQ. The Jurisdiction Information Parameter has a tag value of 196 and contains 6 nibble-wide address signals.

Charge Number

If a valid telephone-subscriber number is present in the P-Charge-Info header, and it is different from the Calling Party Number when the noa parameter is 1, 2, 3 or absent, or, it is different from the Called Party Number hwen the noa parameter is 5, 6, or 7, it will be used in the Charge Number parameter in the optional-parameters of the CC_SETUP_REQ. When an npi or noa parameter is also present in the P-Charge-Info header, the numbering plan indicator and nature of address in the Charge Number will be populated accordingly. This behaviour is consistent with that described in draft-york-sipping-p-charge-info-07. The Charge Number parameter has a tag value of 235 and contains an odd (1) or even (0) indicator bit; seven bits indicating the nature of address; 1 spare bit; 3 bits indicating the numbering plan as E.164 (001); 4 spare bits; an even or odd number of nibble-wide address signals; and, when the number of address signals is odd, a filler (0000). Only the following nature of address values will be accepted:

1	ANI of the calling party, subscriber number
2	ANI not available or not provided
3	ANI of the calling party, national number
5	ANI of the called party, subscriber number
6	ANI of the called party, no number present
7	ANI of the called party, national number

Calling Party Number

If a valid telephone-subscriber number is present in the P-Asserted-Identity header, it will be used in the Calling Party Number parameter in the optional-parameters of the CC_SETUP_REQ. If a Privacy header exists and is set to ‘id’ (or wider scope), the Calling Party Number will be marked presentation-restricted; otherwise, it will be marked presentation-allowed. The Calling Party Number parameter has a tag value of xxxx and contains a one bit odd (1) or even (0) indicator; seven bits of nature of address indicator coded national (significant) number (0000011); 3 bit numbering plan indicating E.164 (001); two bit address presentation restriction indicator indicating presentation-allowed (00) or presentation-restricted (01); a two bit screening indicator indicating network-provided (11); an even or odd number of nibble-wide address signals; and, when the number of address signals is odd, a filler (0000).

Calling Name

If a display-name exists in the P-Asserted-Identity header and the trunk is configured for ISUP CNAM method, the display-name will be placed in a calling name Generic Name parameter in the optional-parameters of the CC_SETUP_CREQ. If a Privacy header exists and is set to ‘user’ (or wider scope), the Generic Name will be marked presentation-restricted; otherwise, it will be marked presentation-allowed. The Generic Name parameter has a tag value of 199; two bits indicating presentation restriction set to presentation-allowed (00) or presentation-restricted (01); one bit indicating availability as available (0); three bits indicating "calling name" (001); and up to 15 IA5 encoded characters.

If there is a display-name portion in the From header, and the outgoing trunk is marked for ISUP CNAM, a "calling name" Generic Name parmaeter will be placed in the optional-parameters of the CC_SETUP_REQ and marked presentation-allowed (if one is not already present). The Generic Name parameter has a tag value of 199; two bits indicating presentation restriction set to presentation-allowed (00); one bit indicating availability as available (0); three bits indicating "calling name" (001); and up to 15 IA5 encoded characters.

Note that this parameter is not normally used in US networks, but is in Canadian and other networks.

Additional User Provided Number

If there is a recognized telephone-subscriber portion in the From header, and it is different from that of the P-Asserted-Identity header, an "additional user provided number - not verified" Generic Address Parameter will be added to the optional-parameters of the CC_SETUP_REQ with presentation-allowed. The Generic Address Parameter has a tag value of 192; one octet indicating "additional user provided number - not verified" (00000011); one bit odd (1) or even (0) indicator; seven bits indicating national (significant) number (0000011); 3 bits indicating E.164 numbering (001); 2 bits indicating presentation restriction indicator - presentation allowed (00); an even or odd number of nibble-wide address signals; and, when the number of address signals is odd, a filler (0000).

End of Optional Parameters

When optional parameters are present in the CC_SETUP_REQ, the end of optional parameters parameter (with tag value zero (0)) will be appended to the optional-parameters.

Response

After issuing the CC_SETUP_REQ primitive on the ISUP stream, the interworking function must await a CC_OK_ACK or CC_ERROR_ACK primitive before issuing any other primitives on the stream. When a CC_OK_ACK primitive is received, the callback function can return. When a CC_ERROR_ACK primitive is received, the interworking function should take the following actions based on the cc_error_type field in the primitive:

CCSYSERR: A system error occured. The cc_unix_error field will contain either [EFAULT] or [EMSGSIZE], indicating that the primitive was poorly formatted (too short or an offset or length field of the primited referred to a memory extent outside the range of the primitive). The interworking function should log the error and respond with a 500 Server Internal Error response to the INVITE and ultimately remove the session and transaction information.
CCOUTSTATE: The CCI stream upon which the primitive was issued was not in a correct state to accept the primitimve (e.g. the stream is not bound). The interworking function should log the error and respond with a 500 Server Internal Error response to the INVITE and ultimately remove the session and transaction information.
CCNOADDR: No appropriate address was provided in the cc_addr_offset and cc_addr_length fields. The interworking function should log the error and respond with a 500 Server Internal Error response to the INVITE and ultimately remove the session and transaction information.
CCBADADDR: The address provided in the cc_addr_offset and cc_addr_length fields was incorrectly formatted or contained illegal information. Barring a bug, this error will normally be returned when the trunk group number specified in the address is incorrect. The interworking function should log the error and respond with a 502 Bad Gateway response to the INVITE and ultimately remove the session and transaction information.
CCBADDIGS: The digits provided in the cc_cdpn_offset and cc_cdpn_length field was poorly formatted or contained illegal values. The interworking function should log the error and respond with a 500 Server Internal Error response to the INVITE and ultimately remove the session and transaction information.
CCBADOPT: The optional parameters provided in the cc_opt_offset and cc_opt_length fields was poorly formatted or contained illegal values. The interworking function should log the error and respond with a 500 Server Internal Error response to the INVITE and ultimately remove the session and transaction information.
CCBADCLR: The user reference contained in the cc_user_ref field is already engaged in a call. The interworking function should log the error and respond with a 500 Server Internal Error response to the INVITE and ultimately remove the session and transaction information.

7.2.1.2 Successful Setup of Calls from SIP to PSTN

Successful setup of calls from SIP to PSTN will always begin with the receipt (by the callback function associated with the second ISUP stream) of a CC_SETUP_CON primitive.

Processing of CC_SETUP_CON

When the interworking function receives a CC_SETUP_CON primitive, it will use the cc_user_ref field of the primitive to locate the call context (session). The interworking function will assign the ISUP provider chosen cc_call_ref field from the primitive and make the call context (session) accessible for lookup using this call reference. The ISUP callback function can then return.

Processing of CC_PROCEEDING_IND

When the interworking function receives a CC_PROCEEDING_IND primitive, it will use the cc_call_ref field of the primitive to locate the call context (session). The CC_PROCEEDING_IND primitive received by the interworking function will be mapped into a 183 Session Progress response message for the transaction corresponding to the received INVITE. The CC_PROCEEDING_IND message results from the receipt of the first backward message, an ACM from ISUP, without an indication in the ACM that the subscriber is free.

The cc_flags field of the CC_PROCEEDING_IND primitives contains one or more of the following flags:

ISUP_BCI_NO_CHARGE
ISUP_BCI_CHARGE: These flags are ignored.
ISUP_BCI_ORDINARY_SUBSCRIBER
ISUP_BCI_PAYPHONE: These flags are ignored.
ISUP_BCI_PASS_ALONG_E2E_METHOD_AVAILABLE
ISUP_BCI_SCCP_E2E_METHOD_AVAILABLE: These flags are ignored.
ISUP_BCI_INTERWORKING_ENCOUNTERED: This flag indicates that interworking was encounted between the Optranex 248 switch and the destination switch. That is, some leg of the call between the Optranex 248 and the destination switch does not use SS7 signaling. The SIP-ISUP interworking function must cut the call through in both directions to the calling party.
ISUP_BCI_E2E_INFORMATION_AVAILABLE: This flag is ignored and should not normally be set.
ISUP_BCI_ISDN_USER_PART_ALL_THE_WAY
ISUP_BCI_HOLDING_REQUESTED: This flag is ignored and should not normally be set in US networks.
ISUP_BCI_TERMINATING_ACCESS_ISDN: This flag is ignored.
ISUP_BCI_IC_ECHO_CONTROL_DEVICE
ISUP_BCI_SCCP_CLNS_METHOD_AVAILABLE
ISUP_BCI_SCCP_CONS_METHOD_AVAILABLE
ISUP_BCI_SCCP_ALL_METHODS_AVAILABLE: These flags are ignored.
ISUP_OBCI_INBAND_INFORMATION_AVAILABLE
ISUP_OBCI_CALL_DIVERSION_MAY_OCCUR
ISUP_OBCI_ADDITIONAL_INFO_IN_SEG
ISUP_OBCI_MLPP_USER

The ISUP callback function can then return.

Processing of CC_ALERTING_IND

When the interworking function receives a CC_ALERTING_IND primitive, it will use the cc_call_ref field of the primitive to locate the call context (session). The CC_ALERTING_IND primitive received by the interworking function will be mapped into a 180 Ringing reponse message. The CC_ALERTING_IND message results from the receipt of the first backward message, an ACM from ISUP, with an indication in the ACM that the subscriber is free.

Processing of CC_PROGRESS_IND

When the interworking function receives a CC_PROGRESS_IND primtive, it will use the cc_call_ref field of the primitive to locate the call context (session). The CC_PROGRESS_IND primitive received by the interworking function will be mapped into an appropriate 1xx response message according to the cc_event field of the primitive as follows:

ISUP_EVNT_ALERTING: Indicates that the called party is being alerted. This event is indicated only if a CC_PROCEEDING_IND primitive has already been received. This event is mapped into a 180 Ringing response to the INVITE in accordance with RFC 3398/7.2.9.
ISUP_EVNT_PROGRESS: Indicates that the call is progressing with the specified optional parameters. This event is mapped into a 183 Session Progress response to the INVITE in accordance with RFC 3398/7.2.9.
ISUP_EVNT_IBI: This event is indicated only by the CC_IBI_IND primitive and will not appear here. If this event appears it must be treated as a CC_IBI_IND primitive (see below).
ISUP_EVNT_CALL_FORWARDED_ON_BUSY: This event indicates that the call has been forwarded on busy and the optional parameters (if any) contain the attributes of the forwarding (e.g., redirecting number, etc.). This event is mapped into a 181 Call is being forwarded response to the INVITE in accordance with RFC 3398/7.2.9.
ISUP_EVNT_CALL_FORWARDED_ON_NO_ANSWER: This event indicates that the call has been forwarded on no answer and the optional parameters (if any) contain the attributes of the forwarding (e.g., redirecting number, etc.). This event is mapped into a 181 Call is being forwarded response to the INVITE in accordance with RFC 3398/7.2.9.
ISUP_EVNT_CALL_FORWARDED_UNCONDITIONAL: This event indicates that the call has been forwarded undconditionally and the optional parameters (if any) contain the attributes of the forwarding (e.g., redirecting number, etc.). This event is mapped into a 181 Call is being forwarded response to the INVITE in accordance with RFC 3398/7.2.9.

When the cc_flags field contains the flag ISUP_EVNT_PRESENTATION_RESTRICTED, for all events other than ISUP_EVNT_ALERTING, the event will not be mapped to SIP.

Processing of CC_IBI_IND

When the interworking function receives a CC_IBI_IND primtive, it will use the cc_call_ref field of the primitive to locate the call context (session). The CC_IBI_IND primitive received by the interworking function will be mapped into a 183 Session Progress response message and will connect early media in the direction from the PSTN to the SIP UAC. If the SIP UAC supports the UPDATE method, early media is established toward the SIP UAC using that method.

Processing of CC_CONNECT_IND

When the interworking function receives a CC_CONNECT_IND primitive, it will use the cc_call_ref field of the primitive to locate the call context (session). The CC_CONNECT_IND primitive received by the interworking function will be mapped into a 200 OK response message and will connect media in both directions. If the SIP UAC supports the UPDATE method and early media was established toward the UAC using that method, cutting through media in both directions may required an additional UPDATE message.

7.2.1.3 Unsuccessful Setup of Calls from SIP to PSTN

Call Abandonment

After issuing a CC_SETUP_REQ primitive for the call, and before receiving a CC_CONNECT_IND for the call, the interworking function may receive a CANCEL message for the session. The CANCEL message indicates that the caller has abandonned the call. The CANCEL received at the sofia-SIP callback is associated with client information that identifies the call context (session). After looking up the session, the interworking function issues a CC_RELEASE_REQ for the call. The cc_user_ref field is populated with the user reference for the call when a CC_SETUP_CON has not yet been received for the call; otherwise, the cc_call_ref field contains the call reference for the call returned in the corresponding CC_SETUP_CON. The cc_cause value should be set to CC_CAUS_NORMAL_CALL_CLEARING.

Automatic Repeat Attempt

After issuing a CC_SETUP_REQ primitive for the call, and before receiving a CC_SETUP_CON for the call, the interworking function may receive a CC_CALL_REATTEMPT_IND primitive. The CC_CALL_REATTEMPT_IND primitive indicates that a call repeat attempt should made by the interworking function and the reason for the reattempt.

The CC_CALL_REATTEMPT_IND primitive contains the cc_user_ref value that is the same as the interworking function provided on the corresponding CC_SETUP_REQ primitive that initiated the call. The interworking function looks up the call context (session) associated with the corresponding INVITE and CC_SETUP_REQ using this cc_user_ref value.

After receiving the CC_CALL_REATTEMPT_IND primitive and lookup up the call context (session) using the cc_user_ref field in the primitive, the interworking function examines a field in the call context to determine whether an automatic reattempt has already been performed. If no reattempt has been performed, the interworking function marks a reattempt⁴⁰ and issues another (can be identical) CC_SETUP_REQ primitive to the ISUP stack.⁴¹

If a reattempt has already been performed, the interworking function examines the cc_reason field of the primitive and provides a response on the sofia-SIP transaction referenced from the call context as follows:⁴²

ISUP_REATTEMPT_DUAL_SEIZURE

The Optranex 248 is not the controlling exchange for a two-way trunk group and a dual siezure was detected on the two-way trunk group. After the first reattempt, the interworking function should return a 503 Service Unavailable response message to the INVITE, resulting in the ultimate release of the transaction and the corresponding call context (session). A Reason header with value ‘Q.850;cause=41;text="temporary failure"’ may be added to the response.

The Optranex 248 will typically be set up (and will so for trial) with outgoing routes to the PSTN that consist of a one-way outgoing trunk group overflowing to a two-way trunk group. The tgrp parameter in the tel URI of the Request-URI field of the INVITE specifies a route (a set of overflow trunk groups) rather than a trunk group. When initiating a CC_SETUP_REQ primitive, the interworking function should first specify the trunk group associated with the primary (one-way outgoing) trunk. This trunk group number will be an even number. If a CC_CALL_REATTEMPT_IND primitive results with a cc_reason of CC_REATTEMPT_CIRCUIT_BUSY, the interworking function may reattempt on the overflow (two-way) trunk. This trunk (if it exists) will have a trunk group number that is one greater than the trunk group number of the one-way outgoing group and will therefore be an odd number. Should a CC_CALL_REATTEMPT_IND result with a cc_reason value of ISUP_REATTEMPT_DUAL_SIEZURE, the interworking function might reattempt on the one-way outgoing trunk group. Dual reattempts on the same trunk group should result in release of the call.

ISUP_REATTEMPT_RESET

The Optranex 248 attempted a call on a circuit which was subsequently reset (either locally or remotely) before the receipt of any backward message for the call. After the first reattempt, the interworking function should return a 503 Service Unavailable response message⁴³ to the INVITE, resulting in the ultimate release of the transaction and the corresponding call context (session). A Reason header with value ‘Q.850;cause=41;text="temporary failure"’ may be added to the response.

ISUP_REATTEMPT_BLOCKING

The Optranex 248 attempted a call on a circuit which was subsequently blocked (either locally ore remotely) before any backward message was received. After the first reattempt, the interworking function should return a 503 Service Unavailable response message⁴⁴ to the INVITE, resulting in the ultimate release of the transaction and the corresponding call context (session). A Reason header with value ‘Q.850;cause=41;text="temporary failure"’ may be added to the response.

ISUP_REATTEMPT_T24_TIMEOUT

The Optranex 248 attempted a call for which continuity testing was required; however, tone was not detected within time T24. After the first reattempt, the interworking function should return a 503 Service Unavailable response message⁴⁵ to the INVITE, resulting in the ultimate release of the transaction and the corresponding call context (session). A Reason header with value ‘Q.850;cause=41;text="temporary failure"’ may be added to the response.

ISUP_REATTEMPT_UNEXPECTED

The Optranex 248 attempted a call for which an unexpected message was received before any backward message. After the first reattempt, the interworking function should return a 503 Service Unavailable response message⁴⁶ to the INVITE, resulting in the ultimate release of the transaction and the corresponding call context (session). A Reason header with value ‘Q.850;cause=41;text="temporary failure"’ may be added to the response.

ISUP_REATTEMPT_COT_FAILURE

The Optranext 248 attempted a call which required continuity testing and the result of the continuity test indicated failure. After the first reattempt, the interworking function should 503 Service Unavailable response message⁴⁷ to the INVITE, resulting in the ultimate release of the transaction and the corresponding call context (session). A Reason header with value ‘Q.850;cause=41;text="temporary failure"’ may be added to the response.

ISUP_REATTEMPT_CIRCUIT_BUSY

This reason is only issued by the CCS provider when the scope was ISUP_SCOPE_CIC or a specific circuit was specified on the CC_SETUP_REQ. After the first reattempt, the interworking function should return a 503 Service Unavailable response message⁴⁸ to the INVITE, resulting in the ultimate release of the transaction and the corresponding call context (session). A Reason header with value ‘Q.850;cause=34;text="no circuit/channel available"’ may be added to the response.

It is the responsibility of the interworking function to reissue the CC_SETUP_REQ. Upon the second reattempt for the same call on the same trunk-group, the interworking function should abandon the call and return an error response 503 Service Unavailable to the INVITE. A Reason header with value ‘Q.850;cause=41;text="temporary failure"’ or ‘Q.850;cause=34;text="no circuit/channel available"’ may be added to the response (depending on the value of the cc_reason field).

Premature Call Failure

If, after issuing a CC_SETUP_REQ primitive for the call, and before receiving a CC_SETUP_CON for the call, the interworking function receives a CC_CALL_FAILURE_IND primitive, the interworking function will examine the cc_reason field of the primitive and responds as follows:

ISUP_CALL_FAILURE_CIRCUIT_BUSY
CC_CAUS_NO_CCT_AVAILABLE: This failure cause indicates that the selected trunk group is all-circuits-busy. This applies to outgoing calls only. This reason is only issued by the CCS provider when the scope was ISUP_SCOPE_TG and no specific circuit was specified on the CC_SETUP_REQ. After the first reattempt, the interworking function should return a 503 Service Unavailable response message⁴⁹ to the INVITE, resulting in the ultimate release of the transaction and the corresponding call context (session). A Reason header with value ‘Q.850;cause=34;text="no circuit/channel available"’ may be added to the response.
ISUP_CALL_FAILURE_T7_TIMEOUT
CC_CAUS_ADDRESS_INCOMPLETE: This failure cause indicates that there was no response to the call setup request. This applies to outgoing calls only. The interworking function should return a 484 Address Incomplete response message to the INVITE. The Reason header may include ‘Q.850;cause=28;text="invalid number format (address incomplete)"’.

Call Rejection

Whereas automatic repeat and premature call failure result from the local detection of call failure, call rejection results from the release of the call by a transit switch or the controlling switch. Call rejection occurs after issuing a CC_SETUP_REQ primitive but before receiving a CC_SETUP_CON primitive.

When the interworking function receives a CC_RELEASE_IND primitive, it uses the cc_user_ref field in the primitive to look up the call context (session). The interworking function examines the cc_cause field value in the CC_RELEASE_IND primitive, issues a CC_RELEASE_RES primitive (if a CC_RELEASE_REQ primitive has not already been issued for the call), awaits a CC_OK_ACK primitive and responds on the SIP side as follows:

Table T-25. Q.850 Cause Value to SIP Response Mapping - Normal Class

Table T-26. Q.850 Cause Value to SIP Response Mapping - Resource Unavailable Class

Note that in Table T-26, for CC_CAUS_NO_CCT_AVAILABLE, ITU-T Q.1912.5 specifies that if call completion to busy subscriber is indicated in the backward call indicators, that the response should be 486 Busy Here instead of 480 Temporarily Unavailable.

Table T-27. Q.850 Cause Value to SIP Response Mapping - Service or Option Not Available Class

Table T-28. ANSI Cause Value to SIP Response Mapping - Normal Class

Table T-29. ANSI Cause Value to SIP Response Mapping - Resource Unavailable Class

Table T-30. ANSI Cause Value to SIP Response Mapping - Service or Option Not Available Class

Call Failure

If after issuing a CC_SETUP_REQ primitive and receiving a CC_SETUP_CON primitive for the call, the interworking function receives a CC_CALL_FAILURE_IND primitive, the interworking function will examine the cc_reason or cc_cause field of the primitive and respond as follows:

ISUP_CALL_FAILURE_RESET
CC_CAUS_NORMAL_UNSPECIFIED: This failure cause indicates that a circuit reset was received for the call during call setup or establishment. This applies to outgoing calls only. The interworking function should return a 480 Temporarily Unavailable response message to the INVITE. The Reason header may include ‘Q.850;cause=31;text="normal unspecified"’.
ISUP_CALL_FAILURE_T3_TIMEOUT
ISUP_CALL_FAILURE_OVERLOAD
CC_CAUS_SWITCHING_EQUIP_CONGESTION: This failure cause indicates that the non-controlling exchange received an overload message or automatic congestion control signal that is applied to this call. This applies to outgoing calls only. The interworking function should return a 500 Server Internal Error of 503 Service Unavailable response message to the INVITE. The Reason header may include ‘Q.850;cause=42;text="switching equipment congestion"’.
ISUP_CALL_FAILURE_T9_TIMEOUT
CC_CAUS_NO_ANSWER: This failure cause indicates that the call failed while waiting for the distant end to answer. This applies to outgoing calls only.

7.2.2 Interworking Calls from PSTN to SIP

All calls from the PSTN to SIP are initiated upon the receipt of an IAM message the ISUP stack. The interworking function establishes a transaction and a call context. CCI primitives sent to and received from the ISUP stack will be initially received on the first ISUP stream, accepted on for the third ISUP stream, and issued and received subsequently on the third ISUP. CCI primitives issued to the ISUP stack will be issued from within the nta message callbacks. CCI primitives will be received on the installed callbacks for the first and third ISUP streams.

7.2.2.1 Mapping of ISUP IAM to SIP INVITE

Processing of CC_SETUP_IND

Upon receiving an IAM message (CC_SETUP_IND primitive) at the ISUP stack beginning a call, the interworking function establishes an nta transaction and prepares an INVITE message. The interworking function establishes a call context (session) and assigns the cc_call_ref supplied in the CC_SETUP_IND primitive corresponding to the IAM message to identify the call with the ISUP stack.

The interworking function examines the cc_call_type field of the CC_SETUP_IND primitive. The accepted call types are as follows:

CC_CALL_TYPE_SPEECH: This call type represents a speech call.
CC_CALL_TYPE_3_1kHZ_AUDIO: This call type represents a 3.1 kHz audio call.
CC_CALL_TYPE_UDI_TA: This call type represents an unrestricted digital information with tones and announcements call.

For all other call types, the interworking function rejects the call with a CC_REJECT_REQ primitive with the cause value (cc_cause) of CC_CAUS_BC_NOT_IMPLEMENTED.

The interworking function then examines the cc_call_flags field of the CC_SETUP_IND primitive. The flags are interpreted as follows:

ISUP_NCI_ONE_SATELLITE_CCT
ISUP_NCI_TWO_SATELLITE_CCT: These flags are ignored.
ISUP_NCI_CONT_CHECK_REQUIRED
ISUP_NCI_CONT_CHECK_PREVIOUS: These flags can be ignored by call control and are, instead, processed by a separate maintenance application.
ISUP_NCI_OG_ECHO_CONTROL_DEVICE: This flag affects the application of echo control on the media circuit. When this flag is set, echo control on the media circuit is not necessary. This flag is seldom set in US domestic networks.
ISUP_FCI_INTERNATIONAL_CALL: This flag is ignored for incoming calls and should not typically be set on egress calls.
ISUP_FCI_PASS_ALONG_E2E_METHOD_AVAILABLE
ISUP_FCI_SCCP_E2E_METHOD_AVAILABLE: These flags can be ignored.
ISUP_FCI_INTERWORKING_ENCOUNTERED: This flag indicates that interworking was encountered in the course of routing the call to this office. In US domestic networks this normally means that an MF or analog trunk is in the call path and that rather than releasing calls with cause, the playing of in-band tones and announcements will be required in some circumstances. The fact that interworking has been encountered should be saved in the call context (session) data associated with the call as it will affect behaviour later in the call.
ISUP_FCI_E2E_INFORMATION_AVAILABLE: This flag is ignored.
ISUP_FCI_ISDN_USER_PART_ALL_THE_WAY: This flag is ignored.
ISUP_FCI_ISDN_USER_PART_NOT_REQUIRED: This flag is ignored.
ISUP_FCI_ISDN_USER_PART_REQUIRED: If this flag is set, the call is rejected using a CC_REJECT_REQ primitive. The cc_cause field should be set to CC_CAUS_FACILITY_REJECTED.
ISUP_FCI_ORIGINATING_ACCESS_ISDN: This flag is ignored.
ISUP_FCI_SCCP_CLNS_METHOD_AVAILABLE
ISUP_FCI_SCCP_CONS_METHOD_AVAILABLE: These flags are ignored.
ISUP_FCI_NUMBER_TRANSLATED: When this flag is present, the npdi parameter will be added to the telephone-subscriber portion of the tel URI contained in the Request-URI of the resulting INVITE message.

Calling Party’s Category

The calling party’s cateogry is contained in the cc_flags field. The field is first masked (logical AND) with the ISUP_CPC_MASK value and then compared to the following values:

ISUP_CPC_UNKNOWN: The cpc parameter in the tel URI portion of the P-Asserted-Identity header is set to unknown, or the cpc parameter is ommitted from the tel URI.
ISUP_CPC_OPERATOR_FRENCH: The cpc parameter in the tel URI portion of the P-Asserted-Identity header is set to operator and the Language header is set to fr.
ISUP_CPC_OPERATOR_ENGLISH: The cpc parameter in the tel URI portion of the P-Asserted-Identity header is set to operator and the Language header is set to en.
ISUP_CPC_OPERATOR_GERMAN: The cpc parameter in the tel URI portion of the P-Asserted-Identity header is set to operator and the Language header is set to de.
ISUP_CPC_OPERATOR_RUSSIAN: The cpc parameter in the tel URI portion of the P-Asserted-Identity header is set to operator and the Language header is set to ru.
ISUP_CPC_OPERATOR_SPANISH: The cpc parameter in the tel URI portion of the P-Asserted-Identity header is set to operator and the Language header is set to es.
ISUP_CPC_OPERATOR_LANGUAGE_6: The cpc parameter in the tel URI portion of the P-Asserted-Identity header is set to 6.
ISUP_CPC_OPERATOR_LANGUAGE_7: The cpc parameter in the tel URI portion of the P-Asserted-Identity header is set to 7.
ISUP_CPC_OPERATOR_LANGUAGE_8: The cpc parameter in the tel URI portion of the P-Asserted-Identity header is set to 8.
ISUP_CPC_OPERATOR_CODE_9: The cpc parameter in the tel URI portion of the P-Asserted-Identity header is set to 9.
ISUP_CPC_SUBSCRIBER_ORDINARY: The cpc parameter in the tel URI portion of the P-Asserted-Identity header is set to ordinary.
ISUP_CPC_SUBSCRIBER_PRIORITY: The cpc parameter in the tel URI portion of the P-Asserted-Identity header is set to 11.
ISUP_CPC_VOICE_BAND_DATA: The cpc parameter in the tel URI portion of the P-Asserted-Identity header is set to 12.
ISUP_CPC_TEST_CALL: The cpc parameter in the tel URI portion of the P-Asserted-Identity header is set to test.
ISUP_CPC_SPARE: The cpc parameter in the tel URI portion of the P-Asserted-Identity header is set to 14.
ISUP_CPC_PAYPHONE: The cpc parameter in the tel URI portion of the P-Asserted-Identity header is set to payphone.

Called Party Number

The cc_cdpn_offset and cc_cdpn_length fields of the CC_SETUP_IND indicate the called party number. This number is extracted from the field and used in the telephone-subscriber portion of the tel URI in both the To header and Request-URI of the INVITE message.

The called party number field is encoded in the format described in ANSI T1.113.3/3.6; that is: one bit indicating whether the number of address signals is odd (1) or even (0); 7 bits indicating that the nature of address; 3 bits providing the numbering plan indicator; an even or odd number of nibble-wide address signals; and, when the number of address signals is odd, a filler (0000). The numbering plan indicator should typically be E.164 (001). The nature of address should typically be national (significant) number (0000011) or international number. When the number is national, a ‘+1’ should be prefixed to the number for the trial. When the number is international, a ‘+’ is prefixed to the number for the trial before placing the number into the telephone-subscriber portion of the tel URI.

Trunk Group

The cc_addr_length and cc_addr_offset will contain an isup_addr structure. The scope field will be set to ISUP_SCOPE_TG to indicate that a trunk group was selected; the id field will be set to the trunk group number; and the cic field will be set to the circuit identification code of the incoming circuit. The tgrp parameter in the tel URI portion of the P-Asserted-Identity header is set to the numeric value of the trunk group number. The circuit identification code is used in conjunction with the signaling point code to which the stream was bound to identify the circuit for media connections.

Optional Parameters

The cc_opt_length and cc_opt_offset fields of the CC_SETUP_IND will contain optional parameters encoded according to ISUP formats and codes. This field contains a list of optional parameters consisting of a one-octet parameter tag, a one-octet parameter length, and then a sequence of octets indicated by the parameter length containing the value of the parameter. The list is terminated with an end-of-optional-parameters parameter. If the field does not follow this format, the setup should be rejected with a CC_REJECT_REQ primitive with a cc_cause value of CC_CAUS_INVALID_MESSAGE.

Optional parameters of the CCI primitive are formatted precisely as they occurred in the optional parameters list of the corresponding ISUP message. This optional parameter list consists of a sequence of parameters terminated by an end-of-optional-parameters parameter. Each parameter in the list contsists of a single octet specifying the parameter type, followed by another single octet specifying the number of octets contained in the parameter value, followed by the octet(s) of the parameter value. The end-of-optional-parameters parameter consists oof one or two octets. When optional parameters are not specified, the optional parameters can be of zero length and no end-of-optional-parameters parameter need appear.

The following optional parameters may be populated in the CC_SETUP_IND primitive that need to be mapped into the information placed into the Request-URI and various headers of the INVITE being prepared.

Ported Number

If a Generic Address Parameter exists in the optional parameters with indication "ported number", then this number will be used as the telephone-subscriber portion of the tel URI in the To header and Request-URI. When the parameter is presentation-restricted, it will only be added to the Request-URI. The called party number which was overwritten will be added, instead, to an rn parameter of the tel URI in the Request-URI only.

Dialed Number

If a Generic Address Parameter is present in the optional parameters with indication "dialed number" and is makred presentation allowed, the number will be used as the telephone-subscriber portion of the tel URI contained in the To header.

Original Called Name

If a Generic Name parameter exists in the optional parameters list with indicating "original called name", and the name is set to presentation-allowed, the name will be used as the display-name portion of the To header.

Originating Line Information

If an Originating Line Information parameter is present in the optional parameters, the value of the parameter will be added to an oli parameter of the telephone-subscriber portion of the tel URI contained in the P-Asserted-Identity header as well as the P-Charge-Info header (if present for other reasons).

Jurisdiction Information

If a Jurisdiction Information parameter is present in the optional parameters, the digits from the parameter will be added to an rn parameter of the telephone-subscriber portion of the tel URI contained in the P-Asserted-Identity header as well as the P-Charge-Info header (if present for other reasons).

Charge Number

If a Charge Number parmaeter is present in the optional parameters a P-Charge-Info header will be added to the INVITE message in accordance with draft-york-sipping-p-charge-info-07. The noa value and telephone-subscriber number portions of the header will be taken directly from the parameter.

Calling Party Number

If a Calling Party Number parameter is present in the optional parameters list and it is not "network provided" (11), the parameter will be ignored. When network provided, the calling party number will be used in the telephone-subscriber portion of the tel URI contained in both the From and P-Asserted-Idenity headers of the resulting INVITE. When marked presentation-restricted, the number will only be placed in the P-Asserted-Identity header and the Privacy header will be elevated to id privacy.

Calling Name

If a Generic Name parameter exists with the indication "calling name" (001) and it is marked presentation-allowed, the name will be placed in the display-name portion of the URI in both the From and P-Asserted-Identity headers. When the name is presentation-restricted, it will only be placed in the P-Asserted-Identity header and the Private header will be elevated to user privacy.

Additional User Provided Number

If a Generic Address Parameter exists with the indication "additional user provided number - not verified" (00000011) in the first octet of the parameter value, the remaining octets in the parameter provide the party number with one bit odd (1) or even (0) indicator; seven bits indicating national (significant) number (0000011) or international number; 3 bits indicating E.164 numbering (001); 2 bits indicating presentation restriction - presentation allowed (00); an even or odd number of nibble-wide address signal; and, when the number of address signals is odd, a filler (0000). When this parameter is present and is presentation allowed, it is used as the telephone-subscriber portion of the tel URI used in the From header of the INVITE message, instead of that contained in the calling party number.

End of Optional Parameters

When optional parameters are present in the CC_SETUP_IND, the end of optional parameters parameter (with tag value zero (0)) will be appended to the optional parameters.

Response

The interworking function will issue a CC_SETUP_RES indicating the ISUP stream upon which the remaining primitives are to be exchanged (the third stream described above) on the listening stream (the first stream described) and will await receive of either a CC_OK_ACK or CC_ERROR_ACK primitive (priority message) on the listening stream before continuing. When a CC_ERROR_ACK is received, the call context should be dropped and the call abandonned. When a CC_OK_ACK is received, the interworking function can issue the prepared INVITE message and either return from the callback or process more received messages on the listening stream.

Note that ISUP should treat these trunks terminating on SIP as interworking trunks. When the CC_SETUP_IND is issued and the CC_SETUP_RES processed successfully, the T11 timer should be started and an ACM message generated automatically if the timer expires.

7.2.2.2 Successful Calls from PSTN to SIP

Note that PRACK, UPDATE and 100 Trying messages, and the like, should be processed by the sofia-SIP stack without involving the ISUP stack.

Processing 180 Ringing Response

CC_ALERTING_REQ

Processing 183 Session Progress Response

CC_PROGRESS_REQ

Processing 181 Call Is Being Forwarded Response

CC_PROGRESS_REQ

Processing 182 Queued Response

CC_PROGRESS_REQ

Processing 200 OK Response

CC_CONNECT_REQ

7.2.2.3 Unsuccessful Calls from PSTN to SIP

Processing 3xx Responses

Processing 4xx, 5xx and 6xx Responses

Call Abandonment

Call Failure

If, after recieving a CC_SETUP_IND primitive and before sending a CC_SETUP_RES primitive for the call, the interworking function receives a CC_CALL_FAILURE_IND primitive, the interworking function will examine the cc_reason or cc_cause field of the primitive and respond as follows:

ISUP_CALL_FAILURE_COT_FAILURE
CC_CAUS_TEMPORARY_FAILURE: This failure cause indicates that the continuity check on the circuit failed. This applies to incoming calls only.
ISUP_CALL_FAILURE_RECV_RLC
CC_CAUS_NORMAL_UNSPECIFIED: This failure cause indicates that the circuit was not completely released by the distant end. This applies to incoming calls only.
ISUP_CALL_FAILURE_BLOCKING
CC_CAUS_TEMPORARY_FAILURE: This failure cause indicates that the circuit was blocked by the receipt of a circuit blocking or circuit group blockin message during call setup. This applies to incoming calls only.
ISUP_CALL_FAILURE_T8_TIMEOUT
CC_CAUS_TEMPORARY_FAILURE: This failure cause indicates that the call failed while waiting for a continuity check report from the distant end. This applies to incoming calls only.
ISUP_CALL_FAILURE_T35_TIMEOUT
CC_CAUS_ADDRESS_INCOMPLETE: This failure cause indicates that additional information (digits) were not received form the caller within a sufficient period of time. This applies to incoming calls only and only when en block signaling is not used.

7.2.3 Interworking of Established Calls

For established calls, an nta transaction is established for the sofia-SIP stack, and a provider call reference is established for the ISUP stack. The transaction is identified by its client identifier for the sofia-SIP stack and the ISUP call is identified by its provider call reference. These two identifiers refer to the same call context object (structure) in the interworking function. To process events (callbacks) from the sofia-SIP stack, the client identifier is used to retrieve the call context. To process primivites received from the ISUP stack, the provider call reference is used to retrieve the call context.

7.2.3.1 Successful Established Calls

Established calls can be suspended and resumed from either a network or user perspective. Suspend and resume indications from ISUP as indicated by the CC_SUSPEND_IND and CC_RESUME_IND primitives are valid in the CC_CONNECTED or CC_SUSPENDED states.

Processing of CC_SUSPEND_IND

Upon receipt of a CC_SUSPEND_IND, the cc_call_ref field of the primitive will be used to retrieve the call context (session). The CC_SUSPEND_IND primitive will be responded to with a CC_SUSPEND_RES primitive and will not initially invoke the UPDATE method for the trial. The interworking function will mark the call context (session) as being in the (network or user) suspended state, CCS_SUSPENDED. At a later date, the CC_SUSPEND_IND primitive might invoke the UPDATE or re-INVITE method to suppress transfer of media during the suspend.⁵⁰

Processing of CC_RESUME_IND

Upon receipt of a CC_RESUME_IND, the cc_call_ref field of the primitive will be used to retrieve the call context (session). The CC_RESUME_IND primitive will be responded to with a CC_RESUME_RES primitive and will not initially invoke the UPDATE method for the trial. The interworking function will mark the call context (session) as being in the (network or user) suspended or established state, CCS_SUSPENDED or CCS_CONNECTED. At a later date, the CC_RESUME_IND primitive might invoke the UPDATE or re-INVITE method to restore transfer of media after resume from the suspend.

7.2.3.2 Failed Established Calls

Established calls can fail due to the expiration of a timer within ISUP (in accordance with normal ISUP procedures) or the expiration of a timer within SIP (in accordance with session timers).

Processing of CC_CALL_FAILURE_IND

ISUP_CALL_FAILURE_T2_TIMEOUT
CC_CAUS_NORMAL_CALL_CLEARING: This failure cause indicates that the controlling exchange received a user suspend message but did not receive a user resume message within time T2. This applies to all established calls.
ISUP_CALL_FAILURE_T6_TIMEOUT
CC_CAUS_NORMAL_CALL_CLEARING: This failure cause indicates that the non-controlling exchange received a network suspend message but did not receive a network resume message within time T6. This applies to all established calls.
ISUP_CALL_FAILURE_T38_TIMEOUT
CC_CAUS_RECOVERY_ON_TIMER_EXPIRY: This failure cause indicates that the call was (network) suspended beyond the allowable period. This applies to all established calls.

7.2.4 Interworking of Call Release

7.2.4.1 Calls Released by the SIP Network

Processing of CANCEL

Processing of BYE

7.2.4.2 Calls Released by the ISUP Network

Release by the Called Party

Release by the Calling Party

Processing of CC_RELEASE_IND

When the interworking function receives a CC_RELEASE_IND primitive for an established call, it uses the cc_call_ref field in the primitive to look up the call context (session). The interworking function examines the cc_cause field value in the CC_RELEASE_IND primitive, issues a CC_RELEASE_RES primitive (if a CC_RELEASE_REQ primitive has not already been issued for the call), awaits a CC_OK_ACK primitive and responds on the SIP side as illustrated in Table T-25, Table T-26, Table T-27, Table T-28, Table T-29 and Table T-30. However, if the cause value (cc_cause) is CC_CAUS_NORMAL_CALL_CLEARING, a BYE message is sent instead of a 4xx, 5xx or 6xx response.

7.2.5 SDP Handling

The OpenSS7 Media stack is illustrated in Figure 12 and interactions between the interworking function and the OpenSS7 Media stack are illustrated in Figure 14.

The OpenSS7 Media stack and Media Gateway Interface (MGI) are used for interworking TDM media connections with RTP. The Optranex 248 uses the OpenSS7 media stack for processing media streams. The /dev/mg driver is used for interworking TDM media streams into RTP media streams. A purpose-developed interworking function exists at the control nexus between the sofia-SIP and OpenSS7 Media stacks.

7.3 Carrier Proxy

The protocol architecture described in Protocol Architecture requires the implementation of a carrier proxy that communicates between customer proxies, the C-SCP, and the Optranex 248 gateway switch.

8 Hardware Architecture

The hardware of the Optranex 248 switch is based on two Kontron hardenned (NEBS 3 compliant) PC server chassis, each equipped with the Optranex 248 SONET/SDH card.

8.1 Power and Cooling

The hardenned (NEBS 3 compliant) PC servers are available with either 110/220VAC or -48VDC single or dual redundant power supplies. Redundant DC power supplies are required for the Central Office environment. The -48VDC power supplies are rated at 450 Watts per server. In a two-server configuration, a maximum of 900 Watts of power (approximately 20 Amps at -48VDC) is required. Cooling for a maximum of 900 Watts of power dissipation is required.

8.1.1 Grounding

The DC chassis provides two #10-32 threaded studs for chassis grounding. A single 90-degree standard barrel, two-hole, compression terminal lug with 5/8-inch pitch suitable for #14-10 AWG conductor (such as the Thomas & Betts’ terminal lug P/N 256-31426-141) must be used for proper safety grounding. A crimping tool may be needed to secure the terminal lug to the grounding cable.

8.2 Mounting

Mounting rails are available for a standard 19" dual or quad rail rack. Mounting rails for the Dallas InfoMart will require specification of whether the colo is in dual or quad rail 19" racks.

8.3 Ethernet Network Interfaces

Initial requirements are for 200 Mbps full-duplex capacity between the Optranex 248 switch servers and the customer proxy and SIP/RTP network. For load testing, however, 4 Gbps full-duplex capacity between the Optranex 248 switch servers and the customer proxy or other SIP/RTP network will be required.

Each server in the two-server configuration has four GigE NIC ports. These ports are accessible from the rear of the chassis. There are no GigE NIC ports accessible from the front of the chassis. The GigE NIC ports are intended to be installed with shielded cabling that is grounded at both ends of the cable.

The GigE NIC ports are intra-building ports suitable for connection to intra-building or unexposed wiring or cabling only. These intra-building ports must not be connected to, nor come into metalic contact with, interfaces that connect to the outside plant or its wiring. These interfaces are designed for use as intra-building interfaces only (Type 2 or 4 ports as described in GR-1089-CORE, Issue 4) and require isolation from the exposed outside plant cabling. Note that the addition of primary protectors is not sufficient protection for these interfaces to connect to, or come into metalic contact with, outside plant wiring.

8.4 SONET/SDH Network Interfaces

Initial requirements are for OC-12 1:1 APS connections from the PSTN (SONET ADM equipment). This OC-12 pipe will support a maximum of 12 DS-3s or 8064 channels; however, trunks are only allocated for an aggregate DS-3 capacity of 3 x DS-3s or 2016 channels.

The platform is capable of 2 x OC-48 1:1 APS connections (maximum of 96 DS-3s or 64,512 channels) or 4 x OC-48 unprotected connections (maximum of 192 DS-3s or 129,024 channels).

8.4.1 Small Formfactor Pluggable Modules

For trial, two SFP pluggable modules will be provided capable of OC-12 Single-Mode Fiber Short Reach (1310 nanometer) connectivity using two LC connectorized fibers per module. One SFP module will be plugged into the Optranex 248 card installed in each of the two hardenned (NEBS-3 compliant) PC servers. The SFP modules will be configured for 1:1 APS operation. These modules will be Finisar FTLF1322P1BTR (LC duplex, OC-12/3, SR, SF, 1310 nm) or equivalent.

8.4.1.1 Finisar Modules

Finisar has been providing SFP modules to the telecommunications industry for some time and is one of the market leaders in these devices. Finisar SFP modules are available from a number of popular suppliers including Digi-key, Avnet and Nu Horizons.

Suitable Finisar SFP modules are listed below in Table T-9.⁵¹

Table T-9. Finisar SFP Modules

Most of these Finisar SFP modules are available from Digi-key, Avnet and Nu Horizons.

For intra-office applications scaling to a maximum OC-3 rate, the FTLF1217P2BTL is the best value ($52.73); OC-12/3 rate, FTLF1322P1BTR ($80.00); OC-48/12/3 rate, FTLF1321P1BTL ($164.34).

Two FTLF1217P2BTL (2 x $80.00) and two FTLF1321P1BTL (2 x $164.34) SFP modules installed an Optranex 248 card can provide every possible configuration of the card: from 4 x OC-3 through 2 x OC-48, under software control.

8.4.1.2 Avago Technologies Modules

Suitable Avago Technologies SFP modules are listed below in Table T-8.

Table T-8. Avago SFP Modules

Avago provides a number of related modules; however, these variations either do not provide DMI (without reducing cost), or provide a temperature wider than the operating temperature range of the Optranex 248 at additional and unnecessary cost.

These Avago SFP modules are not available from Digi-key but are available from Avent. As an option, the AFCT-5765PZ for systems scaling to OC-3; AFCT-5755PZ ($73.85), OC-12/3 ($87.69); AFCT-5745PZ ($223.08), OC-48/12/3; may be used instead of the Finisar equivalents.

8.4.1.3 JDSU SFP Modules

Suitable JDSU SFP modules are listed below in Table T-13.

Table T-13. JDSU SFP Modules

These JSD Uniphase SFP modules are no available from Digi-key nor Avnet but are available from Nu Horizons.

Additional modules are listed under Alternate SFP Modules.

9 Platform Architecture

9.1 Inter-Server Chassis Cabling

Inter-server chassis cabling is provided for hardware APS connection and loopback between the two servers making up the Optranex 248 switch, as illustrated in Figure 8.

Figure 8. Inter-Server Chassis Cabling

Inter-server chassis cabling for the two hardenned PC servers of the Optranex 248 switch will consist of two components:

One set of 4 SMA male connectorized coaxial cables (illustrated in blue in Figure 8).
One SFP module connectorized loopback cable (illustrated in gold in Figure 8).
Two additional optional SFP module connectorized loopback cables (illustrated in gold in Figure 8).

9.1.1 SMA Cables

The purpose of SMA connectorized coaxial cabling is to provide hardware APS connectivity between the two hardenned PC servers that make up the Optranex 248 switch. One set of four SMA male connectorized coaxial cables will be provided for hardware based APS interconnection between the two Optranex 248 cards installed in each of the hardenned PC chassis. The SMA cables will carry receive and transmit paths for each of 2 x 2.5 Gbps AC-coupled LVDS hardware APS connections.

The 2 x 2.5 Gbps AC-coupled LVDS connections provide connection for hardware-based APS failover between the chassis. In this configuration, the each Optranex 248 server is capable of connecting to either SFP OC-12 module installed in separate chassis.

9.1.2 SFP Loop-back Cables

The purpose of the SFP loop-back cables is to provide for performance and capacity testing of the platforms. SFP loop-back cables capable of OC-48 speeds (2.488 Gbps) will be provided.⁵² These loopback cables plug into one SFP pluggable module interface on each of the two chassis and will be capable of looping back 48 DS-3s worth of traffic (32,256 channels). The loop-back cables are solely for performance and capacity testing of the platforms and will be not be used under normal operation.

Two additional optional SFP copper loopback cables capable of OC-12 or better operation may also be provided to meet specific test objectives during trial.

9.2 Spares

Spares will not be provided for the initial trial. Spare modules consist of the following:

spare Intel Xeon 5400 series processor;
spare memory modules;
spare pluggable 450 Watt -48 VDC power supplies;
spare pluggable fan modules (CPU fans, IO fans);
spare filter packs;
spare pluggable SAS harddrives;
spare Optranex 248 SONET/SDH interface PCI Express cards; and,
spare pluggable OC-12 SFP modules.

Note that with the exception of SONET optical modules, SAS harddrives and power supplies, replacement of parts including processors, memory modules, fan modules, filter packs, and PCI cards requires powering down at least one of the redundant servers. SONET optical modules, SAS harddrives and power supplies are hot-pluggable.

10 Management Architecture

10.1 Local Alarms

Each of the servers in the Optranex 248 switch provides a local dry-contact alarms interface.

10.2 Remote Management

Each server in the Optranex 248 platform requires a Remote Management Module and associated NIC.⁵³ These remote management modules are responsible for the remote management of the compute platforms. They provide HTTP, SNMP, and IPMI management capabilities.

10.3 SNMP Management

The SNMP management framework for the Optranex 248 gateway switching application is illustrated in Figure 15.

10.3.1 OpenSS7 Management Information Bases

10.3.1.1 STREAMS MIB

The OpenSS7 management information base used for the management of the STREAMS framework is provided by the OPENSS7-STREAMS-MIB and OPENSS7-STREAMS-EXT-MIB. An agent implementing the complete MIBs is available for trial.

10.3.1.2 SCTP MIB

RFC3873-MIB (SCTP-MIB)

10.3.1.3 M3UA MIB

The M3UA and MTP management information bases are responsible for the management, measurement, monitoring, auditing, alarming and configuration of the OpenSS7 SIGTRAN stack. Only the Application Server portions of the M3UA MIB are used for this application. Only those portions of the MTP MIB applicable to SIGTRAN M3UA are used for this application.

The OpenSS7 management information base used for the management of the SIGTRAN stack is provided by the OPENSS7-M3UA-ASP-MIB. Note that, for the Dallas trial, this MIB will only be implemented to the point necessary to performing configuration and basic alarms necessary for trial purposes. A completed implementation of the MIB will be provided for in-service.

10.3.1.4 ISUP MIB

The OpenSS7 enterprise management information bases used for the management of the ISUP component are contained in the OPENSS7-ISUP-MIB and OPENSS7-ISUP-OM-MIB. The former is responsible for the configuration, management and alarms associated with the ISUP stack. The later is responsible for operational measurements associated with the ISUP stack.

Note that, for the Dallas trial, these MIBs will only be implemented to the point necessary to performing configuration and basic alarms necessary for trial purposes. A completed implementation of the MIBs will be provided for in-service.

10.3.1.5 RTP MIB

10.3.1.6 SONET/SDH MIB

10.3.1.7 MX MIB

The OpenSS7 enterprise management information bases used for the management of the multiplex components are contained in the OPENSS7-MX-MIB, RFC2495-MIB (DS1-MIB), RFC3895-MIB (DS1-MIB), RFC4805-MIB (DS1-MIB), RFC4805-EXT-MIB (DS1-EXT-MIB), RFC2496-MIB (DS3-MIB) and RFC3896-MIB (DS3-MIB).

10.3.1.8 SWITCH MIB

The OpenSS7 enterprise management information bases used for the management of the switching of channel and multiplex components are contained in the OPENSS7-MX-MIB, OPENSS7-PHY-MIB, RFC2494-MIB (DS0-MIB) and RFC2494-EXT-MIB (DS0BUNDLE-MIB).

10.3.1.9 MG MIB

The OpenSS7 enterprise management information bases used ofr the management of the media gateway are contained in the OPENSS7-MG-MIB and OPENSS7-MG-OM-MIB.

11 System Architecture

12 Logistics

12.1 Site Preparation

12.1.1 Rack

Racks must be one of the following:

19-inch 2-Post rack with EIA Universal and EIA Wide hole spacing, and equipment mounting posts from 3 to 5 inches deep.
19-inch 4-Post rack with EIA Universal and EIA Wide hole spacing, and front equipment mounting rail to rear equipment mounting rail separation not exceeding 24 inchecs.
23-inch 2-Post rack with EIA Universal, EIA Wide and ETSI hole spacing, and equipment mounting posts from 3 to 5 inches deep.
23-inch 4-Post rack with EIA Universal, EIA Wide and ETSI hole spacing, and fron equipment mounting rail to rear equipment mount rail separation not exceeding 24 inches.

Physical dimensions and minimum clearances are listed in Table T-7.

Table T-7. Physical Dimensions

Note that additional clearance (to 6 inches) may be required front and rear to ensure that front inlet temperature does not exceed rated maximums and to ensure that rear exhaust does not interfere with other devices mounted in the same rack. Also, clearances are the minimum required to provide adequate ventilation given nominal environmental conditions. Additional clearance is required to provide access to the equipment for service of hard drives and power supplies.

12.1.1.1 Rack Mounts

A separate rack mount kit is required depending upon the rack. One rack mount kit is required for a 19" 2- or 4-post rack, another for a 23" 2- or 4-post rack. Rack mount kits will be provided with the Optranex servers.

12.1.1.2 Cable Management

Rack mount kits for the Optranex servers do not include cable management devices. Sufficient slack in cabling, both DC power and interface cables, must be provided to allow each server chassis to be pulled out 24 inches. Otherwise, any cabling or power feeds must be disconnected before sliding out the equipment on its equipment rails.

12.1.2 Power

The hardenned (NEBS 3 compliant) PC servers are available with either 110/220VAC or -48VDC single or dual redundant power supplies. Renundant DC power supplies are required for the Central Office environment and are provided for trial and in-service.

12.1.2.1 DC Power

The -48VDC power supplies are rated at 450W per server. Breakers or fuses should be rated at no more than 10 amps (per server). For more details on DC power requirements, see DC Power. Breaker or fuse panels for trial will be provided by Heramax.

Grounding

Each DC server chassis provides to #10-32 threaded studs for chassis grounding. A single 90-degree standard barrel, two-hole, compression terminal lug with 5/8-inch pitch suitable for #14-10 AWG conductor (such as Thomas & Betts’ terminal lug P/N 256-31426-141) must be used for proper safety grounding. A crimping tool may be needed to secure the terminal lug to the grounding cable. For more details on grounding, see ‘Grounding the Server’.

12.1.2.2 AC Power

The Optranex servers for the trial are DC powered. AC power will not be required for either the trial or in-service.

12.1.3 Cooling

12.1.3.1 Temperature

The temperature, in which each server operates when installed in an equipment rack must not go below 5 degrees Celcius (41 degress Farenheit) or rise above 35 degress Celcius (95 degress Farenheit). Extreme fluctuations in temperature can cause a variety of problems.

12.1.3.2 Ventilation

The equipment rack must provide sufficient airflow to the front of each server to maintain proper cooling. The rack must also include ventilation sufficient to exhaust a maximum of 1023 BTUs (British Thermal Units) per hour for each server, or 2046 BTU per hour total. The rack selected and the ventilation provided must be suitable to the environment in which the servers will be used.

Physical dimensions and minimum clearances for adequate ventilation are listed in Table T-7.

12.1.4 Connections

12.1.4.1 Ethernet Connections

Each of the two server chassis has 4 x 1000baseT RJ-45 Ethernet NIC primary interfaces, and 1 x 100baseT RJ-45 Ethernet NIC for the remote management module. This is a total of 8 x 1000baseT RJ-45 Ethernet NIC primary interfaces and 2 x 100baseT RJ-45 Ethernet NIC remote management modules, or, a total of 10 RJ-45 connections for trial. Provision should be made for growth to an additional two server chassis at in-service.

Proper alien noise immunity on all Ethernet NIC cables requires Category 6 or 6a STP (Shielded Twisted Pair). These cables will be provided for trial and in-service by Heramax at installation.

For additional information on Ethernet connections, see Ethernet Connections.

12.1.4.2 SONET Connections

Fiber patch cords for connection between GC optical passive cross-connects and the Optranex server chasses will be provided by GC or Heramax. Patch cords will be compiant to OC-12/3, short-reach, single-mode, 1310nm, 9/125 fiber. The Optranex end of the fiber patch cords must have LC duplex connectors.

Additional loop-back copper module terminated cables will be used for performance testing. These copper loop-back cables will be provided by Optranex for trial and are not required for in-service.

For additional information of SONET/SDH connections, see SONET/SDH Connections.

12.1.4.3 Management Connections

Additional management connections, beyond the Ethernet RMM connections which were included above under Ethernet Connections, such as the serial interface and local alarms panel dry contact interface will not be used for trial.

12.1.4.4 Hardware APS Connections

Hardware APS connections use SMA coaxial cables that connect between the server chasses. These cables will be provided by Optranex and need to be installed between the interface card SMA connectors. These connections might not be used for trial but will be used for in-service.

12.2 Equipment List

12.2.1 Servers

The Optranex 248 consists of two server chassis. Each is a Kontron TIGW1U (product code TMRA0201W or TMRD0201W or equivalent) server.

12.2.1.1 Processors

Each server is equipped with two Quad-Core Intel Xeon 5400 or 5500 series processors, preinstalled.

12.2.1.2 Memory

Each server is equipped with DDR3 memory modules, preinstalled.

12.2.1.3 Hard Drives

The Optranex 248 servers are each equipped with 3 hot-swappable SAS (Serial Attached SCSI) hard-drives, preinstalled.

12.2.1.4 PCIe Riser

Each Optranex 248 server is equipped with a PCIe Riser Card inserted into a PCI Super Slot. The PCIe Riser card provides for x1, x4 or x8 lane operation. The Optranex 248 SONET/SDH cards are x4 lane PCIe cards. The Optranex 192 SONET/SDH cards are x8 lane PCIe Cards.

12.2.1.5 Power Supplies

Each Optranex 248 server can be equipment with one or two (redundant, hot-swappable) AC or DC power supplies. Each server chassis will be provided with two (redundant hot-swappable) DC power supplies, preinstalled.

12.2.2 Interface Cards

Each Optranex 248 server is equipped with either a Optranex 248 x4 lane PCIe or Optranex 192 x8 lane PCIe SONET/SDH card. For the Dallas trial, each server will be equipped with one Optranex 248 x4 lane PCIe card. Interface cards will be installed separately and after server installation.

12.2.3 SFP Modules

Each Optranex 248 SONET/SDH card accepts up to four SFP modules. SFP modules must be compliant with SFF Committee INF-8074i Revision 1.0 specifications. SFP modules will be provided by Optranex and will be installed with the interface cards.

12.2.4 Cables

Cable requirements are as follows:

10 Category 6 or 6a STP RJ-45 patch cords, 5 between the rear of each Optranex server chassis and the Juniper router.
2 9/125 fiber patch cords with LC duplex connectors, one between the GC optical patch panel and the rear of each Optranex server chassis.
4 x SMA coaxial patch cords between the rear of the Optranex server chassis.
3 x SFP copper patch cables between the rear of the Optranex server chassis.

12.2.5 Rack Mount Kits

Two 19" rack mount kits will be provided by Optranex: one for each server chassis.

12.2.6 Cable Management Kits

The Optranex servers must be disconnected from power and interface units before the case is opened for service. Cable managements kits are not required when connections are removed before the server is slid out on its equipment rails.

12.3 Installation

The cabinet layout for the Dallas trial is illustrated in Figure 13.

Figure 13. Cabinet Layout

12.3.1 Rack

Two or more people are require to install the server chassis in the rack. Room air temperature must be below 95 degrees Farenheit (35 degrees Celsius) during installation and operation. Air vents (front an back) must have at least 6 inches (15 centimeters) clearance for proper ventilation. Device installation should begin from the bottom of the rack upward. The heaviest devices should be installed toward the bottom of the rack. Not more than one device should be extended our of the rack at a time. Remove rack doors and side pannels to provide unrestricted access during installation. Ensure that devices are attached to properly grounded power feeds and that multiple devices do no overload the power outlets during installation. Do not place any object weighing more than 110 pounds (50 kilograms) on top of rack-mounted devices.

Rack installation requires flat-blade and phillips screwdrivers and rack mount kit appropriate for the rack in which the server chassis are to be installed. There are two rack mount kits: one for 19" 2- and 4-post racks; another for 23" 2- and 4-post racks.

12.3.2 Power

Servers can be installed using one or two (redundant) AC or DC power supplies. For evaluation and laboratory installations, only one AC or DC power supply is required. Requirements for DC and AC power feeds are discussed in DC Power and AC Power.

12.3.2.1 DC Power

Connection with a DC (Direct Current) source should only be performed by trained service personnel. The server with DC input is to be installed in a Restricted Access Location in accordance with articles 110-26 and 110-27 of the National Electric Code, ANSI/NFPA 70. The DC source must be electrically isolated by double or reinforced insulation from any hazardous AC source. The DC source must be capable of providing up to 300 watts of continuous power per feed pair.

Mains DC Power Disconnect

You are responsible for installing a properly rated DC power disconnect for the server system. This mains disconnect must be readily accessible, and it must be labeled as controlling power to the servers. The UL Listed circuit breaker of a centralized DC power system may be used as a disconnect device when easily accessilble and should be rated no more than 10 amps.

Grounding the Server

The servers are inteneded for installation with an isolated DC return (DC-I) and is to be installed in a Commong Bonding Network (CBN) per NEBS GR-1089. To avoid the potential for an electrical shock hazard, the servers must be reliably connected to an earth grounding conductor. The earth grounding conductor must be a minimum 14AWG connected to the earth ground studs on the rear of each server. The safety ground connector should be connected to each chassis stud with a Listed closed two-hole crimp terminal having a 5/8-inch pitch. The nuts on the chassis earth ground studs should be installed with a 10 in-lb torque. The safety ground conductor provides proper grounding only for each server chassis connected. Additional, proper grounding must be provided for the rack and other devices installed in it.

Each DC chassis provides two #10-32 threaded studs for chassis enclosure grounding. A single 90-degree standard barrel, two-hole, compression terminal lug with 5/8-inch pitch suitable for #14-10 AWG conductor (such as the Thomas & Betts’ terminal lug Part Number 256-31426-141) must be used for proper safety grounding.

Overcurrent Protection

Overcurrent protection UL Listed circuit breakers must be provided as part of each host equipment rack and must be incorporated in the field wiring between the DC source and the server. The branch circuit protection shall be rate minimum 75Vdc, 10 A maximum per feed pair. If the DC power system for the equipment rack is installed with more than 10 amperes of protection, supplemental protection for each server must be provided. The overall current rating of a maximum configured server chassis is 8 amperes.

12.3.2.2 AC Power

Mains AC Power Disconnect

The AC power cords are considered the mains disconnect for each server and must be readily accessible when installed. If the individual server power cords will be be readily accessible for disconnection, an AC power disconnect for the entire rack must be provided. This main disconnect must be readily accessible, and it must be labeled as controlling power to the entire rack, not just to the servers.

Grounding the Rack Installation

To avoid the potential for an electrical shock hazard, a third wire safety ground conductor must be included with the rack installation. If the server power cords are plugged into an AC outlet that is part of the rack, proper grounding must be provided for the rack itself. If the server power cord is plugged into a wall AC outlet, the safety ground conductor in the power cord provides proper grounding only for the server. Additional, proper grounding must be provided for the rack and other devices installed in it. This system is intended for connection to a Common Bonding Network (CBN) as defined by NEBS GR-1089.

Overcurrent Protection

The server is designed to an AC line voltage source with up to 20 amperes of overcurrent protection per cord feed. If the power system for the equipment rack is installed on a branch circuit with more than 20 amperes of protection, supplemental protection must be provided for each server. The overall current rating of a configured server is less than 6 amperes.

Do not attempt to modify or use an AC power cordset that is not the exact type required. The power cordset must meet the following criteria:

Rating:– In the US and Canada, cords must be UL (Underwriters Laboratories, Inc.) Listed/CSA (Canadian Standards Organization) Certified type SJT, 18-3 AWG (American Wire Gauge). Outside of the US and Canada, cords must be flexible harmonized (<HAR>) or VDE (Verband Deutscher Electrotechniker, German Institute of Electircal Engineers) certified cord with 3 x 0.75 mm conductors rated 250 VAC.
Connector, wall outlet end:– Cords must be terminated in grounding-type male plug designed for use in your region. The conenct must have certification marks showing certification by an agency acceptable in your region and for U.S. must be Listed and rated 125% of overall current rating of each server.
Connector, server end:– The connectors that plug into the AC receptacle on the server must be an approved IEC (International Electrotechnical Commission) 320, sheet C13, type female connector.
Cord length and flexibility:– Cores must be less than 4.5 meters (14.8 feet) long.

12.3.3 Cooling

Temperature

Ventilation

The equipment rack must provide sufficient airflow to the front of each server to maintain proper cooling. The rack must also include ventilation sufficient to exhaust a maximum of 1023 BTUs (British Thermal Units) per hour for the server. The rack selected and the ventilation provided must be suitable to the environment in which the servers will be used.

12.4 Spares

Spares will not be provided for the initial trial. Spares will be provisioned for the full in-service date. Spares consist of the following:

spare Intel Xeon 5400 series processor;
spare memory modules;
spare pluggable 450 Watt -48 VDC power supplies;
spare pluggable fan modules (CPU fans, IO fans);
spare filter packs;
spare pluggable SAS harddrives;
spare Optranex 248 SONET/SDH interface PCI Express cards; and,
spare pluggable OC-12 SFP modules.

12.5 Schedule

12.5.1 Equipment Delivery and Installation

Optranex server chassis and equipment rails will be delivered to site and installed first. According to current schedules, servers will be shipped to arrive between March 1 and March 30, 2010.

Optranex interface cards, SONET pluggable modules, SMA patch cables, and SFP loop-back cables, will be shipped separately. SONET/SDH Interface cards and components will be shipped, according to current schedules, to arrive between March 30, 2010 and April 12, 2010.

12.5.2 Field Trial

Test plan execution and trunk turn up will commence, according to current schedules, the week of April 12, 2010. During the period from April 12, 2010 to May 12, 2010, the Optranex platform may be turned up and down and may experience unplanned service outages. All planned outages will be performed within an preplanned evening maintenance window after trunks have been turned up the week of April 12, 2010. The Optranex platform can only be provisioned by Optranex staff during the field trial.

12.5.3 Provisioning Trial

Provisioning of the services provided by the Optranex 248 will be available, according to current schedules, the week of May 10, 2010. The provisioning plan will be executed that week to prove the integration with back-end provisining systems. After the provisioning trial is complete, the Optranex 248 platform will be provisionable by Heranax personnel.

12.5.4 Inservice

In service will commence June 1, 2010. A separate inservice plan will be prepared to address redundancy, spares, etc.

13 Provisioning Plan

13.1 SONET Segment Assignments

13.2 SONET Path Assignments

13.3 SIGTRAN Signaling Gateway Additions

This section provides an overview of the addition of signalling gateways for SIGTRAN connectivity from the Optranex switch to the SS7 signaling network.

13.4 PSTN Signaling Point Additions

This section provides an overview of the addition of remote signaling points for SS7 Signaling over SIGTRAN M3UA.

To assign a signaling point, the following information is required:

Signaling point code.
Protocol variant.
Protocol options. Protocol options include the following:
- SS7_POPT_UPT — whether to send UPT messages.
- SS7_POPT_LPA — whether to send LPA messages.
- SS7_POPT_UCIC — whether to send UCIC messages.
Exchange type. This can be one of the following:
- ISUP_XCHG_TYPE_A — the exchange is a end-office exchange.
- ISUP_XCHG_TYPE_B — the exchange is a tandem exchange.

13.5 PSTN Signaling Relation Additions

This section provides an overview of the addition of signalling relations for SS7 ISUP Signaling over SIGTRAN M3UA.

Assignments that need to be made prior to signaling relation additions are as follows:

Signaling point assignment.

Assignments made to add signaling relations are as follows:

Signaling relation assignment.

To assign as signaling relation, the following information is required:

The signaling point code of the near-end signaling point. This signaling point is identified by its signaling point identifier (which is an identifier local to the Optranex switch).
The signaling point code of the far-end signaling point. This signaling point is identified by its signaling point code.
Protocol variant used in the communication between signaling points.
Protocol options used between signaling points.
Timer values as follows (when they deviate from default values):
- T4 — waiting for UPA or other messages.
- T18 — waiting for circuit-group-blocking-acknowledge retry.
- T19 — waiting for circuit-group-blocking-acknowledgement maintenance.
- T20 — waiting for circuit-group-unblocking-acknowledge retry.
- T21 — waiting for circuit-group-unblocking-acknowledge maintenance.
- T22 — waiting group-reset-acknowledge retry.
- T23 — waiting group-reset-acknowledge maintenance.
- T28 — waiting circuit-query-response.
- T29 — congestion attack timer.
- T30 — congestion decay timer.
- Tcgb — waiting for blocking-acknowledge (ANSI).
- Tgrs — waiting for reset-acknowledge (ANSI).
- Thga — waiting for blocking-acknowledge hardware (ANSI).
- Tscga —- waiting for blocking-acknowledge software (ANSI).
- Tscga_d —- waiting for blocking-acknowledge software (ANSI).

13.6 SIP Proxy Additions

This section provides an overview of the addition of Customer proxies to the OpenSIPs and C-SCP platforms. The Optranex is not involved in this assigment.

13.7 PSTN Trunk Group Addtions

This section provides an overview of the addition of PSTN trunks to establish trunk group connectivity between the Optranex and remote switches.

Assignments that need to be made prior to PSTN trunk group additions are as follows:

SONET segment assignment.
SIGTRAN SG assignment.
PSTN Signaling Point assignment.

Assignments made to add PSTN trunk groups are as follows:

ISUP trunk group assignment.

The attributes (data) necessary to make an ISUP trunk group assignment is as follows:

Near-end signaling point code. The near-end signalling point code is a point code selected from the point codes assigned to the Optranex switch.
Far-end signaling point code. The far-end signalling point code is a point code selected from the point codes assigned to the remote switch to which the trunk group connects.
Direction. This can be one of the following:
- ISUP_TG_TYPE_OG — one-way outgoing trunk group.
- ISUP_TG_TYPE_IC — one-way incoming trunk group.
- ISUP_TG_TYPE_2W — both-way trunk group.
Circuit selection procedure. This can be one of the following:
- ISUP_SELECTION_TYPE_MRU — most recently used.
- ISUP_SELECTION_TYPE_LRU — least recently used.
- ISUP_SELECTION_TYPE_ASEQ — ascending sequential.
- ISUP_SELECTION_TYPE_DSEQ — descending sequential.
Trunk group options. This can be zero or more of the following:
- ISUP_TGF_GLARE_PRIORITY — when set, indicates that the local exchange has priority in glare conditions; when unset, indicates that the remote exchange has priority in glare conditions.
- ISUP_TGF_INCOMING_INTERNATIONAL_EXCHANGE — set to indicate that the remote exchange is an incoming international exchange on this trunk group.
- ISUP_TGF_SUSPEND_NATIONALLY_PERFORMED — set to indicate that suspend and resume procedures are performed according to national specifications.
- ISUP_TGF_CONTROLLING_EXCHANGE — set to indicate that the local exchange is a controlling exchange on this trunk group.

13.8 PSTN Route Additions

This section provides an overview of the addition of overflow routes. Overflow routes consist of a series of one-way-outgoing or both-way trunk groups. The series identifies the overflow pattern for outgoing circuit seizures. The first trunk group in the series is attempted first. If as circuits are busy in the first group in the series, the second group is attempted.

Assignments that need to be made prior to PSTN route additions are as follows:

PSTN trunk group assignment.

Assignments made to add PSTN routes are as follows:

PSTN route assignment.

13.9 PSTN Circuit Group Additions

This section provides an overview of the addition, change or removal of circuit groups. Circuit groups are used in the management and maintenance procedures for ISUP signaling. ANSI uses implied or pre-assigned circuit groups. A circuit group is identified using one of the circuit identification codes assigned within the circuit group. Circuit groups must be assigned before circuits within the group can be assigned.

Assignments that need to be made prior to circuit group assignments are as follows:

PSTN Signaling Point assignments (both local and remote).

Assignments made to add circuit groups are as follows:

PSTN circuit group assignment.

13.10 PSTN Circuit Additions

This section provides an overview of the addition, change or removal of trunks (circuits) within PSTN trunk groups.

Assignments that need to be made prior to PSTN trunk additions are as follows:

PSTN trunk group assignment.
PSTN circuit group assignment.
SONET path assignment.

Assignments made to add PSTN trunk groups are as follows:

Near-end signaling point code.
Far-end signaling point code.
Primary circuit identification code.
Pre-assigned or implied grouping.

ISUP circuit assignment.

13.11 PSTN Virtual Trunk Group Additions

This section provides an overview of the addition, change or removal of PSTN virtual trunk groups (for outgoing calls only).

13.12 SIP Virtual Trunk Group Additions

This section provides and overview of the addition of SIP virtual trunk groups (for incoming calls only) to the OpenSIPs and C-SCP platforms.

13.12.1 OpenSIPS

13.12.2 Optranex

13.12.3 C-SCP

14 Test Plan

14.1 OpenSIPS

14.2 Optranex

14.3 C-SCP

14.4 Outgoing Calls

14.5 Incoming Calls

Appendix A Alternate Hardware

A.1 Alternate SFP Modules

This appendix contains lists of SFP modules that are compatible with the Optranex 248 card according to their advertised specifications. Note that these modules have not been tested; however, if they are compliant with the SFP MSA as advertised, they should work properly with the Optranex 248.

A.1.1 Eoptolink Modules

Suitable Eoptolink SFP modules are listed below in Table T-10.

Table T-10. Eoptolink SFP Modules

Eoptolink also has a number of OC-3 to OC-48 capable single fiber bidirectional WDM SFP modules, however, these are not in common usage for central office equipment.

A.1.2 Xgiga SFP Modules

Suitable Xgiga SFP modules are listed below in Table T-11.

Table T-11. Xgiga SFP Modules

A.1.3 Star Opto SFP Modules

Suitable Star Opto SFP modules are listed below in Table T-12.

Table T-12. Star Opto SFP Modules

A.1.4 Opnext SFP Modules

Suitable Optnext SFP modules are listed below in Table T-14.

Table T-14. Optnext SFP Modules

A.1.5 NEC SFP Modules

Suitable NEC SFP modules are listed below in Table T-15.

Table T-15. NEC SFP Modules

A.1.6 LuminentOIC SFP Modules

Suitable LuminentOIC SFP modules are listed below in Table T-16.

Table T-16. LuminentOIC SFP Modules

A.1.7 GEVISTA SFP Modules

Suitable GEVISTA SFP modules are listed below in Table T-17.

Table T-17. GEVISTA SFP Modules

These modules are available from Newstar.

Appendix B Protocol Values

B.1 Cause Values

This section described cause values applicable to US networks and how they interact with SIP 4xx, 5xx and 6xx responses. In these responses, the cause value is contained in the Reason header in accordance with RFC 3326.⁵⁴

B.1.1 Cause Value to SIP Response Mapping

When the Optranex 248 gateway switch generates a SIP 4xx, 5xx or 6xx response to an INVITE message from the SIP network, no Reason header will be included in the SIP response. This is to avoid the situation where an attack on the platform is assisted by the detailed cause value in a response message.

When the Optranex 248 gateway switch receives a SIP 4xx, 5xx, or 6xx response to an INVITE message sent to the SIP network, the Reason header and the contained cause values will only be honored if the response was sent via the C-SCP. That is, a C-SCP host name or IP address is contained in a Via header in the response immediately after the Carrier Proxy Via header. This is to avoid attacks on the platform by UAs that arbitrarily set a Reason header in a response.

ITU-T Q.850 Cause 1 Unallocated (unassigned) number. This cause indicates thtat the called party cannot be reached because, although the called pary number is in a valid format, it is not currently allocated (assigned).
This cause value can be contained in (and will trigger) a 404 Not Found response. This is the default value that will be assigned if a 404 Not Found message is received without an ANSI or Q.850 Reason header. The C-SCP is expected to generate this cause value under appropriate conditions.
ITU-T Q.850 Cause 2 No route to specified transit network. This cause indicates that the equipment sending this cause has received a request to route the call through a particular transit network which it does not recognize. The equipment sendnig this cause does not recognize the transit network either because the transit network does not exist or because that particular transit network, while it does exist, does not serve the equipment which is sending this cause. This cause is supported on a network-dependent basis.
This cause value can be contained in (and will trigger) a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 3 No route to destination. This cause indicates that the called party cannot be reached because the network through which the call has been routed does not serve the destination desired. This cause is supported on a network-dependent basis.
This cause value can be contained in (and will trigger) a 500 Server Internal Error response. The C-SCP is expected to generate this cause value under appropriate conditions.
ITU-T Q.850 Cause 4 Send special information tone. This cause indicates that the calling party cannot be reached for reasons that are of a long term nature and that the special information tone should be returned to the calling party.
This cause value can be contained in (and will trigger) a 500 Server Internal Error response. The C-SCP is expected to generate this cause value under appropriate conditions.
ITU-T Q.850 Cause 5 Misdialled trunk prefix. This cause value is not used for US networks.
This cause value can be contained in (and will trigger) a 404 Not Found response. The C-SCP is expected to generate this cause value under appropriate conditions.
ITU-T Q.850 Cause 8 Preemption. This cause indicates that the call is being preempted.
This cause value can be contained in (and will trigger) a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 9 Preemption - circuit reserved for reuse. This cuase indicates that the call is being preempted and the circuit is reserved for reuse by the preempting exchange.
This cause value can be contained in (and will trigger) a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 16 Normal call clearing. This cause is used to indicate that the call is being cleared because one of the users involved in the call has requested that the call be cleared. Under normal sitations, the source of this cause is not the network.
This cause value is indicated by (or triggers) a BYE or CANCEL request. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 17 User busy. This cause is used to indicate that the called party is unable to accept another call because the user busy condition has been encountered. This cuase value may be generated by the called user or by the network. In the case of user determined user busy, it is noted that the user equipment is compatible with the call.
This cause value is used whenever a 486 Busy Here response is received. This cause value can be contained in (and will trigger) a 486 Busy Here response. The C-SCP is expected to generate this cause value under appropriate conditions.
ITU-T Q.850 Cause 18 No user responding. This cause is used when a called party does not response to a call establishment message with either an alerting or connect indication within the prescribed period of time allocated.
This cause value can be contained in (and will trigger) a 480 Temporarily Unavailable response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 19 No answer from user (user alerted). This value is used when the called party has been alterted but does not response with a connect indication within the prescribed period of time. Note - this cause is not necessarily generated by Q.931 procedures but may be generated by internal network timers.
This cause value can be contained in (and will trigger) a 480 Temporarily Unavailable response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 20 Subscriber absent. This cause value is used when a mobile station has logged off, radio contact is not obtained with a mobile station or if a personal telecommunication user is temporarily not addressable by any user-network interface.
This cause value can be contained in (and will trigger) a 480 Temporarily Unavailable response. The C-SCP is expected to generate this cause value under appropriate conditions.
ITU-T Q.850 Cause 21 Call rejected. This cause indicates that the equipment sending this cause does not wish to accept this call, although it could have been accepted the call because the equipment sending this cause is neither busy nor incompatible. This cause may also be generated by the network, indicating that the call was cleared due to a supplementary service constraint. The diagnostic field may contain additional information about the supplementary service and reason for rejection.
This cause value can be contained in (and will trigger) a 480 Temporarily Unavailable response. The C-SCP is expected to generate this cause value under appropriate conditions.
ITU-T Q.850 Cause 22 Number changed. This cause is returned to a calling party when the called party number indicated by the calling party is no longer assigned. The new called party number may optionally be included in the diagnostic field. If a network does not support this cause value, cause number 1, unallocated (unassigned) number shall be used.
This cause value is used whenever a 410 Gone response is received. This cause value is used whenever a 301 Moved Permanently response is received. The tel URI contained in the Contact header contains the new number. This cause value can be contained in (and will trigger) a 410 Gone or 301 Moved Permanently response (depending upon whether the number is present). The C-SCP is expected to generate this cause value under appropriate conditions.
ITU-T Q.850 Cause 23 Redirect to new destination. This cause is used by a general ISUP protocol mechanism that can be invoked by an exchange that decides that the call should be set up to a different called number. Such an exchange can invoke a redirect mechanism, bu use of this cause value, to request a preceding exchange involved in the call to route the call to the new number.
This cause value is used whenever a 302 Moved Temporarily response is received. The tel URI contained in the Contact header contains the new number. This cause value can be contained in (and will trigger) a 302 Moved Temporarily response. The C-SCP is expected to generate this cause value under appropriate conditions.
ITU-T Q.850 Cause 27 Destination out of order. This cause indicates that the destination indicated by the user can not be reached because the interface to the destination is not functioning correctly. The term "not functioning correctly" indicates that a signaling message was unable to be delivered to the remote party. For example, a physical layer or data link layer failure at the remote party, or user equipment off-line.
This cause value is used whenever a 502 Bad Gateway response is received. This cause value can be contained in (and will trigger) a 502 Bad Gateway response. The C-SCP is expected to generate this cause value under appropriate conditions.
ITU-T Q.850 Cause 28 Invalid number format (address incomplete). This cause indicates that the called party cannot be reached because the called party number is not in a valid format or is not complete. Note - this condition may be determined immediately after the reception of an ST signal, or on time-out after the last received digit.
This cause value is used whenever a 484 Address Incomplete response is received. This cause value can be contained in (and will trigger) a 484 Address Incomplete response. The C-SCP is expected to generate this cause value under appropriate conditions.
ITU-T Q.850 Cause 29 Facility rejected. This cause is returned when a supplementary service requiested by the user cannot be provided by the network.
This cause value can be contained in (and will trigger) a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 31 Normal, unspecified. This cause is used to report a normal event only when no other cause in the normal class applies.
This cause value can be contained in (and will trigger) a 480 Temporarily Unavailable response. The C-SCP is expected to generate this cause value under appropriate conditions.
ITU-T Q.850 Cause 34 No circuit/channel available. This cause indicates that there is no appropriate circuit/channel presently available to handle the call.
This cause value can be contained in (and will trigger) a 480 Temporarily Unavailable response. The C-SCP is expected to generate this cause value under appropriate conditions.
ITU-T Q.850 Cause 38 Network out of order. This cause indicates that the network is not functioning correctly and that the condition is likely to last a relatively long period of time; for example, immediately re-attempting the call is not likely to be successful.
This cause value can be contained in (and will trigger) a 500 Server Internal Error response. The C-SCP is expected to generate this cause value under appropriate conditions.
ITU-T Q.850 Cause 41 Temporary failure. Thie cause indicates that the network is not functioning correctly and that the condition is not likely to last a long period of time; for example, the user may wish to try another call attempt almost immediately.
This cause value can be contained in (and will trigger) a 500 Server Internal Error response. The C-SCP is expected to generate this cause value under appropriate conditions.
ITU-T Q.850 Cause 42 Switching equipment congestion. This cause indicates that the switching equipment generating this cause is experiencing a period of high traffic.
This cause value can be contained in (and will trigger) a 500 Server Internal Error response. The C-SCP is expected to generate this cause value under appropriate conditions.
ITU-T Q.850 Cause 43 Access information discarded. THis cause indicates that the network could not deliver access information to the remote user as requested; that is, user-to-user information, low layer compatibilty, high layer compatibility, or sub-address, as indicated in the diagnostic.
This cause value can be contained in (and will trigger) a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 44 Requested circuit/channel not available. This cause is returned when the circuit or channel indicated by the requesting entity cannot be provided by the other side of the interface.
This cause value can be contained in (and will trigger) a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 46 Precedence call blocked. This cause indicates that there are no preemptable circuits or that the called user is busy with a call of equal or higher preemptable level.
This cause value can be contained in (and will trigger) a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 47 Resource unavailable, unspecified. This cause is used to report a resource unavailable event only when no other cause in the resource unavailable class applies.
This cause value can be contained in (and will trigger) a 500 Server Internal Error response. The C-SCP is expected to generate this cause value under appropriate conditions.
ITU-T Q.850 Cause 50 Requested facility not subscribed. This cause indicates that the user has requested a supplementary service which is implemented by the equipment which generated the cause, but the user is not authorized to use.
This cause value can be contained in a 500 Server Internal Error, 606 Not Acceptable or 488 Not Acceptable response, and will trigger a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 53 Outgoing calls barred within CUG. This cause value is not used in US networks.
This cause value can be contained in (and will trigger) a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 55 Incoming calls barred within CUG. This cause value is not used in US networks.
This cause value can be contained in (and will trigger) a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 57 Bearer capability not authorized. This cause indicates that the user has requested a bearer capability which is implemented by the equipment which generated this cause but the user is not authorized to use.
This cause value can be contained in a 500 Server Internal Error, 606 Not Acceptable or 488 Not Acceptable response, and will trigger a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 58 Bearer capability not presently available. This cause indicates that the user has requested a bearer capability which is implemented by the equipment which generated this cause but which is not available at this time.
This cause value can be contained in a 500 Server Internal Error, 606 Not Acceptable or 488 Not Acceptable response, and will trigger a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 62 Inconsistency in designated outgoing access information and subscriber class. This cause indicates that there is an inconsistency in the designated outgoing access information and subscriber class.
This cause value can be contained in a 500 Server Internal Error, 606 Not Acceptable or 488 Not Acceptable response, and will trigger a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 63 Service or option not available, unspecified. This cause is used to report a service or option not available event only when no other cause in the service or option not available class applies.
This cause value can be contained in a 500 Server Internal Error, 606 Not Acceptable or 488 Not Acceptable response, and will trigger a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 65 Bearer capability not implemented. This cause indicates that the equipment sending this cause does not support the bearer capability requested.
This cause value can be contained in a 500 Server Internal Error, 606 Not Acceptable or 488 Not Acceptable response, and will trigger a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 69 Requested facility not implemented. This cause indicates that the equipment sending this cause does not support the requested supplementary service.
This cause value can be contained in a 500 Server Internal Error, 606 Not Acceptable or 488 Not Acceptable response, and will trigger a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 70 Only restricted digital information bearer capability is available. This cause indicates taht the calling party has requested an unrestricted bearer service but that the equipment sending this cause only supports the restricted version of the requested bearer capability.
This cause value can be contained in a 500 Server Internal Error, 606 Not Acceptable or 488 Not Acceptable response, and will trigger a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 79 Service or option not implemented, unspecified. This cause is used to report a service or option not implemented event only when no other cause in the service or option not implemented class applies.
This cause value can be contained in a 500 Server Internal Error, 606 Not Acceptable or 488 Not Acceptable response, and will trigger a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 87 User not member of CUG. This cause value is not used in US networks.
This cause value can be contained in (and will trigger) a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 88 Incompatible destination. This cause indicates that the equipment sending this cause has received a request to establish a call which has low layer compatibility, high layer compatibility, or other attributes (e.g. data rate) which cannot be accommodated.
This cause value can be contained in a 500 Server Internal Error, 606 Not Acceptable, or 488 Not Acceptable response, and will trigger a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 90 Non-existent CUG. This cause value is not used in US networks.
This cause value can be contained in (and will trigger) a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 91 Invalid transit network selection. This cause value indicates that a transit network identification was received which is of an incorrect format as defined in Annex C of T1.607.
This cause value can be contained in (and will trigger) a 404 Not Found response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 95 Invalid message, unspecified. This cause is used to report an invalid message event only when no other cause in the invalid message class applies.
This cause value can be contained in (and will trigger) a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 97 Message type non-existent or not implemented. This cause indicates that the equipment sending this cause has received a message with amessage type it does not recognize either because this is a message not defined or defined but not implemented by the equipment sending this cause.
This cause value can be contained in (and will trigger) a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 99 Information element/Paramter non-existent or not implemented. This cause indicates that the equipment sending this cause has received a message which includes information elements or parameters not recognized because the information element identifiers or parameter names are not defined or are defined but not implemented by the equipment sending the cause. This cause indicates that the information elements or parameters were discarded. However, the information element is not required to be present in the message for the equipment sending the cause to process the message.
This cause value can be contained in (and will trigger) a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 102 Recovery on timer expiry. This cause indicates that a procedure has been initiated by the expiry of a timer in association with error handling procedures.
This cause value can be contained in (and will trigger) a 480 Temporarily Unavailable response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 103 Parameter non-existent or not implemented - passed on. This cause indicates that the equipment sending this cause has received a message that includes parameter not recognized because the parameters are defined but not implemented by the equipment sending the cause. The cause indicates that the parameters were ignored. In addition, if the equipment sending this cause is an intermediate point, then this cause indicates that the parameters were passed on unchanged.
This cause value can be contained in (and will trigger) a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 110 Message with unrecognized parameter discarded. This cause indicates that the equipment sending this cause has discarded a received message that includes a parameter that is not recognized.
This cause value can be contained in (and will trigger) a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 111 Protocol error, unspecified. This cause is used to report a protocol error event only when no other cause in the protocol error class applies.
This cause value can be contained in (and will trigger) a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ITU-T Q.850 Cause 127 Interworking, unspecified. This cause indicates that there has been interworking with a network that does not provide causes for actions it takes. Thus, the precise cause for a message which is being sent cannot be ascertained. This cause value will be send to the ISUP network whenever a 4xx or 5xx response is received with no Reason header containing an ANSI or Q.850 header value, and the 4xx or 5xx message does not directly map to an ANSI or Q.850 cause value.
This cause value can be contained in (and will trigger) a 480 Temporarily Unavailable response. The C-SCP is not expected to generate this cause value.

ANSI T1.113/2000 Cause 23 Unallocated destination number. This cause indicates failure of a business group call because the destination number is unallocated in the business group numbering plan.
This cause value can be contained in (and will trigger) a 404 Not Found response. The C-SCP is not expected to generate this cause value.
ANSI T1.113/2000 Cause 24 Unknown business group. This cause indicates failure of a business group call because the business group identifier is unknown.
This cause value can be contained in (and will trigger) a 404 Not Found response. The C-SCP is not expected to generate this cause value.
ANSI T1.113/2000 Cause 25 Exchange routing error. This cause indicates that the called party cannot be reached because of an error in exchange number translation tables used to route the call (results when the hop counter parameter value is decremented to 0).
This cause value will be used whenever a 483 Too Many Hops response or a 482 Loop Detected response is received. This cause value can be contained in a 483 Too Many Hops, 482 Loop Detected, or 480 Temporarily Unavailable response, and will trigger a 480 Temporarily Unavailable response.
ANSI T1.113/2000 Cause 26 Misrouted call to a ported number. This cause indicates that the called party cannot be reached because the "ported number" in the generic address parameter identifies a called party that is not served by the exchange.
This cause value can be contained in a 500 Server Internal Error response or a 404 Not Found response, and will trigger a 500 Server Internal Error response. The C-SCP must generate this cause value under appropriate conditions.
ANSI T1.113/2000 Cause 27 Number portability Query on Release (QoR) number not found. This cause value is not used in US networks.
This cause value can be contained in a 500 Server Internal Error response, and will trigger a 500 Server Internal Error response. The C-SCP must generate this cause value under appropriate conditions.
ANSI T1.113/2000 Cause 45 Preemption. This cause value is not used in US networks. This cause indicates that the equipment sending this cause has preempted the circuit for a new call and the existing call should be cleared.
This cause value can be contained in a 500 Server Internal Error response, and will trigger a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ANSI T1.113/2000 Cause 46 Precedence call blocked. This cause value is not used in US networks. In case of a call with a precedence level higher than the lowest level (ROUTINE), this cause indicates that all circuits are busy on calls of equal or higher priority.
This cause value can be contained in a 500 Server Internal Error response, and will trigger a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ANSI T1.113/2000 Cause 51 Call type incompatible with service request. This cause indicates that an action was rejected because it was not comaptible with the bearer capability of the call.
This cause value can be contained in a 500 Server Internal Error response, and will trigger a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.
ANSI T1.113/2000 Cause 54 Call blocked due to group restrictions. This cause indicates failure of a business group call because it did not pass line privileges and/or subgroup screening.
This cause value can be contained in a 500 Server Internal Error response, and will trigger a 500 Server Internal Error response. The C-SCP is not expected to generate this cause value.

B.1.2 Default SIP Response to Cause Value Mapping

When the Optranex 248 gateway switch receives a SIP 4xx, 5xx, or 6xx response to an INVITE message sent to the SIP network, and the Via headers do not indicate that the response was generated by the C-SCP platform, the SIP response will be mapped to a default cause value associated with the response type.

301 Moved Permanently The cause value ITU-T Q.850 Cause 22 Number changed will be assigned. It is not expected that the Optranex 248 switch will receive 3xx class messages. 3xx class messages should be intercepted by the Carrier Proxy.
302 Moved Temporarily The cause value ITU-T Q.850 Cause 23 Redirect to new destination will be assigned. Should the Contact header not be decipherable as a valid tel URI, the cause value ITU-T Q.850 Cause 1 Unallocated (unassigned) number will be assigned instead. It is not expected that the Optranex 248 switch will receive 3xx class messages. 3xx class messages should be intercepted by the Carrier Proxy.
3xx The cause value ITU-T Q.850 Cause 127 Interworking, unspecified will be assigned when an unrecognized 3xx message or a 3xx message for which no default is assigned is received. It is not expected that the Optranex 248 switch will receive 3xx class messages. 3xx class messages should be intercepted by the Carrier Proxy.
404 Not Found The cause value ITU-T Q.850 Cause 1 Unallocated (unassigned) number will be assigned.
410 Gone The cause value ITU-T Q.850 Cause 22 Number Changed will be assigned.
480 Temporarily Unavailable The cause value ITU-T Q.850 Cause 20 Subscriber absent or ITU-T Q.850 Cause 21 Call rejected will be assigned.
482 Loop Detected The cause value ITU-T Q.850 Cause 25 Exchange routing error will be assigned.
483 Too Many Hops The cause value ITU-T Q.850 Cause 25 Exchange routing error will be assigned.
484 Address Incomplete The cause value ITU-T Q.850 Cause 28 Invalid number format (address incomplete) will be assigned.
486 Busy Here The cause value ITU-T Q.850 Cause 17 User busy will be assigned.
488 Not Acceptable Here The cause value ITU-T Q.850 Cause 63 Service or option not available, unspecified will be assigned.
4xx The cause value ITU-T Q.850 Cause 127 Interworking, unspecified will be assigned when an unrecognized 4xx message or a 4xx message for which no default is assigned is received.
500 Server Internal Error The cause value ITU-T Q.850 Cause 38 Network out of order will be assigned.
502 Bad Gateway The cause value ITU-T Q.850 Cause 27 Destination out of order will be assigned.
503 Service Unavailable The cause value ITU-T Q.850 Cause 41 Temporary failure will be assigned.
5xx The cause value ITU-T Q.850 Cause 127 Interworking, unspecified will be assigned when an unrecognized 5xx message or a 5xx message for which no default is assigned is received.
603 Decline The cause value ITU-T Q.850 Cause 21 Call rejected will be assigned.
604 Does Not Exist Anywhere The cause value ITU-T Q.850 Cause 1 Unassigned (unallocated) number will be assigned.
606 Not Acceptable The cause value ITU-T Q.850 Cause 63 Service or option not available, unspecified will be assigned.
6xx The cause value ITU-T Q.850 Cause 127 Interworking, unspecified will be assigned when an unrecognized 6xx message or a 6xx message for which no default is assigned is received.

Appendix C Programmatic Interfaces

Appendix D Platform Sizing

Bibliography

Requests For Comment

RFC 3261, SIP: Session Initiation Protocol
RFC 3311, The SIP UPDATE Method
RFC 3372, Session Initiation Protocol (SIP) for Telephones (SIP-T): Context and Architectures
RFC 3398, Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping
RFC 3487, Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)
RFC 3666, Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows
RFC 3910, The SPIRITS (Services in PSTN requesting Internet Services) Protocol
RFC 3966, The tel URI for Telephone Numbers
RFC 4190, Framework for Supporting Emergency Telecommunications Services (ETS) in IP Telephony
RFC 4780, SIP MIB Modules
RFC 4904, Representing Trunk Groups in tel/sip Uniform Resource Identifiers (URIs)
RFC 4958, A Framework for Supporting Emergency Telecommunications Services (ETS) within a Single Administrative Domain
RFC 5118, Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6)
RFC 5411, The Hitchhiker’s Guide to the Session Initiation Protocol (SIP)
RFC 3263, Locating SIP Servers
RFC 3264, An Offer/Answer Model with the Session Description Protocol
RFC 3265, SIP-Specific Event Notification
RFC 3325, Private Extensions to SIP for Asserted Identity within Trusted Networks
RFC 3327, SIP Extension Header Field for Registering Non-Adjacent Contacts
RFC 3581, An Extension to SIP for Symmetric Response Routing
RFC 3840, Indicating User Agent Capabilities in SIP
RFC 4320, Actions Addressing Issues Identified with the Non-INVITE Transaction in SIP
RFC 4474, Enhancements for Authenticated Identity Management in SIP
RFC 4916, Connected Identity in the Session Initiation Protocol (SIP)
RFC 3311, The SIP UPDATE Method
RFC 3665, Session Initiation Protocol (SIP) Basic Call Flow Examples
RFC 2848, The PINT Service Protocol
RFC 3910, The SPIRITS Protocol
RFC 3372, SIP for Telephones (SIP-T)
RFC 3398, ISUP to SIP Mapping
RFC 4497, Interworking between the Session Initiation Protocol (SIP) and QSIG
RFC 3578, Mapping of ISUP Overlap Signaling to SIP
RFC 3960, Early Media and Ringtone Generation in SIP
RFC 5009, Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media
RFC 3959, Early Session Disposition Type for the Session Initiation Protocol (SIP)
RFC 3204, MIME Media Types for ISUP and QSIG Objects
RFC 3666, Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows
RFC 3262, Reliability of Provisional Responses in SIP
RFC 3323, A Privacy Mechanism for the Session Initiation Protocol (SIP)
RFC 2976, The INFO Method
RFC 3326, The Reason Header Field for SIP
RFC 3388, Grouping of Media Lines in the Session Description Protocol
RFC 3420, Internet Media Type message/sipfrag
RFC 3608, SIP Extension Header Field for Service Route Discovery During Registration
RFC 3841, Call Preferences for SIP
RFC 4028, Session Timers in SIP
RFC 4168, SCTP as a Transport for SIP
RFC 4244, An Extension to SIP for Request History Information
RFC 3515, The REFER Method
RFC 3725, Best Current Practices for Third Party Call Control
RFC 3911, The SIP Join Header Field
RFC 3891, The SIP Replaces Header
RFC 3892, The SIP Referred-By Mechanism
RFC 4117, Transcoding Services Invocation in SIP Using Third Party Call Control
RFC 4730, A SIP Event Package for Key Press Stimulus (KPML)
RFC 4733, RTP Payload for DTMF Digits, Telephone Tones, and Telephony Signals
RFC 3087, Control of Service Context using Request URI
RFC 4662, A SIP Event Notification Extension for Resource Lists
RFC 5363, Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services
RFC 5367, Subscriptions To Request-Contained Resource Lists in SIP
RFC 5365, Multiple-Recipient MESSAGE Requests in SIP
RFC 5366, Conference Establishment Using Request-Contained Lists in SIP
RFC 4240, Basic Network Media Services with SIP
RFC 4458, Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)
RFC 3312, Integration of resource management and Session Initiation Protocol (SIP)
RFC 3313, Private Session Initiation Protocol (SIP) Extensions for Media Authorization
RFC 3323, A Privacy Mechanism for the Session Initiation Protocol (SIP)
RFC 3325, Private Extensions to the Session Initiation Protocol (SIP) for Network Asserted Identity within Trusted Networks
RFC 3326, The Reason Header Field for the Session Initiation Protocol (SIP)
RFC 3329, Security Mechanism Agreement for the Session Initiation Protocol (SIP)
RFC 3455, Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd Generation Partnership Program (3GPP)
RFC 4032, Update to the Session Initiation Protocol (SIP) Preconditions Framework
RFC 3603, Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture
RFC 4457, The Session Initiation Protocol (SIP) P-User-Database Private-Header (P-header)
RFC 5002, The Session Initiation Protocol (SIP) P-Profile-Key Private Header (P-Header)
RFC 4967, Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier
RFC 5009, Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media
RFC 4964, The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular
RFC 4504, SIP Telephone Device Requirements
RFC 4694, Number Portablity Parameters for the "tel" URI
RFC 3824, Using E.164 Numbers with the Session Initiation Protocol (SIP)
RFC 3324, Short Term Requirements for Network Asserted Identity
RFC 2915, The Naming Authority Pointer (NAPTR) DNS Resource Record
RFC 2782, A DNS RR for specifying the location of services (DNS SRV)

Internet-Drafts

draft-patel-dispatch-cpc-oli-parameter-02, Uniform Resource Identifier (URI) Parameters for indicating the Calling Party’s Category and Originating Line Identity.
draft-yu-tel-dai-08, DAI Parameter for the "tel" URI
draft-johnston-sipping-cc-uui-08, Transporting User to User Information for Call Centers using SIP
draft-ietf-bliss-call-completion-05, Call Completion for Session Initiation Protocol (SIP)
draft-alexeitsev-bliss-alert-info-urns-02, Alert-Info header URNs for Session Initiation Protocol (SIP)
draft-jesske-dispatch-reason-in-reponses-01, Use of the Reason header field in Session Initiation Protocol (SIP) responses
rfc5626, Managing Client Initiated Connections in the Session Initiation Protocol (SIP)
draft-york-sipping-p-charge-info-07, P-Charge-Info - A Private Header (P-Header) Extension to the Session Initiation Protocol (SIP)
draft-ietf-sipping-update-pai-09, Updates to Asserted Identity in the the Session Initiation Protocol (SIP)
draft-ietf-speermint-srv-naptr-use-06, Use of DNS SRV and NAPTR Records for SPEERMINT

GSMA

IR.67 - DNS/ENUM Guidelnies for Service Providers & GRX/IPX Providers, Version 4.0, December 10, 2009, GSM Association.
IR.83 - SIP-I Interworking Description, Version 1.0, February 17, 2009, GSM Association.

SFF Comittee

INF-8074i, SFP (Small Formfactor Pluggable) Transciever MultiSource Agreement (MSA), Revision 1.0, May 12, 2001.
SFF-8075, PCI Card Version of SFP Cage, Revision 1.0, July 3, 2001.
SFF-8079, SFP Rate and Application Selection, Revision 1.7, February 2, 2005.
SFF-8089, SFP (Small Formfactor Pluggable) Rate and Application Codes, February 3, 2005.
SFF-8412, HSOI (High Speed Optical Interconnect) Measurement and Performance Requirements for Passive Optical Connections, Revision 12.2, June 18, 2003.
SFF-8431, Enhanced Small Form Factor Pluggable Module SFP+, Revision 4.1, July 6, 2009.
SFF-8432, Improved Pluggable Formfactor, Revision 5.0, July 16, 2007.
SFF-8433, Improved Pluggable Formfactor (IPF) for SFP+ Ganged Cages, Revision 0.7, June 5, 2009.
SFF-8439, SFP-S (System module), Revision 0.3, November 22, 2007.
SFF-8443, Stacked Cages for IPF Modules, Revision 0.1, March 31, 2008.
SFF-8461, SFP+ Active Cable Specifications and Alternate Test Methods, Revision 0.1, August 21, 2009.
SFF-8472, Diagnostic Monitoring Interface for Optical Transceivers, Revision 10.4, January 30, 2009.

Licenses

All code presented in this manual is licensed under the GNU Affero General Public License. The text of this manual is licensed under the GNU Free Documentation License, with no Invariant Sections, no Front-Cover Texts and no Back-Cover Texts. Please note, however, that it is just plain wrong to modify statements of, or attribute statements to, the Author, OpenSS7 Corporation, Monavacon Limited or Optranex Technologies Ltd.

GNU Affero General Public License

The GNU Affero General Public License.

Version 3, 19 November 2007

Copyright © 2007 Free Software Foundation, Inc. http://fsf.org/

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Preamble

The GNU Affero General Public License is a free, copyleft license for software and other kinds of works, specifically designed to ensure cooperation with the community in the case of network server software.

The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, our General Public Licenses are intended to guarantee your freedom to share and change all versions of a program–to make sure it remains free software for all its users.

When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things.

Developers that use our General Public Licenses protect your rights with two steps: (1) assert copyright on the software, and (2) offer you this License which gives you legal permission to copy, distribute and/or modify the software.

A secondary benefit of defending all users’ freedom is that improvements made in alternate versions of the program, if they receive widespread use, become available for other developers to incorporate. Many developers of free software are heartened and encouraged by the resulting cooperation. However, in the case of software used on network servers, this result may fail to come about. The GNU General Public License permits making a modified version and letting the public access it on a server without ever releasing its source code to the public.

The GNU Affero General Public License is designed specifically to ensure that, in such cases, the modified source code becomes available to the community. It requires the operator of a network server to provide the source code of the modified version running there to the users of that server. Therefore, public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version.

An older license, called the Affero General Public License and published by Affero, was designed to accomplish similar goals. This is a different license, not a version of the Affero GPL, but Affero has released a new version of the Affero GPL which permits relicensing under this license.

The precise terms and conditions for copying, distribution and modification follow.

TERMS AND CONDITIONS

Definitions.
“This License” refers to version 3 of the GNU Affero General Public License.

“Copyright” also means copyright-like laws that apply to other kinds of works, such as semiconductor masks.

“The Program” refers to any copyrightable work licensed under this License. Each licensee is addressed as “you”. “Licensees” and “recipients” may be individuals or organizations.

To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.

A “covered work” means either the unmodified Program or a work based on the Program.

To “propagate” a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.

To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.

An interactive user interface displays “Appropriate Legal Notices” to the extent that it includes a convenient and prominently visible feature that (1) displays an appropriate copyright notice, and (2) tells the user that there is no warranty for the work (except to the extent that warranties are provided), that licensees may convey the work under this License, and how to view a copy of this License. If the interface presents a list of user commands or options, such as a menu, a prominent item in the list meets this criterion.
Source Code.
The “source code” for a work means the preferred form of the work for making modifications to it. “Object code” means any non-source form of a work.

A “Standard Interface” means an interface that either is an official standard defined by a recognized standards body, or, in the case of interfaces specified for a particular programming language, one that is widely used among developers working in that language.

The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.

The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work’s System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.

The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source.

The Corresponding Source for a work in source code form is that same work.
Basic Permissions.
All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met. This License explicitly affirms your unlimited permission to run the unmodified Program. The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work. This License acknowledges your rights of fair use or other equivalent, as provided by copyright law.

You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force. You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you.

Conveying under any other circumstances is permitted solely under the conditions stated below. Sublicensing is not allowed; section 10 makes it unnecessary.
Protecting Users’ Legal Rights From Anti-Circumvention Law.
No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures.

When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work’s users, your or third parties’ legal rights to forbid circumvention of technological measures.
Conveying Verbatim Copies.
You may convey verbatim copies of the Program’s source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all notices stating that this License and any non-permissive terms added in accord with section 7 apply to the code; keep intact all notices of the absence of any warranty; and give all recipients a copy of this License along with the Program.

You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee.
Conveying Modified Source Versions.
You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:
1. The work must carry prominent notices stating that you modified it, and giving a relevant date.
2. The work must carry prominent notices stating that it is released under this License and any conditions added under section 7. This requirement modifies the requirement in section 4 to “keep intact all notices”.
3. You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
4. If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so.
A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation’s users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
Conveying Non-Source Forms.
You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:
1. Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.
2. Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.
3. Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b.
4. Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.
5. Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d.
A separable portion of the object code, whose source code is excluded from the Corresponding Source as a System Library, need not be included in conveying the object code work.

A “User Product” is either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling. In determining whether a product is a consumer product, doubtful cases shall be resolved in favor of coverage. For a particular product received by a particular user, “normally used” refers to a typical or common use of that class of product, regardless of the status of the particular user or of the way in which the particular user actually uses, or expects or is expected to use, the product. A product is a consumer product regardless of whether the product has substantial commercial, industrial or non-consumer uses, unless such uses represent the only significant mode of use of the product.

“Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.

If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).

The requirement to provide Installation Information does not include a requirement to continue to provide support service, warranty, or updates for a work that has been modified or installed by the recipient, or for the User Product in which it has been modified or installed. Access to a network may be denied when the modification itself materially and adversely affects the operation of the network or violates the rules and protocols for communication across the network.

Corresponding Source conveyed, and Installation Information provided, in accord with this section must be in a format that is publicly documented (and with an implementation available to the public in source code form), and must require no special password or key for unpacking, reading or copying.
Additional Terms.
“Additional permissions” are terms that supplement the terms of this License by making exceptions from one or more of its conditions. Additional permissions that are applicable to the entire Program shall be treated as though they were included in this License, to the extent that they are valid under applicable law. If additional permissions apply only to part of the Program, that part may be used separately under those permissions, but the entire Program remains governed by this License without regard to the additional permissions.

When you convey a copy of a covered work, you may at your option remove any additional permissions from that copy, or from any part of it. (Additional permissions may be written to require their own removal in certain cases when you modify the work.) You may place additional permissions on material, added by you to a covered work, for which you have or can give appropriate copyright permission.

Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms:
1. Disclaiming warranty or limiting liability differently from the terms of sections 15 and 16 of this License; or
2. Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or
3. Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or
4. Limiting the use for publicity purposes of names of licensors or authors of the material; or
5. Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or
6. Requiring indemnification of licensors and authors of that material by anyone who conveys the material (or modified versions of it) with contractual assumptions of liability to the recipient, for any liability that these contractual assumptions directly impose on those licensors and authors.
All other non-permissive additional terms are considered “further restrictions” within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term. If a license document contains a further restriction but permits relicensing or conveying under this License, you may add to a covered work material governed by the terms of that license document, provided that the further restriction does not survive such relicensing or conveying.

If you add terms to a covered work in accord with this section, you must place, in the relevant source files, a statement of the additional terms that apply to those files, or a notice indicating where to find the applicable terms.

Additional terms, permissive or non-permissive, may be stated in the form of a separately written license, or stated as exceptions; the above requirements apply either way.
Termination.
You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License (including any patent licenses granted under the third paragraph of section 11).

However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation.

Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.

Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License. If your rights have been terminated and not permanently reinstated, you do not qualify to receive new licenses for the same material under section 10.
Acceptance Not Required for Having Copies.
You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so.
Automatic Licensing of Downstream Recipients.
Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License. You are not responsible for enforcing compliance by third parties with this License.

An “entity transaction” is a transaction transferring control of an organization, or substantially all assets of one, or subdividing an organization, or merging organizations. If propagation of a covered work results from an entity transaction, each party to that transaction who receives a copy of the work also receives whatever licenses to the work the party’s predecessor in interest had or could give under the previous paragraph, plus a right to possession of the Corresponding Source of the work from the predecessor in interest, if the predecessor has it or can get it with reasonable efforts.

You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it.
Patents.
A “contributor” is a copyright holder who authorizes use under this License of the Program or a work on which the Program is based. The work thus licensed is called the contributor’s “contributor version”.

A contributor’s “essential patent claims” are all patent claims owned or controlled by the contributor, whether already acquired or hereafter acquired, that would be infringed by some manner, permitted by this License, of making, using, or selling its contributor version, but do not include claims that would be infringed only as a consequence of further modification of the contributor version. For purposes of this definition, “control” includes the right to grant patent sublicenses in a manner consistent with the requirements of this License.

Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor’s essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version.

In the following three paragraphs, a “patent license” is any express agreement or commitment, however denominated, not to enforce a patent (such as an express permission to practice a patent or covenant not to sue for patent infringement). To “grant” such a patent license to a party means to make such an agreement or commitment not to enforce a patent against the party.

If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means, then you must either (1) cause the Corresponding Source to be so available, or (2) arrange to deprive yourself of the benefit of the patent license for this particular work, or (3) arrange, in a manner consistent with the requirements of this License, to extend the patent license to downstream recipients. “Knowingly relying” means you have actual knowledge that, but for the patent license, your conveying the covered work in a country, or your recipient’s use of the covered work in a country, would infringe one or more identifiable patents in that country that you have reason to believe are valid.

If, pursuant to or in connection with a single transaction or arrangement, you convey, or propagate by procuring conveyance of, a covered work, and grant a patent license to some of the parties receiving the covered work authorizing them to use, propagate, modify or convey a specific copy of the covered work, then the patent license you grant is automatically extended to all recipients of the covered work and works based on it.

A patent license is “discriminatory” if it does not include within the scope of its coverage, prohibits the exercise of, or is conditioned on the non-exercise of one or more of the rights that are specifically granted under this License. You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license (a) in connection with copies of the covered work conveyed by you (or copies made from those copies), or (b) primarily for and in connection with specific products or compilations that contain the covered work, unless you entered into that arrangement, or that patent license was granted, prior to 28 March 2007.

Nothing in this License shall be construed as excluding or limiting any implied license or other defenses to infringement that may otherwise be available to you under applicable patent law.
No Surrender of Others’ Freedom.
If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot convey a covered work so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not convey it at all. For example, if you agree to terms that obligate you to collect a royalty for further conveying from those to whom you convey the Program, the only way you could satisfy both those terms and this License would be to refrain entirely from conveying the Program.
Remote Network Interaction; Use with the GNU General Public License.
Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.

Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License.
Revised Versions of this License.
The Free Software Foundation may publish revised and/or new versions of the GNU Affero General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU Affero General Public License “or any later version” applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the GNU Affero General Public License, you may choose any version ever published by the Free Software Foundation.

If the Program specifies that a proxy can decide which future versions of the GNU Affero General Public License can be used, that proxy’s public statement of acceptance of a version permanently authorizes you to choose that version for the Program.

Later license versions may give you additional or different permissions. However, no additional obligations are imposed on any author or copyright holder as a result of your choosing to follow a later version.
Disclaimer of Warranty.
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
Limitation of Liability.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Interpretation of Sections 15 and 16.
If the disclaimer of warranty and limitation of liability provided above cannot be given local legal effect according to their terms, reviewing courts shall apply local law that most closely approximates an absolute waiver of all civil liability in connection with the Program, unless a warranty or assumption of liability accompanies a copy of the Program in return for a fee.

END OF TERMS AND CONDITIONS

How to Apply These Terms to Your New Programs

If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.

To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively state the exclusion of warranty; and each file should have at least the “copyright” line and a pointer to where the full notice is found.

one line to give the program's name and a brief idea of what it does.
Copyright (C) year name of author

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU Affero General Public License as published by
the Free Software Foundation, either version 3 of the License, or (at
your option) any later version.

This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License
along with this program.  If not, see http://www.gnu.org/licenses/.

Also add information on how to contact you by electronic and paper mail.

If your software can interact with users remotely through a network, you should also make sure that it provides a way for users to get its source. For example, if your program is a web application, its interface could display a “Source” link that leads users to an archive of the code. There are many ways you could offer source, and different solutions will be better for different programs; see section 13 for the specific requirements.

You should also get your employer (if you work as a programmer) or school, if any, to sign a “copyright disclaimer” for the program, if necessary. For more information on this, and how to apply and follow the GNU AGPL, see http://www.gnu.org/licenses/.

GNU General Public License

GNU GENERAL PUBLIC LICENSE

Version 3, 29 June 2007

Copyright © 2007 Free Software Foundation, Inc. http://fsf.org/

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Preamble

The GNU General Public License is a free, copyleft license for software and other kinds of works.

The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program–to make sure it remains free software for all its users. We, the Free Software Foundation, use the GNU General Public License for most of our software; it applies also to any other work released this way by its authors. You can apply it to your programs, too.

To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others.

For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.

Developers that use the GNU GPL protect your rights with two steps: (1) assert copyright on the software, and (2) offer you this License giving you legal permission to copy, distribute and/or modify it.

For the developers’ and authors’ protection, the GPL clearly explains that there is no warranty for this free software. For both users’ and authors’ sake, the GPL requires that modified versions be marked as changed, so that their problems will not be attributed erroneously to authors of previous versions.

Some devices are designed to deny users access to install or run modified versions of the software inside them, although the manufacturer can do so. This is fundamentally incompatible with the aim of protecting users’ freedom to change the software. The systematic pattern of such abuse occurs in the area of products for individuals to use, which is precisely where it is most unacceptable. Therefore, we have designed this version of the GPL to prohibit the practice for those products. If such problems arise substantially in other domains, we stand ready to extend this provision to those domains in future versions of the GPL, as needed to protect the freedom of users.

Finally, every program is threatened constantly by software patents. States should not allow patents to restrict development and use of software on general-purpose computers, but in those that do, we wish to avoid the special danger that patents applied to a free program could make it effectively proprietary. To prevent this, the GPL assures that patents cannot be used to render the program non-free.

The precise terms and conditions for copying, distribution and modification follow.

TERMS AND CONDITIONS

Definitions.
“This License” refers to version 3 of the GNU General Public License.

“Copyright” also means copyright-like laws that apply to other kinds of works, such as semiconductor masks.

“The Program” refers to any copyrightable work licensed under this License. Each licensee is addressed as “you”. “Licensees” and “recipients” may be individuals or organizations.

To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.

A “covered work” means either the unmodified Program or a work based on the Program.

To “propagate” a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.

To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.

An interactive user interface displays “Appropriate Legal Notices” to the extent that it includes a convenient and prominently visible feature that (1) displays an appropriate copyright notice, and (2) tells the user that there is no warranty for the work (except to the extent that warranties are provided), that licensees may convey the work under this License, and how to view a copy of this License. If the interface presents a list of user commands or options, such as a menu, a prominent item in the list meets this criterion.
Source Code.
The “source code” for a work means the preferred form of the work for making modifications to it. “Object code” means any non-source form of a work.

A “Standard Interface” means an interface that either is an official standard defined by a recognized standards body, or, in the case of interfaces specified for a particular programming language, one that is widely used among developers working in that language.

The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.

The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work’s System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.

The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source.

The Corresponding Source for a work in source code form is that same work.
Basic Permissions.
All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met. This License explicitly affirms your unlimited permission to run the unmodified Program. The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work. This License acknowledges your rights of fair use or other equivalent, as provided by copyright law.

You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force. You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you.

Conveying under any other circumstances is permitted solely under the conditions stated below. Sublicensing is not allowed; section 10 makes it unnecessary.
Protecting Users’ Legal Rights From Anti-Circumvention Law.
No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures.

When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work’s users, your or third parties’ legal rights to forbid circumvention of technological measures.
Conveying Verbatim Copies.
You may convey verbatim copies of the Program’s source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all notices stating that this License and any non-permissive terms added in accord with section 7 apply to the code; keep intact all notices of the absence of any warranty; and give all recipients a copy of this License along with the Program.

You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee.
Conveying Modified Source Versions.
You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:
1. The work must carry prominent notices stating that you modified it, and giving a relevant date.
2. The work must carry prominent notices stating that it is released under this License and any conditions added under section 7. This requirement modifies the requirement in section 4 to “keep intact all notices”.
3. You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
4. If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so.
A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation’s users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
Conveying Non-Source Forms.
You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:
1. Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.
2. Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.
3. Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b.
4. Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.
5. Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d.
A separable portion of the object code, whose source code is excluded from the Corresponding Source as a System Library, need not be included in conveying the object code work.

A “User Product” is either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling. In determining whether a product is a consumer product, doubtful cases shall be resolved in favor of coverage. For a particular product received by a particular user, “normally used” refers to a typical or common use of that class of product, regardless of the status of the particular user or of the way in which the particular user actually uses, or expects or is expected to use, the product. A product is a consumer product regardless of whether the product has substantial commercial, industrial or non-consumer uses, unless such uses represent the only significant mode of use of the product.

“Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.

If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).

The requirement to provide Installation Information does not include a requirement to continue to provide support service, warranty, or updates for a work that has been modified or installed by the recipient, or for the User Product in which it has been modified or installed. Access to a network may be denied when the modification itself materially and adversely affects the operation of the network or violates the rules and protocols for communication across the network.

Corresponding Source conveyed, and Installation Information provided, in accord with this section must be in a format that is publicly documented (and with an implementation available to the public in source code form), and must require no special password or key for unpacking, reading or copying.
Additional Terms.
“Additional permissions” are terms that supplement the terms of this License by making exceptions from one or more of its conditions. Additional permissions that are applicable to the entire Program shall be treated as though they were included in this License, to the extent that they are valid under applicable law. If additional permissions apply only to part of the Program, that part may be used separately under those permissions, but the entire Program remains governed by this License without regard to the additional permissions.

When you convey a copy of a covered work, you may at your option remove any additional permissions from that copy, or from any part of it. (Additional permissions may be written to require their own removal in certain cases when you modify the work.) You may place additional permissions on material, added by you to a covered work, for which you have or can give appropriate copyright permission.

Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms:
1. Disclaiming warranty or limiting liability differently from the terms of sections 15 and 16 of this License; or
2. Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or
3. Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or
4. Limiting the use for publicity purposes of names of licensors or authors of the material; or
5. Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or
6. Requiring indemnification of licensors and authors of that material by anyone who conveys the material (or modified versions of it) with contractual assumptions of liability to the recipient, for any liability that these contractual assumptions directly impose on those licensors and authors.
All other non-permissive additional terms are considered “further restrictions” within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term. If a license document contains a further restriction but permits relicensing or conveying under this License, you may add to a covered work material governed by the terms of that license document, provided that the further restriction does not survive such relicensing or conveying.

If you add terms to a covered work in accord with this section, you must place, in the relevant source files, a statement of the additional terms that apply to those files, or a notice indicating where to find the applicable terms.

Additional terms, permissive or non-permissive, may be stated in the form of a separately written license, or stated as exceptions; the above requirements apply either way.
Termination.
You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License (including any patent licenses granted under the third paragraph of section 11).

However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation.

Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.

Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License. If your rights have been terminated and not permanently reinstated, you do not qualify to receive new licenses for the same material under section 10.
Acceptance Not Required for Having Copies.
You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so.
Automatic Licensing of Downstream Recipients.
Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License. You are not responsible for enforcing compliance by third parties with this License.

An “entity transaction” is a transaction transferring control of an organization, or substantially all assets of one, or subdividing an organization, or merging organizations. If propagation of a covered work results from an entity transaction, each party to that transaction who receives a copy of the work also receives whatever licenses to the work the party’s predecessor in interest had or could give under the previous paragraph, plus a right to possession of the Corresponding Source of the work from the predecessor in interest, if the predecessor has it or can get it with reasonable efforts.

You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it.
Patents.
A “contributor” is a copyright holder who authorizes use under this License of the Program or a work on which the Program is based. The work thus licensed is called the contributor’s “contributor version”.

A contributor’s “essential patent claims” are all patent claims owned or controlled by the contributor, whether already acquired or hereafter acquired, that would be infringed by some manner, permitted by this License, of making, using, or selling its contributor version, but do not include claims that would be infringed only as a consequence of further modification of the contributor version. For purposes of this definition, “control” includes the right to grant patent sublicenses in a manner consistent with the requirements of this License.

Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor’s essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version.

In the following three paragraphs, a “patent license” is any express agreement or commitment, however denominated, not to enforce a patent (such as an express permission to practice a patent or covenant not to sue for patent infringement). To “grant” such a patent license to a party means to make such an agreement or commitment not to enforce a patent against the party.

If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means, then you must either (1) cause the Corresponding Source to be so available, or (2) arrange to deprive yourself of the benefit of the patent license for this particular work, or (3) arrange, in a manner consistent with the requirements of this License, to extend the patent license to downstream recipients. “Knowingly relying” means you have actual knowledge that, but for the patent license, your conveying the covered work in a country, or your recipient’s use of the covered work in a country, would infringe one or more identifiable patents in that country that you have reason to believe are valid.

If, pursuant to or in connection with a single transaction or arrangement, you convey, or propagate by procuring conveyance of, a covered work, and grant a patent license to some of the parties receiving the covered work authorizing them to use, propagate, modify or convey a specific copy of the covered work, then the patent license you grant is automatically extended to all recipients of the covered work and works based on it.

A patent license is “discriminatory” if it does not include within the scope of its coverage, prohibits the exercise of, or is conditioned on the non-exercise of one or more of the rights that are specifically granted under this License. You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license (a) in connection with copies of the covered work conveyed by you (or copies made from those copies), or (b) primarily for and in connection with specific products or compilations that contain the covered work, unless you entered into that arrangement, or that patent license was granted, prior to 28 March 2007.

Nothing in this License shall be construed as excluding or limiting any implied license or other defenses to infringement that may otherwise be available to you under applicable patent law.
No Surrender of Others’ Freedom.
If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot convey a covered work so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not convey it at all. For example, if you agree to terms that obligate you to collect a royalty for further conveying from those to whom you convey the Program, the only way you could satisfy both those terms and this License would be to refrain entirely from conveying the Program.
Use with the GNU Affero General Public License.
Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU Affero General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the special requirements of the GNU Affero General Public License, section 13, concerning interaction through a network will apply to the combination as such.
Revised Versions of this License.
The Free Software Foundation may publish revised and/or new versions of the GNU General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU General Public License “or any later version” applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation.

If the Program specifies that a proxy can decide which future versions of the GNU General Public License can be used, that proxy’s public statement of acceptance of a version permanently authorizes you to choose that version for the Program.

Later license versions may give you additional or different permissions. However, no additional obligations are imposed on any author or copyright holder as a result of your choosing to follow a later version.
Disclaimer of Warranty.
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
Limitation of Liability.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Interpretation of Sections 15 and 16.
If the disclaimer of warranty and limitation of liability provided above cannot be given local legal effect according to their terms, reviewing courts shall apply local law that most closely approximates an absolute waiver of all civil liability in connection with the Program, unless a warranty or assumption of liability accompanies a copy of the Program in return for a fee.

END OF TERMS AND CONDITIONS

How to Apply These Terms to Your New Programs

one line to give the program's name and a brief idea of what it does.
Copyright (C) year name of author

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or (at
your option) any later version.

This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see http://www.gnu.org/licenses/.

Also add information on how to contact you by electronic and paper mail.

If the program does terminal interaction, make it output a short notice like this when it starts in an interactive mode:

program Copyright (C) year name of author
This program comes with ABSOLUTELY NO WARRANTY; for details type ‘show w’.
This is free software, and you are welcome to redistribute it
under certain conditions; type ‘show c’ for details.

The hypothetical commands ‘show w’ and ‘show c’ should show the appropriate parts of the General Public License. Of course, your program’s commands might be different; for a GUI interface, you would use an “about box”.

The GNU General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License. But first, please read http://www.gnu.org/philosophy/why-not-lgpl.html.

GNU Lesser General Public License Version 2.1

GNU LESSER GENERAL PUBLIC LICENSE

Version 2.1, February 1999

Copyright © 1991, 1999 Free Software Foundation, Inc.
59 Temple Place – Suite 330, Boston, MA 02111-1307, USA

Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.

[This is the first released version of the Lesser GPL.  It also counts
as the successor of the GNU Library Public License, version 2, hence the
version number 2.1.]

Preamble

The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software—to make sure the software is free for all its users.

This license, the Lesser General Public License, applies to some specially designated software—typically libraries—of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below.

When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things.

To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it.

For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights.

We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library.

To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author’s reputation will not be affected by problems that might be introduced by others.

Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license.

Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs.

When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library.

We call this license the Lesser General Public License because it does Less to protect the user’s freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances.

For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License.

In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system.

Although the Lesser General Public License is Less protective of the users’ freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library.

The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a “work based on the library” and a “work that uses the library”. The former contains code derived from the library, whereas the latter must be combined with the library in order to run.

TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION

This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called “this License”). Each licensee is addressed as “you”.
A “library” means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables.

The “Library”, below, refers to any such software library or work which has been distributed under these terms. A “work based on the Library” means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term “modification”.)

“Source code” for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library.

Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does.
You may copy and distribute verbatim copies of the Library’s complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library.
You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.
You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
1. The modified work must itself be a software library.
2. You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change.
3. You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License.
4. If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful.
  (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.)
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library.

In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices.
Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy.

This option is useful when you wish to copy part of the code of the Library into a program that is not a library.
You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange.
If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code.
A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a “work that uses the Library”. Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
However, linking a “work that uses the Library” with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a “work that uses the library”. The executable is therefore covered by this License. Section 6 states terms for distribution of such executables.

When a “work that uses the Library” uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law.

If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.)

Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself.
As an exception to the Sections above, you may also combine or link a “work that uses the Library” with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer’s own use and reverse engineering for debugging such modifications.
You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things:
1. Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable “work that uses the Library”, as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.)
2. Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user’s computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with.
3. Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution.
4. If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place.
5. Verify that the user has already received a copy of these materials or that you have already sent this user a copy.
For an executable, the required form of the “work that uses the Library” must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute.
You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things:
1. Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above.
2. Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work.
You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it.
Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients’ exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License.
If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library.
If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances.

It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.

This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.
If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.
The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and “any later version”, you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation.
If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.
NO WARRANTY
BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

END OF TERMS AND CONDITIONS

How to Apply These Terms to Your New Libraries

If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License).

To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the “copyright” line and a pointer to where the full notice is found.

one line to give the library's name and an idea of what it does.
Copyright (C) year  name of author

This library is free software; you can redistribute it and/or modify it
under the terms of the GNU Lesser General Public License as published by
the Free Software Foundation; either version 2.1 of the License, or (at
your option) any later version.

This library is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307,
USA.

Also add information on how to contact you by electronic and paper mail.

You should also get your employer (if you work as a programmer) or your school, if any, to sign a “copyright disclaimer” for the library, if necessary. Here is a sample; alter the names:

Yoyodyne, Inc., hereby disclaims all copyright interest in the library
`Frob' (a library for tweaking knobs) written by James Random Hacker.

signature of Ty Coon, 1 April 1990
Ty Coon, President of Vice

That’s all there is to it!

GNU Free Documentation License

GNU FREE DOCUMENTATION LICENSE

Version 1.3, 3 November 2008

Copyright © 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
http://fsf.org/

Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.

PREAMBLE
The purpose of this License is to make a manual, textbook, or other functional and useful document free in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.

This License is a kind of “copyleft”, which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.

We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.
APPLICABILITY AND DEFINITIONS
This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The “Document”, below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as “you”. You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.

A “Modified Version” of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A “Secondary Section” is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document’s overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The “Invariant Sections” are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.

The “Cover Texts” are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.

A “Transparent” copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not “Transparent” is called “Opaque”.

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.

The “Title Page” means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, “Title Page” means the text near the most prominent appearance of the work’s title, preceding the beginning of the body of the text.

The “publisher” means any person or entity that distributes copies of the Document to the public.

A section “Entitled XYZ” means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as “Acknowledgements”, “Dedications”, “Endorsements”, or “History”.) To “Preserve the Title” of such a section when you modify the Document means that it remains a section “Entitled XYZ” according to this definition.

The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.
VERBATIM COPYING
You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies.
COPYING IN QUANTITY
If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document’s license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.
MODIFICATIONS
You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:
1. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.
2. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement.
3. State on the Title page the name of the publisher of the Modified Version, as the publisher.
4. Preserve all the copyright notices of the Document.
5. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.
6. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.
7. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document’s license notice.
8. Include an unaltered copy of this License.
9. Preserve the section Entitled “History”, Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled “History” in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.
10. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the “History” section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.
11. For any section Entitled “Acknowledgements” or “Dedications”, Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.
12. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.
13. Delete any section Entitled “Endorsements”. Such a section may not be included in the Modified Version.
14. Do not retitle any existing section to be Entitled “Endorsements” or to conflict in title with any Invariant Section.
15. Preserve any Warranty Disclaimers.
If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version’s license notice. These titles must be distinct from any other section titles.

You may add a section Entitled “Endorsements”, provided it contains nothing but endorsements of your Modified Version by various parties—for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.
COMBINING DOCUMENTS
You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.

The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections Entitled “History” in the various original documents, forming one section Entitled “History”; likewise combine any sections Entitled “Acknowledgements”, and any sections Entitled “Dedications”. You must delete all sections Entitled “Endorsements.”
COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.
AGGREGATION WITH INDEPENDENT WORKS
A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an “aggregate” if the copyright resulting from the compilation is not used to limit the legal rights of the compilation’s users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document’s Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.
TRANSLATION
Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.

If a section in the Document is Entitled “Acknowledgements”, “Dedications”, or “History”, the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.
TERMINATION
You may not copy, modify, sublicense, or distribute the Document except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, or distribute it is void, and will automatically terminate your rights under this License.

However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation.

Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.

Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License. If your rights have been terminated and not permanently reinstated, receipt of a copy of some or all of the same material does not give you any rights to use it.
FUTURE REVISIONS OF THIS LICENSE
The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License “or any later version” applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. If the Document specifies that a proxy can decide which future versions of this License can be used, that proxy’s public statement of acceptance of a version permanently authorizes you to choose that version for the Document.
RELICENSING
“Massive Multiauthor Collaboration Site” (or “MMC Site”) means any World Wide Web server that publishes copyrightable works and also provides prominent facilities for anybody to edit those works. A public wiki that anybody can edit is an example of such a server. A “Massive Multiauthor Collaboration” (or “MMC”) contained in the site means any set of copyrightable works thus published on the MMC site.

“CC-BY-SA” means the Creative Commons Attribution-Share Alike 3.0 license published by Creative Commons Corporation, a not-for-profit corporation with a principal place of business in San Francisco, California, as well as future copyleft versions of that license published by that same organization.

“Incorporate” means to publish or republish a Document, in whole or in part, as part of another Document.

An MMC is “eligible for relicensing” if it is licensed under this License, and if all works that were first published under this License somewhere other than this MMC, and subsequently incorporated in whole or in part into the MMC, (1) had no cover texts or invariant sections, and (2) were thus incorporated prior to November 1, 2008.

The operator of an MMC Site may republish an MMC contained in the site under CC-BY-SA on the same site at any time before August 1, 2009, provided the MMC is eligible for relicensing.

ADDENDUM: How to use this License for your documents

To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:

  Copyright (C)  year  your name.
  Permission is granted to copy, distribute and/or modify this document
  under the terms of the GNU Free Documentation License, Version 1.3
  or any later version published by the Free Software Foundation;
  with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
  Texts.  A copy of the license is included in the section entitled ``GNU
  Free Documentation License''.

If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the “with…Texts.” line with this:

    with the Invariant Sections being list their titles, with
    the Front-Cover Texts being list, and with the Back-Cover Texts
    being list.

If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.

If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.

Index

Jump to:	A D H I L M N P R S T

	Index Entry	Section

A
	Alternate Hardware:	Alternate Hardware
	Application architecture:	Application Architecture

D
	Document abstract:	Preface
	Document audience:	Preface
	Document disclaimer:	Preface
	Document information:	Preface
	Document intent:	Preface
	Document objective:	Preface
	Document organization:	Preface
	Document revisions:	Preface

H
	Hardware architecture:	Hardware Architecture

I
	Introduction:	Introduction

L
	license, AGPL:	GNU Affero General Public License
	license, FDL:	GNU Free Documentation License
	license, GNU Affero General Public License:	GNU Affero General Public License
	license, GNU Free Documentation License:	GNU Free Documentation License
	license, GNU General Public License:	GNU General Public License
	license, GPL:	GNU General Public License
	license, Lesser General Public License Version 2.1:	GNU Lesser General Public License Version 2.1
	license, LGPL v2.1:	GNU Lesser General Public License Version 2.1
	Logistics:	Logistics

M
	Management architecture:	Management Architecture

N
	Network architecture:	Network Architecture

P
	Platform architecture:	Platform Architecture
	Platform sizing:	Platform Sizing
	Programmatic interfaces:	Programmatic Interfaces
	Project drivers:	Project Drivers
	Project gates:	Gates
	Project objectives:	Project Drivers
	Project phases:	Phases
	Protocol architecture:	Protocol Architecture
	Protocol values:	Protocol Values
	Provisioning plan:	Provisioning Plan

R
	Reference architecture:	Reference Architecture

S
	Scope:	Scope
	Software architecture:	Software Architecture
	Solution architecture:	Solution Architecture
	System architecture:	System Architecture

T
	Test plan:	Test Plan
	The Optranex 248 PSTN Gateway:	The Optranex 248 PSTN Gateway

Jump to:	A D H I L M N P R S T

Short Table of Contents

Executive Overview
Preface
- Document Information
- Document Organization
1 Introduction
- 1.1 The Optranex 248 PSTN Gateway
- 1.2 Project Drivers
  - 1.2.1 Project Objectives
- 1.3 Scope
  - 1.3.1 Phases
  - 1.3.2 Gates
2 Application Architecture
- 2.1 Application Requirements
3 Solution Architecture
- 3.1 Optranex 248 PSTN Gateway Deployment
- 3.2 Distinguishing Features
- 3.3 Call Flows
4 Network Architecture
- 4.1 Ethernet Connections
- 4.2 SONET/SDH Connections
5 Reference Architecture
6 Protocol Architecture
- 6.1 C-SCP Interworking Call Flows
- 6.2 Calls from PSTN to SIP
- 6.3 Calls from SIP to PSTN
- 6.4 ENUM Calls from PSTN to SIP
  - 6.4.1 ENUM Call Flows from PSTN to SIP
    - 6.4.1.1 Successful ENUM Call Flow from PSTN to SIP
    - 6.4.1.2 Unsuccessful ENUM Call Flow from PSTN to SIP
- 6.5 ENUM Calls from SIP to PSTN
  - 6.5.1 ENUM Call Flow from SIP to PSTN
    - 6.5.1.1 ENUM Tables (DNS Zones)
7 Software Architecture
- 7.1 General Software Architecture
- 7.2 SIP to ISUP Interworking
- 7.3 Carrier Proxy
8 Hardware Architecture
- 8.1 Power and Cooling
  - 8.1.1 Grounding
- 8.2 Mounting
- 8.3 Ethernet Network Interfaces
- 8.4 SONET/SDH Network Interfaces
  - 8.4.1 Small Formfactor Pluggable Modules
9 Platform Architecture
- 9.1 Inter-Server Chassis Cabling
  - 9.1.1 SMA Cables
  - 9.1.2 SFP Loop-back Cables
- 9.2 Spares
10 Management Architecture
- 10.1 Local Alarms
- 10.2 Remote Management
- 10.3 SNMP Management
  - 10.3.1 OpenSS7 Management Information Bases
11 System Architecture
12 Logistics
- 12.1 Site Preparation
- 12.2 Equipment List
- 12.3 Installation
- 12.4 Spares
- 12.5 Schedule
13 Provisioning Plan
- 13.1 SONET Segment Assignments
- 13.2 SONET Path Assignments
- 13.3 SIGTRAN Signaling Gateway Additions
- 13.4 PSTN Signaling Point Additions
- 13.5 PSTN Signaling Relation Additions
- 13.6 SIP Proxy Additions
- 13.7 PSTN Trunk Group Addtions
- 13.8 PSTN Route Additions
- 13.9 PSTN Circuit Group Additions
- 13.10 PSTN Circuit Additions
- 13.11 PSTN Virtual Trunk Group Additions
- 13.12 SIP Virtual Trunk Group Additions
14 Test Plan
- 14.1 OpenSIPS
- 14.2 Optranex
- 14.3 C-SCP
- 14.4 Outgoing Calls
- 14.5 Incoming Calls
Appendix A Alternate Hardware
- A.1 Alternate SFP Modules
Appendix B Protocol Values
- B.1 Cause Values
  - B.1.1 Cause Value to SIP Response Mapping
  - B.1.2 Default SIP Response to Cause Value Mapping
Appendix C Programmatic Interfaces
Appendix D Platform Sizing
Bibliography
- Requests For Comment
- Internet-Drafts
- GSMA
- SFF Comittee
Licenses
- GNU Affero General Public License
  - Preamble
  - How to Apply These Terms to Your New Programs
- GNU General Public License
  - Preamble
  - How to Apply These Terms to Your New Programs
- GNU Lesser General Public License Version 2.1
  - Preamble
  - How to Apply These Terms to Your New Libraries
- GNU Free Documentation License
Index

Footnotes

(1)

Although some reference is made to capabilities supporting other phases, Phase 1 and Phase 2 are the focus of this document.

(2)

This document is a High-Level Design an Proposal document and it meets the internal requirements for passing Gate 1 of Phase 1 and Phase 2 of the VoIP GW project. An external review of this document by a Beta or Gamma client or sponsor is pending.

(3)

OpenSS7 requires a contractual commitment for purchase from a Beta or Gamma client, or funding from a Sponsor of the OpenSS7 Project, before this gate can be passed and development started.

(4)

See High Density SONET/SDH MG Interface for VoIP Trunking, B. Bidulock, April 24, 2009.

(5)

This section is not intended as a Detailed Design, but provides illustration only for these Application Notes. Refer to RFC XXXX for detailed information.

(6)

Shielded twisted pair (STP) is required for NEBS-3 compliance and the server chassis ports are designed to work with STP cable; however, the servers will operate with unshielded twisted pair (UTP) cable.

(7)

Again, STP is required for NEBS-3 compliants but UTP will function.

(8)

18 octets of Ethernet packet overhead, 4 octets of VLAN packet overhead, 20 octets of IPv4 header overhead, 16 octets of SCTP packet overhead, 8 octets of DATA chunk overhead, 12 octets of M3UA overhead.

(9)

If the optional 10Gig Ethernet connectivity is provided, this interface would require 4 separate IP address for the one interface.

(10)

Note that if the entire OC-12 were to be utilitized during the trial, the number of channels could increase by a factor of four to 8064, giving 1.833 Gbps of RTP traffic at 10ms packetization or 1.3 Gbps of RTP traffic at 30ms packetization.

(11)

Note that currently the Carrier Proxy is envisioned as being coexistent with the C-SCP.

(12)

Increasing the capacity at trial to the full OC-12 would not increase the customer SIP signaling bandwidth to significant levels.

(13)

(14)

I would prefer to avoid this unless absolutely necessary.

(15)

See 3GPP TS 23.002 V9.2.0 (2009-12).

(16)

See 3GPP TS 29.163 7.2.3.2.2A.

(17)

See 3GPP TS 29.163 7.2.3.2.2.3.

(18)

Inserting an invalid number in the user-info portion of the tel URI is in variation from 3GPP TS 29.163, which has no method for passing calling party parameters without a calling party number.

(19)

See RFC 4694 Section 5.2.4. Note, however, that neither ITU-T Q.1912.5/1998 nor 3GPP TS 29.163 V9.0.0 support the concept of communicating the Jurisdiction Information Parameter from the IAM to the INVITE.

(20)

See 3GPP TS 29.163 V9.0.0 (2009-12) Annex C.2, RFC 3325 and draft-patel-dispatch-cpc-oli-parameter-02. See also, 3GPP TS 29.163 7.2.3.2.2.3A.

(21)

See 3GPP TS 29.163 V9.0.0 (2009-12) Annex H.2, RFC 3325 and draft-patel-dispatch-cpc-oli-parameter-02. See also, 3GPP TS 29.163 7.2.3.2.2.3B.

(22)

See 3GPP TS 29.163 V9.0.0, ITU-T Rec. Q.1912.5 and RFC 3325.

(23)

Note that the Called Party Number is always present and the Calling Party Number must be present in an ANSI IAM when the Originating Line Information parameter is present and no Charge Number is present.

(24)

The Optranex 248 switch is not being populated with customer data for the trial: it is capable of populating customer data and forming dial plans from such data, particularly using the ENUM approach illustrated in ENUM Calls from PSTN to SIP.

(25)

The Optranex 248 switch will not perform LNP dips for the trial: the switch is capable of performing TCAP LNP dips or I-ENUM number portability dips in normal operation as illustrated in ENUM Calls from SIP to PSTN.

(26)

See RFC 3326 and draft-jesske-dispatch-reason-in-responses-01 for more information on the Reason header. Note that this header is also proscribed by ITU-T Recommendation Q.1912.5 as well as 3GPP TS 29.163.

(27)

For formatting of tel URLs in sip URIs, see RFC 3261 section 19.1.6.

(28)

See RFC 4504 Section 5.3 for variations on addressing provided by a SIP phone.

(29)

Note that the IP address and UDP port number in the 180 Ringing or OK response to the original INVITE is mapped from the bearer circuit selected for the call.

(30)

See 3GPP TS 29.163 V9.0.0 (2009-12) Annex C.1 and draft-patel-dispatch-cpc-oli-parameter-02.

(31)

See 3GPP TS 29.163 V9.0.0 (2009-12) Annex H.1 and draft-patel-dispatch-cpc-oli-parameter-02.

(32)

(33)

OpenSIPS was formerly called OpenSER.

(34)

Note that this mapping is consistent with Table 21/Q.1912.5.

(35)

Note that this mapping is consistent with Table 21/Q.1912.5.

(36)

The Media Gateway Interface is documented in the OpenSS7 MGI Specification.

(37)

Note that the sofia-SIP libraries are released by OpenSS7 under the GNU General Public License in accordance with Section 3 of the GNU Lesser General Public License Version 2.1.

(38)

net-snmp only provides select(2).

(39)

See 3GPP TS 29.163 V9.0.0 (2009-12) Annex H.1 and draft-patel-dispatch-cpc-oli-parameter-02.

(40)

Additional actions on reattempt can include logging the reattempt and the reason for reattempt, or issuing an SNMP trap notification.

(41)

Cases in which the CC_SETUP_REQ primitive for the reattempt might not be the same can be where the CC_CALL_REATTEMPT_IND is for a circuit in a two-way overflow trunk group: in this case, the reattempt might be for the primary one-way non-overflow trunk group.

PSTN Gateway

Description: OpenSS7 Application Design Documentation.

Optranex 248 PSTN Gateway

Optranex 248 PSTN Gateway Field Trial Plan of Record

About This Manual

List of Examples

List of Messages

Executive Overview

The OpenSS7 Project

The OpenSS7 Carrier VoIP Switch

Open Source Software

Commodity Hardware

Rapid Development

An Evolving Solution

Conclusions

Preface

Document Information

Abstract

Objective

Intent

Audience

Revisions

Version Control

ISO 9000 Compliance

Disclaimer

Document Organization

1 Introduction

1.1 The Optranex 248 PSTN Gateway

1.2 Project Drivers

1.2.1 Project Objectives

1.3 Scope

1.3.1 Phases

1.3.2 Gates

2 Application Architecture

2.1 Application Requirements

2.1.1 Phase 1 Requirements

2.1.2 Phase 2 Requirements

2.1.3 Phase 3 Requirements

2.1.4 Phase 4 Requirements

2.1.5 Phase 5 Requirements

3 Solution Architecture

3.1 Optranex 248 PSTN Gateway Deployment

3.2 Distinguishing Features

3.2.1 Capital Expense Reduction

3.2.2 Power Consuption Reduction

3.2.3 Footprint Reduction

3.2.4 Closed and Proprietary Software Reduction

3.2.5 Cost per Channel Reduction

3.3 Call Flows

4 Network Architecture

4.1 Ethernet Connections

IP Address Requirements

Traffic Requirements

RTP Traffic Calculations

4.1.1 Internet Ethernet Traffic

4.1.2 Test-Bed RTP Ethernet Traffic

4.1.3 Test-Bed SIP Ethernet Traffic

4.1.4 Test-Bed SIGTRAN M3UA Ethernet Traffic

4.1.4.1 Test-Bed SIGTRAN M3UA Network Configuration

4.1.4.2 Test-Bed SIGTRAN M3UA AS Configuration

Signaling Point Codes

4.1.4.3 Test-Bed SIGTRAN M3UA Traffic Requirements

4.1.5 Test-Bed DNS Ethernet Traffic

4.1.6 Customer RTP Ethernet Traffic

4.1.7 Customer SIP Ethernet Traffic

4.1.8 SIGTRAN M3UA Ethernet Traffic

4.1.8.1 SIGTRAN M3UA Network Configuration

4.1.8.2 SIGTRAN M3UA AS Configuration

Signaling Point Codes

4.1.8.3 SIGTRAN M3UA Traffic Requirements

4.1.9 DNS Ethernet Traffic

4.1.10 Management Ethernet Traffic

4.1.10.1 DNS Ethernet Traffic

4.1.10.2 NTP Ethernet Traffic

4.2 SONET/SDH Connections

4.2.1 PSTN Aggregated DS3 over SONET

4.2.1.1 Synchronization

4.2.2 Test-Bed Copper OC-48 Loop Back

4.2.3 Trunk Group Configuration

4.2.3.1 Controlling Exchange