Empowered Branch Solution

ISDN Q-Interface Signaling Protocol Q.931 Tunneling over the IP Network

  • Viewing Options

  • PDF (202.9 KB)
  • Feedback

"What You Will Learn"?

Enterprises embrace new technologies to become more efficient and productive. Adoption of advanced technologies can offer the critical operating advantage necessary for the continued success of enterprises in an increasingly competitive business environment. Ideally, enterprises can deploy a technology and operate it cost effectively for an extended period of time; however, this is not usually the case. Technology continues to evolve, which forces enterprises to change the way they operate and work.
Private branch exchanges (PBXs) are crucial communication components in any organization. As an organization grows and expands to multiple locations, it needs to establish multiple PBXs to keep the locations connected. The primary challenge in operating these multiple PBXs is to get them to work as a single entity so that the user experience is consistent and reliable irrespective of location. For example, when a single voicemail system is installed at headquarters, it needs to be accessible to all remote employees as if they are accessing it locally. To achieve such operation, the PBXs must be connected (Figure 1).
As discussed here, the Cisco ® Q-Interface Signaling (QSIG) tunneling-over-IP feature, which provides the capability to tunnel QSIG protocol messages over an IP network, is an excellent example of a new technology that it is redefining the telecommunications system for enterprises that want to significantly reduce their telecommunications costs without losing existing features. Moreover, it introduces many other opportunities, such as migration to ip-telephony, convergence of voice & data network together, having rich media communication, deployment of unified communication systems etc.

Figure 1. Connecting Voicemail System with PBX Interconnect Using QSIG

Typical PBX Deployment

Traditionally, PBXs are connected through dedicated leased lines known as trunks. The cost of leasing dedicated trunks to interconnect PBXs in different locations is very expensive. Typically, leased lines come in T1 or E1 format, but the number of T1/E1 trunk lines required depends on the total number of end users at each location. In addition, other factors must be considered when deploying a fully-meshed PBX system that spans multiple locations.
Consider, for example, an enterprise that has offices in four locations: London, Paris, Rome, and Berlin (Figure 2). Each location has a PBX onsite with 300 users. To support these users, the enterprise put one E1 line on the trunk side (1:10 ratio), so that between PBX@London and PBX@Rome the enterprise can have up to 30 simultaneous calls (as the capacity of a single E1 is 30 voice channels, and a T1 is 24).

Figure 2. Typical PBX Deployment Example

The following factors require consideration when connecting these PBXs:

Capacity of leased trunk lines: Determining the capacity of trunk lines between different locations is challenging. In most cases, the demand exceeds the capacity of the trunk lines. In this example, the enterprise needs three E1 lines at each location to interconnect with the other sites. An E1 line can connect two sites, so the enterprise needs a total of six E1 lines: (3 * 4)/2 = 6. In the case of a larger enterprise, where m number of E1 lines are needed to connect two PBXs, and where the enterprise has n number of PBXs, ½ * m * (n - 1) * E1 trunk lines are needed at each PBX site to achieve fully meshed connectivity. You can see how quickly costs increase with each additional PBX in the system.

Lower utilization of leased trunk lines: Utilizing all the trunk lines efficiently is also a challenge. Although the enterprise is leasing ½ * (n - 1) * E1 lines for each site, it may be using only one E1 line at a time. The enterprise thus will be paying huge amount of money just to keep the extra leased line facility.

Problems with expansion: A substantial amount of planning and execution time is required to increase trunk-side capacity for a PBX location. For example, if the number of employees in London increases, and the call volume from London then exceeds the current trunk capacity to other sites, the enterprise will need to increase the capacity of the London site and possibly also of other sites depending on the increase in functional and business requirements. You can see how the complexity increases with the increase in number of trunks.

Cost of maintenance: Maintaining all the leased lines at various locations can be difficult and costly. In the case of service unavailability, it can be especially challenging to reroute calls to other PBX locations.

QSIG is a protocol used to connect PBXs within an enterprise with supplementary services. This protocol is designed to be independent of its own transport mechanism as well as to be independent of any means used to transport speech or other media in calls established using QSIG. An example of a typical QSIG deployment is a configuration of primary-rate leased lines so that signaling takes one of the 24 (T1) or 30 (E1) 64-kbps channels while the rest act as 64-kbps bearers for media. The QSIG protocol acts as a variant of ISDN D-channel voice signaling and is based on the ISDN Q.921 and Q.931 standards, setting a worldwide standard for PBX interconnection.

QSIG Overview

