)

6.1 SIP Generalities

6.1.1 Overview
6.1.1.1 Overview
The OmniPCX Enterprise is designed to support the Session Initiation Protocol (SIP). SIP is an
application-layer control protocol for establishing, controlling and terminating multimedia
sessions and phone calls.
The OmniPCX Enterprise offers:
- SIP terminal integration in the PCX environment. This allows SIP terminals to
communicate with internal PCX sets (TDM and IP sets) and gives them access to certain
PCX features.
SIP terminals can operate in one of the following modes:
• SIP sets operating in SIP End Point Level Of Service (SEPLOS) mode are configured
as SIP Extension in the Communication Server. Available as of R9.0, the SEPLOS
mode is dedicated to all SIP sets operating within the OmniPCX Enterprise. Declared
as local users, they have access to a large range of PCX phone services (see: SIP
End Point Level Of Service - Overview )
The Alcatel-Lucent IP Touch 4008/4018 phone Extended Edition sets can operate in
SEPLOS configuration.
• As of R10.0, Alcatel-Lucent IP Touch 4028/4038/4068 phone Extended Edition sets
can operate in NOE-SIP configuration. For more information, see: IP-Phones - 8 series
Operations - NOE Encapsulation in SIP .
• SIP terminals not operating in SEPLOS mode are configured as:
• SIP Device in the Communication Server. Up to R8.0, this mode is used by all SIP
sets declared as local users. As of R9.0, the SIP terminals operating in "SIP
device" mode ("non-SEPLOS" mode) are:
• Polycom video conferencing solution
• Mobile phones operating in dual mode (WIFI and cellular). In WIFI mode,
mobile phones are seen as SIP sets by the Communication Server (see: ACE /
My Cellular Extension - Overview)
The level of service offered to these SIP terminals is lower to that of SIP sets
operating in SEPLOS mode.
• External voice mail in the Communication Server (OpenTouch)
• SIP external gateway in the Communication Server (OpenTouch Fax Center)
Important:
The last two types of SIP terminals are not described in this documentation. For more
information on phone features supported and their configuration in the PCX, refer to the
corresponding documentation relating to these products.
- SIP trunking, used to connect the PCX to a public network (with the same level of service
as ISDN) or a private network (ABC-F). For more information, see: SIP Trunking -
Overview

128/915     


 !"  
 
 

6.1.2 Detailed description

6.1.2.1 SIP description
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) (see figure: H.323 and SIP in the OSI Model ) connected mode. 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 6.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
a user (as an 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

    

 !"  
  129/915
Chapter 6 

location server, which provides the user's actual address at the time of the call (URL of the
terminal 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.
As an option, SIP signaling can be protected by the TLS protocol and voice packets can be
protected by the SRTP protocol.
6.1.2.2 SIP characteristics
6.1.2.2.1 Addressing
The SIP protocol uses URLs. They can be constructed from:
- A name: sip:juliette@sip.mycompany.com
- A number: sip:5000@192.168.5.10
The numbers can also take on the form of standard numbers (base form):
sip:+497118245000@sip.mycompany.com.
The URLs include a domain segment (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.
6.1.2.2.2 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:
Request Comments
INVITE Message sent systematically by the client for any connection re-
quest
ACK Message sent by the client to end and to confirm the connection
request
PRACK Same role as ACK for provisional responses
BYE Message ending a call, RTP packet exchange is stopped
CANCEL Message ending a call currently being set up
SUBSCRIBE - NOTIFY Message used to subscribe to/notify an event (for example: new
voice mail message)
REGISTER Message sent by an agent to indicate his actual address. This in-
formation can be stored in the location server and is used for call
routing
REFER Message requesting an agent to call an address (used for trans-
fers)
INFO Message generating DTMF tone for SIP requests

130/915     


 !"  
 
 

Request Comments
UPDATE Message used for session parameter update and for the keep-
alive mechanism for established sessions

Responses are characterized by a code which is an integer:

Response Comments
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 conditions).
4xx, 5xx, and 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.
6.1.2.2.3 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.
Example of an INVITE message:
INVITE sip:juliette@sip.mycompany.com SIP/2.0
Via: SIP/2.0/UDP 155.132.76.10;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Juliette <sip:juliette@sip.mycompany.com>
From: Alice <sip:alice@155.132.36.1>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@155.132.76.10>
Content-Type: application/sdp
Content-Length: 142
For greater clarity, the body of the above message is not shown.
Header description
In the example of INVITE message presented above, some of these fields (or field parts)
identify transactions and dialogs. Certain fields provide caller and called party data:
- To: Juliette <sip:juliette@sip.mycompany.com>: address of the final called party of the
request. This is a logical address: it does not allow you 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: Alice <sip:alice@155.132.36.1>: address of initial request sender (logical
address).

    

 !"  
  131/915
Chapter 6 

Fields provide routing data in order to ensure that the response will transit through all the SIP
entities which processed the request.
- Via: SIP/2.0/UDP 155.132.76.10: indicates the origin of the request (physical address).
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:alice@155.132.76.10>: physical address of each interlocutor. For more
information, see: Contact Field details
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.
As of R9.1, the History-Info header is added to the INVITE message of a SIP call
forwarded from OmniPCX Enterprise to the SIP local gateway or a SIP external gateway. The
History-Info header is a field containing the user information of the SIP set programmed in
call forwarding (i.e. called party data). For more information, see: Call forwarding information
header details .
As of R10.0, the History-Info header can be replaced by the Diversion header to
transmit call forwarding information. For more information, see: Call forwarding information
header details .
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.
A SIP INFO message includes two additional fields: Signal and Duration.
- Signal: indicates the digit(s) for DTMF tone play. It can be one or several of the following:
0 to 9, *, #, A, B, C, and D.
- Duration: indicates the duration of DTMF tone play. It is between 100 and 1000
milliseconds (160 is the default value).
Contact Field details
Up to R9.0, user information (i.e. calling party data) does not appear in the Contact field. In a
typical configuration, the Contact field contains the SIP gateway IP address sent in the
outgoing calls.
Example:
Contact:<sip: IP address>
Some carriers authenticate and route outgoing SIP calls using the user information provided
by the Contact field. As of R9.1, user information is included in the Contact field of the
INVITE message enabling outgoing SIP calls to be routed to their addressee.
Examples 1:
Contact: <SIP:userinfo@IPaddress>
or Contact: <SIP:userinfo@hostname.DNS_local_domain_name>. The DNS local domain
name is a PCX option configured at the level of the SIP gateway (see: SIP - Configuration procedure -
Configuring the main SIP gateway )
The following scenarios indicate how the Contact field is completed according to the type of

132/915     


 !"  
 
 

call and user information provided by the Call Handling.

Examples 2:
Scenario 1:
A local SIP call for which the Call Handling provides the caller number (without secret identity). In this use
case, the Contact field contains the caller number in the user part.
Received from Call Handling:
From: 11001@172.19.66.10:5060 ; user=phone
SIP message sent on network:
From:<sip:11001@172.19.66.10> ; tag=00aaecc650e01974500c5a73de
Contact:<sip:11001@172.19.66.10;transport=UDP>
Scenario 2:
A SIP call through a SIP trunk group and an external gateway for which the Call Handling provides the
trunk group name (with or without secret identity). In this use case, the Contact field contains the
installation number of the trunk group in the user part.
Received from Call Handling:
From: SIP-ISDN@172.19.66.10:5060 ; user=name where SIP-ISDN is the installation number
SIP message sent on network:
From:<sip:SIP-ISDN@172.19.66.10> ; tag=00aaecc650e01974500c5a73de
Contact:<sip:99405@172.19.66.10;transport=UDP>

Call forwarding information header details

Overview
When a call is forwarded to a SIP external gateway, the INVITE message includes call
forwarding information. This information enables enhanced services.
Call forwarding information includes:
- The identity of the set which has initiated call forwarding
- The reason for call forwarding
This call forwarding information is transmitted in a field called header.
There are two header types:
- The History-Info header, available as of R9.1.
This optional field is compliant with RFC4244.
- The Diversion header, available as of R10.0.
This optional field is compliant with RFC5806.
Header selection is configured according to the external gateway.
Example
User B is forwarded to a SIP external gateway. User A calls user B. The call is forwarded to
the SIP external gateway.

    

 !"  
  133/915
Chapter 6 

Figure 6.2: External call forwarding example

The INVITE message is one of the following:
- When the History-Info header is configured:
............
To: User B <sip:11001@172.19.66.10;user=phone>
From: User A
<sip:11000@172.19.66.10>;tag=8d6c6652fe671da614fac4cf33c88720
Contact: <sip:11000@172.19.66.10;transport=UDP>
Call-ID: c11f90b85311dc8e583089c20c0ffd15@172.19.66.10
CSeq: 2062154840 INVITE
History-Info:<sip:11001@172.19.66.10?Reason=SIP;
cause=302;text="Moved Temporarily">;index=1
............
In the example above, the History-Info header provides:
• The cause parameter, used to indicate the reason for call forwarding, for example:
• 302 for immediate (or unconditional) call forwarding
• 486 for call forwarding on busy set
• 480 for call forwarding on no answer
• The index parameter, used to indicate the chronological order of call forwarding
information
In OmniPCX Enterprise configuration, the index parameter is always set to 1 (see:
Restrictions ).
- When the Diversion header is configured:
...............
To: "User B" <sip:110001@172.19.66.10;user=phone>
From: "User A"
<sip:11000@172.19.66.10>;tag=8d6c6652fe671da614fac4cf33c88720
Contact: <sip:172.19.66.10; transport=UDP>>
Call-ID: c11f90b85311dc8e583089c20c0ffd15@172.19.66.10
CSeq: 2062154840 INVITE
Diversion: <sip:11001@172.19.79.4>; reason=unconditional; counter=1
...................
In the example above, the Diversion header provides:
• The Reason parameter, used to indicate the reason for call forwarding, for example:
• Unconditional for immediate (or unconditional) call forwarding

134/915     


 !"  
 
 

• User Busy for call forwarding on busy set

• No-Answer (No reply) for call forwarding on no answer
• The Counter parameter used to indicate the chronological order of the information.
In OmniPCX Enterprise configuration, the Counter parameter is always set to 1 (see:
Restrictions ).
Interactions with other features
- OmniPCX Client Cellular (also called remote extension): a remote extension call is not
considered a forwarded call but an external call. The INVITE message contains a
History-Info header or Diversion header with the remote extension number but
without a cause or reason parameter.
ABC-F Network: call forwarding information is sent to the SIP external gateway even
when the call is transmitted via an ABC-F or a VPN link.
Restrictions
- The History-Info or Diversion header is not implemented for SEPLOS (SIP End
Point Level of Service)
- The Diversion header does not work for SIP local gateways
- The History-Info or Diversion header is ignored in all SIP requests received by the
OmniPCX Enterprise
- In case of cascading call forwarding, the History-Info or Diversion header contains
information on the last forwarded set. Only one header is present per SIP request.
- When a call is established between two different external SIP entities/gateways via the
OmniPCX Enterprise. If the OmniPCX Enterprise receives the History-Info or
Diversion header in any of the SIP requests from the SIP External gateway, this
History-Info or Diversion header is not added to the outgoing message sent to the
destination SIP entity. For example, a simple call is established from a SIP External
Gateway to OmniPCX Office via the OmniPCX Enterprise.

6.1.2.2.4 Example of a dialog

    

 !"  
  135/915
Chapter 6 

Figure 6.4: 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
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

136/915     


 !"  
 
 

with the results of SDP negotiation,

7. Two messages (BYE and 200 OK) end the dialog. RTP/RTCP channels are also released.
6.1.2.2.5 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 2327).
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 can take place at call setup or during an active session.
Note:
An INVITE message sent during an active session can also be called RE-INVITE.
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 6.5: 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.

Figure 6.6: Media negotiation with no offer in the INVITE message

6.1.2.3 PCX SIP components

This section describes the SIP components implemented in the OmniPCX Enterprise.

    

 !"  
  137/915
Chapter 6 

6.1.2.3.1 PCX SIP components overview

SIP gateway
The SIP gateway acts as an interface between the Call Handling and SIP proxy server:
- At phone signaling level (internal "sipmotor" function)
- At the level of voice channels on IP (use of "Direct RTP in network mode")
- At the level of SIP set integration into the PCX configuration database (numbering plan,
accounting, discrimination, voice mail assignment, etc.)
- At addressing format level ("SIP dictionary" function)
There is only one SIP gateway running on the OmniPCX Enterprise.
The SIP gateway becomes operational when the main SIP trunk group is created and
associated to the main SIP gateway.
The SIP gateway also requires the 185 SIP Gateway software license for running.
SIP dictionary
The SIP dictionary is a database indicating correspondences between PCX directory numbers
and SIP URLs. The dictionary is queried by the SIP gateway upon a call from, or to the SIP
environment.
Within the SIP dictionary, the same directory number can be associated with several SIP
URLs. Each URL corresponds to an alias number.
For an outgoing call, the first URL (alias 0) is used.
For an incoming call, the set can be called by any of its URLs.
The SIP dictionary is automatically updated as soon as a SIP terminal is configured on the
PCX (alias 0 automatically created). This situation also occurs for typical PCX sets when the
user name part of their URL is configured.
For sets already registered in the SIP dictionary, it is possible to create additional aliases or
modify existing URLs (see: SIP - Configuration procedure - Configuring the SIP dictionary ).
SIP registrar server
The SIP registrar server is in charge of collecting SIP terminal registration requests, and then
of transmitting the data to the SIP location server.
For a SIP terminal user, the registration consists in sending a REGISTER request to the SIP
registrar server. This request contains its actual IP address at a given time as well as the
period of validity of this IP address.
The set IP address is kept in the SIP registrar server until the requested period of validity is
reached, provided that this duration is included within the minimum/maximum values
configured on the SIP registrar server (see: SIP - Configuration procedure - Configuring the
SIP registrar server ).
A SIP terminal user can register under several addresses at the same time. In this case, the
call is routed to all his/her locations (physical URLs). The first location to answer takes the call
(forking feature).
SIP location server

138/915     


 !"  
 
 

The SIP location server contains the database of "logical" URL - "physical" URL (current
address to be actually called) relations. This database can be entered from SIP terminal
registrations, or using other means chosen by the manager.
When a communication is established, the INVITE request contains the logical URL of the
recipient user. This URL cannot be used to route the communication. On receiving the request,
the SIP proxy server consults the SIP location server to identify the user's actual URL, then
routes the request to this URL.
SIP proxy server
The SIP proxy server is an intermediate entity that operates as a client or a server by receiving
or transmitting requests from the SIP gateway, SIP terminals connected to this SIP proxy
server, and from SIP entities in other SIP domains. It has the task of routing the requests that
receive from other devices.
- If the request recipient SIP domain corresponds to the SIP domain of the SIP gateway or
of a SIP external gateway, the SIP proxy server and the SIP gateway attempt to locate the
recipient by consecutively consulting:
• The SIP user location database
• The SIP dictionary
• The PCX phone-book
If a single user is found, the call is routed. If no user is found, the call is refused. For a call
to the SIP environment, if several recipients are found, the call is routed to each recipient
(forking feature).
- If the recipient's SIP domain does not correspond to the SIP domain of the SIP gateway or
of a SIP external gateway, the SIP proxy server sends the request to this domain.
6.1.2.3.2 Relationships between PCX SIP components

    

 !"  
  139/915
Chapter 6 

Figure 6.7: Relationships between PCX SIP components

6.1.2.3.3 PCX SIP components operating mode examples

Example based on a SIP terminal call from a PCX set
1. User 4000 dials number 5000. Since the number 5000 is declared as a SIP set operating
in SEPLOS mode (or SIP device mode), the call is transmitted to the SIP gateway
2. The numbers must be converted to URLs: the SIP gateway consults the SIP dictionary

140/915     


 !"  
 
 

3. The SIP gateway sends to the SIP proxy server the INVITE request with the URLs found
in the SIP dictionary; the fields are constructed as follows:
• To: <sip:john@oxe.mycompany.com>
• From: "Lastname Firstname" <sip:smith@oxe.mycompany.com> 1
• Contact: <sip:smith@192.168.3.2;transport=tcp> 2
4. The SIP proxy server consults the SIP location server to find the current URL of the
requested SIP set
5. If the SIP set has registered, the proxy fills in the Request URI field with the IP address
provided by the SIP set at registration, the call can be transmitted

Figure 6.8: Call routing from a PCX set to a Sip set

Example based on a PCX set call from a SIP terminal

1. The SIP set with URL <sip:john@oxe.mycompany.com> sends an INVITE request to its
connection proxy (SIP proxy server), for a call to the URL
<sip:smith@oxe.mycompany.com>
2. The SIP proxy server compares the domain part of the address with its own domain name;
since they match, it consults the SIP location server which contains the data of the
registered sets
3. The SIP location server cannot identify the requested user (the requested set is not a SIP
set); the INVITE request is then transmitted to the SIP gateway
4. The SIP gateway consults the SIP dictionary: in the SIP dictionary, the requested address
corresponds to an alias of the number 4000
5. The SIP gateway transmits the call request to the 4000

1
If no URL had been configured for this set, the address would have been
<sip:4000@oxe.mycompany.com>.
2
The URL of the Contact field is constructed from the user part (i.e. calling party data).

    

 !"  
  141/915
Chapter 6 

Figure 6.9: Call routing from a SIP set to a PCX set

6.1.2.3.4 SIP services offered to SIP devices

Terminal URL declaration on the PCX
To operate with the OmniPCX Enterprise, a SIP terminal must be declared on the
Communication Server and its URL (user and domain parts) must be defined.
Configuring a SIP terminal automatically creates its record in the SIP dictionary, as well as for
typical PCX sets when their URLs have been configured. This operation does not occur for SIP
terminals seen as SIP external Gateways, like the OmniTouch Fax Server.
Here is an example with several SIP terminals and a TDM set.
table 6.3: SIP terminals and TDM sets Configuration
Directory Number 5000 6525 4000
Set Type SIP device External voice 4035 (Reflexes)
(mobile set in mail
dual mode) (OmniTouch
UC)
URL User Name John 6525 martin3
URL Domain oxe.mycompany 192.168.3.6 –
.com

In this example, a record is also created for the TDM set because its URL (user part) has been
configured. Its URL (domain part), left blank, takes gateway FQDN as default value. User 4000
can thus be called from the SIP environment via the address
<sip:martin@oxe.mycompany.com>.
Please note that it is not mandatory to use names in the URLs. It is also a good solution to use

3
For a classic (standard) set, URL configuration is not mandatory.

142/915     


 !"  
 
 

directory numbers. Likewise, it is not mandatory to use FQDN in the URLS (it implies the use
of a DNS). It is possible to use exclusively IP addresses.
If URL User Name and URL Domain are not filled in the SIP terminal configuration
parameters, the address is constructed as follows:
directory_number@PCX_main_IP_address, for example for John, the address would be
<sip:5000@192.168.3.2>.
table 6.4: Records in the SIP Dictionary
Directory Number 5000 6525 4000
Alias No. 0 0 0
SIP URL Username John 6525 martin
SIP URL Domain oxe.mycompany.co 192.168.3.6 oxe.mycompany.com4
m
SIP URL Type Subscriber Voice Mail Subscriber

SIP terminals registration

SIP terminals must register with their IP address in order to be called.
On start-up, a SIP terminal sends a REGISTER request to the SIP registrar server. The SIP
registrar server, in turn, transmits data to the SIP location server.
SIP terminals registration can be performed with or without authentication, see: Authentication
.
When authentication is required, all unauthenticated registration requests are rejected.
When authentication is not required, if the option Only authenticated incoming calls or
Reject unidentified proxy calls is enabled, registration requests form unknown SIP end
points are rejected.
Registration data contain its logical address with URL name and domain (ex:
sip:john@oxe.mycompany.com) or its physical address with IP address (ex:
sip:john@192.168.3.2). From then on, the SIP terminal can be called.
Authentication
The purpose of authentication is to prevent identity abuse and to guarantee that accounting
and discrimination (restrictions) apply to the correct terminals.
If authentication is enabled, name and password are requested by the SIP proxy server, which
specifies authentication realm name in the request. A realm is the domain in which a
name-password pair is valid. On the SIP set, a name-password pair must be configured for
each realm in which it is likely to be used for authentication.
The authentication supported by the OmniPCX Enterprise is digest type: Passwords are never
circulated "in clear" (uncoded) on the network.
The Minimal Authentication Method parameter is used to enable authentication. When the
parameter is set to SIP Digest, authentication is mandatory.
A Minimal Authentication Method parameter is configured:
- At system level (SIP Proxy)

4
The URL (domain part) is entered automatically with the system's FQDN.

    

 !"  
  143/915
Chapter 6 

- At SIP Ext Gateway level: this parameter is used by the external gateways and, as of
R11.2, by SIP devices and external voice mails "behind" the external gateway
If authentication is enabled, it is required for:
- REGISTER requests (depending on configuration)
- INVITE requests from sets declared in PCX configuration data
- REFER requests: this means that sets that are not declared on the PCX cannot request
transfer
- All INVITE and REFER requests, if the Only authenticated incoming calls parameter of
the SIP proxy server is selected: this means that only SIP terminals declared in
configuration data can call the OmniPCX Enterprise
For a SIP terminal to be able to authenticate itself:
- It must be declared on the OmniPCX Enterprise with a name and password.
- Name and password must be registered on the SIP terminal with the name of the
OmniPCX Enterprise proxy realm.
On the PCX, incoming call authentication data may be configured:
- In SIP proxy server parameters (see: SIP - Configuration procedure - Configuring the SIP
proxy server )
- In SIP external gateway parameters: all sets calling from "behind" a gateway use the same
authentication parameters
6.1.2.4 Available features

Feature Comments
SIP end-to-end call Communications between SIP terminals are enabled
when they belong to the same node (1)
Set up, reception and release of outgoing and incoming
Basic call
calls with codec negotiation
Fax call T.38 Fax over IP
DTMF sending See: DTMF transmission mode
Simultaneous calls can be established between the PCX
Multiline
and any SIP terminal
Calling Line Identification Presentation/Calling Line Identi-
CLIP/CLIR
fication Restriction
COLP/COLR Connected Line Identification/Connected Line Restriction
Do not Disturb
Call forwarding
Call hold
Attended transfer
Unattended transfer
Authentication for incoming calls See: Authentication
PCX numbering plan SIP terminals appear in the PCX numbering plan

144/915     


 !"  
 
 

Feature Comments
Dial by name SIP terminals can be called using dial by name
Barring (i.e. discrimination) when SIP terminals class of service are used instead of the
calling PSTN trunk groups trunk groups class of service
Accounting when calling PSTN
SIP terminals are charged instead of the trunk groups
trunk groups
Voice mail use SIP terminals can have a voice mailbox
SIP terminals can be notified of new incoming voice mail
Message waiting indication
messages
Conference SIP terminals can participate to conferences
Call overflow on busy/no answer SIP terminals can program call overflow to entity
Call Admission Control (CAC) and
See: Call Admission Control (CAC)
PCX IP domains
Spatial redundancy See: Configuring DNS addresses on SIP end-points

(1)
: SIP messages exchanged into SIP end-to-end communications are:
- For releases prior to R7.0, all SIP messages exchanged by SIP terminals controlled by the
same SIP gateway
- For releases higher than or equal to R7.0, with the Call Admission Control (CAC) set to:
• Off: all SIP messages exchanged by SIP devices controlled by the same SIP gateway
• On: all SIP messages not relating to the following SIP features: presence and Instant
Messaging (IM).
6.1.2.5 Standard documents
Organization:
- Internet Engineering Task Force (IETF)
Work Groups:
- http://www.ietf.org/html.charters/sip-charter.html
- http://www.ietf.org/html.charters/sipping-charter.html
References:
- RFC 1889: RTP: A Transport Protocol for Real-Time Applications
- RFC 2327: SDP: Session Description Protocol
- RFC 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
- RFC 2976 : The SIP INFO method
- RFC 3261 SIP: Session Initiation Protocol
- RFC 3262 Reliability of Provisional Responses in the Session Initiation Protocol (SIP)
- RFC 3263 Session Initiation Protocol (SIP): Locating SIP Servers
- RFC 3264 An Offer/Answer Model with Session Description Protocol (SDP)
- RFC 3265 Session Initiation Protocol (SIP) - Specific Event Notification
- RFC 3327 Session Initiation Protocol (SIP) Extension Header Fi
- RFC 3515 The Session Initiation Protocol (SIP) REFER Method

    

 !"  
  145/915
Chapter 6 

- RFC 3608 Session Initiation Protocol (SIP) Extension Header Field for Service Route
Discovery During Registration
- RFC 3725 Third Party Call Control (3pcc): flow I
- RFC 3842 A Message Summary and Message Waiting Indication Event Package for the
Session Initiation Protocol (SIP)
- RFC 3891 The Session Initiation Protocol (SIP) "Replaces" header
- RFC 3892 The Session Initiation Protocol (SIP) Referred-By Mechanism
- RFC 4028 Session Timers in the Session Initiation Protocol
- RFC 4244 Extension to the Session Initiation Protocol (SIP) for Request History
Information
- RFC 5806 Diversion Indication in SIP
- draft-ietf-mmusic-sdp-new-21.txt (SDP)
- draft-ietf-sip-cc-transfer-05.txt: transfer
- ITU-T T.38 (04/2004): ITU–T Procedure for Real–time group 3 facsimile communications
over IP network
6.1.2.6 Keep-alive mechanism for established sessions
6.1.2.6.1 Basic principle
RFC 4028 defines a keep-alive mechanism for established sessions.
The keep-alive mechanism consists in a periodic exchange of messages between User Agents
in communication to check that the current session is still active.
The keep-alive parameters of a session include:
- Which party is the refresher, i.e. in charge of sending session refresh requests: UAC (User
Agent Client) or UAS (User Agent Server)
- The session timer value
These parameters are negotiated at session establishment.
Exchanges are as follows:
- The refresher sends periodic session refresh requests: this can be RE-INVITE or UPDATE
messages
- The User Agent at the other side acknowledges the request with a 2xx response
If the refresher receives no response before the session timer expires, the session is
considered terminated. Similarly, if the other side gets no session refresh request before the
session expires, the session is considered terminated.

146/915     


 !"  
 
 

Figure 6.10: Keep-alive exchanges example

6.1.2.6.2 Implementation on the PCX

The OmniPCX Enterprise complies with RFC 4028 (Session Timers in the Session Initiation
Protocol).
Up to R8.0.1, the OmniPCX Enterprise only supports the RE-INVITE method.
As of R9.0, the OmniPCX Enterprise supports both RE-INVITE and UPDATE methods.
The keep-alive mechanism applies to all SIP to SIP communications.

Figure 6.11: Example of keep-alive dialog using the UPDATE method

    

 !"  
  147/915
Chapter 6 

Figure 6.12: Example of keep-alive dialog using the INVITE method

A configuration parameter allows to select the method to be used when the PCX SIP gateway
is in charge of sending the keep-alive requests:
- If RE-INVITE is selected, the SIP gateway always uses this method (even if the remote
SIP party supports the UPDATE method).
- If UPDATE is selected, the SIP gateway uses this method provided the remote SIP party
supports the UPDATE method.
The session timer value and Min Session timer can also be configured.
These configuration parameters apply to all types all SIP communications, whether involving
the main gateway, an external gateway or SEPLOS terminals.
6.1.2.6.3 Operation
When the RE-INVITE method is selected as Session Timer Method, the SIP gateway always
uses this method (even if the remote SIP party supports the UPDATE method).
When the UPDATE method is selected as Session Timer Method:
- If the remote SIP party indicates in the INVITE or 200 OK message that it supports the
UPDATE method, the SIP gateway uses the UPDATE method.
- If the remote SIP party does not indicate in the INVITE or 200 OK message that it supports
the UPDATE method (whether it really does not support it or supports it but does not
indicate it in the allow header), the SIP gateway uses the RE-INVITE method.

148/915     


 !"  
 
 

Figure 6.13: Example of keep-alive dialog when UPDATE is selected as Session Timer Method
- If the SIP gateway sends an UPDATE as session refresh request to the SIP device and
then receives a 405 message (Method Not Allowed), then the subsequent session refresh
requests are sent using the RE-INVITE method.

    

 !"  
  149/915
Chapter 6 

Figure 6.14: Example of keep-alive dialog when a 405 message is received

6.1.2.6.4 UPDATE method processing by the SIP gateway

Up to R8.0.1, the UPDATE method is never accepted by the SIP gateway of the OmniPCX
Enterprise.
As of R9.0, an UPDATE method is accepted and taken into account in the following cases:
- A remote SIP entity sends an UPDATE method as session refresh request. The SIP
gateway replies with a 200 OK.
- After the session establishment, the remote SIP entity sends an UPDATE method for a
session renegotiation (SDP modification). If the modification can be taken into account, the
SIP gateway replies with a 200 OK.
Up to R9.0, an UPDATE method is not accepted in the following case:
- A remote SIP entity sends an UPDATE message during the session establishment. The
message is not taken into account and the SIP gateway replies with a 488 (Not Acceptable
here)
As of R9.1, an UPDATE method is accepted and taken into account when a remote SIP entity
sends an UPDATE message during the session establishment. For more information on
session negotiation using the UPDATE method, see: SIP Trunking - Detailed description -
Negotiation with the UPDATE message .
6.1.2.7 DNS (Domain Name System)
6.1.2.7.1 DNS basic principles
The DNS is a directory system distributed on Internet.
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.
DNS A
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.
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

150/915     


 !"  
 
 

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
Note:
The Weight field of a DNS SRV RR is not taken into account by the OmniPCX Enterprise.
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
to perform a DNS A query (or AAAA for IPV6) for this domain.
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.
The figure: Process for locating a SIP server describes the process followed to locate a SIP
server starting from a given URI.

    

 !"  
  151/915
Chapter 6 

Figure 6.15: Process for locating a SIP server

6.1.2.7.2 Implementation on the PCX

Up to R8.0.1, the OmniPCX Enterprise offers only a DNS A mechanism, which enables the
resolution of a name into an IP address.

152/915     


 !"  
 
 

As of R9.0, the OmniPCX Enterprise offers also a DNS SRV mechanism which enables a
resolution of service/name into a group of IP addresses.
For the main gateway and each external gateway, a configuration parameter allows to select
the type of DNS resolution. According to this parameter, a name resolution will result in a DNS
A or DNS SRV request.
NAPTR is not implemented on the OmniPCX Enterprise. The protocol selected in the gateway
parameters is used.
DNS cache
To speed up call set up and also to limit exchanges on the IP network, OmniPCX Enterprise
holds a cache containing DNS RR (SRV and A) records.
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 6.16: Example of dialog

Unavailable proxy list

    

 !"  
  153/915
Chapter 6 

To avoid sending useless requests to unreachable proxies, OmniPCX Enterprise can hold a
list of unavailable proxies.
An unavailable proxy IP address is stored in the list during a specific timer fixed to four hours.
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
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.
6.1.2.8 DTMF transmission mode
The OmniPCX Enterprise DTMF transmission mode complies with RFC 2833 (RTP payload
for DTMF digits).
As of R8.0, the OmniPCX Enterprise SIP network elements support the SIP INFO method to
generate DTMF tones along the signaling path to activate Integrated Cellular Client features
(for mobile phones operating in dual mode and configured as SIP device).
The SIP INFO method provides:
- DTMF digits along the SIP signaling path
- DTMF tone generation for SIP requests
The Info Method for remote extension parameter defined in the SIP gateway and SIP
external gateway must be activated to enable the SIP INFO method.
6.1.2.9 Call Admission Control (CAC)
6.1.2.9.1 Overview
The aim of Call Admission Control is to control the number of voice communications between
IP telephony domains in order to take into account the bandwidth limitation on the IP network.
Call Admission Control operates as follows: for each domain, a maximum number of
extra-domain communications (with other domains) is defined. A communication between two
parties belonging to different domains is authorized only when the maximum numbers of
extra-domain communications are not reached for the calling and called party domains. There
is no control on communications between two parties belonging to the same domain.
Communications involving SIP terminals operating in SEPLOS mode are always taken into
accoung by CAC.
Communications involving two SIP devices (not operating in SEPLOS mode) are taken into
account by CAC if the CAC SIP-SIP parameter is enabled (see SIP - Configuration procedure
- Configuring the main SIP gateway ). This parameter is available as of R7.1.
If the CAC SIP-SIP parameter is disabled, SIP flows for communications between two SIP
devices are handled by the SIP proxy server, as indicated on figure: SIP flows when CAC

154/915     


 !"  
 
 

SIP-SIP is disabled . This entails that:

- The communication benefits from transparency to SIP headers.
- All types of media and codecs are accepted.

Figure 6.17: SIP flows when CAC SIP-SIP is disabled

If CAC SIP-SIP is enabled, SIP messages initiating and releasing a communication between
two SIP devices are handled by call handling, as indicated on figure: SIP flows when CAC
SIP-SIP is enabled . This entails that:
- There is no transparency to SIP headers.
- Only media and codecs supported by OmniPCX Enterprise are accepted (codec is
negotiated as indicated in Direct RTP in network - Coding configuration ).

    

 !"  
  155/915
Chapter 6 

Figure 6.18: SIP flows when CAC SIP-SIP is enabled

6.1.2.9.2 SIP to legacy set communication

Incoming call
The IP domain of the calling SIP device is obtained from the information in the INVITE
message:
- If the calling and called parties belong to the same domain, the call is accepted.
- If the calling and called parties do not belong to the same domain, the call is accepted only
when the maximum number of authorized extra-domain calls of the two domains are not
reached. If one of these thresholds is reached, the call is rejected.
Outgoing call
The IP domain of the called party is obtained from the information of the 2xx response
message. The principle for call authorization is the same as for an incoming call.
6.1.2.9.3 SIP to SIP communication

156/915     


 !"  
 
 

SIP to SIP communication Set up

The SIP proxy server receives an INVITE message:
- If the system option is not enabled, the call is accepted without further control. The
INVITE message is treated by the proxy server with no intervention from the gateway
- If the system option is enabled, the INVITE message is sent to the gateway, which
searches the IP address of the called party in the localization base:
• If the called party is known in the localization base, its IP domain number is compared
to the IP domain number of the calling party
• If the calling and called parties belong to the same domain, the call is accepted.
• If the calling and called parties do not belong to the same domain, the call is
accepted only when the numbers of extra-domain calls of the two domains are
below the maximum authorized numbers. If one of these thresholds is reached, the
call is rejected.
• If the called party is not known in the localization base, the called party domain is
obtained in the 2xx response message.
• If the called party belongs to the same domain as the calling party, the call is
accepted
• If the called party does not belong to the calling party domain, the call is accepted
provided the maximum number of external calls for the calling party and called
party domains are not reached.
When a call is accepted, a 305 message (Use Proxy) is sent to the SIP proxy server.
Subsequent messages do not transit through the gateway.
Active SIP to SIP communication
Session timer
When a SIP to SIP communication is active, a keep-alive mechanism enables to check that
the communication has not ended. If the communication has ended, the counters of IP
telephony domains are decreased.
For more information on the keep-alive mechanism, see: Keep-alive mechanism for
established sessions .
RE-INVITE
When an external SIP subscriber sends a RE-INVITE message:
- If the codec has changed, the call is accepted except when the new codec is G711
whereas the former codec was G723 or G729
- If the IP address of the media has changed, a CAC control is performed with the new IP
address. If the result of this new control is negative, the call is rejected
6.1.2.9.4 Communications with a SIP trunk group
In the case of a communication to or from a SIP trunk group, the domain taken into account is
the domain of the SIP external gateway.
Note:
There is no difference between internal calls and SIP trunking calls as regards Call Admission Control.
The same counters are used for all calls.

    

 !"  
  157/915
Chapter 6 

As of R11.0.1, each SIP trunk group and each ABC-IP trunk group has its own maximum
number of simultaneous calls. This number is set by the installer according to the gateway
capacity and the used compression algorithm.
6.1.2.9.5 Consequence of CAC activation on SIP features
If CAC is not activated, two SIP devices attached to the same SIP gateway (same node)
benefit from end-to-end SIP communications. This means that these devices can use SIP
features that are not supported by the OmniPCX Enterprise (video, presence).
If CAC is activated, two SIP devices attached to the same SIP gateway (same node) do not
benefit from end-to-end SIP INVITE dialogs. This means that, if CAC is activated, video is not
available. However other SIP messages outside INVITE dialogs (presence, IM) still work
end-to-end.
Note:
In both cases, two SIP devices attached to different SIP gateways on different nodes do not benefit from
end-to-end SIP communications (the signaling goes through the SIP motor). This means that these
devices can only use the SIP features supported by the OmniPCX Enterprise. SIP video or presence are
rejected by the OmniPCX Enterprise.

