Skip to end of metadata
Go to start of metadata


CAS Circuit Configuration Introduction

This section contains information about configuring CAS Circuits, including information about CAS Tunnel and CAS Manual Ring Down (MRD) Protocol.

CAS Tunnel Overview

Implementation of CAS tunnel allows tunneling of signaling and voice from CAS lines in a VX node to CAS lines in another VX node. Thus there is a permanently open duplex path between the trunks in both the nodes. The port type for this includes "CAS Tunnel", and the hunt type includes "Match Own Number".

Currently if CAS signaling needs to be transported to a remote end, standard ON-HOOK or OFF-HOOK signals are converted by standard interworking to a IP protocol like SIP or BSP and a call will be established in the VX for each signaling call from the third party switches. With this feature enabled, the VX nodes will already have a call established and the audio and signaling path of this call will be always open as a tunneled connection. This always open tunnel will be used to carry signaling and voice between two, third party switches. Also for the remote end a third party switch can be used which can accept CAS signaling and DTMF tones over RFC 2833.

CAS Tunnel Network Layout


Figure 1: CAS Tunnel Network Layout


CAS Tunnel Configuration Scenario

The tunnel can internally use BSP or SIP protocol. In this section the BSP protocol is referred.

For every CAS trunk group configured on a tunneled circuit port, the user has to configure corresponding inbound/outbound BSP trunks and the corresponding routes.
A CAS variant state is also introduced and called "CAS Tunnel". The CAS trunk groups used for this feature needs to be configured over this port type.

When both the nodes initialize, after the CAS and BSP channels are in service internally necessary CAS -> BSP and BSP -> CAS connections are made for each channel. The VX CAS channels at either ends will open the tunnel for its external CAS peers, only after the internal connections are setup and the permanent voice and signaling path is open. There may be a case, wherein any of the steps for this internal setup fail. This may be due to licensing or resource restrictions or connectivity problems. Both nodes will register error alarms for the feature in this case and the end CAS tunnel channels will not come in the "Connected" state. To identify either ends of the tunnel, the terms "Master" and "Slave" are used. This is to know beforehand from where the first internal call will be started and will help to avoid complexity. This information is configured by the user in the channel profile. Also if the initial internal setup fails, this concept would help debugging, based on this configuration. After this, CAS channels from the "Master" side will initiate calls to the "Slave" side which will be answered by the "Slave" side VX CAS channels. These calls are made and answered internally without any external stimuli. Once the connection is complete, the channels are declared permanently connected. From this point the tunnel is active and passes any CAS signaling bits to the other side. If the tunnel Setup message is not answered from the remote node, the master channel will register an alarm and retry the setup after the setup retry timer expires. This continues until the setup is answered from slave channel. If a slave channel does not receive a setup message, it waits in the idle state. It will register an alarm after every 60 seconds. Thus the tunnel connection will be setup when both the nodes are up.

If the internal setup was successful, and the VX CAS channels are in the "Connected" state, we transport the following forms of data transparently to either side.

1. CAS abcd bit changes

2. DTMF or MFR1 digits

3. Voice

The responsibility of bringing the CAS trunks "IDLE" at either side of the "tunnel" is with themselves. This is because, by design, VX tunnel would even transport the "IDLE" bit pattern to either side, if it is received. Thus if the third party CAS channel at one end of the tunnel does not send the "idle" pattern, OR sends a wrong "idle" bit pattern, the third party CAS channel at the other end will not be in service. The VX tunnel is just a transporter for the entire CAS signaling and the VX, by itself, will not originate or respond to the CAS signals received. Once the tunnel is open, when a CAS signaling bit transition is detected, this will be transported to the remote end.

Confuguring CAS Tunneling needs to be configured on both the nodes. You will have to specify the channel profile for the "CAS Tunnel" variant. If the trunk uses the master profile, a route to the outbound BSP should be configured. Similar configuration will be required at the remote VX node also where the previous node is a BSP peer.

The below figure depicts the scenario where the CAS tunneling is done between CAS trunks of two nodes.


Figure 2: CAS Tunneling between CAS Trunks of Two Node


For the CAS signaling at the third party CAS trunks at either sides, the internal CAS Tunnel and BSP signaling is transparent. Thus a third party switch can also be used to terminate the tunnel provided:

