Oxo10.3 SD Voipservices 8al91205usac 1 en

! " #$ %

&% '()* + ,('-
./',(0 # 1)('
Legal notice:
The information presented is subject to change without notice.
ALE International assumes no responsibility for inaccuracies contained

herein.
Copyright © ALE International, 2016
Disclaimer:
While efforts were made to verify the completeness and accuracy of the
information contained in this documentation, this document is provided “as
is”. To get more accurate content concerning Cross Compatibilities, Product
Limits, Software Policy and Feature Lists, please refer to the accurate
documents published on the Business Partner Web Site.
In the interest of continued product development, ALE International reserves

the right to make improvements to this documentation and the products it
describes at any time, without notice or obligation.
The CE mark indicates that this product conforms to the following Council
Directives:
- 2014/53/EU for radio equipment
- 2014/35/EU and 2014/30/EU for non radio equipment (including wired
Telecom Terminal Equipment)
- 2014/34/EU for ATEX equipment
- 2011/65/EU (RoHS)

Chapter 1
Expert Documentation structure
Chapter 2
General Presentation
Quality of Service (QoS) ....................................................................... 11

Environment tests ................................................................................... 12
RTP proxy services ................................................................................ 12
Direct RTP .................................................................................................. 13
Chapter 3
IP Telephony
Overview ..................................................................................................... 15

Home Worker ............................................................................................ 15
Detailed description ........................................................................................ 15
Remote Worker ........................................................................................ 16
!"#$ % &'! % () !* % 3/151

Configuring from an External DHCP ................................................ 17

Overview ......................................................................................................... 17
Configuring PIMphony IP ..................................................................... 17
Overview ......................................................................................................... 17
Chapter 4
H.323 Gateway
H.323 Gateway Services ....................................................................... 20

Service H.450 ............................................................................................ 22
Topologies ................................................................................................. 23
Architecture .................................................................................................... 23
Configuring H.323 Gateway ................................................................. 25
Hardware configuration .................................................................................. 25
Configuring a Remote H.323 Gateway ............................................. 27
Configuration examples .................................................................................. 27
Chapter 5
SIP
Overview ..................................................................................................... 33

SIP Protocol .................................................................................................... 33
Addressing ...................................................................................................... 34
Exchanging Messages ................................................................................... 34
Message Formats ........................................................................................... 35
Example of a Dialog ....................................................................................... 36
Media Negotiation ........................................................................................... 37
SIP Network Elements .................................................................................... 40
4/151 !"#$ % &'! % () !* %

Public SIP Trunking ................................................................................ 42

Overview ......................................................................................................... 42
Topologies ...................................................................................................... 42
Feature Description ........................................................................................ 45
Configuration procedure ................................................................................. 90
Private SIP Trunking ............................................................................ 118
SIP Gateway Services .................................................................................. 119
Topologies .................................................................................................... 120
Authentication/Registration ........................................................................... 122
Configuring SIP Gateway ............................................................................. 124
Configuring a Remote SIP Gateway ............................................................. 125
Chapter 6
Installation
Overview ................................................................................................... 132
Chapter 7
VLAN
Overview ................................................................................................... 133

Basic description .......................................................................................... 133
Topologies ............................................................................................... 133
Detailed description ...................................................................................... 133
Configuring VLAN ................................................................................. 135
Configuration procedure ............................................................................... 135
!"#$ % &'! % () !* % 5/151

Chapter 8
Dimensioning
Detailed description ............................................................................. 141

System Sizing ............................................................................................... 141
Configuration examples ...................................................................... 145
H.323/SIP Gateway Only .............................................................................. 145
Small IP Telephony Configuration ................................................................ 145
Large IP Telephony Configuration ................................................................ 145
Average Configuration in Mixed Telephony: IP and Conventional Telephony
(DECT/PWT) ................................................................................................ 145
Average Configuration in Mixed Telephony: IP and Conventional Telephony
(Reflexes) ..................................................................................................... 146
Medium Configuration for Mixed Telephony + H.323/SIP Gateway ............. 146
Bandwidth ..................................................................................................... 146
Limits ......................................................................................................... 147
VoIP Services ............................................................................................... 147
VoIP Channels on PowerCPU EE ................................................................ 147
DSP Channels .............................................................................................. 147
IP Sets .......................................................................................................... 148
"VoIP Access" Channels : H.323/SIP Gateway ............................................ 148
ARS Entry ..................................................................................................... 148
Chapter 9
Maintenance
IP Telephony ........................................................................................... 149

Maintenance ................................................................................................. 149
Service Alarm Messages .................................................................... 149
Maintenance ................................................................................................. 149
6/151 !"#$ % &'! % () !* %

Service Traffic Counters ..................................................................... 150

Maintenance ................................................................................................. 150
!"#$ % &'! % () !* % 7/151

As of R10.1, the OmniPCX Office Expert Documentation has been split into fifteen separated
documents, each corresponding to a chapter of the previous version of this documentation.
These documents are:
table 1.1: Expert Documentation structure
Documentation title Part number
[1] OmniPCX Office Expert Documentation: General Presentation 8AL91200xxAC
Summary: this document contains general information on the Om-
niPCX Office, such as a brief description of services provided,
platform hardware, handsets and user applications available, lim-
its, compatibility with standards, environmental constraints.
[2] OmniPCX Office Expert Documentation: Hardware: Platform, in- 8AL91201xxAC
terfaces and devices
Summary: this document covers all hardware aspects related to
the OmniPCX Office: this includes description of platforms (racks),
boards, sets and complementary equipment such as additional
modules or interface modules. This document also contains com-
missioning procedures for sets.
[3] OmniPCX Office Expert Documentation: User services 8AL91202xxAC
Summary: this document gives the presentation and configuration
procedure of features available for end-users. The final chapter of
the document synthesizes features availability according to the
type of device or application.
[4] OmniPCX Office Expert Documentation: Voice mail 8AL91203xxAC
Summary: this document details the integrated voice mail system
and automated attendant (general description, management, ser-
vices available for end-users), as well as configuration procedure
to connect an external voice mail unit.
[5] OmniPCX Office Expert Documentation: Mobility 8AL91204xxAC
Summary: this document contains a detailed description of mobil-
ity services available on the OmniPCX Office. This includes useful
information to deploy a DECT, PWT or IP-DECT infrastructure,
the description of associated base stations and handsets, and ne-
cessary information to implement OpenTouch Conversation cli-
ents.
Note 1:
This document does not cover VoWLAN.
[6] OmniPCX Office Expert Documentation: VoIP services 8AL91205xxAC
Summary: this document describes VoIP protocols supported by
the OmniPCX Office (such as H.323, SIP), configuration proced-
ure of private or public access through IP links, as well as dimen-
sioning and maintenance basic information.
8/151 !"#$ % &'! % () !* %


[7] OmniPCX Office Expert Documentation: Private networks 8AL91206xxAC
Summary: this documentation gives a description of architectures
and protocols (such as SVPN, QSIG) supported for a private net-
work, a description of ARS, metering, clock synchronization, and
the configuration procedure of accesses.
[8] OmniPCX Office Expert Documentation: General applications 8AL91207xxAC
This document gives a description of various applications avail-
able on the OmniPCX Office, such as Hotel, Call metering, CTI,
doorphones, Network management center, point-to-point/point to
multipoint T0, permanent logical link, multiple automated attend-
ant, multiple entities, My IC Plugin for Outlook®, My IC Web,
PIMphony Touch.
[9] OmniPCX Office Expert Documentation: Web-based tool 8AL91208xxAC
Summary: this document describes the web-based tool, which is
the integrated monitoring tool of the OmniPCX Office.
[10] OmniPCX Office Expert Documentation: OmniTouch Call Center 8AL91209xxAC
Office
Summary: this document provides the description and installation
procedure of OmniTouch Call Center Office. The document also
includes presentation and operation of Announcement, Traceabil-
ity, and a short description of Agent, Statistics and Supervisor ap-
plications.
[11] OmniPCX Office Expert Documentation: Management tools 8AL91210xxAC
Summary: this document describes the two management tools
available for OmniPCX Office: OMC and MMC station. The docu-
ment describes the OMC installation procedure, the different
types of access between OMC and OmniPCX Office (local, re-
mote, with or without proxy), the OmniPCX Office software install-
ation procedure via OMC and the list of services that can be man-
aged by OMC. For MMC stations, the document details the ser-
vices that can be managed and associated menus.
[12] OmniPCX Office Expert Documentation: Maintenance services 8AL91211xxAC
Summary: this document contains basic information concerning
the maintenance of your OmniPCX Office. This includes a dia-
gnosis methodology in case of system of terminal(s) failure, the
list of system messages, procedure to save/restore data, proced-
ure to stop/restart your system, to replace CPU, boards and sets.
[13] OmniPCX Office Expert Documentation: Security 8AL91212xxAC
Summary: this document gives essential information to secure
your OmniPCX Office. This includes deployment guide for certific-
ate, management of passwords, management of accesses to ser-
vices from LAN/WAN and network configuration for remote ac-
cesses,
[14] OmniPCX Office Expert Documentation: System services 8AL91213xxAC
Summary: this document gives information about software keys,
including their complete list. The document also describes opera-
tion of the OmniPCX Office with NTP (as client or server) and the
configuration of the embedded DHCP server.
!"#$ % &'! % () !* % 9/151
Chapter 1

[15] OmniPCX Office Glossary 8AL91214xxAC
Summary: this document contains a glossary of general telecom-
munications terms as well as specific terms related to OmniPCX
Office.
In the present document, cross-references are identified by the number in the first column of
the above table.
Part numbers are given in the last column, where xx corresponds to the language code of the
document.
Outlook is either a registered trademark, or a trademark of Microsoft Corporation in the United
States and/or other countries.
10/151 !"#$ % &'! % () !* %

OmniPCX Office Rich Communication Edition provides 2 services that can be combined:
- Voice over IP is based on the Integrated H.323/SIP Gateway, the core of Voice over IP
(VoIP), which allows communication between the conventional telephony world and the
data world.
- IP telephony enables an enterprise to share its data infrastructure (local IP network)
between the data world and the telephone world by means of IP terminals which connect
to the LAN and/or a Windows application on a Multimedia PC (PIMphony IP Edition) to
simulate a LAN PC station. For more information about PIMphony IP Edition, consult the
"Installation - configuration" file in the "Voice over IP" section.
Remark:
IP terminals can be:
- Alcatel-Lucent 8 series sets
- Mobile IP Touch WLAN handsets
- OmniTouch 8118/8128 WLAN Handset
The Voice over IP services are provided by the PowerCPU EE board and the ARMADA
VoIP32 daughter board. They have the following characteristics:
- 16 VoIP channels on the PowerCPU EE board and 32 additional VoIP channels when the
ARMADA VoIP32 daughter board is used
- supports the audio compression algorithms G711, G729a and G723.1
- IP communications in Full Duplex mode
- use of RTP/RTCP to send audio signals in real time
- supports the T38 protocol (Fax over IP): a Fax type call can be routed over IP through a
T38 fax channel
- echo suppression
- gain improvement
- tone generation and detection
- silence suppression (VAD). Note: do not activate voice detection on an IP station with
Codec G711
Additional characteristics applicable to the SIP gateway:
- direct RTP, reducing DSP channel allocation
- SIP option for (remote) gateway Keep Alive
Note:
All communications and VoIP signals transit via the PowerCPU EE board, except in the case of
communications between a PC with PIMphony IP and an IP terminal, between IP terminals, or between
IP terminals and IP trunks when direct RTP is activated. In all these cases only signaling transits via the
PowerCPU EE board.
2.1 Quality of Service (QoS)
!"#$ % &'! % () !* % 11/151
Chapter 2 + ,
Mechanisms in the system's ARS determine whether a VoIP call to a remote H.323/SIP
gateway can be made without degradation of bandwidth (see "Installation - Configuration"
File).
The aim is to provide an "end-to-end" QoS for all audio IP packets.
To achieve this, the system supports IP ToS (IP Type of Service): each IP VoIP packet
contains a 3-bit precedence field indicating a level of priority. This information can be used by
network elements (routers, gateways, etc.) to assign a level of priority to IP voice packets with
respect to IP data packets. OmniPCX Office Rich Communication Edition also supports
"DiffServ" (RFC 2475) and VLAN (since R5.0).
Note:
End-to-end quality of service can only be guaranteed if all network elements are IP ToS, DiffServ, or
VLAN compatible.
2.2 Environment tests

The H.323/SIP gateway (PowerCPU EE board equipped with the ARMADA VoIP32 daughter
board) is connected either to a 10 Mbps Ethernet LAN or to a 100 Mbps Fast Ethernet LAN via
an RJ45 cable (category 5).
2.3 RTP proxy services

In the case of a call from an IP terminal to a remote H.323/SIP gateway via an IP H.323/SIP
network, this service optimizes the call audio quality as it avoids any unnecessary
compression/decompression of voice packets.
Note:
The "RTP Proxy" function only applies if the Codecs are identical (for instance, same Codec for IP
handsets and IP trunks). In the case of an Alcatel-Lucent 8 series set, the Codec between the set and the
OmniPCX Office Rich Communication Edition adapts itself to the Codec between the OmniPCX Office
Rich Communication Edition and the IP trunk (Note: Alcatel-Lucent 8 series sets do not support 90ms
and 120ms framing and therefore IP trunk codecs should not use them). If the codecs are different, the
former mechanism will be applied, namely: "incoming" call on the gateway, IP/PCM decompression and
PCM/IP recompression for the "outgoing" call with a different codec.
12/151 !"#$ % &'! % () !* %
+ ,
2.4 Direct RTP

The direct RTP service provides direct RTP and RTCP flow exchange between IP endpoints
(IP sets, DSP channels on PowerCPU EE board or ARMADA VoIP32 daughter board, distant
gateways..).
From OmniPCX Office Rich Communication Edition R6.0, the direct RTP feature is offered for
SIP trunking and applies to private and public SIP trunking, provided that:
- The remote SIP proxies that the system is connected to are compatible with the transfer
optimization method (support of Re-INVITE without SDP). Most of the SIP proxies support
this method; OmniPCX Office Rich Communication Edition R5.0 and higher supports this
method in reception.
- IP phones connected to the system support RFC 4733 for DTMF sending.
- If direct RTP is activated and In-Band DTMF is selected for a SIP Trunk gateway, direct
RTP is disabled for all the calls associated to this SIP Trunk gateway, except for transit
calls, where both calls involved support In-Band DTMF. For more information, see: Public
SIP Trunking - Feature Description - DTMF .
The main advantages of direct RTP are:
- Audio path optimization, resulting in bandwidth use reduction in routers and network, better
audio quality by delay reduction.
• In addition to the proxy RTP and SIP optimization features, from R6.0 of OmniPCX
Office Rich Communication Edition, direct RTP can be used for Transfer and
Forwarding services in a heterogenous environment (need for configuration of the ARS
table). For other services such as Hold (with music on hold), Record on line and
Conference, the audio path is optimized by direct RTP on the distant side.
- Cost (and resource) reduction:
• Thanks to direct flow between IP sets and distant gateways or IP sets it is no longer
necessary to allocate DSP channels of the VoIP subscribers channel pool to basic
external calls.
For more information about reduction of VoIP channels, refer, in this chapter VoIP services, to
the section Dimensioning.
RTP/RTCP ports:
- Before R10.0, the port number used by the RTCP flow is assumed to be the consecutive
number of the RTP port (RTCP port = RTP port + 1). Errors can become with NAT devices
using port mapping. Ports order can be beaked.
- As of R10.0, OmniPCX Office Rich Communication Edition supports the RFC 3605
standard. The RTCP port is defined in the rtcp attribute of the SIP SDP request.
The RTCP attribute in SDP parameter authorizes or not the use of the rtcp attribute.
When disable, the OmniPCX Office Rich Communication Edition behavior is the same as
before R10.0: the rtcp attribute is neither generated nor interpreted.
The RTP direct parameter is also used to modify the OmniPCX Office Rich
Communication Edition behavior.
The table below gives the rtcp attribute management in SDP answer (e.g. 200 OK)
!"#$ % &'! % () !* % 13/151
Chapter 2 + ,
RTCP RTCP RTP RTCP port number RTCP attribute

enabled? received? direct? used with calling sent to called
N Y or N Y or N (RTP port received) + 1 no rtcp attribute
Y Y Y RTCP port received RTCP port received
Y Y N RTCP port received (OXO RTP port) +1
Y N Y (RTP port received) + 1 no rtcp attribute
Y N N (RTP port received) + 1 (OXO RTP port) +1
14/151 !"#$ % &'! % () !* %

3.1 Overview
The purpose of this section is to show how OmniPCX Office Rich Communication Edition can
be connected to VLANs.
This service does not require any specific external equipment (IP and/or Proxy/Firewall
Router), unless it is provided for Remote/Home workers.
The IP router (R) connected to the Intranet can be a simple IP router. The reservation of
bandwidth is "guaranteed" if this router supports IP ToS (DiffServ).
The number of remote IP Touch or PIMphony IP subscribers depends on the line bandwidth
(no more than 2 simultaneous calls for 64 Kbps, 5 for 128 Kbps).
3.2 Home Worker
3.2.1 Detailed description

3.2.1.1 Home Worker (remote IP Telephony via a VPN)
!"#$ % &'! % () !* % 15/151
Chapter 3 - , . )
The connection between the Home worker and the Internet must be "always-on" (ADSL, cable,
etc.). It is indispensable to have an IP/Proxy/Firewall router or a VPN server on the Home
worker side.
The IP router (R/F) at the front end of the VPN must offer Proxy/Firewall and VPN server
functionality (e.g. IPSec with 3DES encryption).
The number of remote IP Touch or PIMphony IP sets depends on the line bandwidth (no more
than 2 simultaneous calls for 64 Kbps, 5 for 128 Kbps).
3.3 Remote Worker

3.3.1.1 REMOTE WORKER (PIMphony IP via a VPN)
16/151 !"#$ % &'! % () !* %
- , . )
The connection between the remote PC (PIMphony IP Edition) and the Internet is of the
"dial-on-demand" type (V90 analog, ISDN or ADSL modem). The remote PC first establishes a
connection to the nearest access provider, then a PPTP connection to the company's VPN
server.
3.4 Configuring from an External DHCP
3.4.1 Overview
The following minimum parameters must be configured for Alcatel-Lucent 8 series stations:
- IP address
- Subnet mask
- Router address
- TFTP address (DHCP option code 066)
- "Vendor Specific Information" option:
• If the Alcatel-Lucent 8 series station is configured in DHCP ALE International only, this
option's value must be set at "a4200.0"
• <Recommended> If the Alcatel-Lucent 8 series station is configured in DHCP non-ALE
International, this option must not be configured
3.5 Configuring PIMphony IP
3.5.1 Overview
3.5.1.1 Creating an IP user
A PC equipped with PIMphony IP is considered by the system as an IP user, in the same way
as an IP set.
- For PIMphony you must create an IP user (of type "Multimedia PC") before installing
PIMphony. This is done in the OMC tool, as follows:
1. In the OMC tool, navigate to the screen Users/Basestations List and click Add. This
displays the Add User screen.
2. Select IP Terminal and choose the EDN number in the No. field according to the
numbering plan, then click OK.
3. In the Users/Basestations List screen, change the terminal type for the new
subscriber to "PC Multimedia" in the Terminal/Basestat. field.
3.5.1.2 Registering the IP address
Unlike IP sets, OmniPCX Office Rich Communication Edition does not manage the IP address
of a Multimedia PC; only its MAC address is registered at first connection. No software
(firmware) is transferred between the system and PIMphony IP during the registration
procedure.
Registration is an open operation based upon the IP protocol: the PC generates a Multicast
request and waits for the reply from a VoIP board (PowerCPU EE board). During the
!"#$ % &'! % () !* % 17/151
Chapter 3 - , . )
reply/registration phase, the VoIP board (PowerCPU EE board) indicates its IP address to the
PC and the PC transmits its Ethernet address (MAC Address) to the PBX.
If there is no reply (e.g. IP routing problems), the PC generates the Multicast request several
times, and if no reply is obtained, PIMphony IP enters into a "failure". The user is then asked to
indicate the IP address of the VoIP board (PowerCPU EE board); if the address is incorrect,
another request is made.
Once registration has been performed, the IP address of the VoIP board (PowerCPU EE
board) is stored in the Windows registry and will be used for all future connections. If a
problem arises, such as a change in the IP address of the VoIP board (PowerCPU EE board),
a new registration sequence (Multicast request) is initiated.
After initialization of PIMphony IP, IP connectivity must be permanent, otherwise the system
considers the PC to be out of service.
Note:
A "Multimedia PC" in the subscribers list is a PC equipped with PIMphony IP Edition.
3.5.1.3 Choosing the codec to used

Three different codecs are available:
- G711: This is a high bit rate ITU standard codec. It is based on PCM (Pulse Code
Modulation) at a sampling rate of 8kHz. The frequency bandwidth is 300 Hz – 3.4 kHz. It
uses no compression and it is the same codec used by the PSTN network and ISDN lines.
Each sample is coded with 8 bits A-law (in Europe) or with 7 bits mu-law (in the US), which
produces respectively a 64kbps or 56kbps bit stream. Narrowband MOS (Mean Opinion
Score) = 4.1 – Coding Delay = 1ms – Complexity << 1 MIPS.
- G723.1: G723.1 is recommended for very low bit rates. It is a dual rate coder (5.3 kbps or
6.3 kbps) based on ACELP (Algebraic Code Excited Linear Prediction) for the low-rate
coder and based on MP-MLQ (MultiPulse – Maximum Likelihood Quantization) for the high
rate coder. The bandwidth is 3.1 kHz in both cases. The lower bit rate has a poorer quality
compared to higher bit rate, but provides systems designers with additional flexibility.
Narrowband MOS (Mean Opinion Score) = 3.8 – Coding Delay = 67ms – 97ms –
Complexity = 16 MIPS.
- G729A: The G729a recommendation targets very low bit rate. This is one of the most
recent and promising codec standardized by the ITU. It belongs to the G729 family, and as
such, is a competitor to G723.1. It is based on CS-ACELP (Conjugate Structure –
Algebraic Code Excited Linear Prediction), and produces 8 kbps bit stream from a 3.1 kHz
bandwidth. The bit rate is slightly higher than with G723.1 but the delay is significantly
lower. Narrowband MOS (Mean Opinion Score) = 3.7 – Coding Delay = 25 ms – 35 ms –
With no compression mode, the G711 codec has the highest bandwidth requirements. The two
other codecs (G729A and G723.1) support compressed speech, and you can reduce VoIP
bandwidth by 35% by enabling the voice activity detection (check the box With silence
detection (VAD)).
Note 1:
G711 provides the best audio quality but takes a higher data rate, G729AB is a good trade off between
voice quality and lower data rate but it is not suited for transmission of audio tones and music. G723 has
the lowest data rate but at the expense of quality and delay which makes it the least recommended
choice.
Note 2:
18/151 !"#$ % &'! % () !* %
- , . )
G729AB (G729A with silence detection) is supported when the box With silence detection (VAD) is
checked.
The Quality of Service applies to all codecs.
To enable your preferred codec:
1. Select the PIMphony menu Tools / Options.
2. Click the VoIP tab.
3. Choose a VoIP Application board name or address, or automatically detect the VoIP board
by clicking the Auto-detect button.
4. Select your preferred codec among the options (G711 is the default preferred codec).
The table: Gateway Bandwidth indicates the codec options available for different framing
requirements.
table 3.1: Gateway Bandwidth
CODEC Framing (in milliseconds)
G711 20, 30 (default), 60
G723.1 30 (default), 60, 90, 120
G729a 20, 30 (default), 40, 50, 60, 90, 120
Note 3:
You cannot use framing value 90 ms or 120 ms for codecs G.723.1 and G.729A when IP Touch sets are
connected to OmniPCX Office Rich Communication Edition.
!"#$ % &'! % () !* % 19/151

4.1 H.323 Gateway Services

This service can be implemented using an external router to the internet or to a dedicated link.
The OmniPCX Office Rich Communication Edition H.323 Gateway service can be
implemented in the following 3 contexts:
- H.323 gateway integrated into a standalone configuration
- H.323 gateway integrated into an H.323 area
- Gateway managed from another OmniPCX Office Rich Communication Edition system
4.1.1.1 H.323 Gateway Integrated Into a Standalone Configuration
In a standalone configuration, the integrated gatekeeper is alive; it is masked to the exterior
and cannot be managed from the LAN.
4.1.1.2 Gateway in an H.323 Area

In a network topology like the one below, the H.323 gateway of OmniPCX Office Rich
Communication Edition can be integrated into an H.323 area managed by an external
gatekeeper.
20/151 !"#$ % &'! % () !* %
/'0 0 + 1)
In this configuration, the gatekeeper integrated into OmniPCX Office Rich Communication
Edition must be deactivated and the network administrator must supply the IP address of the
external gatekeeper.
Note:
The ARS table must always contain all the IP addresses.
4.1.1.3 Gateway Managed From Another OmniPCX Office Rich Communication

Edition System
In this configuration, the H.323 gateway is managed by a Gatekeeper which is integrated into
!"#$ % &'! % () !* % 21/151
Chapter 4 /'0 0 + 1)
another OmniPCX Office Rich Communication Edition system and which therefore has its own
gateway. This configuration is suitable for small installations (less than 10 gateways and 50
PC/H.323 terminals).
This requires configuration of numbering plans in full for all systems. All the H.323 items
(remote system, PC, H.323 terminals) should be defined in the ARS tables of all systems. The
Gatekeepers integrated into other OmniPCX Office Rich Communication Edition systems
should be inhibited and the IP address of these systems' external Gatekeeper should be the
same as the master system's.
4.1.1.4 Fax over IP (FoIP)
The Fax over IP services are available when a Fax is detected in an H.323 call. When this
happens, the Audio channels are closed and T38 sessions are initialized to transmit or receive
Fax packets (IFP - Internet Fax Packet).
OmniPCX Office Rich Communication Edition only allows T38 sessions over UDP. In order to
ensure the reliability of the UDP transmission, the packets are sent several times to ensure
that the information reaches its destination; this operation is called "UDP Redundancy".
In order to reduce bandwidth use, an operation (framing) allows the concatenation of packets
of the same type.
The Fax over IP (FoIP) service does not require any particular configuration of the ARS table.
A Fax call is considered as a transparent H.323 call to the ARS operations.
Note:
Fax over G711, an extended procedure of Fax over IP using the SIP protocol, is not supported in the
context of H.323 calls.
4.2 Service H.450

The following services are supported:
H.450 Service Supported level
H.450.1: Generic functional protocol for additional Supported
H.323 services
H.450.2: Call transfer Supervised transfer: supported
Unsupervised transfer:
- if the destination is an OmniPCX Office Rich
Communication Edition: supported
- if the destination does not support this feature, a
transfer by joining is made by forwarding Omni-
PCX Office Rich Communication Edition
H.450.3: Call forwarding Immediate diversion: supported (including PO for-
warding)
Other forwarding: not supported
H.450.4: Warning Not supported
H.450.5: Call parking/pick-up Not supported
H.450.6: Call signaling on the called station Not supported
22/151 !"#$ % &'! % () !* %
/'0 0 + 1)
H.450.7: Camped-on call signaling Not supported

