QSIG

Document

Sat, 09/28/2013 - 02:41
Jun 20th, 2012
User Badges:
  • Cisco Employee,

About


There may be scenarios where a third party vendor’s PBX hardware uses  a proprietary ISDN signaling protocol. Unless the same PBX (signaling  standard) is used on both ends of the circuit, you need a way so that  the two PBXs or voice  gateways can properly communicate signaling  information back and forth. QSIG is an open standard protocol which  defines services and signaling protocols for Private Integrated Services  Networks (PISNs) to overcome this issue. It is a peer-to-peer signaling  protocol that uses Q.931 as its underlying signaling protocol but  modifies the signals so proprietary ISDN signaling protocols can be used  by non-proprietary equipment on the other end of the connection.


The ISDN Q.921 and Q.931 standards provide the basis for QSIG  protocol, which sets a worldwide standard for PBX interconnection. In a  basic QSIG call, a user in a Private Integrated Services Network  Exchange (PINX) can place a call to a user that is in a remote PINX. The  called party receives the caller name or number as the call rings. The  calling party receives the called name and number when the user phone  rings in the remote PINX. All the features that are available as a PBX  user operate transparently across the network. QSIG protocol provides  supplementary and additional network features, as defined for PISNs, if  the corresponding set of QSIG features are supported by both ends of the  call.


Cisco UC solutions support QSIG to connect with various vendors’ PBX  systems and Central Office (CO) switches that use the QSIG standard.  Note that if QSIG information is being tunneled to CUCM (or if it is a  MGCP PRI to CUCM running QSIG) then the feature set supported will  differ from that which is supported in IOS.


Configuation/Deployment Examples


The switch type confiugred must be QSIG:

isdn switch-type primary-qsig


To have IOS decode QSIG messages, enable:

voice service voip
 qsig decode


To enable Call Diversion:

interface Serial x/y/z:23
 isdn supp-service calldiversion


For Transparent Tunneling of QSIG and Q.931 over SIP/H.323:

voice service voip
 signaling forward unconditional 
             OR
 signaling forward rawmsg !this command can also be placed under the respective VoIP dial-peer


For translation between SIP and QSIG MWI, only unsolicited notify is supported:

sip-ua 
 mwi-server dns:cisco.com expires 60 port 5060 transport udp unsolicitedvoice service voip


For CME with QSIG PBX:

voice service voip
 qsig decode

voice service pots
 supplementary-service qsig call-forward


For CME with QSIG PBX being used as Voicemail Server such as Mitel:

voice service voip
 qsig decode

telephony-service
 voicemail <number>

ephone-dn <tag>
 mwi qsig

dial-peer voice <tag> pots
 destination-pattern <voicemail-number>
 port x/y/z:23


H.450.7 may need to be enabled for some scenarios where transferring via Q.SIG over H323:

voice service voip
 supplementary-service h450.7 


CUCM supports both ECMA and ISO standards for Q.SIG.  See the  endpoint specific configuration in CUCM to ensure that it is provisioned  properly.  There are also sevral QSIG service parameters in CUCM under  varios sections such as call forward.


QSIG Support on IOS Voice GWs

Please refer the link below:

QSIG Support on Voice Gateways


CME Support

Please reference the QSIG section in the CME Admin guide for the latest information:

CME Administration Guide

Loading.
j.reinbold Sat, 09/28/2013 - 02:41
User Badges:

Interesting Document, but for those people who choosed to use GSIG with H323 Dialpeers instead of QSIG over MGCP Backhaul (not tunneled) to have pbx connections, it would be very interesting to know  the feature support differences between both methods.  In this document we simply assume that the feature set is identical; which is not the case in practice.  In the pbx interoperability portal, the most pbx connections are older and based on MGCP.


Example of a feature who seems not to work under H323 Dialpeers:  callback from pbx to UC and from UC to PBX


I suggest to make a document on what to do with supplementary services configurations to have similar behaviors as with mgcp.


Jacky

Actions

This Document

Related Content