Alcatel-Lucent Omnipcx Enterprise: R9.1 Sip Newness

Alcatel-Lucent OmniPCX Enterprise
R9.1 SIP Newness
All Rights Reserved © 2009, Alcatel-Lucent 1
OBJECTIVE
To describe the new SIP features of the release R9.1
Alcatel-Lucent OmniPCX Enterprise – R9.1 SIP Newness

Ref. ENTP0400P14TEUS Issue 02
SEPLOS Keep alive mechanism
The purpose of this feature is to create a supervision of the device in order to

know if it’s state is in/out of service
The SIP extension must be able to send “options” messages
There are new parameters in the CS
z SIP extension COS
A Keep alive flag in order to authorize or to forbid the service
z IP QOS COS (specified within the IP domain)
Keep alive timer

SIP lost timer

SEPLOS Keep alive mechanism
(Cont’)
The timer and the destination of keep alive messages must be setup within
each SEPLOS device
z There is no interaction between the CS management and the setup of these
generic devices
z Enter the “keepalive timer” in the “NatKeepAliveTimer” field
z Enter the CS IP@ of FQDN in the “NatkeepAliveDest” field
If the CS do not receive the keep alive by the end of “the Keepalive + SIP lost”
timers it considers the SEPLOS device out of service
z If a “keep alive” is received before the end of the registration leased time
the set is switched back in service otherwise it must register again
The Keep alive timer service is also working with the PCS
z In the SEPLOS device, the PCS is specified as the backup proxy
z In case of CS failure, the SEPLOS device registers and starts to send the
option messages to the active PCS

SEPLOS Keep alive
Management of CS
SIP extension
z Phone classes of service
Keep alive : Yes/No
IP
z IP Domain (“0” for example)
IP Quality of Service : 0
IP
z IP Quality of Service (“0” for example)
SIP lost :5
SIP keep alive : 30
The values are in seconds
For the sets that cannot send the keep alive, a COS must be used with the keep alive set to no
The keep alive timer must be managed with the same value in the QOS COS as in the SIP set because this information is not
exchanged !

SEPLOS Keep alive
Management of Thomson ST2030
The “telnet” service must be validated

SEPLOS Keep alive
Management of Thomson ST2030 (Cont’)
Then a telnet session must be opened on the set in order to be able to specify
the keep alive timer value and the CS IP address (destination)
C:\>telnet 157.1.1.157
*******************************************
** IP Phone firmware V1.64 **
** Compiled on Sep 24 2008 at 10:04:42 **
** IP Phone VPD1020-D49(S) **
*******************************************
Login: administrator
Password : ******
[administrator]#
[administrator]#sip set NatkeppaliveTimer 30
[administrator]#sip set NatkeepaliveDest 157.1.1.3
As of the SIP Device Manager release 1.2, these values can be set up and taken
into account automatically (without any telnet session)
The default password for a telnet session is : 789234 (784518 is used for a HTTP session)
To apply changes, type “commit”, then “ activate”

SEPLOS Keep alive
Maintenance
csipsets
+-----+--------+----------------+---------------+-----+
|Neqt |Number |Name |IP address |State|
+-----+--------+----------------+---------------+-----+
|00607|31900 |SIP Tele tra | Unused| HS |
|00608|31901 |Thomson2030 | 157.1.1.157| ES |
+-----+--------+----------------+---------------+-----+
|Number of SIP extensions: 00002 |
+-----------------------------------------------------+
tradna
(101)communn1r1> tradna 31900
Wed Jun 24 15:02:31 CEST 2009
Logic coupler type : CPL_UA