H.450.8: Advanced display and information Not supported
Optimizing resources
The H450 protocol allows not to use the voice coding resources on OmniPCX Office Rich
Communication Edition. In the case of a transfer or a forwarding request, the two initial calls
are released and replaced with a single direct call between the two parties. Thus, the
bandwidth consumption is decreased and all the DSP resources used for the initial calls are
released on the OmniPCX Office Rich Communication Edition performing the forwarding or the
transfer.
Note:
OmniPCX Office Rich Communication Edition cannot fully optimize a three-node transfer. In this case,
the transfer is made by joining.
4.3 Topologies
4.3.1 Architecture
This section describes typical IP network architecture for implementing the OmniPCX Office
Rich Communication Edition Voice over IP services.
A V4-compatible H.323 gateway complies with recommendations to provide support for:
- Q.931/Q932 signaling
- H.225 v4 protocol for establishing signaling channels between H.323 gateways (including
Fast Connect)
- H.245 v7 protocol to monitor communications: establishing channels, negotiating the
Codec, etc.
- RAS signaling for communications with the H.225 internal gatekeeper (H.225 v4) or to the
outside (authentication, authorization, bandwidth management)
- H.450.1, H.450.2, H.450.3 : additional services (transfer, forwarding)
The gateway also integrates an H.323 v4 gatekeeper that provides the following functions:
- RAS (Registration Admission Status) server
- Testing the presence of remote H.323 gateways (ICMP or H.323 packets)
4.3.1.1 Multi-site configurations
A multi-site configuration is possible via an extended Intranet or an Internet VPN.
4.3.1.2 H.323 gateway integrated into an extended Intranet
!"#$ % &'! % () !* % 23/151
Chapter 4 /'0 0 + 1)
bandwidth is "guaranteed" if this router supports Ipv4 ToS (DiffServ).
4.3.1.3 H.323 gateway integrated into a VPN
functionality (IPSec with 3DES encryption for interoperability with the system's built-in router).
4.3.1.4 IP telephony in an extended Intranet
24/151 !"#$ % &'! % () !* %
/'0 0 + 1)
Note:
See also the Home Worker and Remote Worker topologies described earlier.
4.4 Configuring H.323 Gateway
4.4.1 Hardware configuration

H.323 Gateway: This application layer forms the interface between the IP telephony (H.323
stack) and switched telephony worlds (OmniPCX Office Rich Communication Edition PBX call
manager).
4.4.1.1 Configuring the system as the H.323 gateway
By default, after initialization, all the DSPs are assigned to the pool of VoIP subscriber
channels (IP telephony).
In a pure H.323 gateway configuration, all the DSPs of the system will be used for "IP network"
accesses.
By OMC (Expert View): System -> Voice on IP -> VoIP: Parameters -> General tab
Number of VoIP access channels (IP trunks): Number of channels for VoIP IP access, i.e. 1
DSP channel for 1 "network access".
Quality of IP service: Selection of the type of QoS used for the remote H.323 gateway VoIP
calls.
If all the network equipment items support the IP ToS, one can choose an IP priority from 1 to
7.
If all the network equipment items are "DiffServ" compatible, one can choose from:
- DiffServ PHB Best Effort Forwarding (BE) (priority bits: 00000000 )
- DiffServ PHB Expedited Forwarding (EF) (priority bits: 10111000 )
!"#$ % &'! % () !* % 25/151
Chapter 4 /'0 0 + 1)
Note:
Each DSP placed in the "VoIP access" pool is considered as a "network access" by the PBX, i.e. 1 VoIP
DSP = 1 B-channel. The PowerCPU EE board can be equipped with an ARMADA VoIP32 daughter
board providing up to 32 additional VoIP resources. The maximum number of VoIP resources is therefore
48 i.e. 48 "IP" B-channels.
Network accesses (T0, T2, analog TL, DLT0, DLT2) + VoIP Accesses = 120 Max.
4.4.1.2 Configuring the gatekeeper (optional)
By OMC (Expert View): System -> Voice on IP -> VoIP: Parameters -> Gatekeeper tab
- Integrated gatekeeper: By default, the Gatekeeper is integrated into the PBX (box is
selected); if not, fill in the Gatekeeper's identification
- IP Address: If the PBX is a gateway in an H.323 area, one must use an external
gatekeeper that is the manager of the H.323 area it covers, indicating its IP Address
provided by the network administrator
4.4.1.3 Configuring the Gateway timeouts (optional)
By OMC (Expert View): System -> Voice on IP -> VoIP: Parameters -> Gateway tab
NB: The parameters have standardized values, do not change them without prior analysis.
- RAS Request Timeout: Maximum authorized response time for a RAS request
("Registration, Admission, Status") made to the gatekeeper; between 10 and 180; default
value = 20
- Gateway Presence Timeout : Determines the presence of a remote Gateway; value
between 10 and 600; default value = 50
- Connect Timeout: Maximum authorized time interval between initialization and
connection; value between 10 and 1200; default value = 500
- H.245 Request Timeout: Maximum authorized response time for an H.245 request; value
- H323: End of dialing timeout: Default value = 5
4.4.1.4 Configuration of T38 parameters for Fax over IP (optional)
By OMC (Expert View): System -> Voice on IP -> VoIP: Parameters -> Fax tab
- UDP Redundancy: Number of forwardings of Fax data packets; value between 0 and 2;
default value = 1
- Framing: Number of frames in the same data packet ; value between 0 and 5; default
value = 0. In fact, the number of frames is equal to the number in this field + 1
- Error Correction Mode: As of R10.0, this parameter (previously managed via noteworthy
addresses), enables/disables the FAX ECM mode on IP trunk. This parameter is available
in both H.323 and SIP VoIP protocol mode. This feature is disabled by default
Note:
a) Only T38 traffic is supported: modem, V90, V24, etc., are not available via H323/SIP connection. b) If
the UDP redundancy is set to 0, any framing value (0 to 5) can be used. If the UDP redundancy is set to
26/151 !"#$ % &'! % () !* %
/'0 0 + 1)
1, the framing value must not be higher than 1.
4.5 Configuring a Remote H.323 Gateway
4.5.1 Configuration examples

4.5.1.1 Configuring outgoing communication (ARS table)
The choice of routing a telephone communication between a public network access or a VoIP
access and the busy trunk overflow feature are defined in the ARS table.
Like conventional outgoing telephone calls, a VoIP call is subject to the ARS mechanisms: link
categories, ARS time slot management, overflow on busy, etc.
In the diagram below sites A and B are OmniPCX Office Rich Communication Editions. Site C
is a remote system integrating an H.323 gateway.
- @IP1 : IP address of the PowerCPU EE board at site A

- @IP2 : IP address of the PowerCPU EE board at site B. For example: 192.189.50.120
4.5.1.2 Basic call
The site A stations call the site B stations by dialing their internal numbers:
Internal numbering plan (site A):
Function Start End Base NMT Priv
Secondary trunk group 2 2 ARS Keep Yes
!"#$ % &'! % () !* % 27/151
Chapter 4 /'0 0 + 1)
ARS Table:
Network Access Range Substitute List. Trunk Called Party Comment
group list (ISVPN/H450)
Priv. 2 00-49 2 4 Het H.323 to site B
- The "Called(ISVPN/H450)" field has the value "Heterogeneous" by default. The notions of
ISVPN do not apply to VoIP calls. This field is used for H450. If the remote is known to
manage H450 transfer and/or forwarding services, this parameter can be set to
"Homogenous", "Homogeneous Forward" or "Homogeneous Transfer".
- The "User Comment" field enables a comment to be associated with the ARS input (20
characters maximum)
Note 1:
The IP parameters in the ARS table are accessed by right-clicking and selecting "IP parameters".
Destination IP Type IP address Host- Gateway Gateway Bandwidth Gateway

name Alive Pro- Alive Alive
tocol Timeout Status
Gateway Static 192.189.50.120 option ICMP 300 128 Kbits Enabled
(5 calls)
- The "Destination" field of an ARS input to VoIP accesses must be of the "Gateway" type
(H.323 gateway)
- For a "Gateway" destination, the "IP Type" must be a static IP address (non-modifiable
field)
- The "IP Address" field must be that of the remote H.323 gateway. In the example, this
value corresponds to the IP address of the PowerCPU EE board at site B
- The "Host name" can be used instead of the IP address of the remote gateway's
Gatekeeper. Requires a DNS server
- Gateway Alive Protocol / Gateway Alive Timeout:
The integrated gateway tests the presence of the remote gateway every 300 seconds
(Gateway Alive Timeout, from 0 to 3600 seconds). The test protocol (Gateway Alive
Protocol) used by default is ICMP: the H.323 test protocol can only be used if the remote
gateway is H.323 V4-compatible
Note 2:
Gateway Alive Timeout : If this field is at 0, the "Gateway Alive Protocol " mechanism is inhibited. This
option is to be used in the specific situation where it is impossible to use ICMP or H.323 to test for the
presence of the remote gateway; but in this case, there is no means whatsoever of knowing whether the
remote gateway is alive or out of service.
- Gateway Bandwidth / QoS: For each ARS input to a remote H.323 gateway, a bandwidth
must be reserved for the Voice over IP to the remote H.323 gateway. The number of
simultaneous communications that can be held depends on this value:
28/151 !"#$ % &'! % () !* %
/'0 0 + 1)
Bandwidth Number of simultaneous commu-

nications possible
None No communication possible (Default
value)
55.6 Kbps 1
64 Kbps 2
128 Kbps 5
256 Kbps 10
512 Kbps 20
# 1024 Kbps > 20
For example, if the total bandwidth corresponding to the data rate to a remote gateway is 256
Kbps and the mean traffic level is 50%, it is wise to define a bandwidth of 128 Kbps for Voice
over IP.
4.5.1.3 Remark concerning the quality of service (QoS)
If we take our example, site A can make H.323 calls to sites B and C. One assumes that the
bandwidths reserved for Voice over IP at the LAN/WAN gateways of each site are:
- Bandwidth reserved for VoIP on site A: 1024 Kbps (20 calls or more)
- Bandwidth reserved for VoIP on site B: 128 Kbps (5 simultaneous calls)
- Bandwidth reserved for VoIP on site C: 64 Kbps (2 simultaneous calls)
In this configuration one sees that it is possible to make 7 simultaneous calls from site A to the
remote H.323 gateways: 5 to site B and 2 to site C.
7 DSPs can therefore be assigned in the "VoIP access" pool for site A (7 being the number of
DSPs needed to call sites B and C simultaneously).
However, let us assume that there is no ongoing communication between sites A and C, and
that 5 calls are established between A and B. The total number of VoIP network access DSPs
consumed in PBX A is 5: therefore 2 DSPs remain available to establish two other calls to site
B.
Yet in this example we exceed the bandwidth reserved for Voice over IP at the LAN/WAN
gateway of site B. The quality of service is no longer guaranteed.
To avoid downgrading the VoIP service, the system uses the "Gateway Bandwidth" field of the
ARS table associated with the input to the remote H.323 gateway of site B, which will be
configured at 128 Kbps (5 calls), as quality indicator (QoS). Although there are still 2 DSPs
available, the PBX will refuse a 6th call to site B.
Note 1:
This service is not available if an external gatekeeper is used.
Note 2:
To optimize management of this ARS table parameter, it is vital to have information about the bandwidth
available (reserved) for VoIP calls that is as precise as possible.
- Gateway Alive Status: this regularly updated read-only field indicates the status of the
remote gateway:
• Alive: Remote gateway present
!"#$ % &'! % () !* % 29/151
Chapter 4 /'0 0 + 1)
• Deactivated: Remote gateway absent / out of service

It can, however, turn out to be judicious to deactivate the mechanism if one is sure of network
reliability, in order to reduce the traffic.
4.5.1.4 Incoming call
An incoming "VoIP access" call is analyzed in the private numbering plan. In our example:
Private numbering plan of site B:
Local call 200 249 200 No
4.5.1.5 Forcing a public call to the H.323 gateway

LCR : Least Cost Routing
When a site A subscriber dials the public number of the site B station, the call can be forced to
the VoIP network accesses:
Internal numbering plan of site A:
Main trunk group 0 0 ARS Drop No
ARS Table:
Network Access Range Substi- List. Trunk Called Party Comment
tute group list (ISVPN/H450)
Pub. 04723542 00-49 2 4 Het H.323 to site B
4.5.1.6 Overflow
When a site A subscriber calls a site B station by its internal number, ARS routing enables the
calls to be re-routed to the public network when it is no longer possible to call via the VoIP
accesses. The following criteria render a "VoIP access" trunk group inaccessible:
- The PowerCPU EE board of site A is out of service
- No more DSPs associated with the VoIP accesses are available
- The remote H.323 gateway is out of service (PowerCPU EE board of site B is out of
service).
- The quality of service (QoS) to the remote gateway is poor (exceeding of the possible
simultaneous communication threshold for the bandwidth reserved for Voice over IP for
this remote H.323 gateway)
ARS table of site A: Network
Calling the site B station by its internal number:
30/151 !"#$ % &'! % () !* %
/'0 0 + 1)
Net- Access Range Substitute List. Called Party Comment Destination

work Trunk (ISVPN/H450
group list )
Priv. 2 00-49 2 4 Het H.323 to site Gateway
B
04723542 1 Het ISDN Access No IP
Calling the site B station using its public number:

Net- Access Range Substi- List. Called Party Comment Destina-
work tute Trunk (ISVPN/H45 tion
group list 0)
Pub. 04723542 00-49 2 4 Het H.323 to site Gateway
B
0472354 1 Het ISDN Ac- No IP
2 cess
Pub. 04723542 50-99 0472354 1 Het ISDN Ac- No IP *
2 cess
* : As the public numbers 04723542 50 to 99 do not belong to site B, they must be routed to
the public network.
4.5.1.7 Break In
The break-in service enables the PBX to re-route a public number from site A to site B. In our
example, the public network subscriber dials the number 03 88 67 71 50 which is routed to
station 250 on site B:
Public numbering plan (site A):
Secondary trunk group 7150 7150 ARS Keep No
ARS Table:
group list (ISVPN/H450)
Pub. 0388677150 250 4 Het H.323 to site B
Reminder: It is vital for the PBX "Installation number" field to be configured; e.g. for site A:
388677100.
4.5.1.8 Break Out
The break-out service enables proximity calls to be made. In our example, a site A station dials
a public number starting with 04, the call is routed to site B via the H.323 gateway, then routed
to the public network from site B, configuration:
!"#$ % &'! % () !* % 31/151
Chapter 4 /'0 0 + 1)

Net- Access Range Substitute List. Called Comment Destination
work Trunk Party
group list (ISVPN/H
450)
Pub. 04 004 4 Het H.323 to site Gateway *
B
04 1 Het ISDN Ac- No IP **
cess
* : As the prefix 0 is dropped in the internal numbering plan, 004 must be substituted for 04,
** : This sub-line allows overflow to the public network lines of site A if the VoIP access calls
are inaccessible.
As an incoming VoIP access call is analyzed in the private numbering plan, the following must
be programmed in the private numbering plan of site B:
Main trunk group 0 0 0 Drop No
32/151 !"#$ % &'! % () !* %

5.1 Overview
5.1.1 SIP Protocol

SIP (Session Initiation Protocol) is an IP signaling protocol designed to establish, to maintain
and to end multimedia sessions between different parties. It operates on a client-server mode.
It is based on the exchange of text messages with a syntax similar to that of HyperText
Transport Protocol (HTTP) messages. Elements of the SIP world are identified by SIP Uniform
Resource Locators (URLs) similar to e-mail addresses.
It is important to note that SIP does not provide an integrated communication system. SIP is
only in charge of initiating a dialog between interlocutors and of negotiating communication
parameters, in particular those concerning the media involved (audio, video). Media
characteristics are described by the Session Description Protocol (SDP). SIP uses the other
standard communication protocols on IP: for example, for voice channels on IP, Real-time
Transport Protocol (RTP) and Real-time Transport Control Protocol (RTCP). In turn, RTP uses
G7xx audio codecs for voice coding and compression.
Unlike H.323, the SIP protocol can rely on the IP network transport protocol in datagram mode
User Datagram Protocol (UDP) in addition to the IP network transport protocol in Transmission
Control Protocol (TCP) connected mode: see figure: H.323 and SIP in the OSI Model . UDP
has the advantage of being an unconnected protocol that facilitates swift exchanges. It does
not guarantee datagram reception and transmission sequence preservation. Thus, SIP carries
out these functions, using retransmission, acknowledgement and sequencing mechanisms.
Figure 5.1: H.323 and SIP in the OSI Model

SIP introduces the concept of user mobility. A call is made by entering the "logical" address of
!"#$ % &'! % () !* % 33/151
Chapter 5
a user (as a URL). This address is used to identify the user, but not to detect his/her location.
To execute a conversion between the logical address and the actual location, an entity called a
location server, which provides the user's actual address at the time of the call (URL of the
device to be called), is consulted. The location server knows the addresses of the users
because it has their registrations.
This operating mode also enables a user to receive his calls simultaneously on several
terminals if the latter are registered with the same logical address.
5.1.2 Addressing
The SIP protocol uses URLs. They are constructed from:
- A number (to the left of the "@"), which can take on the form of standard numbers
(canonical form), for example +497118245000
- A domain part (to the right of the "@") which can be an IP address, the name of a machine,
or a Fully Qualified Domain Name (FQDN), i.e. the name of a domain.
Example:
sip:5000@192.168.5.10, sip:+497118245000@sip.mycompany.com
5.1.3 Exchanging Messages

Like HTTP, SIP is constituted by transactions. A transaction is made up of a request sent by a
client and of 0 to n responses to this request sent by a server. Unlike HTTP, a client (who
transmits requests and waits for answers) can also be a server (which receives requests and
sends back answers). All transactions are independent from each other. However, some can
be used to set up a "dialog". Transactions within a dialog are linked. For example, a phone call
is a dialog: in addition to calling, one must hold, or hang up.
The main types of requests (which initiate transactions) are:
- INVITE: message sent systematically by the client for any connection request. The INVITE
message can also be used to update an established session. In this case, it is also called
Re-INVITE.
- ACK: message sent by the client to end and to confirm the connection request.
- PRACK: same role as ACK for provisional responses.
- UPDATE: update method is used to refresh sessions, update connected identity and
change media session parameters.
- BYE: terminates a call, RTP packet exchange is stopped.
- CANCEL: terminates a call currently being set up.
- REGISTER: message sent by an agent to indicate his actual address. This information can
be stored in the location server and is used for call routing.
- OPTION: message used to perform capability query (and keep-alive mechanism by the
OmniPCX Office Rich Communication Edition).
Responses are characterized by a code which is an integer:
- 1xx: informational (transaction in progress).
- 2xx: success (transaction completed successfully).
- 3xx: forward (the transaction is terminated and prompts the user to try again in other
34/151 !"#$ % &'! % () !* %

conditions).
- 4xx, 5xx, 6xx: errors (the transaction is unsuccessfully terminated).
Certain transactions completed successfully establish a dialog within which other transactions
can be exchanged (parameter negotiations, inter-interlocutor signaling data transport, etc.).
Please note that the path followed by the initial transaction is not necessarily the one that other
transactions within the dialog will follow. Indeed, the initial transaction will be sent to the
interlocutor's logical address, and can pass through SIP entities in charge of finding his actual
location. Once the final called party has been found and the initial transaction has established
a dialog, the next transactions within the dialog are exchanged directly between interlocutors.
Certain SIP entities through which the initial transaction is transmitted, can however remain in
the signaling path. A specific transaction is used to terminate the dialog. In the case of a dialog
initiated by an INVITE request, BYE terminates the dialog.
5.1.4 Message Formats

Requests and responses include two parts: A heading (mandatory) and, in certain cases, a
second part called the body. The heading includes several fields called headers.
table 5.1: Example of an INVITE Message:
INVITE sip:3481545074@172.25.41.10;user=phone SIP/2.0
Supported: 100rel
User-Agent: OxO GW
P-Asserted-Identity: sip:+0810021883@mycompany.com;user=phone
To: <sip:3481545074@mycompany.com;user=phone>
From: <sip:+0810021883@mycompany.com;user=phone
;tag=50ea3fbbbf41236cf7cc145b963a9140>
Contact: <sip:+0810021883@62.97.50.243;user=phone>
Content-Type: application/sdp
Call-ID: 78fa3caba1338e93dc50e8262f5ccd13@62.97.50.243
CSeq: 1453537030 INVITE Via: SIP/2.0/udp 62.97.50.243
;branch=z9hG4bKc43959f162a7bc2699f6f86425bf0899
Max-Forwards: 70
Content-Length: 215
** Body not Show **
For greater clarity, the body of the above message is not shown.
Some of these fields (or field parts) identify transactions and dialogs. Certain fields provide
caller and called party data:
- Request-URI sip:3481545074@172.25.41.10: routable address of the destination
- To: sip:3481545074@mycompany.com: address of the final called party of the request.
This is a logical address: it does not allow to send the request directly; the location step is
required to determine the actual address of the called party at the time of the call. SIP
entities called proxies are in charge of transporting requests to the final location of the
called party.
- From: sip:+0810021883@mycompany.com: address of initial request sender (logical
address).
!"#$ % &'! % () !* % 35/151
Chapter 5
Certain fields indicate which path the next requests must follow within a dialog (Contact,
Route, Record-Route fields). Unless requested by the SIP entities used during dialog initiation,
the next requests are directly exchanged by terminal entities.
- Contact: sip:+0810021883@62.97.50.243: physical address of each interlocutor.
Other fields describe the format and the size of the message body (in this example, an SDP
description). Finally, optional fields can be added, depending on selected transaction
functions.
A SIP entity can send a message body containing an SDP description of the media it chooses
to use (IP transport, compression algorithms). The remote entity responds with a SIP message
containing an SDP description of the media selected in the initial offer. This negotiation phase
can also take place again once the call is established.
5.1.5 Example of a Dialog
Figure 5.2: Example of a dialog

The exchange shown in figure: Example of a dialog includes 2 transactions.
The first transaction begins with the INVITE request from Alice to Juliette and ends with a non
1xx response; in the example, the OK response from Juliette:
1. Alice sends an INVITE request to her proxy server for a call to Juliette. This request
contains an SDP description of the media that Alice wishes to use,
2. The proxy server determines Juliette's proxy server address, for example by consulting a
DNS server, transmits an INVITE request to this server and a 100 Trying response to
36/151 !"#$ % &'! % () !* %

Alice,
3. The second proxy server transmits a 100 Trying response to the first server and consults
its location server to find Juliette's actual address. Once this address is identified, the
INVITE request is sent to Juliette's SIP terminal,
4. Juliette is informed of the call when her terminal rings and a 180 Ringing response is sent
to Alice's terminal. This response contains, in the Contact field, Juliette's current address
(where she can be contacted directly without transiting via the proxy server),
5. When Juliette off-hooks, a 200 OK response is sent to Alice's terminal. This response ends
the transaction. It can contain an SDP description of the media that Juliet wants to use in
relation to Alice's suggestion,
6. The second transaction begins with Alice's acknowledgement ACK. The ACK request is
transmitted to Juliette's URL, contained in the 200 OK contact field.
RTP/RTCP voice channels on IP are established between the two terminals, in compliance
with the results of SDP negotiation,
7. Two messages (BYE and 200 OK) end the dialog. RTP/RTCP channels are also released.
5.1.6 Media Negotiation

Media negotiation consists in an offer/answer dialog allowing to select the media that will be
used for a communication between two user agents. The SDP protocol is used (defined in
RFC 4566).
For a voice communication, media negotiation applies to the compression algorithm, to VAD,
to the quantization law (A or µ law) and to the framing.
Media negotiation takes place at call setup. There are two cases:
- The offer is given by the calling user agent in the INVITE message. In this case, the called
user agent gives an answer in the 200 OK message.
Figure 5.3: Media Negotiation with an Offer in the INVITE Message

- The offer is not given by the calling user agent in the INVITE message. In this case, the
called user agent makes an offer in the 200 OK message and the calling user agent makes
an answer in the ACK message.
!"#$ % &'! % () !* % 37/151
Chapter 5
Figure 5.4: Media Negotiation with no Offer in the INVITE Message
5.1.6.1 Offer Description for Voice Communications

table 5.2: Example of Offer
v=0
o=default 1149510698 1149510698 IN IP4 62.97.50.243
s=-
c=IN IP4 62.97.50.243
t=0 0
m=audio 32082 RTP/AVP 0 8 106
a=sendrecv
a=ptime:30
a=maxptime:120
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 telephone-event/8000
a=fmtp:106 0-15
table 5.3: Offer Description

v Version of the offer
c Address of the media gateway that will send and receive media flows
m Media description
- audio: media type
- 32082: port number
- RTP/AVP: transport type
- 0 8 106: payload type proposed
• 0: G711 µ law
• 8: G711 A law
• 106: dynamic payload (telephone-event)
a Media description attributes:
- sendrecv: the media is bidirectional (other value are: recvonly and sendonly)
- ptime: framing
- rtpmap: media associated to the specified payload
- fmtp: parameters for the specified payload
5.1.6.2 Answer Description for Voice Communications
38/151 !"#$ % &'! % () !* %

The answer is similar to the offer. It acknowledges the media given in the offer. In the example
below, the chosen codec is G711 A law.
table 5.4: Example of Answer
v=0
o=default 1149510698 1149510698 IN IP4 62.97.50.243
s=-
c=IN IP4 62.97.50.243
t=0 0
m=audio 32000 RTP/AVP 8 106
a=sendrecv
a=ptime:30
a=maxptime:120
a=rtpmap:8 PCMA/8000
a=rtpmap:106 telephone-event/8000
a=fmtp:106 0-15
table 5.5: Answer Description

m Media attributes:
- audio: media type
- 6666: port number
- RTP/AVP: transport type
- 8 106: payload type proposed
• 8: G711 A law
• 106: dynamic payload (telephone-event)
5.1.6.3 Offer Description for Fax Communications

The table below shows an example of offer for a fax communication.
table 5.6: Example of Offer for a Fax Communication
v=0
o=default 1149510698 1149510698 IN IP4 62.97.50.243
s=-
c=IN IP4 62.97.50.243
t=0 0
m=image 6666 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:72
a=T38FaxMaxDatagram:316
a=T38FaxUdpEC:t38UDPFEC
a=T38FaxUdpEC:t38UDPRedundancy
table 5.7: Fax Offer Description
!"#$ % &'! % () !* % 39/151
Chapter 5
m Media description
- image: media type
- 6666: port number
- udptl: transport type: fax over UDP
- t38: protocol used
a Fax attributes
5.1.7 SIP Network Elements

5.1.7.1 Terminals
A SIP terminal may be either a SIP phone or a SIP application on a PC equipped with a
microphone and loudspeakers (softphone).
In SIP terminology, terminals are sometimes referred to as User Agents (UAs).
5.1.7.2 Location Entities
Several logical functions are used to locate request recipients.
- Registrar
The registrar is in charge of collecting SIP set registration requests, and then of
transmitting the data to the location server.
For a SIP user, the registration consists in sending a REGISTER request to the server.
This request contains its actual address at a given time as well as the period of validity of
this address.
A user can register under several addresses at the same time. In this case, the call will be
routed to all his physical URLs (forking feature).
- Location Server
The location server contains the database of "logical" URL - "physical" URL (current
address to be actually called) relations. This database can be entered from terminal
registrations, or using other means chosen by the manager.
When a call is established, the INVITE request contains the logical URL of the recipient
user. This URL cannot be used to route the call. On receiving the request, the proxy server
consults the location server to identify the user's actual URL, then routes the request to
this URL.
- Proxy
The proxy is an intermediate entity that operates as a client or a server by transmitting
requests for a User Agent.
The main function of the proxy is routing. On receiving an INVITE request, it transmits the
request either to the recipient set, or to another proxy, which is "closer" to the set.
- Redirect Server
A redirect server is a User Agent that generates 3xx responses to the requests it receives,
supplying the client with new addresses to contact.
Unlike the proxy, the redirect server does not transmit requests.
5.1.7.3 Gateways
Gateways are used to ensure the SIP interface with other signaling protocols and with other
voice transport protocols.
Gateways are identified as SIP User Agents. OmniPCX Office Rich Communication Edition is
a User Agent.
40/151 !"#$ % &'! % () !* %

5.1.7.4 DNS (Domain Name System)