QSIG is an internationally standardized signaling protocol for use in corporate and enterprise voice and integrated services networks. Typically employed between PBXs, the QSIG protocol is used to establish and release calls (basic services) and to manage supplementary services between PBXs.
In a basic QSIG call, a user on one PBX can place a call to a user on another (remote) PBX. The called party receives the calling party's name or number when the call rings, and the calling party receives the called party's name and number when the called party's phone rings on the remote PBX. Additionally, the QSIG protocol helps provide supplementary and additional network features as long as the corresponding set of QSIG features is supported at both ends of the call.
Here are some standard QSIG supplementary services available on various PBXs:

• Multiple Subscriber Number

• Call Waiting

• Calling-Line Identification Presentation (CLIP)

• Calling-Line Identification Restriction (CLIR)

• Connected-Line Identification Presentation (COLP)

• Connected-Line Identification Restriction (COLR)

• Malicious Call Identification

• Call Hold

• Advice of Charge

• Three-Way Conference

• Call Diversion

• CFU Supplementary Service

• Path Replacement (ANF-PR)

• Call Transfer by Join (SS-CT)

• Call Completion to Busy Subscriber (CCBS)

• Explicit Call Transfer

All these features can be available to a PBX user operate transparently across the network, but there is a cost associated with having the features available in the voice network. With QSIG tunneling over IP, Cisco can reduce this cost without sacrificing features. The capability to provide QSIG over an IP network provides the benefit of feature transparency and at the same time maximizes PBX facility capabilities and helps ensure toll-quality voice traffic while significantly reducing telecommunication costs.

Significant Cost Savings with QSIG over IP

IP is becoming the universal Layer 3 in data networks. Data bandwidth is increasing rapidly, already overtaking voice bandwidth, and as technology continues to evolve, an increasing number of enterprises are using IP networks for data transfer. Connecting PBXs over IP networks is becoming the preferred solution over time-division-multiplexing (TDM) and dedicated leased lines, and enterprises that have chosen this route are experiencing great benefits in cost and flexibility within their networks.
The QSIG tunneling-over-IP feature enables Cisco voice switching services to connect to PBXs and other crucial systems that communicate using the QSIG protocol (such as the Cisco Unified Communications Manager server). Using this feature, Cisco devices can receive incoming voice calls from a private integrated services network exchange (PINX) device and route them across a WAN to a peer Cisco device, which transports the signaling and voice packets to another PINX device. To do this, all PBXs in the system are connected to the network through Cisco gateways, and the Cisco gateways transparently tunnel both QSIG and Q.931 signaling across the IP network (Figure 3).

Figure 3. PBXs Connected over IP Network

The following are some of the major benefits of deploying QSIG over IP networks:

Virtual circuits: Connectivity among PBXs over IP network is virtual. There is no dedicated point-to-point circuit between PBXs. Instead, PBXs are connected to Cisco Voice Gateways through TDM, and the gateways create virtual connections among themselves using dial peers.

Trunk savings: Because the connections among PBXs are virtual, there is no need for a dedicated, inefficiently utilized TDM connection. Instead of needing ½ * (n - 1) * E1 lines for each site, you can have similar performance with the equivalent bandwidth (2 Mbps per site) of just a single E1 line. By doing so, you can significantly reduce transport costs.

PBX port savings: Using QSIG over IP, you keep PBX T1/E1 physical ports available for other uses. With n number of sites to be connected and each site requiring (n - 1) T1/E1 lines to connect to (n - 1) sites, you need a total of n * (n - 1) T1/E1 lines. But if you use QSIG over IP, you need only n number of T1/E1 lines (assuming that you need only one T1/E1 to connect a site to the network). Of course, if the number of users increases, the quantity will likely increase for both cases, but using QSIG tunneling, you avoid the (n - 1) multiplication factor for determining the number of lines and cost required for IP deployment.

Ease of network expansion: If you need to increase the capacity for any location, implementation is very easy when doing so over the IP network. Additionally, you can avoid all the complexities of adding a new site to an existing system; instead of building in dedicated connectivity to all existing sites, with QSIG over IP you need only create the VPN over IP, and your new site is connected to your network.

Easy configuration and maintenance: Configuring an IP network is much easier than configuring a traditional TDM network. With the evolution of information technology, you can easily find the resources needed to configure your routers and to provide continuous support.

Coexistence with data network: You already have data connections for each site in your system to run your daily operations. With QSIG over IP, your existing data network can be used for tunneling voice calls without losing quality or features.