1. It can answer the tunnel setup call.

2. It should support RFC 2833 relay and detection of CAS abcd bits and DTMF digits

If you need to setup a new tunnel for a trunk group, where a tunnel is already setup, the route should be reconfigured and the ports for the trunk group should be reset so that the new tunnel is setup automatically after that.

Example of CAS Tunnel Deployment

The CAS tunnel deployment is demonstrated below. Either BSP or SIP may be used as the tunnel protocol.


Figure 3: CAS Tunnel Deployment


When the systems are started up, the node with the Master trunkgroup initiates the tunnel call to the node with the slave trunkgroup. Once the tunnel is established, all CAS signaling events are carried across the tunnel in both directions.

Example of Error Handling a CAS Tunnel

Various error scenarios are possible in this feature, mainly due to the user configuration pre-requisites. In the examples below two VX nodes are mentioned, which are named VX1 and VX2. The peer trunk groups in examples are termed TG1 and TG2. TG1 is the CAS permanent circuit trunk group in VX1 and TG2 is the CAS permanent circuit trunk group in VX2

Improper "Master"/"Slave" Configuration of Peer Trunk Groups

Both Trunk Groups Configured as Master

This case occurs due to the following user configuration error:

Both TG1 and TG2 are using channel profile for tunneled circuits in "Master" mode.

This results in channels in both sides sending setup messages for the initial connection which never gets answered. The initial connection fails and both the nodes register master mode alarms for no answer.

Both Trunk Groups Configured as Slave

This case occurs due to the following user configuration error:

Both TG1 and TG2 are using channel profiles configured as in "Slave" mode.

This results in channels in both sides waiting for setup messages which nobody is going to send. The initial connection fails and both the nodes register slave mode alarms for no setup received.

Peer Trunk Group Not Configured for Permanent Circuit

TG1 is configured using a channel profile for cas tunnel; either master or save mode. This case occurs due to the following user configuration errors:

  1. TG2 is not configured for using a tunneled cas channel profileT
  2. G2 is configured for using a tunneled cas channel profile, but the trunk was configured in a port type other than "CAS tunnel" variant.

Case 2 will be handled while verifying the configuration and hence the user will not be able to have such a configuration. In Case 1, if TG1 is master mode, the channels in TG1 send the initial setup and gets no answer, or if TG1 is in slave mode, it will never receive a setup at all.  Thus in VX1, channels in TG1 will register either a master mode alarm for no answer or a slave mode alarm for no answer received.

Slave Mode Tunnel Trunk Group Getting Calls from Two Master Trunk Groups.

This case does not result in an error scenario and works well if the number of channels in the slave trunk group is greater than the sum of channels in both the master trunk groups. An error occurs due to the following user configuration error:

Two master trunk groups have same slave trunk group as peer and the slave trunk group does not have enough termination channels configured for both the master trunk groups

In this case, the calls from the master trunk groups, after all the channels in slave trunk group are used, will not get a corresponding answer for the setup message they sent. Thus at the master side, an alarm will be registered for unanswered setup and at the slave side also alarms will be registered for unsuccessful nailed setup messages received. The details will be decided in the design.

Routing Configuration Error

This can result in nailed setup not answered or rejected. In any case the Master node re-tries the setup based on the setup retry timer. The alarm "Tunnel Setup timeout" will be registered for the channel if the setup is not answered.

CAS MRD Protocol Overview

CAS Manual Ring Down (MRD) protocol is implemented in VX and the interworking of this protocol with SIP is also implemented. This enables VX to act as a gateway between a SIP PBX and a TDM PBX running the MRD protocol. Once the call is established, VX will maintain the call in connected state unless the call has been disconnected from the SIP PBX. For this the port type is "CAS MRD" and the support for new SIP method is "INFO".

CAS MRD protocol is a customized CAS protocol which can run over T1 and E1 frames. In this protocol, a call setup is indicated by a wink in the CAS ABCD bit states. This is the only signaling involved. There is no answer supervision as well as no disconnect supervision in this protocol.