The DNS is a directory system distributed on Internet.
The basic function of a DNS server is to convert domain names into IP addresses. This is
done:
- Through a DNS A request to convert a name into an ipv4 IP address
- Through a DNS AAAA request to convert an name into an ipv6 IP address.
Any SIP entity can use the DNS if the domain part of a URL appears as a name, in order to
convert it into an IP address.
For SIP, the DNS can also be used to resolve protocol type, address and the port number
where requests relating to a given SIP address must be sent. This is done through NAPTR
and DNS SRV requests.
5.1.7.5 NAPTR and DNS SRV
An answer to a NAPTR (Naming Authority Pointer) request for a given domain name consists
of one or several NAPTR records. A NAPTR record contains the supported transport protocol
(UDP, TCP, TLS over TCP, ...) and the replacement name to be used for DNS SRV requests.
The example below shows NAPTR records which could be obtained for a NAPTR request for
the domain "mydomain.com".
Example:
Order pref flags service regexp replacement
IN NAPTR 50 50 “s” “SIP+D2T” “” _sip._tcp.mydomain.com
IN NAPTR 90 50 “s” “SIP+D2U” “” _sip._udp.mydomain.com
The records indicate that the server supports TCP and UDP in that order of preference. Order
specifies the order in which the NAPTR records must be processed to ensure the correct
ordering of rules. Pref specifies the order in which NAPTR records with equal Order values
should be processed, low numbers being processed before high numbers.
Then, the system must make a TCP lookup to get SRV records for “_sip._tcp.mydomain.com”.
An SRV RR answer may be:
Priority Weight Port Target
IN SRV 0 1 5060 server1.mydomain.com
IN SRV 0 2 5060 server2.mydomain.com
The records indicate that the system should send its request to server1. If there is no answer,
server2 should be used. Note that the domain name “mydomain” can change between NAPTR
records and SRV records.
Once the protocol, the port and the domain have been resolved, the system should determine
the IP address of the server. The system performs DNS A query (or AAAA for IPV6) related to
“server1.mydomain.com” to get a list of IP addresses.
The system should try the first SRV RR record. If no answer, the next in the list should be
queried until the end of the list.
If no SRV records were found, the system has to perform DNS A query (or AAAA for IPV6) on
the domain name.
If a port is specified in the URI (example : 1234@mydomain.com:5060), then the system has
!"#$ % &'! % () !* % 41/151
Chapter 5
to perform a DNS A query (or AAAA for IPV6) for this domain.
5.2 Public SIP Trunking
5.2.1 Overview
The following chapters describe the OmniPCX Office Rich Communication Edition connection
to a public provider through SIP trunking.
Public SIP trunking allows connection to a SIP provider with a level of service similar to ISDN.
This includes for example ISDN services such as CLIP/CLIR or fax transport.
The following chapters detail:
- Typical network topologies
- The main features of public SIP trunking
- The public SIP trunking configuration procedure
5.2.2 Topologies
5.2.2.1 Overview
The following section describes several topologies for public SIP trunking.
The described topologies differ in the way the customer private IP network (including the
OmniPCX Office Rich Communication Edition and other telephony IP devices) is connected to
the provider network. This can be through:
- A Multi Protocol Label Switching (MPLS) based IP-VPN network
- The Internet
- A managed IP network
5.2.2.2 Deployment Constraints
The type of connection between the customer IP network and the provider network has an
impact on:
- NAT (Network Address Translation)
NAT is necessary to translate private IP addresses into public IP addresses. Typically, a
router performs level 3 NAT. This means that only IP addresses of IP Packets headers are
translated. SIP requires level 5 NAT so that IP addresses in SIP messages are also
translated.
Before R10.0, OmniPCX Office Rich Communication Edition does not perform level 5 NAT.
According to the network topology, level 5 NAT is performed by the provider Session
Border Controller (SBC) or must be performed by a SIP Application Layer Gateway (SIP
ALG) in the customer border element
As of R10.0, NAT level 5 is supported. for more information on NAT performed on
OmniPCX Office Rich Communication Edition, see: Public SIP Trunking - Feature
Description - Static NAT .
- Outbound proxy
The outbound proxy is the first SIP aware equipment reached by outgoing SIP messages.
42/151 !"#$ % &'! % () !* %

According to the network topology, the provider SBC or the customer border element must
operate as outbound proxy.
- DNS server location
According to the network topology, the DNS server for service and port resolution must be
either in the private network or in the public network.
5.2.2.3 SIP Trunking through an MPLS Network
In this configuration, the customer network is connected to the SIP provider through an MPLS
(Multi Protocol Label Switching) based IP-VPN network.
Figure 5.5: SIP Trunking on an MPLS Network

The SIP provider Session Border Controller (SBC) has a private IP address in the customer
network. This topology requires no equipment performing level 5 NAT in the customer network.
The SIP SBC operates as an outbound proxy for OmniPCX Office Rich Communication
Edition.
If DNS SRV is used, DNS resolution consists in resolving the service/name of the SBC. DNS
servers must belong to the private addressing plan.
5.2.2.4 SIP Trunking in a Managed IP Network
In this configuration, the customer network is connected to the SIP provider through a trusted
managed IP network.
In this case, there are two deployment possibilities:
- Hosted NAT: The piece of equipment on customer premises is a simple router/firewall
performing level 3 and 4 NAT.
• The provider SBC processes SIP signalling and level 5 NAT (Hosted NAT).
• The provider SBC operates as an outbound proxy.
• If DNS SRV is used, DNS resolution consists in resolving the service/name of the
provider SBC. DNS servers belong to the public numbering plan.
!"#$ % &'! % () !* % 43/151
Chapter 5
Figure 5.6: SIP Trunking Topology with Hosted NAT in the Provider Network
- SIP ALG: This topology requires a customer border element performing level 5 NAT (SIP
ALG). The customer border element operates as outbound proxy for OmniPCX Office Rich
Communication Edition.
If DNS SRV is used, DNS resolution consists in resolving the service/name of the
customer border element. DNS servers must belong to customer network.
Figure 5.7: SIP Trunking Topology with SIP ALG in the Customer Border Element
5.2.2.5 SIP Trunking through the Internet

In this case, the customer network is connected to the SIP provider through the Internet.
Hosted NAT or SIP ALG, as described in SIP Trunking in a Managed IP Network , are possible
deployment configurations.
5.2.2.6 Trunking with multiple SIP Registrar
From R8.0 OmniPCX Office Rich Communication Edition is able to register with multiple
registrars. Simultaneous connection to SIP access provider and SIP/GSM gateway is
supported.
44/151 !"#$ % &'! % () !* %

Figure 5.8: Registration with SIP access provider and GSM gateway
5.2.3 Feature Description

5.2.3.1 SIP Trunking Features in a Public Networking Context
The table below contains the features available on public SIP trunking.
table 5.8: Available Features on Public SIP Trunking
Feature Public Networking through a SIP proxy
Direct end-to-end call Not applicable
Call through a SIP proxy Yes
Basic incoming/outgoing voice call Yes
Block dialing Yes
CLIP, CNIP Yes1
CLIR, CNIR Yes 1
COLP, COLR Yes 1
Private/public call differentiation Yes
DTMF transport Yes2
T.38/UDP fax Call Yes3
Fax over G711 with SIP Yes4
Call Forwarding (CFR, CFB) with signaling No
path optimization
Call Forwarding (CFR, CFB) by joining the Yes
two calls (with or without audio path optimiza-
tion)
Call Transfer with signaling path optimization No
!"#$ % &'! % () !* % 45/151
Chapter 5
Feature Public Networking through a SIP proxy

Transfer (consultation, ringing) by joining the Yes
two calls (with or without audio path optimiza-
tion)
Authentication for incoming calls No
Authentication for outgoing calls Yes
Registration (with/without authentication) Yes
Least cost routing Yes
Bandwidth limitation on peer-to-peer basis Yes
Automatic overflow on lack of bandwidth to- Yes
wards a given destination
VoIP route disabling for some subscribers Yes
DDI Yes
Break-in Yes, if numbering plans are compliant
Break-out Yes, if numbering plans are compliant
RTP proxy between a SIP trunk and an IP Yes
phone
RTP proxy between two joined SIP trunks Yes
QoS tickets Yes
Direct RTP between a SIP trunk and an IP Yes
phone
Direct RTP between two joined SIP trunks Yes
DISA Remote Substitution Yes
Codec Pass-Through for SIP phone (in direct Yes
RTP)
Codec Pass-Through for SIP trunks (in direct Yes
RTP)
To describe PBX capability, the following information is included in the Contact header field of
the REGISTER request and in successful responses to OPTIONS requests.
table 5.9: Available User Agent Capabilities Features on Public SIP Trunking
Feature PBX capabilities
Audio Supported
Application Not Supported
1
Provided both SIP stacks are RFC 3323, 3324, 3325 compliant, RFC 4916 (not compliant
with section. 4.5) and OmniPCX Office Rich Communication Edition is a trusted element
2
DTMF transport is transparent to the proxy. When Out-Of-Band (RFC4733) is selected as
DTMF transport mode, the SIP end-element must be RFC 4733 compliant.
3
Fax transport is performed by SIP end-elements and is transparent to the proxy.
4
G711 codecs must be supported end to end.
46/151 !"#$ % &'! % () !* %

Feature PBX capabilities

Data Not Supported
Control Not Supported
Video Yes with codec pass-through enabled
Text Not Supported
Automata Not Supported
Class Personal,business
Duplex Full,half
Mobility Fixed
Description PBX
Event packages Not Supported
Priority Not Supported
Methods INVITE,ACK,CANCEL,BYE,OPTIONS,
PRACK,REFER,NOTIFY,UPDATE
Extensions 100rel, timer, from-change
Schemes Sip
Actor Not Supported
IsFocus Not Supported
5.2.3.2 Standards
The table below contains the RFC used for feature implementation.
table 5.10: Standards used for Feature Implementation
Feature Standard Used
Basic Call RFC 3261, 3264, 4566
Early Media RFC 3262, 3311
Note 1:
Except RFC 3262 section 5
Media RFC 3550, 3551, 3555
Third Party Call Control RFC 3725
Note 2:
As a controller only Flow I are supported.
As a user agent only Flow I, II III are supported.
DNS SRV RFC 3263, 2782, 1034, 1035
Numbering Format RFC 3261, 3966
CLIP RFC 3323, 3324, 3325
CLIR RFC 3325, 3261
!"#$ % &'! % () !* % 47/151
Chapter 5
Feature Standard Used

Connected Identity (COLP) RFC 3323, 3324, 3325, 4916, 3311
Note 3:
Not compliant with RFC 4916 section 4.5
Causes (reject and release) RFC 4497
Authentication of the OmniPCX Office SIP RFC 3261
gateway
Authentication for outgoing calls RFC 2617, 1321
Forward RFC 3261
Hold RFC 3261
Transfer RFC 3261
Fax T.38 Annex D
DTMF Out-Of-Band RFC 4733
In-Band
Symmetric Response Routing RFC 3581
Quality of Service (QoS) RFC 2474, 2475
Miscellaneous RFC 2822, 4028
Interworking RFC 3398
Note 4:
Only QSIG
The Reason Header for the Session Initiation RFC 3326
Protocol Protocol (SIP)
Session Initiation Protocol (SIP) Extension RFC 3327
Header Field for Registering Non-Adjacent
Contacts
An Extension to the Session Initiation Pro- RFC 4244
tocol (SIP) for Request History Information
Registration for Multiple Phone Numbers in RFC 6140
the Session Initiation Protocol (SIP)
Compatibility with 3GPP/TISPAN RFC 3840
The table below contains the RFC list ordered by number.

table 5.11: List of RFC Ordered by Number
RFC RFC Title
1034 Domain names - concepts and facilities
1035 Domain names - implementation and specification
1321 MD5
2474 Definition of Diffserv DS field
2475 An architecture for Diffserv
2616 Hypertext Transfer Protocol -- HTTP/1.1
48/151 !"#$ % &'! % () !* %

RFC RFC Title

2617 HTTP Authentication
2782 DNS RR
2822 Internet message format
3261 SIP
3262 Reliability of provisional responses in SIP (except Section 5)
3263 Locating SIP servers
3264 An offer/answer model with SDP
3311 Session Initiation Protocol (SIP) UPDATE Method
3323 Privacy mechanism for SIP
3324 Short term req for network asserted id
3325 Private extensions to SIP for asserted id
3326 The Reason Header for the Session Initiation Protocol (SIP)
3327 Session Initiation Protocol (SIP) Extension Header Field for Registering
Non-Adjacent Contacts
3398 ISDN user part to SIP mapping (only QSIG)
3515 SIP Refer method (only for Private SIP Trunking, see Private SIP Trunk-
ing - Services - Transfer )
3550 Common Gateway Interface for SIP
3551 IP Payload Compression Using ITU-T V.44 Packet Method
3555 Mime type registration of RTP payload format
3581 Symetric response routing
3605 RTCP attribute in SDP
3725 3rd party call control (1st scenario only) (except Flow IV)
3840 User Agent Capabilities in Session Initiation Protocol (SIP)
3891 Replaces header (only for Private SIP Trunking, see Private SIP Trunk-
ing - Services - Transfer )
3892 Referred-By mechanism (only for Private SIP Trunking, see Private SIP
Trunking - Services - Transfer )
3966 Tel URI for Telephone Numbers
4028 Session timer
4244 An Extension to the Session Initiation Protocol (SIP) for Request History
Information
4497 Interworking between SIP and QSIG
4566 SDP
4733 RTP payload for DTMF digits
4904 Representing Trunk Groups in tel/sip Uniform Resource Identifiers
(URIs)
4916 Connected Identity in the SIP ( not compliant with section 4.5)
!"#$ % &'! % () !* % 49/151
Chapter 5
RFC RFC Title

5009 Private Header (P-Header) Extension to the Session Initiation Protocol
(SIP) for Authorization of Early Media (partially supported)
5626 Managing Client-Initiated Connections in the Session Initiation Protocol
(SIP) (partially supported)
5806 Diversion Indication in SIP
6140 Registration for Multiple Phone Numbers in the Session Initiation Pro-
tocol (SIP)
T.38 Annex D Group 3 fax over IP
5.2.3.3 Ports
UDP is used as transport protocol to carry signalling (SIP), and media (RTP, Fax T.38)
protocols.
Note 1:
The OmniPCX Office supports SIP over UDP protocol only. However, as requested by RFC 3261 section
18.1.1, the PCX switches to TCP if a SIP request message to be transmitted is within 200 bytes of the
path MTU (Maximum Transmission Unit), or if it is larger than 1300 bytes and the path MTU is unknown.
This prevents fragmentation of messages over UDP.
- Ports used for SIP protocol:
1. The PCX is SIP UAC (User Agent Client, that is, when the PCX initiates SIP requests):
• PCX source port to send SIP requests: dynamic port (default) = first free port >
1024 (it can also be programmed to a fixed value, for example, 5060)
• PCX reception port to receive SIP responses: 5060 (default) or dynamic port used
for transmission in case of symmetric port operation (see RFC 3581, rport)
2. The PCX is SIP UAS (SIP User Agent Server, that is, when the PCX returns a SIP
response):
• PCX source port to send SIP responses: use the port in the "sent-by" value of the
SIP request, or the default port 5060, if no port is specified. In case of symmetric
port operation (see RFC 3581, rport), the response must be sent from the same
address and port that the request was received on in order to traverse symmetric
NATs
• PCX reception port to receive SIP requests: 5060 (default)
Note 2:
The default SIP signaling source port is 5060. This value can be changed through OMC (Voice Over
IP >VoIP Parameters >Gateway >SIP Trunk Signal Source Port) to any valid free port (must be
different from 0 and from SIP Phone Signal Source Port).
Any modification of this value requests a system restart. This value must be different from 0 and from
the SIP Phone Signal Source Port value configured in Voice Over IP >VoIP Parameters > SIP
Phone screen.
Port number are symmetrical (source/destination).
- Ports used for RTP protocol: 32000 to 32512 (dynamic allocation)
- Ports used for Fax T.38 protocol: 6666 to 6760 (max. 48 simultaneous fax
communications, only even port numbers)
5.2.3.4 Outbound Proxy
50/151 !"#$ % &'! % () !* %

In the case of public SIP trunking, SIP messages are not sent directly to the SIP gateway but
are first sent to an outbound proxy, which is in charge of routing SIP messages.
According to the network topology, the outbound proxy can be:
- The provider Session Border Controller (SBC)
- The Customer Border Element
For more information, see: Public SIP Trunking - Topologies .
5.2.3.5 DNS SRV
Up to R6.0, the gateway, outbound proxy and registrar IP addresses and port numbers must
be provided statically in Automatic Routing and VoIP Parameters. If there are several
proxies (for example a primary and a secondary proxy), the overflow must be configured
through ARS.
As of R6.1, DNS SRV enables a resolution of service/name.
For an INVITE message, the service/name to resolve is the very next SIP equipment, that is
the outbound proxy.
For example, if the To header of the INVITE message is sip:1234@provider.com, the
service/name to resolve is _sip._udp.provider.com.
A DNS SRV answer may contain several records ordered by priority. Each record contains a
proxy name. If a proxy is unavailable, requests are sent to the second proxy and so on. There
is no need to configure the overflow through ARS.
DNS SRV can also be used for registration. The service/name to resolve is the registrar name.
Note 1:
OmniPCX Office does not perform the DNS A request alone. A DNS A request is always performed
following a DNS SRV request.
The figure: Process for Locating a SIP Server describes the process followed to locate a SIP
server starting from a given URI.
Note 2:
OmniPCX Office does not perform NAPTR requests. The protocol is configurable to UDP or TCP, see
Public SIP Trunking - Configuration procedure - Configuring The Gateway and IP Parameters . For
example, if "domain.com" is the domain name to resolve:
- for TCP, a DNS SRV request for "_sip._tcp.domain.com" is sent
- for UDP, a DNS SRV request for "_sip._udp.domain.com" is sent
!"#$ % &'! % () !* % 51/151
Chapter 5
Figure 5.9: Process for Locating a SIP Server
5.2.3.5.1 DNS Cache

To speed up call set up and also to limit exchanges on the IP network, OmniPCX Office holds
a cache containing DNS RR (SRV and A) records.
52/151 !"#$ % &'! % () !* %

When a service/name to be resolved is present in the cache, the record stored in cache is
used and no DNS request is sent.
A record is saved during the Time To Live (TTL) received in the DNS answer. When the TTL
timer expires for a record, the record is removed from the cache and a subsequent request for
the corresponding service/name results in a DNS request.
If the TTL received in the DNS answer is equal to 0, the corresponding record is not saved in
the cache.
figure: Example of Dialog shows an example of dialog: INVITE 789@prov, sent after TTL
expiration, resulting in a DNS SRV request.
Figure 5.10: Example of Dialog
5.2.3.5.2 Unavailable Proxy List

To avoid sending useless requests to unreachable proxies, OmniPCX Office can hold a list of
unavailable proxies.
An unavailable proxy IP address is stored in the list during a configurable timer. The
unavailable proxy list mechanism can be inhibited by setting this timer to 0.
The administrator can consult and reset the unavailable proxy list through the Web-Based
Tool.
A proxy IP address is put in the unavailable proxy list when:
- A proxy does not answer to an INVITE message before Timer B expiration.
- An ICMP Destination Unreachable message is received.
Timer B = 2Number of Retries * Timer T1
!"#$ % &'! % () !* % 53/151
Chapter 5
By default, Number of Retries = 6, Timer B = 64 * T1

A proxy IP address is removed from the unavailable proxy list when:
- The Unreachable Proxy List Timer expires
- All the proxies corresponding to a given SRV request are in the unavailable proxy list: in
this case, all the proxies corresponding to this SRV request are removed from the list and
messages can be sent again to these proxies after a timer.
- The administrator resets the list through the Web-Based Tool.
To configure the Unreachable Proxy List Timer:
1. In OMC (Expert View), select the System > Voice over IP> VoIP: Parameters > SIP
Trunk tab
2. Review/modify the following attribute:
Unreachable Proxy List Enter the time (in minutes) after which an unavailable proxy
Timer IP address is automatically removed from the unavailable
proxy list.
Enter 0 to inhibit the unavailable proxy list mechanism.
Default value: 10
Max value: 1440 (1 day)
Note:
As of R10.0, this parameter covers the implementation of the sip-
gw_dns_dubl data in the VOIPnwaddr noteworthy address.
5.2.3.6 Registration
Registration is used for mapping between a Uniform Resource Identifier (URI) and a contact
for a user. Registration is also necessary when the IP address is not statically provisioned in
the provider location data base.
As of R8.0, as registration parameters can be configured for each SIP gateway, the OmniPCX
Office can perform registration on one or several Registrar servers.
For a given gateway, a URI corresponding to a system identifier is registered. This identifier
must be configured as requested by the provider and can be for example the installation phone
number.
The registration URI is: sip:system_id@provider_domain
Example:
sip:+497114567110@domain.com;user=phone where is +497114567110 the installation number.
The contact header of the registration request is:
sip:system_id@IPPPX_IP_address
Registration is performed at OmniPCX Office startup and then periodically. The Registered
Expire Time parameter defines the registration periodicity. The default value is 3600 seconds.
The registrar IP address can be defined statically or can be resolved by DNS SRV.
If requested by the registrar, the OmniPCX Office can authenticate itself. Authentication
parameters are sent in a new REGISTER message.
As of R9.2, with the VoIP noteworthy address voip_nw_addr ( value initial_reg_username), the
54/151 !"#$ % &'! % () !* %

private user identity (username) can be sent in the initial REGISTER authorization header.
Note:
By default, nonce caching is enabled in the system. With nonce caching, after receiving the first nonce on
401 message, the private user identity is also presented in initial REGISTER requests sent on timeout to
refresh the registration.
With nonce caching activated, only the very first REGISTER message is sent without any authentication
parameters if initial_reg_username is not activated.
Registration parameters (Registered username, Registrar name, Registrar IP address,
Port, Registered Expire Time) and authentication parameters (Login, Password, Realm)
are configured in OMC (Expert View), in System > Numbering > Automatic Routing
selection > Gateway Parameters.
As of R9.0, OmniPCX Office allows the registration of public Direct Dial In (DDI) numbers
available in the public dialing plan. A maximum of 60 DDI numbers can be registered. Public
DDI registration is configured in OMC (Expert View), in System > Numbering > Automatic
Routing selection > Gateway Parameters.
As of R9.2, the OmniPCX Office allows to configure multiple SIP accounts for the same SIP
domain. Each SIP account has its own registered username and authentication credentials.
Each DDI user uses the appropriate SIP account authentication parameters for incoming and
outgoing calls.
As of R9.2, the Public DDI Registration flag does not exist anymore (in OMC - Expert View:
System > Numbering > Automatic Routing selection > Gateway Parameters.). User
identity registration is achieved with several SIP Accounts management. Further calls to/from
each DDI user uses the authentication configured in SIP Accounts.
As of R10.3, RFC 3327 can be enabled in OMC (Expert View), in System > Numbering >
Automatic Routing selection > Gateway Parameters > Registration. When RFC 3327 is
enabled, the OmniPCX Office sets the option tag “path” in the Supported Header field of all
REGISTER requests sent from OmniPCX Office SIP trunk Gateways.
When a SIP proxy/registrar receives this REGISTER request from the OmniPCX Office, it uses
this option tag “path” to include a SIP Path header while processing this REGISTER request
and its 2xx response. The proxy may add its URI in the path header field.
As of R10.3, RFC 6140 can be enabled in OMC (Expert View), in System > Numbering >
Automatic Routing selection > SIP Accounts, allowing bulk registering of record address.
When the parameter RFC 6140 is enabled for a SIP Account, the REGISTER request from
the OmniPCX Office contains the following information, as described in RFC 6140:
- A specially formatted Contact header containing URI parameter “bnc” with no user portion
- Require and Proxy-Require header fields containing the option tag “gin”
5.2.3.7 Keep Alive Mechanism
The OmniPCX Office supports two keep-alive mechanisms for controlling the up/down status
of the remote gateway.
5.2.3.7.1 "Stateless" Monitoring
At a regular time interval, the PCX sends an IP packet to the remote gateway and monitors the
reception of the awaited answer.
OMC configuration is used to select the keep-alive type of message emitted by the PCX which
can be either an ICMP message (ping) or a SIP Option message.
!"#$ % &'! % () !* % 55/151
Chapter 5
By default, the OmniPCX Office uses ICMP message (ping). A message is sent every 300 s.
Note:
The keep-alive mechanism is inhibited when DNS SRV is enabled.
To configure the keep alive mechanism:
1. By OMC (Expert View), select Numbering > Automatic Routing Selection (ARS) > SIP
Gateway Parameters > Protocol tab
2. Review/modify the following attributes:
Alive Protocol Select ICMP or SIP Option
Alive Timout/s Enter the periodicity (in seconds) of keep alive message
emission.
Enter 0 to inhibit the keep alive mechanism.
Alive Status This read-only information specifies the status of the remote
gateway.
Possible values:
• Alive
• Down
5.2.3.7.2 Active Session Monitoring (During a Call)

In the context of SIP sessions, the OmniPCX Office uses a session timer to check the activty
of the remote party.
To keep the SIP session alive, UAs exchange periodic refreshing requests.
Two refreshing method are available using INVITE (with SDP) or UPDATE (without SDP)
requests in conformity with RFC 4028. A negotiation mechanism allows to define the
appropriate method depending on the context.
To configure the keep alive mechanism for SIP sessions:
1. By OMC (Expert View), select Numbering > Automatic Route Selection (ARS) > SIP
Gateway Parameters
2. Select the gateway to modify and click Details
3. In the Protocol tab, enter the Session Timer value
4. Check or uncheck the UPDATE method enabled to enable/disable the UPDATE method
depending on the context.
5.2.3.8 Authentication
5.2.3.8.1 Incoming Calls
There is no authentication for incoming calls.
Incoming calls are accepted:
- When DNS SRV is not enabled, if the remote gateway IP address matches one IP
Address in the Gateway Parameters.
- When DNS SRV is enabled, if the domain part of the From field of the INVITE message
matches a Domain Name in the Gateway Parameters.
5.2.3.8.2 Outgoing Calls
56/151 !"#$ % &'! % () !* %

If requested by the provider, outgoing calls can authenticate themselves.

The OmniPCX Office supports the Digest authentication scheme (MD5).
Authentication parameters (Login, Password and Realm) are defined in the Gateway
Parameters.
As of R9.2, several SIP accounts can be defined for one gateway. A SIP account is associated
to a range of DDI numbers. The Login, Password and Registered User Name parameters of
the Gateway Parameters page are disabled. These parameters must be configured in the SIP
Account page and associated to a range of DDI numbers. For more information on
configuration and DDI range association, see: Public SIP Trunking - Configuration procedure -
Configuring SIP account .
5.2.3.9 Safety
A mechanism based on a quarantine list (also called blacklist) is used to protect the OmniPCX
Office from DOS (Denial Of Service) type attacks.
IP addresses in the quarantine list are the IP addresses whose messages are ignored for the
duration of the Quarantine Time.
An IP address is automatically placed in the quarantine list when the number of messages
received by the OmniPCX Office from this address has reached a configurable maximum
threshold (Message Peak Number) during a configurable amount of time (Period Peak
Detection).
To configure quarantine parameters:
1. By OMC (Expert View), select System > Voice over IP > VoIP: Parameters > SIP Trunk
tab
2. Review/modify the following parameters:
Message Peak Number Enter a integer between 10 and 250.
Default value: 90
Period Peak Detection Enter the detection period in seconds between 1 and 60.
Default value: 3
Quarantine Time Enter the quarantine time in seconds between 1 and 600.
Default value: 360
When an IP address is placed in quarantine, an alarm, providing this IP address, is generated

in OMC tab History and anomalies > History table.
NMC alarms can be consulted on the NMC application or on sets configured for alarms.
Urgent alarms can be configured via OMC to trigger NMC applications or to send mail
notifications.
The content of the quarantine list can be read from the webdiag tool.
5.2.3.10 Numbering Formats
By default, all numbers transmitted by the OmniPCX Office in SIP messages are in the E.164
canonical form, i.e. +CCnational_number, where CC is the country code.
International numbers have the advantage of being totally unambiguous whatever the type of
call.
!"#$ % &'! % () !* % 57/151
Chapter 5
Some providers do not use number in canonical form.