6.1.2.9.6 Restrictions
SIP sessions established for a media different from audio between two external SIP
subscribers are not taken into account by Call Admission Control.
CAC counters are not decreased in two cases:
- In case or Communication Server Switch-over
- In case of SIP to SIP communication end when the IP network is shutdown: in this case,
the gateway cannot be notified of the end of the call.
6.1.2.10 Configuring DNS addresses on SIP end-points
This section describes the configuration of the SIP proxy and DNS addresses on SIP End
Points in a duplication configuration where the two Communication Servers are on two
different subnetworks (spatial redundancy).
6.1.2.10.1 Overview
To make calls, SIP terminals require a SIP proxy server address. In an OmniPCX Enterprise,
this SIP proxy server is integrated into the Communication Server. In most configurations, the
address for this proxy server is the Communication Server main address (or its associated
hostname, when configured).
In a duplicated Communication Server configuration where the two Communication Servers
are on the same subnetwork, the main Communication Server address is usually the same for
the two Communication Servers. In this way, when there is a switchover between the main
Communication Server and the stand-by Communication Server, SIP terminals still operate
normally.
As of R6.1, the system caters for duplicated Communication Server configurations where the
two Communication Servers are on different subnetworks. In such cases, the main IP address
for Communication Server A and the main IP address for Communication Server B must be
different.
On a SIP terminal, one single IP address can be configured for the SIP proxy server. When the

158/915     


 !"  
 
 

two Communication Server addresses are different, use the node name for the SIP proxy
server. This node name is resolved by the DNS feature implemented on the OmniPCX
Enterprise.
6.1.2.10.2 DNS implementation on PCX
The DNS server allows for the resolution of node name only.
DNS requests are sent to the Communication Server(s). In a duplicated configuration, only the
main Communication Server replies to DNS requests by sending its main IP address.
The DNS feature is activated via netadmin (see: netadmin - Operation).
6.1.2.10.3 Configuration
Network configuration with no Client DNS server
In a configuration where no client DNS server is used, SIP terminals send DNS requests to the
two Communication Servers.
On the SIP terminal, enter:
- As primary DNS address: the main IP address of Communication Server A
- As secondary DNS address: the main IP address of Communication Server B

The Communication Server currently acting as main Communication Server is the only one
that answers a DNS request.

    

 !"  
  159/915
Chapter 6 

The DNS reply sent to the SIP terminal contains the IP main address of the Communication
Server sending the reply.
Note:
To ensure that this information is not cached (and reused after a switchover between the two
Communication Servers), keep 0 as the value of the The Time-To-Live parameter.

Network configuration with a client DNS server

In configurations where a DNS Server is in operation, this server must be maintained to deal
with all DNS requests on the network.
On the SIP terminal, enter as primary DNS address: the address of the client DNS server
The client DNS server must be configured to forward requests on the node name (or on the
area identified by the DNS suffix) to the two Communication Servers making the node.
Caution:
When forwarding applies to the area identified by the DNS suffix, the DNS service only allows for
resolution of the SIP proxy server address.

160/915     


 !"  
 
 

The Communication Server acting as "main" is the only Communication Server that replies to
the client DNS server request, which forwards it to the SIP terminal.

    

 !"  
  161/915
Chapter 6 

Note:
In some configurations, forwarding to hosts is slowed down by time-outs between hosts. This problem
can be avoided by:
1. On the SIP terminal, the address of one of the Communication Servers is used as primary DNS
address,
2. On the SIP terminal, the client DNS server address is used as secondary DNS address,
3. Configuring the client DNS server to forward requests related to the SIP proxy server (node name) to
the second Communication Server.
Input/output channels
This service is based on packets received on port 53/UDP in DNS format.
This service is restricted: it does not include all requests defined in the DNS protocol, but
manages requests related to the hostname that corresponds to the node name as defined in
netadmin.
When a DNS suffix is added by the SIP terminal, it is ignored in name resolution.
The reply to a correct DNS request contains an answer section detailing:
- NAME: i.e. requested domain name (<node_name>[DNS_suffix])
- TYPE: 0x01 (address)
- CLASS: 0x01 (internet)
- TTL: 0 (nothing stored in cache)

162/915     


 !"  
 
 

- RDLENGTH: length of an IP address

- RDATA: main IP address of the Communication Server
6.1.2.11 Com server switchover
This section deals with interactions between Communication Server switchover and SIP
trunking (private and public) and SIP devices. This section does not describe interactions
between Communication Server switchover and SIP terminals operating in SEPLOS mode.
6.1.2.11.1 Overview
Before R9.0, all SIP communications are released when a switchover to the backup
Communication Server occurrs.
As of R9.0, some SIP communications are maintained when a switchover occurs, depending
on:
- The call state:
• active state: SIP call being set up
• stable state: SIP call established
• unstable state: SIP call switching from a stable state (i.e. in conversation) to another
state different from idle (ex: call put on hold).
- The origin of the call
6.1.2.11.2 SIP communications behavior at switchover
When the state of a communication changes, the main Communication Server systematically
updates the stand-by Communication Server with the relevant information (PCX SIP
components data and associated state).
When a switchover occurs, calls are processed as follows:
- Calls in active state are released except incoming calls from a SIP external gateway
(private and public SIP trunking feature), which are routed to the relevant entity
- Calls in stable state are maintained except some of them, such as calls established to an
internal voice mail, which are released. In a three party conference, only one of the two
calls is maintained
- Calls in unstable state are released except incoming calls from a SIP external gateway
(private and public SIP trunking feature), which are routed to the relevant entity
Generally, the SIP communications processing at Communication Server switchover is similar
to that of traditional communications. The existing restrictions also apply to SIP
communications.
When the CAC SIP-SIP parameter is enabled, SIP to SIP communications are not affected by
the Communication Server switchover because they are processed by the SIP proxy server.
When a switchover occurs, the SIP to SIP communications are maintained.
6.1.2.11.3 SIP registration
Communication Server switchover is transparent for SIP external gateways and SIP devices
as regards SIP registration.
A Communication Server switchover does not require new SIP terminals registration. The SIP
location database is identical in the main and stand-by Communication Servers.

    

 !"  
  163/915
Chapter 6 

6.1.2.11.4 Session and supervision timers

When a switchover occurs:
- The session timer is updated on the Stand-by Communication Server. The session timer is
a keep alive mechanism applies to all SIP to SIP communications (see: SIP - Detailed
description - Keep-alive mechanism for established sessions )
- The supervision timer is updated on the Stand-by Communication Server. The supervision
timer is a keep alive mechanism available out of SIP communications (optional)
6.1.2.12 PCX software version upgrade
As of R9.0, the standard mode for SIP set configuration in the OmniPCX Enterprise is
SEPLOS mode. They are declared as SIP extension local users in the PCX.
When upgrading the Communication Server software version from a release lower than R9.0
to R9.0 of higher, all SIP sets previously configured as Extern station (called SIP device as of
R9.0) are converted into SIP Extension, except for OmniTouch Fax Server and OmniTouch
UC which keep their initial configuration.
To allow these SIP terminals to operate as SIP device, it is recommended to save their data
before upgrading the PCX software version.
6.1.2.13 Mapping between call handling error causes and SIP error responses
When a call cannot be established between an ABC-F/ISDN network and a SIP network
(interconnected by the OmniPCX Enterprise), a call failure message is sent to the network of
the called party.
If the call failure occurs in the ABC-F/ISDN network, the call failure message contains a Call
Handling error code indicating the reason for failure.
This Call Handling error code is mapped to a SIP error response in the PCX. which is sent to
the SIP network.
Call failure processing is similar when a call failure message is received from the SIP network.
The SIP error response received by the PCX is mapped to a Call Handling error code.
As of R9.1, it is possible to customize mapping between Call Handling error causes and SIP
error responses (see: SIP - Configuration procedure - Customizing mapping between call
handling causes and SIP responses ).
The following table lists the default mapping of Call Handling error causes to SIP error
responses.
Note:
Call Handling error causes not listed in the table are mapped by default to 500 Server Internal
Error
table 6.6: Default mapping: call handling causes to SIP responses
Call Handling Cause Default SIP Response
1 unallocated number 404 Not Found
2 no route to specify transit network 404 Not Found
3 no route to destination 404 Not Found
4 (France specific) 502 Bad Gateway

164/915     


 !"  
 
 

Call Handling Cause Default SIP Response

5 (Denmark specific) 410 Gone
6 channel unacceptable 502 Bad Gateway
7 call awarded and being delivered in an estab- 502 Bad Gateway
lished channel
8 (Reserved MLPP) 502 Bad Gateway
16 normal call clearing 502 Bad Gateway
17 user busy 486 Busy Here
18 no user responding 480 Temporarily Unavailable
19 no answer from user (user alerted) 480 Temporarily Unavailable
21 call rejected 603 Decline
22 number changed 410 Gone
26 non-selected user clearing 502 Bad Gateway
27 destination out of order 480 Temporarily Unavailable
28 invalid number format 484 Address Incomplete
29 facility rejected 488 Not Acceptable Here
30 response to status enquiry 502 Bad Gateway
31 normal unspecified 502 Bad Gateway
34 no circuit/channel available 503 Service Unavailable
38 network out of order 502 Bad Gateway
41 temporary failure 503 Service Unavailable
42 switching equipment congestion 502 Bad Gateway
43 access information discarded 502 Bad Gateway
44 requested circuit/channel not available 503 Service Unavailable
46 (USA specific) 502 Bad Gateway
47 resources unavailable, unspecified 502 Bad Gateway
49 quality of service unavailable 503 Service Unavailable
50 requested facility not subscribed 503 Service Unavailable
57 bearer capability not authorized 488 Not Acceptable Here
58 bearer capability not presently available 503 Service Unavailable
63 service or option not available, unspecified 503 Service Unavailable
65 bearer capability not implemented 501 Not Implemented
66 channel type not implemented 502 Bad Gateway
69 requested facility not implemented 503 Service Unavailable
70 only restricted digital information bearer capabil- 503 Service Unavailable
ity is available
79 service or option not implemented, unspecified 503 Service Unavailable
81 invalid call reference value 502 Bad Gateway
82 identified channel does not exist 502 Bad Gateway

    

 !"  
  165/915
Chapter 6 

Call Handling Cause Default SIP Response

83 a suspended call exists, but this call identify 502 Bad Gateway
does not
84 call identity in use 500 Server Internal Error
85 no call suspended 502 Bad Gateway
86 call having the requested call identity has been 502 Bad Gateway
cleared
87 (Japan specific) 488 Not Acceptable Here
88 incompatible destination 488 Not Acceptable Here
91 invalid transit network selection 502 Bad Gateway
95 invalid message, unspecified 500 Server Internal Error
96 mandatory information element missing 500 Server Internal Error
97 message type non-existent or not implemented 500 Server Internal Error
98 message not compatible with call state 500 Server Internal Error
99 information element non-existent or not imple- 500 Server Internal Error
mented
100 invalid information element content 500 Server Internal Error
101 message not compatible with call state 500 Server Internal Error
102 recovery on timer expiry 500 Server Internal Error
111 protocol error, unspecified 500 Server Internal Error
127 interworking, unspecified 500 Server Internal Error

The following table lists the default mapping SIP error responses to Call Handling Error
causes.
table 6.7: Default mapping: SIP responses to call handling causes
SIP Response Default Call Handling Cause
400 Bad Request 41 temporary failure
401 Unauthorized 88 incompatible destination
402 Payment Required 88 incompatible destination
403 Forbidden 88 incompatible destination
404 Not Found 1 unallocated number
405 Method Not Allowed 41 temporary failure
406 Not Acceptable 41 temporary failure
407 Proxy Authentication Required 41 temporary failure
408 Request Timeout 41 temporary failure
409 Conflict 41 temporary failure
410 Gone 1 unallocated number
411 Length Required 41 temporary failure
413 Request Entity Too Large 41 temporary failure
414 Request-URI Too Long 41 temporary failure

166/915     


 !"  
 
 

SIP Response Default Call Handling Cause

415 Unsupported Media Type 65 bearer capability not implemented
420 Bad Extension 41 temporary failure
480 Temporarily Unavailable 18 no user responding
481 Call Leg/Transaction Does Not Exist 41 temporary failure
482 Loop Detected 41 temporary failure
483 Too Many Hops 41 temporary failure
484 Address Incomplete 28 invalid number format
485 Ambiguous 1 unallocated number
486 Busy Here 17 user busy
487 Request Terminates 41 temporary failure
488 Not Acceptable Here 65 bearer capability not implemented
500 Server Internal Error 41 temporary failure
501 Not Implemented 41 temporary failure
502 Bad Gateway 41 temporary failure
503 Service Unavailable 41 temporary failure
504 Server Timeout 41 temporary failure
505 Version Not Supported 41 temporary failure
600 Busy Everywhere 17 user busy
603 Decline 21 call rejected
604 Does Not Exist Anywhere 34 No circuit/Channel available
606 Not Acceptable 21 call rejected

6.1.2.14 SIP proxy and SIP gateway protection

As of R5.1, a mechanism can be used to protect the SIP proxy server and SIP gateway from
DOS (Denial Of Service) type attacks. This mechanism is based on two lists, a list of
addresses in quarantine and a list of trusted addresses.
IP addresses in quarantine are the IP addresses of sets whose messages are ignored for the
duration of the quarantine period. Sets can be placed in quarantine either:
- Manually, by configuring set IP addresses
- Automatically: the trigger threshold is 75 messages received by the proxy server in less
than 3s, quarantine lasts for 30 minutes
Trusted IP addresses are the addresses of sets that cannot be placed in quarantine, even if
the number of messages from these sets exceeds the automatic quarantine threshold.
Caution:
There is no control over the IP addresses put in the quarantine list or in the trusted addresses
list. In other words, a specific address can be put in both lists.

Note:
Any modification of any or both theses lists requires a restart of the SIP gateway to be taken into
account. To do this, run the command killall sipmotor

    

 !"  
  167/915
Chapter 6 

6.1.2.15 UTF8
As of R11.2, the following alphabets are supported in OmniPCX Enterprise for UTF8: Latin,
Extended Latin (Polish,…), Cyrillic, Greek, Arabic, Hebrew, Chinese, Japanese, Korean,
Arabic and Thaï. They are now fully supported in SIP trunking, private SIP and for SIP devices.
The Support UTF8 characters set parameter in SIP external gateway and for SIP device
allow to able/disable the sending of UTF8 string (non Latin) to this gateway or SIP device (see:
SIP Trunking - Configuration procedure - Configuring an External Gateway and SIP -
Configuration procedure - Configuring users ).
6.1.2.16 Restrictions
This section describes the restrictions which apply to the SIP sets not operating in SEPLOS
mode, i.e. declared as SIP Device (or Extern station before R9.0) local users.
Although they are declared in system configuration as SIP device local users, SIP sets are
considered by the phone application as part of a remote subnetwork (seen as a plain
subnetwork by the PCX). Thus SIP sets naturally have fewer functions than classic sets in the
PCX. Among the restrictions, the following functions can be found:
- A SIP set has no rights to the PCX prefixes and suffixes
- A SIP set cannot be a "hotel" set
- A SIP set cannot be supervised by CSTA (therefore, one cannot use the Computer
Telephony Integration (CTI) mechanisms of the PCX)
- A SIP set cannot be a call center agent
A SIP set cannot belong to:
- A group of sets
- A pick-up group
- A Manager/Assistant configuration
However, group operations can be imitated if a user registers under several different URLs. In
this case, all the sets ring simultaneously.

6.1.3 Configuration procedure

Implementation of the SIP feature consists in:
1. Checking certain parameters
2. Configuring the subnetwork and SIP trunk group
3. Configuring the SIP gateway
4. Configuring other specific SIP objects (proxy, registrar, dictionary, etc.), when appropriate
5. Creating SIP users
6. If necessary, customizing mapping between Call Handling error causes and SIP error
responses
This module gives a detailed description of the parameters related to the SIP feature. Simple
examples of implementation are given in SIP - Configuration examples .
6.1.3.1 Prerequisites

168/915     


 !"  
 
 

6.1.3.1.1 RTP direct

Check the following parameter:
1. Select: IP > IP Parameters
2. Review/modify the following attribute:
Direct RTP This parameter must be set to True

3. Confirm your entry

6.1.3.1.2 PCX address in DPNSS
To ensure adequate transfer operation, the PCX DPNSS address must be configured. See
ABC-F homogeneous private network - Configuration procedure - Managing Node DPNSS
Address.
6.1.3.2 SIP devices subnetwork
Although they are declared in system configuration as local users, SIP devices are considered
by the phone application as part of a remote subnetwork (subnetwork for the PCX). Before
creating a user, it is necessary to configure this subnetwork as well as the SIP trunk group to
this subnetwork.
6.1.3.2.1 Routing table
1. Select: Translator > Network Routing Table
2. Review/modify the following attributes:
Network Number Enter network number of SIP sets
Protocol Type ABC_F

3. Confirm your entries

6.1.3.2.2 Configuring the main SIP trunk group
Up to R7.0, there is only one SIP trunk group used to reach external SIP extensions and
external SIP gateways.
As of R7.1, one SIP trunk group is used to reach external SIP extensions (this trunk group is
called the main SIP trunk group) and one or several other SIP trunk group(s) are used to reach
external gateways.
Note:
- The main trunk group of the main gateway must always be created. This is necessary for external
gateways to operate, even if these gateways use dedicated trunk groups.
- When ARS is used with either ABC-F SIP or ISDN SIP trunk groups, it is mandatory to use the
[I]nsert command in the DCT of the ARS.
Creating a trunk group
1. Select: Trunk Groups
2. Review/modify the following attributes:

    

 !"  
  169/915
Chapter 6 

Trunk Group ID Enter the trunk group number

Trunk Group Type T2
Remote Network Enter the subnetwork number associated with the trunk
group

3. Confirm your entries.

The system displays a new screen
4. Review/modify the following attributes:
Node number
Q931 signal variant
T2 Specification
Associated Ext SIP gateway
Enter the node number
• Select ABC-F for the main SIP trunk group
• Select either ABC-F or ISDN all countries for other
trunk groups (for more information, see SIP - SIP
Trunking - ABC-F versus ISDN SIP Trunk Groups)
Important:
The value ISDN FRANCE must never be selected
Select the type of SIP trunk group:
• SIP: allows 62 simultaneous communications per
pair of accesses
• MINI SIP (as of R8.0.1): allows 4 simultaneous com-
munications per pair of accesses
Enter the external SIP gateway number associated to
this trunk group
Enter -1 for no association
For more information, see: ARS - Detailed description -
Configuring emergency calls

5. Confirm your entries

Configuring trunk group local parameters
1. Select: Trunk Groups > Trunk Group
2. Review/modify the following attributes:

170/915     


 !"  
 
 

Trunk Group ID Enter the trunk group number

Max ABC-IP and SIP Connections As of R11.0.1, enter the maximum number of commu-
nications over a trunk group:
• When the value equals 0, the number of simultan-
eous calls is not limited
• When the value is above 0: the number of simultan-
eous calls is limited to the configured value
When making a call, if this configured value has
already been reached, then the call does not go
through and the SETUP message is not sent
When the maximum number of calls is reduced, the
new value is taken into account for new call estab-
lishments only. Undergoing calls are not impacted
Calls without a B channel are not impacted: SETUP
is emitted with no impact on counters
Notes:
• This parameter is valid for ABCF-IP and SIP Trunk
groups
• Before this feature was made available, there was no
way to restrain the number of calls in ABCF-IP and
SIP trunks, at the trunk group level

3. Confirm your entries.

Configuring virtual accesses
1. Select: Trunk Groups > Trunk Group > Virtual access for SIP
2. Review/modify the following attribute:
Number of SIP Access When a SIP trunk group is created, a pair of accesses is
automatically created
As of R7,0 up to 16 pairs of accesses can be configured
(6 before). Accesses are always configured in pairs
The maximum number of communications per trunk
group depends on the type of trunk group:
• SIP: 992 simultaneous communications maximum
with 62 communications per pair of accesses (31
per access)
• MINI SIP: 64 simultaneous communications maxim-
um with 4 communications per pair of accesses (2
per access)
This limit only applies to calls between SIP terminals
and standard sets in the PCX (except if CAC SIP-SIP is
used; in this case SIP-SIP communications are also
taken into account)

3. Confirm your entry

4. Reboot the OmniPCX Enterprise server to take the new value into account
Caution:
If you add new SIP accesses and you do not reboot the server, the trkstat command
displays these accesses as free (F) but they cannot be used until next reboot.

    

 !"  
  171/915
Chapter 6 

6.1.3.2.3 Configuring compression type

A compression algorithm is configured at system and SIP trunk group level. The compression
algorithm is selected by negotiation with the SIP set, taking into account this configured data
and the algorithms supported by the set (see: Direct RTP in network - Coding configuration ).
VAD (Voice Activity Detection) is not taken into account.
1. Select: Trunk Groups > Trunk Group
2. Review/modify the following attribute:
IP Compression Type • Default: the system default algorithm is chosen in pri-
ority
• G711: the G711 coding algorithm is chosen in priority
Default value: G711

3. Confirm your entry

6.1.3.3 Configuring the main SIP gateway

Note 1:
For modified SIP gateway parameters to be applied, the gateway must be restarted. To do this, run the
command killall sipmotor.
1. Select: SIP > SIP Gateway
2. Review/modify the following attributes:
SIP Subnetwork Enter the number of the SIP sets subnetwork
SIP Trunk Group Enter the number of the "main" SIP trunk group (created
above)
IP Address Displays the Call Server main IP address retrieved from
Netadmin data
Machine name - Host Displays the hostname for Call Server Main role retrieved
from Netadmin data
SIP Port Number Up to R7.0. Default value: 6060
Note 2:
As of R7.1, this port is not used anymore
SIP Proxy Port Number Default value: 5060
Note 3:
As of R7.1, this port is used by the SIP proxy server and the SIP
motor

Notes:
• You can change Machine name by using Netadmin command
• To allow SIP terminals to resolve Machine name as an IP address (if needed), you must activate
internal DNS by using Netadmin
For more information, see netadmin - Operation.
Two parameters are used to configure the duration of subscriptions to notifications giving
transfer result and new messages

172/915     


 !"  



SIP Subscribe Min Duration
SIP Subscribe Max Duration
The following parameters are used for the keep-alive mechanism for established sessions.
They apply to all SIP to SIP communications, whether they use the main SIP gateway or
an external gateway.
Session Timer Method
Session Timer
Min Session Timer
For the gateway to be able to handle domain names (FQDN), DNS related parameters
must be configured.
DNS local domain name
SIP DNS1 IP Address
SIP DNS2 IP Address
DNS type
   
 !"  

Enter minimum subscription duration (in seconds) for noti-
fication of new messages or the result of phone transfer
Default value: 1800
Enter maximum subscription duration (in seconds) for no-
tification of new messages or the result of phone transfer
Default value: 86400
• RE-INVITE (default value): The SIP gateway sends
Re-INVITE methods as session refresh requests
• UPDATE: SIP gateway sends UPDATE methods as
session refresh requests provided the SIP device al-
lows it. If the SIP device does not allow the UPDATE
method, RE-INVITE is used
Enter the session timer value (in seconds). This timer is
used when the gateway is in charge of sending the keep-
alive messages. This timer defines the maximum amount
of time before a session is considered terminated
Default value: 1800
Enter the minimum value (in seconds) of the session timer
accepted by the gateway. For an incoming call, if the ses-
sion timer is lower than this value, the SIP gateway sends
a 422 message to the remote SIP entity
Default value: 900s
Minimum value: 300s
Enter the name of the domain managed by the primary
DNS. This is often 'sub.network.fr' or 'mycompany.com'
type
Enter primary DNS address
Enter secondary DNS address
• DNSA: the SIP gateway sends DNSA requests to re-
solve a domain name into one single IP address
• DNS SRV: the SIP gateway sends DNSSRV requests
to resolve a domain name into one or several names
or IP addresses

 173/915
Chapter 6 

SDP IN 180 Indicates if the SDP will be present in 180 ALERTING sent
by the main gateway
Cac SIP-SIP • True: SIP to SIP communications between two SIP
devices are taken into account by Call Admission Con-
trol
• False: SIP to SIP communications between two SIP
devices are not taken into account by Call Admission
Control
Note 4:
This parameter does not apply to SIP terminals operating in
SEPLOS mode. The communications involving SEPLOS termin-
als are always taken into account by Call Admission Control.
For more information, see SIP - Detailed description - Call
Admission Control (CAC) .
To enable the SIP INFO method (used only for the reception of DTMF values), configure
the following attribute:
INFO method for remote exten- • True: Enable the out-of-band DTMF transmission
sion (DTMF digits) along the signaling path
• False: Inhibit the out-of-band DTMF transmission
(DTMF digits) along the signaling path
For SIP trunking adaptation, configure the following attribute:
Dynamic Payload Type for Enter a number between 96 and 127
DTMF Default value: 97
This value is suggested by Alcatel-Lucent OmniPCX En-
terprise Communication Server for outgoing calls "negoti-
able value"

3. Confirm your entries

6.1.3.4 Configuring the SIP proxy server
The SIP Proxy object is used to:
- Configure the values of timers used in SIP exchanges.
- Enable digest authentication.
1. Select: SIP > SIP Proxy
2. Review/modify the following attributes:
SIP initial time-out INVITE message retransmission time-out: an un-
answered INVITE message is retransmitted following
this time-out (to be configured according to network
speed).
500 by default
SIP timer T2 Retransmission time-out for other requests
4000 by default

174/915     


 !"  



DNS Timer Overflow
Recursive search
Minimal authentication method
Authentication realm
Only authenticated incoming
calls
Framework Period
Framework Nb Message By Peri-
od
Framework Quarantine Period
Move to TCP
Number of re-transmission for IN- As of R10.0, enter the maximum number of retransmis-
VITE
   
 !"  

Waiting time before DNS requests (sent to the primary
DNS address) are transferred to the secondary DNS ad-
dress
Default value: 5000 (5 s)
Not implemented
Select the authentication method to be used by the main
gateway:
• SIP None: No authentication
• SIP Digest: Authentication by login and password,
with encryption
Default value: SIP Digest
50-character (maximum) string describing the security
domain on which users must authenticate themselves
• True: Incoming calls and transfer requests that are
not authenticated are refused
• False: Incoming calls and transfer requests from
non PCX external stations that are not authenticated
are accepted
Indicates the time of observation before putting an IP
address in quarantine
Default value: 3s
Indicates the trigger threshold of received messages per
second which puts the IP address in quarantine
Default value: 25
Indicates the duration of the quarantine
Default value: 1800 s
This parameter is used when UDP is used as transport
protocol, to allow or ban the use of TCP for long mes-
sages
This parameter applies to external gateways, SiP exten-
sions, SIP devices and SIP external voice mails
• True (default value): TCP is used, rather than UDP,
when the message size is higher than the maximum
size (MTU), e.g. 1300 bytes
• False: UDP is used, whatever the size of messages
sions of an INVITE method after which the OmniPCX
Enterprise considers that no response has been re-
ceived from the remote party
The retransmission process is similar to the one used
for registration (see SIP Trunking - Detailed description -
External gateway registration ).
Default value: 3 (the remote party is considered unavail-
able after 2 seconds)
Note:
This parameter does not apply to other methods such as CAN-
CEL, BYE, REFER, For these methods, the Timer F value
(value: 32s, cannot be modified) applies

 175/915
Chapter 6 

3. Confirm your entries

4. Restart the SIP motor to apply modifications
6.1.3.5 Configuring the SIP registrar server
A registration request for a SIP terminal can contain a period of validity for the IP address it is
transmitting. On the registrar; the data concerning the SIP terminal will be kept during the
requested period of validity, provided that this duration is included within the
maximum/minimum values configured as follows:
1. Select: SIP > SIP Registrar
2. Review/modify the following attributes:
SIP Declared Sets Parameter available up to R7.0:
• True: Only SIP sets declared as users on the PCX
can register
• False: All SIP sets can register
SIP Min Expiration Date Life time applied if the registration request of the SIP
terminal does not contain a period of validity, or is the
requested period is shorter to this minimum value
SIP Max Expiration Date Life time applied if the period of validity requested by the
SIP terminal is longer than this period

3. Confirm your entries

