TBwiki - User contributions [en]

FN17753

2015-06-17T20:07:49Z

Clod Patry: specify which version are affected (5.3.2.2-25)

{{DISPLAYTITLE:FN17753 - Net-SNMP restarts and is generating core files}}

= Affected Products =
* TMG800, TMG3200, TMG7800-CTRL
* Tdev Linux server with (CentOS, RedHat, etc) running Toolpack software

= Problem Description =
* snmpd process continuously restarts in a loop.
* System which are shipped before April 2015 requires this fix.
* This fix is applicable if you have an older net-snmp version than below. To verify:
[root@TB011107 tbsnmpagent]# rpm -qa | grep snmp
net-snmp-libs-5.3.2.2-25.el5.tb
net-snmp-utils-5.3.2.2-25.el5.tb
net-snmp-5.3.2.2-25.el5.tb

If you have version previous to this one (5.3.2.2-25), you are affected by this Field Notice.

= Problem Symptoms =
* core files are observed in tbsnmpagent directory:
/mnt/.0/tb/toolpack/setup/12358/2.8/apps/tbsnmpagent

= Solution =
== Online Procedures ==
Applicable if the system has internet access with proper DNS configuration and is able to reach the TelcoBridges repositories server.

* Stop Toolpack
tbtoolpack stop
* Make sure your system is pointing to the TelcoBridges repositories. Verify the following TelcoBridges repository file:
vim /etc/yum.repos.d/TB-Base.repo

# TelcoBridges-Base.repo
#
# This repository is using TelcoBridges frozen version of CentOS
# to help client installing the required version of the
# applications required to run Toolpack
#

[tb-base]
name=TelcoBridges-$releasever - Base
baseurl=http://repo.telcobridges.com/centos/5/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

#released updates
[tb-updates]
name=TelcoBridges-$releasever - Updates
baseurl=http://repo.telcobridges.com/centos/5/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5-tb

* Get TelcoBridges repository key. If you don't already have them.
cd /etc/pki/rpm-gpg/
wget http://repo.telcobridges.com/centos/RPM-GPG-KEY-CentOS-5
wget http://repo.telcobridges.com/centos/RPM-GPG-KEY-CentOS-5-tb
* Update your net-snmp to the latest version
yum update net-snmp*
* Verify the updated net-snmp version. You should see:
[root@TB011107 tbsnmpagent]# yum list net-snmp
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* tb-base: repo.telcobridges.com
* tb-updates: repo.telcobridges.com
Excluding Packages in global exclude list
Finished
Installed Packages
net-snmp.x86_64 1:5.3.2.2-25.el5.tb installed
* Start Toolpack
tbtoolpack start

== Offline Procedures ==
Applicable for systems which are behind the firewall in a private network without internet access.

* Stop Toolpack
tbtoolpack stop
* Remove net-snmp. Confirm removal with "Y" when prompted.
yum remove net-snmp
* Manually install below RPMs:
rpm -ivhU net-snmp-libs-5.3.2.2-25.el5.tb.x86_64.rpm
rpm -ivhU net-snmp-5.3.2.2-25.el5.tb.x86_64.rpm
rpm -ivhU net-snmp-utils-5.3.2.2-25.el5.tb.x86_64.rpm
* Above files can be found at:
http://repo.telcobridges.com/centos/5/os/x86_64/CentOS/
* Verify the updated net-snmp version. You should see:
[root@TB011107 tbsnmpagent]# yum list net-snmp
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* tb-base: repo.telcobridges.com
* tb-updates: repo.telcobridges.com
Excluding Packages in global exclude list
Finished
Installed Packages
net-snmp.x86_64 1:5.3.2.2-25.el5.tb installed
* Start Toolpack
tbtoolpack start

FN17753

2015-06-17T20:04:17Z

Clod Patry: Force to update only net-snmp instead of the whole system.

{{DISPLAYTITLE:FN17753 - Net-SNMP restarts and is generating core files}}

= Affected Products =
* TMG800, TMG3200, TMG7800-CTRL
* Tdev Linux server with (CentOS, RedHat, etc) running Toolpack software

= Problem Description =
* snmpd process continuously restarts in a loop.
* System which are shipped before April 2015 requires this fix.
* This fix is applicable if you have an older net-snmp version than below. To verify:
[root@TB011107 tbsnmpagent]# rpm -qa | grep snmp
net-snmp-libs-5.3.2.2-25.el5.tb
net-snmp-utils-5.3.2.2-25.el5.tb
net-snmp-5.3.2.2-25.el5.tb

= Problem Symptoms =
* core files are observed in tbsnmpagent directory:
/mnt/.0/tb/toolpack/setup/12358/2.8/apps/tbsnmpagent

= Solution =
== Online Procedures ==
Applicable if the system has internet access with proper DNS configuration and is able to reach the TelcoBridges repositories server.

* Stop Toolpack
tbtoolpack stop
* Make sure your system is pointing to the TelcoBridges repositories. Verify the following TelcoBridges repository file:
vim /etc/yum.repos.d/TB-Base.repo

# TelcoBridges-Base.repo
#
# This repository is using TelcoBridges frozen version of CentOS
# to help client installing the required version of the
# applications required to run Toolpack
#

[tb-base]
name=TelcoBridges-$releasever - Base
baseurl=http://repo.telcobridges.com/centos/5/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

#released updates
[tb-updates]
name=TelcoBridges-$releasever - Updates
baseurl=http://repo.telcobridges.com/centos/5/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5-tb

* Get TelcoBridges repository key. If you don't already have them.
cd /etc/pki/rpm-gpg/
wget http://repo.telcobridges.com/centos/RPM-GPG-KEY-CentOS-5
wget http://repo.telcobridges.com/centos/RPM-GPG-KEY-CentOS-5-tb
* Update your net-snmp to the latest version
yum update net-snmp*
* Verify the updated net-snmp version. You should see:
[root@TB011107 tbsnmpagent]# yum list net-snmp
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* tb-base: repo.telcobridges.com
* tb-updates: repo.telcobridges.com
Excluding Packages in global exclude list
Finished
Installed Packages
net-snmp.x86_64 1:5.3.2.2-25.el5.tb installed
* Start Toolpack
tbtoolpack start

== Offline Procedures ==
Applicable for systems which are behind the firewall in a private network without internet access.

* Stop Toolpack
tbtoolpack stop
* Remove net-snmp. Confirm removal with "Y" when prompted.
yum remove net-snmp
* Manually install below RPMs:
rpm -ivhU net-snmp-libs-5.3.2.2-25.el5.tb.x86_64.rpm
rpm -ivhU net-snmp-5.3.2.2-25.el5.tb.x86_64.rpm
rpm -ivhU net-snmp-utils-5.3.2.2-25.el5.tb.x86_64.rpm
* Above files can be found at:
http://repo.telcobridges.com/centos/5/os/x86_64/CentOS/
* Verify the updated net-snmp version. You should see:
[root@TB011107 tbsnmpagent]# yum list net-snmp
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* tb-base: repo.telcobridges.com
* tb-updates: repo.telcobridges.com
Excluding Packages in global exclude list
Finished
Installed Packages
net-snmp.x86_64 1:5.3.2.2-25.el5.tb installed
* Start Toolpack
tbtoolpack start

FN17753

2015-06-17T19:42:39Z

Clod Patry: update the link for offline procedures.

{{DISPLAYTITLE:FN17753 - Net-SNMP restarts and is generating core files}}

= Affected Products =
* TMG800, TMG3200, TMG7800-CTRL
* Tdev Linux server with (CentOS, RedHat, etc) running Toolpack software

= Problem Description =
* snmpd process continuously restarts in a loop.
* System which are shipped before April 2015 requires this fix.
* This fix is applicable if you have an older net-snmp version than below. To verify:
[root@TB011107 tbsnmpagent]# rpm -qa | grep snmp
net-snmp-libs-5.3.2.2-25.el5.tb
net-snmp-utils-5.3.2.2-25.el5.tb
net-snmp-5.3.2.2-25.el5.tb

= Problem Symptoms =
* core files are observed in tbsnmpagent directory:
/mnt/.0/tb/toolpack/setup/12358/2.8/apps/tbsnmpagent

= Solution =
== Online Procedures ==
Applicable if the system has internet access with proper DNS configuration and is able to reach the TelcoBridges repositories server.

* Stop Toolpack
tbtoolpack stop
* Make sure your system is pointing to the TelcoBridges repositories. Verify the following TelcoBridges repository file:
vim /etc/yum.repos.d/TB-Base.repo

# TelcoBridges-Base.repo
#
# This repository is using TelcoBridges frozen version of CentOS
# to help client installing the required version of the
# applications required to run Toolpack
#

[tb-base]
name=TelcoBridges-$releasever - Base
baseurl=http://repo.telcobridges.com/centos/5/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

#released updates
[tb-updates]
name=TelcoBridges-$releasever - Updates
baseurl=http://repo.telcobridges.com/centos/5/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5-tb

* Get TelcoBridges repository key. If you don't already have them.
cd /etc/pki/rpm-gpg/
wget http://repo.telcobridges.com/centos/RPM-GPG-KEY-CentOS-5
wget http://repo.telcobridges.com/centos/RPM-GPG-KEY-CentOS-5-tb
* Update your system to the latest version
yum update
* Verify the updated net-snmp version. You should see:
[root@TB011107 tbsnmpagent]# yum list net-snmp
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* tb-base: repo.telcobridges.com
* tb-updates: repo.telcobridges.com
Excluding Packages in global exclude list
Finished
Installed Packages
net-snmp.x86_64 1:5.3.2.2-25.el5.tb installed
* Start Toolpack
tbtoolpack start

== Offline Procedures ==
Applicable for systems which are behind the firewall in a private network without internet access.

* Stop Toolpack
tbtoolpack stop
* Remove net-snmp. Confirm removal with "Y" when prompted.
yum remove net-snmp
* Manually install below RPMs:
rpm -ivhU net-snmp-libs-5.3.2.2-25.el5.tb.x86_64.rpm
rpm -ivhU net-snmp-5.3.2.2-25.el5.tb.x86_64.rpm
rpm -ivhU net-snmp-utils-5.3.2.2-25.el5.tb.x86_64.rpm
* Above files can be found at:
http://repo.telcobridges.com/centos/5/os/x86_64/CentOS/
* Verify the updated net-snmp version. You should see:
[root@TB011107 tbsnmpagent]# yum list net-snmp
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* tb-base: repo.telcobridges.com
* tb-updates: repo.telcobridges.com
Excluding Packages in global exclude list
Finished
Installed Packages
net-snmp.x86_64 1:5.3.2.2-25.el5.tb installed
* Start Toolpack
tbtoolpack start

Voice codecs

2015-05-22T20:30:01Z

Clod Patry: Adding G722.

TelcoBridges products support the following voice codecs.

== Supported codecs ==
 

*'''Universal codecs'''
**[http://en.wikipedia.org/wiki/G.711 G.711] - Supported packet durations: 20,30,40,50 and 60 msec
**[http://en.wikipedia.org/wiki/G.722 G.722] - Supported packet durations: 20,30,40,50 and 60 msec
**[http://en.wikipedia.org/wiki/G.723.1 G.723.1] - Supported packet durations: 30,60 and 90 msec
**[http://en.wikipedia.org/wiki/G.726 G.726] - Supported packet durations: 20,30,40,50 and 60 msec
**[http://en.wikipedia.org/wiki/G.729 G.729a/ab] - Supported packet durations: 20,30,40,50,60,70 and 80 msec
**[[Clearmode]] ([http://tools.ietf.org/html/rfc4040 rfc4040]) - Supported packet durations: 5,10,20,30,40,50,60 msec
**[http://en.wikipedia.org/wiki/T.38 T.38]

*'''Wireline codecs'''
**[http://en.wikipedia.org/wiki/G.728 G.728] - Supported packet durations: 20,30,40,50 and 60 msec
**[http://en.wikipedia.org/wiki/G.729 G.729eg] - Supported packet durations: 20,30,40,50,60,70 and 80 msec
**[http://en.wikipedia.org/wiki/Internet_Low_Bit_Rate_Codec iLBC] - Supported packet durations: [13kbps] 30 and 60 msec, [15kpbs] 20 and 40 msec

*'''Wireless codecs''' '''1'''
**[http://en.wikipedia.org/wiki/Adaptive_multi-rate_compression AMR] - Supported packet durations: 20,40,60 and 80 msec
**[http://en.wikipedia.org/wiki/Full_Rate GSM-FR] - Supported packet durations: 20 and 30 msec
**[http://en.wikipedia.org/wiki/Enhanced_Full_Rate GSM-EFR] - Supported packet durations: 20,40 and 60 msec
**[http://en.wikipedia.org/wiki/EVRC EVRC] - Supported packet durations: 20,40 and 60 msec
**[http://en.wikipedia.org/wiki/QCELP QCELP] - Supported packet durations: 20,40 and 60 msec
**[[G.722.2 (AMR-WB)]] - Supported packet durations: 20,40,60 and 80 msec
 

== TMG media gateways codec capacity ==
 
{| cellpadding="5" border="1" class="wikitable" style="text-align: center"
|-
! width="40" rowspan="2" | Media Gateway
! width="400" colspan="7" | Universal codecs
! width="240" colspan="3" | Other codecs
! width="320" colspan="4" | Wireless codecs'''1'''
|-
! width="80" | G.711
! width="80" | G.722
! width="80" | G.723.1
! width="80" | G.726
! width="80" | G.729ab
! width="80" | T.38
! width="80" | clearmode (rfc4040)
! width="80" | G.728
! width="80" | G.729eg
! width="80" | iLBC
! width="80" | AMR
! width="80" | AMR-WB
! width="80" | GSM-FR/GSM-EFR
! width="80" | EVRC/QCELP
|-
| TMG800-8 TMG3200-RJ8
| 256 || 118 || 254 || 256 || 256 || 254 || 256 || 116 || 128 || 150 || 182 || 118 || 214 || 190
|-
| TMG3200-RJ16 TMG3200-TE16 TMG7800-TE16
| 512 || 236 || 508 || 512 || 512 || 508 || 512 || 232 || 256 || 300 || 364 || 236 || 428 || 380
|-
| TMG3200-TE32 TMG7800-TE32
| 1024 || 472 || 1016 || 1024 || 1024 || 1016 || 1024|| 464 || 512 || 600 || 728 || 472 || 856 || 760
|-
| TMG3200-TE48 TMG7800-TE48
| 1536 || 708 || 1524 || 1536 || 1536 || 1524 || 1536 || 696 || 768 || 900 || 1092 || 708 || 1284 || 1140
|-
| TMG3200-TE64 TMG7800-TE64 TMG3200-STM1 TMG7800-STM1
| 2048 || 944 ||2032 || 2048 || 2048 || 2032 || 2048 || 928 || 1024 || 1200 || 1456 || 944 || 1712 || 1520
|}

== Tdev development platform ==

=== TMP6400 Codec density ===
Codec density is comprised of two modes:
*Mixed Mode
*Fixed Mode
 

==== Mixed Mode ====

The following densities are achieved when a codec mix is dynamically negotiated.
{| cellpadding="5" border="1" class="wikitable" style="text-align: center"
|-
! width="150" rowspan="2" | Type of
VoIP mezzanine
! width="400" colspan="6" | Universal codecs
! width="240" colspan="3" | Other codecs
! width="320" colspan="4" | Wireless codecs'''1'''
|-
! width="80" | G.711
! width="80" | G.722
! width="80" | G.723.1
! width="80" | G.726
! width="80" | G.729ab
! width="80" | T.38
! width="80" | G.728
! width="80" | G.729eg
! width="80" | iLBC
! width="80" | AMR
! width="80" | AMR-WB
! width="80" | GSM-FR/GSM-EFR
! width="80" | EVRC/QCELP
|-
| TM-VOIP-1
| 341
| 59
| 127
| 169
| 154
| 127
| 58
| 64
| 75
| 91
| 59
| 107
| 95
|-
| TM-VOIP-2
| 682
| 118
| 254
| 338
| 308
| 254
| 116
| 128
| 150
| 182
| 118
| 214
| 190
|-
| TM-VOIP-3
| 1023
| 177
| 381
| 507
| 462
| 381
| 174
| 192
| 225
| 273
| 177
| 321
| 285
|-
| TM-VOIP-4
| 1364
| 236
| 508
| 676
| 616
| 508
| 232
| 256
| 300
| 364
| 236
| 428
| 380
|}

==== Fixed mode ====

The following densities are achieved when a codec mix is predefined.
{| cellpadding="5" border="1" class="wikitable" style="text-align: center"
|-
! width="150" rowspan="2" | Type of.
VoIP mezzanine
! width="400" colspan="6" | Universal codecs
! width="240" colspan="3" | Other codecs
! width="320" colspan="4" | Wireless codecs'''1'''
|-
! width="80" | G.711
! width="80" | G.722
! width="80" | G.723.1
! width="80" | G.726
! width="80" | G.729ab
! width="80" | T.38
! width="80" | G.728
! width="80" | G.729eg
! width="80" | iLBC
! width="80" | AMR
! width="80" | AMR-WB
! width="80" | GSM-FR/GSM-EFR
! width="80" | EVRC/QCELP
|-
| TM-VOIP-1
| 404
| 60
| 128
| 200
| 168
| 128
| 66
| 72
| 84
| 102
| 60
| 120
| 96
|-
| TM-VOIP-2
| 808
| 120
| 256
| 400
| 336
| 256
| 132
| 144
| 168
| 204
| 120
| 240
| 192
|-
| TM-VOIP-3
| 1212
| 180
| 384
| 600
| 504
| 384
| 198
| 216
| 252
| 306
| 180
| 360
| 288
|-
| TM-VOIP-4
| 1616
| 240
| 512
| 800
| 672
| 512
| 264
| 288
| 336
| 408
| 240
| 480
| 384
|}

['''1'''] May require additional licenses

[[Category:Glossary]]
[[Category:Tmedia_Features|Voice Codecs]]
[[Category:Tdev_Features|Voice Codecs]]
[[Category:Needs_revising]]
[[Category:Revise on Major]]

Voice codecs

2015-05-22T20:12:22Z

Clod Patry: Adding G722

TelcoBridges products support the following voice codecs.

== Supported codecs ==
 

*'''Universal codecs'''
**[http://en.wikipedia.org/wiki/G.711 G.711] - Supported packet durations: 20,30,40,50 and 60 msec
**[http://en.wikipedia.org/wiki/G.722 G.722] - Supported packet durations: 20,30,40,50 and 60 msec
**[http://en.wikipedia.org/wiki/G.723.1 G.723.1] - Supported packet durations: 30,60 and 90 msec
**[http://en.wikipedia.org/wiki/G.726 G.726] - Supported packet durations: 20,30,40,50 and 60 msec
**[http://en.wikipedia.org/wiki/G.729 G.729a/ab] - Supported packet durations: 20,30,40,50,60,70 and 80 msec
**[[Clearmode]] ([http://tools.ietf.org/html/rfc4040 rfc4040]) - Supported packet durations: 5,10,20,30,40,50,60 msec
**[http://en.wikipedia.org/wiki/T.38 T.38]

*'''Wireline codecs'''
**[http://en.wikipedia.org/wiki/G.728 G.728] - Supported packet durations: 20,30,40,50 and 60 msec
**[http://en.wikipedia.org/wiki/G.729 G.729eg] - Supported packet durations: 20,30,40,50,60,70 and 80 msec
**[http://en.wikipedia.org/wiki/Internet_Low_Bit_Rate_Codec iLBC] - Supported packet durations: [13kbps] 30 and 60 msec, [15kpbs] 20 and 40 msec

*'''Wireless codecs''' '''1'''
**[http://en.wikipedia.org/wiki/Adaptive_multi-rate_compression AMR] - Supported packet durations: 20,40,60 and 80 msec
**[http://en.wikipedia.org/wiki/Full_Rate GSM-FR] - Supported packet durations: 20 and 30 msec
**[http://en.wikipedia.org/wiki/Enhanced_Full_Rate GSM-EFR] - Supported packet durations: 20,40 and 60 msec
**[http://en.wikipedia.org/wiki/EVRC EVRC] - Supported packet durations: 20,40 and 60 msec
**[http://en.wikipedia.org/wiki/QCELP QCELP] - Supported packet durations: 20,40 and 60 msec
**[[G.722.2 (AMR-WB)]] - Supported packet durations: 20,40,60 and 80 msec
 

== TMG media gateways codec capacity ==
 
{| cellpadding="5" border="1" class="wikitable" style="text-align: center"
|-
! width="40" rowspan="2" | Media Gateway
! width="400" colspan="6" | Universal codecs
! width="240" colspan="3" | Other codecs
! width="320" colspan="4" | Wireless codecs'''1'''
|-
! width="80" | G.711
! width="80" | G.723.1
! width="80" | G.726
! width="80" | G.729ab
! width="80" | T.38
! width="80" | clearmode (rfc4040)
! width="80" | G.728
! width="80" | G.729eg
! width="80" | iLBC
! width="80" | AMR
! width="80" | AMR-WB
! width="80" | GSM-FR/GSM-EFR
! width="80" | EVRC/QCELP
|-
| TMG800-8 TMG3200-RJ8
| 256 || 254 || 256 || 256 || 254 || 256 || 116 || 128 || 150 || 182 || 118 || 214 || 190
|-
| TMG3200-RJ16 TMG3200-TE16 TMG7800-TE16
| 512 || 508 || 512 || 512 || 508 || 512 || 232 || 256 || 300 || 364 || 236 || 428 || 380
|-
| TMG3200-TE32 TMG7800-TE32
| 1024 || 1016 || 1024 || 1024 || 1016 || 1024|| 464 || 512 || 600 || 728 || 472 || 856 || 760
|-
| TMG3200-TE48 TMG7800-TE48
| 1536 || 1524 || 1536 || 1536 || 1524 || 1536 || 696 || 768 || 900 || 1092 || 708 || 1284 || 1140
|-
| TMG3200-TE64 TMG7800-TE64 TMG3200-STM1 TMG7800-STM1
| 2048 || 2032 || 2048 || 2048 || 2032 || 2048 || 928 || 1024 || 1200 || 1456 || 944 || 1712 || 1520
|}

== Tdev development platform ==

=== TMP6400 Codec density ===
Codec density is comprised of two modes:
*Mixed Mode
*Fixed Mode
 

==== Mixed Mode ====

The following densities are achieved when a codec mix is dynamically negotiated.
{| cellpadding="5" border="1" class="wikitable" style="text-align: center"
|-
! width="150" rowspan="2" | Type of
VoIP mezzanine
! width="400" colspan="6" | Universal codecs
! width="240" colspan="3" | Other codecs
! width="320" colspan="4" | Wireless codecs'''1'''
|-
! width="80" | G.711
! width="80" | G.722
! width="80" | G.723.1
! width="80" | G.726
! width="80" | G.729ab
! width="80" | T.38
! width="80" | G.728
! width="80" | G.729eg
! width="80" | iLBC
! width="80" | AMR
! width="80" | AMR-WB
! width="80" | GSM-FR/GSM-EFR
! width="80" | EVRC/QCELP
|-
| TM-VOIP-1
| 341
| 59
| 127
| 169
| 154
| 127
| 58
| 64
| 75
| 91
| 59
| 107
| 95
|-
| TM-VOIP-2
| 682
| 118
| 254
| 338
| 308
| 254
| 116
| 128
| 150
| 182
| 118
| 214
| 190
|-
| TM-VOIP-3
| 1023
| 177
| 381
| 507
| 462
| 381
| 174
| 192
| 225
| 273
| 177
| 321
| 285
|-
| TM-VOIP-4
| 1364
| 236
| 508
| 676
| 616
| 508
| 232
| 256
| 300
| 364
| 236
| 428
| 380
|}

==== Fixed mode ====

The following densities are achieved when a codec mix is predefined.
{| cellpadding="5" border="1" class="wikitable" style="text-align: center"
|-
! width="150" rowspan="2" | Type of.
VoIP mezzanine
! width="400" colspan="6" | Universal codecs
! width="240" colspan="3" | Other codecs
! width="320" colspan="4" | Wireless codecs'''1'''
|-
! width="80" | G.711
! width="80" | G.722
! width="80" | G.723.1
! width="80" | G.726
! width="80" | G.729ab
! width="80" | T.38
! width="80" | G.728
! width="80" | G.729eg
! width="80" | iLBC
! width="80" | AMR
! width="80" | AMR-WB
! width="80" | GSM-FR/GSM-EFR
! width="80" | EVRC/QCELP
|-
| TM-VOIP-1
| 404
| 60
| 128
| 200
| 168
| 128
| 66
| 72
| 84
| 102
| 60
| 120
| 96
|-
| TM-VOIP-2
| 808
| 120
| 256
| 400
| 336
| 256
| 132
| 144
| 168
| 204
| 120
| 240
| 192
|-
| TM-VOIP-3
| 1212
| 180
| 384
| 600
| 504
| 384
| 198
| 216
| 252
| 306
| 180
| 360
| 288
|-
| TM-VOIP-4
| 1616
| 240
| 512
| 800
| 672
| 512
| 264
| 288
| 336
| 408
| 240
| 480
| 384
|}

['''1'''] May require additional licenses

[[Category:Glossary]]
[[Category:Tmedia_Features|Voice Codecs]]
[[Category:Tdev_Features|Voice Codecs]]
[[Category:Needs_revising]]
[[Category:Revise on Major]]

Voice codecs

2015-05-22T20:11:05Z

Clod Patry: adding G722.

TelcoBridges products support the following voice codecs.

== Supported codecs ==
 

*'''Universal codecs'''
**[http://en.wikipedia.org/wiki/G.711 G.711] - Supported packet durations: 20,30,40,50 and 60 msec
**[http://en.wikipedia.org/wiki/G.722 G.722] - Supported packet durations: 20,30,40,50 and 60 msec
**[http://en.wikipedia.org/wiki/G.723.1 G.723.1] - Supported packet durations: 30,60 and 90 msec
**[http://en.wikipedia.org/wiki/G.726 G.726] - Supported packet durations: 20,30,40,50 and 60 msec
**[http://en.wikipedia.org/wiki/G.729 G.729a/ab] - Supported packet durations: 20,30,40,50,60,70 and 80 msec
**[[Clearmode]] ([http://tools.ietf.org/html/rfc4040 rfc4040]) - Supported packet durations: 5,10,20,30,40,50,60 msec
**[http://en.wikipedia.org/wiki/T.38 T.38]

*'''Wireline codecs'''
**[http://en.wikipedia.org/wiki/G.728 G.728] - Supported packet durations: 20,30,40,50 and 60 msec
**[http://en.wikipedia.org/wiki/G.729 G.729eg] - Supported packet durations: 20,30,40,50,60,70 and 80 msec
**[http://en.wikipedia.org/wiki/Internet_Low_Bit_Rate_Codec iLBC] - Supported packet durations: [13kbps] 30 and 60 msec, [15kpbs] 20 and 40 msec

*'''Wireless codecs''' '''1'''
**[http://en.wikipedia.org/wiki/Adaptive_multi-rate_compression AMR] - Supported packet durations: 20,40,60 and 80 msec
**[http://en.wikipedia.org/wiki/Full_Rate GSM-FR] - Supported packet durations: 20 and 30 msec
**[http://en.wikipedia.org/wiki/Enhanced_Full_Rate GSM-EFR] - Supported packet durations: 20,40 and 60 msec
**[http://en.wikipedia.org/wiki/EVRC EVRC] - Supported packet durations: 20,40 and 60 msec
**[http://en.wikipedia.org/wiki/QCELP QCELP] - Supported packet durations: 20,40 and 60 msec
**[[G.722.2 (AMR-WB)]] - Supported packet durations: 20,40,60 and 80 msec
 

== TMG media gateways codec capacity ==
 
{| cellpadding="5" border="1" class="wikitable" style="text-align: center"
|-
! width="40" rowspan="2" | Media Gateway
! width="400" colspan="6" | Universal codecs
! width="240" colspan="3" | Other codecs
! width="320" colspan="4" | Wireless codecs'''1'''
|-
! width="80" | G.711
! width="80" | G.723.1
! width="80" | G.726
! width="80" | G.729ab
! width="80" | T.38
! width="80" | clearmode (rfc4040)
! width="80" | G.728
! width="80" | G.729eg
! width="80" | iLBC
! width="80" | AMR
! width="80" | AMR-WB
! width="80" | GSM-FR/GSM-EFR
! width="80" | EVRC/QCELP
|-
| TMG800-8 TMG3200-RJ8
| 256 || 254 || 256 || 256 || 254 || 256 || 116 || 128 || 150 || 182 || 118 || 214 || 190
|-
| TMG3200-RJ16 TMG3200-TE16 TMG7800-TE16
| 512 || 508 || 512 || 512 || 508 || 512 || 232 || 256 || 300 || 364 || 236 || 428 || 380
|-
| TMG3200-TE32 TMG7800-TE32
| 1024 || 1016 || 1024 || 1024 || 1016 || 1024|| 464 || 512 || 600 || 728 || 472 || 856 || 760
|-
| TMG3200-TE48 TMG7800-TE48
| 1536 || 1524 || 1536 || 1536 || 1524 || 1536 || 696 || 768 || 900 || 1092 || 708 || 1284 || 1140
|-
| TMG3200-TE64 TMG7800-TE64 TMG3200-STM1 TMG7800-STM1
| 2048 || 2032 || 2048 || 2048 || 2032 || 2048 || 928 || 1024 || 1200 || 1456 || 944 || 1712 || 1520
|}

== Tdev development platform ==

=== TMP6400 Codec density ===
Codec density is comprised of two modes:
*Mixed Mode
*Fixed Mode
 

==== Mixed Mode ====

The following densities are achieved when a codec mix is dynamically negotiated.
{| cellpadding="5" border="1" class="wikitable" style="text-align: center"
|-
! width="150" rowspan="2" | Type of
VoIP mezzanine
! width="400" colspan="6" | Universal codecs
! width="240" colspan="3" | Other codecs
! width="320" colspan="4" | Wireless codecs'''1'''
|-
! width="80" | G.711
! width="80" | G.722
! width="80" | G.723.1
! width="80" | G.726
! width="80" | G.729ab
! width="80" | T.38
! width="80" | G.728
! width="80" | G.729eg
! width="80" | iLBC
! width="80" | AMR
! width="80" | AMR-WB
! width="80" | GSM-FR/GSM-EFR
! width="80" | EVRC/QCELP
|-
| TM-VOIP-1
| 341
| 59
| 127
| 169
| 154
| 127
| 58
| 64
| 75
| 91
| 59
| 107
| 95
|-
| TM-VOIP-2
| 682
| 118
| 254
| 338
| 308
| 254
| 116
| 128
| 150
| 182
| 118
| 214
| 190
|-
| TM-VOIP-3
| 1023
| 177
| 381
| 507
| 462
| 381
| 174
| 192
| 225
| 273
| 177
| 321
| 285
|-
| TM-VOIP-4
| 1364
| 236
| 508
| 676
| 616
| 508
| 232
| 256
| 300
| 364
| 236
| 428
| 380
|}

==== Fixed mode ====

The following densities are achieved when a codec mix is predefined.
{| cellpadding="5" border="1" class="wikitable" style="text-align: center"
|-
! width="150" rowspan="2" | Type of.
VoIP mezzanine
! width="400" colspan="5" | Universal codecs
! width="240" colspan="3" | Other codecs
! width="320" colspan="4" | Wireless codecs'''1'''
|-
! width="80" | G.711.
! width="80" | G.723.1
! width="80" | G.726
! width="80" | G.729ab
! width="80" | T.38
! width="80" | G.728
! width="80" | G.729eg
! width="80" | iLBC
! width="80" | AMR
! width="80" | AMR-WB
! width="80" | GSM-FR/GSM-EFR
! width="80" | EVRC/QCELP
|-
| TM-VOIP-1
| 404
| 128
| 200
| 168
| 128
| 66
| 72
| 84
| 102
| 60
| 120
| 96
|-
| TM-VOIP-2
| 808
| 256
| 400
| 336
| 256
| 132
| 144
| 168
| 204
| 120
| 240
| 192
|-
| TM-VOIP-3
| 1212
| 384
| 600
| 504
| 384
| 198
| 216
| 252
| 306
| 180
| 360
| 288
|-
| TM-VOIP-4
| 1616
| 512
| 800
| 672
| 512
| 264
| 288
| 336
| 408
| 240
| 480
| 384
|}

['''1'''] May require additional licenses

[[Category:Glossary]]
[[Category:Tmedia_Features|Voice Codecs]]
[[Category:Tdev_Features|Voice Codecs]]
[[Category:Needs_revising]]
[[Category:Revise on Major]]

Voice codecs

2015-05-22T20:07:27Z

Clod Patry: fix typo.

TelcoBridges products support the following voice codecs.

== Supported codecs ==
 

*'''Universal codecs'''
**[http://en.wikipedia.org/wiki/G.711 G.711] - Supported packet durations: 20,30,40,50 and 60 msec
**[http://en.wikipedia.org/wiki/G.722 G.722] - Supported packet durations: 20,30,40,50 and 60 msec
**[http://en.wikipedia.org/wiki/G.723.1 G.723.1] - Supported packet durations: 30,60 and 90 msec
**[http://en.wikipedia.org/wiki/G.726 G.726] - Supported packet durations: 20,30,40,50 and 60 msec
**[http://en.wikipedia.org/wiki/G.729 G.729a/ab] - Supported packet durations: 20,30,40,50,60,70 and 80 msec
**[[Clearmode]] ([http://tools.ietf.org/html/rfc4040 rfc4040]) - Supported packet durations: 5,10,20,30,40,50,60 msec
**[http://en.wikipedia.org/wiki/T.38 T.38]

*'''Wireline codecs'''
**[http://en.wikipedia.org/wiki/G.728 G.728] - Supported packet durations: 20,30,40,50 and 60 msec
**[http://en.wikipedia.org/wiki/G.729 G.729eg] - Supported packet durations: 20,30,40,50,60,70 and 80 msec
**[http://en.wikipedia.org/wiki/Internet_Low_Bit_Rate_Codec iLBC] - Supported packet durations: [13kbps] 30 and 60 msec, [15kpbs] 20 and 40 msec

*'''Wireless codecs''' '''1'''
**[http://en.wikipedia.org/wiki/Adaptive_multi-rate_compression AMR] - Supported packet durations: 20,40,60 and 80 msec
**[http://en.wikipedia.org/wiki/Full_Rate GSM-FR] - Supported packet durations: 20 and 30 msec
**[http://en.wikipedia.org/wiki/Enhanced_Full_Rate GSM-EFR] - Supported packet durations: 20,40 and 60 msec
**[http://en.wikipedia.org/wiki/EVRC EVRC] - Supported packet durations: 20,40 and 60 msec
**[http://en.wikipedia.org/wiki/QCELP QCELP] - Supported packet durations: 20,40 and 60 msec
**[[G.722.2 (AMR-WB)]] - Supported packet durations: 20,40,60 and 80 msec
 

== TMG media gateways codec capacity ==
 
{| cellpadding="5" border="1" class="wikitable" style="text-align: center"
|-
! width="40" rowspan="2" | Media Gateway
! width="400" colspan="6" | Universal codecs
! width="240" colspan="3" | Other codecs
! width="320" colspan="4" | Wireless codecs'''1'''
|-
! width="80" | G.711
! width="80" | G.723.1
! width="80" | G.726
! width="80" | G.729ab
! width="80" | T.38
! width="80" | clearmode (rfc4040)
! width="80" | G.728
! width="80" | G.729eg
! width="80" | iLBC
! width="80" | AMR
! width="80" | AMR-WB
! width="80" | GSM-FR/GSM-EFR
! width="80" | EVRC/QCELP
|-
| TMG800-8 TMG3200-RJ8
| 256 || 254 || 256 || 256 || 254 || 256 || 116 || 128 || 150 || 182 || 118 || 214 || 190
|-
| TMG3200-RJ16 TMG3200-TE16 TMG7800-TE16
| 512 || 508 || 512 || 512 || 508 || 512 || 232 || 256 || 300 || 364 || 236 || 428 || 380
|-
| TMG3200-TE32 TMG7800-TE32
| 1024 || 1016 || 1024 || 1024 || 1016 || 1024|| 464 || 512 || 600 || 728 || 472 || 856 || 760
|-
| TMG3200-TE48 TMG7800-TE48
| 1536 || 1524 || 1536 || 1536 || 1524 || 1536 || 696 || 768 || 900 || 1092 || 708 || 1284 || 1140
|-
| TMG3200-TE64 TMG7800-TE64 TMG3200-STM1 TMG7800-STM1
| 2048 || 2032 || 2048 || 2048 || 2032 || 2048 || 928 || 1024 || 1200 || 1456 || 944 || 1712 || 1520
|}

== Tdev development platform ==

=== TMP6400 Codec density ===
Codec density is comprised of two modes:
*Mixed Mode
*Fixed Mode
 

==== Mixed Mode ====

The following densities are achieved when a codec mix is dynamically negotiated.
{| cellpadding="5" border="1" class="wikitable" style="text-align: center"
|-
! width="150" rowspan="2" | Type of
VoIP mezzanine
! width="400" colspan="5" | Universal codecs
! width="240" colspan="3" | Other codecs
! width="320" colspan="4" | Wireless codecs'''1'''
|-
! width="80" | G.711
! width="80" | G.723.1
! width="80" | G.726
! width="80" | G.729ab
! width="80" | T.38
! width="80" | G.728
! width="80" | G.729eg
! width="80" | iLBC
! width="80" | AMR
! width="80" | AMR-WB
! width="80" | GSM-FR/GSM-EFR
! width="80" | EVRC/QCELP
|-
| TM-VOIP-1
| 341
| 127
| 169
| 154
| 127
| 58
| 64
| 75
| 91
| 59
| 107
| 95
|-
| TM-VOIP-2
| 682
| 254
| 338
| 308
| 254
| 116
| 128
| 150
| 182
| 118
| 214
| 190
|-
| TM-VOIP-3
| 1023
| 381
| 507
| 462
| 381
| 174
| 192
| 225
| 273
| 177
| 321
| 285
|-
| TM-VOIP-4
| 1364
| 508
| 676
| 616
| 508
| 232
| 256
| 300
| 364
| 236
| 428
| 380
|}

==== Fixed mode ====

The following densities are achieved when a codec mix is predefined.
{| cellpadding="5" border="1" class="wikitable" style="text-align: center"
|-
! width="150" rowspan="2" | Type of.
VoIP mezzanine
! width="400" colspan="5" | Universal codecs
! width="240" colspan="3" | Other codecs
! width="320" colspan="4" | Wireless codecs'''1'''
|-
! width="80" | G.711.
! width="80" | G.723.1
! width="80" | G.726
! width="80" | G.729ab
! width="80" | T.38
! width="80" | G.728
! width="80" | G.729eg
! width="80" | iLBC
! width="80" | AMR
! width="80" | AMR-WB
! width="80" | GSM-FR/GSM-EFR
! width="80" | EVRC/QCELP
|-
| TM-VOIP-1
| 404
| 128
| 200
| 168
| 128
| 66
| 72
| 84
| 102
| 60
| 120
| 96
|-
| TM-VOIP-2
| 808
| 256
| 400
| 336
| 256
| 132
| 144
| 168
| 204
| 120
| 240
| 192
|-
| TM-VOIP-3
| 1212
| 384
| 600
| 504
| 384
| 198
| 216
| 252
| 306
| 180
| 360
| 288
|-
| TM-VOIP-4
| 1616
| 512
| 800
| 672
| 512
| 264
| 288
| 336
| 408
| 240
| 480
| 384
|}

['''1'''] May require additional licenses

[[Category:Glossary]]
[[Category:Tmedia_Features|Voice Codecs]]
[[Category:Tdev_Features|Voice Codecs]]
[[Category:Needs_revising]]
[[Category:Revise on Major]]

Voice codecs

2015-05-22T20:05:45Z

Clod Patry: Adding G.722 to the list of universal codecs.

TelcoBridges products support the following voice codecs.

== Supported codecs ==
 

*'''Universal codecs'''
**[http://en.wikipedia.org/wiki/G.711 G.711] - Supported packet durations: 20,30,40,50 and 60 msec
**[http://en.wikipedia.org/wiki/G.722 G.722] - Supported packet durations: 20,30,40,50 and 60 msec
**[http://en.wikipedia.org/wiki/G.723.1 G.723.1] - Supported packet durations: 30,60 and 90 msec
**[http://en.wikipedia.org/wiki/G.726 G.726] - Supported packet durations: 20,30,40,50 and 60 msec
**[http://en.wikipedia.org/wiki/G.729 G.729a/ab] - Supported packet durations: 20,30,40,50,60,70 and 80 msec
**[[Clearmode]] ([http://tools.ietf.org/html/rfc4040 rfc4040]) - Supported packet durations: 5,10,20,30,40,50,60 msec
**[http://en.wikipedia.org/wiki/T.38 T.38]

*'''Wireline codecs'''
**[http://en.wikipedia.org/wiki/G.728 G.728] - Supported packet durations: 20,30,40,50 and 60 msec
**[http://en.wikipedia.org/wiki/G.729 G.729eg] - Supported packet durations: 20,30,40,50,60,70 and 80 msec
**[http://en.wikipedia.org/wiki/Internet_Low_Bit_Rate_Codec iLBC] - Supported packet durations: [13kbps] 30 and 60 msec, [15kpbs] 20 and 40 msec

*'''Wireless codecs''' '''1'''
**[http://en.wikipedia.org/wiki/Adaptive_multi-rate_compression AMR] - Supported packet durations: 20,40,60 and 80 msec
**[http://en.wikipedia.org/wiki/Full_Rate GSM-FR] - Supported packet durations: 20 and 30 msec
**[http://en.wikipedia.org/wiki/Enhanced_Full_Rate GSM-EFR] - Supported packet durations: 20,40 and 60 msec
**[http://en.wikipedia.org/wiki/EVRC EVRC] - Supported packet durations: 20,40 and 60 msec
**[http://en.wikipedia.org/wiki/QCELP QCELP] - Supported packet durations: 20,40 and 60 msec
**[[G.722.2 (AMR-WB)]] - Supported packet durations: 20,40,60 and 80 msec
 

== TMG media gateways codec capacity ==
 
{| cellpadding="5" border="1" class="wikitable" style="text-align: center"
|-
! width="40" rowspan="2" | Media Gateway
! width="400" colspan="6" | Universal codecs
! width="240" colspan="3" | Other codecs
! width="320" colspan="4" | Wireless codecs'''1'''
|-
! width="80" | G.711
! width="80" | G.723.1
! width="80" | G.726
! width="80" | G.729ab
! width="80" | T.38
! width="80" | clearmode (rfc4040)
! width="80" | G.728
! width="80" | G.729eg
! width="80" | iLBC
! width="80" | AMR
! width="80" | AMR-WB
! width="80" | GSM-FR/GSM-EFR
! width="80" | EVRC/QCELP
|-
| TMG800-8 TMG3200-RJ8
| 256 || 254 || 256 || 256 || 254 || 256 || 116 || 128 || 150 || 182 || 118 || 214 || 190
|-
| TMG3200-RJ16 TMG3200-TE16 TMG7800-TE16
| 512 || 508 || 512 || 512 || 508 || 512 || 232 || 256 || 300 || 364 || 236 || 428 || 380
|-
| TMG3200-TE32 TMG7800-TE32
| 1024 || 1016 || 1024 || 1024 || 1016 || 1024|| 464 || 512 || 600 || 728 || 472 || 856 || 760
|-
| TMG3200-TE48 TMG7800-TE48
| 1536 || 1524 || 1536 || 1536 || 1524 || 1536 || 696 || 768 || 900 || 1092 || 708 || 1284 || 1140
|-
| TMG3200-TE64 TMG7800-TE64 TMG3200-STM1 TMG7800-STM1
| 2048 || 2032 || 2048 || 2048 || 2032 || 2048 || 928 || 1024 || 1200 || 1456 || 944 || 1712 || 1520
|}

== Tdev development platform ==

=== TMP6400 Codec density ===
Codec denisty is comprised of two modes:
*Mixed Mode
*Fixed Mode
 

==== Mixed Mode ====

The following densities are achieved when a codec mix is dynamically negotiated.
{| cellpadding="5" border="1" class="wikitable" style="text-align: center"
|-
! width="150" rowspan="2" | Type of
VoIP mezzanine
! width="400" colspan="5" | Universal codecs
! width="240" colspan="3" | Other codecs
! width="320" colspan="4" | Wireless codecs'''1'''
|-
! width="80" | G.711
! width="80" | G.723.1
! width="80" | G.726
! width="80" | G.729ab
! width="80" | T.38
! width="80" | G.728
! width="80" | G.729eg
! width="80" | iLBC
! width="80" | AMR
! width="80" | AMR-WB
! width="80" | GSM-FR/GSM-EFR
! width="80" | EVRC/QCELP
|-
| TM-VOIP-1
| 341
| 127
| 169
| 154
| 127
| 58
| 64
| 75
| 91
| 59
| 107
| 95
|-
| TM-VOIP-2
| 682
| 254
| 338
| 308
| 254
| 116
| 128
| 150
| 182
| 118
| 214
| 190
|-
| TM-VOIP-3
| 1023
| 381
| 507
| 462
| 381
| 174
| 192
| 225
| 273
| 177
| 321
| 285
|-
| TM-VOIP-4
| 1364
| 508
| 676
| 616
| 508
| 232
| 256
| 300
| 364
| 236
| 428
| 380
|}

==== Fixed mode ====

The following densities are achieved when a codec mix is predefined.
{| cellpadding="5" border="1" class="wikitable" style="text-align: center"
|-
! width="150" rowspan="2" | Type of.
VoIP mezzanine
! width="400" colspan="5" | Universal codecs
! width="240" colspan="3" | Other codecs
! width="320" colspan="4" | Wireless codecs'''1'''
|-
! width="80" | G.711.
! width="80" | G.723.1
! width="80" | G.726
! width="80" | G.729ab
! width="80" | T.38
! width="80" | G.728
! width="80" | G.729eg
! width="80" | iLBC
! width="80" | AMR
! width="80" | AMR-WB
! width="80" | GSM-FR/GSM-EFR
! width="80" | EVRC/QCELP
|-
| TM-VOIP-1
| 404
| 128
| 200
| 168
| 128
| 66
| 72
| 84
| 102
| 60
| 120
| 96
|-
| TM-VOIP-2
| 808
| 256
| 400
| 336
| 256
| 132
| 144
| 168
| 204
| 120
| 240
| 192
|-
| TM-VOIP-3
| 1212
| 384
| 600
| 504
| 384
| 198
| 216
| 252
| 306
| 180
| 360
| 288
|-
| TM-VOIP-4
| 1616
| 512
| 800
| 672
| 512
| 264
| 288
| 336
| 408
| 240
| 480
| 384
|}

['''1'''] May require additional licenses

[[Category:Glossary]]
[[Category:Tmedia_Features|Voice Codecs]]
[[Category:Tdev_Features|Voice Codecs]]
[[Category:Needs_revising]]
[[Category:Revise on Major]]

Toolpack:Profile SDP Description

2015-05-22T20:03:38Z

Clod Patry: Adding G.722 with payload type 9

You can specify the Profile SDP Description to define which [[voice codecs]] are supported in the [[NAP]] using this Profile.

Here is the default Profile SDP Description.

m=audio 0 RTP/AVP 0 8 4 18 101 13
a=rtpmap:101 telephone-event/8000

Each line of the Profile SDP Description consists of text of the form <type>=<value>. <type> is always exactly one character and is case-significant. <value> is a structured text string whose format depends on <type>. It also will be case-significant unless a specific field defines otherwise. Whitespace is not permitted either side of the `=' sign. In general <value> is either a number of fields delimited by a single space character or a free format string.

In our Profile SDP Description, only 2 <type> are used.

===Media Announcement===

The format of media announcement is as follows.

:m=<media> <port> <transport> <fmt list>

*The first sub-field is the media type. Currently defined media for TMedia is "audio".

*The second sub-field is the transport port to which the media stream will be sent. In Toolpack, it is not specified in Profile SDP Description and therefore you should specify "0".

*The third sub-field is the transport protocol. For most of the application, you may specify it as "RTP/AVP" - the IETF's Realtime Transport Protocol using the Audio/Video profile carried over UDP.

*The fourth and subsequent sub-fields are media formats. For audio and video, these will normally be media payload types as defined in the RTP Audio/Video Profile. When a list of payload formats is given, this implies that all of these formats may be used in the session, but the first of these formats is the default format for the session. When the transport protocol is specified as "RTP/AVP", the payload format can be specified as either
**the payload type number for static payload types
**the payload type number along with additional encoding information for dynamically allocated payload types.

The payload type, which is carried in the actual RTP packet header, is used to identify the type of codec information carried in the packet. A list of payload type values for each codec is defined within RFC3551. Unfortunately, since the payload type field is only 7 bits-wide, all codecs cannot have a permanent payload type value understood universally by all VoIp systems. Therefore, some codecs have dynamic values that need to be negotiated through a call control or session control protocol such as SIP before the actual RTP session can take place.

Here is the list of codec payload type values per RFC3551.
<table border="1">
<tr><th>Codec</th><th>Payload type value</th></tr>
<tr><td>G.711 uLaw</td><td>0</td></tr>
<tr><td>G.723.1</td><td>4</td></tr>
<tr><td>G.711 aLaw</td><td>8</td></tr>
<tr><td>G.722</td><td>9</td></tr>
<tr><td>Comfort Noise</td><td>13</td></tr>
<tr><td>G.728</td><td>15</td></tr>
<tr><td>G.729AB</td><td>18</td></tr>
<tr><td>G.726-40</td><td>dynamic</td></tr>
<tr><td>G.726-32</td><td>2 or dynamic (depends on the network)</td></tr>
<tr><td>G.726-24</td><td>dynamic</td></tr>
<tr><td>G.726-16</td><td>dynamic</td></tr>
<tr><td>G.729EG</td><td>dynamic</td></tr>
<tr><td>AMR</td><td>dynamic</td></tr>
<tr><td>EVRC</td><td>dynamic</td></tr>
<tr><td>QCELP</td><td>dynamic</td></tr>
</table>

When you use dynamic payload types, you need to specify the additional encoding information using the attribute for media announcement.

===Attribute for Media Announcement===

A media description may have any number of attributes ("a=" fields) which are media specific. The format of attribute is as follows.

:a=<attribute>

:or

:a=<attribute>:<value>

Here are some examples of attributes.

====Dynamic payload type====

You specify the additional encoding information for dynamic payload type in the following format:

a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding parameters>]

For audio streams, <encoding parameters> may specify the number of audio channels. This parameter may be omitted if the number of channels is one provided no additional parameters are needed.

====Other media specific attribute====

The use of other media specific attributes depends on the specification of the RTP payload format for the specific media type. Here are some example of attributes.

*a=fmtp:<format> <format specific parameters>

This attribute allows parameters that are specific to a particular format to be conveyed in a way that SDP doesn't have to understand them. The format must be one of the formats specified for the media. Format-specific parameters may be any set of parameters required to be conveyed by SDP and given unchanged to the media tool that will use this format.

*a=ptime:<packet time>

This gives the length of time in milliseconds represented by the media in a packet. This is probably only meaningful for audio data. It should not be necessary to know ptime to decode RTP or vat audio, and it is intended as a recommendation for the encoding/packetisation of audio. It is a media attribute, and is not dependent on charset.

==== Examples ====

Here are some examples of the attributes found in the default profile SDP description.

a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20

The above defines iLBC codec of 8000/sec sample rate with 20ms frame size.

a=rtpmap:98 telephone-event/8000

The above defines the [[DTMF]] relay using RFC2833.

Here is another example, enabling Voice Activity Detection (VAD) for G.711 ulaw, G.711 alaw, G.723.1a and G.729b, in addition to telephony events.
<pre>m=audio 0 RTP/AVP 0 8 4 18 98 13
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:4 G723/8000
a=fmtp:4 bitrate=6300;annexa=yes
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:98 telephone-event/8000
a=fmtp:98 0-15
a=rtpmap:13 CN/8000
</pre>

Another example to disable silence suppression explicitly in the SDP.
<pre>m=audio 0 RTP/AVP 0 8 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=silenceSupp:off - - - -
</pre>

Below shows an example to enable GSM-FR with a dynamic payload type 99:
<pre>m=audio 0 RTP/AVP 18 4 8 0 96 97 98 99 13
a=rtpmap:96 iLBC/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
a=rtpmap:98 telephone-event/8000
a=rtpmap:99 GSM-FR/8000
a=fmtp:4 bitrate=6.3
a=fmtp:4 annexa=no
</pre>
Note: 
1. Your toolpack license needs to be GSM enabled. Please contact TelcoBridges support if you are not sure. 
2. You may need additional third party GSM license(s) from the corresponding patent holders. e.g. GSM-EFR, GSM-HR 

Below is a direct SIP INVITE with T.38. This can be useful if you know this route will always be with fax. It also doesn't require any IVR resources to detect the fax tones: 
<pre>m=image 0 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:400
a=T38FaxMaxDatagram:400
a=T38FaxUdpEC:t38UDPRedundancy
</pre>

==References==
*[http://www.ietf.org/rfc/rfc2327.txt RFC2327] - SDP: Session Description Protocol
*[http://www.ietf.org/rfc/rfc3551.txt RFC3551] - RTP Profile for Audio and Video Conferences with Minimal Control
*[http://www.ietf.org/rfc/rfc3952.txt RFC3952] - Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech
*[http://www.ietf.org/rfc/rfc2833.txt RFC2833] - RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals

Routing script tutorial:Mini Development Guide

2014-12-03T14:49:00Z

Clod Patry: use string instead of symbol in the section "List of SIP reason causes"

== Call object ==

=== Get ===

Those function are used to get the call parameters. The possible parameters are described in the section "Call parameters"

called_number = caf_call.get :called

=== List_params ===

This function is used to retrieve the list of supported call parameters. For example to extract all the possible call params from the the call object and put it in hash.

caf_call.list_params.each {|param| call[param] = caf_call.get param }

=== Accept ===

This function is used to accept a call. It actually creates one outgoing route that gateway application will use to bridge the incoming call leg. If more than one outgoing route is "accepted", gateway will try them one by one in the same order they were accepted. If an outgoing call leg fails (according to 'route retry' parameters), the next route in line will be used.

This method takes 2 arguments, the call parameters (hash) and the route parameters (hash). Note that calling this method does NOT stop the flow of the script.

Apply route remapping rules

caf_call.accept out_call, route

=== Refuse ===

This function is used to set the reason code for the incoming call leg refusal. However, this function does NOT stop the flow of the script.

caf_call.refuse :reason => :temporary_failure

To immediately refuse the incoming call leg and stop processing the script, the script must raise an exception. Exiting the script by raising the exception overwrites any reason cause previously stored using refuse().

raise RoutingException, :no_route

The supported refusal cause values for both refuse() and raise() are described in the section "[[Routing_script_tutorial:Mini_Development_Guide#Reason_values|Reason values]]".

=== Script parameters protocol mapping ===

The following call parameters are available in the call object. For example

called_number = call[:called]

{| cellspacing="1" cellpadding="1" border="1" style="width: 921px; height: 805px;"
|-
! scope="col" | '''Script parameter name'''
! scope="col" | '''ISDN '''
! scope="col" | '''R2 CAS''' 
! scope="col" | '''SS7 '''
! scope="col" | '''SIP '''
! scope="col" | '''Comment '''
! scope="col" | '''Toolpack version '''
|-
| leg_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Leg ID 
| 
|-
| session_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Session ID 
| 
|-
| calling 
| Q931: 'Calling party number' IE - Number digits 
| ANI (Group B) 
| Q763: 'Calling party number' IE - address signals (*) 
| SIP:From - user-info 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead. 
| 
|-
| calling_noa 
| Q931: 'Calling party number' IE - Type of number 
| N/A 
| Q763: 'Calling party number' IE - nature of address indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_npi 
| Q931: 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Calling party number' IE - numbering plan indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_display 
| Q931: 'Display' IE - Display information 
Q931: 'Facility CNAM' IE when presentation is allowed for DMS/NI2 variants 
| N/A 
| Q763: 'Display information' IE - display information 
| SIP:From - display-name 
| 
| 
|-
| calling_display_type 
| Q931: 'Display' IE - Display information (present and/or first byte) 
| N/A 
| Q763: 'Display information' IE - present or not 
| N/A 
| 
| 
|-
| calling_presentation 
| Q931: 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: 'Calling party number' IE - address presentation restricted indicator 
|
SIP:From - display-name (displays 'anonymous' or not)

SIP:Remote-party-id - privacy 

| 
| 
|-
| calling_screening 
| Q931: 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: 'Calling party number' IE - screening 
| SIP:Remote-party-id - screen 
| 
| 
|-
| calling_category 
| N/A 
| Call party category (Group A) 
| Q763: 'Calling party's category' IE - calling party's category 
|
SIP:From - cpc

SIP:P-asserted-identity - cpc 

| 
| 
|-
| calling_subscriber
(Generic Number / NDS) 
| Q931: 2nd 'Calling party number' IE - Number digits 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - Number digits 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| Requires option 'support 2 calling number IE' in the profile. This variable has priority over 'private_address' in the outgoing direction. 
| 
|-
| calling_subscriber_noa 
| Q931: 2nd 'Calling party number' IE - Type of number 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - nature of address indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_npi 
| Q931: 2nd 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - numbering plan indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
 
| 
|-
| calling_subscriber_presentation 
| Q931: 2nd 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - presentation restricted indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_screening 
| Q931: 2nd 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - screening 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| private_display 
| Q931: 'Facility CNAM' IE when presentation is restricted for DMS/NI2 variants 
| N/A 
| N/A 
|
SIP:P-asserted-identity - display-name 

SIP:Remote-party-id - display-name 

| 
| 
|-
| private_display_type 
| N/A 
| N/A 
| N/A 
| N/A 
| Indicate presence or not of the private calling information 
| 
|-
| private_address 
| N/A 
| N/A 
| N/A 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 

| 
| 
|-
| called 
| Q931: 'Called party number' IE - Number digits 
| DNIS (Group A) 
| Q763: 'Called party number' IE - address signals 
| SIP:To - user-info and host 
| 
| 
|-
| called_noa 
| Q931: 'Called party number' IE - Type of number 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| called_npi 
| Q931: 'Called party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| charge_number 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - address signals 
| N/A 
| 
| 
|-
| charge_number_noa 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| charge_number_npi 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default redirecting number and original called number forwarding behavior from incoming to outgoing leg 
| 
|-
| redirecting_number 
| Q931: 'Redirecting number' 1st IE - Number digits 
| N/A 
| Q763: 'Redirecting number' IE - address signals 
| SIP:Diversion (2nd header) - display-name 
| 
| 
|-
| redirecting_number_noa 
| Q931: 'Redirecting number' 1st IE - Type of number 
| N/A 
| Q763: 'Redirecting number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| redirecting_number_npi 
| Q931: 'Redirecting number' 1st IE - Numbering plan identification 
| N/A 
| Q763: 'Redirecting number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_presentation 
| Q931: 'Redirecting number' 1st IE - Presentation indicator 
| N/A 
| Q763: 'Redirecting number' IE - address presentation restricted indicator 
| SIP:Diversion (2nd header) - diversion-privacy 
| 
| 
|-
| redirecting_number_indicator 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirecting indicator 
| N/A 
| 
| 
|-
| redirecting_number_reason 
| Q931: 'Redirecting number' 1st IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - redirecting reason 
| SIP:Diversion (2nd header) - diversion-reason 
| 
| 
|-
| redirecting_number_counter 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirection counter 
| SIP:Diversion (2nd header) - diversion-counter 
| 
| 
|-
| original_called_number
(OCN) 
| Q931: 'Redirecting number' 2nd IE - Number digits 
| N/A 
| Q763: 'Redirection number' IE - address signals 
| SIP:Diversion  (1st header) - display-name 
| 
| 
|-
| original_called_number_noa 
| Q931: 'Redirecting number' 2nd IE - Type of number 
| N/A 
| Q763: 'Redirection number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| original_called_number_npi 
| Q931: 'Redirecting number' 2nd IE - Numbering plan identification 
| N/A 
| Q763: 'Redirection number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| original_called_number_presentation 
| Q931: 'Redirecting number' 2nd IE - Presentation indicator 
| N/A 
| Q763: 'Redirection number' IE - address presentation restricted indicator 
| SIP:Diversion (1st header) - diversion-privacy 
| 
| 
|-
| original_called_number_reason 
| Q931: 'Redirecting number' 2nd IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - original redirection reason 
| SIP:Diversion (1st header) - diversion-reason 
| 
| 
|-
| original_called_number_counter 
| N/A 
| N/A 
| N/A 
| SIP:Diversion (1st header) - diversion-counter 
| 
| 
|-
| ported_number 
| N/A 
| N/A 
| Q763: 'Called party number' IE - address signals 
| SIP:RequestURI - rn 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_noa 
| N/A 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_npi 
| N/A 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| oli
(Originating line information) 
| 5ESS Codeset 6 OLI - Value 
| N/A 
| ANSI: 'Originating line information' IE - OLI 
|
SIP:From - oli

SIP:P-asserted-identity - oli 

| 
| 
|-
| request_uri 
| N/A 
| N/A 
| N/A 
| Complete Request URI string 
| 
| 
|-
| request_uri_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default URI forwarding behavior from incoming to outgoing leg 
| 
|-
| sip_header 
| N/A 
| N/A 
| N/A 
| Any header 
| Requires option 'Forward custom headers' in Profiles->SIP 
| 2.7.63 
|-
| nap
(Network Access Point) 
| N/A 
| N/A 
| N/A 
| N/A 
| Incoming leg NAP name (read-only) 
| 
|-
| type_of_network_identification 
| Q931: 'Transit network selection' IE - Type of network identification 
| N/A 
| Q763: 'Transit network selection' IE - Type of network identification 
| N/A 
| 
| 2.7 
|-
| network_identification 
| Q931: 'Transit network selection' IE - Network identification 
| N/A 
| Q763: 'Transit network selection' IE - Network identification 
| SIP: Request-Line - cic 
| 
| 2.7 
|-
| network_identification_plan 
| Q931: 'Transit network selection' IE - Network identification plan 
| N/A 
| Q763: 'Transit network selection' IE - Network identification plan 
| N/A 
| 
| 2.7 
|-
| location_number_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default location number forwarding behavior from incoming to outgoing leg 
| 2.7 
|-
| location_number 
| N/A 
| N/A 
| Q763: 'Location number' IE - address signals 
| N/A 
| 
| 2.7 
|-
| location_number_noa 
| N/A 
| N/A 
| Q763: 'Location number' IE - nature of address indicator 
| N/A 
| 
| 2.7 
|-
| location_number_npi 
| N/A 
| N/A 
| Q763: 'Location number' IE - numbering plan indicator 
| N/A 
| 
| 2.7 
|-
| location_number_presentation 
| N/A 
| N/A 
| Q763: 'Location number' IE - presentation restricted indicator 
| N/A 
| 
| 2.7 
|-
| location_number_screening 
| N/A 
| N/A 
| Q763: 'Location number' IE - screening 
| N/A 
| 
| 2.7 
|-
| mlpp_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| A script needs to set this to true if it wants to overwrite MLPP information in the outgoing leg. Otherwise, profile relay 'outgoing mode' applies automatically. 
| 2.7 
|-
| mlpp_look_for_busy 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - look ahead for busy 
| N/A 
| 
| 2.7 
|-
| mlpp_precedence_level 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - precedence level 
| SIP:Resource-Priority - q735 
| 
| 2.7 
|-
| mlpp_network_identity 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - network identity 
| N/A 
| 
| 2.7 
|-
| mlpp_service_domain 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - MLPP service domain 
| N/A 
| 
| 2.7 
|-
| called_isub 
| Q931: 'Called party subaddress' IE - subaddress information 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Called party subaddress' IE - subaddress information 
| SIP:To - isub parameter 
| 
| 2.7 
|-
| called_isub_type 
| Q931: 'Called party subaddress' IE - type of subaddress 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Called party subaddress' IE - type of subaddress 
| SIP:To - isub-encoding parameter 
| 
| 2.7 
|-
| calling_isub 
| Q931: 'Calling party subaddress' IE - subaddress information 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Calling party subaddress' IE - subaddress information 
| SIP:From - isub 
| 
| 2.7 
|-
| calling_isub_type 
| Q931: 'Callinf party subaddress' IE - type of subaddress 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Calling party subaddress' IE - type of subaddress 
| SIP:From - isub-encoding 
| 
| 2.7 
|-
| ss7_fci_default 
| N/A 
| N/A 
| Default forward call indicator (FCI) value. 
| N/A 
| Toolpack will overwrite FCI bits A, D, F, I and M with appropriate values according to call conditions 
| 2.7 
|-
| ss7_fci_force_mask 
| N/A 
| N/A 
| Mask to select bits from ss7_fci_default that must be forced. 
| N/A 
| Bits from ss7_fci_default which corresponding bit in ss7_fci_force_mask is set will be forced, and no more controlled by Toolpack 
| 2.7 
|-
| ss7_bci_default 
| N/A 
| N/A 
| Default backward call indicator (BCI) value. 
| N/A 
| Toolpack will overwrite BCI bits AB, I, K, M and N with appropriate values according to call conditions 
| 2.7 
|-
| ss7_bci_force_mask 
| N/A 
| N/A 
| Mask to select bits from ss7_bci_default that must be forced. 
| N/A 
| Bits from ss7_bci_default which corresponding bit in ss7_bci_force_mask is set will be forced, and no more controlled by Toolpack 
| 2.7 
|-
| tdm_ls_name
(Line Service or T1/E1 trunk) 
| Incoming leg line service name 
| Incoming leg line service name 
| Incoming leg line service name 
| N/A 
| (read-only) 
| 2.7 
|-
| tdm_timeslot_nb 
| Incoming leg timeslot number 
| Incoming leg timeslot number 
| Incoming leg timeslot number 
| N/A 
| (read-only) 
| 2.7 
|-
| rtp_local_addr 
| N/A 
| N/A 
| N/A 
| Incoming leg local SDP IP address 
| (read-only) 
| 2.7 
|-
| rtp_local_port 
| N/A 
| N/A 
| N/A 
| Incoming leg local SDP IP port 
| (read-only) 
| 2.7 
|-
| rtp_remote_addr 
| N/A 
| N/A 
| N/A 
| Incoming leg remote SDP IP address 
| (read-only) 
| 2.7 
|-
| rtp_remote_port 
| N/A 
| N/A 
| N/A 
| Incoming leg remote SDP IP port 
| (read-only) 
| 2.7 
|-
| ss7_cot_enabled 
| N/A 
| N/A 
| Requests SS7 in-call continuity test for this outgoing SS7 call 
| N/A 
| Toolpack will request continuity test on the timeslot before making the outgoing call. If COT fails, the call will be dropped (then another route may be attempted) 
| 2.8 
|-
| reverse_charging_indication 
| Incoming leg Reverse charging indication IE present 
| N/A 
| N/A 
| N/A 
| If set in routing script, will add Reverse charging indication IE in outgoing leg (also use reverse_charging_indication_forward_enabled) 
| 2.8.12 
|-
| reverse_charging_indication_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Enable forwarding of reverse charging indication from incoming to outgoing leg 
| 2.8.12 
|-
| sip_local_addr 
| N/A 
| N/A 
| N/A 
| Incoming leg local SIP IP address 
| (read-only) 
| 2.8.13 
|-
| sip_local_port 
| N/A 
| N/A 
| N/A 
| Incoming leg local SIP UDP port 
| (read-only) 
| 2.8.13 
|-
| sip_remote_addr 
| N/A 
| N/A 
| N/A 
| Incoming leg remote SIP IP address 
| (read-only) 
| 2.8.13 
|-
| sip_remote_port 
| N/A 
| N/A 
| N/A 
| Incoming leg remote SIP UDP port 
| (read-only) 
| 2.8.13 
|}

 

'''Notice:''' All values are documented in the '''noa_npi_remap.rb''' script and may change between major release.

=== Noa values ===

*<tt>unknown_number (0x2)</tt>
*<tt>international_number (0x4)</tt>
*<tt>national_number (0x3)</tt>
*<tt>subscriber_number (0x1)</tt>
*<tt>network_specific (0x5)</tt>
*<tt>network_routing_national_format (0x7)</tt>
*<tt>network_routing_international_format (0x8)</tt>
*<tt>abbreviated_number (0x6)</tt>
*<tt>subscriber_number_operator_requested (0x71)</tt>
*<tt>national_number_operator_requested (0x72)</tt>
*<tt>international_number_operator_requested (0x73)</tt>
*<tt>no_number_present_operator_requested (0x74)</tt>
*<tt>no_number_present_cut_through_call_to_carrier (0x75)</tt>
*<tt>test_line_test_code (0x77)</tt>
*<tt>non_unique_subscriber_number (0x71)</tt>
*<tt>non_unique_national_number (0x73)</tt>
*<tt>non_unique_international_number (0x74)</tt>
*<tt>call_950_numbe (0x76)</tt>
*<tt>special_number (0x73)</tt>
*<tt>national_number_with_transit_network_selection (0x74)</tt>
*<tt>international_number_with_transit_network_selection (0x75)</tt>

Those values will be remapped to the protocol specific NOA value. To provide protocol specific value:

*<tt>call_params[:called_noa] = 0x70</tt>

or

*<tt>call_params[:called_noa] = 112</tt>

=== Npi values ===

*<tt>unknown_number</tt>
*<tt>isdn</tt>
*<tt>telephony</tt>
*<tt>private</tt>
*<tt>data</tt>
*<tt>telex</tt>
*<tt>national</tt>

=== Calling Display Type values ===

*<tt>unspecified</tt> => Type is unspecified.
*<tt>calling_party_name</tt> => Type is 0xB1.

Those values will be remapped to the protocol specific Display Information Type value. To provide protocol specific value:

*<tt>call_params[:calling_display_type] = 0xB1</tt>

or

*<tt>call_params[:calling_display_type] = 177</tt>

=== Calling Display value ===

*<tt>call_params[:calling_display] = "Roger Fluffy"</tt>

=== Presentation values for Calling number, Calling Subscriber (Generic Number), Redirecting Number, Original Called Number (OCN) and Location Number ===

*<tt>unspecified</tt>
*<tt>not_available (0x2)</tt>
*<tt>allowed (0x0)</tt>
*<tt>restricted (0x1)</tt>
*<tt>addr_restricted</tt>
*<tt>name_restricted</tt>

=== Calling Party Category ===
values for calling_category
*<tt>unspecified</tt> <tt>(0xa)</tt>
*<tt>unknown</tt> <tt>(0x0)</tt>
*<tt>operator_french</tt> <tt>(0x1)</tt>
*<tt>operator_english</tt> <tt>(0x2)</tt>
*<tt>operator_german</tt> <tt>(0x3)</tt>
*<tt>operator_russian</tt> <tt>(0x4)</tt>
*<tt>operator_spanish</tt> <tt>(0x5)</tt>
*<tt>subscriber</tt> <tt>(0xa)</tt>
*<tt>subscriber_with_priority</tt> <tt>(0xb)</tt>
*<tt>data</tt> <tt>(0xc)</tt>
*<tt>test</tt> <tt>(0xd)</tt>
*<tt>payphone</tt> <tt>(0xf)</tt>

=== Screening values for Calling number, Calling Subscriber (Generic Number), and Location Number ===

*<tt>unspecified</tt>
*<tt>no (0x0)</tt>
*<tt>pass (0x1)</tt>
*<tt>fail (0x2)</tt>
*<tt>network_provided (0x3)</tt>

=== Redirecting indicator values ===

SS7:

*<tt>no_redirection</tt>
*<tt>call_rerouted</tt>
*<tt>call_rerouted_all_restricted</tt>
*<tt>call_diverted</tt>
*<tt>call_diverted_all_restricted</tt>
*<tt>call_rerouted_restricted</tt>
*<tt>call_diverted_restricted</tt>
*<tt>spare</tt>

=== Redirecting number, Original Called Number and Diversion Reason ===

ISDN:

*<tt>unknown</tt>
*<tt>busy</tt>
*<tt>no_reply</tt>
*<tt>deflection</tt>
*<tt>dte_out_of_order</tt>
*<tt>forwarding_by_called_dte</tt>
*<tt>unconditional</tt>

SS7:

*<tt>unknown</tt>
*<tt>busy (SIP: user-busy)</tt>
*<tt>no_reply (SIP: no-answer)</tt>
*<tt>unconditional</tt>
*<tt>deflection</tt>
*<tt>deflection_immediate</tt>
*<tt>mobile_not_reachable</tt>

=== OLI (originating line information) values ===

The OLI parameter is a string that represents an integer value from 0 to 255.

=== Information Transfer Capability values ===

information_transfer_capability:

*<tt>digital</tt>
*<tt>restricted_digital</tt>
*<tt>digital_with_tones</tt>
*<tt>speech</tt>
*<tt>3_1_khz_audio</tt>

=== redirecting_number_forward_enabled values ===

Controls forwarding or discarding of redirecting number (SIP: diversion header) to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true. 0/false: Redirecting number (and original called number) is not forwarded to outgoing call leg 1/true: Redirecting number (and original called number) is forwarded to outgoing call leg The value for this parameter at input of routing script depends on the "Forward redirecting number" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

=== request_uri ===

Enables access to the Request-Line URI. 

For example, if the Request-Line is:
<pre>Request-Line: INVITE sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0</pre>
Then the retrieved request_uri will be "sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0". 

In the routing scripts, to retrieve only the called number, this script can be used: 
<pre> if call_params[:request_uri] && call_params[:request_uri] =~ /sip:(.*)@.*/
call_params[:called] = $1
end
</pre>
=== request_uri_forward_enabled values ===

Controls forwarding or discarding of request uri to outgoing call leg.The request uri is the information in the "Request-Line:" of the SIP INVITE message. 

Values for this parameter are "0", "1", "false" or "true. 

0/false: Request uri is not forwarded to outgoing call leg 

1/true: Request uri is forwarded to outgoing call leg 

The value for this parameter at input of routing script is always false. 

=== sip_header values ===
Contains a hash table of custom sip headers from the inbound call leg. Any custom sip header can be added to an outgoing call leg: 

<pre>call[ :sip_header ] = {"P-my-custom-header"=>"value1", "P-my-custom-header2"=>"value2", "P-my-custom-header3"=>"value3"}</pre>

* PCAP sample: [[File:TB_Custom_SIP_Headers.pcap]]

List of sip headers that will not appear in call[:sip_header] since they are already processed by the SIP stack:
<pre>
Accept Error-Info Remote-Party-ID
Accept-Contact Event Replaces
Accept-Encoding Expires Reply-To
Accept-Language From Request-Disposition
Alert-Info In-Reply-To Subject
Allow Max-Forwards Subscription-State
Allow-Events MIME-version Supported
Also Min-Expires Timestamp
Anonymity Min-SE To
Authorization Organization Unsupported
Authentication-Info Path User-Agent
Call-ID Priority Via
Call-Info Privacy Warning
Contact Proxy-Authenticate WWW-Authenticate
Content-Disposition Proxy-Authorization Require
Content-Encoding Proxy-Require Response-Key
Content-Language P-Media-Authorization Retry-After
Content-Length P-Preferred-Identity RPID-Privacy
Content-Type P-Asserted-Identity Route
CSeq RAck RSeq
RAck Reason Security-Client
Reason Record-Route Security-Server
Date Refer-To Security-Verify
Diversion Referred-By Server
Encryption Reject-Contact Service-Route
Session-Expires
</pre>

=== MLPP Precedence values ===

mlpp_look_for_busy:

*<tt>allowed</tt>
*<tt>path_reserved</tt>
*<tt>not_allowed</tt>

mlpp_precedence_level:

*<tt>flash_override</tt>
*<tt>flash</tt>
*<tt>immediate</tt>
*<tt>priority</tt>
*<tt>routine</tt>

mlpp_network_identity:

3 digits value from 0 to 999

mlpp_service_domain:

24 bits value from 0 to 16777215

=== ISUB subaddress information values ===

called_isub_type:
calling_isub_type:

*<tt>nsap</tt>
*<tt>nsap_ia5</tt>
*<tt>nsap_bcd</tt>
*<tt>user</tt>

called_isub:
calling_isub:

Digits for the subaddress information.

== Route parameters ==

All route may have these parameters:

*calling
*called
*nap
*remapped_calling
*remapped_called
*remapped_nap
*remapped_profile
*remapped_incoming_profile

Example:

route[:remapped_nap]

Additionally it is possible to add dynamic route attributes in the web portal. These can be referenced by their name.

== Playing prompts announcements or tones ==

New feature in release 2.6, all bridges may have these parameters. These can be used to play IVR prompts (audio files) in different states of the call flow.

*'''announcement_tone''' (played before outgoing call is routed)
*'''ring_tone''' (played after when waiting for outgoing call to answer)
*'''busy_tone''' (played if outgoing call failed)
*'''disconnect_tone''' (played after the call has reached it's maximum duration)

The following sections show how to access those different parameters from '''inside''' a filter. The 'params' hash is the sole argument passed to a filter function and contains call, nap, route and bridge parameters. This hash is created by the base_routing.rb scripts to regroup all relevant information just before calling the filter functions.

=== Tone string format ===

All tone strings (:announcement_tone, :busy_tone, :ring_tone, :disconnect_tone) inside bridge parameters are using this format.
<pre>"file1.wav:repeat:start_off:end_off,file2.wav:repeat:start_off:end_off,file3.wav:repeat:start_off:end_off"
</pre>
Optional parameters:
* repeat: number of times to play the file (0 and 1 have the same result)
* start_off: Start offset in milliseconds
* end_off: End offset in milliseconds

==== Example 1 ====
The following example will play file1.wav once, and then play file2.wav in loop:
"file1.wav,file2.wav:-1"

==== Example 2 ====
The following example will play file1.wav from start offset of 1 second to end offset of 3 seconds, then twice file2.wav from second 5 to second 10.
"file1.wav:0:1000:3000,file2.wav:2:5000:10000"

==== Example 3 ====
The following example will play file1.wav once, ending at offset of 30 seconds.
"file1.wav:0:0:30000"

=== announcement_tone ===

params[:bridge][:announcement_tone] = "announcement.wav"

Audio file played on the incoming call before any outgoing call is placed. The outgoing call occurs when the file finished playing.

==== announcement_tone options ====
===== announcement_tone_answer =====
params[:bridge][:announcement_tone_answer] = "yes"

Forces an answer of the call before playing the announcement. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== ring_tone ===
params[:bridge][:ring_tone] = "ringing.wav"

Audio file played on the incoming call while waiting for the outgoing call to be answered.

Ring tone playback can also be configured in the Web Portal, from the incoming call's profile (under "Tones and Call Progress Options").

Routing script has precedence over profile (a routing script that fills params[:bridge][:ring_tone] will override the profile's ring tone behavior).

==== ring_tone options ====
===== ring_tone_state =====
params[:bridge][:ring_tone_state] = :alerted

Call state from which ring tone is being played. Available values are:
* '''immediately''': Ring tone starts playing immediately on the incoming leg
* '''accepted''': Ring tone starts playing as soon as outgoing call is accepted
* '''callprogress''': Ring tone starts playing as soon as "call progress" is received on the outgoing call
* '''alerted''' (default): Ring tone starts playing only once outgoing call is alerted (but won't play if alert indicates early media from outgoing call)

This option also apply when params[:bridge][:ring_tone] is not used, because it also apply to ring tone playback configured in the Web Portal, from the incoming call's profile.

=== busy_tone ===
Toolpack 2.8 and above:
params[:bridge][:busy_tone] = "no_route.wav"

Note: Obsolete name (toolpack 2.7.153 and earlier, but still supported in recent releases):
params[:bridge][:call_progress_tone] = "no_route.wav"

Audio file played on the incoming call when outgoing call fails (never answered).

Note that announcement_tone, if used, is played before the outgoing call attempt is made, and thus before the busy_tone.

Busy tone playback can also be configured in the Web Portal, from the incoming call's profile (under "Tones and Call Progress Options").

Routing script has precedence over profile (a routing script that fills params[:bridge][:busy_tone] will override the profile's busy tone behavior).

Special value '''"none"''' can be used by routing script to force playing nothing (as empty string would default to profile's behavior)

==== busy_tone options ====
===== busy_tone_answer =====
params[:bridge][:busy_tone_answer] = "yes"

Forces an answer of the call before playing the busy tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== disconnect_tone ===
params[:bridge][:disconnect_tone] = "max_duration.wav"

Audio file played on the incoming call when call duration (:max_call_duration) is reached. Then the leg will be terminated with specified reason (:call_duration_reason).

==== disconnect_tone options ====
===== disconnect_tone_answer =====
params[:bridge][:disconnect_tone_answer] = "yes"

Forces an answer of the call before playing the disconnect tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

===== max_call_duration =====
params[:bridge][:max_call_duration] = "60000"

Maximum call duration in millisecond. This timer is started when entering answer state.

===== call_duration_reason =====
params[:bridge][:call_duration_reason] = :resource_unavailable

Drop both legs with this reason when call duration (:max_call_duration) is reached.

=== Managing audio prompts through Web Portal ===
Audio prompts can be uploaded or deleted from the TMedia unit through the Web Portal:
[[Toolpack:Configuring_Audio_Prompts_A|Managing audio prompts]]

Prompts management must be done using the Web Portal of the primary server (in systems with redundant TMedia units or redundant host servers).
The file will automatically get replicated to the secondary server.

=== Managing audio prompts manually ===
Any file on the TMedia host file system can be played. This means it's possible to manage prompts through ssh/scp.

==== The default (replicated) prompts folder ====
By default, when playing a prompt, Toolpack will look in the default prompts folder:
/lib/tb/toolpack/pkg/prompts
The root of this "prompts" directory is automatically replicated to secondary unit of redundant setups (1+1, N+1, redundant hosts). Sub-folders won't be replicated.

Any prompt play request without explicit file path will map to this folder. For example:
params[:bridge][:busy_tone] = "no_route.wav"
This will correspond to file /lib/tb/toolpack/pkg/prompts/no_route.wav

==== Relative file paths ====
Any file path that begins with "file://" is considered relative to the tbstreamserver application's working directory:
/lib/tb/toolpack/setup/12358/2.8/apps/tbstreamserver/
(Where "2.8" may be replaced by the current major version of your system)

For example:
params[:bridge][:busy_tone] = "file://my_folder/no_route.wav"
This will correspond to file /lib/tb/toolpack/setup/12358/2.8/apps/tbstreamserver/my_folder/no_route.wav

==== Absolute file paths ====
Absolute paths can also be provided.
For example:
params[:bridge][:busy_tone] = "file:///root/my_folder/no_route.wav"
This will correspond to file /root/my_folder/no_route.wav

== Recording call legs ==
Introduced in release 2.6.44, it's now possible to use routing scripts to ask for recording incoming and/or outgoing call legs.

See example filter script "call_recording" (created by default in Web Portal routing scripts starting with 2.6.44) for an example.

=== Recording the incoming call leg ===
To record the incoming call leg, the routing script (in a "after filter" for example) has to set the following parameter:

bridge[ :record_incoming ] = ""

=== Recording the outgoing call leg ===
To record the outgoing call leg, the routing script (in a "after filter" for example) has to set the following parameter, per route (the decision to record or not, or the file name to record to, can be set per matching route):

# Need to clone the routes in order to have the right to modify them
routes = clone_routes params[:routes]
routes.each do |route|
route[ :record_outgoing ] = ""
end
# Store modified routes back to the parameters for this outgoing call
params[:routes] = routes

=== Record the outgoing call leg within incoming leg's recorded file (mixing) ===
[...]
route[ :record_outgoing ] = "@{MixWithIncoming}"
[...]

=== Choosing file path to record to ===
The value assigned to ":record_incoming" or ":record_outgoing" is the path to record the file to.

The paths can be absolute, or relative. When relative, they are relative to the "tbstreamserver" application working directory, for example:
/lib/tb/toolpack/setup/12358/2.7/apps/tbstreamserver/

* Empty file name will default to a name that contains various information about the call:
** ''LinkId'': Id common between all legs of this call bridge
** ''LegId'': Unique Id for this leg
** ''Nap'': Current NAP name this call leg is from
** ''Direction'': "IN" or "OUT" (depends if call leg is incoming or outgoing leg)
** ''Calling'': The calling number of this call leg
** ''Called'': The called number of this call leg
** ''Protocol'': The signaling protocol of this call leg (SS7, ISDN, CAS, SIP)
** ''Media info'': Codec + IP/Port for SIP calls, Trunk/Timeslot for TDM calls
* To record outgoing call leg in the same audio file as incoming call leg (mixing), use the following:
** @{MixWithIncoming}: Record outgoing legs in same file as incoming legs
* Variables can be used to insert in the recording path information that's not already available from routing scripts:
** @{DefaultName}: Same file name (without parent folder path) as the one used when empty string is provided
*** Example: "73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{DefaultPath}: Same path as the one used when empty string is provided
*** Example: "/lib/tb/toolpack/setup/12358/recorded_calls/73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "/lib/tb/toolpack/setup/12358/recorded_calls/73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{LinkId}: Current LinkId (Id common between all legs of this call bridge)
*** Example: "73EBA698"
** And all variables listed here: [[Customer_application_framework:play_audio_files#Helpful_variables_to_build_play_or_record_file_paths|Building play or record file path]]

== Controlling UUI (user-to-user information) relay ==
UUI (user-to-user information) can be present in different messages received by either call leg during a call. For example, information can be carried during the initial invite, other information can be carried when the call is alerted, answered, or terminated.

Routing scripts can control if the UUI received from one leg through the call will be forwarded or not to the other call leg:
*uui_forward_enabled

Routing scripts can also read and modify the UUI received with the incoming call leg, before it gets forwarded upon creation of the outgoing call leg:
*uui

=== UUI (user-to-user indication) values ===

Byte array represented as ruby String. Use ''bridge=params[:bridge]'', then ''bridge[:uui]'' to access the data.

To access the bytes in Ruby, use ruby String operator []. For example: bridge[:uui][0] will return the binary value of the first UUI byte.

Function each_byte can also be useful to iterate through all bytes of the UUI.

=== uui_forward_enabled values ===

Controls forwarding or discarding of UUI to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true.
* 0/false: UUI is not forwarded between call legs
* 1/true: UUI is forwarded between call legs

The value for this parameter at input of routing script depends on the "Forward UUI" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

== Authorization ==
Starting with release 2.7, it is possible to issue RADIUS authorization requests from routing scripts. To do so, the params[:authorization] object must be filled with the required RADIUS attributes and [[#Refuse|an exception must be raised]] with reason :authorization_required.

When the authorization is completed, the routing script is called again with the result. The params[:authorization] object will be filled with the RADIUS attributes from the response. The params[:authorization][:result] field will also contain a string indicating the result of the authorization:

* ''accept'': The authorization was successful.
* ''reject'': The authorization was refused.
* ''challenge'': The authorization was challenged.
* ''timeout'': The authorization was not answered.

== Call diversion options ==
It's possible to control the call flow when a call diversion information is received in the alerting state.

Two fields are available: bridge[ :diversion ] and bridge[ :diversion_reason ]

The internal release cause TOOLPACK_DIVERT_NOT_ALLOWED is used by gateway application to terminate both legs.

bridge[ :diversion ] = :allowed
The alert message will not be analyzed and the call will be progressed. Default behavior.
bridge[ :diversion ] = :not_allowed
If the alert message indicates that the call is diverted, the call will be released no matter the In-band information to allow
early media.
bridge[ :diversion ] = :not_allowed_w_early_media
The call will be released If the alert message indicates that the call is diverted with in-band information to allow early media.
bridge[ :diversion_reason ] = "*"
If the diversion is not allowed, the gateway will drop the call for any redirecting reason.
bridge[ :diversion_reason ] = []
bridge[ :diversion_reason ] << :busy
bridge[ :diversion_reason ] << :unconditional
If the diversion is not allowed, the redirecting reason will be analyzed and the call will only be dropped for the configured cases.

See section [[Routing_script_tutorial:Mini_Development_Guide#Redirecting_number_reason_values|Redirecting number reason values]].

== Call transfer requests ==
Toolpack allows to relay [[Call transfer]] requests from one leg to the other, or to process them locally (making another outgoing call to replace the call that requested the call transfer).

If the chosen [[Call transfer]] mode is to process requests locally, upon reception of a call transfer request (SIP REFER or ISDN Facility), routing script will be called once again, to select the routes for the new outgoing call (call transfer target).

=== How to route call transfer request ===
Routing of a call transfer request is done exactly like routing of a normal incoming call.
The routing script generally does not need any modification to support that.

In some cases, the routing script may want to use information related to the transfer request to perform routing, or to insert information in the outgoing call leg.
Additional information is provided to the routing script, allowing routing decisions using information from the call transfer request (SIP REFER or ISDN Facility).
See below...

=== params[ :call ] content during transfer request ===
When processing a call transfer request, the params[ :call ] hash contains the information from the inbound call (same as was passed to the routing script upon arrival of the inbound call)
call = params[ :call ] -> Information from original inbound call, with exception of call[ :called ]

One exception (convenient because it allows a unmodified routing script to process call transfer request the same way as any other routing request):
call[ :called ] -> Replaced by the called number from the call transfer request (also called "redirection number")
Complementary information:
call[ :original_called_number ] -> Contains the called number that was initially received from the incoming call, prior to call transfer request
call[ :redirecting_number ] -> Number of the call from which the call transfer request was received (generally equals to original_called_number)

These fields will also be included in the outgoing call made after routing:
* original called number and redirecting number are existing fields on SS7 and ISDN calls
* SIP "diversion" header is used for SIP calls

=== params[ :transfer ] content ===
(this if valid only for release 2.7.102 and above) 
When processing a call transfer request, information from the call transfer request message (SIP REFER, ISDN Facility) is provided in params[ :transfer ]:
transfer = params[ :transfer ]
The following field is always present:
transfer[ :original_nap ] -> Contains the NAP of the first call from which a call transfer request was received
transfer[ :redirecting_nap ] -> Contains the NAP of the call from which the current call transfer request was received
(same as :original_nap for the first call transfer, different for subsequent transfers)
Examples of other fields that may be present, when appropriate:
transfer[ :uui ] -> The UUI (user-to-user information) found in the call transfer request
transfer[ :sip_header ] -> Contains custom SIP headers from the call transfer request
transfer[ :request_uri ] -> Contains the SIP Request URI

These field are 'read-only'. They won't be included in the outgoing call, as they represent the content of the call transfer request, not the outgoing call to make.

To insert/modify attributes of the outgoing call, the parameters from params[ :call ] must be edited instead.

== Reason values ==

Check here for Termination Reason Cause codes: 

[[Termination_cause_codes|Termination Reason Cause codes]]
 

Example to refuse an incoming call leg.
raise RoutingException, :no_route

Reason cause strings available inside routing scripts:

List of Q.850 reason causes:
:unallocated_number
:no_route_to_network
:no_route_to_destination
:send_special_tone
:misdialled_trunk_prefix
:channel_unacceptable
:call_awarded_in_established_channel
:preemption
:reattempt
:ported_number
:normal_call_clearing
:user_busy
:no_user_responding
:no_answer_from_user
:subscriber_absent
:call_rejected
:number_changed
:redirection
:exchange_routing_error
:non_selected_user_clearing
:destination_out_of_order
:address_incomplete
:facility_rejected
:response_to_status_enquiry
:normal_unspecified
:no_circuit_available
:network_out_of_order
:frame_mode_out_of_service
:frame_mode_connection_operational
:temporary_failure
:switching_equipment_congestion
:access_information_discarded
:requested_circuit_not_available
:precedence_call_blocked
:resource_unavailable
:quality_of_service_not_available
:requested_facility_not_subscribed
:outgoing_calls_barred
:outgoing_calls_barred_within_cug
:incoming_calls_barred
:incoming_calls_barred_within_cug
:bearer_cap_not_authorized
:bearer_cap_not_available
:inconsistency_access_info
:service_not_available
:bearer_cap_not_implemented
:channel_type_not_implemented
:requested_facility_not_implemented
:only_restricted_digital_info
:service_not_implemented
:invalid_call_reference
:channel_does_not_exist
:call_identity_does_not_exist
:call_identity_in_use
:no_call_suspended
:call_has_been_cleared
:user_not_member_of_cug
:incompatible_destination
:non_existant_cug
:invalid_transit_network
:invalid_message_unspecified
:mandatory_ie_missing
:message_type_non_existent
:not_compatible_with_call_state
:ie_non_existent
:invalid_ie_content
:message_not_compatible
:recovery_on_timer_expiry
:parameter_non_existent_passed_on
:msg_with_non_recognized_param_discarded
:protocol_error
:interworking_unspecified

List of toolpack reason causes:

:toolpack_normal or :normal
:toolpack_resource_error or :resource_error
:toolpack_timeout or :timeout
:toolpack_no_route or :no_route
:toolpack_call_collision or :call_collision
:toolpack_sync_drop or :sync_drop
:toolpack_signaling_error or :signaling_error
:toolpack_locally_rejected or :locally_rejected
:toolpack_interface_not_available or :interface_not_available
:toolpack_reset_in_progress or :reset_in_progress
:toolpack_adapter_reject or :adapter_reject
:toolpack_missing_or_invalid_ie or :missing_or_invalid_ie
:toolpack_incoming_only or :incoming_only
:toolpack_system_configuration_changed or :system_configuration_changed
:toolpack_resource_no_more_available or :resource_no_more_available
:toolpack_incompatible_media or :incompatible_media
:toolpack_resource_allocation_failed or :resource_allocation_failed
:toolpack_data_path_not_available or :data_path_not_available
:toolpack_local_congestion or :local_congestion
:toolpack_authorization_required or :authorization_required
:toolpack_call_divert_is_not_allowed or :call_divert_is_not_allowed

List of SIP reason causes: 
Reason causes starting with a digit must use the following syntax (can't use : as prefix).

'400_bad_request'
'401_unauthorized'
'402_payment_required'
'403_forbidden'
'404_not_found'
'405_method_not_allowed'
'406_not_acceptable'
'407_proxy_authentication_required'
'408_request_timeout'
'409_conflict'
'410_gone'
'413_request_entity_too_large'
'414_request_URI_too_long'
'415_unsupported_media'
'416_unsupported_URI_scheme'
'420_bad_extension'
'421_extension_required'
'422_session_timer_too_small'
'423_interval_too_brief'
'429_referrer_identity_error'
'480_temporary_unavailable'
'481_call_or_transaction_does_not_exist'
'482_loop_detected'
'483_too_many_hops'
'484_address_incomplete'
'485_ambiguous'
'486_busy_here'
'487_request_terminated'
'488_not_acceptable_here'
'489_bad_event'
'491_retry_after'
'500_server_internal_error'
'501_not_implemented'
'502_bad_gateway'
'503_service_unavailable'
'504_server_timeout'
'505_version_unsupported'
'513_message_too_large'
'600_busy_everywhere'
'603_decline'
'604_not_exist_anywhere'
'606_not_acceptable'

== Nap status ==

All the status fields of the NAPs are provided for use by the routing scripts. See the nap status provider for more details on which fields are available in the CEngineStatTransNap.hpp file.

'''Notice:''' These values may change between major release.

Routing script call attribute name Description
--------------------------------------------------------------------------------------------
"signaling_type" Signaling type.
"inst_incoming_call_cnt" Instantaneous Count of incoming calls.
"inst_outgoing_call_cnt" Instantaneous Count of outgoing calls.
"available_cnt" Number of available circuits or channels.
"unavailable_cnt" Number of unavailable circuits or channels.
"availability_percent" Percentage of available circuits or channels.
"usage_percent" Percentage of used circuits or channels.
"unused_shared_percent" Percentage of used circuits or channels of this NAP available to make new calls with (taking into account shared with other NAPs)
"total_incoming_call_cnt" Total Count of incoming calls.
"asr_statistics_struct" Detailed Answer-Seizure Rate Statistics.
"global_asr_percent" Global calculated ASR percentage.
"total_outgoing_call_cnt" Total Count of outgoing calls.
"last_24h_asr_percent" Last 24 hours calculated ASR percentage.
"last_24h_outgoing_call_cnt" Last 24 hours outgoing calls.
"current_hour_asr_percent" Current hour calculated ASR percentage.
"current_hour_outgoing_call_cnt" Current hour outgoing calls.
"last_hour_asr_percent" Last hour calculated ASR percentage.
"last_hour_outgoing_call_cnt" Last hour outgoing calls.
"availability_detection_struct" Detailed availibility detection Statistics
"poll_remote_proxy" Remote proxy polling enabled
"is_available" Remote proxy actually available or not
"time_since_polling" Time since the last availibility polling
"time_available_seconds" Number of seconds since the NAP is available
"time_unavailable_seconds" Number of seconds since the NAP is unavailable
"registration_struct" Detailed registration Statistics
"register_to_proxy" Register to proxy enabled
"registered" Actually registered or not
"time_since_refresh" Time since the last refresh
"time_registered_seconds" Number of seconds since the NAP is registered
"time_not_registered_seconds" Number of seconds since the NAP is not registered

 If the nap status is part of a substructure, it's name in the routing scripts must be composed of the structure name appended by an underscore and the field name.

For example the name to use for the global [[ASR]] percentage is:

asr_statistics_struct_global_asr_percent

 It is also possible to add dynamic nap attributes in the web portal. These can be referenced by their name.

== Routing Script Tests ==
The Web portal features a tool for Testing Scripts. The user must enter parameters to simulate the incoming call and after pressing the Test button, will output selected routes and numbers. You do not need to activate the new routes, or the new scripts to use this test tool: It can be used to test the routing scripts and routing table before activating it.
This is available in the Routing Scripts section of the Web portal.

=== Test parameters ===
==== @call_params ====

That variable should contain a hash of call parameters that will passed to the routing script. This is equivalent to the incoming call parameters.

 

==== @nap_list ====

A list of hash containing the nap statuses. This is equivalent to the nap statuses at the time the call is to be routed.

'''The nap list is hashed by the nap names in UPPERCASE.''' It is important to consider this when creating new dynamic route or nap attributes that may nap names that will be used to fetch a status.

 

==== @params ====

A hash of hashes containing parameters. This hash contains bridge parameters and other kind of parameter groups may be added in the future.

Example: @params = {:bridge => {:announcement_tone, "announcement.wav"}}

 

----

 Back to [[Routing script tutorial|Routing Script Tutorial]].

[[category:Needs revising]]

Support:How To extract backtrace from coredump

2014-09-24T14:59:34Z

Clod Patry: coredumps goes into the application's working directory.

When a fault happens in toolpack, developers may need to get more useful informations to fix the problem.

How to give useful informations related to a fault in the code:

# Log to the primary server (ssh)
# Type tbsetup
#: Usually all core files goes into the application's working directory.
# Type cd APPLICATION
#:where:
#:
#:*APPLICATION is the application that crashes
#: In this example, we'll suppose APPLICATION is toolpack_engine
#:
# Execute command: <pre>gdb -se "APPLICATION" -ex "bt full" -ex "thread apply all bt" --batch -c CORE > /tmp/backtrace.txt</pre>
#:where:
#:
#:*APPLICATION is the application that crashes
#:
#:*CORE is the core file.
#:
#:for example:
#:<pre>gdb -se "/lib/tb/toolpack/pkg/2.8.5/bin/release/x86_64-linux64/toolpack_engine" -ex "bt full" -ex "thread apply all bt" --batch -c core.17900 > /tmp/backtrace.txt</pre>
#:
#:If you are not sure about which application caused the crash, you can look in the created file for:
#:
#:Core was generated by `./release/x86_64-linux64/toolpack_engine -gw 12358'.
#:
#:For example, in that specific example, the crash happened at:
#:<code> Program terminated with signal 11, Segmentation fault. #0 0x000000000043ce59 in CallBridgingSampleDisplayMenu () #0 0x000000000043ce59 in CallBridgingSampleDisplayMenu () No symbol table info available.
#:</code>
#:
# Attach the file /tmp/backtrace.txt in your bugID (ticket that you opened to report the problem).

Troubleshooting:

if you see:
# gdb
-bash: gdb: command not found

This is because you did not install the gdb package.
You can do:
yum install gdb

If you prefer to run the application in gdb, consult this [[Support:How_To_Run_Toolpack_Application_In_gdb|page]]

Support:How To extract backtrace from coredump

2014-09-24T14:01:31Z

Clod Patry: created a link to run an application in gdb

When a fault happens in toolpack, developers may need to get more useful informations to fix the problem.

How to give useful informations related to a fault in the code:

# Log to the primary server (ssh)
# cd /tmp
#: Usually all core files goes into /tmp/
#:
# Execute command: <pre>gdb -se "APPLICATION" -ex "bt full" -ex "thread apply all bt" --batch -c CORE > /tmp/backtrace.txt</pre>
#:where:
#:
#:*APPLICATION is the application that crashes
#:
#:*CORE is the core file.
#:
#:for example:
#:<pre>gdb -se "/lib/tb/toolpack/pkg/2.8.5/bin/release/x86_64-linux64/toolpack_engine" -ex "bt full" -ex "thread apply all bt" --batch -c core.17900 > /tmp/backtrace.txt</pre>
#:
#:If you are not sure about which application caused the crash, you can look in the created file for:
#:
#:Core was generated by `./release/x86_64-linux64/toolpack_engine -gw 12358'.
#:
#:For example, in that specific example, the crash happened at:
#:<code> Program terminated with signal 11, Segmentation fault. #0 0x000000000043ce59 in CallBridgingSampleDisplayMenu () #0 0x000000000043ce59 in CallBridgingSampleDisplayMenu () No symbol table info available.
#:</code>
#:
# Attach the file /tmp/backtrace.txt in your bugID (ticket that you opened to report the problem).

Troubleshooting:

if you see:
# gdb
-bash: gdb: command not found

This is because you did not install the gdb package.
You can do:
yum install gdb

If you prefer to run the application in gdb, consult this [[Support:How_To_Run_Toolpack_Application_In_gdb|page]]

Support:How To extract backtrace from coredump

2014-09-24T13:57:25Z

Clod Patry: better formatting

When a fault happens in toolpack, developers may need to get more useful informations to fix the problem.

How to give useful informations related to a fault in the code:

# Log to the primary server (ssh)
# cd /tmp
#: Usually all core files goes into /tmp/
#:
# Execute command: <pre>gdb -se "APPLICATION" -ex "bt full" -ex "thread apply all bt" --batch -c CORE > /tmp/backtrace.txt</pre>
#:where:
#:
#:*APPLICATION is the application that crashes
#:
#:*CORE is the core file.
#:
#:for example:
#:<pre>gdb -se "/lib/tb/toolpack/pkg/2.8.5/bin/release/x86_64-linux64/toolpack_engine" -ex "bt full" -ex "thread apply all bt" --batch -c core.17900 > /tmp/backtrace.txt</pre>
#:
#:If you are not sure about which application caused the crash, you can look in the created file for:
#:
#:Core was generated by `./release/x86_64-linux64/toolpack_engine -gw 12358'.
#:
#:For example, in that specific example, the crash happened at:
#:<code> Program terminated with signal 11, Segmentation fault. #0 0x000000000043ce59 in CallBridgingSampleDisplayMenu () #0 0x000000000043ce59 in CallBridgingSampleDisplayMenu () No symbol table info available.
#:</code>
#:
# Attach the file /tmp/backtrace.txt in your bugID (ticket that you opened to report the problem).

Troubleshooting:

if you see:
# gdb
-bash: gdb: command not found

This is because you did not install the gdb package.
You can do:
yum install gdb

Support:How To extract backtrace from coredump

2014-09-24T13:35:25Z

Clod Patry: use absolute path instead of relative path

When a fault happens in toolpack, developers may need to get more useful informations to fix the problem.

How to give useful informations related to a fault in the code:

1- Log to the primary server (ssh)
2- cd /tmp
Usually all core files goes into /tmp/

3- Execute command: gdb -se "APPLICATION" -ex "bt full" -ex "thread apply all bt" --batch -c CORE > /tmp/backtrace.txt
where:

APPLICATION is the application that crashes

CORE is the core file.

for example:
gdb -se "/lib/tb/toolpack/pkg/2.8.5/bin/release/x86_64-linux64/toolpack_engine" -ex "bt full" -ex "thread apply all bt" --batch -c core.17900 > /tmp/backtrace.txt

If you are not sure about which application caused the crash, you can look in the created file for:

Core was generated by `./release/x86_64-linux64/toolpack_engine -gw 12358'.

For example, in that specific example, the crash happened at:
Program terminated with signal 11, Segmentation fault.
#0 0x000000000043ce59 in CallBridgingSampleDisplayMenu ()
#0 0x000000000043ce59 in CallBridgingSampleDisplayMenu ()
No symbol table info available.

4- Attach the file /tmp/backtrace.txt in your bugID (ticket that you opened to report the problem).

Troubleshooting:

if you see:
# gdb
-bash: gdb: command not found

This is because you did not install the gdb package.
You can do:
yum install gdb

Support:How To extract backtrace from coredump

2014-09-24T13:19:17Z

Clod Patry: initial version

When a fault happens in toolpack, developers may need to get more useful informations to fix the problem.

How to give useful informations related to a fault in the code:

1- Log to the primary server (ssh)
2- cd /tmp
Usually all core files goes into /tmp/

3- Execute command: gdb -se "APPLICATION" -ex "bt full" -ex "thread apply all bt" --batch -c CORE > /tmp/backtrace.txt
where:

APPLICATION is the application that crashes

CORE is the core file.

for example:
gdb -se "./release/x86_64-linux64/toolpack_engine" -ex "bt full" -ex "thread apply all bt" --batch -c core.17900 > /tmp/backtrace.txt

If you are not sure about which application caused the crash, you can look in the created file for:

Core was generated by `./release/x86_64-linux64/toolpack_engine -gw 12358'.

For example, in that specific example, the crash happened at:
Program terminated with signal 11, Segmentation fault.
#0 0x000000000043ce59 in CallBridgingSampleDisplayMenu ()
#0 0x000000000043ce59 in CallBridgingSampleDisplayMenu ()
No symbol table info available.

4- Attach the file /tmp/backtrace.txt in your bugID (ticket that you opened to report the problem).

Troubleshooting:

if you see:
# gdb
-bash: gdb: command not found

This is because you did not install the gdb package.
You can do:
yum install gdb

Voice codecs

2014-04-04T19:10:48Z

Clod Patry: Remove useless lines before T38.

TelcoBridges products support the following voice codecs.

=== Supported codecs ===
 

*'''Universal codecs'''
**[http://en.wikipedia.org/wiki/G.711 G.711] - Supported packet durations: 20,30,40,50 and 60 msec
**[http://en.wikipedia.org/wiki/G.723.1 G.723.1] - Supported packet durations: 30,60 and 90 msec
**[http://en.wikipedia.org/wiki/G.726 G.726] - Supported packet durations: 20,30,40,50 and 60 msec
**[http://en.wikipedia.org/wiki/G.729 G.729a/ab] - Supported packet durations: 20,30,40,50,60,70 and 80 msec
**[[Clearmode]] - Supported packet durations: 5,10,20,30,40,50,60 msec
**[http://en.wikipedia.org/wiki/T.38 T.38]

*'''Wireline codecs'''
**[http://en.wikipedia.org/wiki/G.728 G.728] - Supported packet durations: 20,30,40,50 and 60 msec
**[http://en.wikipedia.org/wiki/G.729 G.729eg] - Supported packet durations: 20,30,40,50,60,70 and 80 msec
**[http://en.wikipedia.org/wiki/Internet_Low_Bit_Rate_Codec iLBC] - Supported packet durations: [13kbps] 30 and 60 msec, [15kpbs] 20 and 40 msec

*'''Wireless codecs''' '''1'''
**[http://en.wikipedia.org/wiki/Adaptive_multi-rate_compression AMR] - Supported packet durations: 20,40,60 and 80 msec
**[http://en.wikipedia.org/wiki/Full_Rate GSM-FR] - Supported packet durations: 20 and 30 msec
**[http://en.wikipedia.org/wiki/Enhanced_Full_Rate GSM-EFR] - Supported packet durations: 20,40 and 60 msec
**[http://en.wikipedia.org/wiki/EVRC EVRC] - Supported packet durations: 20,40 and 60 msec
**[http://en.wikipedia.org/wiki/QCELP QCELP] - Supported packet durations: 20,40 and 60 msec
**[[G.722.2 (AMR-WB)]] - Supported packet durations: 20,40,60 and 80 msec

=== Codec density ===
Codec denisty is comprised of two modes:
*Mixed Mode
*Fixed Mode
 

==== Mixed Mode ====

The following densities are achieved when a codec mix is dynamically negotiated.
{| cellpadding="5" border="1" class="wikitable" style="text-align: center"
|-
! width="150" rowspan="2" | Type of
VoIP mezzanine
! width="400" colspan="5" | Universal codecs
! width="240" colspan="3" | Other codecs
! width="320" colspan="4" | Wireless codecs'''1'''
|-
! width="80" | G.711
! width="80" | G.723.1
! width="80" | G.726
! width="80" | G.729ab
! width="80" | T.38
! width="80" | G.728
! width="80" | G.729eg
! width="80" | iLBC
! width="80" | AMR
! width="80" | AMR-WB
! width="80" | GSM-FR/GSM-EFR
! width="80" | EVRC/QCELP
|-
| TM-VOIP-1
| 341
| 127
| 169
| 154
| 127
| 58
| 64
| 75
| 91
| 59
| 107
| 95
|-
| TM-VOIP-2
| 682
| 254
| 338
| 308
| 254
| 116
| 128
| 150
| 182
| 118
| 214
| 190
|-
| TM-VOIP-3
| 1023
| 381
| 507
| 462
| 381
| 174
| 192
| 225
| 273
| 177
| 321
| 285
|-
| TM-VOIP-4
| 1364
| 508
| 676
| 616
| 508
| 232
| 256
| 300
| 364
| 236
| 428
| 380
|}

==== Fixed mode ====

The following densities are achieved when a codec mix is predefined.
{| cellpadding="5" border="1" class="wikitable" style="text-align: center"
|-
! width="150" rowspan="2" | Type of.
VoIP mezzanine
! width="400" colspan="5" | Universal codecs
! width="240" colspan="3" | Other codecs
! width="320" colspan="4" | Wireless codecs'''1'''
|-
! width="80" | G.711.
! width="80" | G.723.1
! width="80" | G.726
! width="80" | G.729ab
! width="80" | T.38
! width="80" | G.728
! width="80" | G.729eg
! width="80" | iLBC
! width="80" | AMR
! width="80" | AMR-WB
! width="80" | GSM-FR/GSM-EFR
! width="80" | EVRC/QCELP
|-
| TM-VOIP-1
| 404
| 128
| 200
| 168
| 128
| 66
| 72
| 84
| 102
| 60
| 120
| 96
|-
| TM-VOIP-2
| 808
| 256
| 400
| 336
| 256
| 132
| 144
| 168
| 204
| 120
| 240
| 192
|-
| TM-VOIP-3
| 1212
| 384
| 600
| 504
| 384
| 198
| 216
| 252
| 306
| 180
| 360
| 288
|-
| TM-VOIP-4
| 1616
| 512
| 800
| 672
| 512
| 264
| 288
| 336
| 408
| 240
| 480
| 384
|}

['''1'''] May require additional licenses

[[Category:Glossary]]
[[Category:Tmedia_Features|Voice Codecs]]
[[Category:Tdev_Features|Voice Codecs]]
[[Category:Needs_revising]]

Voice codecs

2014-04-04T19:10:19Z

Clod Patry: adding clearmode to the universal list.

TelcoBridges products support the following voice codecs.

=== Supported codecs ===
 

*'''Universal codecs'''
**[http://en.wikipedia.org/wiki/G.711 G.711] - Supported packet durations: 20,30,40,50 and 60 msec
**[http://en.wikipedia.org/wiki/G.723.1 G.723.1] - Supported packet durations: 30,60 and 90 msec
**[http://en.wikipedia.org/wiki/G.726 G.726] - Supported packet durations: 20,30,40,50 and 60 msec
**[http://en.wikipedia.org/wiki/G.729 G.729a/ab] - Supported packet durations: 20,30,40,50,60,70 and 80 msec
**[[Clearmode]] - Supported packet durations: 5,10,20,30,40,50,60 msec

**[http://en.wikipedia.org/wiki/T.38 T.38]

*'''Wireline codecs'''
**[http://en.wikipedia.org/wiki/G.728 G.728] - Supported packet durations: 20,30,40,50 and 60 msec
**[http://en.wikipedia.org/wiki/G.729 G.729eg] - Supported packet durations: 20,30,40,50,60,70 and 80 msec
**[http://en.wikipedia.org/wiki/Internet_Low_Bit_Rate_Codec iLBC] - Supported packet durations: [13kbps] 30 and 60 msec, [15kpbs] 20 and 40 msec

*'''Wireless codecs''' '''1'''
**[http://en.wikipedia.org/wiki/Adaptive_multi-rate_compression AMR] - Supported packet durations: 20,40,60 and 80 msec
**[http://en.wikipedia.org/wiki/Full_Rate GSM-FR] - Supported packet durations: 20 and 30 msec
**[http://en.wikipedia.org/wiki/Enhanced_Full_Rate GSM-EFR] - Supported packet durations: 20,40 and 60 msec
**[http://en.wikipedia.org/wiki/EVRC EVRC] - Supported packet durations: 20,40 and 60 msec
**[http://en.wikipedia.org/wiki/QCELP QCELP] - Supported packet durations: 20,40 and 60 msec
**[[G.722.2 (AMR-WB)]] - Supported packet durations: 20,40,60 and 80 msec

=== Codec density ===
Codec denisty is comprised of two modes:
*Mixed Mode
*Fixed Mode
 

==== Mixed Mode ====

The following densities are achieved when a codec mix is dynamically negotiated.
{| cellpadding="5" border="1" class="wikitable" style="text-align: center"
|-
! width="150" rowspan="2" | Type of
VoIP mezzanine
! width="400" colspan="5" | Universal codecs
! width="240" colspan="3" | Other codecs
! width="320" colspan="4" | Wireless codecs'''1'''
|-
! width="80" | G.711
! width="80" | G.723.1
! width="80" | G.726
! width="80" | G.729ab
! width="80" | T.38
! width="80" | G.728
! width="80" | G.729eg
! width="80" | iLBC
! width="80" | AMR
! width="80" | AMR-WB
! width="80" | GSM-FR/GSM-EFR
! width="80" | EVRC/QCELP
|-
| TM-VOIP-1
| 341
| 127
| 169
| 154
| 127
| 58
| 64
| 75
| 91
| 59
| 107
| 95
|-
| TM-VOIP-2
| 682
| 254
| 338
| 308
| 254
| 116
| 128
| 150
| 182
| 118
| 214
| 190
|-
| TM-VOIP-3
| 1023
| 381
| 507
| 462
| 381
| 174
| 192
| 225
| 273
| 177
| 321
| 285
|-
| TM-VOIP-4
| 1364
| 508
| 676
| 616
| 508
| 232
| 256
| 300
| 364
| 236
| 428
| 380
|}

==== Fixed mode ====

The following densities are achieved when a codec mix is predefined.
{| cellpadding="5" border="1" class="wikitable" style="text-align: center"
|-
! width="150" rowspan="2" | Type of.
VoIP mezzanine
! width="400" colspan="5" | Universal codecs
! width="240" colspan="3" | Other codecs
! width="320" colspan="4" | Wireless codecs'''1'''
|-
! width="80" | G.711.
! width="80" | G.723.1
! width="80" | G.726
! width="80" | G.729ab
! width="80" | T.38
! width="80" | G.728
! width="80" | G.729eg
! width="80" | iLBC
! width="80" | AMR
! width="80" | AMR-WB
! width="80" | GSM-FR/GSM-EFR
! width="80" | EVRC/QCELP
|-
| TM-VOIP-1
| 404
| 128
| 200
| 168
| 128
| 66
| 72
| 84
| 102
| 60
| 120
| 96
|-
| TM-VOIP-2
| 808
| 256
| 400
| 336
| 256
| 132
| 144
| 168
| 204
| 120
| 240
| 192
|-
| TM-VOIP-3
| 1212
| 384
| 600
| 504
| 384
| 198
| 216
| 252
| 306
| 180
| 360
| 288
|-
| TM-VOIP-4
| 1616
| 512
| 800
| 672
| 512
| 264
| 288
| 336
| 408
| 240
| 480
| 384
|}

['''1'''] May require additional licenses

[[Category:Glossary]]
[[Category:Tmedia_Features|Voice Codecs]]
[[Category:Tdev_Features|Voice Codecs]]
[[Category:Needs_revising]]

Clearmode

2014-04-04T19:01:12Z

Clod Patry: initial version

ClearMode is defined in RFC4040 and it's a mode used to send data (vs voice).

== Configuration ==
To configure clearmode, please see:
*[[Toolpack v2.7: clearmode_configuration]]

== References ==
*[http://tools.ietf.org/html/rfc4040 RFC 4040]

[[Category:Needs revising]]

[[category:Glossary]]
[[Category:Needs revising]]

Toolpack v2.7: clearmode configuration

2014-04-04T18:54:24Z

Clod Patry: adding when ptime is not specify, this means 20ms.

=== '''''Applies to version(s): v2.7.''''' ===
{{DISPLAYTITLE:Configure ClearMode}}

Clearmode is defined in RFC4040 and is fully supported and does not required any special licensing or configuration from the Web portal to enable it.

== For ISDN/SS7 to SIP calls ==
If the SETUP/IAM message have its Information Transfer Rate and Information Transfer Capability set to 64kbits/sec Unrestricted, the Codec will be force to Clear Channel on the SIP side.

This will result in:

<code>
m=audio 0 RTP/AVP 96

a=rtpmap:96 CLEARMODE/8000

</code>
By not specifying the ptime, this means it's 20ms.

If you want to use a packetization time different from 20ms, you have to go Profile->RTP and Audio->Clear Channel.

[[Image:profile_clearmode.png]]

And this will result in a SDP like:

<code>
m=audio 0 RTP/AVP 96

a=rtpmap:96 CLEARMODE/8000

a=ptime:10

</code>

== For SIP to ISDN/SS7 calls ==
In the INVITE message, if the SDP is received with Clear Channel SDP (CLEARMODE/8000), the SETUP/IAM ISDN/SS7 Information Transfer Rate and Information Transfer Capability will be set accordingly (64kbits/sec Unrestricted).

Note:
The use of Clear Channel is equivalent to the cost of G.711 codec density.

== References ==
*[http://tools.ietf.org/html/rfc4040 RFC 4040]

Toolpack v2.7: clearmode configuration

2014-04-04T18:52:01Z

Clod Patry: remove a note with an internal ticket.

=== '''''Applies to version(s): v2.7.''''' ===
{{DISPLAYTITLE:Configure ClearMode}}

Clearmode is defined in RFC4040 and is fully supported and does not required any special licensing or configuration from the Web portal to enable it.

== For ISDN/SS7 to SIP calls ==
If the SETUP/IAM message have its Information Transfer Rate and Information Transfer Capability set to 64kbits/sec Unrestricted, the Codec will be force to Clear Channel on the SIP side.

This will result in:

<code>
m=audio 0 RTP/AVP 96

a=rtpmap:96 CLEARMODE/8000

</code>

If you want to use a packetization time different from 20ms, you have to go Profile->RTP and Audio->Clear Channel.

[[Image:profile_clearmode.png]]

And this will result in a SDP like:

<code>
m=audio 0 RTP/AVP 96

a=rtpmap:96 CLEARMODE/8000

a=ptime:10

</code>

== For SIP to ISDN/SS7 calls ==
In the INVITE message, if the SDP is received with Clear Channel SDP (CLEARMODE/8000), the SETUP/IAM ISDN/SS7 Information Transfer Rate and Information Transfer Capability will be set accordingly (64kbits/sec Unrestricted).

Note:
The use of Clear Channel is equivalent to the cost of G.711 codec density.

== References ==
*[http://tools.ietf.org/html/rfc4040 RFC 4040]

File:Profile clearmode.png

2014-04-04T18:50:47Z

Clod Patry: Example where to change the packetization time for the clearmode.

Example where to change the packetization time for the clearmode.

Toolpack v2.7: clearmode configuration

2014-04-04T18:48:52Z

Clod Patry: Initial version

=== '''''Applies to version(s): v2.7.''''' ===
{{DISPLAYTITLE:Configure ClearMode}}

Clearmode is defined in RFC4040 and is fully supported and does not required any special licensing or configuration from the Web portal to enable it.

== For ISDN/SS7 to SIP calls ==
If the SETUP/IAM message have its Information Transfer Rate and Information Transfer Capability set to 64kbits/sec Unrestricted, the Codec will be force to Clear Channel on the SIP side.

This will result in:

<code>
m=audio 0 RTP/AVP 96

a=rtpmap:96 CLEARMODE/8000

</code>

If you want to use a packetization time different from 20ms, you have to go Profile->RTP and Audio->Clear Channel.

[[Image:profile_clearmode.png]]

And this will result in a SDP like:

<code>
m=audio 0 RTP/AVP 96

a=rtpmap:96 CLEARMODE/8000

a=ptime:10

</code>

== For SIP to ISDN/SS7 calls ==
In the INVITE message, if the SDP is received with Clear Channel SDP (CLEARMODE/8000), the SETUP/IAM ISDN/SS7 Information Transfer Rate and Information Transfer Capability will be set accordingly (64kbits/sec Unrestricted).

Note:
The use of Clear Channel is equivalent to the cost of G.711 codec density.
We support only 20ms packet duration for now, but we have the Tracking 15313 Support configurable packetization times for RFC 4040 open to support from 5ms to 60ms. Please contact your sale to know what is the expected release.

== References ==
*[http://tools.ietf.org/html/rfc4040 RFC 4040]

SNMP

2014-03-10T20:47:11Z

Clod Patry: Correct the link for the RFC2495.

The Simple Network Management Protocol (SNMP) is used in network management systems to monitor attached hardware for changes in operation activity. SNMP provides a standardized approach to monitoring and managing network systems.
 For information on configuring your TMedia product to use the SNMP protocol, see the section labeled [[SNMP#Related Tasks|"'''Related Tasks'''"]].
 
== TelcoBridges and SNMP ==
TelcoBridges offers basic support for SNMP versions 1, 2, and 3. '''Toolpack supports SNMP V2 and V3 since release 2.5.80''' (see [[TMG-CONTROL_Version_2.5| TMG-CONTROL version history]]). More specifically, this grants users the ability to remotely poll (or GET) system variables, known as Managed Objects, which are represented in files known as MIB modules. TelcoBridges currently offers polling on '''standard''' MIB modules (RTP, SONET, DS1, DS3, ISDN, etc...) and on the TelcoBridges '''privately defined''' module ([[TB-MIB|'''TB-MIB''']]). 

 
''The following procedures should be used to support SNMP v1 '''ONLY''' for '''Toolpack system previous to 2.5.80''':
*[[Installing NetSNMP from an External Host]]
*[[TMG SNMP support|How to relay SNMP on TMG products]]
 

== Supported SNMP MIB modules ==
#[http://www.ietf.org/rfc/rfc1213.txt RFC 1213 MIB II (RFC1213-MIB)]
#*All tables of the RFC1213-MIB are supported, '''with the exception of''':
#**ipRouteTable
#**EGP group
#**atTable
#[http://www.ietf.org/rfc/rfc1573.txt RFC 1573 Evolution of Interfaces Group of MIB-II (IF-MIB)]
#*The following tables are supported:
#**ifTable
#**ifStackTable
#[http://www.faqs.org/rfcs/rfc2495.html RFC 2495 DS1, J1, E1, DS2, and E2 Interfaces (DS1-MIB)]
#*The following tables of the DS1-MIB are supported:
#**Dsx1ConfigTable
#**Dsx1CurrentTable
#**Dsx1IntervalTable
#**Dsx1TotalTable
#[http://www.faqs.org/rfcs/rfc2496.html RFC 2496 - Definitions of Managed Object for the DS3/E3 Interface Type (DS3-MIB)]
#*The following tables of the DS3-MIB are supported:
#**Dsx3ConfigTable
#**Dsx3CurrentTable
#**Dsx3IntervalTable
#**Dsx3TotalTable
#[http://www.faqs.org/rfcs/rfc1595.html RFC 1595 - Definitions of Managed Object for the SONET/SDH Interface Type (SONET-MIB)]
#*The following tables of the SONET-MIB are supported:
#**sonetMediumTable
#**sonetSectionCurrentTable
#**sonetSectionIntervalTable
#**sonetLineCurrentTable
#**sonetLineIntervalTable
#**sonetFarendLineCurrentTable
#**sonetFarendLineIntervalTable
#**sonetPathCurrentTable
#**sonetPathIntervalTable
#**sonetFarendPathCurrentTable
#**sonetFarendPathIntervalTable
#**sonetVtCurrentTable
#**sonetVtIntervalTable
#**sonetFarendVtCurrentTable
#**sonetFarendVtIntervalTable
#[http://www.rfc-editor.org/rfc/rfc2127.txt RFC 2127 - ISDN Management Information Base using SMIv2 (ISDN-MIB)]
#*The following tables of the ISDN-MIB are supported:
#**isdnBearerGroup
#**isdnSignalingGroup
#[[TB-MIB|Telcobridges Private MIB module (TB-MIB)]]
#*tbMtp2
#*tbM2pa
#*tbM2ua
#*tbM3ua
#*tbIua
#*CPU Usage
#*Memory Usage

=== SNMP IF-MIB ifTable interface type ===
The table below provides the interfaces type supported by TelcoBridges (ifTable) with their corresponding description. The ifType are described in Internet Assigned Number Authority (IANA) in [http://www.iana.org/assignments/ianaiftype-mib IANAifType-MIB]
{| cellpadding="0" border="0" style="width: 820px;" class="wikitable"
|-
! IANA ifType
! TelcoBridges Interface description
|-
| ethernetCsmacd(6)
| Baseboard Ethernet interfaces
|-
| ds1(18)
| Trunks Line Interface
|-
| ds3(30)
| DS3 Line Interface
|-
| sonet(39)
| SONET/SDH Line Interface
|-
| sonetPath(50)
| SONET/SDH Line Service PATH (VC4/VC3/STS1/DS3)
|-
| sonetVT(51)
| SONET/SDH Line Service SECTION (VC11/VC12/VT15/VT2)
|-
| isdn(63)
| ISDN Stack
|-
| lapd(77)
| ISDN LAPD Link (Primary)
|-
| lapd(77)
| ISDN LAPD Link (Backup)
|-
| isdn(63)
| IUA Link
|-
| isdn(63)
| IUA Peer
|-
| lapd(77)
| LAPD Link
|-
| ss7SigLink (156)
| SS7 M2PA Link
|-
| ss7SigLink (156)
| SS7 M2UA Link
|-
| ss7SigLink (156)
| SS7 M2UA Peer
|-
| ss7SigLink (156)
| Ss7 M3ua Sap
|-
| ss7SigLink (156)
| Ss7 M3ua Psp
|-
| ss7SigLink (156)
| Ss7 M3ua Psrv
|-
| ss7SigLink (156)
| Ss7 Mtp2 Link
|}

=== SNMP traps ===
The '''SNMP traps''' module of TelcoBridges products monitor the operation status of some MIBS OIDs and generates notifications when the states change. The default monitoring polling period is set to 1 minute. This value can be modified in the [[Configuring_tbSnmpAgent#Configuring_traps|tbSnmpAgent configuration]].

====IF-MIB SNMP Trap/Notification====
* linkDown (1.3.6.1.6.3.1.1.5.3) OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
* linkUp (1.3.6.1.6.3.1.1.5.4) OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }

Example of packet capture:
tcpdump port 162 -i mgmt0 -s 0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on mgmt0, link-type EN10MB (Ethernet), capture size 65535 bytes
14:08:51.491789 IP 10.7.0.13.37452 > 10.7.0.221.snmptrap: V2Trap(144) system.sysUpTime.0=9546160 S:1.1.4.1.0=S:1.1.5.4
interfaces.ifTable.ifEntry.ifIndex.452160.26=26 interfaces.ifTable.ifEntry.ifAdminStatus.452160.26=1
interfaces.ifTable.ifEntry.ifOperStatus.452160.26=1 S:1.1.4.3.0=E:8072.3.2.10

=== SNMP SET ===
The '''SNMP SET''' command is not supported by TelcoBridges products.

 

== Related Tasks ==
*[[tbSnmpAgent Configuration|Configuring the tbSnmpAgent application]]
 

== External Sources ==
*[http://en.wikipedia.org/wiki/Simple_Network_Management_Protocol Wikipedia article on SNMP]
*[http://www.net-snmp.org/ NetSNMP implementation of the SNMP protocol]
 

[[Category:Glossary]]
[[Category:Needs revising]]

TSG800

2013-10-31T13:27:29Z

Clod Patry: change the wrong chracteristics title

The TSG800 is TelcoBridges 1U Signaling/SIGTRAN gateway.

See TelcoBridges web site for additional information about [http://www.telcobridges.com/products/tsig-signaling-gateways/tsg800 TSG800]

== Characteristics of the TSG800 ==
*1 to 8 T1/E1s
*Single or redundant AC or DC power supplies

== Available configurations ==
*TSG800-1, (1 x T1/E1)
*TSG800-2, (2 x T1/E1)
*TSG800-3, (3 x T1/E1)
*TSG800-4, (4 x T1/E1)
*TSG800-5, (5 x T1/E1)
*TSG800-6, (6 x T1/E1)
*TSG800-7, (7 x T1/E1)
*TSG800-8, (8 x T1/E1)

== References ==
*[[Media:800_Series_Installation_Guide_Issue3.0.pdf|TSG800 Standalone & TSG800 1+1 System Installation Guide]]

== Related Articles ==

[[Category:Needs_revising]]

Status API

2013-10-25T14:12:03Z

Clod Patry: remove italic code which was incorrect

'''******* Getting used with Status API **********'''

Status API consists of status request queries based on a "path". Each status has a path, like:
/adapter
/adapter/ip_interface
/isup/interface
/clock/ref
etc.

We already provide two ways of accessing the Toolpack Status:
- Web Portal
- Command-line tool "tbstatus", that you will find installed within toolpack installation under /lib/tb/toolpack/pkg/2.X.X/bin/release/[your_platform]/tbstatus

'''******* Viewing status tree using Web Portal **********'''

I suggest that you start by using the "browse" option in the WEB portal: 
Go to the Web Portal -> Status -> Browse 
This tool will list available paths that can be queried. 
When you click one of these paths, the web page will show a table that list all fields returned from that path.

'''******* Viewing status tree using the command-line tool **********'''

The command-line tool will also allow getting a list of available paths:
./tbstatus
You can also query stats using one of these path, result is formatted as text output:
./tbstatus /adapter
Example above show stat of all adapters. You can query more specific stats too:
./tbstatus /adapter:TB005432
Or you can query "recursive" information that also includes paths "under" a base path:
./tbstatus /adapter:TB005432/*
Or you can query very deep and specific information:
./tbstatus /isup:ISUP/interface:ISUP_INTERFACE/cic_group:C002020_2_0_12

'''******* Paths for ISUP Circuit states **********'''

You can query states for one circuit group using a path like this one (replace C002020_2_0_12 by your circuit group name, as seen in it's Web portal configuration):
./tbstatus /isup/interface/cic_group:C002020_2_0_12

If you're using version 2.4 or up, you also have access to individual circuits states... but you HAVE to use "-x" option (extended stats mode) to get these.
To get states for all CICs of a group:
./tbstatus [u]-x[/u] /isup/interface/cic_group:C002020_2_0_12/*
For example, to get states for CIC #1705, you can use:
./tbstatus -x /isup/interface/cic_group/cic:1705

'''******* Querying/modifying individual field value using the command-line tool **********'''

To query individual field value, you add "::" after the path, then specify the specific field name.
For example:
./tbstatus /isup/interface/cic_group/cic:1705::desired_cic_state
Or to modify the circuit state (here to force blocking state):
./tbstatus /isup/interface/cic_group/cic:1705::desired_cic_state=Blocked

* Note: Remember that this change is PERSISTENT, which means circuit will remain blocked forever (no matter trunk state) until you change it again (to "Default", or "Unblocked" for example).

'''******* How to write code that use that API **********'''

Now that you understand a bit how Status API works, here is sort explanation on how to write code to manipulate these states.

In short you need to create and start the status client service in your application:
pClient = tbnew CTBCAFServiceStatusClient();
pClient->Start();

Then each available stat is reported under a "path". Your code can call following function to get available paths:
pClient->GetRegisteredPaths();

Once you know the path you want to query, you can retrieve the stats, either synchronously or asynchronously:
Synchronously:
pStatList = pClient->GetStat(
"your_path",
"x"
);

Asynchronously:
pClient->ReqStat(
pMyStatPipe,
"your_path",
"x"
);

Available options:
- Option "x" passed to in_pszOptions means "extended" stats query (provides more detailed stats in some cases, like individual circuits)
- Option "d" will make documentation be returned for each field with the query response (by default, only field names and values are returned)
For more information on "pMyStatPipe", please read documentation from the header files in the code.

Once you get your "pStatList", you can get each item it returned (there can be many if your request matches many):
pStat = pStatList->GetItem( un32StatIdx );

And for each item, you can get list of fields:
pFieldList = pStat->GetFields();

... and list each field (one field is one individual stat value):
pField = pFieldList->GetItem( un32FieldIdx );

Now, as you traverse the stat tree, you will encounter some values that can be changed using:
pField->Set( "new value" );

Once you have changed one or more fields of the stat, you can commit it:
pStat->CommitStates();

For more detailed information, please refer to the source code of the "tbstatus" application, and to documentation in appropriate header files.

'''******* Note **********'''
In order to get/set individual circuits states, you need:
- Release 2.4 or more recent, since release 2.3 allowed only to change state per circuit group... (per trunk in other words)
- Need to use "-x" in the options field of GetStat, as per-circuit stats are shown only in "extended" mode

Web Portal Tutorial Guide v2.7

2013-08-06T18:53:23Z

Clod Patry: replace CASR2 by CAS

=Introduction=
This guide is designed to provide users with a scenario-based approach to installing [[Tmedia]] and [[Tdev]] systems, using the Web Portal configuration tool. This means that users must first go through the steps that are general to all installations, and subsequently follow the instructions that are specific to their particular application scenario (this corresponds to the type of service, and hardware system being set up).

==Prerequisites==
This document assumes that the [[Tmedia]] or [[Tdev]] devices are installed as described in their Quick Reference Guides, and in the case of the Tmedia system communication has been established with the control network.

(Note: Tmedia devices are shipped with the Tmedia Web Portal pre-installed, while Tdev devices require that Toolpack be installed as described in the [[Tmedia_Installation#Tdev|Tdev installation guides]].)

Furthermore, in the case of a Tdev device and the initial configuration of the [[Toolpack]] application server, the following will have been provided:
*The Tdev device to which the Web Portal will first connect.
*The Tdev device will have been pre-configured with its physical TDM interface.
*The serial number of the Tdev device will have been entered into the configuration file.
*The application software for the Tdev device will have been pre-installed on the Toolpack application server, as described in the [[Tmedia_Installation#Tdev|Tdev installation guides]].

This document also assumes familiarity with topics, such as [[ISDN]] signaling, [[SIP]] signaling, [[SS7]], [[CAS|CAS R2]] signaling, and [[SIGTRAN]] signaling.

==Key Concepts==
*'''System:''' A system is defined as the complete solution that is designed for a network. If a system solution is comprised of 4 TMP6400’s and a TMS1600, then the combination of these TelcoBridges devices is termed a system.
*'''Hardware:''' Each TelcoBridges devices, whether it is a TMP6400, TMG3200, or TMS1600 is referred to as a hardware device or hardware adapter.
*'''Line Interface:''' The physical TDM module installed on the TelcoBridges device is referred to as a line interface.

== General Web Portal Applications ==

'''''IMPORTANT!''''' The Topics covered in the following table are common to all TMedia installations. Therefore, this section should be consulted before moving on to any other.

'''Topics covered here:'''

=System=

==Access and User Management==
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" rowspan="2" | Web Portal Access
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" colspan="3"| User Management
|-

! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add User
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Modify User Permission
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Delete User
|-
| valign="top" |
*[[Toolpack:Connecting to the Web Server and logging on to the web portal A|Connect to the Web Portal]]
*[[Toolpack:Logging Off B|Logging Off]]

|

*[[Toolpack:Creating User Groups A|Creating User Groups]]
*[[Toolpack:Creating Users B|Creating Users]]

| valign="top" |

*[[Modify User Permission]]

| valign="top" |

*[[Delete User]]

|}

==Database Backup==
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Create Database Backup
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Restore Database
|-
| valign="top" |
*[[Toolpack:Database Backup B|Carrying out a First Database Backup]]
*[[Toolpack:Downloading a Database Backup B|Downloading a Database Backup]]
| valign="top" |
*[[Toolpack:Uploading a Database Backup B|Uploading a Database Backup]]
*[[Toolpack:Restoring a Database Backup B|Restoring a Database Backup]]
|}

==Configuration==
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Activating a Configuration
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Web Portal Profile
|-
| valign="top" |
*[[Toolpack:Activating_the_Configuration B|Activating the Configuration]]
| valign="top" |
*[[Toolpack:Web_Portal_Profile A|Web Portal Profile]]
|}

<div id="Minor Package Upgrade">
==Minor Package Upgrade==
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Installing a Package
|-
| valign="top" |
*[[Toolpack:Downloading_a_Release_A|Retrieving a software release]]
*[[Toolpack:Uploading_a_Release_A|Uploading a software release]]
*[[Toolpack:Activating_a_Release_A|Activating a software release]]
|}
</div>

==Statistics==
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Configuration
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Profile
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Graphs
|-
| valign="top" |
* [[Toolpack:Configuring_Statistics_A|Configuring Statistics Polling]]
| valign="top" |
* [[Toolpack:Creating_Statistics_Profile_A|Creating Statistics Profiles]]
* [[Toolpack:Enabling_Statistics_Profile_A|Enabling Statistics Profiles]]
| valign="top" |
* [[Toolpack:Generating_Graphs_A|Generating Graphs]]
|}

==Audit Logs==
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Audit Logs
|-
| valign="top" |
*[[Toolpack:Accessing_Audit_Logs_A|Working with Audit Logs]]

|}

==VoIP Bonding==
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | VoIP Bonding
|-
| valign="top" |
*[[Toolpack:Enabling_VoIP_Bonding_A|Enabling VoIP Bonding]]
|}
Note: Web portal configuration for VoIP bonding is not yet available.

=Hardware=

==New Hardware==
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add telecom hardware
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add TMS hardware
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add 1+1 group
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add N+1 group

|-
| valign="top" |
*[[Toolpack:Adding_an_Adapter_C|Add telecom hardware]]
| valign="top" |
*[[Toolpack:Adding_an_TMS_B|Add TMS hardware]]
| valign="top" |
*[[Toolpack:Creating_a_1+1_Group_A|Add 1+1 group]]
| valign="top" |
*[[Toolpack:Creating_a_N+1_Patch_Panel_A|Add N+1 patch panel]]
*[[Toolpack:Creating_a_N+1_Group_A|Add N+1 group]]
|}

==TDM Network==
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Allocate Physical Interfaces
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | (Step 2) System Clock

|-
| valign="top" |
*[[Toolpack:Creating_a_Line_Interface B|Create Line Interfaces]]
*[[Toolpack:Creating_a_Line_Service B|Create Line Services]]
| valign="top" |
*[[Toolpack:Defining_a_Clocking_Source_B|System Clock]]

|}

==IP Network==
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) IP Interfaces
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Create an IP port range

|-
| valign="top" |
*[[Toolpack:Configuring_VoIP_Interfaces B|Configuring VoIP Interfaces]]
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range B|Create an IP port range]]

|}

=Protocol Stacks=

==ISDN NFAS==

{| cellpadding="5" border="1" class="wikitable"
|-

! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Allocate Physical Interfaces

! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Configure ISDN-PRI Signaling

! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Modify NAP profile

! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 4) Configure Network Access Points (NAPs)
|-

| valign="top" |
*[[Toolpack:Creating_a_Line_Interface B|Create Line interfaces]]
*[[Toolpack:Creating_a_Line_Service B|Create Line Services]]

| valign="top" |
*[[Toolpack:Configuring_an_ISDN_Stack C|Configure an ISDN stack]]
OR 
*[[Toolpack:Configuraing_NFAS A|Configure NFAS]]

| valign="top" |
*[[Toolpack:Modify_NAP_profile B|Modify profile]]

| valign="top" |
*[[Toolpack:Allocating_an_ISDN_Network_Access_Point_(NAP) C|Allocate an ISDN NAP]]

|}

===''ISDN Advanced Features''===

<div class="mw-collapsible mw-collapsed" data-collapsetext="ISDN NFAS Overlap" data-expandtext="ISDN NFAS Overlap" style="width: 400px;">

{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" |ISDN Overlap Sending
|-
| valign="top" |
*[[Toolpack:Configuring_Overlap A|''ISDN NFAS Overlap Parameters'']]
|}

</div>
 

==CAS==

{| cellpadding="5" border="1" class="wikitable"
|-

! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Allocate Physical Interfaces
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Configuring a CAS stack
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Modify NAP profile
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 4) Configure Network Access Points (NAPs)

|-
| valign="top" |
*[[Toolpack:Creating_a_Line_Interface B|Create Line Interfaces]]
*[[Toolpack:Creating_a_Line_Service B|Create Line services]]
| valign="top" |
*[[Toolpack:Copy variant script B|Copy variant script]]
*[[Toolpack:Create CAS R2 stack B|Create CAS stack]]
*[[Toolpack:Setting CAS R2 BACK DIGITS variable B|Set backward digits string]]
| valign="top" |
*[[Toolpack:Modify_NAP_profile B|Modify profile]]
| valign="top" |
*[[Toolpack:Creating_a_CAS_R2_NAP B|Create a CAS NAP]]

|}

==SIP==

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Configure IP port range
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Configure SIP Signaling
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Configure Codecs and Tone Detection
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 4) Modify NAP profile
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 5) Configure Network Access Points (NAPs)
|-
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range A|Create an IP port range]]

| valign="top" |
*[[Toolpack:Creating_a_SIP_Stack B|Create a SIP stack]]
*[[Toolpack:Creating_a_SIP_Transport_Server B|Create a SIP transport server]]
*[[Toolpack:Creating_a_Service_Access_Point_(SAP) B|Create a service access point (SAP)]]

| valign="top" |
*[[Toolpack:Accessing_Codec_and_Tone_Detection_Profiles_and_Validating_Settings B|Access profiles and validate settings]]

| valign="top" |
*[[Toolpack:Modify_NAP_profile B|Modify profile]]

| valign="top" |
*[[Toolpack:Allocating_a_SIP_Network_Access_Point_(NAP) B|Allocate a SIP NAP]]

|}

===SIP Advanced Features===
<div class="mw-collapsible mw-collapsed" data-collapsetext="SIP-I SIP-T" data-expandtext="SIP-I SIP-T" style="width: 400px;">
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | SIP-I SIP-T
|-
| valign="top" |
*[[Enabling_SIP_I_SIP_T_B|Enabling SIP-I SIP-T]]
|}
</div>
<div class="mw-collapsible mw-collapsed" data-collapsetext="SIP Spiral" data-expandtext="SIP Spiral" style="width: 400px;">
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | SIP Spiral
|-
| valign="top" |
*[[Enabling_SIP_Spiral_B|Enabling SIP Spiral]]
|}

</div>

<div class="mw-collapsible mw-collapsed" data-collapsetext="NAT traversal" data-expandtext="NAT traversal" style="width: 400px;">
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | Remote NAT Traversal
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | Local NAT Traversal
|-
| valign="top" |
*[[Enabling_Remote_NAT_Traversal_A|Enabling Remote NAT Traversal]]

| valign="top" |
*[[Enabling_Local_NAT_Traversal_A|Enabling Local NAT Traversal]]
|}
</div>

<div class="mw-collapsible mw-collapsed" data-collapsetext="DNS" data-expandtext="DNS" style="width: 400px;">
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | DNS
|-
| valign="top" |
*[[Toolpack:Configuring_DNS_Parameters_A|Enabling DNS]]
|}
</div>

==SS7 ISUP==

===MTP2-MTP3-ISUP===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Allocate Physical Interfaces
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Configuring the MTP2 Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Configuring the MTP3 Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 4) Configuring the ISUP Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 5) Modify NAP profile
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 6) Configure Network Access Points (NAPs)

|-
| valign="top" |
*[[Toolpack:Creating_a_Line_Interface B|Create a new line interface]]
*[[Toolpack:Creating_a_Line_Service B|Create a new line service]]

| valign="top" |
*[[Toolpack:Creating_an_MTP2_Configuration B|Create an MTP2 Configuration]]
*[[Toolpack:Creating_MTP2_Links A|Create an MTP2 Link]]

| valign="top" |
*[[Toolpack:Creating_an_MTP3_Configuration C|Create an MTP3 Configuration]]
*[[Toolpack:Creating_an_MTP3_Network A|Create an MTP3 Network]]
**[[Toolpack:Creating_SS7_Point_Codes B|Create an MTP3 Point Code]]
**[[Toolpack:Creating_an_MTP3_Linkset A|Create an MTP3 Linkset]]
***[[Toolpack:Creating_MTP3_Links A|Create MTP3 Links]]
**[[Toolpack:Creating_an_MTP3_Route A|Create an MTP3 Route]]

| valign="top" |
*[[Toolpack:Creating_an_ISUP_Stack B|Create an ISUP Stack]]
*[[Toolpack:Creating_an_ISUP_Network A|Create an ISUP Network]]
*[[Toolpack:Creating_an_ISUP_User_Part A|Create an ISUP User Part]]
*[[Toolpack:Creating_an_ISUP_Interface A|Create an ISUP Interface]]
*[[Toolpack:Creating ISUP CIC Groups A|Create ISUP CIC Groups]]

| valign="top" |
*[[Toolpack:Modify_NAP_profile B|Modify profile]]

| valign="top" |
*[[Toolpack:Creating_a_NAP_(SIGTRAN)_B|Create an ISUP NAP]]

|}

===M2PA-MTP3-ISUP===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Allocate Physical Interfaces
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Configuring the M2PA Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Configuring the MTP3 Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 4) Configuring the ISUP Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 5) Modify NAP profile
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 6) Configure Network Access Points (NAPs)

|-
| valign="top" |
*[[Toolpack:Creating_a_Line_Interface B|Create a new line interface]]
*[[Toolpack:Creating_a_Line_Service B|Create a new line service]]

| valign="top" |
*[[Toolpack:Creating the SCTP Configuration B|Edit the SCTP Configuration]]
*[[Toolpack:Creating the M2PA Configuration B|Create an M2PA Configuration]]
**[[Toolpack:Creating an M2PA SAP B|Create an M2PA SAP]]
**[[Toolpack:Adding M2PA Links A|Add M2PA Links]]

| valign="top" |
*[[Toolpack:Creating_an_MTP3_Configuration C|Create an MTP3 Configuration]]
*[[Toolpack:Creating_an_MTP3_Network A|Create an MTP3 Network]]
**[[Toolpack:Creating_SS7_Point_Codes B|Create an MTP3 Point Code]]
**[[Toolpack:Creating_an_MTP3_Linkset A|Create an MTP3 Linkset]]
***[[Toolpack:Creating_MTP3_Links A|Create MTP3 Links]]
**[[Toolpack:Creating_an_MTP3_Route A|Create an MTP3 Route]]

| valign="top" |
*[[Toolpack:Creating_an_ISUP_Stack B|Create an ISUP Stack]]
*[[Toolpack:Creating_an_ISUP_Network A|Create an ISUP Network]]
*[[Toolpack:Creating_an_ISUP_User_Part A|Create an ISUP User Part]]
*[[Toolpack:Creating_an_ISUP_Interface A|Create an ISUP Interface]]
*[[Toolpack:Creating ISUP CIC Groups A|Create ISUP CIC Groups]]

| valign="top" |
*[[Toolpack:Modify_NAP_profile B|Modify profile]]

| valign="top" |
*[[Toolpack:Creating_a_NAP_(SIGTRAN)_B|Create an ISUP NAP]]

|}

===M3UA-ISUP===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Allocate Physical Interfaces
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Configuring the M3UA Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Configuring the ISUP Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 4) Modify NAP profile
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 5) Configure Network Access Points (NAPs)

|-

| valign="top" |
*[[Toolpack:Creating_a_Line_Interface B|Create a new line interface]]
*[[Toolpack:Creating_a_Line_Service B|Create a new line service]]

| valign="top" |
*[[Toolpack:Creating the SCTP Configuration B|Edit the SCTP Configuration]]
*[[Toolpack:Creating SS7 Point Codes A|Create SS7 Point Codes]]
*[[Toolpack:Creating an M3UA Configuration (IPSP) B|Create an M3UA Configuration]]
**[[Toolpack:Creating an M3UA SAP A|Create an M3UA SAP]]
**[[Toolpack:Creating an M3UA Network A|Create an M3UA Network]]
**[[Toolpack:Creating an M3UA User Part A|Create an M3UA User Part]]
**[[Toolpack:Creating an M3UA Peer Signalling Process (IPSP) A|Create an M3UA Peer Signalling Process]]
**[[Toolpack:Creating an M3UA Peer Server A|Create an M3UA Peer Server]]
**[[Toolpack:Creating an M3UA Route A|Create an M3UA Route]]

| valign="top" |
*[[Toolpack:Creating_an_ISUP_Stack B|Create an ISUP Stack]]
*[[Toolpack:Creating_an_ISUP_Network A|Create an ISUP Network]]
*[[Toolpack:Creating_an_ISUP_User_Part A|Create an ISUP User Part]]
*[[Toolpack:Creating_an_ISUP_Interface A|Create an ISUP Interface]]
*[[Toolpack:Creating ISUP CIC Groups A|Create ISUP CIC Groups]]

| valign="top" |
*[[Toolpack:Modify_NAP_profile B|Modify profile]]

| valign="top" |
*[[Toolpack:Creating_a_NAP_(SIGTRAN)_B|Create an ISUP NAP]]

|}

===SS7 Advanced Features===

<div class="mw-collapsible mw-collapsed" data-collapsetext="SS7 SPIROU configuration" data-expandtext="SS7 SPIROU configuration" style="width: 400px;">
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | Configuring SPIROU
|-
| valign="top" |
*[[Toolpack:Modifying_Profile_for_SPIROU A|Modifying Profile]]
*[[Toolpack:Modifying_Gateway_Configurations_for_SPIROU A|Modifying Gateway Configurations]]
*[[Toolpack:Modifying_ISUP_Stack_for_SPIROU A|Modifying ISUP Stack]]
*[[Toolpack:Modifying_ISUP_Userpart_for_SPIROU A|Modifying ISUP Userpart]]
*[[Toolpack:Optional_configurations_for_SPIROU A|Optional modifications]]
|}

</div>

==SCCP-TCAP==

===MTP2-MTP3-SCCP-TCAP===

{| cellpadding="5" border="1" class="wikitable"

! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Allocate Physical Interfaces
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Configuring the MTP2 Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Configuring the MTP3 Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 4) Configuring the SCCP Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 5) Configuring the TCAP Layer (optional)

|-

| valign="top" |
*[[Toolpack:Creating_a_Line_Interface B|Create a new line interface]]
*[[Toolpack:Creating_a_Line_Service B|Create a new line service]]

| valign="top" |
*[[Toolpack:Creating_an_MTP2_Configuration B|Create an MTP2 Configuration]]
*[[Toolpack:Creating_MTP2_Links A|Create an MTP2 Link]]

| valign="top" |
*[[Toolpack:Creating_an_MTP3_Configuration C|Create an MTP3 Configuration]]
*[[Toolpack:Creating_an_MTP3_Network A|Create an MTP3 Network]]
**[[Toolpack:Creating_SS7_Point_Codes B|Create an MTP3 Point Code]]
**[[Toolpack:Creating_an_MTP3_Linkset A|Create an MTP3 Linkset]]
***[[Toolpack:Creating_MTP3_Links A|Create MTP3 Links]]
**[[Toolpack:Creating_an_MTP3_Route A|Create an MTP3 Route]]

| valign="top" |
*[[Toolpack:Creating_an_SCCP_Stack A| Create an SCCP Stack]]
*[[Toolpack:Creating_an_SCCP_Network A|Create an SCCP Network]]
**[[Toolpack:Creating_an_SCCP_Userpart A|Create an SCCP Userpart]]
**[[Toolpack:Creating_an_SCCP_LSAP A|Create an SCCP LSAP]]
***[[Toolpack:Creating_an_SCCP_Route A|Create an SCCP Route]]
****[[Toolpack:Creating_an_SCCP_SSN A|Create an SCCP SSN]]
*[[Toolpack:Creating_an_SCCP_GTT_Association A|Create an SCCP GTT Association]]
**[[Toolpack:Creating_an_SCCP_GTT_Address_Map A|Create an SCCP GTT Address Map]]

| valign="top" |
*[[Toolpack:Creating_a_TCAP_Stack A|Create a TCAP Stack]]
**[[Toolpack:Creating_a_TCAP_Userpart A| Create a TCAP Userpart]]
*[[Toolpack:Activating_the_Configuration B|Activating the Configuration]]

|}

===M2PA-MTP3-SCCP-TCAP===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Allocate Physical Interfaces
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Configuring the M2PA Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Configuring the MTP3 Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 4) Configuring the SCCP Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 5) Configuring the TCAP Layer (optional)

|-
| valign="top" |
*[[Toolpack:Creating_a_Line_Interface B|Create a new line interface]]
*[[Toolpack:Creating_a_Line_Service B|Create a new line service]]

| valign="top" |
*[[Toolpack:Creating the SCTP Configuration B|Edit the SCTP Configuration]]
*[[Toolpack:Creating the M2PA Configuration B|Create an M2PA Configuration]]
**[[Toolpack:Creating an M2PA SAP B|Create an M2PA SAP]]
**[[Toolpack:Adding M2PA Links A|Add M2PA Links]]

| valign="top" |
*[[Toolpack:Creating_an_MTP3_Configuration C|Create an MTP3 Configuration]]
*[[Toolpack:Creating_an_MTP3_Network A|Create an MTP3 Network]]
**[[Toolpack:Creating_SS7_Point_Codes B|Create an MTP3 Point Code]]
**[[Toolpack:Creating_an_MTP3_Linkset A|Create an MTP3 Linkset]]
***[[Toolpack:Creating_MTP3_Links A|Create MTP3 Links]]
**[[Toolpack:Creating_an_MTP3_Route A|Create an MTP3 Route]]

| valign="top" |
*[[Toolpack:Creating_an_SCCP_Stack A| Create an SCCP Stack]]
*[[Toolpack:Creating_an_SCCP_Network A|Create an SCCP Network]]
**[[Toolpack:Creating_an_SCCP_Userpart A|Create an SCCP Userpart]]
**[[Toolpack:Creating_an_SCCP_LSAP A|Create an SCCP LSAP]]
***[[Toolpack:Creating_an_SCCP_Route A|Create an SCCP Route]]
****[[Toolpack:Creating_an_SCCP_SSN A|Create an SCCP SSN]]
*[[Toolpack:Creating_an_SCCP_GTT_Association A|Create an SCCP GTT Association]]
**[[Toolpack:Creating_an_SCCP_GTT_Address_Map A|Create an SCCP GTT Address Map]]

| valign="top" |
*[[Toolpack:Creating_a_TCAP_Stack A|Create a TCAP Stack]]
**[[Toolpack:Creating_a_TCAP_Userpart A| Create a TCAP Userpart]]
*[[Toolpack:Activating_the_Configuration B|Activating the Configuration]]

|}

===M3UA-SCCP-TCAP===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Allocate Physical Interfaces
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Configuring the M3UA Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Configuring the SCCP Layer
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 4) Configuring the TCAP Layer (optional)

|-

| valign="top" |
*[[Toolpack:Creating_a_Line_Interface B|Create a new line interface]]
*[[Toolpack:Creating_a_Line_Service B|Create a new line service]]

| valign="top" |
*[[Toolpack:Creating the SCTP Configuration B|Edit the SCTP Configuration]]
*[[Toolpack:Creating SS7 Point Codes A|Create SS7 Point Codes]]
*[[Toolpack:Creating an M3UA Configuration (IPSP) B|Create an M3UA Configuration]]
**[[Toolpack:Creating an M3UA SAP A|Create an M3UA SAP]]
**[[Toolpack:Creating an M3UA Network A|Create an M3UA Network]]
**[[Toolpack:Creating an M3UA User Part A|Create an M3UA User Part]]
**[[Toolpack:Creating an M3UA Peer Signalling Process (IPSP) A|Create an M3UA Peer Signalling Process]]
**[[Toolpack:Creating an M3UA Peer Server A|Create an M3UA Peer Server]]
**[[Toolpack:Creating an M3UA Route A|Create an M3UA Route]]

| valign="top" |
*[[Toolpack:Creating_an_SCCP_Stack A| Create an SCCP Stack]]
*[[Toolpack:Creating_an_SCCP_Network A|Create an SCCP Network]]
**[[Toolpack:Creating_an_SCCP_Userpart A|Create an SCCP Userpart]]
**[[Toolpack:Creating_an_SCCP_LSAP A|Create an SCCP LSAP]]
***[[Toolpack:Creating_an_SCCP_Route A|Create an SCCP Route]]
****[[Toolpack:Creating_an_SCCP_SSN A|Create an SCCP SSN]]
*[[Toolpack:Creating_an_SCCP_GTT_Association A|Create an SCCP GTT Association]]
**[[Toolpack:Creating_an_SCCP_GTT_Address_Map A|Create an SCCP GTT Address Map]]

| valign="top" |
*[[Toolpack:Creating_a_TCAP_Stack A|Create a TCAP Stack]]
**[[Toolpack:Creating_a_TCAP_Userpart A| Create a TCAP Userpart]]
*[[Toolpack:Activating_the_Configuration B|Activating the Configuration]]

|}

==H.248 MEGACO==

If the Tmedia is used to forward signalling messages to the SSW, you will require to configure M2UA, M3UA or IUA before configuring H.248.

If the Tmedia is used to connect media only, then you can go straight to [[#H.248|H.248 Configuration]]

===M2UA===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Create Line Interfaces
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Create MTP2 links
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Create M2UA configuration

|-

| valign="top" |
*[[Toolpack:Creating_a_Line_Interface B|Create line interfaces]]
*[[Toolpack:Creating_a_Line_Service B|Create line services]]

| valign="top" |

*[[Toolpack:Creating an MTP2 Configuration B|Create an MTP2 Configuration]]
**[[Toolpack:Creating MTP2 Links A|Create MTP2 Links]]

| valign="top" |

*[[Toolpack:Creating the SCTP Configuration B|Edit the SCTP Configuration]]
*[[Toolpack:Creating the M2UA Configuration B|Create an M2UA Configuration]]
**[[Toolpack:Creating an M2UA SAP A|Create an M2UA SAP]]
**[[Toolpack:Creating an M2UA Cluster A|Create an M2UA Cluster]]
**[[Toolpack:Creating M2UA Links A|Create M2UA Links]]
**[[Toolpack:Creating M2UA Peers A|Create M2UA Peers]]

|}

===M3UA===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Create Line Interfaces
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Create MTP2 links
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Create MTP3 configuration
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 4) Create M3UA configuration
|-

| valign="top" |
*[[Toolpack:Creating_a_Line_Interface B|Create line interfaces]]
*[[Toolpack:Creating_a_Line_Service B|Create line services]]

| valign="top" |
*[[Toolpack:Creating an MTP2 Configuration B|Create an MTP2 Configuration]]
*[[Toolpack:Creating MTP2 Links A|Create MTP2 Links]]

| valign="top" |
*[[Toolpack:Creating SS7 Point Codes A|Create SS7 Point Codes]]
*[[Toolpack:Creating an MTP3 Configuration C|Create an MTP3 Configuration]]
**[[Toolpack:Creating an MTP3 Network A|Create an MTP3 Network]]
**[[Toolpack:Creating an MTP3 Linkset A|Create an MTP3 Linkset]]
**[[Toolpack:Creating MTP3 Links (M3UA) A|Create MTP3 Links]]
**[[Toolpack:Creating an MTP3 Route A|Create an MTP3 Route]]

| valign="top" |
*[[Toolpack:Creating the SCTP Configuration B|Edit the SCTP Configuration]]
*[[Toolpack:Creating an M3UA Configuration (SGP) A|Create an M3UA Configuration]]
**[[Toolpack:Creating an M3UA SAP A|Create an M3UA SAP]]
**[[Toolpack:Creating an M3UA Network A|Create an M3UA Network]]
**[[Toolpack:Creating an M3UA User Part A|Create an M3UA User Part]]
**[[Toolpack:Creating an M3UA Peer Signalling Process (SGP) A|Create an M3UA Peer Signalling Process]]
**[[Toolpack:Creating an M3UA Peer Server A|Create an M3UA Peer Server]]
**[[Toolpack:Creating an M3UA Route (SGP) A|Create an M3UA Route]] 

|}

===IUA===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Create Line Interfaces
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Create M2UA Configuration

|-

| valign="top" |
*[[Toolpack:Creating a Line Interface B|Create Line Interfaces]]
*[[Toolpack:Creating a Line Service B|Create Line services]]

| valign="top" |
*[[Toolpack:Creating the SCTP Configuration B|Edit the SCTP Configuration]]
*[[Toolpack:Creating the IUA Configuration B|Create an IUA Configuration]]
**[[Toolpack:Creating an IUA SAP A|Create an IUA SAP]]
**[[Toolpack:Creating an IUA Cluster A|Create an IUA Cluster]]
**[[Toolpack:Creating IUA Links A|Create IUA Links]]
**[[Toolpack:Creating IUA Peers A|Create IUA Peers]]

|}

===H.248===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 1) Allocate Physical Interfaces
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 2) Create IP Port Ranges
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 3) Modify NAP profile
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 4) Configure Network Access Points (NAPs)

|-

| valign="top" |
*[[Toolpack:Creating_a_Line_Interface B|Create line interfaces]]
*[[Toolpack:Creating_a_Line_Service B|Create line services]]

| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range B|Create IP port ranges]]
| valign="top" |
*[[Toolpack:Modify_NAP_profile B|Modify profile]]

| valign="top" |
*[[Toolpack:Allocating_a_VoIP_Network_Access_Point_(NAP) B|Allocate a VoIP NAP]]
*[[Toolpack:Allocating_a_TDM_Network_Access_Point_(NAP) B|Allocate a TDM NAP]]
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 5) Configure Media Gateway for H.248 mode
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 6) Add a New Media Gateway Controller
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (Step 7) Associate NAPs Resources to H.248 Configuration

|-

| valign="top" |
*[[Toolpack:Configure the Media_Gateway_for_H248_Mode B|Configure the Media Gateway for H.248 mode]]
*[[Toolpack:Creating_an_H.248_Configuration B|Create a new H.248 configuration]]
| valign="top" |
*[[Toolpack:Adding_a_Media_Gateway_Controller_(MGC) A|Add a new media gateway controller (MGC)]]
| valign="top" |
*[[Toolpack:Associating_NAPs_with_an_H.248_Configuration B|Associate the NAPs with the H.248 configuration]]
*[[Toolpack:Selecting_Timeslots_for_TDM_Interfaces A|Select timeslots for the TDM interfaces]]

|}

<div id="CDR">

=CDR (Call Detail Record)=
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" |Text CDR
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" |RADIUS
|-

| valign="top" |
*[[Toolpack:Enabling CDR A|Enabling CDR]]

| valign="top" |
*[[Toolpack:Enabling RADIUS B|Enabling RADIUS]]
*[[Toolpack:Configuring_RADIUS_client A|Configuring RADIUS client]]
*[[Toolpack:Adding_RADIUS_server A|Adding RADIUS server(s)]]

|}
</div>

=''Fax''=

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" |FAX passthrough
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" |FAX T.38
|-
| valign="top" |
*[[Configure_Fax_Relay_A|Configure Fax Relay]]
*[[Configure_Fax_Passthrough_A|Configure Fax Passthrough]]
| valign="top" |
*[[Configure_Fax_Relay_A|Configure Fax Relay]]
*[[Configure_Fax_T38_A|Configure Fax T38]]
|}

=Routes=

==Static Route==
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" |Add routes
|-
| valign="top" |
*[[Toolpack:Creating_a_First_Call_Route B|Create a first call route]]
|}

==''Routing Script''==
TelcoBridges provides a wide variety of routing script examples which customers can apply directly in their web configuration according to their needs by following just a few simple steps. Please select one of the following examples according to your needs. You may modify it when necessary.

'''*Flexible NOA:''' Remap the Calling/Called NOA flexibly based on the routes. It should cover most of the NOA requests since the routes include the calling/called remapping as well.

'''*Prefix NOA:''' Remapp Calling/Called NOA according to the prefix of the calling/called number, manipulate calling/called number. For calling number, if it is a privacy call, use the number in P-Asserted-Identity line or Remote-Party-ID line as the calling number to remap the NOA and do the manipulation.

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" |Flexible NOA
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" |Prefix NOA
|-
| valign="top" |

*[[Toolpack:Create_New_Routing_Script_B|Create new routing script]]
*[[Import_Customized_Routing_Script_A|Import customized routing script]]
*[[Add_NOA_Columns_in_Routes_B|Add NOA columns in routes]]
*[[Enable_Routing_Script_A|Enable routing script]]
*[[Activate_Configuration_B|Activate configuration]]

| valign="top" |

*[[Toolpack:Create_New_Routing_Script_B|Create new routing script]]
*[[Import_Customized_Routing_Script_A|Import customized routing script]]
*[[Enable_Routing_Script_A|Enable routing script]]
*[[Activate_Configuration_B|Activate configuration]]

|}

<div class="mw-collapsible mw-collapsed" data-collapsetext="Configuring Audio Prompts" data-expandtext="Audio Prompts" style="width: 400px;">

{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" |Audio Prompts
|-
| valign="top" |
*[[Toolpack:Configuring_Audio_Prompts B|Audio Prompts]]
|}

</div>
 

==Label Routing==

This section assumes:
* '''The routing script is already implemented''' (you just need to add the label routing functionality)
* '''The routeset definition and digimap files are already created'''

{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" |Add label routing functionality
|-
| valign="top" |
*[[Toolpack:Adding_Label_Routing_to_any_Routing_Script_B|Add Label Routing to script]]
*[[Toolpack:Create_Databse_Files_B|Create Database Files]]
*[[Toolpack:Assign_Routing_Script_DB_Files_to_Gateway_Application_B|Assign Routing/Script Files to the Gateway Application]]
*[[Toolpack:Add_Digitmap_Files_B|Add the Digit Map Files to the System]]
*[[Toolpack:Add_Routeset_Definition_Files_B|Add the Routset Definition Files to the System]]
*[[Toolpack:Assign_Definition_Digitmap_Files_per_NAP_B|Assign Defintion/Digitmap Files on a per NAP Basis]]
*[[Toolpack:Generate_Dynamic_Routes_B|Generate Dynamic Routes]]
*[[Activate_Configuration_B|Activate configuration]]
|}
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" |Update definition/digitmap files
|-
| valign="top" |
*[[Toolpack:Update_Digitmap_Files_B|Update the Digitmap Files]]
*[[Toolpack:Update_Routeset_Definition_Files_B|Update the Routeset Definition Files]]
*[[Toolpack:Generate_Dynamic_Routes_B|Generate Dynamic Routes]]
*[[Activate_Configuration_B|Activate configuration]]
|}
|}

==RADIUS Authorization and Authentication==
{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="240" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" |RADIUS
|-
| valign="top" |
*[[Toolpack:Configuring_RADIUS_client_B|Configure RADIUS client]]
*[[Toolpack:Adding_RADIUS_server_B|Add RADIUS authorization server]]
*[[Toolpack:Configuring_RADIUS_authorization_A|Configure RADIUS authorization]]
|}
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="300" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" |RADIUS (with custom dictionary)
|-
| valign="top" |
*[[Toolpack:Import_RADIUS_Custom_Dictionary_A|Import RADIUS Custom Dictionary]]
*[[Toolpack:Configuring_RADIUS_client_B|Configure RADIUS Client]]
*[[Toolpack:Adding_RADIUS_server_B|Add RADIUS Authorization Server]]
*[[Toolpack:Create_New_Routing_Script_B|Create New Routing Script]]
*[[Toolpack:Configuring_RADIUS_authorization_A|Configure RADIUS Authorization]]
*[[Toolpack:Enable_Routing_Script_B|Enable Routing Script]]
|}
|}

<div id="Lawful_Intercept">

=Lawful Interception=
{| cellpadding="5" border="1" class="wikitable"
! width="300" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" |Lawful Interception
|-
| valign="top" |
*[[Toolpack:Verifying_lawful_interception_A|Verify Lawful Interception Prerequisite]]
*[[Toolpack:Importing_lawful_interception_A|Import a Lawful Interception CSV File]]
*[[Toolpack:Create_New_Routing_Script_B|Create New Routing Script]]
*[[Toolpack:Enable_Lawful_Interception_in_Routing_Script_A|Enable Lawful Interception in Routing script]]
*[[Toolpack:Enable_Routing_Script_B|Enable Routing Script]]
*[[Toolpack:Configuring_lawful_interception_A|Configure Lawful Agencies]]
|}
</div>

=Troubleshooting=

==Call Trace==
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" |Call trace
|-
| valign="top" |
*[[Toolpack:Configuring_Call_Trace_B|Call trace]]
|}

==Test Call==
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" |Test Call
|-
| valign="top" |
*[[Creating_A_Test_Call_A|Creating a Test Call]]
|}

==Target Recording==
{| cellpadding="5" border="1" class="wikitable"
! width="300" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Activating a Configuration
! width="300" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Web Portal Profile
|-
| valign="top" |
*[[Enabling_Recordings_A|Enabling the Recording of Calls]]
| valign="top" |
* [[Accessing_Recording|Accessing the Recording]]
|}

=''Status Menus''=

The Web Portal configuration tool will guide you through a number of status menus, each of which indicate the current state of a certain hardware service (assuming said service has been configured).
The following table contains the general conventions of the Web Portal's display '''(A)''', as well as a variety of specific status menus '''(B)'''.

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (A) Menus Overview
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | (B) Individual Menu Descriptions

|-
| valign="top" |

*[[Toolpack:Tmedia_Status_Menus A|Tmedia Status Menus]]
**[[Toolpack:Status_Menus:Navigation A|Navigation]]
**[[Toolpack:Status_Menus:Screen_Conventions A|Status Screen Conventions]]

| valign="top" |

*[[Toolpack:Status_Menus:System B|System]]
*[[Toolpack:Status_Menus:Adapters_and_IP_Interfaces B|Adapters and IP Interfaces]]
*[[Toolpack:Status_Menus:1+1|1+1]]
*[[Toolpack:Status_Menus:N+1|N+1]]
*[[Toolpack:Status_Menus:Hosts A|Hosts]]
*[[Toolpack:Status_Menus:Applications A|Applications]]
*[[Toolpack:Status_Menus:TDM_Lines A|TDM Lines]]
**[[Toolpack:Status_Menus:Line Interfaces A|Line Interfaces]]
*[[Toolpack:Status_Menus:SCTP A|SCTP]]
*[[Toolpack:Status_Menus:SS7_MTP2 A|SS7 MTP2]]
*[[Toolpack:Status_Menus:SS7_M2UA A|SS7 M2UA]]
*[[Toolpack:Status_Menus:SS7_IUA A|SS7 IUA]]
*[[Toolpack:Status_Menus:SS7_M2PA A|SS7 M2PA]]
*[[Toolpack:Status_Menus:SS7_M3UA A|SS7 M3UA]]
*[[Toolpack:Status_Menus:SS7_MTP3 A|SS7 MTP3]]
*[[Toolpack:Status_Menus:SS7_ISUP A|SS7 ISUP]]
*[[Toolpack:Status_Menus:SS7_SCCP A|SS7 SCCP]]
*[[Toolpack:Status_Menus:SS7_TCAP A|SS7 TCAP]]
*[[Toolpack:Status_Menus:ISDN A|ISDN]]
**[[Toolpack:Status_Menus:NFAS A|NFAS]]
*[[Toolpack:Status_Menus:CAS R2 A|CAS R2]]
*[[Toolpack:Status_Menus:SIP A|SIP]]
*[[Toolpack:Status_Menus:Clock B|Clock]]
**[[Toolpack:Status_Menus:Clock Status List A|Clock Status List]]
*[[Toolpack:Status_Menus:TMS A|TMS]]
*[[Toolpack:Status_Menus:NAP A|NAP]]
**[[Toolpack:Status_Menus:NAP Status List A|NAP Status List]]
*[[Toolpack:Status_Menus:H.248 A|H.248]]
*[[Toolpack:Status_Menus:RADIUS A|RADIUS]]

|}

[[category:Toolpack]]
[[category:Coming Soon]]

CAS

2013-08-06T18:51:07Z

Clod Patry: added R1

Channel Associated Signaling is a signaling protocol for the set-up and tear-down of phone calls. It is different from other signaling protocols such as [[SS7]] in that it is not message/packet-based but rather based on bit transition for state changing, and tone transmission for information and state information exchange. In many parts of the world, CAS was first replaced by [[ISDN]] and in many cases, was ultimately replaced by SS7. Today, CAS is often used with low density trunks.

 

== CAS and TelcoBridges ==

CAS signaling is supported at the basic API level but is not supported at the [[Toolpack]] / [[Web Portal]] level and is thus not accessible for more basic applications (i.e., that don`t require programming code). As of June 2010, support for CAS R2 has been announced within the [[Web Portal Tutorial Guide v2.5|Toolpack Web Portal v2.5]]; this is slated to ship during the 3rd quarter of 2010. Please note that CAS R2 support is limited to E1 interfaces. It is not compatible with DS-3 or STM-1 interfaces.

 

=== CAS ===

=== CAS R1 ===
As of July 2013, support for CAS R1 has been announced within the [[Web Portal Tutorial Guide v2.7|Toolpack Web Portal v2.7]]; this is slated to ship during the 3rd quarter of 2013. Please note that CAS R1 support is not limited to E1 interfaces.

==== Supported CAS R1 variants ====
The following CAS variants are currently supported by the Toolpack:

*Wink start (immediate, 1 wink or 2 winks)
*FXS Loop start

Please contact TelcoBridges regarding support for additional CAS variants.

=== CAS R2 ===

The TelcoBridges CAS R2 stack features a scriptable register signaling engine that, in practice, allows the complete customization of communication processes using tones. More specifically, it is possible to modify the timing(s) of the tone exchanges, change the meaning(s) of each tone and dynamically specify the sequence in which the tones are played. The CAS R2 stack also provides integrated interoperability between variants and between other signaling types. For instance, the calling party category can be converted between variants and propagated to a SS7 call leg.

==== Supported CAS R2 variants ====
The following CAS variants are currently supported by the Toolpack:

*Generic (ITU spec base)
*Brazil
*Mexico

Using Toolpack's script-based approach to the management of regional variants, variants supplied Toolpack can be adapted to address specific requirements and new variant scripts can be created from scratch, without to need to 'patch' or update the underlying system software version.

== References ==

*[[CAS R2 scripting|CAS R2 Scripting guide]]
*[[Toolpack CAS R2 troubleshooting|CAS R2 Troubleshooting guide]]
*[http://en.wikipedia.org/wiki/Channel_Associated_Signaling Wikipedia article]
*[http://www.itu.int/rec/T-REC-Q.400-Q.490-198811-I ITU Q.400-Q.490 Specification]

[[Category:Glossary]]
[[Category:Needs_revising]]
[[Category:Revise on Major]]

CASr1 scripting

2013-07-31T19:52:07Z

Clod Patry: remove E&M specific part.

This page explains how to configure a generic CASr1 script.

== Summary ==
This script will be identified as a CASR1 script when the following
variable is set:
<pre>
SCRIPT_TYPE="CASR1"
</pre>
The CASR1 script allows implementation of all variants of CASR1 stacks
by controlling what actions must take place following received events.

== Overview ==
The script will received an indication for each timeslot it has to
"control" through function HandleNewTimeslot.
The script will then be notified of any event on that timeslot
(CAS bits changes and others).
To each received event, the script will take one ore more action.

It's up to the script implementation to define it's own states
for handling the calls. The script is thus very flexible in the way
it implements the CASR1 variant call flow.

The current document does not describe how CASR1 call flows are
implemented (what are CAS bits, when and why to they "change",
how calling/called numbers are exchanged, what is the call flow etc.)
The reader shall find that information in the specifications for
CASR1 variants. This script should provide all tools required to
actually implement CASR1 variants.

== Configurable global script constants==
The script can define some constants required by the stack (though
default values are provided if the script does not define these
constants.
<pre>
SCRIPT_TYPE = "CASR1"
</pre>
Defines the type of this sript. Must be CASR1 in current case.

<pre>
ABCD_PATTERN_MATCH_MASK = 0x1111
</pre>
Mask to apply to CAS bits detected from remote equipment.
A bit which mask is set to 0 will be ignored and always reported as
zero (0) to this script.
This is useful in some cases when unused bits have undefined
(and even sometimes toggeling!) values.

<pre>
TONE_USE_DTMF = 1
</pre>
Indicates the type of tones must be used to send/receive AND/DNIS.
Value of 1 stands for DTMF. Value of 0 defaults to MFR1.
DTMF mapping:
<pre>

'0' -> DTMF Digit 0: 941Hz + 1336Hz
'1' -> DTMF Digit 1: 697Hz + 1209Hz
'2' -> DTMF Digit 2: 697Hz + 1336Hz
'3' -> DTMF Digit 3: 697Hz + 1477Hz
'4' -> DTMF Digit 4: 770Hz + 1209Hz
'5' -> DTMF Digit 5: 770Hz + 1336Hz
'6' -> DTMF Digit 6: 770Hz + 1477Hz
'7' -> DTMF Digit 7: 852Hz + 1209Hz
'8' -> DTMF Digit 8: 852Hz + 1336Hz
'9' -> DTMF Digit 9: 852Hz + 1477Hz
'*' -> DTMF Digit Star (*): 941Hz + 1209Hz
'#' -> DTMF Digit Pound (#): 941Hz + 1477Hz
'A' -> DTMF Digit A: 697Hz + 1633Hz
'B' -> DTMF Digit B: 770Hz + 1633Hz
'C' -> DTMF Digit C: 852Hz + 1633Hz
'D' -> DTMF Digit D: 941Hz + 1633Hz
Alternative values for * and #:
'E' -> DTMF Digit Star (*): 941Hz + 1209Hz
'F' -> DTMF Digit Pound (#): 941Hz + 1477Hz
</pre>
MFR1 mapping:
<pre>
'0' -> MFR1 Digit 0: 1300Hz + 1500Hz
'1' -> MFR1 Digit 1: 700Hz + 900Hz
'2' -> MFR1 Digit 2: 700Hz + 1100Hz
'3' -> MFR1 Digit 3: 900Hz + 1100Hz
'4' -> MFR1 Digit 4: 700Hz + 1300Hz
'5' -> MFR1 Digit 5: 900Hz + 1300Hz
'6' -> MFR1 Digit 6: 1100Hz + 1300Hz
'7' -> MFR1 Digit 7: 700Hz + 1500Hz
'8' -> MFR1 Digit 8: 900Hz + 1500Hz
'9' -> MFR1 Digit 9: 1100Hz + 1500Hz
'*' -> MFR1 KP (Start of pulsing): 1100Hz + 1700Hz
'#' -> MFR1 ST (End of pulsing): 1500Hz + 1700Hz
'A' -> MFR1 STI: 900Hz + 1700Hz
'B' -> MFR1 STII: 1300Hz + 1700Hz
'C' -> MFR1 STIII: 700Hz + 1700Hz
'D' -> Not supported in MFR1
</pre>
Alternative characters:
<pre>
'E' -> MFR1 KP (Start of pulsing): 1100Hz + 1700Hz
'F' -> MFR1 ST (End of pulsing): 1500Hz + 1700Hz
</pre>

<pre>
TONE_ON_TIME = 60
</pre>
Determines the "on time" (in ms) of tones used when sending ANI/DNIS.

<pre>
TONE_OFF_TIME = 50
</pre>
Determines the "off time" (inter-digit delay)(in ms) of tones used
when sending ANI/DNIS.

<pre>
TONE_LEVEL = -10
</pre>
Determines the level (in DB) of tones used when sending ANI/DNIS.

== Static constants pushed by the stack, for usage in this script==
Available actions for "StackAction" function:
Commonly used actions:
<pre>
ACTION_END_SIGNALING
ACTION_SET_CAS_BITS
ACTION_SEND_WINK
ACTION_WAIT_WINK
ACTION_SEND_ANI
ACTION_SEND_DNIS
ACTION_WAIT_ANI
ACTION_WAIT_DNIS
ACTION_REPORT_SEIZURE
ACTION_REPORT_VALIDATE_CALL
ACTION_REPORT_ACCEPTED
ACTION_REPORT_ALERTED
ACTION_REPORT_ANSWERED
ACTION_REPORT_BLOCKED
ACTION_REPORT_UNBLOCKED
ACTION_START_TIMER
ACTION_CANCEL_TIMER
</pre>
Additional actions to implement special variants
<pre>
ACTION_SEND_TONE
ACTION_SET_ANI
ACTION_SET_DNIS
</pre>

Events received by this script on "HandleEvents" function:
Commonly used events:
<pre>
EVENT_CAS_BITS_CHANGED
EVENT_WINK_DETECTED
EVENT_WINK_COMPLETED
EVENT_ANI_RECEIVED
EVENT_DNIS_RECEIVED
EVENT_ANI_SENT
EVENT_DNIS_SENT
EVENT_APP_FWD_MAKE_CALL
EVENT_APP_BWD_MUST_ALERT
EVENT_APP_BWD_MUST_ANSWER
EVENT_APP_END_SIGNALING
EVENT_APP_BLOCK_TIMESLOT
EVENT_APP_UNBLOCK_TIMESLOT
EVENT_TIMEOUT
</pre>

Additional events to implement special variants
<pre>
EVENT_TONE_RECEIVED
EVENT_TONE_SENT
</pre>

Result code that HandleNewTimeslot or HandleEvent funtions must return:
<pre>
RESULT_OK
RESULT_FAIL
RESULT_MISMATCH
RESULT_OUT_OF_RESOURCE
RESULT_INVALID_PARAM
RESULT_INVALID_STATE
RESULT_NOT_SUPPORTED
RESULT_TRUNK_RES_NOT_IDLE
RESULT_BLOCKED_LOCALLY
RESULT_BLOCKED_REMOTELY
</pre>

Call release causes to use with ACTION_END_SIGNALING
<pre>
CAUSE_FWD_SEIZURE_COLLISION
CAUSE_FWD_SEIZURE_ACK_TIMEOUT
CAUSE_FWD_TONE_TIMEOUT
CAUSE_FWD_ANSWER_TIMEOUT
CAUSE_FWD_CALL_REFUSED
CAUSE_FWD_REJECT_CALL
CAUSE_FWD_HANG_UP
CAUSE_BWD_TONE_TIMEOUT
CAUSE_BWD_REJECT_CALL
CAUSE_BWD_CALL_REFUSED
CAUSE_BWD_ALERT_TIMEOUT
CAUSE_BWD_ANSWER_TIMEOUT
CAUSE_BWD_HANG_UP
</pre>

Trace levels (used with function StackLogTrace).
Least verbose is TRACE_LEVEL_0 (almost never printed).
Most verbose is TRACE_LEVEL_4 (generally printed)
<pre>
TRACE_LEVEL_0
TRACE_LEVEL_1
TRACE_LEVEL_2
TRACE_LEVEL_3
TRACE_LEVEL_4
TRACE_LEVEL_ALWAYS
TRACE_LEVEL_ERROR
</pre>

== Mandatory functions to implement in this script ==

The script must provide the following mandatory functions, that will
be called by the CAS stack at appropriate moments.

=== HandleNewTimeslot( in_TimeslotCtx, in_InitialCasBits )===
This function is called to prepare a new timeslot so it's ready to
be used to receive events and eventually handle a CASR1 call.
When this function is called, the timeslot must be set to "off-hook"
state. The stack will later send EVENT_APP_UNBLOCK_TIMESLOT when
it's time to go "on-hook" and be ready to make calls.

Parameters:

'''in_TimeslotCtx''' :

Context containing variables for this timeslot.
This context is a LUA table.
This table already contains two values:
["TrunkNumber"] and ["TimeslotNumber"]
The script can create it's own variables here (like the
"call state"), which will be accessible for any event on
this timeslot.

'''in_InitialCasBits''' :

The initial states of CAS bits received from remote equipment
(integer like 0x1111)

=== HandleEvent( in_TimeslotCtx, in_EventType, ... ) ===
This function reports that an event occurred on a timeslot

Parameters :

'''in_TimeslotCtx''' :

Timeslot context used by the script to store any timeslot-
related information, like the "call state".
This is the table that was passed to HandleNewTimeslot.

'''in_EventType''' :

The type of the event that was just received
(see constants EVENT_* documented below)

'''...''' :

Variable number of parameters, that depend on event type.
Available event types and their parameters:
<pre>
EVENT_CAS_BITS_CHANGED
</pre>
Parameter:

- Received CAS bits (integer like 0x1111)
Indicates that CAS bits values received by
remote equipment have changed.
<pre>
EVENT_WINK_DETECTED
</pre>
No specific parameter.

Indicates that a "Wink" has been detected.
This event can only follow ACTION_WAIT_WINK.
<pre>
EVENT_WINK_COMPLETED
</pre>
No specific parameter.

Indicates that a "Wink" has been sent successfully.
This event can only follow ACTION_SEND_WINK.
<pre>
EVENT_TONE_RECEIVED
</pre>
Parameter:

- String that represents the received tone (digit)
(see "Digit format" below)
Indicates that a tone was detected.
Not normally used in CASR1 standard variants.

'''Note''': This does not include tones that are
collected as part of ACTION_WAIT_ANI or
ACTION_WAIT_DNIS, which are coalesced and
reported as separate events.
<pre>
EVENT_ANI_RECEIVED
</pre>
No specific parameter.

Indicates that ANI (calling number) has been
sent received (prefix/suffix detected).
This event can only follow ACTION_WAIT_ANI.
Note: The received ANI/DNIS digits are not passed
to the script. The script does not have
to know them. But the stack keeps them
and they will be reported to the
application upon ACTION_REPORT_VALIDATE_CALL
<pre>
EVENT_DNIS_RECEIVED
</pre>
Same as EVENT_ANI_RECEIVED, but for DNIS
(called number)
<pre>
EVENT_TONE_SENT
</pre>
No specific parameter.

Indicates that a tone (digit) as been sent
successfully following ACTION_SEND_TONE.
Not normally used in CASR1 standard variants.
<pre>
EVENT_ANI_SENT
</pre>
No specific parameter.

Indicates that ANI (calling number) has been
sent successfully (all tones played).
This event can only follow ACTION_SEND_ANI.
<pre>
EVENT_DNIS_SENT
</pre>
Same as EVENT_ANI_SENT, but for DNIS
(called number)
<pre>
EVENT_APP_FWD_MAKE_CALL
</pre>
No specific parameter.

Indicate that a new "forward" call must be made.
The script shall take appropraite actions to
initiate a new call (most likely change the
CAS bits to the "off hook" state).
<pre>
EVENT_APP_BWD_MUST_ALERT
</pre>
No specific parameter.

Indicates that this "backward" call must now
be set to "alerted" state (meaning we have accepted
the call, and received required information to
proceed). The decision of when to alert the call
is made by the application, and at that moment
the script receives this event so it can take
appropriate actions to alert a "backward" call.
(in most variants, there is nothing to do, on
some variants, a "Wink" may be sent).
<pre>
EVENT_APP_BWD_MUST_ANSWER
</pre>
No specific parameter.

Indicates that this "backward" call must now
be set to "answered" state. The decision of when
set the call "answered" is made by the application,
and at that moment the script receives this event
so it can take appropriate actions to answer.
(in most variants, CAS bits must be set to
an "answered" pattern).
<pre>
EVENT_APP_END_SIGNALING
</pre>
No specific parameter.

Indicates either that:
- Application requests to terminate the call.
The script then take appropriate action, like
sedding CAS bits to "idle" state, wait for
remote equipment to acknowledge, then at the
end use ACTION_END_SIGNALING to confirm that
termination is completed.
- Script previously called ACTION_END_SIGNALING,
(after remote equipment set CAS bits to "idle"
or after an error in the script), in which
case this event confirms that the application
is also ready to terminate the call.
<pre>
EVENT_APP_BLOCK_TIMESLOT
</pre>
No specific parameter.

Indicates that the timeslot must be locally
blocked, the next time it becomes "idle".
It's blocked by going "off-hook" and remaining
in that state no matter remote state.
This is also the default state for a newly
created timeslot.
This state can only be canceled by
EVENT_APP_UNBLOCK_TIMESLOT
<pre>
EVENT_APP_UNBLOCK_TIMESLOT
</pre>
No specific parameter.

Cancels a previous EVENT_APP_BLOCK_TIMESLOT.
This causes our CAS bits to be set to "on hook".
<pre>
EVENT_TIMEOUT
</pre>
No specific parameter.

Indicates that the timer previously started with
ACTION_START_TIMER has expired.
Returns :
RESULT_OK, or one of the return codes defined above.
This result code tells to the stack if the event was properly
handled by the script. Upon non-OK code, the stack may decide
to terminate the call.

== Stack functions that can be called by this script ==

=== StackActionToString( in_Action ) ===
Returns string value of an action type.

Example:
local action = ACTION_END_SIGNALING
StackActionToString( action )
will return the string "ACTION_END_SIGNALING".

=== StackEventToString( in_Event ) ===
Returns string value of an event type.

Example:
StackEventToString( in_Event )
will return the string "EVENT_TIMEOUT".

=== StackCauseToString( in_Cause ) ===
Returns string value of a release cause.

Example:
my_release_cause = CAUSE_FWD_SEIZURE_COLLISION
StackCauseToString( my_release_cause )
will return the string "CAUSE_FWD_SEIZURE_COLLISION".

=== StackLogTrace( in_TraceLevel, in_Format, ... ) ===
Asks the stack to print a trace (generally debug traces).

Traces will be sent to the "tblogtrace" application.

Parameters:

'''in_TraceLevel''':

Level of the trace (see TRACE_LEVEL_* above)

'''in_Format''':

String that contains the trace to print, plus refernences
to other arguments ("printf" style format)

..'''.''':

Values for printf-style refernces of in_Format.
Example:
local cas_bits = 0x1100
StackLogTrace( TRACE_LEVEL_2, "Send CAS bits %08X", cas_bits )
will print "Send CAS bits 1100" to tblogtrace log.

=== StackAction( in_Action, ... ) ===
This function executes the specified action (in some cases with
the specified action-specific arguments).
The action is done asynchronously, meaning that control will
immediately return to the script. Events will be received later
according to the actions taken.
Upon an event, the script may perform multiple actions (like
starting a timer, declarign the call "alerted" and sending
CAS bits for example)

Parameters :

'''in_Action''' :
The action to perform.
(see constants ACTION_* documented below)

'''...''' :
Variable number of action-specific arguments.
<pre>
ACTION_END_SIGNALING
</pre>
Parameter:

- The call release cause to report.
See values "CAUSE_".
Indicates either that:

- Application previously requested to terminate
the call (with EVENT_APP_END_SIGNALING), in
which case this action is used by the script
to indicate that signaling is fully idle (local
CAS bits set to "idle", remote equipment
has acknowledged too with "idle" CAS bits).

- Script wants to terminate the call
(after remote equipment set CAS bits to "idle"
or after an error in the script). After
sending ACTION_END_SIGNALING, the script must
wait until EVENT_APP_END_SIGNALING is
received, which confirms that application is
ready to terminate the cally. Only at that
moment the script shall set it's CAS bits
to "idle" value.
<pre>
ACTION_SET_CAS_BITS
</pre>
Parameter:

- CAS bits to set (integer like 0x1111)
Used to change the CAS bits that we are
sending on current timeslot towawrd remote
equipment.
<pre>
ACTION_SEND_WINK
</pre>
Parameters:

- CAS bits to set during the "Wink"
(integer like 0x1111)
- Duration of the "Wink" (in milliseconds)
Used to send a "Wink", which is temporary change of
the CAS bits for few milliseconds, then back to
initial CAS bits value.
EVENT_WINK_COMPLETED will be received by
the script once Wink has completed (CAS bits are
back to their initial value)
<pre>
ACTION_WAIT_WINK
</pre>
Parameters:

- Expected CAS bits during the "Wink"
(integer like 0x1111)
- Minimum duration of the "Wink" (in ms)
- Maximum duration of the "Wink" (in ms)
Used to request a "Wink" detection.
Upon next CAS bits change from remote equipment,
the stack will see if the bits match the Wink
expected bits.
EVENT_WINK_DETECTED will be reported
if CAS bits received from remote equipment change
to the expected pattern for a duration within
specified range, then go back to original value.
Any other CAS bits change not deteced as a "Wink"
will be reported to the script by
EVENT_CAS_BITS_CHANGED (which will probably want
to drop the call because a Wink was expected)
<pre>
ACTION_SEND_TONE
</pre>
Parameters:

- Digit (tone) to send.
(see "Digit format" below)
Used to send one digit (tone) toward remote
equipment. EVENT_TONE_SENT will be received
once the tone has been successfully sent.
Not normally used in CASR1 standard variants.
Note: This action is not used to send ANI/DNIS
(calling/called numbers), it's used to
send other tones that may be used within
the current CASR1 variant call flow.
<pre>
ACTION_SEND_ANI
</pre>
Parameters:

- Prefix to send before ANI. Can be empty.
- Suffix to send after ANI. Can be empty.
(see "Digit format" below)
Used to send ANI (calling number) toward
remote equipment, using tones.
A prefix may be inserted before ANI.
A suffix is mandatory. It's transmitted after ANI.
Remote equipment expects that suffix to determine
that the ANI has been entirely sent.
EVENT_ANI_SENT will be received once
transmission of prefix + ANI + suffix completed
<pre>
ACTION_SEND_DNIS
</pre>
Same as ACTION_SEND_ANI, but for sending DNIS
(called number)
<pre>
ACTION_WAIT_ANI
</pre>
Parameters:

- Prefix to expect before ANI. Can be empty.
- Suffix to expect after ANI. Can be empty only
if next argument (nb expected digits) is set.
(see "Digit format" below)
- Number of expected digits.
Optional. Only required if suffix is empty.
Used to wait for ANI (calling number) from
remote equipment, by detecting tones.
A prefix may be expected before ANI.
A suffix is mandatory. It's received after ANI to
indicate that the ANI has been entirely transmitted.
EVENT_ANI_RECEIVED will be received if a
matching prefix + suffix are detected.
<pre>
ACTION_WAIT_DNIS
</pre>
Same as ACTION_WAIT_ANI, but for receiving DNIS
(called number)
<pre>
ACTION_SET_ANI
</pre>
Parameters:

- ANI to set
Used to replace the ANI detected by the stack with
this ANI provided by the script.
This action must be calld before action
TBX_CASR2VMLIB_CASR1_ACTION_REPORT_VALIDATE_CALL
(otherwise it's too late to set ANI)
Not normally used in CASR1 standard variants.
<pre>
ACTION_SET_DNIS
</pre>
Same as ACTION_SET_ANI, but for DNIS (called number)
<pre>
ACTION_REPORT_SEIZURE
</pre>
No parameter.

Tell the application that seizure (off-hook) has
been deteced on a timeslot.
<pre>
ACTION_REPORT_VALIDATE_CALL
</pre>
No parameter.

Tell the application that ANI and/or DNIS have
been successfully received, and we now have the
information required to process this incoming call.
<pre>
ACTION_REPORT_ACCEPTED
</pre>
No parameter.

Tell the application that a "forward" call has
been accepted by remote equipment, often by
detecting a "Wink".
<pre>
ACTION_REPORT_ALERTED
</pre>
No parameter.

Tell the application that a "forward" call has
been alerted by remote equipment.
On most variants, there is no specific indication
from remote side, and this action must be taken
upon EVENT_DNIS_SENT.
On other variants, a "Wink" may be awaited before
calling this action.
<pre>
ACTION_REPORT_ANSWERED
</pre>
No parameter.

Tell the application that a "forward" call has
been answered by remote equipment, generally
because "off-hook" CAS bits have been received.
<pre>
ACTION_REPORT_BLOCKED
</pre>
No parameter.

Tells the application that the script considers
the timeslot as "remotely blocked". This is the
case when remote side goes "off hook" and remains
in that state for some duration after we've
returned to "on hook" on our side.
<pre>
ACTION_REPORT_UNBLOCKED
</pre>
No parameter.

Tells the application that the timeslot is no
more "remotely blocked", because remote
equipment went "on hook" after we reported
ACTION_REPORT_BLOCKED.
<pre>
ACTION_START_TIMER
</pre>
Parameter:

- Timer duration in milliseconds.
Starts a timer. EVENT_TIMEOUT will be
posted if the timer expires before
ACTION_CANCEL_TIMER is called.
<pre>
ACTION_CANCEL_TIMER
</pre>
No parameter.
Cancels a timer previously started with
ACTION_START_TIMER.

Digit format:

The digit format (for sending tone or ANI/DNIS prefix/suffix)
is represented by a string that contains up to 3 of the
following characters: 0123456789ABCD*#

CAS R1 E&M

2013-07-31T19:45:02Z

Clod Patry: basic page for E&M

E&M is a CASr1 family.
This script is used to configure the following variants:
* Immediate delay
* Wink-start
* Double-ack
* EANA

== Overview ==
E&M scripts use the same logic specified in [[CASr1 scripting]].

== Configuration ==
To specify a script to use E&M, you MUST specify one of the following:
<pre>
CasR1.Variant = CasR1.VariantTypes.DELAY_START
CasR1.Variant = CasR1.VariantTypes.WINK_START
CasR1.Variant = CasR1.VariantTypes.WINK_START_ACK
CasR1.Variant = CasR1.VariantTypes.EANA
</pre>

Depending if you want to use 0, 1 or 2 winks and if you plan to receive or not the ANI.

== Subvariants ==
Here are the differences between the subvariants:

=== Delay Start ===
there's no wink before receiving ANI/DNIS.

=== Wink Start ===
There's 1 wink before receiving ANI/DNIS.

=== Wink Start ACK ===
There's 1 wink before receiving ANI/DNIS.
There's 1 wink after receiving ANI/DNIS.

=== EANA ===
This variant is similar to wink start, but it contains ANI, while wink-start has no ANI.

== ANI ==

This is the Automic Number Identification, commonly called the "calling number".

<pre>
ANI = {
prefix = "*",
suffix = "*",
expected_digits = 0,
inter_digit_timeout = 0,
}
</pre>

== DNIS ==

This is the Dialed Number Identification Service, commonly called the "called number".
<pre>
DNIS = {
prefix = "*",
suffix = "#",
expected_digits = 0,
inter_digit_timeout = 0,
}
</pre>

By using the 2 above sections, you're expecting to receive:
<pre>
*ANI*DNIS#
</pre>
when you're in the incoming addressing state.

CAS R1 E&M

2013-07-31T19:11:36Z

Clod Patry: moved E&M to CASr1 scripting: this page is what's needed for all CASr1 script, not specific to E&M.

#REDIRECT [[CASr1 scripting]]

CASr1 scripting

2013-07-31T19:11:36Z

Clod Patry: moved E&M to CASr1 scripting: this page is what's needed for all CASr1 script, not specific to E&M.

E&M is a CASr1 family.
This script is used to configure the following variants:
* Immediate delay
* Wink-start
* Double-ack

== Summary ==
This script will be identified as a CASR1 script when the following
variable is set:
<pre>
SCRIPT_TYPE="CASR1"
</pre>
The CASR1 script allows implementation of all variants of CASR1 stacks
by controlling what actions must take place following received events.

== Overview ==
The script will received an indication for each timeslot it has to
"control" through function HandleNewTimeslot.
The script will then be notified of any event on that timeslot
(CAS bits changes and others).
To each received event, the script will take one ore more action.

It's up to the script implementation to define it's own states
for handling the calls. The script is thus very flexible in the way
it implements the CASR1 variant call flow.

The current document does not describe how CASR1 call flows are
implemented (what are CAS bits, when and why to they "change",
how calling/called numbers are exchanged, what is the call flow etc.)
The reader shall find that information in the specifications for
CASR1 variants. This script should provide all tools required to
actually implement CASR1 variants.

== Configurable global script constants==
The script can define some constants required by the stack (though
default values are provided if the script does not define these
constants.
<pre>
SCRIPT_TYPE = "CASR1"
</pre>
Defines the type of this sript. Must be CASR1 in current case.

<pre>
ABCD_PATTERN_MATCH_MASK = 0x1111
</pre>
Mask to apply to CAS bits detected from remote equipment.
A bit which mask is set to 0 will be ignored and always reported as
zero (0) to this script.
This is useful in some cases when unused bits have undefined
(and even sometimes toggeling!) values.

<pre>
TONE_USE_DTMF = 1
</pre>
Indicates the type of tones must be used to send/receive AND/DNIS.
Value of 1 stands for DTMF. Value of 0 defaults to MFR1.
DTMF mapping:
<pre>

'0' -> DTMF Digit 0: 941Hz + 1336Hz
'1' -> DTMF Digit 1: 697Hz + 1209Hz
'2' -> DTMF Digit 2: 697Hz + 1336Hz
'3' -> DTMF Digit 3: 697Hz + 1477Hz
'4' -> DTMF Digit 4: 770Hz + 1209Hz
'5' -> DTMF Digit 5: 770Hz + 1336Hz
'6' -> DTMF Digit 6: 770Hz + 1477Hz
'7' -> DTMF Digit 7: 852Hz + 1209Hz
'8' -> DTMF Digit 8: 852Hz + 1336Hz
'9' -> DTMF Digit 9: 852Hz + 1477Hz
'*' -> DTMF Digit Star (*): 941Hz + 1209Hz
'#' -> DTMF Digit Pound (#): 941Hz + 1477Hz
'A' -> DTMF Digit A: 697Hz + 1633Hz
'B' -> DTMF Digit B: 770Hz + 1633Hz
'C' -> DTMF Digit C: 852Hz + 1633Hz
'D' -> DTMF Digit D: 941Hz + 1633Hz
Alternative values for * and #:
'E' -> DTMF Digit Star (*): 941Hz + 1209Hz
'F' -> DTMF Digit Pound (#): 941Hz + 1477Hz
</pre>
MFR1 mapping:
<pre>
'0' -> MFR1 Digit 0: 1300Hz + 1500Hz
'1' -> MFR1 Digit 1: 700Hz + 900Hz
'2' -> MFR1 Digit 2: 700Hz + 1100Hz
'3' -> MFR1 Digit 3: 900Hz + 1100Hz
'4' -> MFR1 Digit 4: 700Hz + 1300Hz
'5' -> MFR1 Digit 5: 900Hz + 1300Hz
'6' -> MFR1 Digit 6: 1100Hz + 1300Hz
'7' -> MFR1 Digit 7: 700Hz + 1500Hz
'8' -> MFR1 Digit 8: 900Hz + 1500Hz
'9' -> MFR1 Digit 9: 1100Hz + 1500Hz
'*' -> MFR1 KP (Start of pulsing): 1100Hz + 1700Hz
'#' -> MFR1 ST (End of pulsing): 1500Hz + 1700Hz
'A' -> MFR1 STI: 900Hz + 1700Hz
'B' -> MFR1 STII: 1300Hz + 1700Hz
'C' -> MFR1 STIII: 700Hz + 1700Hz
'D' -> Not supported in MFR1
</pre>
Alternative characters:
<pre>
'E' -> MFR1 KP (Start of pulsing): 1100Hz + 1700Hz
'F' -> MFR1 ST (End of pulsing): 1500Hz + 1700Hz
</pre>

<pre>
TONE_ON_TIME = 60
</pre>
Determines the "on time" (in ms) of tones used when sending ANI/DNIS.

<pre>
TONE_OFF_TIME = 50
</pre>
Determines the "off time" (inter-digit delay)(in ms) of tones used
when sending ANI/DNIS.

<pre>
TONE_LEVEL = -10
</pre>
Determines the level (in DB) of tones used when sending ANI/DNIS.

== Static constants pushed by the stack, for usage in this script==
Available actions for "StackAction" function:
Commonly used actions:
<pre>
ACTION_END_SIGNALING
ACTION_SET_CAS_BITS
ACTION_SEND_WINK
ACTION_WAIT_WINK
ACTION_SEND_ANI
ACTION_SEND_DNIS
ACTION_WAIT_ANI
ACTION_WAIT_DNIS
ACTION_REPORT_SEIZURE
ACTION_REPORT_VALIDATE_CALL
ACTION_REPORT_ACCEPTED
ACTION_REPORT_ALERTED
ACTION_REPORT_ANSWERED
ACTION_REPORT_BLOCKED
ACTION_REPORT_UNBLOCKED
ACTION_START_TIMER
ACTION_CANCEL_TIMER
</pre>
Additional actions to implement special variants
<pre>
ACTION_SEND_TONE
ACTION_SET_ANI
ACTION_SET_DNIS
</pre>

Events received by this script on "HandleEvents" function:
Commonly used events:
<pre>
EVENT_CAS_BITS_CHANGED
EVENT_WINK_DETECTED
EVENT_WINK_COMPLETED
EVENT_ANI_RECEIVED
EVENT_DNIS_RECEIVED
EVENT_ANI_SENT
EVENT_DNIS_SENT
EVENT_APP_FWD_MAKE_CALL
EVENT_APP_BWD_MUST_ALERT
EVENT_APP_BWD_MUST_ANSWER
EVENT_APP_END_SIGNALING
EVENT_APP_BLOCK_TIMESLOT
EVENT_APP_UNBLOCK_TIMESLOT
EVENT_TIMEOUT
</pre>

Additional events to implement special variants
<pre>
EVENT_TONE_RECEIVED
EVENT_TONE_SENT
</pre>

Result code that HandleNewTimeslot or HandleEvent funtions must return:
<pre>
RESULT_OK
RESULT_FAIL
RESULT_MISMATCH
RESULT_OUT_OF_RESOURCE
RESULT_INVALID_PARAM
RESULT_INVALID_STATE
RESULT_NOT_SUPPORTED
RESULT_TRUNK_RES_NOT_IDLE
RESULT_BLOCKED_LOCALLY
RESULT_BLOCKED_REMOTELY
</pre>

Call release causes to use with ACTION_END_SIGNALING
<pre>
CAUSE_FWD_SEIZURE_COLLISION
CAUSE_FWD_SEIZURE_ACK_TIMEOUT
CAUSE_FWD_TONE_TIMEOUT
CAUSE_FWD_ANSWER_TIMEOUT
CAUSE_FWD_CALL_REFUSED
CAUSE_FWD_REJECT_CALL
CAUSE_FWD_HANG_UP
CAUSE_BWD_TONE_TIMEOUT
CAUSE_BWD_REJECT_CALL
CAUSE_BWD_CALL_REFUSED
CAUSE_BWD_ALERT_TIMEOUT
CAUSE_BWD_ANSWER_TIMEOUT
CAUSE_BWD_HANG_UP
</pre>

Trace levels (used with function StackLogTrace).
Least verbose is TRACE_LEVEL_0 (almost never printed).
Most verbose is TRACE_LEVEL_4 (generally printed)
<pre>
TRACE_LEVEL_0
TRACE_LEVEL_1
TRACE_LEVEL_2
TRACE_LEVEL_3
TRACE_LEVEL_4
TRACE_LEVEL_ALWAYS
TRACE_LEVEL_ERROR
</pre>

== Mandatory functions to implement in this script ==

The script must provide the following mandatory functions, that will
be called by the CAS stack at appropriate moments.

=== HandleNewTimeslot( in_TimeslotCtx, in_InitialCasBits )===
This function is called to prepare a new timeslot so it's ready to
be used to receive events and eventually handle a CASR1 call.
When this function is called, the timeslot must be set to "off-hook"
state. The stack will later send EVENT_APP_UNBLOCK_TIMESLOT when
it's time to go "on-hook" and be ready to make calls.

Parameters:

'''in_TimeslotCtx''' :

Context containing variables for this timeslot.
This context is a LUA table.
This table already contains two values:
["TrunkNumber"] and ["TimeslotNumber"]
The script can create it's own variables here (like the
"call state"), which will be accessible for any event on
this timeslot.

'''in_InitialCasBits''' :

The initial states of CAS bits received from remote equipment
(integer like 0x1111)

=== HandleEvent( in_TimeslotCtx, in_EventType, ... ) ===
This function reports that an event occurred on a timeslot

Parameters :

'''in_TimeslotCtx''' :

Timeslot context used by the script to store any timeslot-
related information, like the "call state".
This is the table that was passed to HandleNewTimeslot.

'''in_EventType''' :

The type of the event that was just received
(see constants EVENT_* documented below)

'''...''' :

Variable number of parameters, that depend on event type.
Available event types and their parameters:
<pre>
EVENT_CAS_BITS_CHANGED
</pre>
Parameter:

- Received CAS bits (integer like 0x1111)
Indicates that CAS bits values received by
remote equipment have changed.
<pre>
EVENT_WINK_DETECTED
</pre>
No specific parameter.

Indicates that a "Wink" has been detected.
This event can only follow ACTION_WAIT_WINK.
<pre>
EVENT_WINK_COMPLETED
</pre>
No specific parameter.

Indicates that a "Wink" has been sent successfully.
This event can only follow ACTION_SEND_WINK.
<pre>
EVENT_TONE_RECEIVED
</pre>
Parameter:

- String that represents the received tone (digit)
(see "Digit format" below)
Indicates that a tone was detected.
Not normally used in CASR1 standard variants.

'''Note''': This does not include tones that are
collected as part of ACTION_WAIT_ANI or
ACTION_WAIT_DNIS, which are coalesced and
reported as separate events.
<pre>
EVENT_ANI_RECEIVED
</pre>
No specific parameter.

Indicates that ANI (calling number) has been
sent received (prefix/suffix detected).
This event can only follow ACTION_WAIT_ANI.
Note: The received ANI/DNIS digits are not passed
to the script. The script does not have
to know them. But the stack keeps them
and they will be reported to the
application upon ACTION_REPORT_VALIDATE_CALL
<pre>
EVENT_DNIS_RECEIVED
</pre>
Same as EVENT_ANI_RECEIVED, but for DNIS
(called number)
<pre>
EVENT_TONE_SENT
</pre>
No specific parameter.

Indicates that a tone (digit) as been sent
successfully following ACTION_SEND_TONE.
Not normally used in CASR1 standard variants.
<pre>
EVENT_ANI_SENT
</pre>
No specific parameter.

Indicates that ANI (calling number) has been
sent successfully (all tones played).
This event can only follow ACTION_SEND_ANI.
<pre>
EVENT_DNIS_SENT
</pre>
Same as EVENT_ANI_SENT, but for DNIS
(called number)
<pre>
EVENT_APP_FWD_MAKE_CALL
</pre>
No specific parameter.

Indicate that a new "forward" call must be made.
The script shall take appropraite actions to
initiate a new call (most likely change the
CAS bits to the "off hook" state).
<pre>
EVENT_APP_BWD_MUST_ALERT
</pre>
No specific parameter.

Indicates that this "backward" call must now
be set to "alerted" state (meaning we have accepted
the call, and received required information to
proceed). The decision of when to alert the call
is made by the application, and at that moment
the script receives this event so it can take
appropriate actions to alert a "backward" call.
(in most variants, there is nothing to do, on
some variants, a "Wink" may be sent).
<pre>
EVENT_APP_BWD_MUST_ANSWER
</pre>
No specific parameter.

Indicates that this "backward" call must now
be set to "answered" state. The decision of when
set the call "answered" is made by the application,
and at that moment the script receives this event
so it can take appropriate actions to answer.
(in most variants, CAS bits must be set to
an "answered" pattern).
<pre>
EVENT_APP_END_SIGNALING
</pre>
No specific parameter.

Indicates either that:
- Application requests to terminate the call.
The script then take appropriate action, like
sedding CAS bits to "idle" state, wait for
remote equipment to acknowledge, then at the
end use ACTION_END_SIGNALING to confirm that
termination is completed.
- Script previously called ACTION_END_SIGNALING,
(after remote equipment set CAS bits to "idle"
or after an error in the script), in which
case this event confirms that the application
is also ready to terminate the call.
<pre>
EVENT_APP_BLOCK_TIMESLOT
</pre>
No specific parameter.

Indicates that the timeslot must be locally
blocked, the next time it becomes "idle".
It's blocked by going "off-hook" and remaining
in that state no matter remote state.
This is also the default state for a newly
created timeslot.
This state can only be canceled by
EVENT_APP_UNBLOCK_TIMESLOT
<pre>
EVENT_APP_UNBLOCK_TIMESLOT
</pre>
No specific parameter.

Cancels a previous EVENT_APP_BLOCK_TIMESLOT.
This causes our CAS bits to be set to "on hook".
<pre>
EVENT_TIMEOUT
</pre>
No specific parameter.

Indicates that the timer previously started with
ACTION_START_TIMER has expired.
Returns :
RESULT_OK, or one of the return codes defined above.
This result code tells to the stack if the event was properly
handled by the script. Upon non-OK code, the stack may decide
to terminate the call.

== Stack functions that can be called by this script ==

=== StackActionToString( in_Action ) ===
Returns string value of an action type.

Example:
local action = ACTION_END_SIGNALING
StackActionToString( action )
will return the string "ACTION_END_SIGNALING".

=== StackEventToString( in_Event ) ===
Returns string value of an event type.

Example:
StackEventToString( in_Event )
will return the string "EVENT_TIMEOUT".

=== StackCauseToString( in_Cause ) ===
Returns string value of a release cause.

Example:
my_release_cause = CAUSE_FWD_SEIZURE_COLLISION
StackCauseToString( my_release_cause )
will return the string "CAUSE_FWD_SEIZURE_COLLISION".

=== StackLogTrace( in_TraceLevel, in_Format, ... ) ===
Asks the stack to print a trace (generally debug traces).

Traces will be sent to the "tblogtrace" application.

Parameters:

'''in_TraceLevel''':

Level of the trace (see TRACE_LEVEL_* above)

'''in_Format''':

String that contains the trace to print, plus refernences
to other arguments ("printf" style format)

..'''.''':

Values for printf-style refernces of in_Format.
Example:
local cas_bits = 0x1100
StackLogTrace( TRACE_LEVEL_2, "Send CAS bits %08X", cas_bits )
will print "Send CAS bits 1100" to tblogtrace log.

=== StackAction( in_Action, ... ) ===
This function executes the specified action (in some cases with
the specified action-specific arguments).
The action is done asynchronously, meaning that control will
immediately return to the script. Events will be received later
according to the actions taken.
Upon an event, the script may perform multiple actions (like
starting a timer, declarign the call "alerted" and sending
CAS bits for example)

Parameters :

'''in_Action''' :
The action to perform.
(see constants ACTION_* documented below)

'''...''' :
Variable number of action-specific arguments.
<pre>
ACTION_END_SIGNALING
</pre>
Parameter:

- The call release cause to report.
See values "CAUSE_".
Indicates either that:

- Application previously requested to terminate
the call (with EVENT_APP_END_SIGNALING), in
which case this action is used by the script
to indicate that signaling is fully idle (local
CAS bits set to "idle", remote equipment
has acknowledged too with "idle" CAS bits).

- Script wants to terminate the call
(after remote equipment set CAS bits to "idle"
or after an error in the script). After
sending ACTION_END_SIGNALING, the script must
wait until EVENT_APP_END_SIGNALING is
received, which confirms that application is
ready to terminate the cally. Only at that
moment the script shall set it's CAS bits
to "idle" value.
<pre>
ACTION_SET_CAS_BITS
</pre>
Parameter:

- CAS bits to set (integer like 0x1111)
Used to change the CAS bits that we are
sending on current timeslot towawrd remote
equipment.
<pre>
ACTION_SEND_WINK
</pre>
Parameters:

- CAS bits to set during the "Wink"
(integer like 0x1111)
- Duration of the "Wink" (in milliseconds)
Used to send a "Wink", which is temporary change of
the CAS bits for few milliseconds, then back to
initial CAS bits value.
EVENT_WINK_COMPLETED will be received by
the script once Wink has completed (CAS bits are
back to their initial value)
<pre>
ACTION_WAIT_WINK
</pre>
Parameters:

- Expected CAS bits during the "Wink"
(integer like 0x1111)
- Minimum duration of the "Wink" (in ms)
- Maximum duration of the "Wink" (in ms)
Used to request a "Wink" detection.
Upon next CAS bits change from remote equipment,
the stack will see if the bits match the Wink
expected bits.
EVENT_WINK_DETECTED will be reported
if CAS bits received from remote equipment change
to the expected pattern for a duration within
specified range, then go back to original value.
Any other CAS bits change not deteced as a "Wink"
will be reported to the script by
EVENT_CAS_BITS_CHANGED (which will probably want
to drop the call because a Wink was expected)
<pre>
ACTION_SEND_TONE
</pre>
Parameters:

- Digit (tone) to send.
(see "Digit format" below)
Used to send one digit (tone) toward remote
equipment. EVENT_TONE_SENT will be received
once the tone has been successfully sent.
Not normally used in CASR1 standard variants.
Note: This action is not used to send ANI/DNIS
(calling/called numbers), it's used to
send other tones that may be used within
the current CASR1 variant call flow.
<pre>
ACTION_SEND_ANI
</pre>
Parameters:

- Prefix to send before ANI. Can be empty.
- Suffix to send after ANI. Can be empty.
(see "Digit format" below)
Used to send ANI (calling number) toward
remote equipment, using tones.
A prefix may be inserted before ANI.
A suffix is mandatory. It's transmitted after ANI.
Remote equipment expects that suffix to determine
that the ANI has been entirely sent.
EVENT_ANI_SENT will be received once
transmission of prefix + ANI + suffix completed
<pre>
ACTION_SEND_DNIS
</pre>
Same as ACTION_SEND_ANI, but for sending DNIS
(called number)
<pre>
ACTION_WAIT_ANI
</pre>
Parameters:

- Prefix to expect before ANI. Can be empty.
- Suffix to expect after ANI. Can be empty only
if next argument (nb expected digits) is set.
(see "Digit format" below)
- Number of expected digits.
Optional. Only required if suffix is empty.
Used to wait for ANI (calling number) from
remote equipment, by detecting tones.
A prefix may be expected before ANI.
A suffix is mandatory. It's received after ANI to
indicate that the ANI has been entirely transmitted.
EVENT_ANI_RECEIVED will be received if a
matching prefix + suffix are detected.
<pre>
ACTION_WAIT_DNIS
</pre>
Same as ACTION_WAIT_ANI, but for receiving DNIS
(called number)
<pre>
ACTION_SET_ANI
</pre>
Parameters:

- ANI to set
Used to replace the ANI detected by the stack with
this ANI provided by the script.
This action must be calld before action
TBX_CASR2VMLIB_CASR1_ACTION_REPORT_VALIDATE_CALL
(otherwise it's too late to set ANI)
Not normally used in CASR1 standard variants.
<pre>
ACTION_SET_DNIS
</pre>
Same as ACTION_SET_ANI, but for DNIS (called number)
<pre>
ACTION_REPORT_SEIZURE
</pre>
No parameter.

Tell the application that seizure (off-hook) has
been deteced on a timeslot.
<pre>
ACTION_REPORT_VALIDATE_CALL
</pre>
No parameter.

Tell the application that ANI and/or DNIS have
been successfully received, and we now have the
information required to process this incoming call.
<pre>
ACTION_REPORT_ACCEPTED
</pre>
No parameter.

Tell the application that a "forward" call has
been accepted by remote equipment, often by
detecting a "Wink".
<pre>
ACTION_REPORT_ALERTED
</pre>
No parameter.

Tell the application that a "forward" call has
been alerted by remote equipment.
On most variants, there is no specific indication
from remote side, and this action must be taken
upon EVENT_DNIS_SENT.
On other variants, a "Wink" may be awaited before
calling this action.
<pre>
ACTION_REPORT_ANSWERED
</pre>
No parameter.

Tell the application that a "forward" call has
been answered by remote equipment, generally
because "off-hook" CAS bits have been received.
<pre>
ACTION_REPORT_BLOCKED
</pre>
No parameter.

Tells the application that the script considers
the timeslot as "remotely blocked". This is the
case when remote side goes "off hook" and remains
in that state for some duration after we've
returned to "on hook" on our side.
<pre>
ACTION_REPORT_UNBLOCKED
</pre>
No parameter.

Tells the application that the timeslot is no
more "remotely blocked", because remote
equipment went "on hook" after we reported
ACTION_REPORT_BLOCKED.
<pre>
ACTION_START_TIMER
</pre>
Parameter:

- Timer duration in milliseconds.
Starts a timer. EVENT_TIMEOUT will be
posted if the timer expires before
ACTION_CANCEL_TIMER is called.
<pre>
ACTION_CANCEL_TIMER
</pre>
No parameter.
Cancels a timer previously started with
ACTION_START_TIMER.

Digit format:

The digit format (for sending tone or ANI/DNIS prefix/suffix)
is represented by a string that contains up to 3 of the
following characters: 0123456789ABCD*#

CASr1 scripting

2013-07-30T15:15:51Z

Clod Patry: more formatting

2013-05-03T19:09:53Z

Clod Patry:

File:Local nat add.png

2013-05-03T19:09:26Z

Clod Patry:

File:Nat menu.png

2013-05-03T19:09:12Z

Clod Patry:

Enabling Local NAT Traversal A

2013-05-03T19:09:00Z

Clod Patry: add everything

=== '''''Applies to version: v2.7.''''' ===
{{DISPLAYTITLE:Enabling Local NAT Traversal}}

 
To enable Local NAT Traversal:

1- Select '''NATs''' from the left menu.

[[Image:nat_menu.png]]

2- Click on '''Create New Configuration'''
* Enter a significant Name
* Choose a Local Method.
* If necessary, give extra parameter.

[[Image:local_nat_add.png]]

* Click '''Create'''

Now that the NAT configuration has been done, you have to associate this with your NAP.

3- Select '''NAP''' from the navigation panel

[[Image:NatTraversal_0_A.png]]

4- Select a SIP NAP from the '''Network Access Point List'''
* Click '''Edit'''

[[Image:SipParams_0_1_A.png]]

5- In the section '''Network Address Translation''':
* Choose the proper Local Method. The select box will contain the same name as your Local NAT configuration, that you gave in step #2.
[[Image:local_nat_select.png]]

* Click '''Save'''

'''Here's more useful regarding the 2 Local NAT Traversal Methods:'''

'''No NAT'''

This method is if you're not behind a NAT. This is the default value.

'''Force Public IP'''

This method will set some SIP Headers and SDP fields with the IP address you set.

== Related actions ==
[[Symmetric_NAT_Traversal|Symmetric NAT traversal]]