- The OmniPCX Office can be configured to send calling and called numbers for outgoing
calls in the format required by the provider
- The OmniPCX Office can be configured to interpret calling and called numbers for
incoming calls received in non-canonical forms
The paragraph below present the SIP Public Numbering configuration for outgoing calls and
incoming calls.
The examples shown use the following installation numbers.
table 5.15: Installation Numbers used in the following examples
Installation Number 4567
International Prefix 00
International Code 49
Intercity Prefix 0
Intercity Code 711
Recall Prefix 0

Calling Number Format
The calling number format for outgoing calls applies to:
- The user part of the FROM and P-asserted-identity headers of outgoing INVITE requests.
- The alerted number in a 180 Ringing
- The connected number in a 200 OK
- The divert number in an INVITE
Two parameters are used to configure the calling number format: Calling Format (Outgoing)
and Calling Prefix (Outgoing).
Note:
The typical calling number is a concatenation of installation (system) number and DDI set (extension)
number. The alternative CLIP/COLP number allows to send a specific CLIP/COLP number instead of the
typical CLIP/COLP number, as explained: Alternative CLIP/COLP Numbers .
The table below shows examples of numbers constructed for the different values of the
Calling Format (Outgoing) parameter.
table 5.16: User Part of the From Header according to the Calling Format (Outgoing) Value
Calling Prefix (Outgoing) =
Calling Format (Outgoing) No Calling Prefix (Outgoing)
"+"
Canonical (default value) +497114567110 497114567110
International +00497114567110 00497114567110
National +07114567110 07114567110
National without intercity
+7114567110 7114567110
prefix
58/151 !"#$ % &'! % () !* %

Calling Prefix (Outgoing) =

Calling Format (Outgoing) No Calling Prefix (Outgoing)
"+"
Regional +4567110 4567110
Alternative CLIP/COLP Numbers

There are several types of alternative numbers:
- Alternative access CLIP/COLP number
- Alternative system CLIP number
- Alternative CLIP/COLP number defined at SIP Public Numbering level and applying to
the associated SIP gateway(s)
- Alternative user CLIP/COLP number
For more information on alternative numbers, see: [3] Alternative CLIP and COLP Numbers.
The format type of an alternative number (international, national, ...) can be deduced by
comparing the leading digits of that number to the international or national prefixes configured
in the installation numbers table. The CLIP/COLP number finally passed within the SIP
protocol is the alternative number that has been formatted according to the ARS Calling
Format (Outgoing) and ARS Calling Prefix (Outgoing) parameters.
The table below shows examples of numbers in different cases. In this example, the Calling
Prefix (Outgoing) is set to +. "NOK" means that the configuration is not valid.
table 5.17: Example of CLIP/COLP Numbers in SIP Messages According to Alternative Num-
bers and ARS Calling Format (Outgoing)
Alternative Number Format Type De- ARS Calling Format ID Number Sent in
Configured duced (Outgoing) the SIP Message
0033390671234 International Canonical +33390671234
International 0033390671234
National 0033390671234
NOK
Regional 33390671234
NOK
0390671234 National Canonical +49390671234
National 0390671234
Regional 390671234
NOK
1234 Other Canonical +497111234
National 07111234
Regional 1234
From R8.0, the OmniPCX Office allows to configure an alternative CLIP/COLP for each SIP
gateway. This is a complementary service to the trunk alternative CLIP/COLP number, which
is a global number defined for the whole VoIP trunk. Having separate alternative CLIP/COLP
!"#$ % &'! % () !* % 59/151
Chapter 5
numbers defined at the gateway level can be useful for instance to manage a configuration
with a public SIP operator and a GSM gateway (i.e. when each type of calls requires to force a
specific identity number).
The specified number is used as calling or connected party number information in case of any
public /private external outgoing or incoming call on those SIP accesses.
The Alternative CLIP/COLP for SIP operator and GSM gateway can be configured in System
> Numbering > Automatic Routing Selection > SIP Public Numbering.
From R10.3, the OmniPCX Office allows to select the SIP headers in which the Alternative
CLIP number is inserted. Possible headers are:
- Contact
- From
- P-Asserted-Identity
- P-Preferred-Identity
For more information, see Public SIP Trunking - Configuration procedure - Configuring The
Gateway and IP Parameters .
Note 1:
The selection of Address of Record Registration (AOR) parameter in System > Numbering >
Automatic Routing Selection > Gateway Parameters > Registration overrides the Alternative CLIP
selection.
Note 2:
When Identity secrecy is enabled, the Alternative CLIP configuration for SIP headers
P-Asserted-Identity (PAI), P-Preferred-Identity (PPI) and Contact is not taken into account. These SIP
headers contain the user info part as mentioned in the below table.
60/151 !"#$ % &'! % () !* %

Identity Privacy Alternative RFC 3325 User part in User part in oth-
Secrecy Noteworthy CLIP in FROM Header er SIP Headers
Address FROM Head- (PPI, PAI and
er Contact)
Enabled Anonymous
Enabled AOR (If con-
Disabled figured) or Altern-
0 ative CLIP
Enabled Anonymous
Disabled AOR (If con-
Disabled
figured) or DDI
AOR (If con- AOR (if con-
Enabled Enabled figured) or Altern- figured) or DDI
ative CLIP
Enabled
AOR (If con-
Disabled figured) or Altern-
1 ative CLIP
AOR (If con-
Enabled
figured) or DDI
Disabled
AOR (If con-
Disabled
figured) or DDI
Called Number Format

The called number format for outgoing calls applies to the user part of the Request-URI and
the To header of INVITE messages.
Two parameters are used to configure the called number format for outgoing calls: Called
Format (Outgoing) and Called Prefix (Outgoing).
The table below shows numbers constructed for different dialed number and the different
possible values of Called Format (Outgoing). In the example, the Called Prefix (Outgoing)
is empty.
table 5.19: Called Number in the To Header According to the Called Format (Outgoing)
Value
Called Format (Outgoing) Value
Number National
dialed National / In-
Canonical International without inter- Undefined
ternational
city prefix
3699 497113699 00497113699 07113699 7113699 3699
(number in the
same region)
7111234 497117111234 0049711711123 07117111234 7117111234 7111234
(number in the 4
same region)
!"#$ % &'! % () !* % 61/151
Chapter 5
Called Format (Outgoing) Value

Number National
dialed National / In-
Canonical International without inter- Undefined
ternational
city prefix
07111234 497111234 00497111234 07111234 7111234 07111234
(national num-
ber in the same
region)
06541234 496541234 00496541234 06541234 6541234 06541234
(national num-
ber)
0033123456789 33123456789 0033123456789 0033123456789 33123456789 0033123456789
(international
number)

The format of calling and called numbers for incoming calls can be configured.
The calling (or called) format selected has an impact on the way a received number is
interpreted and transformed. The principle is as follows:
- If a received number begins with the International Prefix or the Intercity Prefix (national
prefix), the Calling Format (Incoming) (or Called Format (Incoming)) is not used
- If a received number does not begin with the international prefix or the national prefix, the
number is considered to be the configured Calling Format (Incoming) (or Called Format
(Incoming)) type.
As of R9.2, a received calling number without prefix can also be considered to be an
International number, depending on the number of digits defined in Cli_inatLn parameter
(System Miscellaneous > Memory > Other Labels).
If all received numbers must be seen as private, the Index of SIP Numbers Format
parameter must be empty in the Gateway parameters.
Calling Number Format
The calling number format for incoming calls concerns the FROM and P-asserted-identity
headers.
Two parameters are used to configure the calling number format for incoming calls: Calling
Format (Incoming) and Calling Prefix (Incoming).
The Calling Prefix (Incoming) is used to distinguish private from public calling numbers:
- If the calling number begins with the Calling Prefix (Incoming), it is considered to be
public
- If the calling number does not begin with the Calling Prefix (Incoming), it is considered to
be private
If the Calling Prefix (Incoming) is empty, all calling numbers are considered public.
The calling format selected has an impact on the way a received number is transformed for
storage and display on the called set.
- If a received number begins with the international prefix or the national prefix, the Calling
62/151 !"#$ % &'! % () !* %

Format (Incoming) is not used

- If a received number does not begin with the International Prefix or the Intercity Prefix
(national prefix), the number is considered to be of the configured Calling Format
(Incoming) type. An inconsistency between a received number and the configured Calling
Format (Incoming) will result in a wrong interpretation of the number type and a wrong
displayed number on the called set.
As of R9.2, a received calling number can be considered as an international number,
depending on its number of digits:
Cli_inatLn noteworthy address defines the minimum number of digits of an international
calling number.
If the received calling number does not begin with the international or intercity prefix, and the
Unknown Calling Format is not selected, then the number of digits of this number can be
tested.
If this number has at least the same number of digits as defined in Cli_inatLn, this number is
considered as an international number.
If Cli_inatLn is set to 0, the test is desactivated.
The table below shows examples of transformation of numbers according to the Calling
Format (Incoming) selected. "NOK" means that the number is misinterpreted.
table 5.20: Calling Number Displayed According to the Configuration Choice
Number re- Calling Format (Incoming) selected
Format ceived in the Canonical /
From header International National Regional Unknown
(+)3312345678
033123456789 33123456789 33123456789
9 0033123456789
NOK NOK NOK
(other country)
Canonical (+)497654321
0497654321 497654321 497654321
with/without (own country, 07654321
leading prefix other region) NOK NOK NOK
(+)497119876
0497119876 0497119876 0497119876
(own country 9876
NOK NOK NOK
and region)
0033123456789
0033123456789 0033123456789 0033123456789 0033123456789
(other country)
00497654321
(own country, 07654321 07654321 07654321
with interna- NOK
tional prefix other region)
00497119876
00497119876
(own country 9876 9876 9876
NOK
and region)
!"#$ % &'! % () !* % 63/151
Chapter 5
Number re- Calling Format (Incoming) selected

Format ceived in the Canonical /
From header International National Regional Unknown
07654321
(own country, 07654321 07654321 07654321 07654321
National with other region)
prefix 07119876
07119876
(own country 9876 9876 9876
NOK
and region)
7654321
007654321 7654321 7654321
(own country, 07654321
NOK NOK NOK
National other region)
without prefix 7119876
007119876 7119876 7119876
(own country 9876
NOK NOK NOK
and region)
00987654321 0987654321
Other 987654321 987654321 987654321
NOK NOK
As of R9.2, when the intercity code in the received calling number is the same as the intercity
code configured in the installation number, the intercity code (aka area code) can be kept
according to the OwnAreaCod noteworthy address. If the OwnAreaCod noteworthy address
is set to 1 the intercity code is kept, if set to 0 the intercity code is not kept. In other words,
OwnAreaCod allows to display a Regional number either in the Regional form or in the
National form.
The table below shows the compatibility between called numbers that are likely to be received
and the configured Called Format (Incoming).
Example:
If the calling numbers sent by the provider in the From header can be in international with prefix, national
with prefix or national without prefix formats, the Called Format (Incoming) parameter must be set to
National.
table 5.21: Compatibilities Between Format of Number Received in From Header and Called
Format (Incoming) Value
Format or Number in the From Header
Canonical or
Called international international National with National
Else
Format with/without with prefix prefix without prefix
(Incoming) prefix
Canonical/ In-
OK OK OK NOK NOK
ternational
National NOK OK OK OK NOK
Regional NOK OK OK NOK OK
DDI NOK NOK NOK NOK OK
Called Number Format
64/151 !"#$ % &'! % () !* %

The called number format for incoming calls concerns the To header.
Two parameters are used to configure the calling number format for incoming calls: Called
Format (Incoming) and Called Prefix (Incoming).
The Called Prefix (Incoming) is used to distinguish private from public called numbers:
- If the called number begins with the Called Prefix (Incoming), it is considered to be public
- If the called number does not begin with the Called Prefix (Incoming), it is considered to
be private
If the Called Prefix (Incoming) is empty, all called numbers are considered to be public.
The called format selected has an impact on the way a received number is interpreted and
sent to the public numbering plan. If the transformed number does not match any entry in the
public numbering plan, the call fails. The principle is as follows:
- If a received number begins with the international prefix or the national prefix, the Called
Format (Incoming) is not used
- If a received number does not begin with the International Prefix or the Intercity Prefix
(national prefix), the number is considered to be of the configured Called Format
(Incoming) type. An inconsistency between received number and the configured Called
Format (Incoming) will result in a wrong interpretation of the number type and a wrong
number sent to the public numbering plan.
The table below shows the numbers sent to the public numbering plan according to the
number received and the called format configured. NOK means that the number is
misinterpreted and that the call fails.
Called Format (Incoming)
Number received in the
From header Canonical/ Interna-
National Regional DDI
tional
(+)49 7114567110 110 NOK NOK 110
(+)00 49 7114567110 110 110 110 110
(+)0 7114567110 110 110 110 110
(+)7114567110 NOK 110 NOK 110
(+)4567110 NOK NOK 110 110
(+)110 NOK NOK NOK 110
5.2.3.11 CLIP/CLIR
5.2.3.11.1 CLIP/CLIR for Outgoing Calls
CLIP for Outgoing Calls
CLIP is provided in both the From and P-asserted-Identity headers of the INVITE method.
Example:
From : "John" <sip:+497114567110@localdomain;user=phone>
P-Asserted-Identity : "John Lennon"
<sip:+497114567110@localdomain;user=phone>
!"#$ % &'! % () !* % 65/151
Chapter 5
CLIR for Outgoing Calls

By default, RFC 3325 is used. If secret identity is required for an outgoing SIP call, the FROM
header of the INVITE message takes a particular syntax with anonymous values and the two
headers "P_Asserted_Identiy" and "Privacy" are added, as shown in the example below.
Example 1:
From : <sip:anonymous@anonymous.invalid>
P-Asserted-Identity : "John" <sip:+497114567110@localdomain;user=phone>
Privacy : user,id
If the provider does not take the P-Asserted-Identity header into account, the RFC 3325
parameter of the Gateway Parameters must be set to No. If secret identity is required for an
outgoing SIP call, the calling party identity is provided in the From header and a Privacy
header is added, as indicated in the example below.
Example 2:
From : "John" <sip:+497114567110@localdomain;user=phone>
Privacy : user,id
5.2.3.11.2 CLIP/CLIR for Incoming Calls

CLIP for Incoming Calls
The calling party number is retrieved from the user part of the SIP URL of:
- The P-Asserted-Identity header, if present in the INVITE message
- The From header if there is no P-Asserted-Identity header
The corresponding calling name is used for SIP name display.
CLIR for Incoming Calls
CLIR applies to an incoming call if the Privacy header is present in the INVITE method,
whatever its value ("id", "user" or "header"). This means that the Privacy header applies,
- To the P-Asserted-Identity header, if present in the INVITE message
- To the From header, if there is no P-Asserted-Identity header
5.2.3.12 Transmission of the diverting number
If the call is a consequence of a diversion, the OmniPCX Office sets the To header to the initial
called number, that is the diverting number. The Request-URI is set to the actual destination of
the request. In addition, the OmniPCX Office will add a diversion info based on Diversion info
configured in OMC (see Public SIP Trunking - Configuration procedure - Configuring The
Gateway and IP Parameters ):
- If History-Info is enabled, the OmniPCX Office adds a History-Info header composed with
the following entries:
• If no secrecy is required from the diverting party, the first entry is set to the diverting
number. A cause 302 (for “Moved Temporarily”) is associated
• The last entry is set to the current request URI
• The OmniPCX Office limits the set of History-Info to two entries, i.e the first forwarding
66/151 !"#$ % &'! % () !* %

hop and the current request URI

• Transmission of the diverting number
- If Diversion is enabled, the OmniPCX Office adds a Diversion header made up of the
following entries:
• The diversion header contains the Request URI of the request prior to the diversion
and the reason tag field associated with the diversion header gives the kind of
diversion: Unconditional for an immediate diversion, user-busy for a busy diversion
• If secrecy is required from the diverting party, the privacy tag is set to "full" in the
Diversion header
5.2.3.13 Connected Identity
5.2.3.13.1 Overview
The SIP protocol intiates sessions providing information on the identities of the two concerned
end implied. The COLP feature, Connected Line Presentation, allows a calling party to be
notified of the callee identity answering a SIP call.
Up to R7.0, the OmniPCX Office only supported a proprietary solution to manage the
COLP/COLR feature, the SIP protocol RFC 3261 being unable to manage COLP information.
As of R7.1, the OmniPCX Office supports a standard solution, built on RFC 4916 and
UPDATE request, to display connected identity relative to basic calls and calls supporting
supplementary services (transfer in conversation, transfer in ringing, dynamic routing, CFU,
CFB, CFNR, call pickup and monitoring).
Depending on the compatibilty of the remote party (OmniPCX Office or third party products),
with the RFC 4916 protocol OmniPCX Office can operate proprietary and standard solutions to
manage COLP/COLR information.
If the remote party does not support RFC 4916 and the UPDATE request, the OmniPCX Office
only applies the proprietary solution to manage COLP/COLR information.
If the remote party supports RFC 4916 and the UPDATE request, the OmniPCX Office applies
both the proprietary and RFC 4916 solutions to manage COLP/COLR information.
5.2.3.13.2 Receiving Connected Identity
When receiving the COLP identity using RFC 4916 supporting the UPDATE request, the
OmniPCX Office can update the connected identity sent to the caller user device in the
folllowing operation contexts:
- Private and Public SIP trunking with third party proxy
- Heterogeneous, homogeneous, homogeneous transfer and homogeneous forward mode
5.2.3.13.3 Sending Connected Identity
When use of RFC 4916 is possible, the OmniPCX Office sends updated connected identity
with the following activated services:
- Immediate forward
- Dynamic routing
- Call transfer in conversation
- Call transfer in ringing
- Transit call
!"#$ % &'! % () !* % 67/151
Chapter 5
The connected identity can be sent in the following operation contexts:

- Private and Public SIP trunking with third party proxy
- Heterogeneous, homogeneous, homogeneous transfer and homogeneous forward mode
5.2.3.13.4 Prerequisite
The management of the COLP/COLR (with the open solution compatible with RFC 4916)
requires the activation of the UPDATE method (see Public SIP Trunking - Configuration
procedure - Do not Allow Update ).
5.2.3.13.5 COLP/COLR for Outgoing Calls (Proprietary Solution)
COLP for Outgoing Calls
COLP is retrieved from the user part of the SIP URL of:
- the P-Asserted-Identity header, if present in the 200.OK response or 180 Ringing message
- the Contact header, if there is no P-Asserted-Identity header
COLR for Outgoing Calls
COLR applies if the Privacy header is present in the 200.OK answer or the 180 Ringing
message, whatever its value ("id", "user" or "header"). This means that the Privacy header
applies to the P-Asserted-Identity header, if present, or to the Contact header.
5.2.3.13.6 COLP/COLR for Incoming Calls (Proprietary Solution)
COLP for Incoming Calls
COLP is provided in the Contact and P-Asserted-Identity headers of the 200.OK and
180.Ringing messages.
Example:
Contact : "John" <sip:+497114567110@localdomain;user=phone>
COLR for Incoming Calls

If COLR is required for an incoming call, the Privacy header value is set to "id".
Example:
Contact : "John" <sip:+497114567110@localdomain;user=phone>
Privacy : user,id
5.2.3.14 DTMF
The OmniPCX Office supports two modes for DTMF transmission:
- Out-Of-Band (RFC4733) mode. Payload is negotiated with the provider.
- In-Band mode
The mode used for DTMF digit detection and transmission is configured in the SIP Gateway
68/151 !"#$ % &'! % () !* %

Parameters.
Note:
The OmniPCX Office does not support the INFO method DTMF transmission modes.
5.2.3.14.1 Out-Of-Band (RFC4733) DTMF

DTMF for Outgoing Calls
A dynamic payload X is proposed in the SDP part of the INVITE message.
Example:
m=audio 32082 RTP/AVP 0 8 106
The OmniPCX Office behavior depends on the contents of the SDP part of the 200.OK
response:
- Payload X: use of RFC 4733 with payload X for emission and reception
- Payload Y: use of RFC 4733 with payload Y for DTMF emission and payload X for DTMF
reception
- None: no DTMF
To modifty the dynamic payload value:
1. In OMC (Expert View), select System > Voice Over IP > VoIP: Parameters > Codecs tab
2. Under Dynamic Payload, review/modify the following parameters:
DTMF This field defines the dynamic payload for DTMF used for SIP
trunk and IP sets. On IP trunks, DTMF is always exchanged
according to the RFC4733 standard (RTP with a specific pay-
load type).
In the drop-down menu, select the dynamic payload value.
The value range is from 96 to 122
The default value is 106
G722.2 This field defines the dynamic payload for G.722.2 used for
SIP trunk and IP sets. The RTP Payload used for G.722.2 is
in the dynamic range specified by RFC3551.
The value range is from 96 to 127
The default value is 117
Note 1:
The values for G722.2 Dynamic payload and the DTMF Dynamic payload MUST be different. In case
of overlap, the OMC displays an error message on validation (when clicking the OK button).
3. Confirm your entries
Note 2:
As of R10.0, the DtmfDynPL noteworthy address must not be used anymore.
DTMF for Incoming Calls

DTMF transmission depends on the contents of the SDP part of the INVITE method:
- Payload Y: agreement on payload Y in the 200.OK response, use of payload Y
!"#$ % &'! % () !* % 69/151
Chapter 5
- None: No payload in the 200.OK response, no DTMF

In addition as of R9.2, the reception of InBand DTMF digit on SIP trunk depends on the
SIPdtmflnB noteworthy address:
- If the SIPdtmflnB noteworthy address is set to 0, DTMF digits are discarded
- If the SIPdtmflnB noteworthy address is set to 1, DTMF digits are taken into account
1. In OMC (Expert View), select: System > System Miscellaneous > Memory Read/Write >
Other Labels
2. Select SIPdtmflnB:
SIPdtmflnB Enter the value of this noteworthy address:
• 0: DTMF digits are discarded
• 1: DTMF digits are taken into account
5.2.3.14.2 In-Band DTMF

When DTMF is configured as In-Band for a SIP gateway, DTMF digit detection and
transmission is done in In-Band mode over the SIP Trunk associated to this SIP Gateway.
When DTMF is configured as In-Band for a SIP gateway, RTP proxy, Direct RTP and VAD
configuration are disabled dynamically for all calls associated with this SIP gateway, except for
transit calls where In-Band DTMF is configured in both SIP gateways involved.
In a transit call scenario where In-Band DTMF is configured in both SIP gateways involved,
direct RTP is possible. Hence, in this scenario, RTP proxy and Direct RTP are not disabled
dynamically and the global Direct RTP parameter configured in VoIP Parameters is used. If
Direct RTP is disabled in VoIP Parameters, RTP proxy is enabled for the transit call.
For proper In-Band DTMF reception/transmission, it is recommended to use G711 codec.
When other codecs are used, In-Band DTMF tone may not be properly detected (potential
wrong DTMF digits detection) at receiving end.
In-Band DTMF call scenario with non IP phone subscribers
In case of outgoing call from a non IP phone subscriber, if In-Band DTMF is enabled, the
OmniPCX Office does not support RTP Telephonic event payload type for both sending and
receiving DTMF on the associated SIP gateway. SDP Offer from OmniPCX Office contains no
Telephonic Event / Specific DTMF RTP Payload. DTMF are sent and received only in In-Band
mode.
In case of incoming call to a non IP Subscriber, SDP Answer sent by OmniPCX Office contains
no DTMF Telephonic event type. DTMF are sent / received only in In-Band mode.
In-Band DTMF support for analog access
Before R10.3, In-Band or Out-Of-Band mode used for DTMF from/to a set is configured in the
SIP Gateway Parameters.
DTMF parameter configuration controls DTMF reception/transmission for all the sets
connected to the OmniPCX Office. If In-Band DTMF is selected for a SIP Gateway, DTMF is
sent or received in In-Band mode from/to a set in OmniPCX Office via this SIP Gateway.
As of R10.3, In-Band or Out-Of-Band mode used for DTMF from/to an analog set is
configured in the Feature Rights (Part3) and in the SIP Gateway Parameters.
In case of machine to machine communications through DTMF, some media gateways are not
able to rebuild correct DTMF from RFC4733 events (with possible loss or misinterpretation of
70/151 !"#$ % &'! % () !* %

the DTMF digits).

The table below gives the DTMF management for analog set in case of incoming and outgoing
calls based on the configuration parameters In-Band DTMF of analog set and DTMF in SIP
Gateway.
In-Band DTMF DTMF configuration
DTMF Transmission mode
for Analog access in Gateway Parameters
In-Band In-Band
Enabled
Out-Of-Band In-Band
In-Band In-Band
Disabled
Out-Of-Band Out-Of-Band
In-Band DTMF call scenario with SIP phone and IP phone subscribers
In case of SIP Phones and IP Phone (Alcatel-Lucent 8 series, IP Premium DeskPhones), If
In-Band DTMF is configured, the OmniPCX Office disables RTP proxy mode and Direct RTP
support internally for all the calls associated with the corresponding SIP Gateway and IP
Phone Subscribers.
In case of external outgoing call from SIP phone via SIP trunk, DTMF from SIP Phone/IP sets
is received in Out-Of-Band mode, as RTP Telephonic event payload type, and the OmniPCX
Office sends the same DTMF in In-Band mode via SIP trunk. SDP Answer to SIP Phone
contains an RTP Telephonic event payload type for DTMF exchange.
In case of external incoming call from SIP trunk to SIP phone, DTMF are received in In-Band
mode via SIP trunk and same DTMF are sent in Out-Of-Band mode as RTP Telephonic event
payload to the corresponding SIP Phone subscriber. Hence, SDP Offers to SIP Phones
contains RTP Telephonic event payload type.
5.2.3.15 IP QoS
The OmniPCX Office provides the same tagging value for signaling and media flows.The
tagging value is written in the DS (Differentiated Services) field of the IP Packet. DS field (see
RFC 2474) is a replacement header field which supersedes the former definition of the IPv4
TOS byte (Type of Service).
Default DS tagging value is 46 (10111000 DIFFSERV_PHB_EF - Expedited Forwarding
forwarding). It can be configured using OMC (System > Voice over IP > VoIP Parameters >
General > IP Quality of Service or System > Voice over IP> VoIP: Parameters > SIP Trunk
> IP Quality of Service).
5.2.3.16 Codec/Framing Negotiation
The following codecs are available:
- G711: This is a high bit rate ITU standard codec. It is based on PCM (Pulse Code
Modulation) at a sampling rate of 8kHz. The frequency bandwidth is 300 Hz – 3.4 kHz. It
uses no compression and it is the same codec used by the PSTN network and ISDN lines.
Each sample is coded with 8 bits A-law (in Europe) or with 7 bits mu-law (in the US), which
produces respectively a 64kbps or 56kbps bit stream. Narrowband MOS (Mean Opinion
Score) = 4.1 – Coding Delay = 1ms – Complexity << 1 MIPS.
- G722 is an ITU-T standard 7 kHz wideband speech codec based on sub-band adaptive
differential pulse code modulation (SB-ADPCM) within a bit rate of 48, 56 or 64 kbit/s. It
offers a significant improvement in speech quality over older narrowband codecs such as
!"#$ % &'! % () !* % 71/151
Chapter 5
G.711. The G.722 codec samples audio data at a rate of 16 kHz (using 14 bits), double
that of traditional telephony interfaces, which results in superior audio quality and clarity.
Wideband MOS (Mean Opinion Score) = 3.9 - Coding Delay = 1.5ms – Complexity = 10
MIPS.
- G723.1: G723.1 is recommended for very low bit rates. It is a dual rate coder (5.3 kbps or
6.3 kbps) based on ACELP (Algebraic Code Excited Linear Prediction) for the low-rate
coder and based on MP-MLQ (MultiPulse – Maximum Likelihood Quantization) for the high
rate coder. The bandwidth is 3.1 kHz in both cases. The lower bit rate has a poorer quality
compared to higher bit rate, but provides systems designers with additional flexibility.
Narrowband MOS (Mean Opinion Score) = 3.8 – Coding Delay = 67ms – 97ms –
- G729A: The G729a recommendation targets very low bit rate. This is one of the most
recent and promising codec standardized by the ITU. It belongs to the G729 family, and as
such, is a competitor to G723.1. It is based on CS-ACELP (Conjugate Structure –
Algebraic Code Excited Linear Prediction), and produces 8 kbps bit stream from a 3.1 kHz
bandwidth. The bit rate is slightly higher than with G723.1 but the delay is significantly
lower. Narrowband MOS (Mean Opinion Score) = 3.7 – Coding Delay = 25 ms – 35 ms –
For the G711 codec, VoIP bandwidth can be reduced by 35% by enabling voice activity
detection (check the box With silence detection (VAD)).
Note 1:
G729AB, Annex B is supported when the box With silence detection (VAD) is selected.
The table: Gateway Bandwidth indicates the codec options available for different framing
requirements.
table 5.26: Gateway Bandwidth
CODEC Framing (in milliseconds)
G711 20, 30 (default), 60
G722 20, 30 (default), 60
G723.1 30 (default), 60, 90, 120
G729a 20, 30 (default), 40, 50, 60, 90, 120
Note 2:
You cannot use framing value 90 ms or 120 ms for codecs G.723.1 and G.729A when IP Touch sets are
connected to OmniPCX Office.
The codec and framing used for a communication are the result of a negotiation between the
OmniPCX Office and the remote party.
The OmniPCX Office behavior depends on the Codec/Framing value in the SIP Gateway
Parameters window (Media tab)
In a default configuration (Codec/Framing set to default), the codec/framing to use is
selected in the default codecs list according to the codec priority order (Voice Over IP > VoIP:
Parameters > Codecs).
If the Codec/Framing parameter is set to a specific value, OmniPCX Office uses only this
configured value. If this codec/framing is not supported by the remote party, the call fails.
Note 3:
Noteworthy addresses can be used for specific behavior. For more information, see Public SIP Trunking -
72/151 !"#$ % &'! % () !* %