6.1.3.6 Configuring the SIP dictionary
There are two types of terminals declared in the dictionary:
- SIP terminal configured on the PCX as local user (SIP device or SIP extension (i.e.
SEPLOS) or external voice mail: alias 0 is automatically created when the SIP terminal is
declared. It is then possible to create additional aliases.
- PCX standard set (TDM set, DECT PWT set, etc.): an alias is created automatically if the
parameter URL UserName has been configured.
Note:
A user not declared as a user on the PCX cannot be declared in the SIP dictionary.
For terminals already registered in the SIP dictionary, the SIP Dictionary object allows to
create additional aliases or modify existing URLs.
1. Select: SIP > SIP Dictionary
2. Review/modify the following attributes:
Directory Number
Directory Number Enter the directory number of the terminal
Alias No. Enter the alias number (between 0 and 15)
SIP URL Username Enter the user name part of the URL

176/915     


 !"  
 
 

SIP URL Domain Enter the domain part of the URL If this logical address
must be resolved by the integrated SIP proxy server,
this field must correspond to SIP gateway IP address (or
FQDN)
SIP URL Type • For a SIP set, select Subscriber.
• Voice Mail type is reserved for access to Alcatel-Lu-
cent voice mail applications (Alcatel-Lucent OmniT-
ouch Unified Communications)
• The Other type is not used
SIP URL Origin Only in consultation mode. Filled with the terminal origin
node

3. Confirm your entries

6.1.3.7 Configuring the country codes
Country codes must be entered on the PCX in order to be recognized in numbers received in
canonical form.
For more information, see SIP Trunking - Detailed description - Incoming Calls.
1. Select: Translator > External Dialing Plan > Country Codes
2. Review/modify the following attributes:
Country code prefix Enter the country code (for example: 33 for France)
Country Value Select the country if it is listed or Other Country other-
wise
Country Name To be completed if Country Value=Other Country

3. Confirm your entries

6.1.3.8 Configuring the quarantined IP addresses (safety precaution)
It is possible to configure manually the list of SIP terminal IP addresses to put in quarantine.
SIP messages exchanged between these IP addresses put in quarantine and the PCX are not
processed.
1. Select: SIP > Quarantined IP addresses
2. Review/modify the following attribute:
Quarantined address Enter the IP address of the SIP terminal to put in quar-
antine

3. Confirm your entry

6.1.3.9 Configuring the trusted IP addresses (safety precaution)
It is possible to configure a list with the SIP terminal IP addresses that cannot be automatically
placed in quarantine, even if the number of SIP messages from these SIP terminals exceeds
the automatic quarantine threshold defined by the Framework Nb Message By Period
parameter (see: Configuring the SIP proxy server ).
1. Select: SIP > Trusted IP addresses
2. Review/modify the following attribute:

    

 !"  
  177/915
Chapter 6 

Trusted address Enter the IP address of the trusted SIP terminal

3. Confirm your entry

Caution:
Any modification of any or both theses lists requires a restart of the SIP gateway to be taken into
account. To do this, run the command killall sipmotor

6.1.3.10 Configuring users

6.1.3.10.1 Configuring a SIP device
This section describes the configuration of SIP terminals which cannot operate in SEPLOS
mode, i.e.:
- Before R9.0, all SIP terminals: they are declared as Extern Station local users
- As of R9.0, only terminal which cannot operate in SEPLOS mode: they are declared as
SIP Device local users
Note:
A SIP set can only be created if SIP network number, SIP trunk group and gateway are already
configured.
Two types of SIP devices may be created:
- Users who must register on the SIP proxy server
- Remote domain users who must not register on the SIP proxy server. Declaring these sets
allows them to be assigned authentication parameters and a public network access COS
SIP user registering on the Alcatel-Lucent OmniPCX Enterprise CS
1. Select: Users
2. Review/modify the following attributes:
Directory Number Enter the directory number of the set
Shelf Address Enter 255
Board Address Enter 255
Equipment Address Enter 255
Set Type Select SIP Device (or Extern Station before R9.0)
URL UserName Enter, for example, the directory number of the set or
user name
Note 1:
This field can be left blank. In this case, the directory number
is used for the user part of the URL
URL Domain For a set belonging to the PCX domain, this field must
be left blank
Note 2:
Do not complete set physical address, otherwise the set will
not register in the Call Server registrar

178/915     


 !"  
 
 

SIP Authentication Consultation of the name used for authentication with

the SIP proxy server (non modifiable field): for a set
that registers on the Alcatel-Lucent OmniPCX Enter-
prise CS, name takes the value of the parameter: SIP
URL Username
SIP Passwd Enter a password (10 characters maximum)
Note 3:
As of R5.1, the SIP authentication password is set by default
at the same value as the default password (secret code) of
the other sets
Confirm Confirm password.
Support UTF8 characters set As of R11.2, this parameter is used in SIP for UFT8:
• No (default value): For incoming calls, a Latin
name (trunk name) is always associated to the
UTF8 non Latin name received, to be able to
handle the case where the receiver doesn’t support
UTF8.
UTF8 is fully handled for basic calls and call trans-
fer
• Yes: The UFT8 supports characters set

3. Confirm your entries

Remote domain SIP user
1. Select: Users
2. Review/modify the following attributes:
Directory Number Enter the directory number of the set
Shelf Address Enter 255
Board Address Enter 255
Equipment Address Enter 255
Set Type Select SIP Device (or Extern Station before R9.0)
URL UserName Enter for example the directory number of the set or a
name
Note 1:
This field can be left blank. In this case, the directory number
is used for the user part of the URL
URL Domain For a set not belonging to the PCX domain, this field
must be filled in
This field corresponds to the logical address domain of
the SIP set
Enter the set address if it is not attached to a domain
SIP Authentication Consultation of the login used for authentication with
the SIP proxy server (non modifiable field): For a re-
mote domain set, the login takes the value: SIP URL
Username@SIP URL Domain

    

 !"  
  179/915
Chapter 6 

Password Enter a password (10 characters maximum)

Note 2:
As of R5.1, the SIP authentication password is set by default
at the same value as the default password (secret code) of
the other set
Confirm Confirm password.
Support UTF8 characters set As of R11.2, this parameter is used in SIP for UFT8:
• No (default value): For incoming calls, a Latin
name (trunk name) is always associated to the
UTF8 non Latin name received, to be able to
handle the case where the receiver doesn’t support
UTF8.
UTF8 is fully handled for basic calls and call trans-
fer
• Yes: The UFT8 supports characters set

3. Confirm your entries

After creating a SIP user, new entries are automatically created in:
• SIP > Authentication
• SIP > SIP Dictionary
6.1.3.10.2 Configuring a standard user
For a standard user, the URL UserName and URL Domain attributes are optional. They can
be completed to make the set accessible to the SIP world by a specific SIP URL of
Username@domain type.
If they are not configured, the URL is automatically constructed by the system from MAO
system configuration data:
- The URL Domain takes SIP gateway IP address (or FQDN) as default value
- The URL UserName takes set directory number as default value
6.1.3.11 Modifying SIP terminal authentication password
Following SIP terminal configuration in the PCX, it is possible to modify the SIP terminal
authentication password as follows:
1. Select: SIP > SIP Authentication
2. Review/modify the following attributes:
Directory Number Enter the directory number of the target SIP terminal
SIP Authentication Displays the login used for SIP terminal authentication
with the SIP proxy server
SIP Passwd Enter the password (10 characters maximum)
Confirm Confirm password

3. Confirm your entries

6.1.3.12 Customizing mapping between call handling causes and SIP responses
6.1.3.12.1 Mapping SIP error responses to call handling error Causes

180/915     


 !"  
 
 

1. Select: SIP > SIP To CH Error Mapping

2. Review/modify the following attribute:
SIP Response Displays the SIP error response selected previously
Note:
The complete list of SIP error responses is provided: SIP -
Detailed description - Mapping between call handling error
causes and SIP error responses
Ch Cause Displays the default mapping of Call Handling error
causes. This mapping can be changed by selecting an-
other Call Handling error cause from the following list:
• Unallocated Number (code value: 1)
• User Busy (code value: 17)
• No User Responding (code value: 18)
• Call Rejected (code value: 21)
• Invalid Number Format (code value: 28)
• Temporary Failure (code value: 41)
• Bearer Cap Not Implemented (code value: 65)
• Incompatible Destination (code value: 88)
• Others: this option is used to enter the appropriate
Call Handling error cause by its code value (see
the Call Handling Cause parameter below)

3. Confirm your entry

An additional parameter is displayed when the Call Handling error cause is set to Others
4. Review/modify the following attribute:
Call Handling Cause Enter the code value relating to the appropriate Call
Handling error cause. An error message is displayed
when this code value is not valid

5. Confirm your entry

6.1.3.12.2 Mapping call handling error causes to SIP error responses
1. Select: SIP > CH to SIP Error Mapping
2. Review/modify the following attribute:

    

 !"  
  181/915
Chapter 6 

Call Handling Cause Displays the Call Handling error cause selected previ-
ously
Note:
The complete list of Call Handling error causes is provided:
SIP - Detailed description - Mapping between call handling
error causes and SIP error responses
SIP Response Displays the default mapping of SIP error response.
This mapping can be changed by selecting another
SIP error response from the following list:
• Not found (code value: 404)
• Gone (code value: 410)
• Temporary Unavailable (code value: 480)
• Address Incomplete (code value: 484)
• Busy Here (code value: 486)
• Not Acceptable Here (code value: 488)
• Server Internal Error (code value: 500)
• Not Implemented (code value: 501)
• Bad Gateway (code value: 502)
• Service Unavailable (code value: 503)
• Decline (code value: 603)
• Others: this option is used to enter the appropriate
SIP error response by its code value (see the SIP
response parameter below)

3. Confirm your entry

An additional parameter is displayed when the Call Handling error cause is set to Others
4. Review/modify the following attribute:
SIP response Enter the code value relating to the appropriate SIP er-
ror response. An error message is displayed when this
code value is not valid

5. Confirm your entry

6.1.4 Configuration examples

6.1.4.1 Introduction
This module presents several examples of simple configurations:
- A basic example without authentication or DNS.
- An example with set authentication.
- An example with authentication and use of DNS.
The first example describes the minimum configuration required to implement the SIP feature.
The following examples are based on the first example, only the additional configuration
operations required are described.
The values used in the examples are the following:
- CS: 192.168.4.52 (network 0, node 1), machine name “oxe”
- SIP set: 192.168.4.23, directory number 3003

182/915     


 !"  
 
 

- A4645: 3333
The SIP set is configured to register on the Alcatel-Lucent OmniPCX Enterprise CS proxy.
Note 1:
Theoretically, a SIP set can operate in stand-alone mode or register with a registrar:
- In the first case, its SIP URL domain is its IP address
- In the second case, its SIP URL domain is the registrar's IP address (with an Alcatel-Lucent
OmniPCX Enterprise CS, this is the Com Server's main address, or node name)

Note 2:
Configuration operations performed on the SIP set are not described here. For more information, refer to
the set manufacturer's documentation or the technical bulletins issued by Alcatel-Lucent technical
support.

6.1.4.2 Basic Configuration

6.1.4.2.1 Configuration Steps
The different steps are:
On the Com Server:
1. Select a SIP network.
2. Create a trunk group to reach this network.
3. Configure the SIP gateway.
4. Declare SIP sets as users.
5. Restart the SIP motor.
On the SIP set:
1. Configure set IP parameters.
2. Specify the IP address of the Alcatel-Lucent OmniPCX Enterprise CS proxy.
6.1.4.2.2 Configuration
6.1.4.2.3 Configuration on the Com Server
SIP Network
Select: Translator > Network Routing Table

    

 !"  
  183/915
Chapter 6 

Node Number (reserved) : 1

Instance (reserved) : 1
Network Number : 4
Rank of First Digit to be Sent : 1
Incoming identification prefix : --------
Protocol Type + ABC-F
Dialing Plan Descriptor ID : 11
ARS Route list : 0
Schedule number : -1
ATM Address Id : -1
Network call prefix : --------
City/Town Name : --------------------
Send City/Town Name + False
Associated Ext SIP gateway : -1

SIP Trunk Group

Create the Trunk Group
Select: Trunk Groups
Node Number (reserved) : 1
Trunk Group Id : 24
Trunk Group Type + T2
Trunk Group Name : sip
Remote Network : 4
Q931 signal variant + ABC-F
T2 Specification + SIP
Overlap dialing + NO

Configure Virtual Accesses

Select: Trunk Groups > Trunk Group > Virtual access for SIP
Node Number (reserved) : 1
Trunk Group ID : 24
Instance (reserved) : 1
Instance (reserved) : 1

Number of SIP Accesses : 2

Note:
Two SIP accesses allow 62 simultaneous calls on the trunk group.

SIP Gateway
Select: SIP > SIP Gateway

184/915     


 !"  
 
 

Node Number (reserved) : 1

Instance (reserved) : 1
Instance (reserved) : 1

SIP Subnetwork : 4
SIP Trunk Group : 24
IP Address : 192.168.4.52
Machine name - Host : OXE
SIP Proxy Port Number : 5060
SIP Subscribe Min Duration : 1800
SIP Subscribe Max Duration : 86400
Session Timer : 1800
Min Session Timer : 900
Session Timer Method : RE_INVITE
DNS local domain name : --------------------
DNS type + DNS A
SIP DNS1 IP Address : --------------------
SIP DNS2 IP Address : --------------------
SDP IN 180 + True
Cac SIP-SIP + False
INFO method for remote extension + False

Declare SIP Users on the Alcatel-Lucent OmniPCX Enterprise CS

Select: Users
Node Number (reserved) : 1
Directory Number : 3003

Directory name : John

Directory First Name : --------------------
Location Node : 1
Shelf Address : 255
Board Address : 255
Equipment Address : 255
Set Type + SIP device
Entity Number : 1
URL UserName : 3003
URL Domain : --------------------

Restart the SIP Motor

Enter the command killall sipmotor to restart the SIP gateway and apply the new
parameter settings.
6.1.4.2.4 Configuration on the SIP Set
On the SIP set:
- Configure set URL: sip:3003@192.168.4.52,
- Configure proxy address: 192.168.4.52.

    

 !"  
  185/915
Chapter 6 

6.1.4.3 Configuration with Digest Authentication

6.1.4.3.1 Configuration Overview
Configuration is as in the previous example with the following additional operations:
On the Com Server:
1. Enable authentication and specify authentication realm on the proxy
Note:
Only digest authentication is supported.
2. Configure authentication passwords for each user
On the SIP set:
1. Configure authentication parameters for Alcatel-Lucent OmniPCX Enterprise CS proxy
authentication realm.
6.1.4.3.2 Configuration on the Com Server
SIP Proxy Server
Select: SIP > SIP Proxy
Node Number (reserved) : 1
Instance (reserved) : 1
Instance (reserved) : 1
SIP Initial time-out : 500
SIP timer T2 : 4000
SIP connection duration : 180000
Recursive search + False
Minimal authentication method + SIP Digest
Authentication realm : AlcatelOmniPCX
Only authenticated incoming calls + False
Framework Period : 3
Framework Nb Message By Period : 25
Framework Quarantine Period : 1800

User
Select: Users

186/915     


 !"  
 
 

Node Number (reserved) : 1

Directory Number : 3003
Directory name : John
Directory First Name : --------------------
Location Node : 1
Shelf Address : 255
Board Address : 255
Equipment Address : 255
Set Type + SIP device
Entity Number : 1
URL UserName : --------------------
URL Domain : --------------------
SIP Authentication : 3003
Password : ****
Confirm : ****

6.1.4.4 Configuration with Authentication and DNS

Configuration is as in the previous example, but by configuring a DNS, with address
10.20.22.20, responsible for resolving the addresses of the local domain, mycompany.com.
6.1.4.4.1 SIP Gateway
Select: SIP > SIP Gateway
Node Number (reserved) : 1
Instance (reserved) : 1
Instance (reserved) : 1
SIP Subnetwork : 4
SIP Trunk Group : 24
IP Address : 192.168.4.52
Machine name - Host : OXE
SIP Proxy Port Number : 5060
SIP Subscribe Min Duration : 1800
SIP Subscribe Max Duration : 86400
Session Timer : 1800
Min Session Timer : 900
Session Timer Method : RE_INVITE
DNS local domain name : mycompany.com
DNS type + DNS A
SIP DNS1 IP Address : 10.20.22.20
SIP DNS2 IP Address : --------------------
SDP IN 180 + True
Cac SIP-SIP + False
INFO method for remote extension + False

Note:
The DNS client configuration file on the Com server is the file, /etc/resolv-adns.conf (this is not
the standard DNS client file, resolv.conf).

6.1.4.4.2 SIP User Configuration

    

 !"  
  187/915
Chapter 6 

Select: Users
Node Number (reserved) : 1
Directory Number : 3003
Directory name : John
Directory First Name : --------------------
Location Node : 1
Shelf Address : 255
Board Address : 255
Equipment Address : 255
Equipment Address : 255
Set Type + SIP device
Entity Number : 1
URL UserName : John
URL Domain : OXE.mycompany.com
SIP Authentication : 3003
Password : ****
Confirm : ****

6.1.4.4.3 Configuration on the SIP Set

On the SIP set:
- Configure set URL: sip:John@OXE.mycompany.com
- Configure proxy address: OXE.mycompany.com
6.1.4.4.4 Primary DNS Server
In this example, machine 10.20.22.20 is the DNS server used to resolve addresses for the
domain “mycompany.com”.
This server must contain a record linking the name selected for the Com Server
(Alcatel-Lucent OmniPCX Enterprise Communication Server) with its IP address
(192.168.4.52).
For a duplicated Com Server configuration where the two Com Servers are on different
subnetworks, refer to: SIP - Detailed description - Configuration .

6.1.5 Maintenance
6.1.5.1 Maintenance Commands

Command Definition
represent Checks the connections
trkstat Checks the state of T2-SIP trunk group
sipacces Checks the number of trunk group accesses: see sipacces
Command .
sipgateway Displays:
- SIP gateway management data
- The list of addresses that are placed in quarantine
- The list of trusted addresses

188/915     


 !"  
 
 

Command Definition
sipextgw Displays SIP external gateway management data, status (in
or out of service), URLs stored for Service Route header
sippool Displays the list of pools of gateways
sipdict Displays the contents of dictionary, i.e. the correspondence
between the MCDUs and URLs of the sets
Caution:
Do not confuse with the SIP sets registered with the Com Serv-
er Registrar. The list of registered sets can be consulted in the
directory /tmpd in the text file localize.sip on the Com
Server. This file must not be edited manually.
sipauth Displays external set authentication information (user name
and corresponding password)
sipregister Displays the list of SIP users registered on the system
sipdump Displays a menu which allows to access a set of features re-
lating to the SIP gateway, such as its configuration data, in-
formation on SIP calls, device numbers and SIP calls' corres-
pondence, SIP calls' list, SIP calls' filtering, etc.
Note 1:
For more information, see: sipdump Command
motortrace c Displays SIP general configuration
killall sipmotor Reboots the SIP gateway (new parameter settings are then
applied)
Note 2:
sipmotor can be delivered as a dynamic patch. It must be activated
by rebooting the SIP gateway with the killall sipmotor com-
mand.

6.1.5.2 sipacces Command

The sipacces command checks the number of trunk group accesses.
Example:

    

 !"  
  189/915
Chapter 6 

(1)cs80> sipacces
Mon Jul 21 16:56:16 CEST 2008
+------------------------------------------------------------------------------+
| 1 | SIP Trunk Group Access |
+------------------------------------------------------------------------------+
| TG Nb | 200 | -1 | -1 | -1 | -1 |
| | | | | | |
| Access | User - Net | User - Net | User - Net | User - Net | User - Net |
+------------------------------------------------------------------------------+
| 1 | 14 - 15 | . . . | . . . | . . . | . . . |
| 2 | . . . | . . . | . . . | . . . | . . . |
| 3 | . . . | . . . | . . . | . . . | . . . |
| 4 | . . . | . . . | . . . | . . . | . . . |
| 5 | . . . | . . . | . . . | . . . | . . . |
| 6 | . . . | . . . | . . . | . . . | . . . |
| 7 | . . . | . . . | . . . | . . . | . . . |
| 8 | . . . | . . . | . . . | . . . | . . . |
| 9 | . . . | . . . | . . . | . . . | . . . |
| 10 | . . . | . . . | . . . | . . . | . . . |
| 11 | . . . | . . . | . . . | . . . | . . . |
| 12 | . . . | . . . | . . . | . . . | . . . |
| 13 | . . . | . . . | . . . | . . . | . . . |
| 14 | . . . | . . . | . . . | . . . | . . . |
| 15 | . . . | . . . | . . . | . . . | . . . |
| 16 | . . . | . . . | . . . | . . . | . . . |
+------------------------------------------------------------------------------+
By default, after creation, a SIP trunk group contains 2 virtual accesses:
- One connects to the call handling (user side). This corresponds to access 14 of trunk
group 200 in the example above
- The other connects to the gateway (network side). This corresponds to access 15 of trunk
group 200 in the example above
To configure the number of virtual accesses, see SIP - Configuration procedure - Configuring
virtual accesses . Possible values for the number of virtual accesses on a trunk group are: 2,
4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32.
The virtual access ID can not be specified manually, it is allocated by the system
automatically.
6.1.5.3 sipdump Command
To run the sipdump command:
1. Log in to the Com Server from a command window (e.g. Hyperterminal or Telnet)
2. From the CPU prompt, enter the sipdump command
The main menu opens:
SIP Gateway resources menu
1 - Dump the gateway management datas
2 - Dump a call
3 - Display the number of calls
4 - Display the calls-neqt mapping
5 - Display the calls list
6 - Release a call
7 - Display subscription list
8 - Display calls through a gateway
9 - Display calls in a trunk group
10 - SIP traces filters
0 - Exit
Choice [0 - 10] :
Several options are offered:
• Option 0 : Exit used to exit the menu
• Options 1 to 7 are described below
3. Log in to the Com Server from a second command window
4. From the CPU prompt, launch the traced & command

190/915     


 !"  
 
 

Caution:
The results of the sipdump command are displayed in the form of traces. To display the
results, it is mandatory to launch the traced & command in a second command window.
6.1.5.3.1 Option 1 - Dump the gateway management datas
This option allows to access SIP gateway configuration data.
The information displayed consists of:
- The availability of the license 188 SIP network links
- The number of initial licenses
- The number of licenses used
- The PCX role (main or standby)
- The PCX operating mode (normal or degraded)
The PCX runs in degraded mode when it detects an incoherence in the license files used.
Example:
1178194223 -> ---------------------------------------
1178194223 -> Gateway Management Data
1178194223 -> ---------------------------------------
1178194223 ->
1178194223 -> Use of licenses : Yes
1178194223 -> Number of initial licenses : 99999
1178194223 -> Number of available licenses : 99999
1178194223 ->
1178194223 -> Main server : Yes
1178194223 -> degraded mode : Yes
1178194223 -> ---------------------------------------

6.1.5.3.2 Option 2 - Dump a call

This option allows to access information on a SIP call handled by the SIP gateway. SIP calls
directly handled by the SIP proxy server are not taken into account by this option (i.e. calls
between two SIP sets without Call Admission Control).
This option requires to enter the equipment number used by the SIP call. To know the
correspondence between a SIP call and the associated equipment number, use the option 4 -
Display the calls-neqt mapping.
The information displayed consists of:
- The call equipment number (Neqt field)
- The call identifier (Call ID field)
- The call status (Current state field)
- The calling party (From field)
- The called party (To field)
- The external gateway number used by the SIP call (Ext. Gateway field)
Example:

    

 !"  
  191/915
Chapter 6 

1178194781 -> ---------------------------------------

1178194781 -> Call Dump
1178194781 -> ---------------------------------------
1178194781 ->
1178194781 -> Neqt : 865
1178194781 -> Call ID : 97..........ef5@192.40.64.17
1178194781 -> Current state : COMPLETE_STATE
1178194781 -> From : sip:7101@192.40.64.17
1178194781 -> To : sip:7300@node25
1178194781 -> Ext. Gateway : Not used
1178194781 -> To : sip:7300@node25
1178194781 -> ---------------------------------------

6.1.5.3.3 Option 3 - Display the number of calls

This option allows to know the number of SIP calls handled by the SIP gateway as well as the
number of active calls. A SIP call is considered as active when it is in one of these following
states: Completed state, Running timer state, or Proceeding state.
Example:
1178194690 -> ---------------------------------------
1178194690 -> Number of Calls : 2 (Active calls: 1)
1178194690 -> ---------------------------------------

6.1.5.3.4 Option 4 - Display the calls-neqt mapping

This option allows to know the correspondence between the SIP calls handled by the SIP
gateway and the associated device numbers. SIP calls are classified according to their status
(active or inactive call).
Reminder:
A SIP call is considered as an active call when it is in one of these following states: Completed,
Running timer, or Proceeding

Example:
1178194613 -> ---------------------------------------
1178194613 -> Neqt - Call mapping
1178194613 -> ---------------------------------------
1178194613 ->
1178194613 -> Active Calls (1/2)
1178194613 -> Eqt = 865 <-> Call ID = 971112c7........
1178194613 ->
1178194613 -> Unactive Calls (1/2)
1178194613 -> Eqt = 866 <-> Call ID = 0b1a60a8........
1178194613 ->---------------------------------------

6.1.5.3.5 Option 5 - Display the calls list

This option allows to display the list of SIP calls handled by the SIP gateway. In this list, each
SIP call is identified by its call identifier (Call ID). When the PCX operates correctly, this list is
the same as the list provided by the previous option 4 - Display the calls-neqt
mapping.
Example:
1178194873 -> ---------------------------------------
1178194873 -> List of Calls
1178194873 -> ---------------------------------------
1178194873 ->
1178194873 -> Active Calls (1/2)
1178194873 -> Call ID = 971112c7........
1178194873 ->
1178194873 -> Unactive Calls (1/2)
1178194873 -> Call ID = 0b1a60a8........
1178194873 ->---------------------------------------

192/915     


 !"  
 
 

6.1.5.3.6 Option 6 - Release a call

This option allows to release a SIP call handled by the SIP gateway. When selected, the
sipdump command displays by traces the correspondence between SIP calls and device
numbers.
Releasing a SIP call is done by entering the corresponding device number. Aconfirmation
message is displayed asking to confirm SIP call release.
6.1.5.3.7 Option 7 - Display subscription list
This option gives:
- The list of subscriptions on the Alcatel-Lucent OmniPCX Enterprise CS gateway
- For each subscription, the subscription key, the instance number of the call and the call-id
6.1.5.3.8 Option 8 - Display calls through a gateway
This option displays the list of SIP calls through a specified SIP Gateway (main or external).
Information displayed includes:
- For each call:
• The call identifier
• The call state: the state can be Initial, Proceeding, Accepted, Completed, etc.
• The From field of the SIP call
• The To field of the SIP call
• The Session Timer method used for the refreshing
- The total number of calls through the gateway (both active and inactive calls)
6.1.5.3.9 Option 9 - Display calls in a trunk group
This option allows to display the list of calls through the specified trunk group.
After selecting this option, you are prompted to give the trunk number, then a sub-menu is
displayed:
1. Option 1 allows to give a specific gateway number to display the list of calls through the
specified gateway using the specified trunk group: this is the same as Option
8 - Display calls through a gateway .
2. Option 2 allows to display the list of calls using the specified trunk group irrespective of the
gateway. Information displayed includes:
• For each call:
• The call identifier
• The call state: the state can be Initial, Proceeding, Accepted, Completed,
etc.
• The From field of the SIP call
• The To field of the SIP call
• The Session Timer method used for the refreshing
• The External Gateway number (It can be Not Used or -1 to 999)
• The total number of calls in the trunk (both active & inactive calls)
6.1.5.3.10 Option 10 - SIP traces filters

    

 !"  
  193/915
Chapter 6 

As of R9.0, this option allows to apply filters to SIP calls displayed in the traces.
A maximum of five filters can be configured.
Filters Overview
The filters appear in a table as follows:
Example:
-------------------------------------------------------------------
| Nb | Filter | From | To | P_Asserted |Request URI |
-------------------------------------------------------------------
| 1 | alcatel-lucent.fr | Yes | Yes | | |
-------------------------------------------------------------------
| 2 | 78450 | | Yes | | Yes |
-------------------------------------------------------------------
......
Each line refers to a filter with the criteria on which the filter must apply, which includes:
- The SIP call data to search (Filter field)
- The header fields in which the SIP call data must be searched (From, To, P_Asserted,
and Request URI fields). When one or several header fields are selected (set to Yes),
SIP calls are traced according to the content of these selected headers.
In the example above, the first filter allows to trace the SIP calls which contain the data
alcatel-lucent.fr in their From header or To header.
SIP calls are traced when they match at least one of the five potential filters. A SIP call
matches a filter if it fills one of the conditions of the filter.
If a SIP call does not match any filter, the related traces are not displayed (whatever the trace
level).
Filters Configuration Menu
When the option SIP traces filters is selected, a new sub-menu is available:
SIP traces filters menu
1 - Display the traces filters
2 - Add a traces filter
3 - Update a traces filter
4 - Remove a traces filter
5 - Remove all traces filters
0 - Previous menu
Choice [0 - 5] :
Option details are as follows:
- 1 - Display the traces filters: is used to display the filters already configured
with data to search and header fields to filter
Example:
-------------------------------------------------------------------
| Nb | Filter | From | To | P_Asserted |Request URI |
-------------------------------------------------------------------
| 1 | alcatel-lucent.fr | Yes | Yes | | |
-------------------------------------------------------------------
| 2 | 78450 | | Yes | | Yes |
-------------------------------------------------------------------
| 3 | siemens | Yes | | | |
-------------------------------------------------------------------
| 4 | ... | ... | ... | | ... |
-------------------------------------------------------------------
| 5 | ... | ... | ... | | ... |
-------------------------------------------------------------------
- 2 - Add a traces filter: is used to create a new filter by entering filter data and

194/915     


 !"  
 
 

selecting the header fields to filter

- 3 - Update a traces filter: is used to modify the criteria defined for a filter by
indicating for each header field if it must be filtered or not
- 4 - Remove a traces filter: is used to remove a particular filter
- 5 - Remove all traces filter: is used to remove all filters already configured. This
option allows to displays the traces of all SIP calls
6.1.5.4 Incidents

Incident Number Incident description

5800 Indicates that the SIP trunk group N has got into service
5801 Indicates that the SIP trunk group N has got out of service
5812 Indicates that an external gateway has got into service
5813 Indicates that an external gateway has got out of service

6.1.5.5 Traces

Between the Call Server and the Proxy, there is:

- Interface I1, facing Call handling,
- Interface I2, facing the motor, which sends "simili-SIP" messages to the motor,
- The motor, which creates SIP messages from data supplied by interface I2 (Call ID is
managed by the motor).
Traces can be executed at three levels:
- Between I1 and 12:
tuner +cpu +cpl
tuner hybrid=on
mtracer -a &
Note:
Comply with the order, "send" indicates coming from SIP.
- Between I2 and the motor ("simili-SIP" messages)
tuner appli-trace=on
actdbg sip=on
mtracer -a &
- Between the motor and the proxy ("real" SIP messages)
cd /usr2/servers
motortrace n (with two useful trace levels: n = 2 or 3)
traced &

    

 !"  
  195/915
Chapter 6 

6.2 SIP End Point Level Of Service

6.2.1 Overview
6.2.1.1 Overview
Within the Alcatel-Lucent OmniPCX Enterprise Communication Server, SIP sets are declared
as local users. They benefit from the phone services usually available for typical PCX sets.
Up to R8.0, although they are declared in the Alcatel-Lucent OmniPCX Enterprise
Communication Server as local users (SIP device mode), SIP sets are considered by the
phone application as part of a remote subnetwork (seen as a plain subnetwork by the PCX).
This operating mode requires to configure a subnetwork, and the trunk group associated to
this subnetwork, before declaring SIP sets. These SIP sets operating in SIP device mode
have fewer phone services than typical PCX sets. They cannot use prefixes/suffixes to activate
PCX phone services.
As of R9.0, SIP sets operate in SEPLOS (SIP End Point Level of Service) mode when they are
declared as local users in the Alcatel-Lucent OmniPCX Enterprise Communication Server. The
SIP sets operating in SEPLOS mode are considered by the phone application as internal sets
of the Alcatel-Lucent OmniPCX Enterprise Communication Server. They are assigned an
equipment number.
More phone services are available on the SIP sets operating in SEPLOS mode, compared to
the SIP sets operating previously in SIP device mode.
SIP sets operating in SEPLOS can, notably:
- Use prefixes/suffixes to activate PCX phone services
- Access to a large range of PCX phone services (camp on, consultation call, broker call,
call forwarding, etc.)
- Belong to a pick-up or hunting group
- Be used as hotel dedicated set
SIP sets operating in SEPLOS mode can also be monitered by CSTA services.

6.2.2 Detailed description

6.2.2.1 SIP Sets Operating in SEPLOS Mode
As of R9.0, the standard mode for SIP sets configured in the OmniPCX Enterprise is the
SEPLOS mode.
The SIP sets operating in SEPLOS mode must be declared as multiline sets in PCX
configuration, except for SIP sets operating as room sets in a hotel/hospital configuration. In
this case, they must be monoline sets.
When an OmniPCX Enterprise software version update occurs for R9.0, all SIP sets declared
previously as SIP device are converted into SIP extension (i.e. SEPLOS mode).
All new SIP sets must be configured as SIP Extension in the Com Server (see: SIP End Point
Level Of Service - Configuration procedure - Configuring SIP Sets ).

196/915     


 !"  
 
 

6.2.2.2 OmniPCX Enterprise SIP Components

Figure 6.24: OmniPCX Enterprise SIP Component Architecture

The SIP components included in the Alcatel-Lucent OmniPCX Enterprise Communication
Server are not specific to the SEPLOS mode. They are also used by the SIP trunking service.
For more information on their role and the messages exchanged, see: SIP - Detailed
description .
6.2.2.3 SIP Sets Configuration and Registration in SEPLOS Mode
To operate in SEPLOS mode, a SIP set must be:
- Declared on the Com Server as a SIP Extension (see: SIP End Point Level Of Service -
Configuration procedure - Configuring SIP Sets ). Declaring a SIP extension set
automatically triggers its registration in the SIP dictionary.

    

 !"  
  197/915
Chapter 6 

- Registered on the Com Server following its start-up. The SIP set sends a REGISTER
request to the Com Server registrar server. The registrar server, in turn, transmits data to
the location server. Registration data contain the SIP set's name and IP address.
Once a SIP Extension is declared on the PCX, it is in/out of service according to its
registration status on the registrar server. After telephony services are started (after a
RUNTEL), a SIP extension is in service only after it has registered: this can introduce a slight
delay in the SIP extension availability.
Caution:
A SIP extension must not be put in/out of service with the Inserv and Outserv commands.
The number of SIP sets operating in SEPLOS mode in the Alcatel-Lucent OmniPCX
Enterprise Communication Server is controlled by the current 177-SIP set user license
lock.
Notes:
- The forking feature is not compatible with SIP sets operating in SEPLOS mode. SIP set user should
not register under several addresses at the same time.
- To prevent identity abuse, it is recommended to use authentication for SIP set registration.
6.2.2.4 Dialing Modes
6.2.2.4.1 Outgoing Call
General Information
SIP set users have access to the complete numbering plan of the OmniPCX Enterprise
(internal, external, etc.).
Two situations can occur when a SIP set user makes a call:
- Dialing is complete (block dialing).
- Dialing is sent in overlap mode, digit by digit (overlap dialing).
Performing an outgoing call via the programmable keys, redial list, dial by name feature, etc.
may be available, depending on the SIP set capabilities.
Block Dialing
The SIP set sends an Invite message to the Com Server. The To field of this message
includes the complete dialed number.
Example:

198/915     


 !"  
 
 

Figure 6.25: Direct Call (Complete Dialing)

Overlap Dialing
The SIP set sends an Invite message to the Com Server with an incomplete dialing of a
number. The Com Server returns to the SIP set a response code 183 Progress, which
includes the SDP of the selected tone generator.
The SIP set sends the remaining digits to dial, digit by digit (DTMF sending). For more
information, see: DTMF Transmission
Example:

Figure 6.26: Direct Call (Incomplete Dialing)

6.2.2.4.2 Incoming Call

General Information
Depending on the PCX configuration for SIP set, up to 10 simultaneous incoming calls can be
processed when the SIP set is a multiline set (current configuration). If the SIP set is monoline
(room set in a hotel/hospital configuration), only one incoming call can be processed.
Note:
Distinction between internal or external calls through ringing melody and cadence, or LED signaling
depends on the SIP set capability. The PCX option Melody ringing type (access path: System > Other
system param.) is irrelevant for SIP sets.

Block Dialing (Invite Message Structure)

When an incoming call is presented to the SIP set, the Com Server sends an Invite
message.
In this message, the Request-URI, From and To fields consist of the following:
- Request-URI field: Uniform Resource Identifier (URI) of the SIP set
- From field: combination of the caller URI and name. For external calls, if the dictionary
does not succeed in associating a name to this number, the display name of the From field
contains the calling number: the number sent is the concatenation of the outgoing call
prefix and the calling number translated by the external callback translator (PCX option
Translator > External numbering plan > External callback translation).
Example 1:
if the external user 123456789 calls a SIP set, the From field becomes: “0123456789”
00123456789@192.168.80.10.

    

 !"  
  199/915
Chapter 6 

- To field: its content depends on the call type:

• Direct call: SIP set URI and name.
• Forwarded call: URI and name of the set that has forwarded its calls to the SIP set.
• Supervised call: URI and name of the set that is supervised by the SIP set.
Example 2:

Figure 6.27: Direct Call

6.2.2.5 Codec Negotiation

6.2.2.5.1 Outgoing Call
During call establishment, the SIP set sends to the Com Server an Invite message including
an SDP with the list of codecs defined in its parameters (see: SIP End Point Level Of Service -
Configuration procedure - Operations to Perform on SIP Sets ).
The Com Server applies a filter to the list of codecs provided by the SIP set.
This filter removes:
- The codecs not identical to the compression algorithm defined in the PCX (PCX option
System > Other system param. > Compression parameters > Compression type),
whether or not the PCX is configured for multiple algorithms (PCX option System > Other
system param. > Compression parameters > Multi. Algorithms for Compression)
- The G.711 codec not using the PCX law (PCX option System > Other system param. >
System parameters > Law)
Example:

200/915     


 !"  
 
 

Following the filtering of codecs by the Com Server, several situations can occur:
- No codec is selected: the call is released with a response code 415 Unsupported
Media Type
- One codec is selected:
• G.723 or G.729 (for intra or extra domain call): this codec is selected (1).
• G.711:
• For intra domain call: G.711 is selected.
Note 1:
Provided that CAC counters allow the call, and a compressor is available if necessary (for
example, the SIP set calls a TDM set behind a Media Gateway).
• For extra domain call (without compression used): G.711 is selected.
Note 2:
Provided that CAC counters allow the call, and a compressor is available if necessary (for
example, the SIP set calls a TDM set behind a Media Gateway).
• For extra domain call (with requested compression): G.711 is selected if:
• Two compressors are available in the SIP set domain for G.711 <-> G.72x
translation.
Note 3:
Provided that CAC counters allow the call, and a compressor is available if necessary
(for example, the SIP set calls a TDM set behind a Media Gateway).

• Two compressors are available in a third domain for which no compression is

    

 !"  
  201/915
Chapter 6 

used between this domain and the SIP set domain.

Note 4:
Provided that CAC counters allow the call, and a compressor is available if necessary
(for example, the SIP set calls a TDM set behind a Media Gateway).

• If only one compressor or no compressor is available, the call is released with a

response code 415 Unsupported Media Type
- Two codecs are selected: the direct RTP service is promoted from end-to-end. If the first
codec is G.711, and direct RTP is possible with compression and not possible with G.711,
the second codec is used (G.723 or G.729).
6.2.2.5.2 Incoming Call
During call establishment, the Com Server sends to the SIP set an Invite message including
an SDP with the PCX list of codecs (PCX compression algorithm and PCX law).
Depending on the caller and the SIP set domains, the codec list sent by the Com Server is
built according to the following extra or intra domain rule:
- Compression is required:
1. PCX compression algorithm (PCX option System > Other system param. >
Compression parameters > Compression type)
2. G.711 with PCX law (PCX option System > Other system param. > System
parameters > Law)
- Compression is not required:
1. G.711 with PCX law (PCX option System > Other system param. > System
parameters > Law)
2. PCX compression algorithm (PCX option System > Other system param. >

202/915     


 !"  
 
 

Compression parameters > Compression type)

Example:
The PCX compression algorithm is G.729 and the PCX law is A. The caller is in another domain than the
SIP set and the extra-domain call requires compression. According to the rule explained above, the built
codec list is as follows:
1. G.729
2. G.711 (A law)
6.2.2.6 DTMF Transmission
DTMF transmission used with SIP sets complies with RFC 4733 (RTP payload for DTMF
digits) and uses the Out of band method for DTMF sending. Each digit is sent within the RTP
flow with a specific payload (negotiated through SDP).
The In band and Info methods are not used for SIP sets operating in SEPLOS mode. The
selection of the DTMF sending mode is performed on SIP set parameters (see: SIP End Point
Level Of Service - Configuration procedure - Operations to Perform on SIP Sets )
Note:
As the Out of band method is used for DTMF sending, the SIP set is always in DTMF signaling mode
during conversation.

6.2.2.6.1 Outgoing Call

For RTP payload, the used value is given by the SIP set.
6.2.2.6.2 Incoming Call
For RTP payload, the used value is given by the following PCX option: Dynamic payload type
for DTMF parameter (access path: SIP > SIP Gateway).
For network calls, the codec list and RTP payload values are defined on the caller side and
sent through an ABC-F trunk. The Com Server copies these parameters in SDP part included
in the Invite message.
6.2.2.7 Keep-Alive Dialog
As of R9.1, a keep-alive dialog can be established between a SIP set and the Com Server,
provided that the Keep-Alive parameter is set to yes in PCX configuration (see: SIP End Point
Level Of Service - Configuration procedure - Configuring SIP Set Specific Parameters ). The
keep-alive dialog allows SIP sets to use the features impacted by their status.
The keep-alive dialog requires that SIP sets can send OPTION requests to the PCX.
A keep-alive dialog, initiated by the SIP set, allows the Com Server to check whether the SIP
set is in service. Periodically, the SIP set sends an OPTION request to the Com Server to
indicate it is operational. In turn, the Com Server sends an acknowledgement message to the
SIP set. The SIP set keeps sending OPTION requests as long as it receives acknowledgement
messages from the Com Server.
The time interval between two OPTION requests must be defined:
- In SIP set parameters.
The destination address for OPTION requests must be specified. See: SIP End Point Level
Of Service - Configuration procedure - Operations to Perform on SIP Sets
- In the settings of IP domain. The SIP Keep Alive timer is configured in the IP Quality of

    

 !"  
  203/915
Chapter 6 

Service COS of the IP domain of the IP set.

A SIP Lost delay must be specified. See: SIP End Point Level Of Service - Configuration
procedure - Configuring SIP Set Specific Parameters
When the Com Server does not receive an OPTION request before the timer expires (sum of
SIP Keep Alive timer and SIP Lost delay), the SIP set is considered out of service by the
Com Server. The SIP set must register once again to be in service. If the Com Server receives
an OPTION request before the SIP set registration expires, the SIP set is put in service again.
In a Com Server duplication configuration, the standby Com Server only updates the SIP Keep
Alive timer when it receives a REGISTER request from the SIP set. When a switchover occurs,
the main Com Server starts updating the timer every second and the keep-alive dialog is
maintained.
6.2.2.8 Caller Name Display on SIP Sets
The caller name displayed on SIP sets can be:
- The standard name (non-UTF-8) in Latin characters (up to 16 characters long, PCX
options Users > Directory name and Directory first name)
- The UTF-8 name used for long Latin names (up to 30 characters long, PCX options Users
> UTF-8 Directory name and UTF-8 Directory first name) and name in non-Latin
characters
The format of the caller name displayed on SIP sets is determined by the PCX option Display
UTF-8 (access path: Users > SIP Extension > Phone COS). For more information, see: SIP
End Point Level Of Service - Configuration procedure - Configuring SIP Set Specific
Parameters .
Note:
The Com Server does not control the information displayed on SIP sets.

6.2.2.9 Available Phone Features

Important:
The following sections do not describe the general process of message exchanges between SIP
sets and the Com Server. To view the detail of exchanges, see: SIP End Point Level Of Service -
Call Flows Description - Available Phone Features .

6.2.2.9.1 Appointment Reminder and Wake-up

A SIP set user can program an appointment reminder or a wake-up call from his/her SIP set by
dialing the corresponding prefix.
Caution:
Only one appointment reminder or wake-up can be programmed at a time on a SIP set.

6.2.2.9.2 Automatic Off-hook Dialing

The Automatic off-hook dialing service cannot be activated for SIP sets because they cannot
send an empty Invite message to the Com Server (PCX option: Class of service > Phone
feature COS > Routing Mode At Off-hook). Depending on the SIP set, it can however be
used as a local feature.
6.2.2.9.3 Barge-in
A SIP set user can perform barge-in on a busy PCX set which is in communication with

204/915     


 !"  
 
 

another set (local or external) by dialing the corresponding suffix.

Caution:
A PCX set user cannot make an intrusion on a SIP set in busy state because this SIP set is
multiline (current configuration).

6.2.2.9.4 Broker Call

A SIP set user can speak with two correspondents alternatively.
6.2.2.9.5 Call Announce
During call establishment (ringing phase), a SIP set user can activate the call announce
feature (i.e. Loudspeaker Barge-in) feature by dialing the corresponding suffix.
This feature is not available when the called party is located on another node connected via an
ABC-F trunk group on IP.
Caution:
A PCX set user cannot speak on the loudspeaker of the SIP set called, whether the set is busy or
not.

6.2.2.9.6 Call Forwarding

A SIP set user can activate call forwarding and select the destination set to which incoming
calls are rerouted.
Call forwarding can be programmed on the Com Server (prefix) or SIP set (local
programming).
Since call forwarding can be programmed on both SIP set and Com Server, their order of
execution is governed by a priority rule. The following table gives the result according to the
selected settings:
Com Server forwarding
Yes No
Yes Com Server forward (1) SIP set forward (2)
SIP set forwarding
No Com Server forward (1) No forward

(1)
: There is no message sent by the Com Server to the SIP set on incoming call.
Caution 1:
Because a SIP set cannot send an empty Invite message to the Com Server, the SIP set user
cannot listen to the voice guide played when off-hook indicating the call is forwarded.
(2)
: If the SIP set user programs local call forwarding, the SIP set sends to the Com Server a
response code 302 Moved Temporarily. If this response cannot be translated into an entry
in the Com Server numbering plan, the incoming call is either rerouted to the associate set if
configured or:
- Released if the incoming call is an internal call
- Routed according to the SIP set's entity table if the incoming call is an external call
Caution 2:
If a local call is forwarded to the entry point of a Routing Service Intelligence (RSI), call
forwarding cannot operate.

    

 !"  
  205/915
Chapter 6 

Note:
If forwarding on no reply is programmed on both sides, it is the one with the shortest timeout which is
used.
If the destination of call forwarding is an external SIP voice mail and this voice mail is
unavailable, the set that programmed the last call forwarding rings, provided call forwarding is
configured in the OmniPCX Enterprise. The parameter Display call server information must
be set to False (see: SIP End Point Level Of Service - Configuration procedure - Configuring
SIP Set Specific Parameters ).
6.2.2.9.7 Call Hold
During a conversation, a SIP set user can put the other party on hold.
A PCX set user can also put a SIP set user on hold.
6.2.2.9.8 Call Park
A SIP set user can park a call and retrieve a call that has been parked using the appropriate
prefix.
6.2.2.9.9 Callback Request
During call establishment (ringing phase), a SIP set user can activate the callback feature by
dialing the corresponding suffix.
This feature is not available when the called party is located on another node connected via an
ABC-F trunk group on IP.
6.2.2.9.10 Camp-on
During call establishment (ringing phase), a SIP set user can asks for camp on by dialing the
corresponding suffix. On suffix reception, the Com Server connects the SIP set to the hold
tone until the called party answers.
The Camp-on feature can be authorized or forbidden on the Com Server (prefix) or SIP set
(local programming).
Since the camp-on can be authorized or forbidden on both SIP set and Com Server, their
order of execution is governed by a priority rule. The following table gives the result according
to the selected settings:
Com Server call waiting
Authorized Forbidden
Authorized Authorized Forbidden
SIP set call waiting Forwarded to the asso-
Forbidden ciate, if configured Forbidden
(see: Call Forwarding )

6.2.2.9.11 Conferences
Three–party Conference
A SIP set user can initiate and participate in a three-party conference.
A SIP set user can initiate a transfer or exclude a participant.

206/915     


 !"  
 
 

Casual Conference
A SIP set user can participate in a casual conference but cannot insert new participants. When
this situation occurs, the Invite message sent to the new called party is rejected with the
response code 488 Not Acceptable Here.
Mastered Conference
A SIP set user can participate in a mastered conference but cannot be the master of the
conference.
Meet-me Conference
A SIP set user can initiate and participate in a meet-me conference using the appropriate
prefix.
6.2.2.9.12 Consultation Call (i.e. Enquiry Call)
During a conversation, a SIP set user can put the other party on hold (dialog is interrupted)
and call a new party.
6.2.2.9.13 Do not Disturb
A SIP set user can activate the do not disturb feature by dialing the appropriate prefix.
Since do not disturb can be programmed on both SIP set and Com Server, their order of
execution is governed by a priority rule. The following table gives the result according to the
selected settings:
Com Server do not disturb
Yes No
Com Server do not dis- SIP set do not disturb
Yes
SIP set do not dis- turb (1) (2)
turb Com Server do not dis-
No Any do not disturb
turb (1)

(1)
: there is no message sent by the Com Server to the SIP set on an incoming call.
Caution:
There is no indication on the SIP set that the do not disturb feature is active.
(2)
: if the SIP set has programmed a local do not disturb, it sends to the Com Server a
response code 486 Busy Here (or 480 Temporarily Unavailable or 603 Decline).
6.2.2.9.14 Hotel Dedicated Sets
A SIP set can be:
- An administrative (staff) set
- A room or suite set
- A booth (house) set
When a client of a room calls another room or administrative set, the Com Server sends an
Invite message including at the end of the Display-name of the From field the following
information: VIP status, type of occupancy and guest language respectively V, * and language

    

 !"  
  207/915
Chapter 6 

code (two characters maximum).

Caution:
- When a guest check-in occurs, the SIP set idle screen is not refreshed by the Com Server.
- Only direct external calls can be made from booth set. Line transfer (dialing tone) from the
attendant is not allowed, but call transfer (the external set is rung) is allowed.
6.2.2.9.15 Multiline Set
A SIP set must be a multiline set with at least two programmable keys configured as multiline.
It can have up to 10 programmable keys.
A SIP multiline set can have programmable keys associated to:
- The main directory number
- Secondary directory number(s)
When secondary directory numbers are declared on a multiline set, the Invite message sent
to the SIP set includes the called directory number at the beginning of the Display-name of
the From field.
Notes:
- A consultation call cannot be carried out on a busy line of a multiline SIP set. It is always made on a
new multiline key.
- The following PCX options Automatic Incoming Seizure, Automatic Outgoing Seizure and
Supervision at off-hook (access path: Users) are irrelevant for SIP sets because they cannot send
to the Com Server an empty Invite message.
6.2.2.9.16 Pick-up or Hunting Group
A SIP set can belong to pick-up or hunting groups (circular or sequential), except for parallel
hunting groups.
For an incoming group call to a SIP set, the Invite message sent to the SIP set includes the
group call mark (*) at the end of the Display-name of the From field.
6.2.2.9.17 Secret Identity
The secret/identity status of an outgoing call from a SIP set depends on:
- The secret identity defined in the SIP set entity
- The presence of the Secret/Identity prefix
- The secret identity local feature dedicated to SIP sets
By defaut, SIP set calls are subject to secret identity as configured in the entity they belong to.
When SIP set users have no right to modify their secret identity, they are subject to the secret
identity definition in the SIP set entity of the PCX. The Invite message type (anonymous or
non anonymous) and the presence of the Secret/Identity prefix are not taken into account.
When SIP set users have right to modify their secret identity, they can use the Secret/Identity
prefix and hence not be subject to the state imposed on their entity.
Since secret identity can be programmed on the Com Server and also activated on the SIP
set, their order of execution is governed by a priority rule. The following table gives the result
according to selected settings when the SIP set user has right to modify the secret identity
feature on his/her set.

208/915     


 !"  
 
 

Set entity programming

Secret Identity
Secret identity not activ- Called party number Secret Identity
ated on the SIP set (non Secret/Identity prefix +
anonymous Invite called party number Secret Secret
message)
Secret identity activated Called party number Secret Secret
on the SIP set Secret/Identity prefix +
(anonymous Invite called party number Secret Secret
message)

6.2.2.9.18 Supervision
A SIP set user can supervise PCX set users. The status of the supervised PCX set is not
indicated on the SIP set by a signaling key (no icon or LED). Supervised calls are identified by
a ringing on the SIP set. This demands to configure the ringing option on the SIP set.
The supervision key must have its ringing mode set with another option than no ring (it can be
short ring or long ring). There is no distinction between the different ring types, as the SIP set
rings during the whole of call presentation.
Note:
Supervision of a set located on another node is not possible.

6.2.2.9.19 Transfer
Transfer Made During Ringing Phase
A SIP set user is in conversation with a first party and starts a consultation call to another
party. The first party is put on hold.
During call establishment (ringing phase) with the second party (e.g. consultation call), the SIP
set user can activate the transfer feature by pressing the appropriate programmable key on
his/her SIP set.
Note:
A PCX set user can also transfer a SIP set user during call establishment.

Transfer Made During a Conversation

A SIP set user wishes to put on hold the first party and is in conversation with a second party.
During conversation, the SIP set user can transfer the party in conversation to:
- The first party on hold by pressing the appropriate programmable key on his/her SIP set.
- A given addressee by pressing the appropriate programmable key on his/her SIP set.
Note:
A PCX set user can also transfer a SIP set user during a conversation.

6.2.2.9.20 Twin Sets

A SIP set can belong to a twin set association as main or secondary set.
When the SIP set is the main set and an incoming call (direct or forwarded) is presented to the

    

 !"  
  209/915
Chapter 6 

twin set association, the Com Server sends to the SIP set an Invite message with the From
and To fields filled as described in: Block Dialing (Invite Message Structure) .
The content of the From and To fields change when the main set is:
- An Alcatel-Lucent 8/9 series set and the incoming call is a forwarded call: the content of
the From and To fields depend on the PCX option Specific telephone services > Display
mode of call ID.
Display mode of call ID
Calling Name => Called Calling No => Called
=> Called party name
No Name
Calling party name and
From Calling party number (*) Calling party number (*)
number
Field
Called party name and Called party name and
To Called party name (*)
number number
(*)
: the display-name contains the other party's number.
- A Reflexes set and the incoming call is a direct call or forwarded call:
• The From field includes the display and entity installation number; which is the
concatenation of the digits to add to perform a callback (PCX option Translator >
External Numbering Plan > Ext. Callback Translation) and the installation number
of SIP set entity (PCX options Entities > Installation No. (ISDN) and
Supplement.Install.No.).
• The To field includes the set name and URI. The indication of call forwarded is lost
(except through the display-name of the From field).
Note:
The following PCX option Users > Ringing in partial busy is irrelevant for SIP sets because they are
always rung during the entire call presentation.

6.2.2.9.21 Phone Features Provided by Dialing a Prefix

When an Invite message with a prefix number is sent to the Com Server, the Com Server
returns a response with a Reason Header. The SIP set user can hear prefix acknowledgement
(or refusal) or intermediate steps if the Invite message does not contain the whole of prefix
and related data.
When the prefix is accepted, the Com Server sends a 183 Progress response with a Reason
Header and the user can hear the tone corresponding to the service (or voice guide, or voice
mail acknowledgement, as e.g. to program a wake-up call). The 183 Progress response
contains a Reason Header with cause=200 and no text, unless the Send NOTIFY instead of
MESSAGE parameter is enabled (see below). When some prefixes such as forward, do not
disturb, wake-up, lock are accepted, 8082 My IC Phone sets release the call with a Cancel
message. The behavior of other sets depends on their configuration.
When the prefix is refused, the Com Server sends a 403 Forbidden response and a text
identical to the one displayed on Alcatel-Lucent 8/9 series set in a similar situation. The text in
the Reason Header is written in the set language stored on the Com Server. SIP sets display
this text, according to their capability and configuration.
When a prefix is accepted, a text is included in the Reason Header in the 183 Progress
response, provided the Send NOTIFY instead of MESSAGE parameter, defined in the
configuration of SIP extension > Phone Class of Service, is set to YES (see SIP End Point
Level Of Service - Configuration procedure - Configuring SIP Set Specific Parameters ). This

210/915     


 !"  
 
 

feature is used in particular by 8082 My IC Phone sets.

The list of prefixes associated to a text in the reason header of a response message is
detailed: table: table: List of prefixes with text .
table 6.51: List of prefixes with text
Set features Immediate forward
Immediate forward on busy
Forward on no answer
Forward on busy or no answer
Forward cancellation
Lock
Password modification
Do not disturb
Language
Suite do not disturb (hotel)
Local Features Wake-up or appointment reminder
Cancel wake-up or appointment reminder
Suite wake-up (hotel)
Suite wake-up cancel (hotel)

Example:
The detail of message exchanges when a SIP set user dials the prefix relating to immediate forwarding is
given in SIP End Point Level Of Service - Call Flows Description - Activating a PCX Service from a SIP
Set by Dialing a Prefix .
The following table presents the phone features available or not by dialing a prefix:
Feature Available Comments
Attendant call Yes Routing
Professional trunk seizure Yes Routing
Modem trunk seizure N.A.
Set features:
Immediate forward Yes
Immediate forward on busy Yes
Forward on no answer Yes
Forward on busy or no answer Yes
Forward cancellation Yes
Forward cancellation by destin- Yes
ation
Overflow on no answer to as- Yes
sociate
Cancel overflow to associate Yes
Station group exit Yes

    

 !"  
  211/915
Chapter 6 

Feature Available Comments

Station group entry Yes
Protected against barge-in and Yes
beeps
Lock Yes
Auto-assignment Yes
Substitution Yes
Password modification Yes
Accounting and charge back No
readout
Do not disturb Yes
Set in or out of service No
Associate directory number Yes
modification
Remote forward Yes
Cancel remote forward Yes
Cancel automatic call back on Yes
busy
Personal directory program- No Can be a local feature
ming
Personal directory use No Can be a local feature
Language Yes
Adjust display visibility No
Access and review alarms No Can be a local feature
Camp-on control Yes
Overflow on busy to associate Yes
set
Overflow on busy or no answer Yes
to associate set
Voice guide listening Yes
Suite do not disturb Yes
No ringing No Attendant assistant feature not avail-
able
Tandem: assistant away No Via a programmable key
Tandem: filter activation No Via a programmable key
Force set type identification No
Privileged substitution No
Ubiquity mobile programming Yes
Ubiquity Yes
Remote extension deactivation Yes
Remote extension activation Yes

212/915     


 !"  
 
 

Feature Available Comments

General features:
Group call pick up Yes
Direct call pick up Yes
Agent processing group call No
pick up
Local features:
Speed call to associated set Yes
Access to callback list No Only automatic callbacks can be car-
ried out
Last caller call back No Can be a local feature
Paging call answer Yes
Voice mail access Yes
Wake-up or appointment re- Yes
minder
Tone test Yes
Collect telex Yes
Collect text Yes
Collect fax Yes
Message deposit Yes
Text deposit Yes
Image deposit Yes
ACD No
Meet-me conference Yes
Cancel wake-up or appoint- Yes
ment
Switch off message LED Yes
Room status management Yes
Mini-bar Yes
Voice mail manager access No
Conversation recording No Via a programmable key
PBX address in DPNSS N.A.
Direct paging call Yes
Infocenter Yes
Voice mail deposit Yes
Select primary line Yes
Select Secondary line Yes
Z dialing behind UA N.A.
Mask remote identity No Via a programmable key

    

 !"  
  213/915
Chapter 6 

Feature Available Comments

Recordable voice guides No
Suite wake-up Yes
Suite wake-up cancel Yes
Physical room call Yes
Under 4980 Softphone control Yes
Manual add-on conference No
Automatic add-on conference No
Announcement No
Automatic answering N.A. Can be a local feature
Call restriction service Yes
Explicit priority Yes
Intercom service loop No Via a programmable key
Explicit precedence level Yes
CUG call No
Background music No Via a programmable key
External features:
Direct trunk seizure No
Business account code Yes
Redial last number No Can be a local feature
Night service answering No
DTMF frequencies test No
Park call or retrieve call Yes
Access to waiting call No Can be a local feature
Rotary end-to-end dialing No
DTMF end-to-end dialing No
Malicious call No Via a programmable key
Common hold No Via a programmable key
Identity secrecy Yes Can be a local feature
Alphanumeric paging Yes
Manual hold No Via SIP protocol
Direct speed dialing number Yes Routing
Data transfer No
DISA N.A.
Incoming call greeting guide No
Speed dialing area Yes Routing
Network number Yes Routing
Professional trunk group with overlap- Yes Routing
ping

214/915     


 !"  
 
 

Feature Available Comments

Routing number Yes Routing
Robot call N.A.
VPN overflow N.A.
Individual attendant call Yes Routing
Attendant group call Yes Routing
Entity call Yes Routing
Personal trunk group seizure Yes Routing
Personal trunk group seizure with Yes Routing
overlapping
ARS professional trunk group seizure Yes Routing
ARS professional trunk group seizure Yes Routing
with overlapping
ARS personal trunk group Yes Routing
ARS Personal trunk group with over- Yes Routing
lapping
ARS modem trunk group with overlap- Yes Routing
ping
Local short dialing Yes Routing
Open routing number Yes Routing
X25 physical address N.A.
X25 ISDN access number N.A.
Hybrid access N.A.
Virtual access N.A.
Entity voice mail box number Yes
Hybrid link N.A.
Hybrid trunk group address N.A.
ARS server N.A.
Unlock DISA Yes
Ubiquity services:
Ubiquity voice mail Yes
Ubiquity mobile Yes
Ubiquity contact Yes
Analog compressed support No
Centrex reserved area Yes
Company call number Yes
External network dialing No
Remote extension DISA N.A.

N.A.: not applicable.

    

 !"  
  215/915
Chapter 6 

6.2.2.9.22 Phone Features Provided by Programmable Keys

A SIP set operating in SEPLOS mode can have up to 10 programmable keys. These keys are
virtual and there is no correlation between them and the SIP set physical keys.
Example:
A supervision of a given set is programmed on a SIP set on key 3 in the Alcatel-Lucent OmniPCX
Enterprise Communication Server configuration. The SIP set is in idle state and an incoming call is
received on the supervised set. The call on the supervising set is presented on the first free physical call
key of the SIP set.
The following table presents the phone features provided or not by programmable keys:
Feature Available Comments
Programmed No Can be a local feature
Videophone No
Telesurveillance No
Manager mail No
Forwarding on ringing No Can be a local feature
Assistant away No
Screening key Yes
Unscreening key Yes
Trunk group Supervision No Key signaling required
Trunk supervision No Key signaling required
Set supervision Yes
Assistant call No
Manager call No
Multiline Yes
Routing assistant No
ACD resources No
ACD listening No
ACD general forwarding No
Headset No Can be a local feature
Data No
ISDN filtering key No
Data supervision key No
Screening supervision Yes
Consultation No Via SIP protocol
Broker No Via SIP protocol
Forward No Via a prefix or local feature
Redial No Can be a local feature
Mail No

216/915     


 !"  
 
 

Feature Available Comments

Redial memory No Can be a local feature
Transfer No Via SIP protocol
ISDN No Can be a local feature
Personal directory No Can be a local feature
Callback No Via a suffix
Three-party conference No Via SIP protocol
Barge-in No Via a suffix
Busy camp-on No Via a suffix
Speaker paging No Via a suffix
Call announcement No Via a suffix
Paging request No Via a suffix
Business number No
Rotary end-to-end dialing No
DTMF end-to-end dialing No
Malicious call No Via a prefix
Voice mail message deposit No Via a suffix
Camp-on control No
Network manager call No
Network assistant call No
General forwarding of pilot No
Closing processing group No
Attendant assistant No
Tele-worker permanent connection No
Supervised parallel set No
Primary MLA No Key signaling required
Secondary MLA No Key signaling required
Voice mail supervision No Key signaling required
ACD line No
CEI key No

6.2.2.10 Interactions with other PCX Services

6.2.2.10.1 Accounting
Accounting tickets (call detail record) are generated for local or external calls to a SIP set .
6.2.2.10.2 Attendant Service
A SIP set user can call an attendant. On attendant answer, the Com Server sends to the SIP
set a response code 200 OK.
An attendant can also call a SIP set user but cannot reserve this SIP set user. The SIP set is

    

 !"  
  217/915
Chapter 6 

immediately rung.
In conversation with a SIP set user, an attendant cannot perform a transfer with privilege
(service not available).
Caution:
An attendant cannot create a SIP set. If the SIP set is already created, the attendant can modify its
status and parameters (except for set type), or delete it.

Note:
To view the detail of message exchanges, see the example presented: SIP End Point Level Of Service -
Call Flows Description - Attendant Service .

6.2.2.10.3 Messaging Service

Voice Messages (Voice Mail)
A SIP set user can have a voice mailbox.
When connected to a voice mail, the SIP set controls it through DTMF signaling (Out of band
method).
During the ringing phase, a SIP set user can leave a voice message to the distant mailbox by
dialing the appropriate suffix. On suffix reception, the SIP set user is connected to the distant
mailbox.
This feature is not available when the called party is located on another node connected via an
ABC-F trunk group on IP.
Note:
To view the detail of message exchanges, see the example presented: SIP End Point Level Of Service -
Call Flows Description - Messaging Service .

Text Messages
A SIP set user cannot send or receive text messages from PCX set users. The PCX option
Dial by name and text msg. (access path: Users) is irrelevant for SIP sets.
The text message service is available on SIP sets using the Instant Messaging or SMS
services.
Alarm Messages
A SIP set user cannot receive alarm messages from a Notification Server. The PCX option
Notification server rights (access path: Users) is irrelevant for SIP sets.
Fax Messages
A SIP set user can view faxes if he/she has access to the Messaging Services provided by the
Alcatel-Lucent OmniTouch Unified Communications.
Unanswered Call Messages
Display of unanswered internal and external calls depends on the SIP set type. The PCX
options Internal and External (access path: Users) are irrelevant for SIP sets.
Automatic Callback

218/915     


 !"  
 
 

Only automatic callbacks are available on SIP sets in busy state (busy state on all lines of the
set is not required).
When an automatic callback is programmed for a SIP set, the Com Server sends an Invite
message including in the From field the following message Callback in progress before
the caller name.
When the SIP set user answers, the Com Server changes the incoming call into an outgoing
call by sending a Refer message to the SIP set.
Caution:
When the callback is activated, the SIP set rings. There is no way to prevent ringing when
sending an Invite message.

Note:
To view the detail of message exchanges, see the example presented SIP End Point Level Of Service -
Call Flows Description - Messaging Service .

Waiting Messages Indication

The Com Server sends a Notify message to the SIP set when the number of voice
messages, callbacks or faxes change. The following types of message-context-class are
used (see RFC 3458 and 3842):
- Voice-Message for voice messages
- Fax-Message for faxes
Note:
To view the detail of message exchanges, see the example presented: SIP End Point Level Of Service -
Call Flows Description - Messaging Service .

6.2.2.10.4 Infocenter
SIP set user absence can be configured via Infocenter facilities (call forwarding or do not
disturb)
When using Infocenter facilities, a set can have its phone book name modified in order to give
to the caller some information related to absence.
6.2.2.11 ABC-F Networking
If the remote node of the called party runs R9.0 (or higher), ABC-F messages carry RTP
information. The SIP messages flow is optimized.
If the remote node of the called party runs a release lower than R9.0, ABC-F messages do not
carry RTP information. The SIP messages flow is not optimized.
Note:
To view the detail of exchanges, see: SIP End Point Level Of Service - Call Flows Description -
Networking .

6.2.2.12 CSTA Services

SIP sets operating in SEPLOS mode can be monitered by CSTA.
CSTA also provides the call control features intended for SIP sets. The following table
presents the CSTA services which can apply to SIP sets.

    

 !"  
  219/915
Chapter 6 

Caution:
The CSTA services require to add the Answer-Mode field to the Invite message sent to a SIP set
(see RFC 5373) and the SIP set must not be forwarded or in do not disturb.
Activating local features such as Forward or Do Not Disturb is forbidden when using the
following services:
- Make call
- Answer call
table 6.54: Supported CSTA Services
CSTA Service Comments
Make call (without automat- On Make call service reception, the Com Server sends an Invite
ic off-Hook) message to the SIP set. The SIP set user answers.
The Com Server changes the incoming call into an outgoing call
by sending a Refer message to the SIP set
Make call (with automatic On Make call service reception, the Com Server adds an An-
off-Hook) swer-Mode field with Auto value in Invite message sent to
the SIP set
Make call (with answer call On Answer call service reception, the Com Server releases the
service) current dialog established with the SIP set. The Com Server cre-
ates a new dialog with the SIP set by sending an Invite mes-
sage with the Answer-Mode field set to Auto
Answer call A SIP set user is called.
On Answer call service reception, the Com Server releases the
current dialog with the SIP set (Invite message with the An-
swer-Mode field set to Manu). The Com Server creates a new
dialog with the SIP set by sending an Invite message with the
Answer-Mode field set to Auto
Clear connection (during The Com Server sends to the SIP set a response with the code
outgoing call) 487 Request terminated
Clear connection (during The Com Server sends a Bye message to the SIP set
conversation)
Divert call A SIP set user is called.
On Divert call service reception, the Com Server sends to the
SIP set a Cancel request
Hold call A SIP set user is in conversation.
On Hold call service reception, the Com Server sends to the SIP
set an Invite message with the SDP field set to Inactive
Retrieve call A SIP set user is on hold.
On Retrieve call service reception, the Com Server sends to the
SIP set an Invite message with a two-ways SDP

Note:
To view the detail of exchanges, see: SIP End Point Level Of Service - Call Flows Description - CSTA
Services .

6.2.2.13 Restrictions

220/915     


 !"  
 
 

A SIP set operating in SEPLOS mode cannot be:

- A Manager/Assistant set
- A night forwarding set (night service)
- An attendant set
- An associated set of an IP attendant
- An attendant assistant set
- An agent of a contact Center (Alcatel-Lucent OmniTouch Contact Center - Standard
Edition)
- An alarm set
SEPLOS is not compatible with TLS protection.
The following RFCs are not implemented in R9.1:
- RFC 3840 Indicating User agent Capabilities in the Session Initiation Protocol (SIP)
- RFC 4916 Connected Identity in the Session Initiation Protocol (SIP)
These RFCs will become available in future releases.
6.2.2.14 Standard Documents Used (RFCs and Drafts)
RFC References:
- RFC 3261 SIP: Session Initiation Protocol
- RFC 3323 A privacy Mechanism for the Session Initiation Protocol (SIP)
- RFC 3324 Short Term Requirements for Network Asserted Identity
- RFC 3325 Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks
- RFC 3326 The Reason Header Field for the Session Initiation Protocol (SIP)
- RFC 3458 Message Context for Internet Mail
- RFC 3515 The Session Initiation Protocol (SIP) Refer Method
- RFC 3578 Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP)
Overlap Signaling to the Session Initiation Protocol (SIP)
- RFC 3842 A Message Summary and Message Waiting Indication Event Package for the
Session Initiation Protocol (SIP)
- RFC 4733 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
Draft Reference:
- draft-ietf-sip-answermode Requesting Answering Modes for the session