MAO coupler type : UA_FICTIF
Coupler state : IN SERVICE
Terminal state : OUT OF SERVICE
+-----------------------------------------------------------------------------+
| Cry:Cpl:ac:term | neqt |nulog| typ term | dir nb | Out of service cause |
+-----------------------------------------------------------------------------+
| 002 0 0 10 | 00607 | 3| SIP| 31900 | A . I . . . . . . . |
+-----------------------------------------------------------------------------+
| A: att_mserv, C: hs_defich, I: hs_isolauto, X: hs_isolman, T: hs_terdef |
| U: hs_usdef, P: hs_errparite, B: hs_bascul, Y: hs_cristisol, N: hs_inex |
+-----------------------------------------------------------------------------+
HS: out of service

ES: in service

SEPLOS Keep alive
Maintenance (Cont’)
listerm (on the virtual UA board used for IP devices)
Wed Jun 24 15:04:53 CEST 2009
-------------------------------------------------------------------------
|Coupler: 2 0 Logic type: CPL_UA Board:UA_FICT State: IN SERVICE |
|-------------------------------------------------------------------------|
| Cry:Cpl:ac:term| neqt | typ term | dir nb | Out of service cause |
|-------------------------------------------------------------------------|
| 2 0 0 0 | 00597 | POS_NUM | REG | . . . . . . . . . . |
| 2 0 0 1 | 00598 | POS_NUM | REG | . . . . . . . . . . |
| 2 0 0 2 | 00599 | POS_NUM | REG | . . . . . . . . . . |
| 2 0 0 3 | 00600 | POS_NUM | REG | . . . . . . . . . . |
| 2 0 0 4 | 00601 | POS_NUM | REG | . . . . . . . . . . |
| 2 0 0 5 | 00602 | POS_NUM | REG | . . . . . . . . . . |
| 2 0 0 6 | 00603 | POS_NUM | REG | . . . . . . . . . . |
| 2 0 0 7 | 00604 | POS_NUM | REG | . . . . . . . . . . |
| 2 0 0 8 | 00605 | IPT 4068 | 31068 | . . . . . . . . . . |
| 2 0 0 9 | 00606 | IPT 4038 | 31038 | A . . . . . . . . . |
| 2 0 0 10 | 00607 | SIP | 31900 | A . I . . . . . . . |
| 2 0 0 11 | 00608 | SIP | 31901 | . . . . . . . . . . |

History Info (RFC 4244)
External Gateways
The purpose of this feature is to add the “History-Info” header in the Invite
message for SIP External gateways, SIP Voice mails
The RFC4244 defines a standard mechanism for capturing the history

information associated with a SIP request
Invite:
AAPP
<From: Poste A>
SIP Voicemail
<History-info: Called B – Cause: Immediat Forwarding>
SIP Externe Gateway

(Public Operator)
Extension A
Extension B
(Forwarded to an equipment / SIP)
This capability enables many enhanced services by providing more information

about a call
In case of External voicemail, the History info can be used to reach the right

External Gateways (Cont’)
The RFC4244 defines a new optional SIP header, “History-Info”, for sending the history
information in requests
When the Call is forwarded from CS to Sip External gateway, the History-Info header is
added in SIP Invite message, which contains the initial Called User information
The History Info header contains Targeted-To-URI, cause parameter and index parameter
z The Targeted-To-URI contains the Called User SIP URI
z The Index parameter contains the chronological order of the information

In OXE case the index parameter is always set to 1
z The cause parameter contains the forward reason
The CS will specify the cause