Configuration procedure - Appendix: Noteworthy Addresses for Codec/Framing Negotiation .

Codec/Framing set to default
1. The OmniPCX Office sends the default list of supported codec/framing in the SDP part of
the INVITE message
2. The called party answers with one codec/framing in the SDP part of the 200.OK response
3. The OmniPCX Office acknowledges this response
Codec/Framing Set to a Specific Value
1. The OmniPCX Office sends the configured codec/framing (e.g. G723_30) in the SDP part
of the INVITE message.
2. The called party either accepts or rejects the call.
Codec/Framing Set to default
First Case
1. The caller sends a list of codec/framing in the SDP part of the INVITE message.
2. The OmniPCX Office select the first supported codec/framing in the list.
Second Case
1. The caller sends a specific codec/framing in the SDP part of the INVITE message.
2. If the proposed codec/framing is supported by OmniPCX Office Rich Communication
Edition, the call is accepted. Otherwise, the call is rejected.
Codec/Framing Set to a Specific Value
First Case
1. The caller sends a list of codec/framing in the SDP part of the INVITE message.
2. If the codec/framing configured for OmniPCX Office Rich Communication Edition is in the
list proposed by the caller, the call is accepted. Otherwise, the call is rejected.
Second Case
1. The caller sends a specific codec/framing in the SDP part of the INVITE message.
2. If the proposed codec/framing matches the codec/framing configured for OmniPCX Office,
the call is accepted. Otherwise, the call is rejected.
5.2.3.16.3 Music On Hold and preannouncement (as of R9.0)
The G711 Codec for Music on Hold and preannouncement parameter allows using in
priority G711 codec to play:
- Music on Hold on SIP trunk, when:
• Codec/Framing set to default
• The codec list defined by noteworthy address AlCodLst (see Public SIP Trunking -
Configuration procedure - Appendix: Noteworthy Addresses for Codec/Framing
Negotiation ) contains G711 codec.
!"#$ % &'! % () !* % 73/151
Chapter 5
- Preannouncement on SIP trunk incoming calls.

5.2.3.17 Codec Pass-Through
PCX behavior depends on the Codec/Framing value in the SIP Gateway Parameters window
(Media tab) refer to Codec/Framing Negotiation .
Before R8.1, SIP gateways cannot communicate if:
- Using an audio codec unknown to the system
- Trying to connect to a medium unknown to the system
As of R8.1, when direct RTP is enabled, the Codec Pass-Through for SIP trunks system
VoIP parameter allows to disable this restriction.
Note 1:
The Codec Pass-Through for SIP phones operates in the same manner, but applies to SIP phones
only.
The Codec Pass-Through for SIP trunks parameter applies to gateways configured with the
codec parameter set to default. It does not apply to gateways configured with a specific audio
codec.
When the Codec Pass-Through for SIP trunks is set to Yes, a SIP gateway can establish
calls with media unknown to the system.
However, the SIP gateway cannot establish such a call:
- When direct RTP is disabled
- When the system is involved in the call, that is to say, when a DSP is required
A DSP is required in the following cases:
• When the addition of an RTP flow is necessary (for conferences, or barge-in)
• With Music on hold (MOH), when greeting messages are needed
• When a TDM phone is involved in the conversation
This feature is available for calls between:
- Two SIP gateways
- A SIP Gateway to a SIP set which supports more media than the system does, provided its
Codec Pass-Through for SIP phones parameter is set to Yes
To avoid a communication cut after some actions (hold, transfer, …), a SIP set involved in a
codec pass-through communication must manage, at least, one codec supported by OmniPCX
Office.
This feature is configured in OMC (Voice over IP > VoIP Parameters > General > RTP
Direct:
- Validate the Codec Pass-Through for SIP trunks check box to enable codec
pass-through between SIP gateways
- Validate the Codec Pass-Through for SIP phones check box to enable codec
pass-through on SIP phones
The following table provides an overview of media filtering according to ARS and Codec
Pass-Through parameter configuration.
74/151 !"#$ % &'! % () !* %

ARS codec on gate- Incoming media Media filtering result Media filtering result
way gateway offer with codec pass- with codec pass-
through disabled through enabled
G711 Audio (G722, G711), Audio (G711) Audio (G711)
Video
G723 Audio (G711), Video Call rejected Call rejected
Default Audio (G722, G711), Audio (G711) Audio (G722, G711),
Video Video
Default Audio (GSM), Video Call rejected Audio (GSM), Video
Note 2:
Even when theoretically codec filtering makes it possible, a call can still be rejected or restricted by the
called party capabilities.
5.2.3.18 Early Media using Prack

5.2.3.18.1 Early media
Early media refers to media that are exchanged before the called user accepts a specific
session. Typical examples of early media generated by the callee are ringing tone and
announcements.
Within a dialog, early media occurs from the moment the initial INVITE request is sent until the
User Agent Server (UAS) generates a final response. It may be unidirectional or bidirectional,
and can be generated by the caller, the callee, or both.
SIP uses the offer/answer model to negotiate session parameters. One of the user agents -
the offerer - prepares a session description, called the offer.
The other user agent - the answerer - responds with another session description, called the
answer. This two-way handshake allows both user agents to agree upon the session
parameters to be used to exchange media. The offer/answer model decouples the
offer/answer exchange from the messages used to transport the session descriptions.
For example, the offer can be sent in an INVITE request and the answer can be received in
the 200 (OK) response for this INVITE, or, alternatively, the offer can be sent in the 200 (OK)
for an empty INVITE request and the answer can be sent in the ACK response. When reliable
provisional responses and UPDATE requests are used, there are many more possible ways to
exchange offers and answers.
5.2.3.18.2 Prack
The Session Initiation Protocol (SIP) is a request- response protocol for initiating and
managing communications sessions. SIP defines two types of responses, provisional and final.
Final responses convey the result of the processing of the request, and are sent in a reliable
manner. Provisional responses providing information on the progress of the request
processing are not sent in a reliable manner.
The reliability mechanism works by mirroring the current reliability mechanisms for 2xx final
responses to the INVITE message. These requests are transmitted periodically by the
Transaction User (TU) until a separate transaction, ACK is received indicating reception of the
2xx by the UAC.
The PRACK request plays the same role as ACK message, but for provisional responses.
There is an important difference, however. PRACK is a standard SIP message, like BYE. As
!"#$ % &'! % () !* % 75/151
Chapter 5
such, its own reliability is ensured hop-by-hop through each stateful proxy. Also like BYE, but
unlike ACK, PRACK has its own response. If this was not the case, the PRACK message
could not traverse proxy servers.
As of R10.0, the PRACK method can be disabled.
When disabled:
- SIP trunk gateways never send or receive PRACK methods.
- The 100rel option tag in the SUPPORT header and PRACK method in the Allow header
are removed in all SIP requests and responses.
- All incoming INVITE requests containing the 100rel option tag in a header are rejected with
the 420 error code (according to RFC3262).
To enable/disable the PRACK method for a SIP gateway:
1. In OMC (Expert View), select System > Numbering > Automatic Routing Selection >
Gateway Parameters
3. In the Protocol tab, check or uncheck the PRACK method enabled box
5.2.3.18.3 OmniPCX Office and Early Media
The OmniPCX Office supports Early media with PRACK not only on basic calls but also on
services such as heterogeneous External diversion and break out calls.
When the OmniPCX Office initiates a dialog without SDP OFFER, and receives a reliable
provisional response with SDP OFFER, it generates an SDP ANSWER in the PRACK, and
establishes the media communication before call connection. Otherwise, the OmniPCX Office
expects the SDP OFFER in the final response to the INVITE, then it provides the SDP
ANSWER in the ACK answer.
As of R9.0, OmniPCX Office implements the mechanism of P-Early media to control the
establishment of early media flows. By default, the feature is disabled.
To enable/disable the P-Early media for a SIP gateway:
Gateway Parameters
3. In the Protocol tab, check or uncheck the “P-Early-Media for SIP trunk box (disabled by
default)
Note:
As of R10.0, the pearlymedia noteworthy address must not be used anymore.
5.2.3.18.4 Example of Early Media with Prack

In the example, PCX 2 is configured in a public trunk with ISDN, PCX 1 and PCX 2 are
configured with private SIP trunk.
If PCX 2 receives an INVITE with SDP OFFER from PCX 1, PCX 2 makes an outgoing call to
the public ISDN trunk. If the public trunk makes early media, then PCX 2 must send SDP
answer in reliable 183 responses and establish media communication before call connection
76/151 !"#$ % &'! % () !* %

(see figure: Early Media with Prack ).
Figure 5.11: Early Media with Prack
5.2.3.19 Native G722 support

As of R9.1, the OmniPCX Office natively supports the G.722 codec, without the need for any
codec pass-through in direct RTP mode for SIP phones and SIP Trunks (refer to Codec
Pass-Through ).
The G.722 codec is supported on the following sets:
- 8082 My IC Phone
- 4135 IP Conference Phone
- SIP phones
Note 1:
G722.2 can also be supported with Open SIP Phone and Basic SIP Phone according to the type of set.
New values have been introduced in the ARS table for the Codec/Framing field:
- G722/G711_20: this value corresponds to the codec list: G722.2, G722, G711.a, G711.µ
with this priority order and with a framing of 20ms.
For these values, the codec to use is negotiated from actual capabilities. The G722 codec is
!"#$ % &'! % () !* % 77/151
Chapter 5
used in priority, G711 is a second choice, used when the G722 codec is not supported by the
remote Gateway, or when the call is initiated or sent to a non G722 compliant access (non SIP
access or SIP access that does not support G722) on the OmniPCX Office.
The SDP offers and responses sent by the OmniPCX Office are built according to the following
algorithm:
- For SDP offers received from a SIP set or a SIP trunk (transit call)
• If the ARS rule is configured with “G722/G711_XX”, the codecs transmitted are the
codecs common to the two parties (if both G722 and G711 are transmitted, G722 is
placed before G711). The Ptime value negotiated is the one which is in the ARS table
(here replaced by “XX”)
• If the ARS table contains “Default”, the codecs transmitted are the codecs common to
the two parties in the order specified by the default list. The Ptime value is not forced.
- For SDP answers transmitted by the OmniPCX Office Rich Communication Edition
• If the ARS rule is configured with “G722/G711_XX”
• If the offer received contains the G722 codec, the only codec transmitted in the
answer is G722.
• If the offer received contains the G711 codec and does not contain G722 codec,
the only codec transmitted in the answer is G711.
• If the offer received does not contain a G722 or G711 codec, the call is rejected.
• If the ARS table contains “Default”
• If the call is sent to a non SIP phone, the codec transmitted is the first common
codec between the codecs of the offer and those that are in the default table. If
there is no common codec, the call is rejected.
• If the call is sent to a SIP phone, the set transmits the selected codec and the
OmniPCX Office selects the first codec in the SDP answer of the SIP phone.
Note 2:
This algorithm is also valid for transit calls.
Note 3:
For non SIP phones, neither G722 nor G722.2 codecs are used in SDP offers or in SDP responses.
5.2.3.20 Update Method

The UPDATE method allows a client to update the parameters of a session (such as the set of
media streams and their codecs) with no impact on the state of a dialog. In this sense, it is like
a re-INVITE message, but unlike re-INVITE, it can be sent before the initial INVITE has been
completed. This makes it very useful for updating session parameters within early dialogs.
The OmniPCX Office supports the UPDATE method allowing to change media streams
without impact on the dialog state.
When the OmniPCX Office acts as a UAC, it always includes an Allow header field in the
INVITE request, listing the method UPDATE, to indicate its ability to receive an UPDATE
request.
In a transit scenario, when the OmniPCX Office (as UAS) receives an INVITE request for a
new dialog, it always includes an Allow header field that lists the UPDATE method in its
response, in reliable and unreliable provisional responses. The remote party is informed that
the OmniPCX Office can receive an UPDATE request at any time.
When the OmniPCX Office acts as a UAS, it always includes an Allow header field listing the
UPDATE method in its 200 OK response to the INVITE transaction.
78/151 !"#$ % &'! % () !* %

By default, UPDATE method is enabled. To disable it:).

1. By OMC (Expert View), select Numbering > Automatic Routing Selection (ARS) > SIP
Gateway Parameters
2. Select the gateway and click Details
3. In the Protocol tab, uncheck the UPDATE method enabled box
Figure 5.12: Update Method Example

In this example, the PCX makes an outgoing call to softswitch and establishes early media. If
the PCX receives an UPDATE request with SDP OFFER, it responds with an SDP ANSWER
in 200 OK and then establishes the new RTP communication based on the UPDATE method
media negotiation. The caller or callee identity may be also updated by the UPDATE method.
Note:
UPDATE method is also used as a refresh method to determine if a SIP session is still active, see Public
SIP Trunking - Configuration procedure - Session Timer .
5.2.3.21 Fax over IP (FoIP)

The OmniPCX Office supports two methods for fax transmission over a Private or Public SIP
Trunk:
- T.38 Annex D: this fax-relay method is today the best-adapted for FoIP communications.
T.38 is standard-based, offers a robust redundancy mechanism and consumes the least
amount of bandwidth. It is therefore the recommended setting for PCX
- Fax over G711: this is an alternate FoIP method introduced in OmniPCX Office R7.1.
!"#$ % &'! % () !* % 79/151
Chapter 5
G711 fax pass-through has a reputation for simplicity but has some major drawbacks in
comparison to T.38. For PCX, it is only recommended to select it when T.38 is not
supported on the network
Note:
some known inconveniences of the fax over G711 (pass-through method) are listed below:
• It is not standard based and hence implementation can be different depending on the vendor
• Bandwidth usage with G711 codec is high
• As with many vendors, the PCX implementation does not offer packet redundancy. Fax
transmission is then very dependent on end-to-end performance of the IP network and reliability
is very sensible to packet loss
• End-to-end G711 transparency must be guaranteed, that means no transcoding of the media
channel is allowed through the IP network
• Voice Activity Detection (VAD) must be disabled on both sides of the fax call
The maximal speed of a fax communication with PowerCPU EE VoIP DSP's is 9600 bps.
5.2.3.21.1 Selection of FoIP mode on PCX
The choice of the Fax protocol, T.38 or Fax over G711, is defined for each gateway via the
OMC (ARS/Gateway parameters/Fax parameter). For the configuration procedure, see Public
SIP Trunking - Configuration procedure - Configuring the Gateway Parameters .
5.2.3.21.2 FoIP Service
No matter the OMC setting (T.38 or G711), a SIP fax call on PCX is always established first as
a normal voice call transmitting an RTP flow. After some seconds, upon detection of the fax
tone, the FoIP service is then triggered to operate the selected T.38 or G711 choice (see Fax
T.38 Annex D or Fax over G711 ).
5.2.3.21.3 Fax T.38 Annex D
When the T.38 protocol is selected, RTP voice channels are closed and T.38 sessions are
initialized to transmit or receive Internet Fax packets (IFP). The SIP GW attached to the called
fax is due to trigger the FoIP service by sending a SIP/T.38 Re-Invite over the running call.
OmniPCX Office only allows T.38 sessions over UDP, see Ports
In order to ensure the reliability of the UDP transmission, the packets are sent several times to
ensure that the information reaches its destination. This operation is called "UDP
Redundancy". In order to reduce bandwidth use, an operation (framing) allows the
concatenation of packets of the same type: see Configuring H323 Gateway - Hardware
configuration - Configuration of T38 parameters for Fax over IP (optional)
As of R9.1, the Error Correction Mode (ECM) is supported for fax over IP using T.38. The ECM
procedure is an end-to-end process, that is to say it is managed by the fax machines involved
in the call. As of R10.0, by default, the ECM mode is disabled, but can be enabled, refer to
Private SIP Trunking - Hardware configuration - Configuration of T38 Parameters for Fax over
IP (optional) .
5.2.3.21.4 Fax over G711
When Fax over G711 is selected, RTP voice channels are maintained but if current codec is
G729A or G723, it is renegotiated to G711.
Fax over G711 is not compatible with Voice Activity Detection (VAD) which is a mechanism
used to save bandwidth during VoIP calls. Therefore, the PCX supports the "silenceSupp"
80/151 !"#$ % &'! % () !* %

attribute in the SDP part of the SIP message in order to dynamically disable VAD during the
Fax over G711 media session.
This attribute is used to request the other side to disable VAD. It works as follows:
- Case of an incoming fax call: the PCX detects the fax tone in the RTP stream and sends
Re-Invite to renegotiate the media session characteristics with "silenceSupp" attribute set
to "off" in order to ask the remote side to disable VAD
• If the PCX receives a response containing "silenceSupp" attribute set to "off", it means
that remote side has disabled VAD and then the PCX disables VAD also. This is the
normal mode of operation
• If the PCX receives a response which does not contain "silenceSupp" attribute set to
"off, then VAD remains active on the PCX side. In that case fax over G.711 is not
guaranteed when VAD on both ends is not disabled
- Case of an outgoing fax call: remote side (called side) should detect fax tone. The PCX
expects to receive a Re-Invite from the remote side with "silenceSupp" attribute set to "off"
• If the PCX receives a Re-Invite request containing "silenceSupp" attribute set to "off", it
means that remote side requests to disable VAD, then the PCX disables VAD and
sends a response containing "silenceSupp" attribute set to "off" to acknowledge the
request. This is the normal mode of operation
• If the PCX receives a request which does not contain "silenceSupp" attribute set to "off,
then VAD remains active on the PCX side. In that case, fax over G.711 is not
guaranteed when VAD on both ends is not disabled
Recommendation for deployment of Fax over G711:
- If remote side supports "silenceSupp" attribute => this is the expected mode of operation
- If remote side does not support "silenceSupp" attribute => disable VAD on both the remote
side and the PCX => Fax over G711 works but VoIP calls will not benefit from bandwidth
optimization
- If remote side does not support "silenceSupp" attribute and it is not possible to disable
VAD on remote side => fax over G.711 is not guaranteed as VAD on both ends is not
disabled
To enable fax over G.711 for a SIP subscriber, the following PBX configuration directives must
be followed:
- “Fax 2/3” services associated to the subscriber must be enabled (in OMC, Subscriber
>Services)
- VoIP VAD must be disabled (in OMC, Voice Over IP >DSP)
- If a SIP trunk is configured on the PBX, Fax over G.711 must be configured in gateway
parameters in the ARS (in OMC, Numbering >Automatic Route Selection/Gateway
Parameters). The remote gateway MUST support fax over G.711. (Reminder : the use of
voipnwaddr/inhibit_t38 flag is deprecated).
On the other hand, in the media gateway configuration, the codec to use along with the PBX
must be forced to G.711 (alaw or µlaw), and VAD must be disabled.
5.2.3.21.5 Fallback to Fax over G.711
As of R10.0, when a T38 fax call is not possible, fallback to fax over G.711 is offered.
When the OmniPCX Office is configured for the T38 protocol, the system tries to detect the fax
tone after each call connection.
!"#$ % &'! % () !* % 81/151
Chapter 5
When a fax tone is detected, the system tries to switch to T38. A re-INVITE with a T38 SDP
offer is sent.
- If T38 is accepted, the call switches to T38.
- If T38 is rejected (message: 415 Unsupported Media Type, 488 Not Acceptable Here or
501 Not Implemented):
• Before R10.0, the call is released
• As of R10.0, a fallback to fax over G.711 is offered.
If the offer is accepted, the fax call is sent over G.711. If the offer is refused, the call is
released.
Switchback to voice after fax over T.38
Before R10.0, a call must be released at the end of a fax communication to switch back to
speech mode.
Switching to audio mode after a fax call is completed is a use case supported from R10.0 for
an analog fax set connected to an OmniPCX Office behind a SIP Trunk.
At the end of a fax call over T38, if the remote party attempts to switch back to an audio
communication, the received reINVITE is treated as any voice reINVITE with the same ARS
codec rules priorities.
The communication is released only when one of the party releases the call.
5.2.3.22 Static NAT
As of R10.0, the OmniPCX Office can provide static NAT (Network Address Translation)
service for SIP.
82/151 !"#$ % &'! % () !* %

Figure 5.13: NAT service for OmniPCX Office

On a local network, the NAT service associated to the router translates IP addresses of the
internet protocol but does not modify addresses of the SIP protocol. To provide a correct NAT
service, the OmniPCX Office translates the IP addresses of the SIP protocol.
On the OmniPCX Office, SIP calls to public gateways are modified as follow:
- Signaling flow: the OmniPCX Office replaces the private addresses and ports by the public
addresses and ports . This replacement is performed in all headers and SDP of the SIP
protocol.
- RTP flow: direct RTP is not allowed when static NAT is activated. All calls with the public
network are redirected to the OmniPCX Office for addresses and ports translations.
Dimensioning is the same as for a service without RTP Direct, see Dimensioning - Detailed
description .
Wideband codecs (G722 or G722.2) and video calls are not supported.
Public addresses and ports are static and must be configured in the OmniPCX Office. To
activate and configure the static NAT service, see: Public SIP Trunking - Configuration
procedure - Configuring Static NAT .
The NAT service provides security but not protection against eavesdroppers.
5.2.3.23 Nonce caching for SIP phones
!"#$ % &'! % () !* % 83/151
Chapter 5
5.2.3.23.1 SIP authentication messages (prior to R10.0)

SIP requests are challenged for authentication without nonce caching. Each request are
challenged independently.
Figure 5.14: SIP authentication without nonce caching

1. The SIP set (acting as a client) sends a request (INVITE or REGISTER) without
authentication information
2. This request is refused because an authentication is required. An error message is
transmitted. This message includes a challenge. This challenge includes:
• Realm: this name, provides by the server, identifies the security domain
• qop (Quality of Protection): defines the protection level required by the server
• nonce: random number used for password protection
3. The SIP set sends a new request (INVITE or REGISTER) with authentication information:
The authentication information includes:
• The realm, qop, nonce and username: returned as received from the carrier
• The cnonce (client nonce): parameter generated from the OmniPCX Enterprise. The
cnonce is a random number used to increase the complexity of the hash coding
• The response: calculated (hash coding) by the OmniPCX Enterprise from username,
password, nonce and cnonce
• The nc (Nonce Counter): this counter is incremented each time the nonce is used. This
84/151 !"#$ % &'! % () !* %

counter is reset when the nonce is changed.

4. After verification, the request is accepted or refused
Without nonce caching, the OmniPCX Office sends a challenge to each request. This protocol
increases the SIP traffic.
5.2.3.23.2 SIP authentication messages (as of R10.0)
As of R10.0 and when the configuration allows it, SIP authentication messages are simplified
with nonce caching:
- Nonce caching using next nonce
After a first authentication, proceeded as in SIP authentication messages (prior to R10.0) ,
To simplify authentication messages, the OmniPCX Office sends a next nonce field. The
SIP set stores this nonce and used it for the next request authentication.
Figure 5.15: SIP authentication with nonce caching using Next nonce
- Nonce caching using previous nonce
!"#$ % &'! % () !* % 85/151
Chapter 5
The OmniPCX Office allows SIP sets, which cannot proceed the Next nonce field, to reuse
the previous nonce for next request authentication. The reuse of the previous nonce is
limited to 10 requests or 30 minutes.
5.2.3.24 Supplementary Services

5.2.3.24.1 Hold
86/151 !"#$ % &'! % () !* %

A remote party can put on hold a local user through a public SIP trunk group by:
- Sending a Re-INVITE with an IP address set to 0.0.0.0 or media attribute set to "sendonly".
The local music on hold is played by the OmniPCX Office to the user put on hold.
- Sending a Re-INVITE with a valid IP address.
The remote party plays its own music on hold. Hold is transparent to the OmniPCX Office
Rich Communication Edition.
A local user can put on hold a remote party through a public SIP trunk group. The local music
on hold is played by the OmniPCX Office to the remote party put on hold. A Re-INVITE is
transmitted with a valid media IP address.
5.2.3.24.2 Call Forwarding
Call forwarding is performed by joining the two calls.
Call forwarding with signaling path optimization is not supported.
Media optimization can be performed through the RTP direct mechanism.
The 3xx message is not used:
- The OmniPCX Office does not send a 3xx message.
- The provider must not send a 3xx message. Such a message is rejected with a
503.Service Unavailable message.
5.2.3.24.3 Transfer
Transfer is performed by joining the two calls. The Re-INVITE method is used.
Transfer with signaling path optimization is not supported.
Media optimization can be performed through the RTP direct mechanism.
RFC 3515, 3891 and 3892 are not supported on public SIP Trunking.
- The OmniPCX Office does not use the REFER method
- The provider must not send REFER message nor an INVITE message including a
Replaces field.
5.2.3.24.4 Other Services
Other services requiring a renegotiation of media, such as conference or recording a
conversation, are performed by using the Re-INVITE method.
5.2.3.25 Symmetric Response Routing
As of R7.0, the OmniPCX Office complies with the RFC 3581 extension to the Session
Initiation Protocol (SIP), for symmetric response routing. The goal is to facilitate interworking
with NATs.
Client behavior: when UDP transport is used, the OmniPCX Office includes the rport
parameter in the top Via header, to indicate that the RFC 3581 extension is supported and
requested for the associated transaction. The OmniPCX Office Rich Communication Edition is
ready to receive responses either to the request’s source port, or to the 5060 port.
Server behavior : the OmniPCX Office examines the topmost Via header field. If it finds an
rport parameter, when building the response, it populates the rport parameter with the
source port of the request and adds a received parameter with the source IP address of the
!"#$ % &'! % () !* % 87/151
Chapter 5
request. Then, it sends the response back to the received/ rport address (in other words to
the source address of the received request), from the same address and port where the
request was received.
5.2.3.26 Trunk group information in SIP messages
As of R10.1, the OmniPCX Office complies with RFC 4904 Representing Trunk Groups in
tel/sip Uniform Resource Identifiers (URIs). RFC 4904 allows to convey trunk group
information in SIP messages.
5.2.3.26.1 Outgoing Call Scenario
For outgoing call, a SIP Request establishes a dialog from the OmniPCX Office. It contains the
trunk group parameters in the Contact header URI representing the originating trunk group as
described in figure: Outgoing Call scenario with trunk group parameters in Contact header . As
per RFC4904, subsequent SIP Requests in the dialog towards the OmniPCX Office contain
the same trunk group parameters in the Request-URI.
Note:
Contact: <sip: +6441231234 ;tgrp= +6441231230;
trunk-context=telecom.co.nz@10.65.1.100:5060;transport=udp>
Figure 5.17: Outgoing Call scenario with trunk group parameters in Contact header
5.2.3.26.2 Incoming Call Scenario