MRD is a specific CAS protocol widely used in some TDM environments for applications like rapid, 'always-on' communication between lines. Signaling is provided for an 'attention' indication, often triggered by a single button. On the line, this is indicated as a bit transition or wink.
This protocol differs from normal CAS protocols having call setup signaling, answer supervision signaling and disconnect supervision signaling for a complete call. The call setup signal indicated by the wink is the only signaling involved. Thus there is no answer supervision as well as disconnect supervision. VX will support this protocol for its interworking with standard SIP protocol. Since there is no way to convey the "call release" from the TDM side, the only way to disconnect an established call is to release it from the SIP side. Thus, the call will be in connected state until it is released from SIP side.

CAS MRD Protocol Network Layout


Figure 4: CAS MRD Protocol Network Layout


CAS MRD Protocol Call Flow Scenarios

This protocol is implemented in VX to interwork only with SIP protocol. The following are the call flow scenarios supported.

Call Flow from MRD to SIP

The CAS MRD channel on VX will wait for the wink from the MRD side to establish the call between the MRD side and SIP side. There will be no disconnect supervision signal sent to the MRD side when the call is disconnected from the SIP side. The release of the call from the SIP side will follow RFC 3261.


Figure 5: Call Flow from MRD to SIP


When VX receives a wink from the MRD side, VX will send an INVITE to the SIP side and establish the call with the SIP side. The received wink needs to hold the "seize" state for at least "Rx minimum wink duration" configured in the MRD channel profile for that wink to be considered as a valid call setup request and processed by VX. The outbound INVITE message will be sent only after the "Rx minimum wink duration" value. The media path will then be opened between the MRD end and SIP side upon successful completion of INVITE transaction.

Call Setup from SIP to MRD

VX will send a wink to the MRD end to establish a call upon successful completion of an INVITE transaction at the SIP side. There will be no disconnect supervision signal sent to the MRD side when the call is disconnected from the SIP side. The release or cancel of the call from the SIP side will follow RFC 3261.


Figure 6: Call Setup from SIP to MRD


The outbound wink duration will be as per the value for "Tx wink duration" configured in the MRD channel profile.

SIP INFO Method Support

A call that is already established does not have any disconnect supervision in CAS MRD protocol. In this protocol, it is possible for one user to desire to contact another even though the call itself has never cleared. In this case, the 'INFO' message will be used to transport this request. This case will be known in this document as "Call Refresh". Once a call is setup, call can be refreshed from either side as follows:

  • When the TDM user wants to re-contact the SIP user, a wink has to be sent to the VX by MRD end and VX will send the SIP INFO message to the SIP side.
  • When the SIP user wants to re-contact the TDM user, an INFO message has to be sent to the VX SIP side and VX will send a wink to MRD end.

The INFO message sent from VX will have the mandatory headers and the subject header. The subject header will have the data as "Call Refresh" for traceability purpose. For the incoming INFO message VX will expect only the mandatory headers and will process it for generating the wink on to the TDM side.

The INFO message implementation will be compliant with RFC2976.

An example of the INFO message sent to the SIP side:

INFO sip:2222@10.253.6.208 SIP/2.0

Via: SIP/2.0/TCP 10.253.6.223:5060;branch=z9hG4bK7bb9d4ccad68

Max-Forwards: 70

To: <sip: 2222@10.253.6.208>

From: <sip:1111@10.253.6.223>;tag=26ca0000

Call-ID: 577220090409220919998@10.253.6.223

CSeq: 458000642 INFO

Subject: Call Refresh

Content-Length: 0

Call Refresh from MRD to SIP


Figure 7: Call Refresh from MRD to SIP


If VX receives a wink from TDM side after the media path between MRD end and SIP side is established (following a successful call setup), then VX will send the INFO message to the SIP side to inform the SIP user. In order to successfully detect this wink, the received wink needs to hold the "seize" state for the configured "Rx minimum wink duration" configured in the CAS MRD channel profile. Effectively, after the start of the wink is received, the INFO message is sent to the SIP side only after "Rx minimum wink duration" value.

There will be no change in the existing media path.

Once VX detects a successful wink from the MRD side, it will act upon a subsequent wink only after the configured value "Min. call refresh interval" in CAS MRD channel profile. The default value of this interval will be 6 seconds.

Call Refresh from SIP to MRD