Strategic move toward IP: Although the current system is capable of providing QSIG features to existing TDM phone users transparently, tunneling QSIG over IP positions your company for the move to IP telephony. If you have been or will be considering a move to IP telephony, this is the first step in the process: it will enable your voice network over the IP platform. When you do finally make the move to IP telephony, you will be ready to deploy Cisco Unified Communication solutions over the existing gateways that will remain as part of your new system.

Solution Overview

The QSIG tunneling-over-IP feature provides the capability for Cisco gateways to transparently pass QSIG and Q.931 signaling across an IP network by tunneling QSIG and Q.931 messages through Session Initiation Protocol (SIP) and H.323 protocol messages. This feature does not add any QSIG services to SIP interworking.
Consider a scenario in which PBX1 and PBX2 are connected through an originating gateway (OGW) and a terminating gateway (TGW) over an IP network (Figure 4). Signaling between PBX1 and OGW and between PBX2 and TGW uses QSIG, and signaling between OGW and TGW takes place over a SIP or H.323 IP network.

Figure 4. Transporting QSIG over IP Network

In a conventional PBX that is deploying QSIG, two PBXs are connected by means of an inter-PINX link, which consists of two channels:

• A signaling channel (carrying QSIG messages)

• One or more user information channels (carrying media)

The Cisco gateway will tunnel both the signaling and the media channel over the IP network using H.323 or SIP. You can choose the protocol based on your network design.

Tunneling over H.323

H.323 is an umbrella recommendation that encompasses various ITU-T recommendations, primarily recommendations H.225.0 and H.245 (basic communication capabilities) and recommendation H.450.1 (generic functional protocol for the support of supplementary services). Tunneling QSIG over H.323 is specified in H.323 Annex-M1. However, Cisco IOS ® Software H.323 QSIG tunneling does not implement Annex-M1 (as the Cisco Unified Communications Manager H.323 implementation does). Instead it uses the ISDN Generic Transparency Descriptor (GTD) to transport QSIG messages in the corresponding H.225 message to another Cisco gateway device on the other side of the network.
Because H.323 is based on the ISDN Q.931 standard, H.225 messages have a very close correspondence to QSIG ISDN messages. The H.225 messages tunnel the entire QSIG message unchanged, starting with the Protocol Discriminator field, and ending with the other information elements. For example, the QSIG SETUP message is tunneled in an H.225.0 SETUP message. For some messages, there may be no corresponding H.225.0 (Q.931) message, or the corresponding message may not be available because it has already been sent. In those cases, the QSIG message will be tunneled in an H.225.0 FACILITY message. A single QSIG call will be tunneled in a single H.323 call.
H.323 QSIG tunneling is enabled by default for QSIG trunks configured on Cisco IOS gateway platforms supporting this function, and no command-line interface (CLI) commands are needed beyond basic H.323 dial peers.

Tunneling over SIP

The Cisco gateway receives QSIG messages from the PBX side and then identifies the destination of the message (or call). The QSIG messages received from the PBX are encapsulated within SIP messages as Multipurpose Internet Mail Extensions (MIME) bodies and are sent (tunneled) across the IP network to the recipient gateway.
When encapsulating a QSIG message (for switch type primary-qsig) inside a SIP message, Cisco gateways include the QSIG message in a MIME body of the SIP request or response using media type
Content-Type: application/QSIG
If any other MIME body needs to be included (such as Session Descriptor Protocol [SDP] or GTD), the Cisco gateway will use multipart MIME to encapsulate the content, encoded accorded to RFC 3204. The content within the MIME body is binary data that includes the entire QSIG message, beginning with the protocol discriminator. This MIME body is encapsulated within the SIP message, and the content length header is used to convey the size of the binary QSIG data.
The content disposition header is included to specify how this body should be interpreted and handled:
Content-Disposition: signal; handling=optional
At the receiving end of the IP network (TGW), the ISDN message is decoded to identify the message type, and then a corresponding message is sent to ISDN.
This feature supports any other switch type at OGW and TGW, but for tunneling any non-QSIG Q.931 messages, SIP uses the following content type in the header:
Content-Type: application/x-q931


By default, QSIG Q931 tunneling is enabled on H.323 gateways, but not on Cisco SIP gateways. To configure QSIG Q.931 tunneling on a Cisco SIP gateway, you need to configure the following commands at the CLI:
signaling forward rawmsg
signaling forward unconditional
There is a minor difference in the configuration of QSIG tunneling using H.323 and using SIP, listed in Table 1.

Table 1. Behavior of QSIG in H.323 and SIP




Default: No specific voice-over-IP (VoIP) level CLI command is configured (signaling forward ...)

a) session target ip-address

b) session target RAS