In case of incoming call from external SIP client, when the OmniPCX Office is a User Agent
88/151 !"#$ % &'! % () !* %

Server in a dialog associated with a gateway, the trunk group parameters in the incoming SIP
Request“s Request-URI imply that it should use the named trunk group for the outbound call.
If trunk group parameters are present in Contact URI of the incoming request, as per
RFC4904, subsequent SIP requests in the dialog from the OmniPCX Office contain the same
trunk group parameters in Request-URI, as shown in figure: Incoming call scenario with trunk
group parameters in Contact header .
Figure 5.18: Incoming call scenario with trunk group parameters in Contact header
When the RFC 4904 parameter is configured through OMC, and if the Contact header of the
incoming call SIP INVITE request does not contain the trunk group parameters, the OmniPCX
Office uses the existing default behavior to build the subsequent SIP Request-URI as shown in
figure: Incoming Call scenario without trunk group parameters .
The OmniPCX Office ignores the trunk group parameter present in Request-URI in the
following cases:
- When the incoming call's Request-URI is different from the values configured in OMC: SIP
Gateway Parameters > Protocol (Trunk Group ID, Trunk Context)
- When the RFC 4904 parameter is disabled in OMC
!"#$ % &'! % () !* % 89/151
Chapter 5
Figure 5.19: Incoming Call scenario without trunk group parameters
5.2.4 Configuration procedure

5.2.4.1 Pre-Requisites
The following must be declared:
- Installation Numbers: no SIP specificity
- DDI number range in the Public Dialing Plan: no SIP specificity
5.2.4.2 Checking Noteworthy Addresses
1. In OMC (Expert View), select System > System Miscellaneous > Memory Read/Write >
Other Labels
2. Check the VipPuNuA value is 00
3. Check the ExtNuFoVoi value is 22
Note:
The default value of the ExtNuFoVoi address is country dependant. Its function and value are the
same as ExtNumForm for ISDN.
5.2.4.3 Checking the VoIP Protocol and Setting the Number of VoIP Trunk Channels
90/151 !"#$ % &'! % () !* %

As of R8.0, SIP is set as the default VoIP protocol. By default, the number of DSP channels
reserved for VoIP (H.323 or SIP) is equal to 0.
To check the VoIP protocol and to increase the number of channels for VoIP trunks to a
non-null value:
1. In OMC (Expert View), select the System > Voice over IP > VoIP: Parameters > General
tab
2. Review/modify the followings attributes:
Number of VoIP-Trunk Chan- Enter the number of channels used for SIP trunking.
nels
VoIP Protocol Select SIP

4. If the VoIP Protocol has been switched from H323 to SIP, you are requested to reset the
PowerCPU EE board
5.2.4.4 Configuring the VoIP Trunks and Trunk Group
5.2.4.4.1 Configuring VoIP Trunks as Public
The VoIP trunks must be configured as public trunks.
1. In OMC (Expert View), select System > External Lines > List of Accesses > Details
2. Check the Public trunk box
5.2.4.4.2 Creating the VoIP Trunk Group
1. In OMC (Expert View), select System > External Lines > List of Trunk Groups
2. Create a trunk group containing the VoIP trunks
3. If necessary, modify the Link Category value (Traffic Sharing)
4. If necessary, modify the Traffic sharing & barring matrix
5.2.4.4.3 Creating a List Index for the VoIP Trunk Group
Trunk Group Lists
2. Create a list index for the VoIP trunk group
5.2.4.4.4 Creating the ARS Route
An ARS route must be created to route all numbers to the VoIP trunk group list. The figure
below shows the relationship between objects.
!"#$ % &'! % () !* % 91/151
Chapter 5
Automatic Routing: Prefixes
2. Add a line that routes everything to the VoIP trunk group
Activation Yes
Network pub
Prefix Leave blank
Ranges 0-9
Substitute Leave blank
TrGpList Enter the trunk group list index
Called(ISVPN/H450) het
5.2.4.4.5 Configuring ARS Optional Parameters

If the VoIP trunks are configured as public (see Configuring VoIP Trunks as Public ), the
Calling and Called/PP parameters of a public Automatic Routing: Prefixe can be left to their
default values.
On an installation combining both public and private SIP trunk groups, if the VoIP trunks are
configured as public, the Calling and Called/PP parameters of the private Automatic
Routing: Prefixe must be set to Priv:
2. Right-click on the line and select Opt. Parameters
Calling Select Priv
Called/PP Select Priv
5.2.4.4.6 Creating an ARS Prefix

1. In OMC (Expert View), select System > Numbering > Dialing Plans > Internal Dialing
Plan tab
92/151 !"#$ % &'! % () !* %

2. Create or modify the Main Trunk Group prefix

Feature Main Trunk Group
Start 0
End 0
Base ARS
NMT Drop
Priv No

5.2.4.5 Configuring The Gateway and IP Parameters
5.2.4.5.1 Configuring ARS IP Parameters with DNS SRV Disabled
The figure: ARS Configuration with DNS SRV disabled describes the main parameters to
configure, and their relationship, when DNS SRV is disabled.
Figure 5.21: ARS Configuration with DNS SRV disabled
Configuring the Route IP Parameters

2. Right-click on the line and select IP Parameters
Destination SIP Gateway
Index of Gateway Parameters Enter the gateway index.
Configuring the Gateway Parameters

!"#$ % &'! % () !* % 93/151
Chapter 5
Gateway Parameters
2. In the General tab, review/modify the following parameters:
Index The index field is a unique index number asso-
ciated to a gateway entry. It is automatically
determined when a new entry is created
through Create or Paste functions. However, if
need be, it can be modified in this screen.
Index Label This optional field can contain a label referring
to the SIP provider connected via this gateway
SIP Numbers Format Index Enter the index of SIP Public Numbering
where number format and alternative CLIP/
COLP number are configured
3. In the Domain Proxy tab, review/modify the following parameters:

IP Type Static
IP Address Enter the IP address of the outbound proxy.
Note 1:
This IP address is used to identify the origin of in-
coming calls.
Note 2:
This field can be left empty if the Hostname is filled.
Hostname This field is optional and can be entered as an
alternative to IP address of the remote SIP
gateway.
Note 3:
The hostname must be locally DNS solved (in OMC
and PC's DNS parameters).
Default Transport Mode Select the default transport mode to use.
Default value: UDP.
Target Domain Name Enter the domain name of the provider.
Note 4:
This parameter is used to fill the domain part of the
To header of an INVITE message.
Local Domain Name Enter the local domain name of the PCX.
Note 5:
A specific local domain name can be configured for
each SIP gateway.
Realm Enter the Realm value.
Remote Signalling Port Indicates the UDP port to which the PCX sends
SIP messages.
Outbound Proxy Enter the IP address of the outbound proxy.
4. In the Registration tab, review/modify the following parameters:
94/151 !"#$ % &'! % () !* %

Requested Check this box if the PCX must register on this

gateway.
If registration is requested, fill in the paramet-
ers below.
Registration check for sending requests This parameter enables registration checks be-
fore routing requests to the outbound proxy. By
default, leave blank.
Registrar Name Enter the name of the Registrar on which the
PCX is to register.
Registrar IP address Enter the IP address of the Registrar on which
the PCX is to register.
Port Indicates the port where to send registration
messages.
Expire time Enter the life time of the registration.
Address of Record Registration This parameter defines how the system uses
the registration identifier in the INVITE request
by selecting one or more of the following op-
tions:
• Contact
• From
• P-Asserted-Identity
• P-Preferred-Identity
For more details about this parameter, see:
Description .
By default, leave blank, the DID number of the
user is sent with the INVITE message.
RFC 3327 Select the box to enable the use of RFC 3327.
By default, disabled.
5. In the Media tab, review/modify the following parameters:

Fax Select the fax protocol:
• T38
• G711
Note 6:
The index value from ARS / Gateway Parameters
must be added to Index of gateway Parameters in
ARS/Automatic Routing: Prefixes
Note 7:
The codecs framing value must be less than or
equal to 60 ms when the G711 protocol is selected.
DTMF From R10.1, this parameter allows to select the
method used to send and receive DTMF.
• Out-Of-Band (RFC4733) (default value)
• In-Band
For more information, see Public SIP Trunking
- Feature Description - DTMF .
!"#$ % &'! % () !* % 95/151
Chapter 5
Codec/Framing • Default: the codec/framing chosen de-

pends on the remote party.
• Other values: OmniPCX Office uses only
this codec/framing.
Gateway Bandwidth Select the bandwidth available towards the re-
mote gateway. The number of simultaneous
communications towards the gateway depends
on this value.
6. In the DNS tab, review/modify the following parameters:

DNS Disabled
Primary DNS Server Leave blank.
Secondary DNS Server Leave blank.
7. In the Identity tab, review/modify the following parameters:

RFC3325 Indicates if CLIR management is supported by
remote proxy server.
By default, enabled.
Diversion info Select the diversion info to include:
• None: No diversion header info is included
• History-Info: a History-Info header is in-
cluded
• Diversion: a Diversion header is included
Default value: History-Info
- Feature Description - Transmission of the di-
verting number .
96/151 !"#$ % &'! % () !* %

Alternative CLIP Select the SIP header(s) in which the Alternat-

ive CLIP number is inserted:
• Contact: the Contact header contains the
alternative CLIP number
• From: the From header contains the altern-
ative CLIP number
• P-Asserted-Identity: the P-Asser-
ted-Identity header contains the alternative
CLIP number
• P-Preferred-Identity: the P-Pre-
ferred-Identity header contains the alternat-
ive CLIP number
By default all the SIP headers are selected.
The SIP headers which are not selected con-
tain the DDI number.
If no SIP header is selected, the alternative
CLIP number is not available in any of the
headers, even if an alternative CLIP number is
configured.
The selection of Address of Record Registra-
tion parameter in the Registration tab over-
rides the Alternative CLIP selection.
8. In the Protocol tab, review/modify the following parameters:

Alive Protocol Select ICMP or SIP Option.
Alive Timeout/s Enter the timeout between 20 and 3600 s.
RFC 4904 Select the box to enable RFC 4904
- Feature Description - Trunk group information
in SIP messages .
Trunk Group ID Enter the trunk group ID that will be conveyed
in SIP messages.
Trunk Context Enter the trunk context that will be conveyed in
SIP messages.
Note 8:
* : As of R9.2 , Login, Password and Registered User Name parameters are configurable in SIP
Accounts.
5.2.4.5.2 Configuring ARS IP Parameters with DNS SRV Enabled
The figure: ARS Configuration with DNS SRV enabled describes the main parameters to
configure, and their relationship, when DNS SRV is enabled.
!"#$ % &'! % () !* % 97/151
Chapter 5
Figure 5.22: ARS Configuration with DNS SRV enabled
Configuring the Route IP Parameters

2. Right-click on the line and select IP Parameters
Destination SIP Gateway
Index of Gateway Parameters Enter the gateway index.
Configuring the Gateway Parameters

Gateway Parameters
2. In the General tab, review/modify the following parameters:
Index The index field is a unique index number associated to a
gateway entry. It is automatically determined when a new
entry is created through Create or Paste functions.
However, if need be, it can be modified in this screen.
Index Label This optional field can contain a label referring to the SIP
provider connected via this gateway
SIP Numbers Format Index Enter the index of SIP Public Numbering where number
format and alternative CLIP/COLP number are configured
3. In the Domain Proxy tab, review/modify the following parameters:

IP Type Dynamic
IP Address Leave blank.
Hostname Leave blank.
Default Transport Mode Select the default transport mode to use.
Default value: UDP.
98/151 !"#$ % &'! % () !* %

Target Domain Name Enter the domain name of the provider.

Note 1:
This parameter is used to fill the domain part of the To header of
an INVITE message.
Local Domain Name Enter the local domain name of the PCX.
Note 2:
A specific local domain name can be configured for each SIP gate-
way.
Realm Enter the Realm value.
Remote Signaling Port Indicates the UDP port to which the PCX sends SIP mes-
sages.
Outbound Proxy Enter the name or the IP address of the outbound proxy.
4. In the Registration tab, review/modify the following parameters:

Requested Check this box if the PCX must register on this gateway.
If registration is requested, fill in the parameters below.
Registration check for send- This parameter enables registration checks before routing
ing requests requests to the outbound proxy.
By default, leave blank.
Registrar Name Enter the name of the Registrar on which the PCX is to re-
gister.
Expire time Enter the life time of the registration.
Address of Record Registra- This parameter defines how the system uses the registra-
tion tion identifier in the INVITE request by selecting one or
more of the following options:
• Contact
• From
• P-Asserted-Identity
• P-Preferred-Identity
For more details about this parameter, see Description .
By default, leave blank, the DID number of the user is sent
with the INVITE message.
RFC 3327 Select the box to enable the use of RFC 3327.
By default, disabled.
5. In the Media tab, review/modify the following parameters:

Fax Select the fax protocol:
• T38
• G711
Note 3:
The index value from ARS / Gateway Parameters must be added
to Index of gateway Parameters in ARS/Automatic Routing:
Prefixes
Note 4:
The codecs framing value must be less than or equal to 60 ms
when the G711 protocol is selected.
!"#$ % &'! % () !* % 99/151
Chapter 5
6. In the DNS tab, review/modify the following parameters:

DNS Select DNSSRV.
Primary DNS Server Enter the IP address of the primary DNS server.
Secondary DNS Server Enter the IP address of the secondary DNS server.
Note 5:
This IP address is used when the primary server does not answer.
7. In the Identity tab, review/modify the following parameters:

RFC3325 Indicates if CLIR management is supported by remote proxy
server.
By default, enabled.
Diversion info Select the diversion info to include:
• None: No diversion header info is included
• History-Info: a History-Info header is included
• Diversion: a Diversion header is included
Default value: History-Info
For more information, see Public SIP Trunking - Feature
Description - Transmission of the diverting number .
Alternative CLIP Select the SIP header(s) in which the Alternative CLIP num-
ber is inserted:
• Contact: the Contact header contains the alternative
CLIP number
• From: the From header contains the alternative CLIP
number
• P-Asserted-Identity: the P-Asserted-Identity header
contains the alternative CLIP number
• P-Preferred-Identity: the P-Preferred-Identity header
contains the alternative CLIP number
By default all the SIP headers are selected.
The SIP headers which are not selected contain the DDI
number.
If no SIP header is selected, the alternative CLIP number is
not available in any of the headers, even if an alternative
CLIP number is configured.
The selection of Address of Record Registration para-
meter in the Registration tab overrides the Alternative
CLIP selection.
8. In the Protocol tab, review/modify the following parameters:

Alive Protocol Leave blank (keep-alive is disabled when DNS SRV is
used).
Alive Timeout/s Leave blank.
Note 6:
The OmniPCX Office can belong to one domain only. If several gateways are defined, they use the same
DNS servers. The modification of DNS server addresses for one gateway is automatically applied to the
100/151 !"#$ % &'! % () !* %

other gateways for which DNS SRV is enabled. However, it is possible to mix gateways with DNS SRV
enabled and gateways with DNS SRV disabled. As of R8.0 a Local Domain Name can be associated to
each gateway, multiple Local Domain Name being supported.
5.2.4.5.3 Configuring SIP Public Numbering

SIP public numbering configuration is described in Public SIP Trunking - Feature Description -
Numbering Formats .
5.2.4.6 Configuring the Local Domain Name
Gateway Parameters
2. Review/modify the following parameter:
Local Domain Name This name is used in the domain part of the FROM header. It
can be for example the domain name of the provider.
A unique Local Domain Name can be defined for each SIP
trunk (public and private).
5.2.4.7 Configuring Timers

1. In OMC (Expert View), select System > Voice Over IP > VoIP: Parameters > SIP Trunk
tab
Timer T1 Retransmission timer: waiting duration before re-sending a
request.
Default value: 1000 ms
Timer T2 Response timer
Note:
T1 and T2 timers are defined in the RFC3261.
Number of Retries Maximum number of retries.
5.2.4.8 Configuring IP Quality of Service

1. In OMC (Expert View), select System > Voice Over IP > VoIP: Parameters > SIP Trunk
tab
!"#$ % &'! % () !* % 101/151
Chapter 5
IP Quality of Service for SIP From the OmniPCX Office R10.0.

trunk signaling The default value and behavior is identical as for the IP Qual-
ity of service field under System > Voice Over IP > VoIP:
Parameters > General > IP Quality of Service (see Public
SIP Trunking - Feature Description - IP QoS )
UDP to TCP Switching From the OmniPCX Office R10.0.
This parameter is used to disable the automatic switching of
transport type (from UDP to TCP) for outgoing SIP mes-
sages.
By default, the check box is selected (UDP/TCP switching en-
abled)
DNS Authentication From the OmniPCX Office R10.0.
This parameter is used to enable authentication of incoming
call based on IP address for DNS enabled ARS lines.
By default, the check box is not selected (the source IP ad-
dress is not checked for incoming calls associated to DNS
ARS lines).
5.2.4.9 Configuring Registration Parameters

If the OmniPCX Office must register, registration parameters must be configured for each
registrar (to allow for Multiple SIP registrars):
Gateway Parameters
3. In the Registration tab, check the Requested box
Registrar name Enter name of the Registrar on which the PCX is to register.
Registrar IP address Enter the IP address of the Registrar on which the PCX is to
register.
Port Indicates the port where to send registration messages.
Expire Time Enter the validity time of the registration.
Default value: 3600 s
5. If DNS SRV is not used, review/modify the following attributes:

Registrar IP Address Enter the Registrar IP address.
Port Enter the port number to be used for registration.
Outbound Proxy IP Enter the Outbound Proxy IP address.
6. If DNS SRV is used, check the DNS SRV box and review/modify the following attributes:
Registrar Name Enter the Registrar name.
Outbound Proxy Enter the Outbound Proxy name.
7. OmniPCX Office supports the Digest authentication scheme (MD5). If OmniPCX Office
must authenticate to the provider, enter the authentication parameters:
102/151 !"#$ % &'! % () !* %

User Name Enter the user name (login) for authentication.

Shared Secret Enter the password associated with the user name for au-
thentication.
Registered Realm Enter the realm name.
5.2.4.10 Configuring SIP account

When a gateway supports several SIP accounts, the account parameters must be configured
in the SIP account page:
SIP Account
2. In the SIP Account panel, check the Add box
Index Index of the account. This index is incremented automatic-
ally.
Login Enter the login for this account.
Password Enter the password for this account.
Registered User Name Enter the registered user name for this account.
Note 1:
The user name is unique per SIP domain.
Note 2:
This parameter is available only if the Registration Requested para-
meter is set to Yes in the Gateway parameters window.
Index of Gateway Parameters Select the gateway parameter index for this account.
RFC 6140 Indicates the use of RFC 6140 for this account:
• Enabled: enables the support of RFC 6140
• Disabled (default value): disables the support of RFC
6140
Note 3:
To support RFC 6140, the RFC 3327 flag must be enabled in the
Index of Gateway Parameters selected.
5.2.4.11 Associating a SIP account to a DDI range

As of R9.2, it is possible to associate a SIP account to a DDI range:
1. In OMC (Expert View), select System > Numbering > Dialing Plans
2. Select the Public Dialing Plan or the Restricted Public Dialing Plan tab
Feature Select: User
Start Enter the first DDI number of the range
End Enter the last DDI number of the range
... .
!"#$ % &'! % () !* % 103/151
Chapter 5
SIP Acc. Index Select the SIP account associated to this DDI range
Note:
This parameter can be left empty if there is no SIP Account needed
for the DDI range.
Figure 5.23: DDI range, SIP account and gateway parameters
5.2.4.12 Configuring Static NAT

As of R10.0, static NAT can be activated and configured on the OmniPCX Office.
5.2.4.12.1 Service activation
1. In OMC (Expert View), select Numbering > Automatic Routing Selection > Gateway
Parameters
2. Select the Protocol tab
3. Review/modify the following parameters in the Protocol frame:
Static NAT Validate this option to activate the static NAT service
5.2.4.12.2 Public data configuration

1. In OMC (Expert View), select Voice Over IP > VoIP: parameters
2. Select the Topology tab
3. Review/modify the following parameters in the Static NAT (public data) frame:
IP address Enter the public IP address of the OmniPCX Office
SIP Port (UDP/TCP) Enter the SIP port number used for signaling messages on
the public network
104/151 !"#$ % &'! % () !* %

Range ports for RTP (UDP) Enter the first public port number used for media messages
Note 1:
The last port number is automatically entered to define a range of
256 ports.
Range ports for T38 (UDP) Enter the first public port number used for T38 fax mes-
sages.
Note 2:
The last port number is automatically entered to define a range of
96 ports.
Note 3:
On the router, the NAT service must be configured for a static translation of:
- OmniPCX Office IP address: public - private
- RTP ports: private ports (32000 to 32255) - public ports
- T38 ports: private ports (6666 to 6761) - public ports
5.2.4.13 RTCP flow configuration
1. In OMC (Expert View), select Voice Over IP > VoIP: parameters
2. Select the General tab
RTCP attribute in SDP • When the option is validated, the RTCP port is added to
all OmniPCX Office requests containing SDP and when
SDP containing RTCP port is received it will be used as
remote RTCP port.
• When the option is not validated, the RTCP port is not
added in OmniPCX Office request containing SDP and
when SDP containing RTCP port is received, it is not in-
terpreted. RTP port +1 will be used as remote RTCP
port.
Note:
This parameter is displayed only when the VOIP protocol is set to
SIP
5.2.4.14 Configuring In-Band DTMF support for analog set

1. In OMC (Expert View), select Subscribers/Base stations List > Details
2. Select the Feature Rights tab
3. In Feature Rights Part3, review/modify the following parameters:
!"#$ % &'! % () !* % 105/151
Chapter 5
In-Band DTMF over SIP As of R10.3, this parameter allows to select the mode: In-
Trunk Band or Out-Of-Band used for DTMF sending or receiving
from or to an analog set via the SIP Gateway.
By Default, disabled.
Note:
This parameter is displayed only for analog set.
This parameter is greyed out for the other type sets or if the VoIP
Protocol is set to H323.
5.2.4.15 Appendix: Noteworthy Addresses for Codec/Framing Negotiation

5.2.4.15.1 Noteworthy Addresses Configuration
MultAnsRei
1. In OMC (Expert View), select System > System Miscellaneous > Memory Read/Write >
Debug Labels
2. Select MultAnsRei
MultAnsRei • 01 (default value): Re-invite sent on multiple-codec an-
swer
• 00: No Re-invite sent on multiple-codec answer
5.2.4.16 Appendix: VoIP Noteworthy Addresses

5.2.4.16.1 Overview
The values of noteworthy addresses (VOIPnwaddr) can be modified as typical OmniPCX
Office noteworthy addresses can be.
Any modification must be followed by a warm reset of the PCX.
Restart the OmniPCX Office when a VoIP daugther board is present on the main CPU.
Note:
As of R10.0, some of the VoIP noteworthy addresses are replaced by configuration parameters in OMC
and must not be used anymore. These noteworthy addresses are still available but their values are
ignored.
5.2.4.16.2 Presentation
- Name: internal name of the value
- Position: position of the value in the Noteworthy address buffer of OMC
The first position is at 0, the last position is at 0x63
- Length: length of the value in bytes
- Default: factory default configuration or after a cold reset of the OmniPCX Office
- Range: range of accepted values
5.2.4.16.3 List of Values
Privacy Level
106/151 !"#$ % &'! % () !* %

Presentation
Name Position Length Default Range Example

(byte) (byte)
Sipgw_priv_lvl 2 1 00 before 00-01 00 or 01
R8.2
01 as of
R8.2
Description
Set the OmniPCX Office privacy policy when CLIR is active.
If the identity presentation of user 1234 is restricted, the From field of an outgoing INVITE
message from the OmniPCX Office is:
- If Privacy Level = 00
From: sip:anonymous@anonymous.invalid
- If Privacy Level = 01
From: sip:1234@LocalDomain
To as Req-URI
Presentation

(byte) (byte)
Sipgw_to_ruri 3 1 00 00-01 00 or 01
Description
Set the To field for outgoing SIP calls.
By default, the To field is not same as Request URI for private and public forward. In this case,
the To field is the diverting number (the destination of the first call). To set the To field to
Request URI, this value must be set to 01.
- If Sipgw_to_ruri = 00
INVITE 1234@LocalDomain To: sip:5678@LocalDomain
- If Sipgw_to_ruri = 01
INVITE 1234@LocalDomain To: sip:1234@LocalDomain
Session Timer
Caution:
As of R10.0, the Session Timer noteworthy address must not be used anymore. The session
timer is managed with the Session Timer parameter of Numbering > Automatic Route Selection
(ARS) > Gateway Parameters (Protocol tab)
Presentation
!"#$ % &'! % () !* % 107/151
Chapter 5
Name Position Length (byte) Default Range Example

(byte)
Session 4 2 0000 0000-FFFF 0060 for one
Timer hour
Description
The session timer is the delay parameter specified in RFC4028.
For each call, a keep alive (session refresh) operation, which consists in a re-invite or update
refresh request, depending on the context, is performed at 50% of the period specified by this
variable.
The selection of the refreshing method (UPDATE or INVITE) is the result of a negotiation.
If no session refresh operation is performed or is successful by the end of this timer, the call is
released.
The timer unit is the minute and its minimum value 2 minutes:
- The 0000 default value refers to the default timer, of a 720 minutes (12 hours) duration.
- The FFFF value results in disabling the session timer: no keep alive operation is
performed. This selection avoids several interoperability problems.
- Any other value defines the session timer duration in minutes
Don't Use DNS SRV Unreachable Proxy List
Caution:
As of R10.0, this noteworthy address must not be used anymore. The unreachable proxy list is
activated/deactivated by configuring the Unreachable Proxy List Timer in System > Voice over IP>
VoIP: Parameters > SIP Trunk.
Presentation

(byte) (byte)
Don’t use DNS 6 1 00 00-01 01 results in not using the
SRV unreachable unreachable proxy list
proxy list
Description
DNS SRV makes use of a quarantine list to memorize unreachable proxies. This optimizes
overflow by not trying to connect to known unreachable proxies.
The default value 00 results in using the unreachable proxy list.
The 01 value results in not using the unreachable proxy list.
NAT Keep Alive for DNS SRV
Presentation
108/151 !"#$ % &'! % () !* %


(byte) (byte)
NAT Keep 8 2 0000 0000-FFFF 0258 results in NAT con-
Alive nection in router during
600 seconds
Description
When the OmniPCX Office is reached via a router (NAT/Firewall), the NAT connection must be
permanently open.
This noteworthy address is the duration of the NAT connection in the router.
When DNS SRV is enabled, the OmniPCX Office sends the OPTION messages at 75% of the
delay in order to maintain the NAT connection.
The 0 value results in no NAT Keep Alive.
A value above 0 results in enabled NAT Keep Alive for DNS SRV rules, and specifies the NAT
connection duration.
Registration Identifier Noteworthy Address
Presentation

(byte) (byte)
sipgw_regid 15 1 00 00-10 00: default
value
Description
- If sipgw_regid = 00
OmniPCX Office does not use registration identifier in INVITE i.e. DID number of user is
sent along with the INVITE message.
OmniPCX Office uses the registration AOR in P-asserted id for outgoing INVITE.
OmniPCX Office uses the registration Contact in outgoing INVITE’s Contact header.
OmniPCX Office uses the registration AOR in P-asserted id and registration Contact in
INVITE’s Contact.
OmniPCX Office uses the registration AOR in P-preferred id for outgoing INVITE.
OmniPCX Office uses the registration AOR in P-asserted id and contact header for all
INVITE request sent (Re-Invite).
OmniPCX Office uses the registration AOR in From and Contact header for outgoing
INVITE request sent.
As of R10.0, the sipgw_regid noteworthy address is replaced by check boxes located in
!"#$ % &'! % () !* % 109/151
Chapter 5
Numbering > Automatic Route Selection (ARS) > Gateway Parameters >Registration tab
>.Address of Record Registration box.
The table below details the relation between the sipgw_regid values used before R10.0 and
check boxes used as of R10.0:
sipgw_regid Contact From P-Asserted-id P-Preferred-id
value
00
01 Enable
02 Enable
03 Enable Enable
04 Enable Enable
05 Enable Enable
06 Enable Enable
07 Enable Enable Enable
08 Enable Enable
10 Enable Enable
P-Preferred Id
Presentation

(byte) (byte)
sipgw_prefid 16 1 00 00-05 00 default value
Description
Parameter available values are:
- 00
• Outgoing calls: no P-preferred Id
• Incoming calls: process P-preferred Id only if P-asserted id is absent
- 01:
• Outgoing calls: add a P-preferred Id with user identity (DID)
• Incoming calls: process P-preferred Id only if P-asserted id is absent
- 02:
• Outgoing calls: no P-preferred Id
• Incoming calls: process P-preferred Id in priority
- 03:
• Outgoing calls: add a P-preferred Id with user identity (DID)
• Incoming calls: process P-preferred Id in priority
- 04:
• Outgoing calls: no P-preferred Id no P-asserted id
110/151 !"#$ % &'! % () !* %

• Incoming calls: process From header in priority

- 05:
• Outgoing calls: add a P-preferred Id with user identity (DID), no P-asserted id
- 08:
• Outgoing calls: add a P-asserted id with user identity (DID), no P-preferred Id
When there is no P-preferred Id or no P-asserted id in a 180 Ringing or 200 OK
message, the To header of the response message is taken into account to display the
called party number.
- 10:
• Outgoing calls: the From header of INVITE message is set to the registration AOR.
Note:
When the sipgw_prefid parameter is set to 10, this parameter is used only when the sip_regid
parameter is set to 10.
- 20:
• Outgoing calls: headers of 180 Ringing or 200 OK responses are not taken into
account to display the called party number and name.
Does not apply to re-INVITE messages
• Incoming calls: no effect
As of R10.0, the sipgw_prefid noteworthy address is replaced by parameters located in
Numbering > Automatic Route Selection (ARS) > Gateway Parameters >Identity tab.
The table below details the relation between the sipgw_regid values used before R10.0 and
check boxes used as of R10.0:
sip- Calling Preferred Identity Connected Preferred Iden-
gw_regid tity
value Incoming Outgoing Outgoing Outgoing Incoming
Header list P-Preferred-Id P-Asserted-Id Header list
00 P-Asserted-Id Disabled Enabled Enabled P-Asserted-Id
P-Preferred-Id P-Preferred-Id
From Contact
To
01 P-Asserted-Id Enabled Enabled Enabled P-Asserted-Id
From Contact
To
02 P-Preferred-Id Disabled Enabled Enabled P-Asserted-Id
P-Asserted-Id P-Preferred-Id
From Contact
To
!"#$ % &'! % () !* % 111/151
Chapter 5
03 P-Preferred-Id Enabled Enabled Enabled P-Asserted-Id

From Contact
To
04 From Disabled Disabled Enabled P-Asserted-Id
P-Preferred-Id Contact
To
05 From Enabled Disabled Enabled P-Asserted-Id
To
08 P-Asserted-Id Disabled Enabled Enabled P-Asserted-Id
From To
Contact
10 From Disabled Enabled Enabled P-Asserted-Id
To
20 P-Asserted-Id Disabled Enabled Disabled P-Asserted-Id
From Contact
To
Do not Allow Update
Caution:
As of R10.0, the sipgw_noupdate noteworthy address is no more used and is replaced by the
UPDATE method enable check box located in Numbering > Automatic Route Selection (ARS) >
Gateway Parameters >Protocol tab.
Presentation

(byte) (byte)
sipgw_noupdate 17 1 00 00-01 00 UPDATE meth-
od is enabled
Description
This parameter enables/disables the support of the UPDATE method, which allows a client to
update session parameters (such as the set of media streams and their codecs) with no
impact on the state of a dialog.
Parameter available values are:
112/151 !"#$ % &'! % () !* %

- 01 : The UPDATE method is disabled.

- 00 : The UPDATE method is enabled (default value).
Send No-Signal Noteworthy Address
Caution:
As of R10.0, the send_no_signal is not used anymore and is replaced by the T38 additional
signaling parameter in Numbering > Automatic Route Selection (ARS) > Gateway Parameters
>Media tab.
Presentation

(byte) (byte)
send_no_signal 19 1 00 00-01 00 (default value) No
no-signal message is
sent
Description
This parameter allows to send a no-signal message for outgoing fax calls.
This parameter allows the IP-PBX to send a short burst of T.38/T.30 no-signal messages
during the setup of T.38 Fax calls.
Emitting these no-signal messages is especially useful when the IP-PBX is connected to an
external NAT-L3 router. The UDP Fax port is consequently enabled in the NAT and incoming
T.38 traffic is routed to the IP-PBX.
The default value 00 does not send no-signal message.
The 01 value sends no-signal messages for T38 fax calls.
Disable History-Info
Caution:
As of R10.0, the Disable_hi noteworthy address in no more used and is replaced by the
History-Info enabled check box (before R10.2) or the Diversion info parameter (as of R10.2)
located in Numbering > Automatic Route Selection (ARS) > Gateway Parameters >Identity tab.
Presentation

(byte) (byte)
Disable_hi 20 1 00 00-01 00 (default value) means
History-Info is enabled.
Description
This parameters allows to disable the support of History-Info (RFC 4244) header in send and
receive.
The default value 00 results in enabling the History-Info.
!"#$ % &'! % () !* % 113/151
Chapter 5
The 01 value results in disabling the History-Info.

Disable Optimization of Authentication
Presentation

(byte) (byte)
auth_optimize 21 1 00 00-01 00 (default value)
means Optimization of
Authentication is en-
abled.
Description
This parameters allows to disable the support of Optimization of Authentication.
The default value 00 results in enabling Optimization of Authentication.
The 01 value results in disabling Optimization of Authentication.
Enable Force DNS_A resolution
Caution:
As of R10.0, this noteworthy address in no more used. Force DNS_A resolution is enabled by
setting the DNS parameter in Numbering > Automatic Route Selection (ARS) > Gateway
Parameters >Identity tab.
Presentation

(byte) (byte)
force_dns_a 22 1 00 00-01 00 (default value) means
Force DNS_A resolution
is enabled.
Description
This parameters allows to enable the support of Force DNS A resolution.
The default value 00 results in enabling DNS A resolution instead of DNS SRV resolution.
The 01 value results in disabling Force DNS_A resolution.
V21 Jitter buffer depth
Presentation

(byte) (byte)
v21_jitter_depth 24 2 00 00 00 01F4 means 500ms for
00-FFFF V21 jitter buffer dept.
114/151 !"#$ % &'! % () !* %

Description
This parameter allows to tune the depth of the fax V21 jitter buffer. The unit is the millisecond.
The default value 00 00 results in applying default V21 jitter buffer depth, i.e 240ms.
Other values: depth of the V21 jitter buffer depth in milliseconds.
T4 Jitter buffer depth
Presentation

(byte) (byte)
t4_jitter_depth 26 2 00 00 00 01F4 means 500ms for
00-FFFF T4 jitter buffer depth.
Description
This parameter allows to tune the depth of the fax T4 jitter buffer. The unit is the millisecond.
The default value 00 00 results in applying default T4 jitter buffer depth, i.e 240ms.
Other values: depth of the T4 jitter buffer depth in milliseconds.
Trigger Alert message
Presentation

(byte) (byte)
trigger_alert 28 1 00 00-01 00 means No Alert
message is sent in Pro-
gress State.
Description
This parameter allows to send 180 Ringing and 183 Session Progress, when 180 Ringing or
183 Session Progress with SDP is received, with the delay (~1s) after 100 Trying is received in
transit case.
This parameter has:
- Value 01: In transit case, if 180 Ringing or 183 Session Progress is received with SDP with
a delay (~1s) after receiving 100 Trying, sends Alert message (180 Ringing), which is
followed by Session Progress (183) with SDP to another call leg.
- Value 00: In transit case, if 180 Ringing or 183 Session Progress is received with SDP with
a delay (~1s) after receiving 100 Trying, sends Session Progress (183) with SDP to
another call leg.
Send Simulated CED Tone
Presentation
!"#$ % &'! % () !* % 115/151
Chapter 5

(byte) (byte)
send_ced 34 1 00 00-01 00 (default value) means
simulated ced tone (T38
message) is not sent.
Description
As of R8.0, this parameters allows to send simulated T38 ced message to the network:
- Value 00: simulated T38 ced message is not sent to the network
- Value 01: simulated T38 ced message is not sent to the network
As of R10.0, this noteworthy address in no more used.
P-Early-Media activation
Caution:
As of R10.0, the pearlymedia noteworthy address in no more used and replaced by the
P-Early-Media for SIP trunk check box located in Numbering > Automatic Route Selection (ARS) >
Gateway Parameters >Protocol tab.
Presentation

(byte) (byte)
pearlymedia 58 1 00 00-01 00 (default value) means
p-earlymedia is disabled.
Description
This parameter allows to enable the control of early media flow through p-early-media.
The default value 00 results in disabling P-Early-Media: no control of early media flow.
The 01 value results in enabling P-Early-Media: control of early media flow.
G711A Silence Suppression
Presentation

(byte) (byte)
sip_g711a_vad_ 59 1 00 00-01 01 means silence sup-
pression is disabled for
G711A codec.
Description
This parameter allows to disable the silence suppression for G711A codec in both SIP phone
and SIP trunk gateway.
The value 00 results in using silence suppression parameters configured in OMC (Voice Over
116/151 !"#$ % &'! % () !* %

IP > VoIP) for G711A codec.

The 01 value results in disabling silence suppression for G711A codec.
Initial register authentication activation
Presentation

(byte) (byte)
Ini- 63 1 01 00-01 01 means the first RE-
tial_reg_username GISTER sent includes
an authentication field
Description
As of R9.2, this parameter allows to send authentication parameters in the initial REGISTER
message.
The default value 01 results in sending authentication parameters, including username, in the
initial REGISTER message.
The value 00 disables authentication in the initial REGISTER message.
Disable UPDATE without SDP when connected identity changes
Presentation

(byte) (byte)
Sip_4916_off 66 1 00 00-01 01 disables the identity
change messages
Description
When UPDATE methods are allowed on OmniPCX Office, UPDATE methods without SDP are
sent by the system when connected identity changes (RFC4916).
Some networks do not support such messages and cause extra traffic.
As of R10.0, it is possible to disable the sending of these UPDATE message:
- Value 0: the sending of these message is enabled.
- Value 1: the sending of these message is disabled.
5.2.4.17 Appendix: Noteworthy Addresses for Calling party presentation
5.2.4.17.1 OwnAreaCod
Presentation
Name Default Range Example

OwnAreaCod 00 00-01 See: Description
!"#$ % &'! % () !* % 117/151
Chapter 5
Description
As of R9.2, this flag allows to keep the area code in the incoming calling number, when the
area code is the same than the area code defined in the 'Installation number'.
Example:
International code: 49
Area code: 320
Received calling number: 0049 320 9988100
Displayed number:
9988100 (OwnAreaCod=00)
0 320 9988100 (OwnAreaCod=01)
5.2.4.17.2 Cli_inatLn
Presentation
Name Default Range Example

Cli_inatLn 0 00-255 See: Description
Description
As of R9.2, this noteworthy address allows to detect the international type of unprefixed SIP
incoming calling numbers, according to their length. The value defines the minimum number of
digits of such numbers.
Numbers with same or more digits than defined in this value are handled as international
numbers.
Numbers with less digits are not impacted and handled as described in previous table.
Default value: 0 (deactivated)
Typical use case: both unprefixed international numbers and unprefixed national/regional
numbers received from the SIP gateway.
The noteworthy address has no effect in following cases:
- National or international prefix included in the number,
- Unknown format is selected
Example:
Cli_inatLn=0B (11 digits)
Configured SIP „incoming calling number“ format = National
Received calling numbers:
49 320 9988100 is International number (12 digits unprefixed: detected by Cli_inatLn)
320 9988100 is National number (10 digits unprefixed: use configured number format)
0 320 9988100 is National number (11 digits, but with national prefix '0')
5.3 Private SIP Trunking
118/151 !"#$ % &'! % () !* %

5.3.1 SIP Gateway Services

5.3.1.1 Standards
See Public SIP Trunking - Feature Description - Standards
5.3.1.2 Services
As of OmniPCX Office Rich Communication Edition R7.1.1, SIP (Session Initiation Protocol)
becomes the default VoIP protocol designed to replace H.323 standard protocol which
becomes the second VoIP protocol.
OmniPCX Office Rich Communication Edition 10.3 embeds an integrated SIP gateway with
the following features:
- Up to 48 simultaneous VoIP calls
- G711, G729a, and G723.1 support
- RTP/RTCP: manages audio signals, including real-time packetization of media streams
and control reports
- T38: real-time Fax over IP
- Fax over G711 codec
- Echo cancellation
- Tone detection/generation
- Voice Activity Detection (VAD)/Silence suppression
- ICMP Keep Alive (to remote gateway)
- SIP option Keep Alive (to remote gateway)
- Direct RTP
- SIP registration and authentication
- SIP public numbering
- Codec pass-through for SIP sets (in direct RTP)
- Codec pass-through for SIP trunks (in direct RTP)
5.3.1.2.1 Overview
OmniPCX Office Rich Communication Edition users can communicate with remote SIP
components such as gateways, proxies or terminals, through SIP for signalization and
RTP/RTCP for voice.
!"#$ % &'! % () !* % 119/151
Chapter 5
5.3.1.2.2 Transfer
Transfer in private networks complies with standards RFC 3515, 3891 and 3892.
Transfer in conversation and in ringing with optimized audio path is fully supported in private
networks.
5.3.1.2.3 Fax over IP (FoIP)
See Public SIP Trunking - Feature Description - Fax over IP (FoIP)
5.3.2 Topologies
5.3.2.1 Architecture
The following topology is recommended for connecting an OmniPCX Office Rich
Communication Edition using SIP.
120/151 !"#$ % &'! % () !* %

The bandwidth of an Ethernet LAN can be 10 or 100 Mbps. If the network operates at 100
Mbps, adding terminals operating at 10 Mbps risks downgrading the bandwidth used by VoIP
and hence audio quality. You might need to isolate these devices on external LAN switches
hooked up to the system.
The PowerCPU EE board is connected to the local client network using a LAN switch. This
solution helps reduce Ethernet traffic on the PowerCPU EE board.
5.3.2.1.1 Multi-site Configurations
A multi-site configuration is possible via an extended Intranet or an Internet VPN.
5.3.2.1.2 SIP Gateway Integrated Into an Extended Intranet
!"#$ % &'! % () !* % 121/151
Chapter 5
bandwidth is "guaranteed" if this router supports Ipv4 ToS (DiffServ).
5.3.2.1.3 SIP Gateway Integrated Into a VPN
functionality (IPSec with 3DES encryption for interoperability with the system's built-in router).
5.3.2.1.4 IP Telephony in an Extended Intranet
Note:
See also the Home Worker and Remote Worker topologies described earlier.
5.3.3 Authentication/Registration
122/151 !"#$ % &'! % () !* %

5.3.3.1 Authentication and Registration

5.3.3.1.1 Authentication and ARS
The OmniPCX Office authentication mechanism conforms to the RFC 3261 recommendation
and to data registered in the ARS table. Two fields are provided in the ARS table for SIP
components: login and password (username and shared secret).
Incoming Calls
There is no authentication for incoming calls. Only calls from IP addresses registered in the
ARS table are accepted.
Outgoing Calls
The type of authentication depends upon destination listed in the ARS table. For calls to proxy
servers, OmniPCX Office sends an authenticated request when a 401 or 407 response
containing an authentication challenge is received. Authorization is accomplished by a
combination of a user name and a password (shared secret) in accordance with
recommendations RFC 2617and RFC 1321.
Parameters
By OMC (Expert View): Numbering -> Automatic Routing Selection-> Gateway paramet-
ers
The following fields display in the Gateway Parameters Details window:

- Index
- Login
- Password
- Domain Name
- Realm
- RFC3325 (not used for authentication)
- Remote SIP port (not used for authentication)
- SIP Numbers format index (not used for authentication)
- Index label
- DNS
- Local Domain Name
For more information on these fields, you can also refer to the OMC On-line documentation.
5.3.3.1.2 Registration Parameters
By OMC (Expert View): Numbering -> Automatic Routing Selection-> Gateway paramet-
ers
The following fields are used to control registration and authentication:

- In the Domain Proxy tab:
!"#$ % &'! % () !* % 123/151
Chapter 5
• Realm
- In the Registration tab:
• Requested (yes/no): indicates if registration is required
• Expire time: timeout used to refresh registration periodically (by default, 3600
seconds)
• Registrar IP Address: Registrar's IP Address
• Port: UDP number for REGISTER request
By OMC (Expert View): Numbering -> Automatic Routing Selection-> SIP accounts
- Login: username (login) for authentication

- Password: password associated with the username for authentication
- Registered Username: Username used for registration
5.3.4 Configuring SIP Gateway

5.3.4.1 Hardware configuration
SIP Gateway is an application layer which works as an interface between IP telephony (SIP
stack) and switched telephony (OmniPCX Office Rich Communication Edition PBX call
manager).
5.3.4.1.1 Checking the VoIP Protocol
Since R8.0, SIP is set as the default VoIP protocol in OmniPCX Office Rich Communication
Edition. To check, and, if necessary, modify the VoIP protocol:
If the VoIP Protocol has been switched from H.323 to SIP, OMC asks you to reboot the
PowerCPU EE board.
5.3.4.1.2 Configuring the System as the SIP Gateway
By default, after initialization, all the DSP channels are assigned to the pool of VoIP subscriber
channels (IP telephony).
In a pure SIP gateway configuration, all the DSP channels of the PowerCPU EE board and the
ARMADA VoIP32 daughter board are used for "IP network" accesses.
Number of VoIP access channels (IP trunks): Number of channels for VoIP IP access, i.e. 1
DSP channel for 1 "network access".
Direct RTP: The direct RTP service provides direct RTP and RTCP flow exchange between IP
endpoints (IP sets, DSP channel on PowerCPU EE board, distant gateways).
To activate the direct RTP option, check the check box. This should be carried out when there
is no traffic on the system.
Note:
Each DSP channel placed in the "VoIP access" pool is considered as a "network access" by the PBX, i.e.
124/151 !"#$ % &'! % () !* %

1 VoIP DSP = 1 B-channel. As there can be a maximum of 16 DSP channels on PowerCPU EE board
and 32 DSP channels on ARMADA VoIP32 daughter board, there can be no more than 48 VoIP access
DSP channels, i.e.48 "IP" B-channels.
Network accesses (T0, T2, analog TL, DLT0, DLT2) + VoIP accesses = 120 accesses Max.
Once the protocol has been modified, OMC asks you to reboot the PowerCPU EE board.
Quality of IP service: Selection of QoS type for the remote SIP gateway VoIP calls.
If all the network elements support the IP ToS, you can choose an IP priority from 1 to 7.
If all the network elements are "DiffServ" compatible, you can choose:
- DiffServ PHB Best Effort Forwarding (BE) (priority bits: 00000000 ), or
- DiffServ PHB Expedited Forwarding (EF) (priority bits: 10111000 ).
5.3.4.1.3 Configuring the Gateway Timeouts (optional)
By OMC (Expert View): System -> Voice on IP -> VoIP: Parameters -> Gateway tab
NB: The parameters have standardized values, do not change them without prior analysis.
- RAS Request Timeout: Maximum authorized response time for a RAS request
("Registration, Admission, Status") made to the gatekeeper; between 10 and 180; default
value = 5
- Gateway Presence Timeout : Determines the presence of a remote Gateway; value
- Connect Timeout: Maximum authorized time interval between initialization and
connection; value between 10 and 1200; default value = 500
- H.245 Request Timeout: Maximum authorized response time for an H.245 request; value
- SIP: End of dialing timeout: Default value = 5
5.3.4.1.4 Configuration of T38 Parameters for Fax over IP (optional)
By OMC (Expert View): System -> Voice on IP -> VoIP: Parameters -> Fax tab
- T38/UDP Redundancy Number of Fax data packets forwardings; value between 0 and 2;
default value = 1
- T38/Framing Number of data packets in the same frame; value between 0 and 5; default
value = 0. In fact, the number of packets is equal to the number set in this field + 1
- T38/Error Correction Mode As of R10.0, this parameter (previously managed via
noteworthy addresses), enables/disables the FAX ECM mode on IP trunk. This parameter
is available in both H.323 and SIP VoIP protocol mode.This feature is disabled by default
Note:
a) Only T38 traffic is supported: modem, V90, V24, etc. are not available via H.323/SIP connection. b) if
the UDP redundancy is set to 0, any framing value (0 to 5) can be used. If the UDP redundancy is set to
1, the framing must not be configured to a value higher than 1
5.3.5 Configuring a Remote SIP Gateway
!"#$ % &'! % () !* % 125/151
Chapter 5
5.3.5.1 Configuration examples