This scenario applies when the media path between MRD end and SIP side is established after a successful call setup. VX receives an INFO message from SIP side, then VX will process it and respond with 200 OK.VX will then send out the wink to the MRD end to recontact the MRD user. The outbound wink duration will be as per the value for "Tx wink duration" configured in the MRD channel profile. There will be no change in the existing media path.


Figure 8: Call Refresh from SIP to MRD


Example of VX Deployment for CAS MRD <=> SIP Interworking

As shown below, VX can act as a media gateway between a TDM PBX (which supports CAS MRD protocol) and a SIP PBX to maintain "always-on" connections between a TDM end point and a SIP end point.


Figure 9: VX Deployment for CAS MRD <=> SIP Internetworking


Example of Error Handling of CAS MRD Protocol

CAS MRD to SIP, Call Failure at SIP Side

In case of a call initiated from the CAS side, if the SIP signaling fails at the remote side, VX will not establish the media path and no indication will be sent to the MRD end. An alarm "MRD call setup failure at SIP outbound" will be registered if it was a call setup. Alarm "MRD call refresh failure at SIP outbound" will be registered if it was a call refresh. 

Glare Scenarios

MRD to SIP Glare Scenario During Call Setup.

If VX receives an INVITE message from the SIP side while it is waiting for the wink detection, then VX will reject the INVITE message with a 486 busy message. Once the wink detection is complete, VX will send out the INVITE message to the SIP side. Once the call is established with the SIP side, the media path between the MRD end and SIP side will be opened.


Figure 10: MRD to SIP Glare Scenario During Call Setup


SIP to TDM Glare Scenario During Call Setup

VX will ignore any CAS bit state transitions while processing an INVITE transaction from the SIP side. Once the INVITE tranction is complete, VX will send the wink to the MRD end.


Figure 11: SIP to TDM Glare Scenario During Call Setup


MRD to SIP with Glare Scenario During Call Refresh

During a call refresh from MRD end, if an INFO message is received while validating a wink received from the TDM side, then the INFO message will be rejected with "486 User Busy" response. Once the MRD wink holds for the configured "Rx minimum wink duration", VX will send the INFO message to the SIP side. There will be no change in the existing media path.


Figure 12: MRD to SIP with Glare Scenario During Call Refresh


SIP to MRD Glare Scenario During Call Refresh

This scenario applies when the media path between MRD end and SIP side is established after a successful call setup. VX will ignore any CAS bit state transitions while processing an INFO message from SIP side. VX will respond to the INFO message with 200 OK and then send a wink to the MRD end to recontact the MRD user. This wink should be ignored by the remote MRD end in case the user is still off-hook and is waiting for audio.


Figure 13: SIP to MRD Glare Scenario During Call Refresh


Common Configuration Concepts

The following new configuration concepts will be introduced for this feature which is common to both "CAS Tunnel" as well as "CAS MRD":

  • Ring Down Destination Number
  • Own Number
  • Hunt type of "Match own number"

These new concepts are related to each other and their purpose and intended functionality is explained below. User will be provided ability to configure "Ring Down Destination Number" and "Own Number" for channels of type "CAS Tunnel" and "CAS MRD" at the timeslot configuration as well as in channel profile configuration. The values configured in timeslot configuration holds precedence if the parameters are configured at both the places. The internal calls required for this tunnels setup will use these values.Thus when a tunnel "SETUP" originates from a master channel, its configured "Ring Down Destination" will be used as the called party number and the "Own Number" will be used as the calling party number. Route may be configured in the same node for routing the tunneled SETUP to the appropriate remote node based on the "Ring Down destination" configured for the master channel involved. In the remote node route should be configured for this same number pointing to the required tunneled CAS trunk group. The new outbound channel hunt type "own number match" will be provided for selecting the outbound channel with the "Own Number" same as "Called Party Number" for a call. Thus from a trunk group selected for terminating the call, a channel will be selected through hunting only if the incoming "called party number" of the call is same as the "own number" configured for the candidate channel.This enables a one to one timeslot level mapping of the CAS trunks.

To summarize, following are the configuration enhancements:

1. Configuration of  "Ring Down Destination Number" and "Own Number" in the timeslot configuration for port type of "CAS Tunnel" and "CAS MRD".