6.2.3 Configuration procedure

6.2.3.1 Preamble
This chapter describes the settings to be configured for commissioning SIP sets in SEPLOS
mode.
Configuration can be divided into several steps:

    

 !"  
  221/915
Chapter 6 

- Configuring SIP sets with:

• Operations to perform on SIP sets
• Operations to perform on Com Server
- Configuring the SIP parameters dedicated to SIP sets operating in SEPLOS mode (phone
class of service)
- Configuring the dynamic payload type for DTMF
- Configuring the timers involved in the transactions (requests/responses) between SIP sets
and Com Server
- Configuring other specific SIP objects (proxy, registrar, dictionary, etc.), when appropriate
Note:
These SIP objects are not described in this chapter because they are not exclusively used for the
SEPLOS mode (see: SIP - Configuration procedure ).
The IP address of SIP sets can be consulted when SIP sets are registered on the Com Server
(see: Checking the IP Address of the SIP Sets Registered on the Com Server ).
6.2.3.2 Configuring SIP Sets Operating in SEPLOS Mode
6.2.3.2.1 Operations to Perform on SIP Sets
To configure SIP set parameters differs according to the SIP set type. This paragraph specifies
only parameters to configure on SIP sets. It does not provide any procedures and/or screens
to help in configuring SIP set parameters.
In all case, it is recommended to configure the following parameters:
- SIP set Initialization mode (dynamic or static)
- Network parameters if the initialization mode is static with:
• SIP set IP address
• Subnetwork mask
• Default router IP address
- SIP parameters with:
• Service domain address (*)
• Registrar address (**)
• Proxy address (**)
• Backup registrar address (***)
• Backup Proxy address (***)
• SIP set directory number and name
(*)
: This field must be completed with the logical node name of the Alcatel-Lucent
OmniPCX Enterprise CS.
(**)
: All these fields must be completed with the Com Server name or IP address. In a
duplicated configuration where the two Com Servers are on different subnetworks, they
must be configured with the Com Server name and the DNS addresses must be
configured as explained in: SIP - Detailed description - Configuring DNS addresses on SIP
end-points .
(***)
: These fields are used if the SIP extension is to be rescued by a Passive
Communication Server. They must be completed with the Passive Communication Server
IP address.

222/915     


 !"  
 
 

- The codec list definition. It is recommended to build the codecs list respecting the
following order:
1. The codec corresponding to the PCX compression algorithm (PCX option System >
Other system param. > Compression parameters > Compression type)
2. The G.711 corresponding to the PCX law (PCX option System > Other system
param. > System parameters > Law)
- The phone settings with:
• DTMF sending method: select only the Out of Band method (RFC 4733)
• Voice mail server address (Com Server IP address) and its directory number
- The keep-alive timer configuration with:
• The time interval expected between two OPTION requests from the SIP set. The timer
value must be identical to that of the Keep_Alive parameter defined in PCX
configuration (see: Configuring SIP Set Specific Parameters )
• The destination address for OPTION requests (addresses of Com Servers (main and
Standby) and PCS)
6.2.3.2.2 Operations to Perform on Com Server
Checking the Software Lock Dedicated to SIP Service
The number of SIP sets operating in SEPLOS mode is controlled by the existing 177-SIP
set user software lock. This software lock is dedicated to all SIP devices operating in both
SEPLOS and SIP device modes.
To display the software lock state, enter the spadmin command from the Com Server prompt.
Configuring SIP Sets
A SIP set operating in SEPLOS mode must be declared as an SIP Extension local user.
1. Select: Users
2. Review/modify the following attributes:
Directory Number Enter the directory number of the SIP set
Shelf Address Enter 255
Board Address Enter 255
Equipment Address Enter 255
Set Type Select SIP Extension.
URL UserName Enter, for example, the directory number of the set or
user name.
Note 1:
This field can be left blank. In this case, the directory number
is used for the user part of the URL.
URL Domain Leave this field blank

    

 !"  
  223/915
Chapter 6 

SIP Authentication Consultation of the name used for authentication with

proxy (non modifiable field): when a set registers on
the Alcatel-Lucent OmniPCX Enterprise CS, name
takes the value of the parameter: SIP URL User-
name.
SIP Passwd Enter a password (10 characters maximum).
Note 2:
The SIP authentication password is set by default at the
same value as the default password (secret code) of other
sets.
Confirm Confirm password.

3. Confirm your entries

6.2.3.3 Configuring SIP Set Specific Parameters
Configuring the SIP set specific parameters is a two step process:
1. Assign a phone Class Of Service (COS) to the SIP set. The phone COS used is
exclusively dedicated to SIP service (do not confuse with the phone COS that apply to all
PCX sets and which are defined in Classes of service > Phone feature COS).
1. Select: Users > SIP Extension Parameters
2. Review/modify the following attributes:
Directory number Enter the directory number of the selected SIP set
Phone COS Select a phone COS number between 0 to 31. Up to
32 phone COS are available
Default value: 0

3. Confirm your entry

2. In the phone class of service, configure the SIP set parameters:
1. Select: SIP Extension > Phone classes of service
2. Review/modify the following attributes:
Phone COS Enter the phone COS number associated to the selec-
ted SIP set
Display UTF-8 Yes: the caller name displayed on the SIP set is the
UTF-8 name
No: the caller name displayed on the SIP set is the
standard name in Latin characters
Default value: No

224/915     


 !"  
 
 

Display call server information
Keep-Alive
Send NOTIFY instead of MES-
SAGE
Yes: at SIP set registration or Com Server settings up-
date, a message is sent to the SIP set providing inform-
ation on Com Server settings, such as forward activa-
tion. The complete list of Com Server settings is
provided: SIP End Point Level Of Service - Call Flows
Description - Com Server Information Display
No: no message is sent to the SIP set following the set
registration or when the Com Server settings are up-
dated
Default value: yes
Yes: a keep-alive dialog (i.e. periodic exchange of
messages) is established between the SIP set and
PCX
No: no keep-alive dialog is established between the
SIP set and PCX
Default value: No
Select Yes for 8082 My IC Phone and sets which can
parse the NOTIFY message.
Select No for sets which cannot parse the NOTIFY
message with event user-profile.
For more information about this parameter, see SIP
End Point Level Of Service - Detailed description -
Phone Features Provided by Dialing a Prefix and SIP
End Point Level Of Service - Call Flows Description -
Call Type Identification

3. Confirm your entries

Additional parameters must be configured when the Keep_Alive parameter is set to yes.
1. Select: IP > IP Quality of Service COS
2. Review/modify the following attributes:
IP QoS COS Select the desired IP Quality of Service COS. This
COS must correspond to the COS defined in the IP do-
main of the set
SIP Lost This delay added to the SIP Keep Alive timer
(configured below) is used to define when a SIP set is
considered out of service (absence of keep-alive dia-
log). When the SIP set does not send an OPTION re-
quest before the timer elapses (sum of SIP Keep Alive
timer and SIP Lost delay), the SIP set is seen as out
of service
Default value: 5 (in seconds)
SIP Keep Alive Enter the time interval expected between two OPTION
requests from the SIP set
Default value: 30 (in seconds)

3. Confirm your entries

6.2.3.4 Configuring the Value of Dynamic Payload Type for DTMF
1. Select: SIP > SIP Gateway

    

 !"  
  225/915
Chapter 6 

2. Review/modify the following attribute:

Dynamic Payload Type for DTMF Enter a number between 96 and 127
This value is suggested by the PCX for outgoing calls
"negotiation value".
Default value: 97

3. Confirm your entry

6.2.3.5 Configuring the Timers
The timers involved in the transactions (requests/responses) between SIP sets and Com
Server are available for consultation and if needed for modification.
1. Select: System > Timers
2. Review/modify the following attributes:
Timer No. Enter the number of the timer
Timer units Modify the number of timer units (standard
unit:100ms).

3. Confirm your entry

table 6.61: List of Timers Available for Consultation
Timer No. Timer Unit Meaning
Max duration for call handling response on call control stimulus
361 1s
(internal timer)
362 32s Max duration for 180 Ringing response from SIP set
363 32s Max duration for 200 Ok response from SIP set
364 32s Max duration for 202 Accepted response from SIP set
Max duration for 487 Request Terminated response from SIP
365 32s
set
366 32s Max duration for Ack request from SIP set.
367 32s Max duration for Bye request from SIP set
368 32s Max duration for Invite request from SIP set.
369 32s Max duration for Notify request from SIP set.

6.2.3.6 Checking the IP Address of the SIP Sets Registered on the Com Server
When SIP sets send a request to the Com Server registrar server, their IP address are
registered in both registrar database and Com Server. The IP address is used to assign the
SIP set to an IP Telephony Domain and to handle features, such as Call Admission Control
(CAC).
When the registrar server receives a de-registration request or does not detect SIP set
presence after a timeout (5 minutes), the IP address of the corresponding SIP set is put to
0.0.0.0 on the Com Server and the SIP set is put out of service.
To consult the IP address of SIP sets:
1. Select: Users > IP SIP Extension

226/915     


 !"  
 
 

2. Review/modify the following attributes:

Directory Number Displays the directory number of the SIP set previously
selected
Set Type Displays: SIP Extension
IP Address Displays the IP address of the SIP set

6.2.4 Maintenance
6.2.4.1 Maintenance Commands
The following commands (to launch on the system terminal) are used to handle SIP sets
operating in SEPLOS mode:
Command Definition Syntax
csipsets Lists, for each declared SIP set, its csipsets
equipment number, directory number, or csipsets [d directory num-
name and its status (in or out of ser- ber]
vice)
or csipsets [n equipment num-
ber]
csipview Lists, for each active SIP set, its equip- csipview com
ment number, directory number, name,
IP addess and Call Handling or Call
Control processes presence
csipre- Resets SIP set dynamic data when it is csiprestart [d directory
start blocked number]
or csiprestart [n equipment
number]
sipdict Lists all declared SIP devices and their sipdict [-ilv]
type or sipdict [-n directory num-
ber]
or sipdict [-u URI name and
domain]
Inserv Puts a SIP set into service inserv [d directory number]
or inserv [n equipment num-
ber]
Outserv Puts a SIP set out of service outserv [d directory number]
or outserv [n equipment num-
ber]
killall Restarts the SIP motor process
sipmotor

6.2.4.2 Traces
6.2.4.2.1 Call Handling Traces
Enter the following commands to activate the specific SEPLOS call handling traces.

    

 !"  
  227/915
Chapter 6 

tuner [ at ] [ , equipment number]

actdbg noe on sip=on csip=on
mtracer&

6.2.4.2.2 SIP Motor Traces

Enter the following commands to activate the SIP motor traces.
motortrace [1234]
traced&

6.2.4.3 Error Codes

Error Message Meaning

403 Forbidden
404 Not Found
415 Unsupported Media
Type
416 Unsupported URI
Scheme
480 Temporarily Unavail-
able
484 Address Incomplete
488 Not Acceptable Here
Feature not allowed:
- Unauthorized prefix
- Wrong parameters (ex: SIP set forward attempt to itself)
- Wrong password
Wrong number
SDP not correct:
- No codecs correspondence
SDP: No codec has been selected in given list
- DTMF payload is missing (no RFC 4733)
SDP: DTMF payload for RFC 4733 is missing
- Direction is not set to send or receive
SDP: Direction must be sent and received
The Call Admission Control (CAC) does not allow the call, or no
compressor is available
URI of To field cannot be converted into a non-canonical number
(ex: +33390677001@alcatel.fr).
The called party, set or trunk group, is busy or out of service.
Or configuration is not available (when dialing a prefix that modi-
fies SIP set data)
Number not complete
Call Handling does not accept this situation (*)