5.3.5.1.1 Configuring outgoing communication (ARS table)
The choice of routing a telephone communication between a public network access or a VoIP
access and the busy trunk overflow feature are defined in the ARS table.
Like conventional outgoing telephone calls, a VoIP call is subject to the ARS mechanisms: link
categories, ARS time slot management, overflow on busy, etc.
In the diagram below sites A and B are OmniPCX Office Rich Communication Editions. Site C
is a remote system integrating a SIP gateway.
- @IP1 : IP address of the PowerCPU EE board at site A -

- @IP2 : IP address of the PowerCPU EE board at site B. For example: 192.189.50.120
5.3.5.1.2 Basic call
The site A stations call the site B stations by dialing their internal numbers:
Internal numbering plan (site A):
Secondary trunk group 2 2 ARS Keep Yes
ARS Table:
126/151 !"#$ % &'! % () !* %

Net- Ac- Range Substi- List. Called Party Comment Destination

work cess tute Trunk (ISVPN/H45
group 0)
list
Priv. 2 00-49 2 4 het SIP to site B SIP Gateway
- By default, the "Called(ISVPN/H450)" field is set to "het" (heterogeneous). When set to

"hom" (homogeneous), a remote IP is expected to support optimized forwarding and
transfer; local and remote numbering plans are supposed to be consistent. Moreover, CLIP
and CLIR features are then played according to ALE International manufacturer’s
mechanism in a Private network context.
For an IP remote to be described, this field tells about its SIP interoperability.
“called(ISVPN/H450)” To configure when occurs when forward service
value is asked
Hom (Homogeneous) the IP remote is known as forward: SIP optimized
SIP private interoperability transfer: SIP optimized
and ARS component type is
GW
Het (Heterogeneous) Otherwise forward: SIP not optimized
transfer: SIP not optimized
Hom Fwd (Homogeneous the IP remote is known as forward: SIP optimized
Forward) SIP interoperability and ARS transfer: SIP not optimized
component type is GW
Hom Trf (Homogeneous the IP remote is known as forward: SIP not optimized
Transfer) SIP interoperability and ARS transfer: SIP optimized
component type is GW
- The "User Comment" field enables a comment to be associated with the ARS input (20
characters maximum).
- The "Destination" field of an ARS input to VoIP accesses must be set to "SIP Gateway".
Note:
The IP parameters are configured in the parameters of the gateway associated to the ARS table.
IP Type IP address Hostname Gateway Alive Pro- Alive Alive

(Domain (Domain Proxy (Domain Bandwidth tocol Timeout/s Status
Proxy tab) Proxy tab) (Media tab) (Protocol (Protocol (Protocol
tab) tab) tab) tab)
Static 192.189.50.120 option 128 Kbits (5 either 300 Enabled
calls) ICMP
(default)
or SIP op-
tion
- For a "SIP Gateway" destination, the "IP Type" must be a static IP address (non-modifiable
field).
- The "IP Address" field must be that of the remote SIP gateway. In the example, this value
corresponds to the IP address of the PowerCPU EE board at site B.
- The "Host name" can be used instead of the IP address of the remote gateway. Requires a
!"#$ % &'! % () !* % 127/151
Chapter 5
DNS server.
- Alive Protocol:
• The Alive Protocol can be either:
• ICMP
• SIP option (From OmniPCX Office Rich Communication Edition R6.0)
- Alive Timeout/s:
The Alive Timeout/s can be selected between 20 and 3600 seconds (300 by default).
When set to 0, the gateway alive protocol mechanism is inhibited. This option is to be used
specifically when it is impossible to use ICMP to test the presence of the remote gateway.
In this case, it is impossible to know whether the gateway is alive or out of service.
- Gateway Bandwidth / QoS: for each ARS input to a remote SIP gateway, a bandwidth
must be reserved for the VoIP to the remote SIP gateway. The number of simultaneous
communications that can be held depends on this value:
Bandwidth Number of possible simultaneous
communications
None No communication possible (Default
value)
55.6 Kbps 1
64 Kbps 2
128 Kbps 5
256 Kbps 10
512 Kbps 20
# 1024 Kbps > 20
Example: if the total bandwidth corresponding to the data rate to a remote gateway is 256
Kbps, and the mean traffic level is 50%, it would be wise to define a bandwidth of 128 Kbps for
VoIP.
5.3.5.1.3 Remark concerning the quality of service (QoS)
If we take our example, site A can make SIP calls to sites B and C. One assumes that the
bandwidths reserved for VoIP at the LAN/WAN gateways of each site are the following:
- Bandwidth reserved for VoIP on site A: 1024 Kbps (20 calls or more)
- Bandwidth reserved for VoIP on site B: 128 Kbps (5 simultaneous calls)
- Bandwidth reserved for VoIP on site C: 64 Kbps (2 simultaneous calls)
In this configuration, you can see that it is possible to make 7 simultaneous calls from site A to
the remote SIP gateways: 5 to site B and 2 to site C.
7 DSPs can therefore be assigned in the "VoIP access" pool for site A (7 being the number of
DSPs needed to call sites B and C simultaneously).
However, let us assume that there is no ongoing communication between sites A and C, and
that 5 calls are established between A and B. The total number of VoIP network access DSPs
consumed in PBX A is 5: therefore 2 DSPs remain available to establish two other calls to site
B.
Yet in this example we exceed the bandwidth reserved for VoIP at the LAN/WAN gateway of
site B: the quality of service is no longer guaranteed.
128/151 !"#$ % &'! % () !* %

To avoid downgrading the VoIP service, the system uses the "Gateway Bandwidth" field of the
ARS table associated with the input to the remote SIP gateway of site B, which will be
configured at 128 Kbps (5 calls), as quality indicator (QoS). Although there are still 2 DSPs
available, the PBX will refuse a 6th call to site B.
Note:
To optimize management of this ARS table parameter, it is vital to have a precise information about the
bandwidth available (reserved) for VoIP calls.
- Alive Status: this regularly updated read-only field indicates the status of the remote
gateway:
• Alive: remote gateway present
• Down: remote gateway absent / out of service
It can, however, turn out to be judicious to deactivate the mechanism if one is sure of network
reliability, in order to reduce the traffic.
5.3.5.1.4 Incoming call
An incoming "VoIP access" call is analyzed in the private numbering plan. In our example:
Private numbering plan of site B:
Local call 200 249 200 No
5.3.5.1.5 Forcing a public call to the SIP gateway