2. Configuration of "Ring Down Destination Number" and "Own Number" in the CAS tunnel and CAS MRD channel profiles. This will be useful if the user does not want a custom timeslot configuration and wants to configure "Ring Down Destination Number" and "Own Number" at a port level.

3. Configuration in timeslot configuration has more precedence than configuration in channel profile.

4. New hunt type of "own number match" will be added to the existing list which can be selected currently from a trunk group. This will be same as the existing "standard" hunting algorithm, but an outbound channel will be selected only if the "called party number" of the call matches the "own number" of the terminating channel.

5. Config verify error will be thrown for a "CAS tunnel" master channel and "CAS MRD" channel if "Ring Down destination" is not configured. This prevents initial call setup failure due to missing called party number.

6. Config verify error will be thrown if "Own Number" is not configured for a "CAS Tunnel" "slave" channel or "CAS MRD" channel, if it is within a trunk group with hunt type "own number match" configured. This prevents tunnel setup failure due to missing "own number" for a terminating channel.

7. Config verify error will be thrown if the hunt type of "own number match" is configured for a port type which is not "CAS Tunnel" or "CAS MRD". This prevents call failures in other protocol due to usage of hunt type "own number match" in trunk groups. This is required because "own number" can be configured only for channel types of "CAS Tunnel" and "CAS MRD",and a channel cannot be selected for call termination using hunt type of "own number match" if a "own number" is not configured.

Points to be noted:

1. Configuration of "Ring Down Destination Number" and "Own Number" will be provided only on the port type and channel profile of type"CAS Tunnel" and "CAS MRD". This is  not supported for any other protocol, not even other regular CAS variants.

2. Configuration in timeslot configuration has more precedence than configuration in channel profile. There will be no default values for these numbers, but since a blank value configuration will result in call setup failure, a configuration verify check will prevent the user from having a configuration with blank mandatory parameters. This restriction is ensured by config verify checks mentioned in points 5 and 6 above

3. The new hunt type of "own number match" can be configured only over port type of "CAS tunnel" and "CAS MRD". This prevents the usage of this hunt type in the other protocol trunk groups. This is done because other protocol channels don't have "Own number" configuration to match. This restriction is ensured by config verify check mentioned in point 7 above.

4. For a "CAS Tunnel" master channel, "Ringdown Destination" will be the called party number and "Own-Number" will be the calling party number in the tunnel setup message. For a "CAS MRD" inbound channel, "Ringdown Destination" will be the called party number and "Own-Number" will be the calling party number passed to the peer SIP channel. As a result these corresponding numbers will appear in the INVITE message generated corresponding to a "CAS MRD" wink.

5. For a slave channel, two cases are possible:

a. If the trunk group is configured with a hunt type of "own number match", a  "setup" terminating to that channel will be answered only if the setup message contains its "own number" as the "called party number". Otherwise tunnel setup fails in the second node for outbound channel hunting.

b.If the trunk group is configured with any other hunt type, number match is not in effect and any setup routed normally to that trunk group will be answered and tunnel will be set up.

6. For an outbound call on a "CAS MRD" channel, following two cases are possible if "own number" is configured for the channel:

a. If the trunk group for the channel is configured with a hunt type of "own number match", a  call terminating to that channel will be answered only if the call has the "called party number" same as the "own number" of the channel. Otherwise tunnel setup fails for outbound channel hunting.

b. If the trunk group is configured with any other hunt type, number match is not in effect and any call routed normally to that trunk group will be forwarded as an outbound MRD wink.

7. For a slave channel, the "Ring down destination number" is not mandatory to configure, because it is not used for any validation while a call is terminating to a slave channel. So there will be no configuration restriction in this regard and user will be able to leave "Ring down destination number" blank for a slave channel if he chooses to.

8. For a master channel, configuring "Own number" is not mandatory because for a master channel, presence of a valid "ring down destination" is the necessary and sufficient condition for a successful tunnel setup. So there will be no configuration restriction in this regard and user will be able to leave "Own Number" blank for a master channel if he chooses to. If this happens the tunnel setup will not have a "calling party number". Same applies for a "CAS MRD" channel also.

  • No labels