(*)
: This situation can occur when:
- The PCX configuration does not allow it. For example, only incoming calls are allowed for
this SIP set (PCX option: Classes of service > Phone features COS > Routing Mode at
Off-hook is set to Specialized incoming)
- All PCX resources configured for this SIP set are used. For example, two lines are
programmed and busy, and the SIP set wants to start a new call
- Parallel outgoing calls are not allowed. For example, an outgoing call is made while the
current one is not again answered

6.2.5 Call Flows Description

6.2.5.1 Graphical Conventions

228/915     


 !"  
 
 

Icon Comments
Com Server with:
- Typical PCX sets (TDM or IP) or SIP sets operating in SEPLOS
mode with:
• Name: Laura, directory number: 7001
• Name: Carol, directory number: 7002
• Name: Sandy, directory number: 7003
- Internal applications with:
• A voice mail: My voice mail, directory number: 7100
• An attendant: The attendant, directory number: 7999
SIP set operating in SEPLOS mode (Name: Brian, directory number:
7000)

SIP message (only relevant fields are displayed)

RTP flow

6.2.5.2 Outgoing Calls

6.2.5.2.1 Outgoing Call with Bloc Dialing

Example:

6.2.5.2.2 Outgoing Call with Overlap Dialing

Example:

    

 !"  
  229/915
Chapter 6 

Note:
Overlap dialing as described here has nothing to do with the one described in RFC 3578.

6.2.5.2.3 Called Party is Free

Example:

230/915     


 !"  
 
 

6.2.5.2.4 Called Party is Busy

Example:

6.2.5.2.5 Called Party is Forwarded

Example:

    

 !"  
  231/915
Chapter 6 

When the called party is located on another node and has forwarded calls towards an external
number, the Com Server is not able to fill correctly the 302 Moved Temporarily Contact
field because the external number is not provided by call handling.

232/915     


 !"  
 
 

An incoming call from a SIP set towards a set which has forwarded calls towards a text
message does not follow the forward. The initial called party is rung (same functioning as for
sets without display).
6.2.5.2.6 Called Party is Forwarded on no Answer

Example:

6.2.5.2.7 Called Party is in Do not Disturb Mode

Example:

    

 !"  
  233/915
Chapter 6 

6.2.5.2.8 Called Party has Activated Secret Identity

Example:

6.2.5.2.9 Called Party is out of Service

Example:

6.2.5.2.10 Outgoing Call Picked up

Example:

234/915     


 !"  
 
 

6.2.5.2.11 Outgoing Call Rejection

Badly Formatted Invite Message
When the Invite message is incorrect (SDP, URI or To field), the Com Server sends an error
code response to the SIP set (for more information, see: SIP End Point Level Of Service -
Maintenance - Error Codes )
Example:
Outgoing call rejection due to a problem on the codecs list sent by the SIP set.

    

 !"  
  235/915
Chapter 6 

Call Handling Rejection

In case of unwanted incoming calls (according to configuration or call handling), the Com
Server sends an error code response 488 Not Acceptable Here to the SIP set (for more
information, see: SIP End Point Level Of Service - Maintenance - Error Codes )
Example:
Outgoing call rejection due to a problem of outgoing calls made in parallel by the same SIP set.

6.2.5.3 Incoming Calls

6.2.5.3.1 Direct Incoming Call

236/915     


 !"  
 
 

Example:

6.2.5.3.2 Incoming Call Resulting from a Forward or Supervision Request

Example:
The Com Server sends an Invite message where the URI of Request-URI and To fields differ.

For calls forwarded, the From and To fields are always filled in the same way, whatever the
value of the following PCX option: Display mode of call ID (access path: Specific Telephone
Services).

    

 !"  
  237/915
Chapter 6 

6.2.5.3.3 Incoming Call Resulting from a Barge-in (i.e. Intrusion) Request

Example:

Note:
The Com Server sends an Invite message including the SDP conference equipment.

6.2.5.3.4 Incoming Call with Caller Secret Identity Activated

Example:

238/915     


 !"  
 
 

Note:
The Com Server does not include a P-Asserted-Identity field into Invite message.

6.2.5.3.5 Incoming Call Rejection (Error Code)

Example:

6.2.5.3.6 Unanswered Incoming Calls

Incoming calls can be presented to a SIP set, but not answered because of Call Handling
restriction. This situation can occur when a SIP set is configured as:
- A monoline set (operating as room sets in a hotel/hospital configuration), and engaged in a
consultation call (i.e. enquiry call)
- A multiline set (current configuration), and involved in a conference
- A multiline set (current configuration), and connected to a voice mail
- A multiline set (current configuration), and in conversation with an attendant (see example
below).
In this last configuration, answering an incoming call is not possible due to the fact that an
attendant cannot be put on hold. Thus , the Com Server sends a response code 488 Not
Acceptable Here.
Example:

    

 !"  
  239/915
Chapter 6 

6.2.5.3.7 Call Type Identification

The incoming call type identification feature allows to indicate the type of an incoming call in
the Alert-Info header of INVITE message.
The incoming call type identification feature is enabled when the Send NOTIFY instead of
MESSAGE parameter, defined in the configuration of SIP extension > Phone Class of
Service, is set to YES (see SIP End Point Level Of Service - Configuration procedure -
Configuring SIP Set Specific Parameters ). This feature has been implemented for 8082 My IC
Phone sets, which accept all the call types mentioned below.
Example:

240/915     


 !"  
 
 

The different call types are:

- External call: Call from an external trunk
- Appointment call: Call for a predefined appointment (wake-up call)
- Boss call: Call from a manager in a manager/assistant set
- Internal call: Other calls
The call type is defined in the URN
- External call: urn:alert:tone:external
- Appointment call: urn:alert:tone:appointment
- Boss call: urn:alert:tone:boss
- Internal call: urn:alert:tone:internal
Note:
Only the internal and external types of call are defined in a standard (IETF document: Alert-Info URNs for
the Session Initiation Protocol (SIP) draft-alexeitsev-bliss-alert-info-urns-02). SIP sets complying to this
standard can accept these two types of call.

6.2.5.4 Call Release

6.2.5.4.1 Following an Outgoing Call
Release Made by the SIP Set User

Example:

    

 !"  
  241/915
Chapter 6 

Release Made by the Called Party

Example:

6.2.5.4.2 Following an Incoming Call

Release Made by the SIP Set User

Example:

Release Made by the Called Party

Example:

242/915     


 !"  
 
 

6.2.5.4.3 In Conversation
Release Made by the SIP Set User

Example:

Release Made by the Called Party

On distant on-hook, the Com Server connects the SIP set to the on-hook tone. If, following the
time-out, the SIP set user has not picked up, the Com Server releases the call with a Bye
message.
Example:

    

 !"  
  243/915
Chapter 6 

6.2.5.5 Available Phone Features

6.2.5.5.1 Appointment Reminder and Wake-up
When the appointment reminder expires, the SIP set rings. When this situation occurs, the
Com Server sends an Invite message to the SIP set including in the From field the following
information:
- The Display name: combination of the You asked for an appointment string and
appointment time
- The Uniform Resource Identifier (URI): combination of the digits to add in order to perform
a callback (PCX option Translator > External Numbering Plan > Ext. Callback
Translation) and installation number of SIP set entity (PCX options Entities > Installation
No. (ISDN) and Supplement.Install.No. (ISDN)).
Example 1:
If the Installation number of SIP set entity is 0123450001 and appointment is at 4:27 pm, the From field
contains: "You asked for an appointment: 4:27 pm" 00123450001@192.168.80.10

Example 2:

244/915     


 !"  
 
 

6.2.5.5.2 Barge-in (i.e. Intrusion)

On barge-in suffix reception, the Com Server selects a conference circuit to perform intrusion.
The Com Server sends to the SIP set the response code 200 OK SDP: Conference
equipment.
Example:

6.2.5.5.3 Broker Call

    

 !"  
  245/915
Chapter 6 

A SIP set user has put his/her first correspondent on hold and is in conversation with a second
correspondent.
The SIP set user can put on hold the second correspondent. When this situation occurs, the
SIP set sends to the Com Server an Invite message with the SDP field set to Send only.
The SIP set user picks up the first correspondent on hold. The SIP set sends to the Com
Server an Invite message with the SDP field set to Send and receive.
Example:

6.2.5.5.4 Call Announce

On call announce suffix reception, the called party loudspeaker is activated (unidirectional
communication). When the called party off-hooks, the loudspeaker of the set is activated
(bidirectional communication)
The Com Server sends to the SIP set an Invite message with SDP: Called party set
- Send and Receive
Example:

246/915     


 !"  
 
 

6.2.5.5.5 Call Forwarding

Example:

6.2.5.5.6 Call Hold

Distant Put on Hold by the SIP Set User
When this situation occurs, the SIP set sends an Invite message with a one-way SDP. The
distant is then connected to the SIP set entity hold music. If the distant cannot be put on hold,
the Com Server sends to the SIP set a response code 488 Not Acceptable Here with the
Reason field set to Call can't be put on hold.

    

 !"  
  247/915
Chapter 6 

To retrieve the correspondent on hold, the SIP set sends to the Com Server an Invite
message with a two-way SDP.
Example:

SIP Set Releases Distant Previously Put on Hold

Possibility to release a call put on hold. The SIP set sends a Bye towards the Com Server.

SIP Set Put on Hold by the Distant

248/915     


 !"  
 
 

Example:

6.2.5.5.7 Callback Request

On callback suffix reception, the Com Server connects the SIP set user to the request
recorded tone or corresponding voice guide.
Example:

    

 !"  
  249/915
Chapter 6 

6.2.5.5.8 Camp-on
On camp-on suffix reception, the Com Server connects the SIP set user to the hold tone until
the called party answers.
The Com Server sends to the SIP set the response code 200 OK SDP: Called party
set
Example:

6.2.5.5.9 Conferences
Three–party Conference
Three–party Conference Initiated by a SIP Set User
If one of the participants leaves the conference, the Com Server sends a Bye message to the
SIP set. The remaining RTP flow is kept with the last participant.
When the SIP set user excludes a participant who was previously on hold before starting the
conference, the SIP set sends a Bye message to the Com Server. The remaining RTP flow is
kept with the last participant.

250/915     


 !"  
 
 

When the SIP set user initiates a transfer, the SIP set sends a Refer message to the Com
Server. The SIP set user is no longer connected to both correspondents which still converse. If
the transfer is forbidden, the Com Server sends to the SIP set a response code 488 Not
Acceptable Here.
When the SIP set user is inserted into a conference, the Com Server sends to the SIP set an
Invite message including the SDP conference equipement.
Example:

If transfer is forbidden, the Com Server answers with a 488 Not Acceptable Here instead
of Notify.

    

 !"  
  251/915
Chapter 6 

Three–party Conference Released by a SIP Set User

Example:

252/915     


 !"  
 
 

One of the Correspondents Leaves the Conference

Example:

Transfer of Two Correspondents Initiated by a SIP Set User

Example:

    

 !"  
  253/915
Chapter 6 

Three–party Conference Initiated by a PCX Set User

Example:

254/915     


 !"  
 
 

Casual Conference

Example:

    

 !"  
  255/915
Chapter 6 

6.2.5.5.10 Consultation Call (i.e. Enquiry Call)

When a SIP set user puts his/her correspondent on hold (during a conversation) and calls a
new correspondent, an Invite message is sent to the Com Server (a new dialog is
established).
Example:

6.2.5.5.11 Do not Disturb

Example:

6.2.5.5.12 Multiline Set

Example:

256/915     


 !"  
 
 

6.2.5.5.13 Secret Identity

Example:

Caution:
An anonymous call must include in the Invite message a P-Asserted-Identity (see RFC
3323, 3324 and 3325) or Contact field with the SIP set URI.

6.2.5.5.14 Supervision
When the supervised set is called, the Com Server sends to the SIP set an Invite message
with:
- The From field filled as follows:

    

 !"  
  257/915
Chapter 6 

• Display name: combination of Supervision string and caller name

• URI: caller URI
- The To field filled as follows:
• Display name: supervised number
• URI: supervised URI
Example:

6.2.5.5.15 Transfer
Transfer Made by a SIP Set User (Ringing Phase)
When this situation occurs, the consultation call is released and with a Refer message, the
SIP set notifies the Com Server to put both correspondents in contact. If transfer is not
allowed, the Com Server sends a response code 488 Not Acceptable Here.
Example 1:

258/915     


 !"  
 
 

If transfer is forbidden, the Com Server answers with a response code 488 Not
Acceptable Here, instead of the Notify message.
Example 2:

    

 !"  
  259/915
Chapter 6 

Transfer Made by a SIP Set User (in Conversation)

During the conversation, the SIP set user can transfer his/her correspondent to:
- The first one on hold by pressing the appropriate programmable key on his/her SIP set.
When this situation occurs, the SIP set sends a Refer message to the Com Server to put
both correspondents in contact. If transfer is not allowed, the Com Server sends to the SIP
set a response code 488 Not Acceptable Here.
- A given recipient by pressing the appropriate programmable key on his/her SIP set. When
this situation occurs, the SIP set sends a Refer message to the Com Server with the
directory number of the new contact to which the call must be transferred. If the directory
number does not correspond to any entry in the OmniPCX Enterprise numbering plan, the
recipient is out of service or transfer is not allowed, the Com Server sends to the SIP set a
response code 488 Not Acceptable Here.

260/915     


 !"  
 
 

Attended Transfer

Example:

Unattended Transfer

Example:
When in conversation, a SIP set user asks the Com Server to transfer the correspondent to a given
recipient.

    

 !"  
  261/915
Chapter 6 

Note:
If the Refer-To URI does not correspond to any entry in the Com Server numbering plan, the recipient
is out of service or transfer is forbidden, the Com Server answers with a response code 488 Not
Acceptable Here, instead of the Notify message.

Transfer Made by the Distant (Ringing Phase)

Example:

262/915     


 !"  
 
 

Transfer Made by the Distant (in Conversation)

Example:

    

 !"  
  263/915
Chapter 6 

6.2.5.6 Interactions with other PCX Services

6.2.5.6.1 Attendant Service
Attendant Called by a SIP Set User

Example:

264/915     


 !"  
 
 

SIP Set Called by an Attendant

Example:

6.2.5.6.2 Messaging Service

Voice Mail Deposit

Example:

    

 !"  
  265/915
Chapter 6 

Automatic Callback

Example:
Brian asks for an automatic callback on Laura's set.

266/915     


 !"  
 
 

Message LED Configuration

Example:

    

 !"  
  267/915
Chapter 6 

6.2.5.7 Activating a PCX Service from a SIP Set by Dialing a Prefix

Example:
A SIP set user activates an immediate forward on his/her set by dialing the prefix followed by the required
forward directory number.

6.2.5.8 Com Server Information Display

At SIP set registration or Com Server settings update, a message is sent to the SIP set
providing information on Com Server settings, provided that the Display call server
information parameter is set to yes in PCX configuration (see: SIP End Point Level Of
Service - Configuration procedure - Configuring SIP Set Specific Parameters ).

268/915     


 !"  
 
 

The information displayed in the message applies to the following features:

Feature Information displayed
Forward activation The type of forward, on which lines it applies
(primary or secondary) and the destination
number.
- Immediate forward: Immediate fwd, P
: immediate fwd or S : immediate
fwd
- Immediate forward on busy: Forward
on busy, P : fwd on busy or S :
fwd on busy
- Delayed forward on no answer: Fwd on
no reply, P : fwd no reply or S :
fwd no reply
- Forward on busy and no answer: Fwd
busy/no rep, P : busy/no reply or
S : busy/no reply
Do not disturb activation Do not disturb activated
Remote extension deactivation Dual ring off
Hunting group belonging You are in the group or You are out
of group
Appointment or wake-up programmed Appointment at or Wake up at string
and the appointment hour.
Lock activation Set is locked

When information applies to several features, data is concatenated in a string, which may be
up to 128 characters long (data order is the same as in the list presented above). For example,
if immediate forward to 7001 is activated and an appointment at 4:27 pm is programmed, the
string is: Immediate fwd -> 7001 – Appointment at 4:27 pm
Example:
Message sent to the SIP set indicating an immediate forward (Immediate fwd) on the directory number
7001. The From and To fields are the SIP set URI

6.2.5.9 Networking
6.2.5.9.1 Remote Node Release R9.0 (or Later)

Example:

    

 !"  
  269/915
Chapter 6 

Brian calls a remote IP phone.

6.2.5.9.2 Remote Node Release up to R8.0

Example:
Brian calls a remote IP phone:
- On Alert reception, the Com Server sends a 180 Ringing with the local tone generator RTP
information as SDP. It gets then the remote tone generator RTP information with some delay through
H.323. A second response code 180 Ringing is sent.
- Same behavior on Connect reception. The Com Server sends a first RESPONSE CODE 200 Ok
with remote tone generator RTP information as SDP. It gets then the remote called party RTP
information with some delay through H.323. An Invite is then sent, but only after Ack reception.

270/915     


 !"  
 
 

6.2.5.10 CSTA Services

6.2.5.10.1 Make Call (Without Automatic Off-Hook)

Example:

    

 !"  
  271/915
Chapter 6 

6.2.5.10.2 Make Call (with Automatic Off-Hook)

Example:

272/915     


 !"  
 
 

6.2.5.10.3 Make Call (with Answer Call Service)

Example:

    

 !"  
  273/915
Chapter 6 

Figure 6.96: Part 1

274/915     


 !"  
 
 

Figure 6.97: Part 2

6.2.5.10.4 Answer Call

Example:

    

 !"  
  275/915
Chapter 6 

6.2.5.10.5 Clear Connection (During Outgoing Call)

Example:

6.2.5.10.6 Clear Connection (During Conversation)

Example:

6.2.5.10.7 Divert Call

Example:

276/915     


 !"  
 
 

6.2.5.10.8 Hold Call

Example:

6.2.5.10.9 Retrieve Call

Example:

    

 !"  
  277/915
Chapter 6 

6.3 SIP Trunking

6.3.1 Overview
6.3.1.1 Overview
SIP trunking allows connection:
- To one or several public operators with the same level of service as ISDN
- To a private network: for example to other Alcatel-Lucent OmniPCX Enterprise
Communication Server
Features offered by SIP trunking include:
- Possibility to mix different kinds of accesses on a node: analog, ISDN, H.323, SIP
- Compatibility with existing services such as routing (by means of ARS, speed dialing
numbers, routing prefixes, etc.), call barring, incoming call distribution
- Access to ABC-F network, transit between SIP and public (ISDN, analog, ...) or private
(QSIG, DPNSS, ...) accesses
- Integration with management tools, such as configuration tools, traffic observation,
metering, alarms, etc.
- Compatibility with OmniTouch Contact Center solutions, and more generally the same
CSTA level of service as for classical accesses
- Compatibility with the internal services originally devoted to ISDN accesses, such as
OmniPCX Integrated Cellular Client, automatic substitution, digit transparency, etc.
- Call Admission Control over IP
- T.38 fax
- ISDN services such as CLIP/CLIR, COLP/COLR

6.3.2 Topologies
6.3.2.1 Overview

278/915     


 !"  
 
 

SIP carriers are reached through a SIP trunk group and an external gateway.
Up to R7.0, there is only one SIP trunk group, used for external SIP extensions, OTUC and
external gateways.
As of R7.1, it is possible to create several SIP trunk groups. The main SIP trunk group should
therefore be used only for external SIP extensions and OTUC. Additional SIP trunk group(s)
can be created to connect the Alcatel-Lucent OmniPCX Enterprise CS to either:
- another private network (A-BCF),
- a public network (ISDN).
There are four possible topologies as illustrated in the following paragraphs.
6.3.2.2 SIP Trunking Based on One Gateway, one SIP Carrier and one SIP Trunk
Group

Figure 6.104: Configuration Example with one Carrier, one Gateway and one ISDN SIP Trunk
Group

Figure 6.105: Configuration Example with one Carrier, one Gateway and one ABC-F SIP
Trunk Group

6.3.2.3 SIP Trunking Based on One Gateway for each SIP Carrier
- One SIP trunk group for several external gateways

    

 !"  
  279/915
Chapter 6 

Figure 6.106: Configuration Example with one SIP Trunk Group and two Carriers
- One SIP trunk group for each external gateway

Figure 6.107: Configuration Example with two SIP Trunk Groups and two Carriers

6.3.2.4 SIP Trunking Based on Several SIP Access Points for one Carrier
If the remote carrier provides several SIP access points, either the supervision through
OPTIONS or DNS SRV can be used.
The SIP access points provided by a carrier can be supervised through OPTIONS, as
illustrated: figure: Configuration Example with one Carrier and two Gateways Supervised
through OPTIONS . In this configuration, load balancing is not available. External gateway 2
and proxy 2 are used as backup when external gateway 1 and proxy 1 are unavailable.
For outgoing calls, ARS is used:
- The first route uses the SIP trunk group + external gateway 1

280/915     


 !"  
 
 

- The second route uses the SIP trunk group + external gateway 2

Figure 6.108: Configuration Example with one Carrier and two Gateways Supervised through
OPTIONS
A carrier may provide two SIP access points and DNS SRV service, as illustrated: figure:
Configuration Example with one Carrier Providing Two Proxies associated to DNS SRV . DNS
SRV sends the addresses of the two proxies along with the associated priority levels.
In this configuration, load balancing and main/backup redundancy are available, depending on
the level of priority associated to each access point.
- If the priority level of proxy 1 and proxy 2 are the same, load is shared between the two
proxies.
- If the priority level of proxy 2 is lower than the priority level of proxy 1, proxy 2 is used as
backup of proxy 1

Figure 6.109: Configuration Example with one Carrier Providing Two Proxies associated to
DNS SRV

Note:

    

 !"  
  281/915
Chapter 6 

The DNS SRV function can also be provided by the Session Border Controller (SBC) as illustrated:
figure: Configuration Example with one Carrier Providing Two Proxies associated to DNS SRV .
Operation is similar as with DNS SRV provided by the carrier.

Figure 6.110: Configuration Example with DNS SRV Function Provided by SBC

6.3.2.5 SIP Trunking Based on Several Trunk Groups for several Gateways and one
Carrier
In this configuration, one trunk group is dedicated to outgoing calls through ARS, while the
other trunk group is dedicated to incoming calls.

Figure 6.111: Configuration Example with one Carrier, two Gateways and two SIP Trunk
Groups

6.3.3 Detailed description

6.3.3.1 SIP external gateways

282/915     


 !"  
 
 

An external gateway is an OmniPCX Enterprise object. It is the internal representation of a

remote proxy/gateway of a SIP carrier.
As of R7.1, characteristics of an external gateway are enhanced. For example, an external
gateway can register with its own address to the SIP carrier.
As of R10.0, SIP/TLS is supported with external gateways: see IP Touch Security - Overview
for more details.
The parameters of an external gateway include:
- An integer value used for internal identification within the OmniPCX Enterprise (SIP
External Gateway ID)
- As of R7.1, if needed, the address of the outbound Proxy to be used for outgoing requests
from the external gateway
- As of R7.1, if the external gateway is to register to the SIP carrier, a Registration Id and
Belonging domain, which correspond to the user and domain parts of the registration
address
- A SIP Remote domain, which corresponds to the domain name of the remote SIP entity
(proxy/gateway of the SIP carrier) associated with the external gateway
- The identifier of the SIP trunk group to be used by incoming calls
In the examples below, the following values are used:
- Registration Id: GwId
- Belonging domain: LocalDomain
- External proxy address part: there.com
- External proxy user part: SIP carrier
- SIP Remote domain: RemoteDomain
- OmniPCX Enterprise address: OXE_Address
6.3.3.2 Outbound proxy
It is possible to define an outbound proxy to be used for outgoing requests from the external
gateway toward the SIP carrier. If no outbound proxy is defined, outgoing requests are sent to
the SIP remote domain.
Example 1:
INVITE request with an outbound Proxy, whose URL is sipcarrier@there.com
INVITE sip:4000@RemoteDomain SIP/2.0
To :<sip:4000@RemoteDomain>
From : <sip:5000@LocalDomain>
Route : <sip:sipcarrier@there.com>
The INVITE request is sent to the IP address of there.com.
Example 2:
INVITE request without outbound Proxy
INVITE sip:4000@RemoteDomain SIP/2.0
To : <sip:4000@RemoteDomain>

    

 !"  
  283/915
Chapter 6 

From : <sip:5000@LocalDomain>
The INVITE request is sent to the IP address of RemoteDomain.
6.3.3.3 DNS cache
The OmniPCX Enterprise can send outbound requests either to an outbound proxy, if
configured (see: Outbound proxy ), or to the SIP remote domain. For readability purposes, the
term remote target refers to either the outbound proxy or SIP remote domain in the rest of the
document.
The remote target can be identified either by a FQDN or an IP address. When the FQDN is
used, a DNS request is sent by the external gateway to a DNS server to determine the IP
address of the remote target. The type of DNS request (DNS A or DNS SRV) depends on the
DNS type parameter value configured in the external gateway (see: SIP Trunking -
Configuration procedure - Configuring an External Gateway ).
The PCX stores the IP addresses of all remote targets to which outbound requests are sent, in
a DNS cache. For more information, refer to the SIP Generalities documentation (see: SIP -
Detailed description - DNS cache ).
As of R10.1, according to the external gateway configuration, the DNS cache can be used for
incoming call routing: it enables to determine the origin of an incoming call (see: Origin of the
incoming call ).
The following scenarios indicate how the DNS cache of the OmniPCX Enterprise is updated
after outbound requests sent to remote targets. The sent messages use the REGISTER,
INVITE or OPTIONS methods.
Possible scenarios are:
- The remote target (proxy1) is identified by its IP address:

As a result, the IP address of proxy1 is stored in the DNS cache of the OmniPCX
Enterprise.
- The remote target (proxy1) is identified by its FQDN. A DNS A request is sent:

284/915     


 !"  
 
 

As a result, the IP address of proxy1 is stored in the DNS cache of the OmniPCX
Enterprise.
- The remote target (proxy1) is identified by its FQDN. A DNS SRV request is sent and a full
response is returned:

As a result, the IP addresses of proxy1 and proxy2 are stored in the DNS cache of the
OmniPCX Enterprise.
- The remote target (proxy1) is identified by its FQDN. A DNS SRV request is sent and an
incomplete response is returned:

    

 !"  
  285/915
Chapter 6 

As a result:
a. The IP address of proxy1 is stored in the DNS cache of the OmniPCX Enterprise.
b. The IP address of proxy2 is stored in the DNS cache of the OmniPCX Enterprise.
Note:
When a switchover occurs, or when the SIP Motor restarts, or when a PCS becomes active, the
registration procedure restarts. In the standby PCX or inactive PCS, the DNS cache remains empty.
6.3.3.4 External gateway registration
6.3.3.4.1 Principle
If configured on the OmniPCX Enterprise, an external gateway registers to the associated SIP
carrier. A registration Id and a domain name must be defined, as well as an expiration timer,
which defines the life time to be applied to the registration.
The registration of external gateways takes place at Communication Server start-up. It is sent

286/915     


 !"  
 
 

to the URL of the outbound proxy, if defined, or to the SIP remote domain otherwise.
Example:
With an outbound Proxy
REGISTER sip:RemoteDomain SIP/2.0
To : <GwId@RemoteDomain>
From : <GwId@LocalDomain>
Contact : <GwId@OXE_Address>
Route : <sip:sipcarrier@there.com>
Expires : Timer
If a REGISTER method receives a 200.OK response, the external gateways get back, or
remain, into service.
If a REGISTER method receives no response after a timer, it is retransmitted until the
maximum number of retransmissions is reached. When this number is reached the OmniPCX
Enterprise considers the SIP carrier as unavailable.
- Up to R9.1, the maximum number of retransmissions is 6, as defined in RFC 3261. As a
consequence, it takes 32 s before the OmniPCX Enterprise considers that no response
has been received.
- As of R10.0, the maximum number of retransmissions can be configured in the external
gateway parameters (Number of re-transmission for REGISTER / OPTIONS): see SIP
Trunking - Configuration procedure - Configuring an External Gateway . This allows to
manage the time after which an external gateway is considered unavailable, as indicated
on table: Expiration Timer Value Relating to the Number of Retransmissions .
table 6.67: Expiration Timer Value Relating to the Number of Retransmissions
Number of Retransmissions Expiration Timer Value
1 1s
2 2 s (default value)
3 4s
4 8s
5 12 s
6 16 s

6.3.3.4.2 Registration after an outbound proxy switchover

SIP carriers may provide several outbound proxies. In this case, when there is a switchover
between the active outbound proxy and another outbound proxy, SIP communications are not
delivered to the PCX, nor accepted by the SIP carrier, as long as a new external gateway
registration has not been performed on the operational outbound proxy.
When an outbound request (that is an INVITE method) is sent to the outbound proxy out of
service, the request is rejected with the error response: 403 forbidden.
As of R10.1, when the Registration on proxy discovery parameter value is set to True, and
the current outbound proxy is out of service, a new external gateway registration is launched
using the information stored in the DNS cache of the OmniPCX Enterprise (see: DNS cache ).
The following scenarios display the registration procedure when the current outbound proxy is

    

 !"  
  287/915
Chapter 6 

out of service, according to the DNS type used (A or SRV) and the Time To Live (TTL) status
(running or expired):
- Registration process with DNS A and TTL running:

While the TTL is running, a switchover occurs between proxy1 and proxy2:
• The PCX sends an INVITE method to proxy1
As proxy1 is out of service, its IP address is removed from the DNS cache
• The PCX sends a DNS request, which returns the IP address of proxy2
The IP address of proxy2 is stored in the DNS cache
• The PCX sends a REGISTER method to proxy2
The registration procedure is executed
- Registration procedure with DNS A and TTL expired:

288/915     


 !"  
 
 

When a switchover occurs between proxy1 and proxy2 and the TTL expires:
• The PCX tries to send an INVITE method
• As the TTL has expired, the PCX sends a DNS request, which returns the IP address
of proxy2
The IP address of proxy2 is stored in the DNS cache
• As the external gateway is not registered with proxy2, the request is rejected with the
error response: 403 forbidden.
The IP address of proxy2 is stored in the DNS cache
• The PCX sends a REGISTER method to proxy2
The registration procedure is executed
- Registration procedure with DNS SRV and TTL running:

    

 !"  
  289/915
Chapter 6 

While the TTL is running, a switchover occurs between proxy1 and proxy2:
• The PCX sends an INVITE method to proxy1
As proxy1 is out of service, its IP address is outdated
• The PCX sends an INVITE method to proxy2
• As the external gateway is not registered with proxy2, the request is rejected with the
error response: 403 forbidden.
• The PCX sends a REGISTER method to proxy2
The registration procedure is executed
- Registration procedure with DNS SRV and TTL expired:

290/915     


 !"  
 
 

When a switchover occurs between proxy1 and proxy2 and the TTL expires:
• The PCX tries to send an INVITE method
• As the TTL has expired, the PCX sends a DNS request, which returns the IP
addresses of proxy1 and proxy2
The IP addresses of proxy1 and proxy2 are stored in the DNS cache
• As proxy1 does not answer, the PCX sends an INVITE method to proxy2
The IP address of the proxy1 is outdated in the DNS cache
• As the external gateway is not registered with proxy2, the request is rejected with the
error response: 403 forbidden.
• The PCX sends a REGISTER method to proxy2
The registration procedure is executed

    

 !"  
  291/915
Chapter 6 

Note:
• In releases prior to R11.0, all INVITE methods sent during the registration procedure fail.
• As of R11.0, all INVITE methods sent during the registration procedure are queued. When
registration is performed, the queued methods are sent.
6.3.3.5 Supervision of an external gateway
To avoid useless Outgoing Traffic, the status of each external gateway can be supervised by
sending periodic OPTIONS method to the remote carrier. The periodicity of OPTIONS method
emission is configured in the external gateway parameters (Supervision timer): see SIP
Trunking - Configuration procedure - Configuring an External Gateway .
The domain part of the From section of the OPTIONS method is built with the SIP Remote
domain parameter, rather than with the Belonging domain, as is done for the INVITE
method.
Example:
With an outbound Proxy
OPTIONS sip:RemoteDomain SIP/2.0
To : <GwId@RemoteDomain>
From : <GwId@LocalDomain>
Contact : <GwId@OXE_Address>
Route : <sip:sipcarrier@there.com>
Expires : Timer
If a 200.OK or a 405.Method Not Allowed response is received, the corresponding
external gateway moves, or remains, into service. When getting back into service, incident
5812 is generated.
When no adequate response, or no response, is received after the timer has elapsed, the
OPTIONS method is retransmitted until the maximum number of retransmissions is reached.
The retransmission process is the same as for registration ( External gateway registration ).
- Up to R9.1, the maximum number of retransmissions is 6, as defined in RFC 3261. As a
consequence, it takes 32 s before the OmniPCX Enterprise considers that no response
has been received.
- As of R10.0, the maximum number of retransmissions can be configured in the external
gateway parameters (Number of re-transmission for REGISTER / OPTIONS): see SIP
Trunking - Configuration procedure - Configuring an External Gateway .
If no adequate response, or no response, is received after the maximum number of
retransmissions is reached, the external gateway moves, or remains, out of service. Incident
5813 is generated.
When an external gateway moves out of service, if the associated trunk group is only served
by this gateway, the trunk group moves out of service. Incident 5801 is generated.
The supervision process goes on during the time an external gateway is out of service. As
soon as a 200.OK or a 405.Method Not Allowed response is received, the external
gateway gets back into service and, if required, tries to register again.
If an outbound proxy is managed, there may be one or more remote proxy behind the
OmniPCX Enterprise. In this case, the entire path is supervised.

292/915     


 !"  
 
 

6.3.3.6 Proxy server selection

A SIP carrier can implement a configuration with several proxy servers for the same gateway.
This configuration allows:
- Redundancy: when a server fails, the others continue to work
- Load balancing: when a server is overloaded, calls can be routed to another server
The OmniPCX Enterprise is notified of a multi proxy server configuration from the DNS
request.
To received multi proxy server notifications, the external gateway of the SIP carrier must be
configured with the DNS type parameter set to DNS SRV (see configuration: SIP Trunking -
Configuration procedure - Configuring an External Gateway ).
A multi proxy DNS response includes:
- The list of IP address of the proxy servers
- The priority of each proxy server
- The load of each proxy server
- The live time for received information
The OmniPCX Enterprise selects the proxy server to use according to the priority and load
information it receives. If priority and load are identical, the OmniPCX Enterprise balances
INVITE requests between these servers.
When the INVITE request to a selected proxy does not generate an answer, the OmniPCX
Enterprise tries another proxy.
When the INVITE request receives a busy response, two processes are possible:
- Before R11.0.1, when a proxy server answers an INVITE request with a busy message,
the call fails.
- As of R11.0.1, when a proxy server answers an INVITE request with a busy message, the
OmniPCX Enterprise reroutes the INVITE message to another server. If this new server
also returns a busy message, the OmniPCX Enterprise reroutes again the INVITE
message again.
The number of rerouting is limited by the parameter DNS SRV/Call retry on busy server
of the external gateway (see configuration: SIP Trunking - Configuration procedure -
Configuring an External Gateway ).
The list of busy messages invoking a rerouting is:
• 408 Request Timeout
• 480 Temporarily Unavailable
• 486 Busy here
• 488 Not Acceptable Here
• 500 Server Internal Error
• 503 Service Unavailable
• 504 Server Timeout
6.3.3.7 The Service Route header (RFC 3608)
6.3.3.7.1 Service description

    

 !"  
  293/915
Chapter 6 

When an external gateway registers, the Supported header of the REGISTER message
includes the path header in the list of the supported headers.
The 200.OK response sent by the remote proxy may contain a Service Route header
containing a list of URLs. As of R10.0, the OmniPCX Enterprise stores the list of URLs
received.
The list of URLs stored for an external gateway is used for outbound calls: each INVITE or
OPTIONS method includes one Route header for each URL stored, as illustrated: figure:
Example of Exchange with Service Route Header .
Note 1:
The outbound proxy URL configured for an external gateway is included as first Route header in INVITE
and OPTIONS methods, whether it is present in the Service Route header received from the remote
proxy or not.

Figure 6.120: Example of Exchange with Service Route Header

Note 2:
When an external gateway registers to the OmniPCX Enterprise, the 200.OK response sent by the
OmniPCX Enterprise does not include any Service Route header.

6.3.3.7.2 URL’s list storage

- The OmniPCX Enterprise can store up to 32 lists of URLs.
- Each list can contain up to five URLs: if more than five URL’s are received in the Service
Route header, only the first five ones are stored.
- When the registration of an external gateway fails, or if no Service Route is received in the
response, the URLs stored previously are erased.

294/915     


 !"  
 
 

- The killall sipmotor command erases all the lists of URLs.