LCR : Least Cost Routing
When a site A subscriber dials the public number of the site B station, the call can be forced to
the VoIP network accesses.
ARS Table:
group list (ISVPN/H45
0)
Pub. 04723542 00-49 2 4 het SIP to site B
5.3.5.1.6 Overflow
When a site A subscriber calls a site B station by its internal number, ARS routing enables the
calls to be re-routed to the public network when it is no longer possible to call via the VoIP
accesses. The following criteria render a "VoIP access" trunk group inaccessible:
- The PowerCPU EE board of site A is out of service
- No more DSPs associated with the VoIP accesses are available
- The remote SIP gateway is out of service (PowerCPU EE board of site B is out of service)
!"#$ % &'! % () !* % 129/151
Chapter 5
- The quality of service (QoS) to the remote gateway is poor (exceeding of the simultaneous
communications threshold for the reserved VoIP bandwidth of this remote SIP gateway)
Calling the site B station by its internal number:
work Trunk Party
group list (ISVPN/H
450)
Priv. 2 00-49 2 4 het SIP to site B SIP Gateway
04723542 1 het ISDN Access Not IP
Calling the site B station using its public number:

work Trunk Party
group list (ISVPN/H
450)
Pub. 04723542 00-49 2 4 het SIP to site B SIP Gate-
way
04723542 1 het ISDN Access Not IP
Pub. 04723542 50-99 04723542 1 het ISDN Access Not IP *
* : As the public numbers 04723542 50 to 99 do not belong to site B, they must be routed to
the public network.
5.3.5.1.7 Break In
The break-in service enables the PBX to re-route a public number from site A to site B. In our
example, the public network subscriber dials the number 03 88 67 71 50 which is routed to
station 250 on site B:
Public numbering plan (site A):
Secondary trunk group 7150 7150 ARS Keep No
ARS Table:
Network Access Range Substitute List. Trunk Called Comment
group list Party
(ISVPN/H4
50)
Pub. 0388677150 250 4 het SIP to site B
Reminder: it is vital for the PBX "Installation number" field to be configured; e.g. for site A:
388677100.
5.3.5.1.8 Break Out
The break-out service enables proximity calls to be made. In our example a site A station dials
130/151 !"#$ % &'! % () !* %

a public number starting with 04, the call is routed to site B via the SIP gateway, then routed to
the public network from site B. Configuration:

work Trunk Party
group list (ISVPN/H
450)
Pub. 04 004 4 het SIP to site B SIP Gate- *
way
04 1 het ISDN Ac- Not IP **
cess
* : as the prefix 0 is dropped in the internal numbering plan, 004 must be substituted for 04,
** : this sub-line allows overflow to the public network lines of site A when the VoIP access
calls are inaccessible.
As an incoming VoIP access call is analyzed in the private numbering plan, the private
numbering plan of site B must be programmed as follows:
Main trunk group 0 0 0 Drop No
!"#$ % &'! % () !* % 131/151

6.1 Overview
A few precautions must be taken when adding a machine into a local network to ensure the
lasting compatibility and quality of the network.
The starting point for the integration and configuring of OmniPCX Office Rich Communication
Edition on a LAN is the knowledge of the network structure, its characteristics and its
elements. After that, it is necessary to collect the significant parameters and characteristics of
the LAN.
Below is a list of the parameters to be collected:
CPU Board
- Hostname: DNS name or alias of the board
- IP Address: IP address of the board
- IP Subnet Mask : subnet mask of the LAN
General
- Number of IP trunk DSP channels: number of channels associated with remote H.323
gateway access
- Number of IP subscriber DSP channels: number of channels associated with the IP
Telephony service
- Quality of service: type of quality of service to be implemented according to the LAN
equipment
H.323 Gateway
- IP addresses of remote H.323 gateways
- Gatekeeper integrated into the PBX: use of an integrated gatekeeper or not
- Identification of gatekeeper: IP address of external gatekeeper
SIP Gateway
- IP address of remote SIP registrar
- IP addresses of remote SIP gateways
IP Telephony
- Activate the integrated DHCP server: use of the integrated DHCP server or not
- Dynamic Range: dynamic IP address range for IP telephony (IP sets) or for PCs
132/151 !"#$ % &'! % () !* %

!"#
7.1 Overview
7.1.1 Basic description

A Virtual Local Area Network (VLAN) is a group of network elements from one or more LANs
that are configured in such a way that they can communicate as if they were attached to the
same wire.
VLANs are very flexible because they are based on logical connections instead of physical
connections. The purpose is to segment ethernet traffic logically.
The figure below represents the abstraction of a physical LAN divided into two VLANs: a Voice
VLAN (VoIP frames) for IP phone sets, and a Data VLAN for computers. In VLAN uses, the
number of VLAN can be different depending the LAN management rules and the choice of the
network administrator.
A VLAN architecture offers the following advantages:

- Increased performance through traffic segmentation (voice and data frames)
- Network tuning and simplified software configurations: LAN administrators can optimize
their networks by grouping users logically
- Physical topology independance
- Increased security options: LAN administrators can segment privileged users (access to
sensitive information) and standard users into separate VLANs, regardless of their physical
location
7.2 Topologies
!"#$ % &'! % () !* % 133/151
Chapter 7 2
The purpose of this section is to show how OmniPCX Office Rich Communication Edition
could be connected to VLANs. The OmniPCX Office is able to operate on 2 VLANS (1 for
Voice and 1 for Data).
Because the PowerCPU EE works with both VLANs it must have a unique IP address for each
VLAN.
Note:
LanX boards must not be used in a VLAN topology because they do not recognize or support
VLAN-tagged frames (802.1Q).
OmniPCX Office Rich Communication Edition is configured to manage two VLANs, one for
voice and the other for data. Additional voice and data VLANs will be managed by the external
ethernet switch configuration and external routers (communication between VLANs).
OmniPCX Office Rich Communication Edition is connected to a switch with the following
characteristics:
- VLAN-aware: a switch that can recognize and support VLAN-tagged frames.
- Each port to which the PowerCPU EE board and IP phone sets are connected must be of
hybrid type with the same VLAN identifier (VID). An hybrid port is a switch port configured
to send and receive 802.3 (data VLAN protocol) or 802.1Q (voice VLAN protocol) frames
134/151 !"#$ % &'! % () !* %
2
7.3 Configuring VLAN
7.3.1 Configuration procedure

VLAN is configured for OmniPCX Office Rich Communication Edition through OMC. As VLAN
configuration is closely related to IP Address configuration, both configurations are defined on
the same node:
The IP/LAN Configuration property sheet contains the following pages:

- LAN Configuration
- Boards
- IP Addresses for PPP
- Routing
- Priority Mapping
7.3.1.1 LAN Configuration
This property page defines the overall LAN logical structure. It is divided into two areas: Data
Traffic and Voice Traffic.
In the default LAN configuration:
- Data Traffic property is set to On normal LAN - all LAN data traffic circulates in 802.3
frames.
- Voice Traffic property is set to Use the same LAN/VLAN as Data Traffic - voice and
data packets are not tagged. There is no VLAN for voice traffic so traffic is not segmented.
If the Voice Traffic property is set to Use Separate VLAN data packets are not tagged but
voice packets are sent with the VLAN=3 tag (as shown in the example above).
When you change the IP Subnet Mask or the Default Router IP Address fields, the Network
IP Address field is recalculated and a warning icon is displayed to indicate that all boards IP
addresses have been recalculated to match the new network. (This only applies to data traffic)
!"#$ % &'! % () !* % 135/151
Chapter 7 2
VLAN IDs
Select the Data Traffic property Use VLAN (802.1p, 802.1Q) to define a VLAN ID for data
traffic.
Select theVoice Traffic property Use a separate VLAN to define a VLAN ID for voice traffic.
Note that the Voice Traffic default router IP address is calculated from the router IP address
provided in the Data Traffic section.
Note:
The default VLAN ID for Data Traffic is 2. The default VLAN ID for Voice Traffic is 3.
7.3.1.2 Boards
When voice traffic has been assigned to a separate VLAN (see LAN Configuration section), an
icon in the LAN column indicates to which VLAN (data or voice) a board is associated.
The IP addresses defined for each board should be consistent with the network settings in the
LAN Configuration page. To help you choose consistent addresses, the network and subnet
mask IP addresses are explained beside each VLAN icon at the bottom of the page.
The "Main CPU" and "Main CPU (Voice)" fields have a particular behavior. They can be used
to modify the networks. Changes are reported to the LAN Configuration page for system
consistency. In that case, all corresponding IP addresses associated to the same VLAN (data
or voice) are automatically recalculated to match the new networks.
7.3.1.3 Routing
With the introduction of traffic segmentation, the main CPU can be connected to more than
one LAN/VLAN. To send packets to a destination whose IP address is related to one of these
LANs/VLANs, the main CPU only needs a network IP address and a subnet mask IP address.
When the target destination lies beyond the main CPU's visible LANs/VLANs, a routing
decision must be taken.
In OMC, you can specify up to 40 routes. Each route is defined by a destination subnet
(network IP address and subnet mask) and the IP address of the router via which the packets
must be routed. This router must be visible from one of the LANs/VLANs to which the main
CPU is connected. (See network IP addresses and subnet masks of voice and data VLANs at
the bottom of the page.)
136/151 !"#$ % &'! % () !* %
2
7.3.1.4 Priority Mapping

This page allows mapping Diffserv code points (DSCP) to 802.1p Ethernet priority values.
7.3.1.4.1 802.1p priority
!"#$ % &'! % () !* % 137/151
Chapter 7 2
Standard Ethernet frame headers are made of the source and destination MAC address
followed by a 2-byte length/type field. Tagged Ethernet frames include an extra 2 bytes in the
header in order to support VLAN (802.1Q) and priority (802.1p) protocols. Three bits are
available for priority, giving 8 possible priority values. Mapping is simple: 0 is the lowest priority
and 7 is the highest.
7.3.1.4.2 IP ToS, Precedence, and DSCP
An IP packet header contains a byte called Type of Service. This byte contains several fields
whose interpretation has evolved over the years. Initially interpreted as a 3-bit precedence
value plus several ToS flags, the current interpretation uses the top 6 bits as a single value
called the "Differential Services Code Point".
Remember the following points:
- DSCP can be interpreted as a 6-bit number
- The top 3 bits occupy the same position in the IP header as in the original definition of the
"IP Precedence" field
- To keep a minimum compatibility with the older interpretation, DSCP values are organized
into several classes of increasing priority. For example, the lowest priority class covers
DSCPs 0 to 7
- The values within a class are not necessarily organized in order of increasing priority
- Some values have a specific meaning. For example: 0 means "Best Effort" (BE), 46 means
"Expedited Forwarding" (EF), a high precedence DSCP often used for VoIP traffic
- The interpretation of DSCPs is not fully imposed. There is a notion of Diffserv domain and
the DSCP code of a packet may change as it passes across a domain boundary
7.3.1.4.3 Priority Mapping in OMC
As far as OMC is concerned, all that is required is to provide a way to determine the frame
priority that should be used when an IP packet is transmitted through an Ethernet frame. In
other words, you need to associate an 802.1p priority value (between 0 and 7) to each of the
possible 64 DSCPs.
138/151 !"#$ % &'! % () !* %
2
The "Service Type" column displays a description for the following DSCPs:
DSCP Description
0 Best Effort (BE)
8 Class 1
16 Class 2
24 Class 3
32 Class 4
40 Express Forwarding
46 Expedited Forwarding (EF)
48 Control
!"#$ % &'! % () !* % 139/151
Chapter 7 2
DSCP Description
56 Control
The default priority assignments are the following:

DSCP values 802.1p priority
0-7 0
8 - 15 1
16 - 23 2
24 - 31 3
32 - 39 4
40 - 47 5
48 - 55 6
56 - 63 7
140/151 !"#$ % &'! % () !* %

$
8.1 Detailed description
8.1.1 System Sizing

Information in this chapter is valid for OmniPCX Office Rich Communication Edition, Release
8.1.
8.1.1.1 DSP Channels Required For IP Trunk Services
Number of DSPs = Number of VoIP network accesses = 48 max.
8.1.1.2 DSP Channels Required by VoIP Services

The number of DSP channels (VoIP ports) required depends on the system configuration and
the VoIP services to be implemented.
The most common situations are the following:
- H.323/SIP gateway only: the number of DSP channels is equal to the number of IP
network accesses.
Note:
The desired number of DSP channels can be limited by the bandwidth reserved for VoIP accesses.
Example: if the reserved bandwidth is 64 KBps, only 2 calls can be made simultaneously; the
number of VoIP accesses can thus be limited to 2 channels.
- IP Telephony only
- Conventional telephony (Reflexes / DECT / Z, etc.) and IP Telephony
- H.323/SIP gateway and IP Telephony
8.1.1.3 Case of DSP Channels Required With Direct RTP
The direct RTP feature enables direct audio paths between IP sets and distant gateways or IP
sets. Certain VoIP services no longer necessitate an allocation of a DSP channel.
A selection of typical configurations examples in the table below shows how to calculate DSP
needs.
figure: DSP Channel Needs With Direct RTP illustrates how direct RTP decreases the need for
DSP channels.
From left to right, columns show:
- the number of terminals and the number of trunks necessary
- the mix of IP terminals and legacy sets in numbers
- for a given ratio of IP/Legacy trunks in the configuration, the number of necessary DSP
channels
Note 1:
Configuration possibilities are not limited to the examples given in the table.
!"#$ % &'! % () !* % 141/151
Chapter 8 3
Figure 8.1: DSP Channel Needs With Direct RTP
Note 2:
The total number of DSP channels is:
- 16 without ARMADA VoIP32 daughter board
142/151 !"#$ % &'! % () !* %
3
- 48 with ARMADA VoIP32 daughter board

8.1.1.4 Case of DSP Channels Required Without Direct RTP
figure: DSP Channel Needs With no Direct RTP below illustrates DSP channels required by
VoIP services and shows how to calculate DSP needs.
From left to right, columns show:
- the number of terminals and the number of trunks necessary
- the mix of IP terminals and legacy sets in numbers
- for a given ratio of IP/Legacy trunks in the configuration, the number of necessary DSP
channels
Note 1:
Configuration possibilities are not limited to the examples given in the table.
!"#$ % &'! % () !* % 143/151
Chapter 8 3
Figure 8.2: DSP Channel Needs With no Direct RTP
Note 2:
The total number of DSP channels is:
- 16 without ARMADA VoIP32 daughter board
144/151 !"#$ % &'! % () !* %
3
- 48 with ARMADA VoIP32 daughter board
8.2 Configuration examples
8.2.1 H.323/SIP Gateway Only
Note:
Configuration possibilities are not limited to the example given in this section.
- 1 Attendant station (non-IP)
- 40 Reflexes stations (non-IP)
- 5 T0 accesses
- 4 VoIP network accesses (example: 2 to site A with a bandwidth = 64 KBps and 2
accesses to site B with a bandwidth = 64 KBps)
As all the DSP channels are associated with the H.323/SIP gateway (no IP telephony), the
number of DSP channels needed for this configuration corresponds to the number of VoIP
accesses, i.e. 4.
8.2.2 Small IP Telephony Configuration
Note:
- 16 IP sets
- 3 T0 (=6 channels)
The average number of DSPs needed for this configuration is 8.
8.2.3 Large IP Telephony Configuration
Note:
- 70 IP sets
- 1 T2 access with 30 channels
8.2.4 Average Configuration in Mixed Telephony: IP and Conventional

Telephony (DECT/PWT)
Note:
!"#$ % &'! % () !* % 145/151
Chapter 8 3
- 25 IP sets
- 25 DECT/PWT stations
- 6 T0 accesses
8.2.5 Average Configuration in Mixed Telephony: IP and Conventional

Telephony (Reflexes)
Note:
- 5 IP sets
- 40 conventional Reflexes stations
- 6 T0 accesses
The number of DSPs needed for this configuration is 4.
8.2.6 Medium Configuration for Mixed Telephony + H.323/SIP Gateway
Note:
- 5 IP sets
- 40 conventional Reflexes stations
- 4 T0 accesses
- 5 VoIP network accesses
- The number of DSP channels needed for IP telephony is Min(5,9) = 5
- The H.323/SIP gateway requires 5 additional DSP channels
8.2.7 Bandwidth
In an H.323/SIP gateway configuration, a bandwidth can be associated with each ARS table
entry to a remote H.323/SIP gateway.
Number of DSPs depending on call type:
- PIMphony IP or IP Phone
• IP Phone - IP Phone: 0 DSP
• IP Phone in conference: 1 DSP
• IP Phone or PIMphony IP - Reflexes station or analog/ISDN network: 1 DSP
• IP Phone or PIMphony IP - PC H.323 or H.323 gateway (IP trunk): 2 DSPs
- PC - PC: 0 DSP
146/151 !"#$ % &'! % () !* %
3
- PC with internal H.323 gateway - PC with internal H.323 gateway: 1 DSP

The following table indicates the potential number of simultaneous calls depending on the
bandwidth reserved for VoIP calls:
Data rate (bandwidth) Number of possible simultan- CODEC used
eous communications
55.6 Kbps (or less) 1 G.723.1/G729a
64 Kbps 2 G.723.1/G729a
128 Kbps 5 G.723.1/G729a
256 Kbps 10 G.723.1/G729a
512 Kbps 20 G.723.1/G729a
= 1024 Kbps Depends on the number of IP G.723.1/G729a
trunks
8.3 Limits
8.3.1 VoIP Services

Voice over IP services require a software key.
8.3.2 VoIP Channels on PowerCPU EE

VoIP channels are supported by DSP located on the board and on the daughter board.
- The PowerCPU EE board supports 16 VoIP channels
- The ARMADA VoIP32 daughter board (optional) supports 32 VoIP channels
8.3.3 DSP Channels

After a cold reset, all the DSPs are assigned to the VoIP subscriber channel pool by default.
The DSP assignment can be modified using OMC.
Any DSP assigned to the VoIP access pool is removed from the VoIP subscriber pool: it will
therefore no longer be available for IP telephony. Conversely, a DSP from the VoIP user pool
will not be able to be used for H.323/SIP gateway calls.
8.3.3.1 Restrictions due to limited number of DSPs
If the caller of a SIP phone is:
- A non IP terminal
- Behind an ISDN trunk
- Behind a SIP trunk if “direct RTP” flag is set to False
then a DSP is necessary to:
- To call a SIP phone
- To establish a conversation with the SIP phone
!"#$ % &'! % () !* % 147/151
Chapter 8 3
So, depending on the telephonic load and on the subscriber DSP numbers available on the
system (VoIP subscriber channels on OMC), the following restrictions exist:
- A SIP phone cannot be called
Note 1:
If the caller is external, the call is redirected to the attendant group, and if the attendant is only
composed of IP/SIP phones and if no DSP has become available in the meantime, the call is finally
redirected to the Automated Attendant
- A SIP phone could not retrieve a call that has previously been put on hold (since the DSP
is freed during the hold)
Note 2:
To prevent this second restriction, the following mechanism has been implemented: when a SIP
phone puts a call using a DSP on hold, the system reserves 1 DSP, up to the limit defined by the
noteworthy address DspOohRsv (DSP out of hold reservation).
This means that 1 DSP is reserved for the hold retrieval, when a SIP phone having a call on hold
(needing a DSP) exists in the system. The default value for the noteworthy address DspOohRsv is
2.
8.3.4 IP Sets
The theoretical limit on the number of IP sets + PIMphony IP stations that can be connected is
200, however:
- It is compulsory for the operator station to be a Reflexes station connected to a UA link,
which means that at least one UAI board must be installed in the system
- The IP sets are "deducted" from the limit on Reflexes stations
The Ethernet access of an IP set is at 10 or 10/100 MBps.
8.3.5 "VoIP Access" Channels : H.323/SIP Gateway

A DSP channel assigned to the pool of VoIP access channels is considered by the system to
be a public network access, that is to say "1 B channel".
OmniPCX Office Rich Communication Edition can have a maximum of 120 public network
accesses: the maximum number of DSPs assigned to the VoIP access pool is 48.
Network accesses (T0, T2, DLT2, DLT0, TL) + VoIP accesses = 120 max. accesses
8.3.6 ARS Entry

The number of entries in the ARS table with a remote H.323/SIP gateway as destination is
limited to 200.
The number of entries in the ARS table that make reference to a PC (individual entry or with a
range) is limited to 150.
148/151 !"#$ % &'! % () !* %

%
9.1 IP Telephony
9.1.1 Maintenance
9.1.1.1 Loss of IP connectivity
It takes several seconds to detect a loss of connection: the IP set attempts to restore the
connection for several seconds. During this period the user may observe a slowing in the
station displays resulting from repeated restoring and loss of connections.
9.1.1.2 Alcatel-Lucent 8 series stations: error messages
See: IP Touch 4008/4018 Phone - Maintenance, IP Touch 4028/4038/4068 Phone -
Maintenance and OmniPCX Office Glossary - Maintenance for 80x8 - Error and Information
messages.
9.2 Service Alarm Messages
9.2.1 Maintenance
The NMC (Network Management Center) application OmniVista 8770 enables the following
alarm messages specific to Voice over IP to be retrieved:
- Reset of the PowerCPU EE board equipped with the ARMADA VoIP32 daughter board
(message identical to those of the other boards in the system).
- PowerCPU EE board equipped with the ARMADA VoIP32 daughter board out of service.
• Diagnosis: reset and/or replace the board.
- DSP of the PowerCPU EE board equipped with the ARMADA VoIP32 daughter board out
of service.
• Diagnosis: reset and replace the PowerCPU EE board equipped with the ARMADA
VoIP32 daughter board if the fault persists or recurs.
- Ethernet interface of the PowerCPU EE board equipped with the ARMADA VoIP32
daughter board out of service.
• Diagnosis: check the connection to the LAN and possibly the LAN components (Hub,
switch, etc.).
- Ethernet interface of the PowerCPU EE board equipped with the ARMADA VoIP32
daughter board in service.
- Remote gateway xxxxx Out of Service.
• Diagnosis: check the IP connectivity with the remote gateway (LAN, intermediate IP
router) and the status of the remote gateway.
- Remote gateway xxxxx In Service.
- Automatic overflow: too much traffic to/from remote gateway xxxxx.
• Diagnosis: if this alarm occurs frequently, the bandwidth associated with this remote
!"#$ % &'! % () !* % 149/151
Chapter 9 (
gateway in the ARS table and the number of DSPs assigned to VoIP accesses must
be increased if possible.
- Automatic overflow: VoIP call to/from gateway xxxxx refused because "not enough VoIP
access channels available".
• Diagnosis: if this alarm occurs frequently, the sizing of the DSPs must be reviewed:
either the bandwidth in the ARS table must be increased, or the number of DSPs
assigned to VoIP accesses must be increased.
- IP Telephony failures: no more DSP channels available.
• Diagnosis: if this alarm occurs frequently, the number of DSPs assigned to the IP
subscriber pool must be increased (by reducing the number of VoIP access DSPs.
This alarm is generated every 10th (value by default) allocation failure.
- The IP set cannot be initialized because of a DHCP server fault (no IP addresses
available).
• Diagnosis: increase the number of IP addresses in the DHCP server range (this range
of IP addresses must be greater than or equal to the number of IP sets to be installed).
9.3 Service Traffic Counters
9.3.1 Maintenance
The VoIP services feature the following specific traffic counters accessible via OMC in the
menu: System Miscellaneous -> VoIP -> Traffic counters
9.3.1.1 "General" Tab
- Number of incoming VoIP calls
- Number of outgoing VoIP calls
- Number of transiting VoIP calls (Break In, Break Out)
- Number of outgoing VoIP calls to remote gateway xxxxx refused because "all VoIP access
channels busy" (Overloaded outgoing IP trunk groups)
- Number of incoming VoIP calls to gateway xxxxx refused because "all VoIP access
channels busy", (Incoming calls on no free IP trunks)
- Number of failed IP Telephony (audio) calls: all the DSP channels reserved for IP
Telephony are busy
Additional traffic counters are enabled only if OMC is connected to a system running OmniPCX
Office Rich Communication Edition R6.0 and beyond.
- No DSP free for calls through IP trunks. This counter is not used in the current
implementation, because there are as many DSP channels for IP trunks as there are IP
trunks. Overload on IP trunks will be reported on:
• Overloaded outgoing IP trunk groups
• Incoming calls on no free IP trunks
- Max. number of DSPs used at the same time for IP subs.
- Max. number of DSPs used at the same time for IP trunks
The last 2 counters give the maximum number of simultaneously used DSP channels since the
last cold restart or counters reset. The counters are saved on warm restart but not saved on
150/151 !"#$ % &'! % () !* %
(
swap with datasaving.

9.3.1.2 "Gateways" Tab
These counters indicate the number of VoIP calls to each of the remote VoIP gateways
refused for the following reasons:
- Overflow on outgoing VoIP calls: VoIP board out of service
- Overflow on outgoing VoIP calls: no more bandwidth available
- Incoming VoIP calls refused: no more bandwidth available
!"#$ % &'! % () !* % 151/151

Oxo10.3 SD Voipservices 8al91205usac 1 en

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oxo10.3 SD Voipservices 8al91205usac 1 en

Uploaded by

Copyright:

Available Formats

     

   

   ! " #$ %

The information presented is subject to change without notice.

ALE International assumes no responsibility for inaccuracies contained

Copyright © ALE International, 2016

In the interest of continued product development, ALE International reserves

 Quality of Service (QoS) ....................................................................... 11

 Overview ..................................................................................................... 15

 Configuring from an External DHCP ................................................ 17

 H.323 Gateway Services ....................................................................... 20

 Overview ..................................................................................................... 33

 Public SIP Trunking ................................................................................ 42

 Overview ................................................................................................... 132

 Overview ................................................................................................... 133

 Detailed description ............................................................................. 141

 IP Telephony ........................................................................................... 149

 Service Traffic Counters ..................................................................... 150

Documentation title Part number

Documentation title Part number

2.1 Quality of Service (QoS)

2.2 Environment tests

2.3 RTP proxy services

2.4 Direct RTP

RTCP RTCP RTP RTCP port number RTCP attribute

3.2 Home Worker

3.2.1 Detailed description

3.3 Remote Worker

3.3.1 Detailed description

3.4 Configuring from an External DHCP

3.5 Configuring PIMphony IP

3.5.1.3 Choosing the codec to used

4.1 H.323 Gateway Services

4.1.1 Detailed description

4.1.1.2 Gateway in an H.323 Area

4.1.1.3 Gateway Managed From Another OmniPCX Office Rich Communication

4.2 Service H.450

4.2.1 Detailed description

H.450.7: Camped-on call signaling Not supported

4.4 Configuring H.323 Gateway

4.4.1 Hardware configuration

1, the framing value must not be higher than 1.

4.5 Configuring a Remote H.323 Gateway

4.5.1 Configuration examples

- @IP1 : IP address of the PowerCPU EE board at site A

Destination IP Type IP address Host- Gateway Gateway Bandwidth Gateway

Bandwidth Number of simultaneous commu-

• Deactivated: Remote gateway absent / out of service

4.5.1.5 Forcing a public call to the H.323 gateway

Net- Access Range Substitute List. Called Party Comment Destination

Calling the site B station using its public number:

ARS table of site A: Network

5.1.1 SIP Protocol

Figure 5.1: H.323 and SIP in the OSI Model

5.1.3 Exchanging Messages

5.1.4 Message Formats

5.1.5 Example of a Dialog

Figure 5.2: Example of a dialog

5.1.6 Media Negotiation

Figure 5.3: Media Negotiation with an Offer in the INVITE Message

Figure 5.4: Media Negotiation with no Offer in the INVITE Message

5.1.6.1 Offer Description for Voice Communications

table 5.3: Offer Description

! " #$ %

Quality of Service (QoS) ....................................................................... 11

Overview ..................................................................................................... 15

Configuring from an External DHCP ................................................ 17

H.323 Gateway Services ....................................................................... 20

Overview ..................................................................................................... 33

Public SIP Trunking ................................................................................ 42

Overview ................................................................................................... 132

Overview ................................................................................................... 133

Detailed description ............................................................................. 141

IP Telephony ........................................................................................... 149

Service Traffic Counters ..................................................................... 150