a) Tunnels both QSIG/Q.931 and GTD

b) Tunnels only QSIG/Q931

No tunneling

signaling forward rawmsg

Tunnels QSIG/Q931 only

Tunnels QSIG/Q931 only

signaling forward unconditional

session target ip-address | RAS

Tunnels both QSIG/Q931 and GTD

Tunnels both QSIG/Q931 and GTD

signaling forward none

No tunneling

No tunneling

Transparent QSIG Tunneling on Cisco Unified Border Element

Consider a scenario in which PBX1 and PBX2 are connected through the originating gateway (OGW), Cisco Unified Border Element (formerly known as Cisco Multiservice IP-to-IP Gateway), and terminating gateway (TGW) over an IP network. Signaling between PBX1 and OGW and between PBX2 and TGW uses Q931, and signaling between OGW, Cisco Unified Border Element, and TGW is tunneled through the SIP trunk (Figure 5).

Figure 5. QSIG over Cisco Unified Border Element

The following are important considerations in the development of QSIG tunneling on the Cisco Unified Border Element:

• The QSIG tunneling feature extends the transparent tunneling support to multiple SIP-SIP gateways inserted between OGW and TGW.

• Normal calls will continue to work even if the Cisco Unified Border Element does not support multipart MIME body or QSIG tunneling, or if QSIG tunneling is disabled on the Cisco Unified Border Element.

• Cisco Unified Border Element supports all three types of QSIG signaling massages:

– Connection-oriented call-related messages

– Connection-oriented call-independent messages

– Connectionless messages

• The media path cannot be established while transporting connection-oriented call-independent messages.

Fallback from QSIG Tunneling

In some situations, QSIG tunneling will fail or need to fall back:

Remote party does not support multipart MIME body: In this case, the remote side sends a "415 Media Not Supported" response. Upon receiving this response, OGW will fall back to normal mode and send an INVITE request without any tunneled content. This procedure helps ensure that at least the basic call will work normally.

Remote party does not understand tunneled content: If the remote side does not support the tunneled content, it should drop the tunneled content and continue as a normal call; because all essential parameters are present in the original INVITE, the call can go through without the need for fallback.


Cisco tested the QSIG feature with many PBX vendors, including the following:

• Lucent/Avaya Definity G3r using T1 or E1

• Avaya MultiVantage and Communication Manager

• Alcatel 4400 using E1 or T1

• Ericsson MD110 using E1

• Nortel Meridian using E1 or T1

• Siemens Hicom 300 E CS using T1

• Siemens Hicom 300 E using E1

• Siemens HiPath 4000

For the latest information, please visit

Supported Platforms and Cisco IOS Software Versions

Cisco supports the QSIG feature on the following platforms: Cisco 2801, 2811, 2821, 2851, 3825, and 3845 Integrated Services Routers; and Cisco AS5350XM and AS5400XM Universal Gateways.
The QSIG feature is provided on the following versions of Cisco IOS Software:

• QSIG over H.323 is released on Cisco IOS Software Release 12.1(2)T.

• QSIG over SIP is released on Cisco IOS Software Release 12.4(15)XZ.


The QSIG feature does not support any new or modified MIBs.
For descriptions of supported MIBs and how to use them, see the Cisco MIB Website at


Cisco has maintained the following standards:

ECMA-141: Private Telecommunication Networks-Inter-Exchange Signaling-Data Link Layer Protocol (QSIG-L2)

ECMA-142: Private Integrated Services Network (PISN)-Circuit Mode 64-kbps Bearer Services-Service Description, Functional Capabilities, and Information Flows (BCSD)

ECMA-143: Inter-Exchange Signaling Procedures and Protocol (QSIG-BC), 4th edition

ECMA-165: Generic Functional Protocol for the Support of Supplementary Services-Inter-Exchange Signaling Procedures and Protocol

ECMA-333: Tunneling of QSIG over H.323

ECMA-336: Tunneling of QSIG directly over TCP/IP

ECMA-355: Corporate Telecommunication Networks-Tunneling of QSIG over SIP, 2nd edition

ITU-T Recommendation H.323: Packet-based multimedia communications systems

ITU-T Recommendation H.225.0: Call-signaling protocols and media stream packetization for packet-based multimedia communication systems

For More Information

RFC-3261: SIP

RFC-3265: SIP-specific event notification

RFC-3204: MIME media types for ISDN user part (ISUP) and QSIG objects

RFC-4497: Interworking between the SIP and QSIG MIME media types for ISUP and QSIG objects

Reference Documents

Configuration guide:

PBX interoperability:

Cisco Unified Border Element: