Configuring Private Wire Interworking

You can configure the device to interwork in a private wire system, where one side is IP (SIP) based and the other side is legacy, digital PSTN (E1/T1 CAS) based.

The feature is applicable only to IP-to-Tel calls and E1/T1 CAS.

Private wire is a generic term used to describe static point-to-point voice connections between two locations. Private Wires are typically used by a number of communities such as military, railways, emergency services, and financial services. Historically, private wire services were achieved by running direct private connections (telephone cables) between offices in the same building. In private wire services, dialing is unnecessary and there is a direct, "always on" and immediate connection.

Trading turret systems are also part of private wire services. A trading turret or dealer board is a specialized telephony key system that is generally used by financial traders on their trading desk. Trading turrets enable users to prioritize incoming call activity from customers or counter-parties and make calls to these same people instantaneously by pushing a single button to access dedicated point-to-point telephone lines (commonly called Ringdown circuits). No dialing is necessary; the user simply picks up the handset or pushes a button and a dedicated line is seized. Thus, many turrets have multiple handsets and multi-channel speaker units, allowing immediate connection with multiple parties (e.g., 30 channels). These channels remain constantly open throughout the trading day.

Today, private wire services are evolving from digital TDM architectures to IP-based architectures. The device can be used for interworking between these two architectures, where you have the PSTN switch (PBX) using the E1/T1 CAS protocol on one side, and a SIP-based private wire (turret system) trunk on the other side. The device converts the CAS channels into a SIP call with a called and calling number and if required, passes the ABCD bit state changes through SIP messages, and vice versa. The following diagram shows an example of private-wire interworking by the device:

SIP-based private wire calls are established as any other INVITE dialog, but with the addition of the following headers:

■ SIP Supported header with the value "pw-info-package" (i.e., Supported: pw-info-package).
■ SIP Recv-Info header with the value "pw-info-package" and with the parameter "pw-type=" with a value denoting the private wire state, which can be:
● Ring Down state: 
Recv-Info: pw-info-package;pw-type=ringdown
● Hook Switch: 
Recv-Info: pw-info-package;pw-type=hookswitch
● TOS: 
Recv-Info: pw-info-package;pw-type=tos

The following is an example of an INVITE message for a private wire call: 

INVITE sip:109701@10.221.108.249:5060;transport=tcp SIP/2.0
Via:SIP/2.0/TCP10.221.109.4:5060;oc-node=101;branch=z9hG4bKqkYGTNi7Husc11Jlmw6d9g;rport
From: <sip:uas@10.221.109.4>;tag=ENvIDQ
To: <sip:109701@10.221.108.249:5060;transport=tcp>
Call-ID: WHuqvQgdIZB27ewgrhJRYw
CSeq: 835392 INVITE
Contact: <sip:10.221.109.4:5060;transport=tcp;oc-node=101>
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 635
Supported: pw-info-package
Recv-Info: pw-info-package;pw-type=ringdown

Once a SIP-based private wire is established, the private wire user may wish to signal any of the following private wire events to the far-end private wire user, at any time during the "always-on" call:

■ Hook Switch (On Hook and Off Hook states): This event signals a change in the state of an electronic hook switch. An example is when the user connects a wireless headset to the phone.
■ Ring Down (Ring and No Ring states): This event signals a ring or no ring state. An example is when the user lifts the handset or pushes a button on the phone to alert the far-end user, which instantly sends ringing to the far end (even though they are already connected). This is also known as Automatic Ring Down (ARD) or Manual Ring Down (MRD).
■ TOS (transmission only service): If neither Ring Down or Hook Switch modes are specified in the INVITE, TOS is assumed. In this case, the device ignores all CAS signaling, replies with 200 OK and opens a media channel.

These special private wire events are signaled during a call using the SIP INFO message in association with the INFO package (per IETF draft). The INFO package is the INFO message's body, which is in XML schema. The root element of the XML is "<pwsignal>", which contains two child elements:

■ "<ringDown>" - requests a local Ring Down alert
■ "<hookSwitch>" - requests a Hook Switch alert:
◆ "onHook" - signals that the endpoint is not in use
◆ "offHook" - signals that the endpoint is in use