- The sipextgw tool shows the list of URL’s associated to each gateway.
6.3.3.8 Numbering
6.3.3.8.1 Canonical form
The canonical address format is a universal phone number. This format explicitly identifies the
components of a phone number and can be translated according to the country dialing rules.
The canonical address format is: +CountryCode AreaCode SubscriberNumber.
SIP trunking allows translation between SIP URLs in canonical form and OmniPCX Enterprise
phone number forms.
SIP trunking allows translation between URLs used by SIP devices ( FROM and TO headers)
and phone calling and called numbers used by the OmniPCX Enterprise call handling feature.
6.3.3.8.2 Outgoing calls
Two kinds of numbering plan can be used for outgoing calls from a SIP external gateway:
- Routing prefix
- ARS
Caution:
- Routing prefix can only be used with an ABC-F SIP trunk group. In this case, an open
numbering plan can not be used (Rank of First Digit to be sent = 1)
- ARS can be used with both ABC-F and ISDN trunk groups

Note:
When ARS is used with either ABC-F SIP or ISDN SIP trunk groups, it is mandatory to use the [I]nsert
command in the DCT of the ARS.
Barring can be applied to outgoing calls on a SIP trunk group
To insure the translation of telephone numbers into URL in canonical form, ARS and the
Numbering Plan Descriptor associated to the SIP trunk group must be configured
consequently. For more information on constructing FROM and TO headers, see User parts of
SIP URLs .
User parts of SIP URLs
A SIP URL user part can be either:
- a name: sip:alice@sip.mycompany.com, or
- a number: sip:5000@192.168.5.10.
The number can be in a form of a canonical address format: for example,
sip:+33155664000@sip.mycompany.com.
Note:
FROM headers are mandatory in SIP messages. If there is no calling number in the setup message, the
user part of the FROM header will be filled with the name of the trunk group.
The two tables below list different syntaxes of the FROM and TO headers that correspond to:
- the Type Of Number (TON)/Numbering Plan Identification (NPI) of the ISDN SETUP

    

 !"  
  295/915
Chapter 6 

message received by the Call Handling,

- the system Country Code.
NPI TON Calling number Construction of FROM header
36200 "36200"<sip:36200@LD> (1) (*)
X Unknown 36200 "NOM PRENOM"<sip:urlname@LD> (1) (*)
155636200 "155636200"<155636200@LD> (*)
ISDN National 155636200 "155636200"<sip: +33 155636200@LD> (2)
(*)
ISDN Internat 33155636200 "33155667000"<sip: + 33155636200@LD> (*)

(*): LD is Local Domain.

NPI TON Called number Construction of TO header
X Unknown 36105 sip:36105@RD (*)
ISDN National 155636105 <sip: +33 155636105@RD> (2) (*)
ISDN Internat 33155636105 <sip: + 33155636105@RD> (*)

(*): RD is Remote Domain.

Domain parts of SIP URLs
The domain part of the FROM header of an INVITE method is built based on the field
Belonging domain of the relative SIP external gateway.
The domain part of the TO header of an INVITE method is built based on the field Remote
domain of the relative SIP external gateway.
6.3.3.8.3 Incoming calls
An incoming call from a SIP operator is identified by the domain part of the P-Asserted-ID,
FROM or Via header of the INVITE method.
For more information on domain parts in SIP URLs, refer to Domain parts of SIP URLs .
An external gateway can only handle one type of URL for the "Request URI" header. For
example it is not possible to handle a URL in canonical form and a URL in a private form on
the same gateway.
If URLs in canonical form are used, the External Callback translator must be configured to
translate URL in canonical form into international type numbers. For more information, refer to
User parts of SIP URLs .
User parts of SIP URLs
A SIP URL user part can be either:
- a name: sip:alice@sip.mycompany.com, or
- a number: sip:5000@192.168.5.10.
The number can be in a form of a canonical address format: for example,
sip:+33155664000@sip.mycompany.com.
The two tables below list different syntaxes of the CALLING and CALLED data that correspond
to the value of the FROM and TO headers of the ABC-F SETUP message of the ISDN SETUP

296/915     


 !"  
 
 

message received by the Call Handling.

SIP received FROM header Construction NPI TON External Call-
URI of calling back Translat-
number or
Generic surname.name@RD (*) 4000 ISDN Unknown DEF
Number
Country code ISDN Nation DEF
= system
Country Code :
Canonical 155636200
+33155636200@RD (*)
Form Country code ISDN Internat A
<> system
Country Code :
33155636200
Local Num- 36200@RD (1) (*) 36200 ISDN Unknown DEF
ber

(*): RD is Remote Domain.

TO header Construction of called NPI TON
number
surname.name@LD (*) 5000 Unknown Unknown
+33155636105@LD (*) 33155636105 ISDN Internat
36105@LD (*) 36105 Unknown Unknown

(*): LD is Local Domain.

Domain parts of SIP URLs
The domain part of the FROM header of an INVITE method is built from the field Remote
domain of the relative SIP external gateway.
The domain part of the TO header of an INVITE method is built from the field Belonging
domain of the relative SIP external gateway.
Call presentation
Up to R9.1, the following mechanism applies for call presentation:
- If The P-Asserted-ID header is present, it is used to provide the Calling Number
- If the P-Asserted-ID header is not present, the From header is used to provide the Calling
Number
This mechanism does not cope with all situations because all carriers do not use the headers
in the same way. For example, some carriers give the user number in the From header and
the installation number in the P-Asserted-ID header. This means, that in some cases, the From
header should be used to provide the calling number even if the P-Asserted-ID header is
present. As of R10.0, three parameters allow to manage the way the headers are used for
calling presentation.
The three parameters, configured for each external gateway, are:
- P-Asserted-ID in Calling Number

    

 !"  
  297/915
Chapter 6 

- Trusted P-Asserted-ID header

- Trusted From header
The following mechanism applies for call presentation:
- The P-Asserted-ID header is present:
• P-Asserted-ID in Calling Number = True and Trusted P-Asserted-ID header = True
The P-Asserted-ID header is used to provide the Calling Number. The Calling Number
is considered as provided by carrier network and is trusted.
• P-Asserted-ID in Calling Number = True and Trusted P-Asserted-ID header =
False
The P-Asserted-ID header is used to provide the Calling Number. The Calling Number,
is not considered as provided by carrier (may be provided by remote user) and then
not trusted.
• P-Asserted-ID in Calling Number = False and Trusted P-Asserted-ID header =
True
The From header is used to provide the Calling Number. If the User part of
P-Asserted-ID and From are identical, the Calling Number is considered as network
provided and then is trusted. Otherwise, the Calling Number is not trusted.
• P-Asserted-ID in Calling Number = False and Trusted P-Asserted-ID header =
False
The From header is used to provide the Calling Number. The Calling Number is
considered as not trusted
- No P-Asserted-ID header is present:
• Trusted From header = False
The From header is used to provide the Calling Number. The Calling Number is
considered as not trusted.
• Trusted From header = True
The From header is used to provide the Calling Number. The Calling Number is
considered as trusted.
Note 1:
In that case, the content of From Header is considered as provided by remote user but verified
by carrier network.
Note 2:
When no P-Asserted-ID header is present, the P-Asserted-ID in Calling Number and Trusted
P-Asserted-ID header parameters are not used.

Note 3:
When Calling Number is not trusted, automatic substitution mechanism (remote extension, DISA…) can
not be activated.

6.3.3.8.4 Tel URI

Overview
As of R11.0, the OmniPCX Enterprise supports headers containing the identifier: Tel URI.
Example of Tel URI:
tel: +12015555000

298/915     


 !"  
 
 

tel : 4000;phone-context=carrier;com
Note:
Separators such as "-", ".", "("or ")" are optional
Tel URI is used by some operators and comply with the RFC 3986 standard.
A Tel URI does not include a domain name. SIP URI and Tel URI are not processed
identically.
Called identity
When an INVITE method is received with a Request URI header containing Tel URI, the
system tries to identify the destination domain with the Route header. When the Route header
is not present, the called number is retrieved from the Request header (Tel URI) and the type
of number is set to international.
Calling identity
To identify the calling party, P-Asserted-ID, Via and From headers are used. P-Asserted-ID
and From headers can contain Tel URI. In addition, system parameters can be used.
The following diagram shows how the calling identity is defined:

    

 !"  
  299/915
Chapter 6 

Figure 6.121: Calling party identification

Note:
From and Via headers are always present in an INVITE method. The Via header always contains a SIP
URI.
When the calling party is identified from a Tel URI, the calling number is retrieved from Tel URI
and the Type of number is set to international.
Anonymous calls
When the Privacy header is present, the incoming call is processed as an anonymous call.
200.OK response
The P-Asserted-ID header of the 200.OK response contains the identity of the connected
party. This header can contain Tel URI.
The connected number is retrieved from Tel URI and the Type of number is set to
international.
Redirection
The OmniPCX Enterprise can forward a call from a SIP gateway to an other SIP gateway.
Calling identity headers, such as P-Asserted-ID or From headers of outgoing methods always
contain SIP URI.
When calling identity headers of the incoming call contain Tel URI, the local OmniPCX
Enterprise builds SIP URI from incoming Tel URI and gateway configuration parameters.
Restrictions
- The OmniPCX Enterprise supports Tel URI only for INVITE inbound request and 200.OK
responses.
- The OmniPCX Enterprise never provides Tel URI in outbound INVITE nor in REGISTER
nor in OPTIONS
- Tel URI can be received only in methods coming from SIP ISDN.
- The following optional parameters defined in the RFC 3966 are not taken into account:
• isub
• ext
• phone-context
6.3.3.9 Incoming call routing
To route an incoming call, the OmniPCX Enterprise must determine:
- The destination of the call (see: Destination of the incoming call )
- The origin of the call (see: Origin of the incoming call )
6.3.3.9.1 Destination of the incoming call
On incoming calls, the OmniPCX Enterprise verifies the inbound request (that is the INVITE
method). The PCX determines that it is the destination of the incoming call when one of the
following condition applies:

300/915     


 !"  
 
 

- The Route header is present in the INVITE method, and its domain part matches either
the IP address, the Machine name, or the concatenation of the fields Machine name and
DNS local domain name of the main SIP gateway and its user part matches the
Registration Id parameter of an external gateway (see: SIP Trunking - Configuration
procedure - Configuring an External Gateway ).
Note 1:
When this occurs, the data of the Route header is used for call routing through the "loose route"
mechanism defined by RFC 3261. As of R10.1, when the Loose route with RegID system
parameter is disabled, the user part of the Route header is not required for call routing (see: SIP
Trunking - Configuration procedure - Configuring system parameters ).
- There is not any Route header, and the domain part of the "Request URI" header of the
INVITE method contains:
• The OmniPCX Enterprise IP address, or
• The OmniPCX Enterprise Machine name, or
• The concatenation of the fields Machine name and DNS local domain name of the
main SIP gateway
When one of the conditions above applies, the OmniPCX Enterprise determines the origin of
the incoming call before its routing to the Call Handling application (see: Origin of the incoming
call ).
Note 2:
If the domain part of the "Request URI" header does not correspond to that of the OmniPCX Enterprise,
the call is routed to the destination indicated in the INVITE method.
As of R11.2, when the proxy of the SIP carriers use the "Request URI" to indicate the
destination number, some others use a different header of the INVITE, while the "Request
URI" itself may for instance indicate the IP-PBX “installation number”, i.e. the global number
used for registration procedure, but not, in any case, the real destination user number. This is
determined by the DDI destination number system parameter (see: SIP Trunking -
Configuration procedure - Configuring an External Gateway ).
6.3.3.9.2 Origin of the incoming call
As of R10.1, the process to determine the origin of the incoming call depends on the value of
the Proxy identification on IP address parameter, configured in the SIP external gateway:
- If the Proxy identification on IP address parameter is set to True, the origin of the call is
determined by a search performed among all external gateways configured with the Proxy
identification on IP address parameter set to True.
For each external gateway, the PCX retrieves the source IP address of the inbound
request sender (outbound proxy or remote domain).
The PCX compares the source IP address with the IP addresses registered in its DNS
cache (see: DNS cache ). If the source IP address matches one of the IP addresses of
DNS cache, the incoming call is identified as originating from this external gateway and
routed to the corresponding trunk group.
- If the Proxy identification on IP address parameter is set to False, the incoming call is
identified as originating from an external gateway and routed to the corresponding trunk
group when one of the following conditions applies:
• The P-Asserted-ID header is present, and its domain part matches the RemoteDomain
of a given external gateway.
• There is not any P-Asserted-ID header, and the domain part of the From header

    

 !"  
  301/915
Chapter 6 

matches the RemoteDomain of a given external gateway.

• If the Via Header_ Inbound Calls Routing option is enabled (see SIP Trunking -
Configuration procedure - Configuring system parameters ): one or several Via header
are available, and the domain part of one of the URL’s matches the RemoteDomain of
a given external gateway.
If the call is not identified as originating from an external gateway, the call is routed to the main
IP trunk group. As of R10.1, when the origin of the call cannot be determined, the call is either
routed to the main IP trunk group or rejected with the SIP error response: 403 forbidden.
The choice of call routing is defined by the Reject unidentified proxy calls system parameter
(see: SIP Trunking - Configuration procedure - Configuring system parameters ).
When several external gateways refer to the same remote domain, the origin of the call is
determined by a search performed among all external gateways. The first external gateway
whose call data can be processed by the OmniPCX Enterprise is used. As of R10.1, the
Outbound calls only parameter value, configured in the external gateway enables to exclude
an external gateway from the search to identify the origin of the incoming call. In this case, this
external gateway can only handle outgoing calls.
As of R11.2, when the Proxy identification on IP address parameter is set to true, it is
required to manage either registration (REGISTER) or supervision (OPTIONS), in order to
periodically update the associated DNS cache, and so receive initial incoming call prior to any
outgoing call. This is determined by the OPTIONS required system parameter (see: SIP
Trunking - Configuration procedure - Configuring an External Gateway ).
However, it might be required to use this feature without REGISTER or OPTIONS, when a
carrier does not want to wish information or does need to manage them. In this case, the DNS
cache must be periodically updated, without sending any SIP request.
6.3.3.10 CLIP/CLIR
Calling Line Presentation (CLIP) is available on SIP trunk groups. Conversions between URL
and telephone number are performed as indicated in Outgoing calls .
Calling Line Restriction (CLIR) is also handled by SIP trunk groups. 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 on the example below.
Example:
SETUP
Called # : 147858000 TON = Nat
Calling # : 33155669001 TON = Int (Octet 3) Presentation Restricted (Octet
3a)

generates the following INVITE message towards the SIP carrier

INVITE sip:+33147858000@RemoteDomain SIP/2.0

To : <sip:+33147858000@RemoteDomain>
From : <sip:anonymous@anonymous.invalid>
Route : <sip:sipcarrier@there.com>
P_Asserted_Identity : <sip:+33155669001@LocalDomain>
Privacy : user

302/915     


 !"  
 
 

For an incoming call, the reverse mechanism applies.

6.3.3.11 COLP/COLR and CONP/CONR
The Connected Line Presentation (COLP) and the Connected Name Presentation (CONP)
services allow to transmit the number or the name (if available) of the connected party.
- For an incoming call, the OmniPCX Enterprise answers with:.
• A 180.Ringing provisional message. This message includes a P-Asserted -ID header
which contains the number and the name of the ringing party
• A 200 (OK) message, including a P-Asserted-ID header. This header contains the
number and the name of the connected party
- For an outgoing calls, the OmniPCX Enterprise scans:
• A 180.Ringing provisional message. If this message contains a P-Asserted-ID
header, the number or the name contained in this header is the ringing party
identification. Only the name is taken into account and transmitted to the calling party
for display.
• A 200 (OK) message, If this message contains a P-Asserted-ID header, the number
or the name contained in this header is the connected party identification. Only the
name is taken into account and transmitted to the calling party for display.
If this message does not contain a P-Asserted-ID header, the OmniPCX Enterprise
transmits the called number as connected number.
The Connected Line Restriction (COLR) and the Connected Name Restriction (CONR)
services allows to mask the number or the name of the connected party.
- For an incoming call, the OmniPCX Enterprise answers with a 200 (OK) message
including a Privacy header. This header contains the string "user".
- For an outgoing calls, the OmniPCX Enterprise scans the received 200 (OK) message. If
this message contains a Privacy header containing a value other than none, the call is
considered as an anonymous call. Neither a number nor a name are transmitted to the
calling party.
Note:
- COLP/COLR services and CONP and CONR services are available for SIP ABC-F
- COLP/COLR services are available for SIP ISDN
- As of R11.0.1, CONP and CONR services are available for SIP ISDN
6.3.3.12 Call transfer and redirection
6.3.3.12.1 Transfer initiated by a user
On the OmniPCX Enterprise, a user who holds two calls simultaneously (broker call or three
party conference) can initiate a call transfer. These two calls can be external calls, set up on
SIP ISDN.
- Before R11.0.1, to perform a transfer, the OmniPCX Enterprise uses a re-INVITE message
for capacity renegotiation. After renegotiation, the OmniPCX Enterprise performs
signalization transfer.
- As of R11.0.1, to perform a transfer, the OmniPCX Enterprise uses (when possible) a
REFER message and transfer is performed directly by the carrier. The REFER message
includes the Refer-To header containing the destination of the transfer.

    

 !"  
  303/915
Chapter 6 

At the end of the transfer procedure (on receipt of NOTIFY/180 Ringing or NOTIFY/ 200
Ok) , the OmniPCX Enterprise releases the two calls.

Figure 6.122: Messages exchanged during a transfer

Restrictions:
• Anonymous call: when the SIP leg A-Y has been established from an anonymous
calling party, the REFER message cannot be used. The OmniPCX Enterprise
processes transfers using re-INVITE messages as performed before R11.0.1.
• The carrier must support RFC3615 and RFC 3892. The OmniPCX Enterprise is
notified of carrier capacity with the parameter Attendant Transfer (RFC3615 & RFC
3892) of the external gateway (see configuration: SIP Trunking - Configuration
procedure - Configuring an External Gateway ).
When the carrier does not support these standards, the OmniPCX Enterprise
processes transfers using re-INVITE messages as performed before R11.0.1.
• When the two SIP legs belong to two different carriers or different external gateways
then REFER messages are not used. Transfers are proceeded using re-INVITE
messages as performed before R11.0.1
REFER request failure:
- When the REFER request fails, the OmniPCX Enterprise processes transfers using
re-INVITE messages as performed before R11.0.1.

304/915     


 !"  
 
 

- When there is no response to the REFER request, calls are released.

At the end of a REFER procedure, a BYE message is sent to release transferred calls.
- Before R11.1, the OmniPCX Enterprise always sends the BYE message
- As of R11.1, according to the SIP external gateway parameter Send BYE on REFER, the
OmniPCX Enterprise or the SIP carrier sends the BYE message.
When the parameter is set to TRUE, OmniPCX Enterprise sends a BYE messageto carrier
immediately after NOTIFY successful response. When the parameter is set to FALSE, a
timer is launched which monitors arrival of a BYE message from external.
6.3.3.12.2 Transfer initiated by RSI
The RSI (routing Service Interface) application can initiate a transfer to redirect an incoming
call:
- Before R11.0.1, the OmniPCX Enterprise sets up a new call with a INVITE message to the
destination of the transfer. After this second call establishment, the OmniPCX Enterprise
holds two calls and is in charge of the signaling of these two calls.
- As of R11.0.1, the OmniPCX Enterprise sends a REFER request and the carrier performs
the transfer. The REFER message includes the Refer-To header containing the destination
of the transfer.
After transfer establishment (on receipt of a 180 Ringing message or a 200 OK message),
the OmniPCX Enterprise releases the initial call.

    

 !"  
  305/915
Chapter 6 

Figure 6.123: Messages exchanged during a transfer initiated by RSI

The transfer with REFER is possible when:
• The call to transfer is set up on SIP ISDN (not allowed on an ABC-F network)
• The SIP access and the RSI are located on the same node
• The proxy supports transfers with the REFER message. The OmniPCX Enterprise is
notified of the proxy capacity with the parameter Unattended Transfer for RSI of the

306/915     


 !"  
 
 

external gateway (see configuration: SIP Trunking - Configuration procedure -

Configuring an External Gateway ).
• The proxy supports a numeric format for transfer destination. Canonical formats, such
as +33155665555, are never transmitted.
• The second call must be an external public number
• The corresponding RSI parameter Route select relay is set to Yes (see: SIP Trunking
- Configuration procedure - Configuring the RSI application ).
REFER request failure:
• When the REFER request fails, the OmniPCX Enterprise processes transfers using
re-INVITE messages as performed before R11.0.1.
• When there is not answer to the REFER message, transfer fails.
6.3.3.12.3 Incoming call redirection
The call redirection function optimizes call routing on ABC-F networks.
In the example below; the OmniPCX Enterprise network includes three nodes and only one
URI domain (for example: oxe.com).
All incoming calls for this oxe.com domain are routed via the SBC to node N1.

Figure 6.124: Routing of an incoming call with and without redirection

For calls to a called party located on node N3:
- Before R11.0.1, calls received on node N1 are transmitted, via the ABC-F network, to the
destination node. ABC-F links are unnecessarily loaded (see: figure: Routing of an
incoming call with and without redirection )
- As of R11.0.1, the call can be redirected to the appropriate node by the SBC.

    

 !"  
  307/915
Chapter 6 

N1 receives the INVITE message and returns a 301. Move Permanently response. This
message includes a Contact header containing the destination node of the called user.
The SBC reroutes the call (see: figure: Routing of an incoming call with and without
redirection ).

Figure 6.125: Messages exchanged for a call redirection

Restrictions:
- The SBC must be able to resolve the domain part of URI of the Contact header
(oxe_node_3 in our example).
In the SBC, each OmniPCX Enterprise node must be named: oxe_node_x/xx where x/xx
represents the node number (one or two digits). For example, when node number is 3, the
contact field is oxe_node_3. When node number is 40, the contact field is oxe_node_40.
- A redirection is only available on a SIP ISDN trunk group, and when the parameter
Redirection functionality for SIP ISDN of the external gateway is set to True (see: SIP
Trunking - Configuration procedure - Configuring an External Gateway ).
- Redirection is not available for forwarding and call pick up. For example; the called user is
connected to node N1 but this user is forwarded to another node. An incoming call for this
user is not redirected but routed via the ABC-F network.
6.3.3.13 Call in transit
Before R11.0.1, in a configuration with several PCX connected by SIP ABC trunk groups, calls
cannot transit via the OmniPCX Enterprise for routing reasons.
As of R11.0.1, in a configuration with several PCX connected by SIP ABC trunk groups, calls
can transit via the OmniPCX Enterprise.

308/915     


 !"  
 
 

Figure 6.126: Example of configurations supporting calls in transit

These calls can be proceeded by the OmniPCX Enterprise in two ways:
- Simplified process: the OmniPCX Enterprise, acting as a proxy server, reroutes calls
without any control.
Only the internal process, called the SIP motor is activated.
This process avoids an unnecessary load for the OmniPCX Enterprise.
- Complete process: the OmniPCX Enterprise proceeds SIP calls in transit as all other calls.
Internal processes such as Call Handling and SIP motor are activated. All call functions
such as accounting, CAC (Call Admission Control) and barring are activated.
The system parameter Private SIP transit mode defines the routing behaviour of the
OmniPCX Enterprise :
- Proxy or redirect mode: all calls are proceeded according to the simplified process
described above
- Full Call Handling mode: all calls are proceeded according to the complete process
described above
- Mixed mode: calls between OpenTouch and OmniPCX Office and calls between
OmniPCX Office and OmniPCX Office are proceeded according to the complete process.
Other SIP calls are proceeded according to the simplified process.
For Private SIP transit mode system parameter configuration, see: . SIP Trunking -
Configuration procedure - Configuring system parameters .
6.3.3.14 Media negotiation
Media negotiation can take place at call setup or during an active session as explained: SIP -
Overview - Media Negotiation.

    

 !"  
  309/915
Chapter 6 

Note:
The value of the SDP in 180 and RFC3262 Forced Use parameters have an impact on the behavior of
the PCX for media negotiation. For more information on the configuration of these parameters, see: SIP
Trunking - Configuration procedure - Configuring an External Gateway .

6.3.3.14.1 Negotiation with the INVITE and RE-INVITE messages

INVITE and RE-INVITE messages received by the PCX
Before R8.0.1, the OmniPCX Enterprise only accepts INVITE (or RE-INVITE) messages with
an SDP part. INVITE (or RE-INVITE) messages without SDP are rejected and the call is
released.
As of R8.0.1, the OmniPCX Enterprise complies with RFC3725, Flow I and accepts INVITE (or
RE-INVITE) messages without SDP.
The different cases of negotiation are as follows:
First Case
1. The OmniPCX Enterprise receives an INVITE (or RE-INVITE) message with a list of
algorithms in the SDP part.
2. The OmniPCX Enterprise answers with one algorithm in the SDP part of the 200.OK
response.
Second Case
1. The OmniPCX Enterprise receives an INVITE (or RE-INVITE) message without SDP.
2. The OmniPCX Enterprise answers with a list of algorithms in the SDP part of the 200.OK
response.
Note:
The OmniPCX Enterprise always sends INVITE messages with an SDP part.

INVITE messages sent by the PCX

If no answer is received before the expiration of the watchdog timer, INVITE messages are
retransmitted.
The table below gives timer values according to the retransmission number.
table 6.72: Expiration Timer Value Relating to the Number of Retransmissions
Number of Retransmissions Watchdog Timer Value
1 1s
2 2s
3 4 s (default value)
4 8s
5 16 s
6 32 s
n 2(n-1) s

RE-INVITE messages sent by the PCX

310/915     


 !"  
 
 

When a call transfer is initiated from the OmniPCX Enterprise, the OmniPCX Enterprise sends
a RE-INVITE message with SDP, to the SIP carrier. The OmniPCX Enterprise provides the
coding algorithm in the SDP part of the RE-INVITE message.
As of R10.1, the OmniPCX Enterprise can send the RE-INVITE message without SDP. This
depends on the value of the Support Re-Invite without SDP parameter, configured in the SIP
external gateway:
- If the Support Re-Invite without SDP parameter is set to False, the PCX provides the
coding algorithm in the SDP part, when it sends a RE-INVITE message to the SIP carrier.
Example 1:
A user declared in the OmniPCX Enterprise is in conversation with two external SIP users (X and Y).
This user initiates a call transfer.

Figure 6.127: RE-INVITE message with SDP

In this scenario, the SDP of each party does not change in the 200 OK response. If it ichanges,
compressors are taken on OmniPCX Enterprise and a new negotiation is performed from the PCX
towards both sides.
- If the Support Re-Invite without SDP parameter is set to True, the PCX can send a
RE-INVITE message without SDP to the SIP carrier. This option must be selected when
the SIP carrier supports RE-INVITE messages without SDP. In this case, the SIP carrier is
in charge of providing an SDP offer.

    

 !"  
  311/915
Chapter 6 

Example 2:
A user declared in the OmniPCX Enterprise is in conversation with tho external SIP users (X and Y).
This user initiates a call transfer.

Figure 6.128: RE-INVITE message without SDP

In R10.1, RE-INVITE message without SDP (see figure above) is used only when the
OmniPCX Enterprise transfers the call between two external SIP users.
As of R11.0, when the G722 for SIP trunking parameter is set to TRUE, RE-INVITE
message without SDP is used for transferring the call between one external SIP user
and any other user on the same node or within the network.
As of R11.0, when the Enhanced codec negotiation parameter is set to Local Type or
Network Type, RE-INVITE without SDP is used for transferring the call between one
external SIP user and any other user on the same node or in the network. For more
information, see: Codec negotiation
6.3.3.14.2 Negotiation with the UPDATE message
As of R9.1, the OmniPCX Enterprise complies with the RFC3311 standard. It supports
UPDATE messages.
With an UPDATE message, a user agent can modify the media offer during the session
initialization dialog. This feature is used for example when a call is transferred at ringing.
The following sections show different scenarios of media change with UPDATE method,
initiated by the external gateway or the PCX.
Media change initiated by the external gateway

312/915     


 !"  
 
 

Figure 6.129: Example of Offer Modification with an UPDATE Message

In the example above:
- A set connected to the OmniPCX Enterprise initiates the call (an INVITE message is sent
to the SIP remote device set 1)
- The called party (set 1) rings and sends back the 18x Answer1 message
- Set 1 (the called set) transfers the call to set 2 without answering the call
- Set 2 initiates a new media negotiation with its own media parameters (Offer2 in the
UPDATE message)
- The calling party answers with a 200 ok message
- The dialogs ends as usual
For this scenario, the SDP in 180 parameter must be set to True to convey UPDATE message
authorization in a 18x message.
Media change initiated by the PCX
Outgoing call from the PCX
The PCX makes an outgoing call through SIP: it sends an INVITE message with offer1 to the
external gateway with UPDATE method in the allow header field and receives 18x response
from the external gateway.
The PCX behavior depends on the 18X response received:
- The 18X response contains 100rel parameter in the required header: the PCX sends
PRACK method with/without SDP depending on the media change requirement: see
Negotiation with the PRACK message .

    

 !"  
  313/915
Chapter 6 

- The 18X response does not contain 100rel parameter in the required header: two cases
are possible:
• The 18X response contains an UPDATE method in the allow header: if a media
change is needed, the PCX sends an UPDATE method: figure: Media Change with
UPDATE Method Initiated by the PCX shows the SIP call flow in this case.

Figure 6.130: Media Change with UPDATE Method Initiated by the PCX
• The 18X response does not contain an UPDATE method in the allow header: the PCX
will not send any UPDATE to the external gateway. If a media change is needed, the
PCX will send a RE-INVITE method once the call is answered.
Incoming call to the PCX
When the PCX receives an INVITE message with/without SDP from an external gateway the
following cases are possible:
- The INVITE message contains an UPDATE method in the allow header:
• If the INVITE message contains an SDP offer, the PCX behavior depends on the SDP
in 18x parameter value:
• If the SDP in 18x parameter is set to False, the PCX does not send UPDATE
message to the external gateway. It sends the answer1 in the final response.
• If the SDP in 18x parameter is set to True, the PCX will send an UPDATE method
if a media change is needed: figure: Media Change with UPDATE Method Initiated
by the PCX shows the SIP call flow in this case.

314/915     


 !"  
 
 

Figure 6.131: Media Change with UPDATE Method Initiated by the PCX
• If the INVITE message contains no SDP offer, the PCX behavior depends on the 18x
informational message sent by the PCX:
• If 18x informational messages are not sent reliably, the PCX will not send UPDATE
message to external gateway.
• If 18x informational message are sent reliably, the PCX will send an UPDATE
method if a media change is needed.
- The INVITE message does not contain an UPDATE method in the allow header: the PCX
will not send any UPDATE to the external gateway.
6.3.3.14.3 Negotiation with the PRACK message
As of R9.1, the OmniPCX Enterprise complies with the RFC3262 standard. It supports PRACK
(PRovisional ACKnowledge) messages which include an SDP element. This element can be
used to convey a new offer.
This feature is useful to connect the OmniPCX Enterprise to specific gateways.
Outgoing call until R9.0
When the PCX makes an outgoing call through SIP, it sends an INVITE message with offer1 to
the external gateway, with 100rel parameter in the require header if the RFC3262 Forced Use
parameter is set to True.
If the 18X response contains 100rel parameter in the required header, the PCX will use the
PRACK method with SDP if a media change is needed.
Incoming call until R9.0
The PCX receives an INVITE message with 100rel parameter in the required header.
- If the INVITE message contains no SDP answer, the PCX sends 18x informational
response with offer1 irrespective of the SDP in 180 parameter value. Then external

    

 !"  
  315/915
Chapter 6 

gateway sends PRACK message with answer1. As an acknowledgement, the PCX sends
200 OK for PRACK message without SDP. Then the PCX sends 200 OK for INVITE
message without SDP: figure: INVITE Received Without SDP shows the SIP call flow in
this case.

Figure 6.132: INVITE Received Without SDP

- If the INVITE message contains an SDP answer, the PCX behavior depends on the SDP
in 180 parameter value:
• If the SDP in 18x is set to False, the PCX sends 18X informational response to
external gateway without SDP.
• If the SDP in 18x parameter is set to True, the PCX sends 18X informational response
to external gateway with SDP (answer1). If a media change is needed, the external
gateway sends a PRACK message allowing to change media parameters (Offer 2).
The PCX sends an acknowledgement, 200 ok message with Answer 2: figure:
Example of Media Negotiation with a PRACK Message shows the SIP call flow in this
case.

316/915     


 !"  
 
 

Figure 6.133: Example of Media Negotiation with a PRACK Message

Outgoing call as of R9.1

When the OmniPCX Enterprise makes an outgoing call through SIP, it sends an INVITE
message with offer1 to the external gateway. This message can include a 100rel parameter in
the Require header or in the Supported header according to the Outbound Calls 100 REL
parameter.
The selected option must match the external gateway configuration.
Incoming call as of R9.1
When the OmniPCX Enterprise receives an incoming call through SIP, it answers with an 18x
informational response. This message can include a 100Rel parameter according the received
message and the OmniPCX Enterprise configuration.
- When the received INVITE message indicates a 100Rel parameter in the Require header,
the 18x response includes a 100Rel in the Require header, irrespective of configuration.
- When the received INVITE message does not indicate a 100Rel parameter in either the
Require header or in the Supported header, the 18x response does not include a 100Rel
parameter in the Require header, irrespective of configuration.
- When the received INVITE message does not include a 100Rel parameter in the Require
header and includes a 100Rel parameter in the Supported header, the Incoming Calls
100 REL parameter is taken into account:
• Not requested: the 18x response does not include a 100Rel parameter in the Require
header
• Required Mode 1: the 18x response includes a 100Rel parameter in the Require
header only when the 18x message has provided an SDP. When this not the case, no
100Rel parameter is included in the Require header.
• Required Mode 2: the 18x response includes a 100Rel parameter in the Require
header

    

 !"  
  317/915
Chapter 6 

6.3.3.14.4 Codec negotiation

Overview
On the OmniPCX Enterprise, the following audio codecs are available:
- G711 for non compressed calls. Calls, with this codec, require a bandwidth of 64 Kbits/s
There are two kinds of G711 codecs: one works in A law and the other in µ law.
- G729 for compressed calls. Calls, with this codec, require a bandwidth of 8 Kbits/s
- G722 (as of R11.0) for high quality calls. Calls, with this compressed codec, require a
bandwidth of 64 kbits/s, 56 kbits/s or 48 kbits/s
The G722 codec is available only when the G722 for SIP trunking system option is set to
TRUE.
Note 1:
G722.1, G722.2 and G723 codecs are not available for the OmniPCX Enterprise.
According to the link type, all codecs may not be supported:

Figure 6.134: OmniPCX Enterprise supported links

318/915     


 !"  
 
 

Link Available codecs

OmniPCX Enterprise - IP Phone G711, G722 (if supported by the set) and
G729
Note 2:
SIP sets do not support G722.
SIP -ISDN trunk group G711, G722 and G729
SIP -ABCF trunk group G711, G722 and G729
ABCF link G711 and G729
(network of OmniPCX Enterprise)

Note 3:
GD-3, GA-3 and INT-IP3 boards do not support G722. TDM sets connected to a media gateway never
establish call with the G722 compression algorithm.

Codec negotiation between IP phones and SIP-ISDN

Outgoing call

Figure 6.135: Example of codec negotiation for an outgoing call

Codecs selected in the OmniPCX Enterprise offer depends on the ability of the calling set, its
domain and the Type of codec negotiation parameter of the SIP gateway.
The table below details the OmniPCX Enterprise offer according to these parameters:
table 6.74: Codec offer for outgoing calls
IP phone and do- Type of codec negotiation
main ability (parameter of the SIP ISDN outgoing gateway)
Default From domain Single Codec Single Codec
G711 G729

    

 !"  
  319/915
Chapter 6 

G722 supported G722/G711 G722/G711 G722/G711 G729

and /G729 /G729
IP domain not re-
stricted
G722 not suppor- G711/G729 G711/G729 G711 G729
ted and
IP domain not re-
stricted
G722 not suppor- G729/G711 G729 G711 G729
ted and (Configuration er-
IP domain re- ror)
stricted

Incoming call

Figure 6.136: Example of codec negotiation for an incoming call

For incoming calls, the OmniPCX Enterprise selects the preferred codec. The preferred codec
depends on the called phone capability (G722 compatibility) and the IP domain of the called
phone (restricted or not).
The table below details codec selection conditions, when the incoming offer includes G722,
G711 and G729:
IP phone and domain ability Preferred codec
G722 supported and G722
IP domain not restricted
G722 not supported and G729
IP domain restricted
G722 not supported and G711
IP domain not restricted

320/915     


 !"  
 
 

G722 supported and G729

IP domain restricted

Codec negotiation for calls in transit from SIP–ABCF to SIP-ISDN

The codec offer, sent to the SIP-ISDN trunk group, depends on the incoming call offer, the
domain of the incoming SIP ABCF trunk group and the Type of codec nego parameter of the
SIP ISDN outgoing gateway.
When the incoming offer is not compatible with the outgoing SIP gateway, the call is released.
The table below details the new offer:
Incoming offer Type of codec negotiation parameter of the SIP ISDN outgo-
ing gateway
Default From domain Single codec Single codec
G711 G729
G722/G729/G711/G723 G722/G711 G722/G711 G722/G711 G729
From a non restricted do- /G729 /G729
main
G722/G729/G711/G723 G729/G711 G729 G711 G729
From a restricted domain
G722 Release call Release call Release call Release call
G711 G711 G711 G711 Release call
G729 G729 G729 Release call G729
G723 Release call Release call Release call Release call