{ 302 for Immediate /Unconditional Forward
{ 486 for Forward on Busy
{ 480 for Forward on no reply

External Gateways (Cont’)
In case of forwarding
z The “Invite” and “To” URI are different

The “Invite” URI is the final destination
{ The directory N° used for the forwarding
The “To” URI is the original called set
z The “Cause” field indicates the reason of forward
In case of remote extension
z Both “Invite” and “To” URI are equal

The “Invite” URI is the public N°
The “To” URI is also the public N°
z There is no “Cause” field because it is not a forwarding

External Gateways - Restrictions
This feature is not implemented for SEPLOS
If the CS receives History-Info header in any of the SIP Requests, it will ignore
the header
When the CS is in transit case
z When a call is established between two different external SIP entities/

gateways via the CS, the same “History-Info” header will not be added in
outgoing message for destination SIP entity
For example, a simple call is established from SIP External Gateway to OXO via CS
{ The CS will always add only one History-Info entry in INVITE Request
{ For Multiple forwarding cases, the History-Info header contains the last forwarded user
information
So the index parameter is always set to 1

“History Info” (RFC 4244)
External Gateways (Cont’) - Configuration
In order to send the initial calling user Id (instead of the forwarded set Id)
manage:
z /System / Other System Parameters/ External Signaling Parameters
NPD for external forward: specify an already created NDP
{ The given NPD is not really used but only activates the feature (the NPD selected via the
ARS will be really used to setup the “Calling Number”)
To insert the “History” info in the “INVITE” message, the following field has to
be set up:
z /Trunk Groups/ Trunk Group
IE External Forward: Diverting_LEG_INFO
Situation: the user 31000 calls the user 31500 who is forwarded to tan external number “998837000”
Example of an “INVITE” message « INVITE » via an external SIP Gateway
1255676240 -> SEND MESSAGE TO NETWORK (171.1.1.3:5060 [UDP]) (BUFF LEN = 1195)
----------------------utf8-----------------------
INVITE sip:+998837000@171.1.1.3;user=phone SIP/2.0
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, SUBSCRIBE, OPTIONS, UPDATE
Supported: replaces,timer,100rel
User-Agent: OmniPCX Enterprise R9.1 i1.605.3
Session-Expires: 1800;refresher=uac
Min-SE: 900
P-Asserted-Identity: "noe 4039 ACT 0" <sip:+2981431000@151.1.1.103>
History-Info: <sip:2981431500@151.1.1.103?reason=SIP%3bcause%3d302%3btext%3d%22M
oved%20Temporarily%22>;index=1,sip:+998837000@171.1.1.3;index=1.1
Content-Type: application/sdp
To: <sip:2981431500@151.1.1.103;user=phone>
From: "noe 4039 ACT 0" <sip:+2981431000@151.1.1.103>;tag=3256c741df91b8ce456adb0
411abed8b

SEPLOS Call Server Information display
A SIP MESSAGE can be sent to the SEPLOS device in order to inform the user
about the CS settings
Forward activation
Do not disturb activation
Remote extension deactivation
Hunting group belonging
Appointment or wake-up programmed
Lock activation
There is a new SIP method called “Message”

A message is sent for display with an information link with the activated feature
If the terminal is not compatible with the “Message” method it does not take
into account the message and reject the method with a message “405: method
not allowed”
Accents a specific letters

By default the OXE provides UTF-8 coded letters for display. According to the set
compatibility, it may be required to de-activate this feature for a better display
1) Management object: SIP Extension/Class of service: “Display UTF-8: No”

With a compatible terminal
DND activation
SEPLOS CS
Invite (DND prefix)
100 Trying
(1)
183 Session progress
Message : “Do not disturb activated”
200 OK
1) In addition to the “183 Session Progress” message, the OXE connects the SEPLOS terminal to the corresponding feature voice guide
Via the SIP “Message” method the OXE sends a “Do Not disturb activated” message in order to display this information on the screen of
the terminal.
The SEPLOS terminal must be compatible with this “Message” method otherwise it will be rejected without any effect on the feature
itself that will be activated anyway.
Remark:
The secret code is sent to a DTMF receiver (via a RTP flow)

DND de-activation
SEPLOS CS
Invite (DND prefix)
100 Trying
Message : “”
200 OK
The SIP method “Message” sends an empty message in order to cancel the displayed information sent previously.

Forwarding activation
SEPLOS CS
Invite (Forwarding on busy prefix)
100 Trying
Message : “Frwrd on busy Æ 31000”
200 OK
Remark:
The destination number is sent to a DTMF receiver (via a RTP flow)

Forwarding de-activation
SEPLOS CS
Invite (Forwarding cancellation prefix)
100 Trying
Message : “”
200 OK

Hunting group entry
SEPLOS CS
Invite (Hunting group entry prefix)
100 Trying
Message : “You are in the group”
200 OK

Hunting group exit
SEPLOS CS
Invite (Hunting group exit prefix)
100 Trying
Message : “You are out of group”
200 OK

Hunting group entry and DND activation
SEPLOS CS
Invite (Hunting group entry prefix)
100 Trying
200 OK
Invite (DND prefix)
100 Trying
Message : “Do not disturb activated - You are in the group”
200 OK
It is possible to provide information about several features like DND validated when belonging to a hunting group for example

DND de-activation (Stay within the hunting group)
SEPLOS CS
Invite (DND prefix)
100 Trying
200 OK
When DND is cancelled the CS does not send an empty message but a message about the hunting group belonging
The CS checks the status of all of the features that requests a message in order to build the new message when a feature is de-
activated.

With an incompatible terminal
DND activation
SEPLOS CS
Invite (DND prefix)
100 Trying
Message : “Do not disturb validated”
405 Method not allowed
If the SIP device is not compatible with the “Message” method it sends a “405 Method not allowed” to the CS but anyway the feature is
taken into account, it’s only the display on the device that will not work.

SEPLOS Reason header (RFC 3326)
There is a new field called “Reason Header” that provides information about
the cause of call re-routing or rejected (Busy / Do not Disturb…)
z The RFC 3326 defines the field structure
The following values have been defined:
z SIP
Status code
{ RFC 3261 (Global SIP RFC)
z Q.850
Cause value in decimal
{ ITU-T Q.850
Q850 standard defines the cause of ISDN call rejection

SEPLOS Reason header (RFC 3326)
Example with Q850 cause
An incoming call from the public side generates an INVITE
When the public user release the call a CANCEL message is sent by the gateway
z This message contains the cause of the release (Q850 16)
Caller SIP GW Called
Setup
Invite
100 Trying
Release (16)
Cancel (Q.850 16)
200 OK

SIP: PRACK with SDP
The CS is able to
z Handle SIP PRACK Offer and Response with SDP
z Re-negotiate the codec if new offer SDP is received in PRACK
z Avoid sending new SDP offer in “200 OK” for “Invite” and send the SDP offer
in “Re-Invite” in case “PRACK” is required for the call
This feature is only available for SIP External gateways
z The CS will not send PRACK method to SEPLOS, SIP Devices, SIP Voice mails
and OTUC

SIP: Call Admission Control for FAX calls
The purpose of the Call Admission Control (CAC) is to control the number of IP
communications between IP telephony domains
z It takes into account the bandwidth limitation of the IP network
The CAC is working in the following way :

z Each IP domain defines the maximum number of voice connection
A call between two parties belonging to different IP domains is authorized only when this value
of CAC is not reached
When a voice communication is established between different IP domains, the value of the CAC
is incremented by 1 for both IP domains
z There is no control on calls between two parties belonging to the same domain
Many customers want to use G711 algorithm for FAX calls and G729/G723 algorithm for
Voice calls
z G711 needs more bandwidth that G72x
z This feature will help the customers to control the number of calls dynamically
z When there are FAX calls, the number of voice calls can be limited to less number
than no FAX call situation
This mechanism of controlling the bandwidth is possible for any other kind of equipment

(Cont’)
With this feature, IP domains can be configured so that two domains are
Tandem domains
The voice equipment are in a “Tandem primary IP domain” and the FAX are in a
“Tandem secondary IP domain”
z The two domains are linked together
z A factor is applied to the FAX calls

If the factor is 3 then each FAX call count for 3 voice calls in the CAC
z The maximum number of calls in the secondary IP domain defines the FAX
calls
This value cannot exceed the maximum number of calls of the primary IP domain
divided by the CAC factor

(Cont’)
Example:
z Domain 1 and Domain 2 are tandem domains
Intra and Extra algorithms of Domain 1 are G711 and G729 respectively
Intra and Extra Algorithms of Domain 2 are G711 and G711 respectively
z The configuration can be managed in order to authorize only 1 voice call

when there is a fax call and 3 voice calls if there is no FAX call

Management
/IP/IP Domain
z IP Domain N°: 1
Tandem Primary domain : -1

Domain Max Voice connection :6
z IP Domain N°: 2
Tandem Primary domain :1

Domain Max Voice connection :2
Tandem CAC Factor :3
Tandem Primary domain : -1 in case of Primary domain (Voice terminals) otherwise the value of the associated Primary IP domain in
case of secondary.
Tandem CAC Factor : Each time a FAX call is established, the CAC value of the primary domain is increased of this value (the CAC of
the secondary one is increased of 1).
Domain Max Voice connection : In the primary domain it is the maximum number of voice calls that can be established.
In the secondary domain it is the maximum number of FAX calls. A fax call count for a “tandem CAC factor” in the primary domain.
Example:
Primary IP domain 5
tandem primary domain : -1
domain max voice connection : 6
Secondary IP domain 6
tandem primary domain :5
domain max voice connection : 2
tandem CAC factor :3
It is possible to establish a maximum of 6 voice calls or of 2 fax calls or a combination of them.

A fax call = 3 voice calls in this example. So if there are 1 fax call established it is possible to establish 3 voice calls maximum.
In the opposite, if there are form 4 to 6 voice calls established, it is not possible to establish any FAX calls.

Maintenance
cnx dom
Wed Jun 24 14:54:11 CEST 2009
IP Domain
domain type : IP_R-> IP_REMOTE NIPR-> NO_IP_REMOTE
| number | 0 | 1 | 2 |
| type | NIPR | IP_R | IP_R |
| allowed | ffff | 6 | 2 |
| used | 0 | 0 | 0 |
| RIP Intr| G711 | G711 | G711 |
| RIP Extr| G711 | G723 | G711 |
| IPP Intr| G711 | G711 | G711 |

| IPP Extr| G711 | G723 | G711 |
| cac over| 0 | 0 | 0 |
| comp alw| 48 | 0 | 0 |
| comp use| 1 | 0 | 0 |
| comp fre| 23 | 0 | 0 |
| comp out| 24 | 0 | 0 |
| comp ovr| 0 | 0 | 0 |
| Tand PDm| -1 | -1 | 1 |
| Tand CAC| -1 | -1 | 3 |
Tand PDm : primary domain index

Tand CAC : value of the CAC for each call of this domain (CAC factor)

SEPLOS: “SIP/CSTA divert service”
The purpose of the feature “SEPLOS SIP/CSTA - Divert Service” is to provide the
“Divert” service over CSTA for SEPLOS
The typical case is to reroute the caller to a given number
z When a SEPLOS user receives a call it can send a CSTA “divert” service
request to the CS
This request provides the “divert destination”
z The CS releases the SIP call on the called extension and reroute the caller on
the new destination number

Mapping between ABC−F/ISDN causes and SIP responses
From the release 9.1 it is possible to manage the codes sent by the CS in case of
problem in case of ABCF/ISDN ÅÆ SIP exchanges
There are two new objects for this management
z SIP To CH Error Mapping (1)

Examples :
{ Not Found ÅÆ unallocated number
{ Address Incomplete ÅÆ invalid number format
{ Busy Here ÅÆ user busy
z CH To SIP Error Mapping (2)

Examples :
{ unallocated number ÅÆ Not Found
{ user busy ÅÆ Busy Here
{ invalid number format ÅÆ Address Incomplete
1) Mapping for corresponding messages from SIP to Call Handling (telephone application)
2) Mapping for corresponding messages from Call Handling to SIP (telephone application)

Mapping between ABC−F/ISDN causes and SIP responses
Management
SIP
z SIP to CH error mapping
SIP response : Not Found

ChCause : Unallocated Number(1)
…
SIP
z CH to SIP error mapping
ChCause : Unallocated Number

SIP response : Not Found(1)
…
1) The mapping can be modified
List of CH cause:
Unallocated number
User busy
No user responding
Call rejected
Invalid number format
Temporary failure
Bearer capability not implemented
Others
The list of SIP cause is much more important.

SIP: Contact Header – User part
Before the release 9.1, the user part was sent only in the “From” field
z Only the gateway ip address was sent in the “contact” field
FROM: <sip:11001@10.1.1.3> ; tag=00aaecc650e01974500c5a73de

Contact: <sip:10.1.1.3;transport=UDP>
For external gateways, as of the R9.1, the user part is sent in the “FROM” and
in the “Contact” fields
FROM: <sip:11001@10.1.1.3> ; tag=00aaecc650e01974500c5a73de

Contact: <sip:11001@10.1.1.3;transport=UDP>
Some carriers uses the user part in the “Contact” field for authentication and
routing
Example of Invite message:
1112864159 -> SEND MESSAGE TO NETWORK (171.1.1.3:5060 [UDP]) (BUFF LEN = 1071)
----------------------utf8-----------------------
INVITE sip:988637000@sbc.orange.fr SIP/2.0
Allow: INVITE, ACK, CANCEL, BYE, PRACK, NOTIFY, SUBSCRIBE, OPTIONS, UPDATE
Supported: replaces,timer,100rel
User-Agent: OmniPCX Enterprise R9.1 i1.605.14
Session-Expires: 1800;refresher=uac
Min-SE: 900
P-Asserted-Identity: "DuFour Jean" <sip:2014331000@node1.alcatel-lucent.com;user=phone>
Content-Type: application/sdp
To: sip:988637000@sbc.orange.fr
From: "DuFour Jean" <sip:2014331000@node1.alcatel-lucent.com;user=phone>;tag=531
76dbe5ce9f354e418a75df80f48f0
Call-ID: 5daf6ec876e782391898d312d90ed428@151.1.1.3
CSeq: 250642940 INVITE
Via: SIP/2.0/UDP 151.1.1.3;branch=z9hG4bKf08d858301fe6fdb5724d0a6c096cec9
Max-Forwards: 70
Content-Length: 312

Local users calls to SIP
Without “secret identity”
z Without spatial redundancy

FROM: <sip:11001@172.19.66.10 > ; tag=00aaecc650e01974500c5a73de
Contact: <sip:11001@172.19.66.10(1) ;transport=UDP>
z With spatial redundancy
FROM: <sip:11001@node1.spatialI1 > ; tag=00aaecc650e01974500c5a73de
Contact: <sip:11001@node1.spatialI1(2) ;transport=UDP>
With “secret identity”

FROM:sip:anonymous@anonymous.invalid;tag=00aaecc650e01974500c5a73de
FROM:sip:anonymous@anonymous.invalid;tag=00aaecc650e01974500c5a73de
Contact: <sip:11001@node1.spatialI1;transport=UDP>
1) IP@ of the CS
2) Host name and DNS local domain from the SIP gateway parameters

Trunk call to SIP
Without “secret identity”

FROM: <sip:12006@172.19.66.32>;tag=d8ce180b20403245d4cd85021
Contact: <sip:12006 (1) @172.19.66.32;transport=UDP>
FROM: <sip:12006@node1.spatialI1>;tag=d8ce180b20403245d4cd85021
With “secret identity”

FROM:sip:<SIP-ISDN@172.19.66.10>;tag=00aaecc650e01974500c5a73de
Contact: <sip:99405 (2) @172.19.66.10;transport=UDP>
FROM:sip:<SIP-ISDN@node1.spatialI1>;tag=00aaecc650e01974500c5a73de
1) Id of the public caller party
2) Installation N° of the SIP TG entity

SIP: Method update for early media (RFC 3311)
The UPDATE method defined in RFC 3311 allows to provide updated session
information before to receive a final response to the initial INVITE request
z Early media allows to open the RTP flow before the final response in order to
be able to send ringing tones or announcements
The UPDATE method can be sent by a UA within a dialog in order to update

session parameters without impacting the dialog state itself
The UPDATE method is already implemented in OXE for session timer

z It has been modified in order to be compliant with RFC 3311
Example of situation that needs this method

z The CS sends an INVITE to an external gateway with SDP and receives a 18x
response with SDP
z If after this response there is a change in the call properties then the CS
sends a new SDP in an update message
It can occurs after transfer or algorithm change because of IP domains
Update method is available only for external SIP gateways.

The CS will not send any update message to the SEPLOS, SIP devices, SIP Voice mail or OTUC
According to the “SDP in 180” field value managed in the external gateway object, the CS sends or not the SDP in the 180 and the
update method
If the value is false the CS will not send any update message

Flow without update method
CS Gateway
Invite with SDP 1
18x with answer to SDP1 + update method forbidden
200 OK for Invite without SDP
ACK
Re Invite with SDP 2
200 OK for Invite with answer to SDP 2
ACK

Flow with update method
CS Gateway
Invite with SDP 1
18x with answer to SDP1 + update method allowed
Update with SDP 2
200 OK for Update with answer to SDP 2
200 OK for Invite without SDP
ACK

SIP: Active calls display
“sipdump” tool
The first development step in OXE R8.0.1 provides a new tool called “sipdump”,
which gives a status about the internal resources of the SIP Gateway
The second step in OXE R9.0 provides an interface in order to filter the traces
of SIP calls
The third step in OXE R9.1 provides two more options
z Display of calls through a gateway (submenu “8”)

z Display of calls in a trunk group (submenu “9”)
The tool can dump only the SIP calls handled by the SIP gateway
SIP calls, which are directly handled by the SIP proxy, are not concerned
{ For example, a call between two SIP devices (without Call Admission Control) won’t be able
to be dumped by the tool
A call between two SIP extensions is handled by the SIP gateway
The filter are applied only on the SIP calls, which are handled by the SIP gateway
Reminder:
Two connections are required to use this tool. On one hand a connection to manage (setup) filters via the “sipdump” tool, and on other
hand a second connection to run a SIP trace (motortrace)
Complete menu:
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

SIP: Active calls display
“sipdump” tool (Cont’)
A filter setup and/or an option selection in the “sipdump” tool will be

automatically applied on the “motortrace” trace (activated via “traced”)
window
8- Display calls through a gateway
Gateway Number : specify the expected gateway
9- Display of calls in a trunk group
Trunk Group Number : 100 (for example)
Display of trunk groups Menu
{ 1 - Display calls through any one gateway using the trunk group(100)
Gateway Number : specify the expected gateway
{ 2 - Display calls through all the gateways using the trunk group(100)
{ 0 - Previous menu
Example of result:


Alcatel-Lucent Omnipcx Enterprise: R9.1 Sip Newness

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Alcatel-Lucent Omnipcx Enterprise: R9.1 Sip Newness

Uploaded by

Copyright:

Available Formats

Alcatel-Lucent OmniPCX Enterprise

R9.1 SIP Newness

All Rights Reserved © 2009, Alcatel-Lucent 1

 To describe the new SIP features of the release R9.1

Alcatel-Lucent OmniPCX Enterprise – R9.1 SIP Newness

 The purpose of this feature is to create a supervision of the device in order to

 The SIP extension must be able to send “options” messages

 There are new parameters in the CS

z SIP extension COS

 A Keep alive flag in order to authorize or to forbid the service

z IP QOS COS (specified within the IP domain)

 Keep alive timer

All Rights Reserved © 2009, Alcatel-Lucent 2

Alcatel-Lucent OmniPCX Enterprise – R9.1 SIP Newness

All Rights Reserved © 2009, Alcatel-Lucent 3

Alcatel-Lucent OmniPCX Enterprise – R9.1 SIP Newness

All Rights Reserved © 2009, Alcatel-Lucent 4

The values are in seconds

Alcatel-Lucent OmniPCX Enterprise – R9.1 SIP Newness

 The “telnet” service must be validated

All Rights Reserved © 2009, Alcatel-Lucent 5

Alcatel-Lucent OmniPCX Enterprise – R9.1 SIP Newness

All Rights Reserved © 2009, Alcatel-Lucent 6

Alcatel-Lucent OmniPCX Enterprise – R9.1 SIP Newness

(101)communn1r1> tradna 31900

Wed Jun 24 15:02:31 CEST 2009

Logic coupler type : CPL_UA

All Rights Reserved © 2009, Alcatel-Lucent 7

HS: out of service

Alcatel-Lucent OmniPCX Enterprise – R9.1 SIP Newness

 listerm (on the virtual UA board used for IP devices)

Wed Jun 24 15:04:53 CEST 2009

All Rights Reserved © 2009, Alcatel-Lucent 8

Alcatel-Lucent OmniPCX Enterprise – R9.1 SIP Newness

 The RFC4244 defines a standard mechanism for capturing the history

SIP Externe Gateway

 This capability enables many enhanced services by providing more information

All Rights Reserved © 2009, Alcatel-Lucent 9

Alcatel-Lucent OmniPCX Enterprise – R9.1 SIP Newness

z The Targeted-To-URI contains the Called User SIP URI

z The Index parameter contains the chronological order of the information

z The cause parameter contains the forward reason

 The CS will specify the cause

All Rights Reserved © 2009, Alcatel-Lucent 10

Alcatel-Lucent OmniPCX Enterprise – R9.1 SIP Newness

z The “Invite” and “To” URI are different

z The “Cause” field indicates the reason of forward

 In case of remote extension

z Both “Invite” and “To” URI are equal

z There is no “Cause” field because it is not a forwarding

All Rights Reserved © 2009, Alcatel-Lucent 11

Alcatel-Lucent OmniPCX Enterprise – R9.1 SIP Newness

 This feature is not implemented for SEPLOS

 When the CS is in transit case

z When a call is established between two different external SIP entities/

All Rights Reserved © 2009, Alcatel-Lucent 12

Alcatel-Lucent OmniPCX Enterprise – R9.1 SIP Newness

All Rights Reserved © 2009, Alcatel-Lucent 13

Alcatel-Lucent OmniPCX Enterprise – R9.1 SIP Newness

 There is a new SIP method called “Message”

 Accents a specific letters

All Rights Reserved © 2009, Alcatel-Lucent 14

1) Management object: SIP Extension/Class of service: “Display UTF-8: No”

To describe the new SIP features of the release R9.1

The purpose of this feature is to create a supervision of the device in order to

The SIP extension must be able to send “options” messages

There are new parameters in the CS

A Keep alive flag in order to authorize or to forbid the service

Keep alive timer

The “telnet” service must be validated

listerm (on the virtual UA board used for IP devices)

The RFC4244 defines a standard mechanism for capturing the history

This capability enables many enhanced services by providing more information

The CS will specify the cause

In case of remote extension

This feature is not implemented for SEPLOS

When the CS is in transit case

There is a new SIP method called “Message”

Accents a specific letters

Hunting group entry

Hunting group exit

Hunting group entry and DND activation

DND de-activation (Stay within the hunting group)

The following values have been defined:

An incoming call from the public side generates an INVITE

This feature is only available for SIP External gateways

The CAC is working in the following way :