The following is an example of the XML for private wire signaling in the SIP INFO message:

 <?xml version="1.0" encoding="UTF-8"?>
   <xsd:schema targetNamespace="urn:bt-trs:params:xml:ns:private-wire:0"
              xmlns="urn:bt-trs:params:xml:ns:private-wire:0"
              xmlns:xsd="http://www.w3.org/2001/XMLSchema"
              elementFormDefault="qualified"
              version="0.1">
   <xsd:annotation>
           <xsd:documentation xml:lang="en">Version 0.1 Draft XML schema
           for Private Wire Signalling in SIP INFO body
    </xsd:documentation>
   </xsd:annotation>
     <!--  pwSignal -->
   <xsd:complexType name="pwSignallingType">
    <xsd:sequence>
     <xsd:choice>
      <xsd:element ref="ringDown" />
      <xsd:element ref="hookSwitch" />
      <xsd:any namespace="##other" minOccurs="0"
       maxOccurs="unbounded" processContents="lax" />
     </xsd:choice>
    </xsd:sequence>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:complexType>
   <xsd:element name="pwSignal" type="pwSignallingType"/>
   <!--  ringDown -->
   <xsd:complexType name="ringDownType">
    <xsd:sequence>
     <xsd:any namespace="##other" minOccurs="0"
      maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:attribute name="signal" type="ringDownSignalType" use="required"/>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:complexType>
   <xsd:element name="ringDown" type="ringDownType"/>
   <!-- hookSwitch  -->
   <xsd:complexType name="hookSwitchType">
    <xsd:sequence>
     <xsd:any namespace="##other" minOccurs="0"
      maxOccurs="unbounded" processContents="lax" />
    </xsd:sequence>
    <xsd:attribute name="signal" type="hookSwitchSignalType" use="required"/>
    <xsd:anyAttribute namespace="##other" processContents="lax" />
   </xsd:complexType>
   <xsd:element name="hookSwitch" type="hookSwitchType"/>
   <!-- DATATYPES-->
   <xsd:simpleType name="ringDownSignalType">
    <xsd:restriction base="xsd:token">
     <xsd:enumeration value="ring"/>
    </xsd:restriction>
   </xsd:simpleType>
   <xsd:simpleType name="hookSwitchSignalType">
    <xsd:restriction base="xsd:token">
     <xsd:enumeration value="onHook"/>
     <xsd:enumeration value="offHook"/>
    </xsd:restriction>
   </xsd:simpleType>
  </xsd:schema>

The following is an example of the message flow for the interworking private wire Ring Down state between the private wire trunk and the E1/T1 CAS trunk:

The following is an example of the message flow for interworking private wire Hook Switch states between the private wire trunk and the E1/T1 CAS trunk:

➢ To configure private wire interworking:
1. Enable TDM tunneling for private wire services, by doing one of the following:
● Globally: Open the Digital Gateway Parameters page (Setup menu > Signaling & Media tab > Gateway folder > Digital Gateway > Digital Gateway Parameters), and then from the 'TDM Tunneling' drop-down list, select Private Wire:

● Per Trunk: Configure the ini file parameter [EnableTDMOverIPforTrunk].
2. Configure the ini file parameter [EnableReansweringInfo] to 1.
3. Upload a CAS table file that supports your private wire service. For loading files to the device, see Loading Auxiliary Files.
4. In the Trunk Settings page (see Configuring Trunk Settings), configure your E1 or T1 CAS Trunk. Make sure that you select the CAS table file that you loaded in the previous step, in the 'CAS Table per Trunk' field:

5. In the Trunk Groups table (see Configuring Trunk Groups), configure the Trunk Group ID for the E1/T1 CAS Trunk, as shown in the following example:

6. In the Trunk Group Settings table (see Configuring <trnkgrpsettable<product>>), configure the method for selecting channels for the E1/T1 CAS Trunk to By Dest Phone Number, as shown in the following example:

7. In the IP-to-Tel Routing table (see Configuring IP-to-Tel Routing Rules), configure IP-to-Tel Routing rules.