Codec negotiation in case of external call forwarding

A call can be forwarded, by the OmniPCX Enterprise, from carrier X to carrier Y. The codec
offer from carrier X is transferred transparently to carrier Y. Codec selection is also transferred
transparently.
Note:
This behavior is true only when carrier X and carrier Y are connected to the same OmniPCX Enterprise
node.

Voice mail
In case of recording of a communication established in G722, the call fallbacks to G711 during
recording. After recording, the call switches back to G722.
G711 codec specificities
There are two kinds of G711 codecs: one works in A law (called G711A) and the other in µ law
(called G711MU or G711µ).
The OmniPCX Enterprise can work in A law or µ law, according to the Law system parameter.
The Accept µ and A laws in SIP parameter determines codec compatibility (see: SIP
Trunking - Configuration procedure - Configuring system parameters ):
- When set to False:
• Outgoing calls: the G711 codec type (G711A or G711µ) provided in an offer

    

 !"  
  321/915
Chapter 6 

corresponds to the law of the OmniPCX Enterprise

• Incoming call:
• If the received offer includes both G711A and G711µ only the law defined for the
system is taken into account.
• If only one law is received and this law does not match the system law, the G711
codec cannot be selected. If no offer matches, the call fails and the 145 Media not
supported response is retuned.
- The Accept µ and A laws in SIP parameter is set to True:
• Outgoing call: the G711 offer provides both G711A and G711µ
• Incoming call: the offer (G711A, G711µ or both G711A and G711µ) is transmitted to
the called party for negotiation
When the called party selects a law which does not match the system law, some
services, such as voice mailbox, do not operate properly.
Enhanced codec negotiation
As of R11.1, the OmniPCX Enterprise supports the 491 Pending Request method.
This method, defined by the RFC 3261 standard, is used to solve collision of Re-INVITE
messages, and avoid call releases
A collision of Re-INVITE messages happens when you receive Re-INVITE as the answer to a
Re-INVITE message. This means that the two parties initiate a Re-INVITE simultaneously.
When a Re-INVITE collision happens, the RFC 3261 standard recommends to:
- Send a 491 Pending Request method
- Wait for a duration between zero and two seconds if you initiated the call, and between two
and four seconds if you received the call
- Repeat the Re-INVITE message
To support this feature, the Enhanced codec negotiation system parameter must be
configured.
The 491 Pending Request method is not supported for Fax T.38 calls.
6.3.3.15 SDP handling in 18x responses
For incoming calls to the PCX, if the INVITE message contains an SDP offer, the PCX
behavior depends on the SDP in 18x parameter value. If the SDP in 18x parameter is set to
False, the PCX sends an 180 RINGING response without SDP to the external gateway. This
occurs when it is SIP carrier, rather than the PCX, that provides the ring back tone to the
calling party. The SDP information is provided in the final 200 OK response as follows:

322/915     


 !"  
 
 

Figure 6.137: Example of incoming call

For more information on SDP use in media negotiation, refer to Media negotiation .
Until R10.1, when the called party is forwarded, the SIP carrier sends an 18x message with
SDP to the PCX. The PCX returns to the SIP carrier an 18x response with the SDP sent
transparently, as follows:

Figure 6.138: Example of immediate call forwarding (until R10.1)

In this example, the 183. Session Progress message with SDP received by the PCX is
returned to the SIP carrier in a 183. Session Progress response with SDP. This also
occurs when the message sent by the SIP carrier is a 180. Ringing message with SDP: the
PCX returns a 180. Ringing response with SDP.

    

 !"  
  323/915
Chapter 6 

As of R10.1, when the called party is forwarded, PCX behavior depends on the value of the
SDP relay on Ext. Call Fwd parameter, configured in the SIP external gateway:
- If the SDP relay on Ext. Call Fwd parameter is set to Default, the standard procedure
applies: the PCX returns to the SIP carrier an 18x response with the SDP sent
transparently (see: figure: Example of immediate call forwarding (until R10.1) )
- If the SDP relay on Ext. Call Fwd parameter is set to 180 only, the PCX systematically
returns to the SIP carrier a 180 Ringing response with SDP, regardless of the initial
message (and SDP) sent by the SIP carrier: 180 Ringing or 183 Session Progress
Caution:
To use the 180 only parameter value, the SIP trunk group defined between the SIP external
gateway and the PCX must be an ISDN SIP trunk group.
The following scenario shows the dialog for an immediate call forwarding when the SDP
relay on Ext. Call Fwd parameter is set to 180 only. This also applies to a delayed call
forwarding on no answer, provided that the SDP in 18x parameter is set to False.

Figure 6.139: Example of immediate call forwarding (as of R10.1)

In this example, the 183. Session Progress message with SDP received by the PCX
is returned to the SIP carrier in a 180. Ringing response with SDP. This also occurs
when the message sent by the SIP carrier is a 180. Ringing message with SDP: the
PCX returns a 180. Ringing response with SDP. If the message sent by the SIP carrier
has no SDP, the PCX returns the response without SDP.
For more information on the configuration of the SDP relay on Ext. Call Fwd parameter, see:
SIP Trunking - Configuration procedure - Configuring an External Gateway .
6.3.3.16 ABC-F versus ISDN SIP trunk groups
SIP trunk groups can be of two different types:
- ABC-F
- ISDN
An ABC-F trunk group offers the following services:

324/915     


 !"  
 
 

- Transfer, using the REFER, "Referred-by" and "Replaces" headers

- Diversion, using the 3xx Responses
- Direct RTP, using Re-INVITE
Note 1:
To avoid diversion loops, if a 3xx Response is received during the set up of an outgoing call, it is
released with the cause value "No route to destination". In the same way, if a REFER method or an
INVITE method with a "Replaces" header is received, the call is releases with a "503.Service
Unavailable" SIP response.
An ISDN SIP trunk group only offers Direct RTP. Transfer and diversion are carried out
internally by the OmniPCX Enterprise: REFER method, method containing a "Referred-by" or
"Replaces" headers or 3xx Responses are not sent to the SIP carrier.
Caution:
An ABC-F trunk group should not be used when canonical form is used by the SIP carrier.
Diversions and transfers would fail.

Note 2:
When ARS is used with either ABC-F SIP or ISDN SIP trunk groups, it is mandatory to use the [I]nsert
command in the DCT of the ARS.

6.3.3.17 Fax transmissions

6.3.3.17.1 Overview
A fax call is first established as a voice call. It switches to fax call, when the fax carrier is
detected.
There are several ways of transmitting a fax call:
- Via the T38 protocol. This protocol, dedicated to fax calls, includes the retry facility, which
allows the loss of packets. In addition, this protocol tolerates transmission delays.
- Via G711 transparent. Fax signaling are transmitted on a voice channel as it would be
done on an analog line. This transmission does not support loss of packets and requires a
lesser transmission delay.
Before R11, when a SIP external gateway is involved, the OmniPCX Enterprise only supports
the T38 protocol.
As of R11, when a SIP external gateway is involved, the OmniPCX Enterprise supports the
following procedures:
- T38 only: see T38 fax transmission
- G711 transparent: see G711 transparent fax transmission
- T38 to G711 Fallback: see T38 to G711 transparent transmission fallback
The type of procedure is selected in the external gateway parameters: see: SIP Trunking -
Configuration procedure - Configuring an External Gateway .
6.3.3.17.2 T38 fax transmission

    

 !"  
  325/915
Chapter 6 

Figure 6.140: Messages transmitted during a T38 fax outgoing call

When the remote party detects that the call is a fax call, if it supports the T38 protocol, it sends
a RE-INVITE message with the T38 offer.
If the T38 protocol is supported, the fax is transmitted according to the T38 protocol. If the T38
protocol is not supported, an error message is received.
When the OmniPCX Enterprise is in transit between two SIP external gateways, all messages,
including T38 messages or error messages, are transmitted transparently.
6.3.3.17.3 G711 transparent fax transmission
Nominal case
After initial negotiations, the fax is transmitted transparently. A voice channel is used to
transmit fax signaling.
G711 transparent fax transmission requires:
- A voice call established with the G711 algorithm
- An INT-IP3 board or a GD-3 board in front of the fax
Exceptional cases
Outgoing call
If the OmniPCX Enterprise receives a RE_INVITE with a T38 offer, the negotiated codec and
the IP coupler type are checked.

326/915     


 !"  
 
 

Two cases:
- The used codec is not G711 or the coupler is neither an INT-IP3 board nor a GD-3 board:
The fax call is processed according to the T38 protocol.

- The used codec is G711 and the coupler is an INT-IP3 board or a GD-3 board:
When the OmniPCX Enterprise receives RE_INVITE message with T38, it sends 488: Not
Acceptable Here to the external gateway and the fax call fails. This is because, when the
fax configuration of the external gateway is set to G711 transparent, the Media Gateway
is unable to switch to T38 mode.

    

 !"  
  327/915
Chapter 6 

Figure 6.142: Messages transmitted during a G711 transparent fax outgoing call

Incoming call
If the initial call is established with a G729/G723 codec or if the coupler in front of FAX is not
an INTIP3/MG3/GA3 board, the fax is transmitted according to the T38 protocol.
6.3.3.17.4 T38 to G711 transparent transmission fallback
As of R11.0, faxes can be transmitted either in T38 or in G711 transparent according to the
remote party capabilities.
Outgoing call
After fax detection:
- When the remote party can operate via the T38 protocol, a RE-INVITE message,
containing a T38 offer is transmitted
- When the remote party does not support the T38 protocol, the fax is transmitted on the
voice channel
Incoming call
When the OmniPCX Enterprise detects a fax call, it returns a RE-INVITE message with the
T38 offer:
- If the remote party accepts it, the fax is transmitted via the T38 protocol
- If the remote party refuses it, an error message is received and:
• If the coding algorithm is G711 and if an INT-IP3 board or a GD-3 boards is used, the

328/915     


 !"  
 
 

fax is transmitted transparently

• If the negotiated codec is not G711 or if the used board is not a INT-IP3 board nor a
GD-3 board, the call is refused
6.3.3.18 Authentication
6.3.3.18.1 Authentication on SIP gateway
According to the carrier subscription, connections messages (INVITE or REGISTER ) to the
external gateway can require an authentication by username and password.
Digest access authentication
The OmniPCX Enterprise supports the Digest access authentication which is a
challenge-reponse authentication. The Digest access authentication is compliant with the
RFC 2617 standard.
The main steps of a Digest access authentication process are:
1. A client which intends to connect to a server protected with a Digest access authentication,
sends a connection request
2. The server answers with an authentication request which includes a nonce. A nonce is a
random number used as a challenge.
3. The client must return an authentication message which includes its username in clear text
and an MD5 hash coding field built with the received nonce and the password.
4. On reception, the server compares the received MD5 hash coding and an MD5 hash
coding locally built with the same nonce and the configured password.
• If the comparison matches, the authentication succeeds and the request is accepted
• If the comparison does not match, the authentication fails and the request is refused
With this authentication procedure, the password is protected from eavesdroppers and from
reply attacks.
SIP authentication messages (prior to R11.0)
Authentication messages are:

    

 !"  
  329/915
Chapter 6 

Figure 6.143: SIP messages for authentication

1. The OmniPCX Enterprise (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 carrier, identifies the security domain
• qop (Quality of Protection): defines the protection level required by the carrier
• nonce: random number used for password protection
3. The OmniPCX Enterprise 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
counter is reset when the nonce is changed.
4. After verification, the request is accepted or refused

330/915     


 !"  
 
 

This procedure presents the drawback of overloading the network: for each request three
messages are required.
SIP authentication messages (as of R11.0)
As of R11.0 and when the configuration allows it, SIP authentication messages are simplified:
- For the first request, the authentication is performed as described in: SIP authentication
messages (prior to R11.0) .
- The following requests are simplified. Each request message (REGISTER and INVITE)
includes authentication information.
Several cases occur according to carrier behavior:
• Normal case:

Figure 6.144: Simplified authentication

The Response field is built with the nonce previously received and a new cnonce. The
nonce counter is incremented each time the nonce is used.
• New challenge:
The carrier can decide to challenge again the OmniPCX Enterprise: the INVITE (or
REGISTER) request is refused and a new challenge is received.
The authentication procedure is similar to the one described: SIP authentication
messages (prior to R11.0) .
• A new nonce is transmitted:

    

 !"  
  331/915
Chapter 6 

Figure 6.145: 200 Ok message with a Nextnonce field

The carrier accepts the request and simultaneously sends a new nonce which will be
used for the next request. The nonce counter is set to 1.
CPU restart and CPU duplication
The nonce and the nonce counter are not stored in a permanent memory nor duplicated in the
backup CPU. In case of CPU switchover or CPU restart, authentication is restarted as
described: figure: SIP messages for authentication .
6.3.3.18.2 Authentication from an external gateway
As of R11.2, authentication of an external gateway by the OmniPCX Enterprise is possible.
The fields Incoming username and Incoming Password are used.
6.3.3.19 Early-Media feature
6.3.3.19.1 Overview
As of R11.0, the OmniPCX Enterprise supports the Early-Media feature.
With the Early-Media feature, before call establishment, the calling user hears a tone (for
example: ring back tone) locally generated by the set or a voice channel of the SIP trunk.
Not all SIP gateways support the Early-Media feature (see: SIP Trunking - Configuration
procedure - Configuring an External Gateway ).
6.3.3.19.2 Early Media negotiation
The P-Early-Media header can be used in SIP messages to control the early media:
1. When the gateway supports the feature, the INVITE message includes a P-Early-Media
header set to Supported
2. The answer is transmitted in the P-Early-Media header:

332/915     


 !"  
 
 

• When the remote party sends back the P-Early-Media header, set to sendonly or
sendrecv, the calling party is connected to the voice channel.
• When the remote party sends back the P-Early-Media header, set to recvonly or
inactive, the calling party is connected to the tone locally generated by the set.
The Early Media feature can also be controlled via SDP offer and SDP answer.
6.3.3.19.3 Outgoing calls
INVITE messages can include the P-Early-Media header to offer the Early Media feature to the
remote party.

Figure 6.146: Example of messages for a connection to a remote SIP gateway

UPDATE messages can also transmit an SDP offer.
Response messages (180 Ringing and 183 Progress) can also transmit a P-Early-Media
header and/or an SDP answer.
When the call status changes, several response messages (180 Ringing and 183 Progress)
can be received successively and active or deactivate the Early-Media feature accordingly.
Both P-Early-Media header and SDP answer can be included in a response. When the
P-Early-Media header is included, the direction parameter in SDP answer is not taken into
account.
Mode 1 and Mode 2 parameters are used to connect voice channel locally or remotely based
on the presence of P-Early-Media header in the Invite Responses:
- Mode 1: local connection to play the tone if P-Early-Media header is not present in the
response.
- Mode 2: remote connection to the voice channel if SDP is present in the response and no
P-Early-Media header.
6.3.3.19.4 Incoming calls
When the OmniPCX Enterprise receives an INVITE (or UPDATE) message with the
P-Early-Media header set to supported, it answers with a provisional response including a
P-Early-Media header set to sendrecv.

    

 !"  
  333/915
Chapter 6 

When the OmniPCX Enterprise receives an INVITE message without the P-Early-Media
header, it answers with a provisional response which does not provide any P-Early-Media
header.

Figure 6.147: Example of incoming call with a P-Early-Media header

6.3.3.19.5 Transit calls

A call coming from a SIP gateway can be routed to another SIP gateway.

Figure 6.148: Example of transit call with P-Early-Media header

Whether the RFC 5009 supported / Outbound call parameter of the destination gateway is
configured in Mode 1 or Mode 2 (see: SIP Trunking - Configuration procedure - Configuring an
External Gateway ), the P-Early-Media header is transmitted without modification.
When the RFC 5009 supported / Outbound call call parameter of the destination gateway is
configured as Not supported, the P-Early-Media header is not included in outgoing INVITE.

334/915     


 !"  
 
 

In these two cases, answers are transmitted without modification.

For transit calls only, UPDATE messages can include a P-Early-Media header.
6.3.3.19.6 Network call
A transit call, from a SIP gateway to an other SIP gateway can be routed via several OmniPCX
Enterprise nodes. As long as the inter node protocol transmits the P-Early-Media header, a
network call is similar to a transit call.
6.3.3.20 CAC on SIP trunk group
CAC (Calls Admission Control) limits the number of calls on a SIP trunk group. This limitation
allows to maintain good sound quality.
The parameter Max ABCF-IP and SIP connections defines the maximum number of
simultaneous calls allowed on a given trunk group.
At each call establishment, the system verifies this parameter and if the maximum number of
established calls is reached, the call is rejected or rerouted (provided overflow routes are
configured).
The maximum number of voice connections on a trunk group is defined by the installer from
the capacity of the trunk group and from the used compression algorithms.
When a SIP trunk group connects two OmniPCX Enterprises, enter the same value for the
configuration of the two systems. If not, the lowest value defines the maximum number of calls.
6.3.3.21 302 support for Call Forwarding
This feature is dealing with the so called external call forwarding. The scenario is an external
inbound call (User X), whose destination is an internal user (User A), which has itself activated
a forward to an external user (User Y). This activation may be either unconditional, or on no
reply, or on busy.
Up to release 11.1, this scenario leads the OmniPCX Enterprise to relay the call from user X to
user Y, while remaining in the signaling path.
If both users X and Y are located behind a SIP carrier, there is consequently a signaling loop
between the SIP leg-X and the SIP leg-Y, through the OmniPCX Enterprise. The OmniPCX
Enterprise remains in the SIP signaling path, and two SIP licenses are consequently used. In
addition, it requires two “resources” on SIP carrier side.
As of R11.2, the request is to relay the procedure to the SIP carrier by using the 302.Moved
Temporarily response.
The SIP carrier, by analyzing the SIP URI of the Contact header of the 302.Moved
Temporarily response, becomes in charge to directly route the call from User X to User Y. In
other words, the OmniPCX Enterprise disappears from the SIP signaling path. This is
determined by the Redirection response support parameter (see: SIP Trunking -
Configuration procedure - Configuring an External Gateway ).
The set A has to be located on the same node as the incoming call (leg X-A) and outgoing call
(leg A-Y). A is an OmniPCX Enterprise user, it cannot be an OpenTouch user. It applies only
to SIP-ISDN trunks.
It’s strongly recommended to set up this functionality in a topology where a unique SIP carrier
is located at customer site.
In addition, a Metering Ticket is provided and contains the following information: The charged
party is the OmniPCX Enterprise user (User A). It provides the destination number (User Y).

    

 !"  
  335/915
Chapter 6 

As Internal Facility, it provides either “Call Forwarding Unconditional”, or “Call Forwarding On

No Reply”, or “Call Forwarding On Busy”. Its duration is null.
6.3.3.22 Restrictions
6.3.3.22.1 Restrictions due to lack of SIP specifications
The following features are not available on SIP trunk groups because they are not specified by
SIP
- Metering (however, for outgoing calls, Duration Metering function can be used)
- Call Completion
- Malicious Call Tracing
- Diversion: there is no history of the call, only the 3xx Class Responses is defined
6.3.3.22.2 Other restrictions
A SIP trunk group cannot be distributed over several nodes.
SIP URLs are not supported by OmniPCX Enterprise: it is not possible to type directly an URL
on a set of the OmniPCX Enterprise. One must dial a phone number, which is converted into a
URL using the dictionary.
When using routing prefixes, open numbering plan is not supported.
Dialing by overlap is not allowed by SIP. En-bloc ARS prefixes must be used.
Flow II, flow III and flow IV defined in RFC3725 are not implemented.

6.3.4 Configuration procedure

6.3.4.1 Overview
According to the network topology (see SIP Trunking - Topologies ), SIP trunking configuration
requires:
- The configuration of one or several SIP trunk groups: Configuring a SIP Trunk Group
- The configuration of one or several external gateways: Configuring an External Gateway
Two complete configuration examples are described in:
- SIP Trunking - SIP Trunking Configuration Examples - ISDN Mode
- SIP Trunking - SIP Trunking Configuration Examples - ABC-F Mode
6.3.4.2 Prerequisites
SIP trunking requires the basic SIP configuration to be performed: see SIP - Configuration
procedure .
- The main trunk group of the main gateway must be created. This is necessary for external
gateways to operate, even if these gateways use dedicated trunk groups.
- When ARS is used with either ABC-F SIP or ISDN SIP trunk groups, it is mandatory to use
the [I]nsert command in the DCT of the ARS.
6.3.4.3 Configuring system parameters

336/915     


 !"  



1. Select System > Other System Param. > SIP Parameters
2. Review/modify the following attributes:
Via Header_ Inbound Calls Rout-
ing
Reject unidentified proxy calls
Loose Route with RegID
   
 !"  

As of R9.1, this system option allows the analysis of the
Via header to determine the origin of incoming calls: see
SIP Trunking - Detailed description - Incoming Calls for
more details.
• False (default value): The via header is not used to
determine the origin of incoming calls.
• True: The via header is used to determine the origin
of incoming calls when other headers do not match
with the RemoteDomain of an External Gateway.
As of R10.1, when the origin of an incoming call cannot
be determined (see: SIP Trunking - Detailed description
- Origin of the incoming call ), the call can be routed as
follows:
• False (default value): The call is routed to the main
trunk group
• True: The call is rejected and the SIP error re-
sponse: 403 forbidden is sent to the SIP network
of the calling party
The Route header is used for incoming call routing
when it is present in the INVITE message and its do-
main part includes the OmniPCX Enterprise IP address,
or machine name, or the concatenation of the fields Ma-
chine name and DNS local domain name of the main
SIP gateway
As of R10.1, the parameter Loose Route with RegID
determines if the user part of the Route header is re-
quired for call routing (see: SIP Trunking - Detailed de-
scription - Origin of the incoming call ):
• True (default value): The user part is required and
must contain the registration identifier (that is Re-
gID) of the external gateway
Example 1:
INVITE sip:+33155669001@RemoteDomain SIP/
2.0
To: <sip:+33155669001@BelongingDomain>
From: <sip:+33147858000@RemoteDomain>
Route: <sip:RegID@OXE_Address>
• False: The user part is not required and can be
empty
Example 2:
INVITE sip:+33155669001@RemoteDomain SIP/
2.0
To: <sip:+33155669001@BelongingDomain>
From: <sip:+33147858000@RemoteDomain>
Route: <sip: OXE_Address>

 337/915
Chapter 6 
G722 for SIP trunking
Enhanced codec negotiation
Private SIP transit mode
3. Confirm your entries
1. Select System > Other System Param. > System Option
2. Review/modify the following attributes:
338/915
 !"  
As of R11.0, this parameter defines the use of the G722
algorithm on SIP trunk groups:
• False: The G722 algorithm is never used on SIP
trunk groups. The G722 codec is never sent in an
offer.
• True (default value): The G722 algorithm can be
used on SIP trunk groups. The G722 codec can be
included in an offer.
As of R11.0, this parameter defines codec renegotiation
for call transfers:
• Not available: Codec are not renegotiated for call
transfers (default value)
• Local Type: Codec are renegotiated for calls trans-
fers only when destination of the transfer is located
on the same node
• Network Type: Codec are renegotiated for calls
transfers. The destination of the transfer can be loc-
ated on the same node or on an other node.
Restrictions:
• All nodes must operate with a R11.0.1 release
or above
• All nodes must be configured with the En-
hanced codec negotiation parameter set to
Network Type
• There is no TDM link, no ABC-F TDM trunk
group nor QSIG TDM trunk group in the network
Select the OmniPCX Enterprise behavior for calls in
transit:
• Proxy or redirect mode: SIP calls in transit are
rerouted by the OmniPCX Enterprise acting as a
proxy.
This option avoids an unnecessary load for the Om-
niPCX Enterprise.
• Full Call Handling mode: SIP calls in transit are
proceeded by the Call Handling as all other calls.
• Mixed mode (default value):
• Calls between OpenTouch and OmniPCX Office
and calls between OmniPCX Office and OmniP-
CX Office are proceeded by the Call Handling as
all other calls.
• Other calls are rerouted as a proxy
This option must be selected when the OmniPCX
Enterprise operates with an OpenTouch.
   


 

Accept MU and A laws in SIP
As of R9.0, this parameter defines which coding law is
accepted in a G711 offer (G711A or G711µ):
• False: (default value)
• For incoming calls, only the law matching the
system law is accepted
• For outgoing calls, a G711 offer includes the law
matching the system law
• True:
• For incoming calls, the G711 offer is transmitted
to the called party for negotiation
• For outgoing calls, a G711 offer includes both
G711A and G711µ.

3. Confirm your entries

1. Select System > Other System Param. > Compression Parameters
2. Review/modify the following attributes:
Multi. Algorithms for Compres- • False: Only one compression algorithm is used for
sion voice.
(recommended)
• True: The G723 or G729 coding algorithm can be
used for voice compression.

3. Confirm your entries

6.3.4.4 Configuring a SIP Trunk Group
One SIP trunk group is used to reach external SIP extensions (this trunk group is called the
main SIP trunk group) and one or several other SIP trunk group(s) are used to reach external
gateways.
Note:
- The main trunk group of the main gateway must always be created. This is necessary for external
gateways to operate, even if these gateways use dedicated trunk groups.
- When ARS is used with either ABC-F SIP or ISDN SIP trunk groups, it is mandatory to use the
[I]nsert command in the DCT of the ARS.
6.3.4.4.1 Creating a trunk group
1. Select: Trunk Groups
2. Review/modify the following attributes:
Trunk Group ID Enter the trunk group number.
Trunk Group Type T2
Remote Network Enter the subnetwork number associated with the trunk
group.

3. Confirm your entries.

The system displays a new screen
4. Review/modify the following attributes:

    

 !"  
  339/915
Chapter 6 

Node number Enter the node number

Q931 signal variant • Select ABC-F for the main SIP trunk group
• Select either ABC-F or ISDN all countries for other
trunk groups (for more information, see SIP - SIP
Trunking - ABC-F versus ISDN SIP Trunk Groups)
Important:
The value ISDN FRANCE must never be selected.
T2 Specification Select the type of SIP trunk group:
• SIP: Allows 62 simultaneous communications per
pair of accesses.
• MINI SIP (as of R8.0.1): Allows 4 simultaneous
communications per pair of accesses.
Associated Ext SIP gateway Enter the external SIP gateway number associated to
this trunk group.
Enter -1 for no association
For more information, see: ARS - Detailed description -
Configuring emergency calls.
Max. ABC-IP and SIP Connec- As of R11.0.1, enter the maximum number of simultan-
tions eous voice connections.
When this attribute is set to 0, the number of simultan-
eous calls is not limited.
In case of reduction of the maximum number of calls,
the new value is taken into account for new call estab-
lishments only. Calls in conversation are not affected.
This parameter is only used on SIP trunk groups and IP
ABC trunk groups

5. Confirm your entries

6.3.4.4.2 Configuring compression type
As of R11.0, the IP Compression Type parameter is replaced by the Type of codec
negotiation parameter of the gateway configuration (see: Configuring an External Gateway ).
The IP Compression Type parameter is no more available.
Before R11.0, a compression algorithm is configured at system and SIP trunk group level. The
compression algorithm is selected by negotiation with the SIP set, taking into account this
configured data and the algorithms supported by the set (see: Direct RTP in network - Coding
configuration ).
1. Select: Trunk Groups > Trunk Group
2. Review/modify the following attribute:
IP Compression Type • Default: Only the system algorithm can be used by
the gateway associated to this trunk
• G711 (default value): Both G711 and G729 can be
used by the gateway associated to this trunk

3. Confirm your entry

6.3.4.4.3 Configuring virtual accesses

340/915     


 !"  
 
 

1. Select: Trunk Groups > Trunk Group > Virtual access for SIP
2. Review/modify the following attribute:
Number of SIP Access When a SIP trunk group is created, a pair of accesses is
automatically created.
As of R7,0 up to 16 pairs of accesses can be configured
(6 before). Accesses are always configured in pairs.
The maximum number of communications per trunk
group depends on the type of trunk group:
• SIP: 992 simultaneous communications maximum
with 62 communications per pair of accesses (31
per access)
• MINI SIP: 64 simultaneous communications maxim-
um with 4 communications per pair of accesses (2
per access)
This limit only applies to calls between SIP terminals
and standard sets in the PCX (except if CAC SIP-SIP is
used; in this case SIP-SIP communications are also
taken into account).

3. Confirm your entry

4. Reboot the OmniPCX Enterprise server to take the new value into account
Caution:
If you add new SIP accesses and you do not reboot the server, the trkstat command
displays these accesses as free (F) but they cannot be used until next reboot.
6.3.4.5 Configuring the RSI application
1. Select: Applications > CCD > RSI
2. Review/modify the following attribute:
RSI Directory Number Enter the directory number of the RSI
Route select relay Select the behavior of the OmniPCX Enterprise when
the RSI application initiates a call transfer:
• False: The OmniPCX Enterprise performs call trans-
fers with a second call establishment.
• True: The OmniPCX Enterprise performs call trans-
fers with REFER messages.
This option authorizes the parameter Unattended
Transfer (RFC3515) for RSI of external gateways
to be set to True

3. Confirm your entry

6.3.4.6 Configuring an External Gateway
It is possible to declare one or several external gateways on the PCX. Gateways are accessed
either by routing number or ARS: see the SIP - Configuration examples - External Gateway.
1. Select: SIP > SIP Ext Gateway
2. Review/modify the following attributes:

    

 !"  
  341/915
Chapter 6 

SIP External Gateway ID Enter gateway number

Gateway Name Enter a name for the gateway
SIP Remote domain Enter the domain part of the remote access SIP URL
PCS IP Address Enter the PCS IP Address if the external gateway can
be rescued by a Passive Communication Server:
• When a valid IP address is entered, the PCS with
this address is associated.
• When this parameter is empty, no PCS is associ-
ated. This value is used when the external gateway
is associated with the communication server.
• As of R11.1, when 255.255.225.255 is entered for
this parameter, no PCS is associated to this gate-
way.
The value 255.255.255.255 is called the Global ad-
dress.
In addition, when a Global address is used, a SIP
trunk group and a SIP external gateway is created
automatically for each configured PCS.
SIP Port Number Enter the port number to be used by SIP signalling of
the external gateway in the remote domain.
Default value: 5060
Transport Type Enter the transport type:
• TCP (default value)
• UDP
• TLS Client
• TLS Server
Belonging domain To be filled in if the external gateway is to register to the
SIP carrier.
Enter the domain part of the address of the external
gateway to be used for registration.
Registration Id To be filled in if the external gateway is to register to the
SIP carrier.
Enter the identifier of the external gateway to be used
for registration.
The gateways registers under the address
[Registration Id]@[Belonging domain]
Registration_ID_P_Asserted This parameter and the RFC 3325 supported by the
distant parameter are used for outgoing calls when the
calling user requests an anonymous call.
See the RFC 3325 supported by the distant paramet-
er for details.

342/915     


 !"  
 
 

Registration timer Enter the lifetime applied to the registration (in

seconds).
Default value: 0 (no registration).
Note 1:
In a PCS configuration, if the OmniPCX Enterprise is respons-
ible for the external gateway registration/supervision, a value
different from 0 is mandatory for one of the Registration timer
and Supervision timer parameters.
SIP Outbound Proxy To be filled in if outgoing requests to the associated SIP
carrier must be routed to a proxy.
Enter the user part of the address of the external proxy.
Note 2:
If no address is entered, outgoing requests are sent to the re-
mote domain.
Supervision timer Enter the periodicity (in seconds) of emission of OP-
TION method to the external gateway (this is used to
supervise the state of the external gateway).
Default value: 0 (no supervision).
Note 3:
In a PCS configuration, if the OmniPCX Enterprise is respons-
ible for the external gateway registration/supervision, a value
different from 0 is mandatory for one of the Registration timer
and Supervision timer parameters.
Trunk group number Enter the number of the SIP trunk group to be used by
incoming calls from the external gateway.
Default value: the main SIP trunk group number.
Note 4:
If a different trunk group is used for outgoing calls, its number
is entered in the ARS route.
Pool Number This parameter is used if several gateways are associ-
ated to the same SIP carrier.
Enter a number between 0 and 4.
Default value: -1 (the gateway is not part of a pool).
Outgoing realm Realm (SIP security area identifier) for which authentic-
ated name and password will be provided in response to
an authentication request made by the remote SIP gate-
way.
This authentication information is checked by the re-
mote gateway.
Outgoing username Authenticated name provided in response to an authen-
tication request made by the remote SIP gateway.
This authentication information is checked by the re-
mote gateway.

    

 !"  
  343/915
Chapter 6 

Outgoing Password Password provided in response to an authentication re-

Incoming username
Incoming Password
RFC 3325 supported by the dis-
tant
DNS type
quest made by the remote SIP gateway (20 characters
maximum).
This authentication information is checked by the re-
mote gateway.
Authenticated name that the remote SIP gateway must
provide to the Call Server.
For incoming calls from an external gateway to be au-
thenticated, the following attributes must be completed.
Authentication realm is defined in the proxy parameters.
Authenticated password that the remote SIP gateway
must provide to the Call Server (20 characters maxim-
um).
This parameter and the Registration_ID_P_Asserted
parameter are used for outgoing calls when the calling
user requests an anonymous call.
These parameters define the content of the From, P-
Asserted-Identity and Privacy headers. These paramet-
ers must be set according to the capacity of the external
gateway:
• RFC 3325 supported by the distant set to True
and Registration_ID_P_Asserted set to False:
From: sip:anonymous@anomymous.invalid
P-Assert-Identity:
sip:UserNumber@BelongingDomain
Privacy: user,id
• RFC 3325 supported by the distant set to True
and Registration_ID_P_Asserted set to True:
From: sip:anonymous@anomymous.invalid
P-Assert-Identity: sip:RegID@BelongingDomain
Privacy: user,id
• RFC 3325 supported by the distant set to False:
and Registration_ID_P_Asserted set to False:
From: sip:UserNumber@BelongingDomain
P-Assert-Identity: this header is not present
Privacy: user
• RFC 3325 supported by the distant set to False:
and Registration_ID_P_Asserted set to True:
From: sip:UserNumber@BelongingDomain
P-Assert-Identity: sip:RegID@BelongingDomain
Privacy: user,id
Select the type of the DNS server used to solve the
FQDN for this external gateway:
• DNSA: The SIP external gateway sends DNSA re-
quests to resolve a domain name in one single IP
address.
• DNS SRV: The SIP external gateway sends DNSS-
RV requests to get one or several names or IP ad-
dresses corresponding to a domain name.

344/915     


 !"  



SIP DNS1 IP Address
SIP DNS2 IP Address
SDP IN 18x
Minimal authentication method
INFO method for remote exten-
sion
Send only trunk group algo
To EMS
   
 !"  

As of R9.0. enter the primary DNS address used by this
external gateway.
If no address is entered, the SIP DNS1 IP Address of
the main gateway is used.
As of R9.0. Enter the secondary DNS address used by
this external gateway.
If no address is entered, the SIP DNS1 IP Address of
the main gateway is used.
Indicates if the SDP will be present in 180 RINGING
sent by the OmniPCX Enterprise.
Select the authentication method to be used by the ex-
ternal gateway:
• SIP None: No authentication
• SIP Digest: Authentication by login and password,
with encryption
Default value: SIP Digest.
Note 5:
This parameter applies to the external gateway and all SIP
devices and external voice mails behind this gateway.
To enable the SIP INFO method (used only for the re-
ception of DTMF values), configure the following attrib-
ute:
• True: SIP external gateway supports the SIP INFO
method.
• False: SIP external gateway does not support the
SIP INFO method.
• Before R11.0, this parameter is used for codec ne-
gotiation:
• True:
a. If the IP compression type parameter of
the SIP trunk group is set to default, the co-
dec offer contains only G729.
b. If the IP compression type parameter of
the SIP trunk group is set to G711, the co-
dec offer contains only G711.
• False:
The codec offer is built according to other para-
meters (and typically results in a G711/G729 or
G729/G711 offer)
• As of R11.0, this parameter is no longer available. It
is replaced by the Type of codec negotiation para-
meter for external gateway configuration.
Select Yes if the external gateway is used for connec-
tion to an EMS.
Default value: No.

 345/915
Chapter 6 

SRTP Select the voice transmission type:

Ignore inactive / black hole
Contact with IP address
Dynamic Payload Type for DTMF
• RTP only: The RTP flow is never secured
• RTP or SRTP: The RTP flow is secured according
to the remote party capacity
• SRTP only: The RTP flow is always secured. When
the remote party does not support SRTP, the call
fails.
This only applies to SIP ABC-F:
• False: The receipt of a RE-INVITE, whose SDP in-
dicates either inactive or c=0.0.0.0, is handled as a
Hold request
• True: The same kind of RE-INVITE leads the RTP
flow towards the remote party to be cut.
This parameter is used in spatial redundancy.
This parameter defines the content of the Contact head-
er:
• False: The Contact header is filled with the concat-
enation of the Machine name field and DNS local
domain name field of the main SIP gateway
The remote SIP End Point is in charge of retrieving
the IP address with a DNS query or with a supervi-
sion mechanism using OPTIONS...
• True: The Contact header is filled with the IP ad-
dress
Note 6:
The Contact header is included in the following methods:
• INVITE
• 180.Ringing
• 183.Session Progress
• Re-INVITE
• 200.OK for INVITE and Re-INVITE
• ACK
• OPTIONS
• REGISTER
• REFER (used for private SIP Trunking)
• NOTIFY (used for private SIP Trunking)
• SUBSCRIBE (used for private SIP Trunking)
For SIP trunking adaptation, configure the following at-
tribute:
Enter a number between 96 and 127
Default value: 97
This value is suggested by OmniPCX Enterprise for out-
going calls "negotiable value"

346/915     


 !"  



Outbound Calls 100 REL
Incoming Calls 100 REL
Gateway type
Serial Number of Certificate TLS
Re-trans No. for REGISTER/OP-
TIONS
P-Asserted-ID in Calling Number
   
 !"  

As of R9.1. select one of the following options:
• Not supported (default option): Outgoing INVITE
messages do not include the 100Rel option tag
neither in the Supported header nor in the Require
header
• Supported: Outgoing INVITE messages include the
100Rel option tag in the Supported header
• Required: Each outgoing INVITE messages include
the 100Rel option tag in the Require header
This parameter applies only when the received INVITE
message does not include the 100Rel option tag in the
Require header and includes the 100Rel option tag in
the Supported header.
Select one of the following options:
• Not requested: 18x provisional response from the
OmniPCX Enterprise does not include the 100Rel
option tag in the Require header
• Required Mode 1: 18x provisional response from
the OmniPCX Enterprise includes the 100Rel option
tag in the Require header only when it provides an
SDP answer. If this is not the case, the answer does
not include the 100Rel option tag.
• Required Mode 2: 18x provisional response from
the OmniPCX Enterprise includes the 100Rel option
tag in the Require header
This parameter defines the usage of P-Alcatel-CSBU
and P-CAC-ALU proprietary headers:
• Standard type: These headers are not provided
This option is used for an external gateway connec-
ted to a SIP carrier.
• ICE type: These headers are provided
This option is used for an external gateway connec-
ted to an OpenTouch.
Enter the certificate serial number of the client gateway
in case of mutual authentication.
This parameter is used only when the Transport Type
parameter is set to TLS Client.
As of R10.0, enter the number of retransmissions of RE-
GISTER and OPTIONS methods after which the Omni-
PCX Enterprise considers that the external gateway is
unavailable.
Default value: 2
See SIP Trunking - Detailed description - External gate-
way registration and SIP Trunking - Detailed description
- Supervision of an external gateway for more details.
Select the calling number:
• False: The calling number is filled from the From
header
• True: The calling number is filled from the P-
Asserted-ID header

 347/915
Chapter 6 

Trusted P-Asserted-ID header As of R10.0, this parameter is used for call presentation
of incoming calls. It applies to calls with a P-Asserted-ID
header in the INVITE message:
• True (default value): The octet 3a indicates Net-
work provided, or User provided, not screened if
the P-Asserted-ID in Calling Number parameter is
disabled and the User part of P-Asserted-ID and
From are different.
• False: The octet 3a indicates User provided, not
screened
See SIP Trunking - Detailed description - Call Presenta-
tion for more details.
Diversion Info to provide via In the outbound INVITE; the selected header is added to
provide information on Call deflection/forward:
• History-Info (RFC 4244)
• Diversion (RFC 5806)
Proxy identification on IP address As of R10.1, this parameter defines the process used to
determine the origin of an incoming call (see: SIP Trunk-
ing - Detailed description - Origin of the incoming call ):
• True: The DNS cache of the OmniPCX Enterprise
and the source IP address of the inbound request
sender (outbound proxy or remote domain) are
used: if the source IP address matches one of the IP
addresses of the DNS cache, the incoming call is
identified as originating from this external gateway
• False (default option): The headers of the inbound
request (Route, P-Asserted-ID, FROM or Via)
are used to identify the incoming call as originating
from this external gateway
Outbound calls only When several external gateways refer to the same re-
mote domain, the origin of the call is determined by a
search, performed among all external gateways, to
identify the first external gateway whose call information
can be processed by the OmniPCX Enterprise. For
more information, see: SIP Trunking - Detailed descrip-
tion - Origin of the incoming call .
As of R10.1, the external gateway can be excluded from
the search procedure to find the origin of the call:
• False (default value): this external gateway can re-
ceive incoming calls
• True: this external gateway can only handle outgo-
ing calls

348/915     


 !"  



SDP relay on Ext. Call Fwd
Registration on proxy discovery
SDP Transparency Override
   
 !"  

As of R10.1, this parameter determines the response
sent by the PCX to the SIP carrier when an incoming
call is forwarded (see: SIP Trunking - Detailed descrip-
tion - SDP handling in 18x responses ):
• Default (default value): When the SIP carrier sends
a 183. Session Progress message with SDP,
the PCX returns to the SIP carrier a 183. Session
Progress response with SDP
When the SIP carrier sends a 180. Ringing mes-
sage with SDP, the PCX returns a 180. Ringing
response with SDP
• 180 only: When the SIP carrier sends a 183.
Session Progress message with SDP, the PCX
returns a 180. Ringing response with SDP
When the SIP carrier sends a 180. Ringing mes-
sage with SDP, the PCX returns a 180. Ringing
response with SDP
Caution 1:
This parameter only applies to external gateways associ-
ated to an ISDN SIP trunk group. When external gateways
are associated to an ABC-F SIP trunk group, the standard
procedure (Default value) applies.
As of R10.1, this parameter is used when the external
gateway is registered to an out of service outbound
proxy (see: SIP Trunking - Detailed description - Regis-
tration after an outbound proxy switchover ):
• True: If the SIP carrier has another outbound proxy,
the external gateway can register to this outbound
proxy, using the information stored in the DNS
cache of the OmniPCX Enterprise
• False (default option): The registration procedure
described: SIP Trunking - Detailed description - Ori-
gin of the incoming call applies
Caution 2:
The Registration on proxy discovery can be set to True
provided the Registration timer parameter value is differ-
ent from 0.
Define the SDP offer in case of transit from a SIP gate-
way #1 to a SIP gateway #2:
• False (default value): Each SDP offer received from
a SIP gateway #1 is transparently relayed on SIP
gateway #2
• True: If a SIP SDP offer received is unique (G711 or
G729) the SDP offer relayed on the SIP gateway #2
is enhanced with missing codecs

 349/915
Chapter 6 

RFC 5009 supported / Outbound
call
Nonce caching activation
FAX Procedure Type
Defines the system behavior about the P-Early-Media
header:
• Not supported (default value): For outgoing calls,
the P-Early-Media header is never included in IN-
VITE, or UPDATE methods.
• Mode 1: For outbound calls, the P-Early-Media
header is always included in INVITE or UPDATE
(for transit only) methods.
In addition, when the P Early Media is not present in
a 18x response, the content of the SDP answer is
not taken into account to activate the Early Media
feature. In that case, a local ring back tone is gener-
ated
• Mode 2: For outbound calls, the P-Early-Media
header is always included in INVITE or UPDATE
(for transit only) methods.
In addition, when the P Early Media header is not
present in the 18x response, the content of the
SDP answer is taken into account to activate the
Early Media feature.
As of R11.0, this parameter defines the authentication
procedure for INVITE or REGISTER requests:
• No (default value): The OmniPCX Enterprise never
provides authentication information with the first IN-
VITE or REGISTER requests.
With this option, OmniPCX Enterprise behavior is
identical to its behavior prior to R11.0.
• Yes: The OmniPCX Enterprise stores received
nonces and provides authentication information in
the first INVITE or REGISTER messages, provided
the nonce already exists
As of R11.0, this parameter defines the FAX transmis-
sion procedure used over the SIP trunk group:
• T38 only (default value): FAX calls are transmitted
according to the T38 protocol.
If the remote party does not support the T38 pro-
tocol, the call fails.
• G711 transparent: FAX calls are transmitted with
G711.
If the two conditions below are not met, the FAX call
is transmitted according to the T38 protocol. And in
this case, if the remote party does not support the
T38 protocol, the call fails.
G711 transparent requires that:
• The initial call is established with the G711 com-
pression algorithm
• The call uses an INT-IP3 board or a GD-3 board
• T38 to G711 Fallback: T38 transmission is tested
first. If available the call goes through. If does not
suit, the G711 transparent transmission is tested. If
available the call goes through, if does not suit, the
call fails.

350/915     


 !"  



DNS SRV/Call retry on busy serv- As of R11.0.1, enter the number rerouting of an INVITE
er
Unattended Transfer for RSI
Redirection functionality
Attended Transfer
Send BYE on REFER
   
 !"  

request, when the proxy server answers with a busy
message.
When this attribute is set to 0, the request is not
rerouted and the call fails.
As of R11.0.1, select the behavior of the proxy server
for transfers initiated from the RSI application:
• NO: The proxy server does not support REFER
messages for call transfers
• YES: The proxy server does not support REFER
messages for call transfers
Note 7:
This parameter can be set to True only when the parameter
Route select relay of RSI data is set to True.
See: Configuring the RSI application
As of R11.0.1, select the behavior of the SBC server for
call redirections:
• NO: The SBC does not support call redirections
• YES: The SBC supports call redirections
As of R11.0.1, select the behavior of the proxy server
for a transfer initiated by a user:
• NO : The proxy server does not support REFER
messages for call transfers
• YES: The proxy server supports REFER messages
for call transfers
Note 8:
This parameter can be set to True only if the parameter
Support Re-Invite without SDP is set to True.
As of R11.1, select the behavior of the OmniPCX Enter-
prise for the release of transferred calls:
• No: The OmniPCX Enterprise waits for a BYE mes-
sage from the carrier to release the transferred calls.
• Yes (default value): The OmniPCX Enterprise initi-
ates the release of transferred call by sending the
BYE message.
This option must be used with SIP carrier full com-
pliant with RFC 5589.

 351/915
Chapter 6 

Redirection response support As of R11.2, the following configuration allows a SIP

OPTIONS required
carrier to process the call forwarding of an OmniPCX
Enterprise user, when the caller and the recipient of the
call forwarding rely on this SIP carrier. In this configura-
tion, the OmniPCX Enterprise plays no part in the call
forwarding process.
If set to Yes, when external call forward is activated on
User A to User Y, while receiving an external call from
User X, the OmniPCX Enterprise is analyzing the relev-
ant diverted-to number (User Y). A 302.Moved Tempor-
arily response is then sent back to the SIP carrier on
the following conditions:
• Condition 1: The diverted-to number provides an
ARS prefix. At that time, the ARS mechanism is
analyzed on behalf of User A, i.e. just as if User A
had directly dialed the diverted-to number. This
mechanism returns a route list. The following pro-
cedure applies to the first route of this route list
• Condition 2: A DCT is available for this route, and a
SIP gateway number is available for this DCT
• Condition 3: The SIP gateway number the original
call comes from matches with the one of the DCT
If all the conditions above are fulfilled, the Contact head-
er of the 302.Moved Temporarily response is built as
follows:
• User part: The Add and Delete commands, if any,
of the route, is applied to the original diverted-to
number. The result might be provided in a canonical
form, depending on the NPD management of the
route
• Domain part: It’s built with the Remote Domain
parameter of the gateway the call comes from
No is the default value
As of R11.2, this parameter is used to manage either re-
gistration (REGISTER) or supervision (OPTIONS) to
periodically update the DNS cache:
• False: If the parameter: Proxy identification on IP
address is set to True and Supervision timer is
managed, at the start of the system, the OmniPCX
Enterprise makes a DNS request using the Remote
Domain gateway parameter, updates the DNS
cache accordingly, but does not send any request
(no OPTION). The procedure is repeated at expira-
tion of the supervision timer.
Note 9:
If the Remote Domain is managed as an IP address, the
DNS cache is updated without any DNS request.
• True (default value): The existing procedure applies

352/915     


 !"  



Support UTF8 characters set
CSTA User-to-User supported
DDI destination number
Video Support Profile
Trusted From header
Support Re-Invite without SDP
   
 !"  

As of R11.2, this parameter is used in SIP for UFT8:
• No (default value): For incoming calls, a Latin name
(trunk name) is always associated to the UTF8 non
Latin name received, to be able to handle the case
where the receiver doesn’t support UTF8.
UTF8 is fully handled for basic calls and call transfer
• Yes: The UFT8 supports characters set
• NO (default value): any Global Call ID or Correlator
Data received at the gateway side from OmniPCX
Enterprise or SIP remote party is ignored.
• YES: any Global Call ID or Correlator Data received
at the gateway side, either from OmniPCX Enter-
prise or SIP remote party is relayed to the opposite
side.
As of R11.2, this parameter applies to inbound calls:
• ReqURI (default value): The "Request URI" is used
to build the called number (normal procedure)
• To: The To is used to build the called number
For more information, see: Video over IP - Video on
public and private SIP trunking
Define if the header From, received from the SIP carrier,
is trusted or not:
• False (default value): The header is considered as
not trusted
• True: The header is considered as trusted
The From header is not used when the P-Asserted-ID
header is provided by the SIP carrier.
The From header is used only when the P-Asserted-ID
header is not provided by the SIP carrier. In this case,
the P-Asserted-ID in Caling number parameter and
the Trusted P-Asserted-ID header parameter, associ-
ated to the P-Asserted-ID header, are not used.
The Trusted From header parameter is used for applic-
ations, such as DISA, which may require additional au-
thentication.
As of R10.1, this parameter only applies when the PCX
sends RE-INVITE messages to the SIP-ISDN carrier
during transfer (see: SIP Trunking - Detailed description
- RE-INVITE messages sent by the PCX ):
• False: The PCX sends RE-INVITE messages to the
SIP carrier with SDP. In this case, the PCX provides
the coding algorithm in the SDP part of the RE-
INVITE message
In R10.1, False is the default value.
• True: The PCX sends RE-INVITE messages to the
SIP carrier without SDP. When this occurs, the SIP
carrier must support RE-INVITE messages without
SDP. In this case, the SIP carrier is in charge of
providing an SDP offer
As of R11.0, True is the default value.

 353/915
Chapter 6 

Type of codec negotiation
Select the type of negotiation used to build the codec of-
fer:
• Default (default value)
The codec offer contains G711 and G729 in the or-
der defined by the calling domain
• From domain
The codec offer only contains the codecs allowed by
the calling domain
• Single codec G711
The codec offer only contains G711
• Single codec G729
The codec offer only contains G729
For database translation from R10.x to R11.0 see: fig-
ure: Translation from R10.x to R11.0 for the Type of co-
dec negotiation parameter

3. Confirm your entries

Note 10:
The value for the parameter: Type of codec negotiation, after database translation from R10.x to
R11.0, depends on:
- The gateway type
- The type of the trunk group leading to the gateway
- The parameter IP Compression Type for this trunk group (not available anymore in R11.0)
- The parameter Send only trunk group algo for the gateway (not available anymore in R11.0)
The following diagram shows database translation for the parameter: Type of codec negotiation:

354/915     


 !"  
 
 

Figure 6.149: Translation from R10.x to R11.0 for the Type of codec negotiation parameter

6.3.4.7 Configuring the topology type for enhanced codec negotiation

As of R11.1, the enhanced codec negotiation feature requires the configuration of the topology
type.
1. Select: System > Other System Param.> SIP parameters
2. Review/modify the following attribute:
Enhanced codec negotiation Select your topology:
• Local Type: Select this option when your node is
not included in an ABC network.
• Network Type: Select this option when your node is
included in an ABC network.

3. Confirm your entry

6.3.5 SIP Trunking Configuration Examples

6.3.5.1 External Gateway
A SIP external gateway allows a group of sets or external network to be reached via SIP.
Access to an external gateway may be via a routing number or via ARS.
The following example shows two gateways:

    

 !"  
  355/915
Chapter 6 

- Gateway 2 is used to access a group of sets with numbers in the form 33xx: in this case, a
routing number is used.
- Gateway 3 allows the public network to be accessed: in this case, ARS is used.

Figure 6.150: Configuration with External Gateway

6.3.5.1.1 Configuration of External Gateway 2 with Routing Number

Configuration consists in:
1. Selecting a network dedicated to the gateway.
2. Creating a SIP trunk group for this gateway
3. Creating the gateway.
4. Creating a routing number to access sets located behind the gateway.
Network Dedicated to the External Gateway
Select: Translator > Network Routing Table
Network Number 2
Rank of First Digit to be Sent 1
Incoming identification prefix 1
Protocol Type ABC-F
Numbering Plan Descriptor ID 11
ARS Route list 3
Schedule number -1
ATM Address Id -1
Network call prefix --------
City/Town Name --------
Send City/Town Name False

356/915     


 !"  
 
 

Associated Ext SIP gateway 2

Enable UTF8 name sending True

Note:
In this example, an open numbering plan can not be used (Rank of First Digit to be Sent = 1).

SIP Trunk Group Configuration

Select: Trunk Groups
Trunk Group Id 25
Trunk Group Type T2
Trunk Group Name sip25
Remote Network 2
Q931 signal variant ABC-F
T2 Specification SIP
Overlap dialing NO

Gateway Configuration
Select: SIP > SIP Ext Gateway
SIP External Gateway ID 2
Gateway name Ext Gateway 2
SIP Remote domain 10.20.22.61
PCS IP Address
SIP Port Number 5060
SIP Transport Type + TCP TCP
RFC3262 forced use False
Belonging domain --------------------
Registration Id
Registration IP in P_Asserted False
Registration timer 0
SIP Outbound Proxy
Supervision timer 0
Trunk group number : 25
Pool Number : -1
Outgoing Realm SanTheodor
Outgoing username userOXE
Outgoing Password *******
Confirm *******
Incoming username alkazar

    

 !"  
  357/915
Chapter 6 

Incoming Password *******

Confirm *******
RFC 3325 supported by the dis- True
tant
DNS type DNS A
SIP DNS1 IP Address
SIP DNS2 IP Address
SDP in 18x True
Minimal authentication method SIP Digest
INFO method for remote exten- False
sion
Dynamic Payload type for DTMF 97
Type of codec negotiation Default

In this example, the remote gateway authentication realm is “SanTheodor”.

For incoming calls (from the external gateway to the Communication Server), they authenticate
themselves with the name and password for the Communication Server (ALE International
PCX) authentication realm: Incoming username and Incoming password parameters.
Routing Number to the Gateway
Select Translator > Prefix Plan
Number 33
Prefix Meaning Routing No.
Network Number 2
Node Number/ABC-F Trunk Group 25
Number of Digits 4
Number With Subaddress (ISDN) NO
Default X25 Id.pref. NO

6.3.5.1.2 Configuration of Gateway 3 with ARS

In this example, the remote gateway is used to access a remote SIP carrier.
On the remote gateway, the public network access prefix is 83.
On the local node, the ARS seize prefix is 023. Via discrimination, this prefix is associated with
an ARS route list whose first route takes the SIP trunk group (26). The dialing command table
associated with this route converts the number 023xxxxxxxxxx to 83xxxxxxxxxx and routes the
call to external gateway No. 3.
Configuration consists of the following steps:
1. Selecting a network dedicated to the gateway.
2. Creating a SIP trunk group for this gateway
3. Creating the gateway.
4. Configuring a dialing command table pointing to the gateway.

358/915     


 !"  
 
 

5. Creating an ARS route list with a route using the SIP trunk group and the previously
created dialing command table.
6. Creating the time-based route list
7. Configuring restrictions (discrimination)
8. Associating the system discriminator with the entity discriminator
9. Creating the ARS prefix.
Note:
When ARS is used with either ABC-F SIP or ISDN SIP trunk groups, it is mandatory to use the [I]nsert
command in the DCT of the ARS.

Network Dedicated to the External Gateway

Select Translator > Network Routing Table
Network Numbe 3
Rank of First Digit to be Sent 1
Incoming identification prefix ---------------------
Protocol Type ABC-F
Numbering Plan Descriptor ID 11
ARS Route list 0
Schedule number -1
ATM Address Id -1
Network call prefix -----------------------------------
City/Town Name ---------------------------------------
Send City/Town Name False
Associated Ext SIP gateway 3
Enable UTF8 name sending True

SIP Trunk Group Configuration

Select: Trunk Groups
Trunk Group Id 26
Trunk Group Type T2
Trunk Group Name sip26
Remote Network 3
Q931 signal variant ISDN all countries
T2 Specification SIP
Overlap dialing NO

Note:
When ARS is used with either ABC-F SIP or ISDN SIP trunk groups, it is mandatory to use the [I]nsert
command in the DCT of the ARS.

    

 !"  
  359/915
Chapter 6 

Gateway Configuration
Select SIP > SIP Ext Gateway
SIP External Gateway ID 3
Gateway name Ext Gateway 3
SIP Remote domain 10.20.22.61
PCS IP Address
SIP Port number 5060
SIP Transport type TCP
RFC3262 forced use False
Belonging domain LocalDomain
Registration Id +33155667000
Registration IP in P_Asserted False
Registration timer 0
SIP Outbound Proxy sipcarrier@there.com
Supervision timer 1800
Trunk group number 26
Pool Number -1
Outgoing realm syldavie
Outgoing username userOXE
Outgoing Password *******
Confirm *******
Incoming username ottokar
Incoming Password : *******
Confirm *******
RFC 3325 supported by the dis- True
tant
DNS type DNS A
SIP DNS1 IP Address
SIP DNS2 IP Address
SDP in 18x True
Minimal authentication method SIP Digest
INFO method for remote exten- False
sion
Dynamic Payload type for DTMF 97
Type of codec negotiation From domain

In this example, the remote gateway authentication realm is “syldavie”.

Calls leaving the Communication Server for the gateway authenticate themselves on the
external gateway with the name and password for this realm: Outgoing username and

360/915     


 !"  
 
 

Outgoing password parameters.

For incoming calls (from the external gateway to the Communication Server), they authenticate
themselves with the name and password for the Communication Server (ALE International
PCX) authentication realm: Incoming username and Incoming password parameters.
Dialing Command Table
Select Translator > Automatic Route Selection > Numbering Command Table
Table Id 3
Carrier Reference 3
Command A83I
Associated Ext SIP gateway 3

Note:
The carrier number entered here is only used for accounting: This number will be shown on call records
for calls to the external gateway.

ARS Route List

Select Translator > Automatic Route Selection > ARS Route list > ARS Route
ARS Route list 3
Route 1
Name GW_SIP
Trunk Group 26
No.Digits To Be Removed 0
Digits To Add --------------------------------------
Numbering Command Tabl. ID 3
VPN Cost Limit 0
Protocol Type Dependant on Trunk Group Type
NPD identifier 255
Route Type Public
ATM Address Id -1
Preempter False
Quality
[ Add ] [ Remove ] [ Next ] [Previous]
Quality Speech

Time-Based Route List

Select Translator > Automatic Route Selection > ARS Route list > Time-based Route List
ARS Route list 3
Time-based Route List ID 1

    

 !"  
  361/915
Chapter 6 

Time-based Route
[ Add ] [ Remove ] [ Next ] [Previous]
Time-based Route
Route Number 1
Waiting Cost Limit -1
Stopping Cost Limit -1

Call Restrictions - Barring (Discrimination)

Restriction (discrimination) configuration for 01xxxxxxxx numbers is given below.
Select Translator > External Numbering Plan > Numbering Discriminator > Discriminator
Rule
Discriminator No. 3
Call Number 01
Area Number 1
ARS Route List Number 3
Schedule Number -1
Number of Digits 10

Discriminator Selector
Select Entities > Discriminator Selector
Discriminator 00 0
Discriminator 01 1
Discriminator 02 0
Discriminator 03 3
Discriminator 04 0
Discriminator 05 0
Discriminator 06 0
Discriminator 07 0

ARS Prefix
Select Translator > Prefix Plan
Number 023
Prefix Meaning ARS Prof.Trg Grp Seizure
Discriminator No. 3

6.3.5.2 SIP Trunk Group

6.3.5.2.1 ISDN Mode

362/915     


 !"  
 
 

Following the information provided by the SIP carrier, the DNS domain associated with the
fields Remote domain and Belonging domain of the external SIP gateway can be identical.
To better understand the examples presented in this section, see the below two figures.

Figure 6.151: Configuration Example of an ISDN SIP Trunk Group

Figure 6.152: ISDN Mode of a SIP Trunk Group

SIP Gateway

... .
Subnetwork number 9

    

 !"  
  363/915
Chapter 6 

Trunk Group 29
IP Address 192.168.4.52
Machine name OXE
... .
DNS local domain name my-company.com
... .
First DNS IP Address 10.15.1.3
... .

SIP Ext Gateway

Instance (reserved) 124

SIP Remote domain isp-gateway.my-isp.com
... .
Belonging domain OXE.my-company.com
... .
Trunk group number 124
... .

Trunk Groups (global)

Trunk Group Id 124

Trunk Group Type T2
Trunk Group Name SIP_pub_24
... .
Node number 22
... .
Q931 signal variant ISDN all countries
... .
T2 Specificity SIP
... .

Trunk Groups (local)

... .
Entity Number 1
... .
Nb of digits unused (ISDN) 8
... .

Virtual access for SIP

364/915     


 !"  
 
 

... .
Number of SIP Access 2

Trunk Group NPD Selector

Public NPD id 29
... .

Prefix Plan

Number #1
Prefix Meaning ARS Prof.Trg Grp Seizure
Discriminator No. 3

Entities

Discriminator 00 0
Entity Number 1
Name Entity_N0
Installation No (ISDN) 012010
Supplement.Install.No (ISDN) 1000
...
Discriminator 03 124

Numbering Discriminator

Discriminator Nr 124
Name Discri_SIP_pub_24
Call Number 4
Area Number 1
ARS Route List Number 124
Number of Digits 10

ARS Route List

ARS Route list 1234

Name ARS_SIP_pub_24
Route 1
Name SIP_TG_124
... .
Trunk Group 124
... .

    

 !"  
  365/915
Chapter 6 

Numbering Command Tabl.Id 4

... .
NPD identifier 42
... .
Quality Speech

Numbering Command Table

... .
Table Id 4
Carrier Reference 4
... .
Associated Ext SIP gateway 124

Numbering Plan Description (NPD)

Description identifier 42
Name NPD_SIP_pub_24
Calling Numbering plan ident. NPI/TON Isdn National
Called numbering plan ident. NPI/TON Isdn National
... .
Install. number source Entity source
Default number source Entity source
... .
Description identifier 29
... .
Calling Numbering plan ident. NPI/TON Isdn National
Called numbering plan ident. NPI/TON Isdn National
Install. number source Entity source
Default number source Entity source

Signalling String (System)

Country Code
... .
Country Code 39

Prefix Plan

Number 2395
... .

366/915     


 !"  
 
 

Local Features Pabx address in DPNSS

6.3.5.2.2 ABC-F Mode

Following the information provided by the client, the DNS domain associated with the fields
Remote domain and Belonging domain of the external SIP gateway can be identical.
To better understand the examples presented in this section, see the below two figures.

Figure 6.153: Configuration Example of an ABC-F SIP Trunk Group

    

 !"  
  367/915
Chapter 6 

Figure 6.154: ABC-F Mode of a SIP Trunk Group (Routing and ARS Prefixes)

SIP Gateway

Subnetwork number 9
Trunk Group 29
IP Address 192.168.4.52
Machine name OXE
... .
DNS local domain name local-site.com
First DNS IP Address 10.15.1.3
... .

SIP Ext Gateway

368/915     


 !"  
 
 

Instance (reserved) 224

SIP Remote domain remote-gateway.remote-site.com
... .
Belonging domain OXE.local-site.com
... .
Trunk group number 124
... .

Trunk Groups (Global)

Trunk Group Id 224

Trunk Group Type T2
Trunk Group Name SIP_priv24
... .
Remote Network 4
... .
Node number 22
... .
Q931 signal variant : ABC-F
... .
T2 Specificity SIP
... .

Trunk Groups (Local)

... .
Entity Number 1
... .

Virtual access for SIP

Number of SIP Access 2

Trunk Group NPD Selector

Public NPD id 2
...

Prefix Plan

Number #2
Prefix Meaning ARS Prof.Trg Grp Seizure

    

 !"  
  369/915
Chapter 6 

Discriminator Nr. 4

Entities

Entity Number 1
Name Entity_N0
Installation No (ISDN) 012010
Supplement.Install.No (ISDN) 1000
... .
Discriminator 04 224

Numbering Discriminator

Discriminator Nr. 224

Name Discri_SIP_priv_24
Discriminator Rule
Call Number 02
Area Number 1
ARS Route List Number 224
Number of Digits 5

ARS Route List

ARS Route list 224

Name ARS_SIP_priv_24
Route 1
Name SIP_TG_224
... .
Trunk Group 224
Nb.Digits To Be Removed 1
... .
Numbering Command Tabl.Id 14
... .
NPD identifier 44
... .
Quality Speech
... .

Numbering Command Table

370/915     


 !"  
 
 

Table Id 14
Carrier Reference 0
Command I
Associated Ext SIP gateway 224

Numbering Plan Description (NPD)

Description identifier 44
Name NPD_SIP_priv_24
Calling Numbering plan ident. Unknown
Called numbering plan ident. Unknown
... .
Install. number source NPD source
Default number source NPD source
... .
Description identifier 2
... .
Calling Numbering plan ident. Unknown
Called numbering plan ident Unknown
Install. number source Entity source
Default number source Entity source

Signalling String (System)

Country Code
... .
Country Code 39

Prefix Plan

Number 2395
... .
Local Features Pabx address in DPNSS

Prefix Plan

Number 24
Prefix Meaning Routing No.
Network Number 4
Node Number/ABC-F Trunk 224
Group

    

 !"  
  371/915
Chapter 6 

Number of Digits 6

Network Routing Table

Network Number 4
Rank of First Digit to be Sent 3
... .
Associated SIP gateway 224

Ext.Callback Translation

Basic Number B
Nb.Digits To Be Removed 1
... .

6.4 Video on public and private SIP trunking

As of R11.2, the OmniPCX Enterprise allows video to transit over two SIP trunks.

6.4.1 Supported topologies

- Local configurations
Video is received by an ISDN or an ABC-F gateway and relayed to an ABC-F or ISDN
gateway on the same node.
Basic calls can carry video information. On demand video and transfers can embed video
information.
The typical case is for an OpenTouch user (with an OpenTouch device) going through the
OmniPCX Enterprise to establish a video communication with a SIP carrier.
If an OmniPCX Enterprise or OmniPCX Enterprise node is in a release prior to R11.2, it
cannot transmit video from or to the SIP carrier.

- Network configurations
Video is received by an ISDN or an ABC-F gateway and relayed through the network to an
ABC-F or ISDN gateway.
• One OpenTouch user calls another OpenTouch user through the OmniPCX
Enterprises. Video can be established between them. The ABC-F OmniPCX Enterprise
network carries video information.

372/915     


 !"  
 
 

• When the OpenTouch and the SIP ISDN trunk are not on the same node, the ABC-F
OmniPCX Enterprise network carries video information

• Other PBXs (for example, the OmniPCX Office or a Cisco or Avaya system) can be
interconnected via the OmniPCX Enterprise using the SIP ABC-F transit feature

• If the OpenTouch device, sending or receiving video, is a SIP device, all the above
topologies are supported

    

 !"  
  373/915
Chapter 6 

6.4.2 Process overview

6.4.2.1 SIP offer and answer / Fast update
6.4.2.1.1 Video negotiation
Video may be negotiated through any SDP offer (INVITE, UPDATE, RE-INVITE & 200.OK - in
case of INVITE or RE-INVITE without SDP).
The answer is relayed in the messages: 180.Ringing, 183.Session Progress, 200.OK or
ACK.
Video negotiation of video is performed for basic call and for all call evolution resulting to a SIP
to SIP call.
Note:
In any case, the video Offer / Answer mechanism remains in charge of end users. In other words, the
system is transparent regarding video transit.

6.4.2.1.2 SIP INFO request – Fast Update / RFC 5168

XML content in INFO message, the so-called “fast update” mechanism, as defined in RFC
5168, is transparently carried through the OmniPCX Enterprise.
6.4.2.2 Session Border Controller (SBC)
In a topology where an SBC acts as RTP proxy between the OmniPCX Enterprise and the SIP
carrier or end point, this SBC must process video as it processes voice. In addition, the SBC
must remain transparent to the various m lines in the messages, different from video (such as
control or application).

6.4.3 Configuring SIP video transit

6.4.3.1 Video basic configuration
To enable the feature:
1. Select System > Other System Param. > SIP parameters
2. Review/modify the following attribute:
SIP video transit mode According to your needs, select:
• Not available (default value): No video is offered on
this node
• Local: Video can be negotiated locally on this node
• Network: Video can be negotiated locally and in an
ABC-F network (provided all nodes are in R11.2 (or
later version)
Any modification of this value requires a reboot to create
or update the internal table used to store the video in-
formation.
Enhanced codec negotiation This attribute interacts with the former, as detailed in ta-
ble: Multi-codec compatibility table

374/915     


 !"  
 
 

table 6.132: Multi-codec compatibility table

Enhanced co- Not available Local Network
dec negoti-
ation
SIP Video
transit mode
Not available No Multi-codec Multi-codec: local Multi-codec: net-
No video No video work + local
No video
Local Not allowed Multi-codec: local Multi-codec: net-
Video: local work + local
Video: local
Network Not allowed Not allowed Multi-codec: net-
work + local
Video: network +
local

3. Confirm your entry

4. Select: IP > IP Domains > Video Extra Domain
5. Review/modify the following attribute:
Video Extra Domain According to your needs, select:
• Yes: Direct and on demand video calls are allowed
• No: Video is not taken into account for "direct" calls
(voice remains available), while “On demand” video
is rejected with the message: 488.Not Acceptable
Here.

6. Confirm your entry

7. Select SIP > SIP Ext Gateway
8. Review/modify the following attribute:
Video Support Profile
According to your needs, select:
• Not supported (default value): No video is offered
on this gateway
• On demand: Video is negotiated after establishment
of the call (in the RE-INVITE). The INVITE does not
contain video.
• Unrestricted: Video can be negotiated in basic call
as well as after call evolution

9. Confirm your entry

6.4.3.2 Configuring SIP devices
1. Select Users
2. Select the user with the SIP device to configure
3. Review/modify the following attribute:

    

 !"  
  375/915
Chapter 6 

Video Support Profile According to your needs, select:

• Not supported (default value): No video is offered
on this SIP device
• On demand: Video is negotiated after establishment
of the call (in the RE-INVITE part of the message).
The INVITE does not contain video.
• Unrestricted: Video can be negotiated in basic calls
as well as after call evolution

4. Confirm your entry

6.4.3.3 Private SIP transit mode and CAC SIP-SIP interaction
This paragraph only applies to some configurations with transit SIP-ABCF/SIP-ABCF.
1. Select System > Other System Param. > SIP parameters
2. Review/modify the following attribute:
Private SIP transit mode This attribute interacts with the attribute Cac SIP-SIP, as
detailed in table: Private SIP transit mode/Cac SIP-SIP
compatibility table

table 6.137: Private SIP transit mode/Cac SIP-SIP compatibility table

Private SIP Proxy or redirect mode Full Call Handling mode
transit mode Mixed mode
CAC SIP-SIP
True Only Direct Video calls are Direct and On Demand
available through the proxy Video calls are available
through Call handling
False Direct and On Demand Direct and On Demand
Video calls are available Video calls are available
through the proxy through Call handling

Note:
In Full Call Handling mode, Intra Domain Video calls are allowed without any restrictions.
For Extra Domain calls, the Video Extra Domain parameter from the IP domains is taken into
account: see Video basic configuration
3. Confirm your entry

6.4.4 Restrictions
- CAC does not apply to video and remains dedicated to voice traffic
- A call which begins by the reception of an INVITE without SDP cannot result in a video call
- Video is not available
• For SIP Extensions
• For remote extensions behind SIP
• For SIP Nomadic
• For an ABC-F Trunk Group over IP

376/915     


 !"  
 
 

- Metering tickets cannot provide any information about video

6.4.5 Maintenance
Several maintenance commands are available for this feature:
- sipextgw: indicates the status of SIP external gateways on the system
sipextgw -h (help)
sipextgw -l (list of available external gateways)
sipextgw -g <external gateway number range 0..999>
sipextgw -s <external gateway number range 0..999>
sipextgw -invite (displays the list of invites to re-send)
sipextgw -invite -delete (deletes the list of invites to re-send)
- zdjonct:
zdjonct <n neqt-number (0-31169)>
zdjonct <d directory-number [1..8]>
zdjonct <p crist-nb cpl-nb access-us-nb term-nb>
zdjonct <p crist-nb cpl-nb access-us-nb a for all
- mtracer: to activate traces when SIP is active
- videoview: displays call handling video table information, including:
• Current index
• Owner piece of equipment number
• First associated piece of equipment number
• Second associated piece of equipment number
• Third associated piece of equipment number
• SIP event
• Offer/Answer current status
• Date/time
• Active 1/2 com
• A dedicated option allows to delete one or all entries in the table

    

 !"  
  377/915