TG0069_Ed12

7/26/2019 TG0069_Ed12

1/155

1

TROUBLESHOOTING GUIDE TG0069 Ed. 12

OmniPCX Enterprise Nb of pages :152 Date : 23rd April 2014

SUBJECT : Session Initiation Protocol (SIP)

CONTENTS

1. INTRODUCTION......................................................................... 7

2. DOCUMENT HISTORY................................................................. 7

3. REFERENCES............................................................................ 7

4. ABBREVIATIONS AND NOTATIONS............................................ 7

4.1 Abbrevations .......................................................................................... 7

4.2 Notations ............................................................................................... 7

5. PROTOCOL................................................................................ 8

5.1 SIP Overview .......................................................................................... 8

5.2 SIP Terminology ...................................................................................... 8

5.3 SIP structure ........................................................................................... 9

5.4 SIP Messages .......................................................................................... 9

5.5

SIP Transaction, Dialog Session .......................................................... 10

5.5.1 Transaction ..................................................................................................... 10

5.5.2 Dialog ............................................................................................................. 11

5.5.3 Session ........................................................................................................... 11

5.6 SIP Addressing ..................................................................................... 11

6. SIP LICENSING........................................................................ 12

7. INTERWORKING WITH OXE...................................................... 13

8. SIP OXE IMPLEMENTATION...................................................... 13

8.1

RFCs implemented on OXE .................................................................... 13

7/26/2019 TG0069_Ed12

2/155

2

8.1.1 SIP .................................................................................................................. 13

8.1.2 RTP, T38 & DTMF (used for SIP) ....................................................................... 14

8.2 SIPMOTOR processes ............................................................................ 14

8.3 OXE duplication .................................................................................... 15

8.4 The OXE contains the following compoments: ........................................ 15

8.4.1 Registrar......................................................................................................... 15

8.4.2

Proxy.............................................................................................................. 15

8.4.3 Gateway.......................................................................................................... 17

8.4.4 Dictionnary..................................................................................................... 17

8.4.5 SIP users ........................................................................................................ 17

8.4.6

SIP External Voice Mail................................................................................... 18

8.5

Overview of Interaction between Components ....................................... 19

8.6 Network number rules .......................................................................... 19

8.7 Overview of Remote Extension feature............................................... 19

8.8 Overview of G7 Transparent Fax and T38 fallback G7 feature..... 20

8.8.1 The T38 only procedure.................................................................................. 20

8.8.2 The G711 only procedure................................................................................ 20

8.8.3

The T38 to G711 Fallback procedure............................................................... 21

8.9 Overview of Private SIP Transit mode feature..................................... 22

8.10 SIP parameters explanation / under the object SIP: ................................ 25

8.10.1 SIP Trunk Group ............................................................................................. 25

8.10.2 The local SIP gateway ..................................................................................... 26

8.10.3 The external SIP gateways.............................................................................. 27

8.10.4 Timer usage for SIP Trunking (Trunk Categoy, by default 31).......................... 30

8.10.5 The SIP proxy ................................................................................................. 30

8.10.6 SIP Registrar ................................................................................................... 31

8.10.7SIP Dictionnary ............................................................................................... 32

8.10.8 SIP Authentication ........................................................................................... 32

8.10.9 Quarantined IP Addresses .............................................................................. 32

8.10.10 Trusted IP Addresses ................................................................................... 32

8.10.11 SIP To CH Error Mapping ............................................................................. 33

8.10.12 CH To SIP Error Mapping ............................................................................. 33

8.11 SIP parameters explanation / under the object USERS: ........................... 33

8.11.1

SIP Device ...................................................................................................... 33

8.11.2

SIP Extension (or SEPLOS)............................................................................. 34

8.12 SIP parameters explanation / under the object SIP Extension: ................. 35

8.13 SIP parameter explanation / under the object External Voice Mail: .......... 35

7/26/2019 TG0069_Ed12

3/155

3

8.14 SIP parameters explanation / under the object System:........................... 36

9. IP DOMAINS, CODECS AND PCS............................................... 37

9.1 IP domains rules ................................................................................... 37

9.2

System law for PCM codec ..................................................................... 37

9.3 Codecs on SDP (before OXE R11) ........................................................... 37

9.3.1 Initial offer : the offer sent in an initial INVITE ................................................ 37

9.3.1 Initial answer : the answer to an initial offer on incoming call ....................... 38

9.4 Codecs on SDP (from OXE R11) ............................................................. 38

9.4.1 Initial offer : the offer sent in an initial INVITE ................................................ 38

9.4.2 Initial answer : the answer to an initial offer on incoming call ....................... 39

9.5 How to manage the type of codec negotiation from OXE R11? ................ 40

9.6 How to manage the SDP transparency override from OXE R10.1? ........... 40

9.7 PCS ...................................................................................................... 40

10. CONTENTS OF A SIP MESSAGES (GENERAL VIEW).................. 41

10.1 The HEADER ......................................................................................... 41

10.2 The BODY ............................................................................................ 43

11. EXAMPLES OF COMMON SIP FLOWS....................................... 44

11.1 Registration .......................................................................................... 44

11.2 De-registration ..................................................................................... 47

11.3

Simple call establishement .................................................................... 48

12. TROUBLESHOOTING................................................................ 51

12.1 SIPMOTOR processes ............................................................................ 51

12.2 SIPMOTOR memory used ...................................................................... 52

12.3

Check the SYSTEM and SIPMOTOR backtraces/alarms ............................ 52

12.3.1 Backtraces ................................................................................................... 52

12.3.2 Alarms ......................................................................................................... 53

12.4 SIP traces ............................................................................................. 55

12.4.1 SIPMOTOR traces........................................................................................... 55

12.4.2

Call Handling traces........................................................................................ 57

12.4.3 Tcpdump / Network traces.............................................................................. 58

12.5 Maintenance commands ....................................................................... 59

12.5.1

sip ............................................................................................................... 59

12.5.2 trkstat .......................................................................................................... 59

12.5.3 trkvisu ......................................................................................................... 60

7/26/2019 TG0069_Ed12

4/155

4

12.5.4 sipaccess ..................................................................................................... 61

12.5.5 sipgateway .................................................................................................. 61

12.5.6 Sipdump ...................................................................................................... 62

12.5.7 sipextgw ...................................................................................................... 70

12.5.8

sippool ........................................................................................................ 71

12.5.9 sipdict .......................................................................................................... 72

12.5.10 sipauth ........................................................................................................ 73

12.5.11 sipregister ................................................................................................... 73

12.5.12 csipsets ........................................................................................................ 75

12.5.13 csipview com ............................................................................................... 76

12.5.14 csiprestart .................................................................................................... 76

12.5.15 sipextusers ................................................................................................... 77

12.6 Link between SIPMOTOR traces and Call Handling traces ....................... 77

12.6.1 Call Handling / SIPMOTOR links implementation ........................................ 77

12.6.2 General view ............................................................................................... 78

12.6.3 neqt link between SIPMOTOR and Call Handling traces.......................... 78

12.7 Information in the SIPMOTOR traces ...................................................... 79

12.8 Follow a call on the SIPMOTOR trace ..................................................... 80

12.9 Traces analyses .................................................................................... 82

12.9.1

Incoming SIP call using a SIP Trunk Group: SIPMOTOR point of view............ 82

12.9.2

Incoming SIP call using a SIP Trunk Group: Call Handling point of view......... 91

12.9.3 Incoming SIP call in case of SIP extension: SIPMOTOR point of view............. 96

12.9.4

Incoming SIP call in case of SIP extension: Call Handling point of view........ 106

12.10Main call flows explanation ................................................................. 112

12.10.1 Forwards ................................................................................................... 112

12.10.2 Transfer ..................................................................................................... 114

12.10.3 UPDATE on Early Media ............................................................................ 117

12.11

Configuration issues ........................................................................... 119

12.11.1 SIP configuration rule ................................................................................ 119

12.11.2 SIP alarms generated on OXE .................................................................... 120

12.11.3 Common SIP issues ................................................................................... 122

12.11.4 SIP Device issues ....................................................................................... 126

12.11.5 SIP extension issues ................................................................................... 127

12.11.6 SIP External Gateway Issue........................................................................ 127

11.13 Summary for SIP issue analyse ............................................................ 128

13. SYMPTOMS, DIAGNOSIS AND SOLUTIONS............................. 129

13.1.1 Outgoing Call Cancel sent by OXE after 180 w SDP ............................... 129

7/26/2019 TG0069_Ed12

5/155

5

13.1.2 Telephone-event are not provided on SDP offer ........................................ 129

13.1.3 Loss of communication with SIP External Voicemail ................................... 129

13.1.4 Impossible to let a message when routing via SIP Automated Attendant... 129

13.1.5 When call is transfer from a Third Party Server, after few seconds, a Re-Invite

is sent by OXE to reroute RTP to a GD card ................................................................ 129

13.1.6 Incoming call from a SIP Third Party Server is rejected by OXE with a SIP Error488 Not Acceptable Here ........................................................................................... 129

13.1.7 Incoming call is not recognized as INTERNATIONAL ................................. 130

13.1.8 When we attempt to register on SIP External Gateway, OXE answers by a SIPerror 482 Loop Detected ........................................................................................ 130

13.1.9 When we attempt to register our SIP External Gateway with an external SIPProxy, SIP Proxy answers by a SIP error 416 Unsupported URI Scheme.................. 131

13.1.10 Incoming call doesnt transit via Trunk Group configured on SIP Ext Gw... 132

13.1.11

Wrong caller number sent in case of forward ........................................... 132

13.1.12 Diversion/History-Info header is not present ............................................. 132

13.1.13 SIP-Trunking Name is displayed on calling phone set when call is established 133

13.1.14 From header doesnt have the national format......................................... 133

13.1.15 Incoming and outgoing fax communications impossible through SIP Gw .. 133

13.1.16 No Re-Invite with T38 offer sent by OXE .................................................... 133

13.1.17 External call with secret identity over SIP Provider fails ............................. 134

13.1.18

On SIP outgoing call, dynamic ports are used instead of port 5060 .......... 134

13.1.19 A "+" character is added on calling number when ISDN call is routed to SIP134

13.1.20 Diversion Field doesnt have the canonical form....................................... 134

13.1.21 Leg1 and leg2 are external set, when OXE user performs a blind transfer, itdoesnt work.............................................................................................................. 135

13.1.22 SingleStep Transfer with REFER, no referred-by in the following INVITE ... 135

13.1.23 Major alarm szSdpMessage > 1000 is present on sipalarm.log ................ 136

13.1.24 SIP-Trunking Bad routing and bad display from time to time trough SIP trunk

136

13.1.25 SIPMOTOR goes to "Degraded mode enabled" state .................................. 136

13.1.26 A Diversion header is added in case of single step transfer after a consultationcall 137

13.1.27 Incoming calls from SIP Provider are rejected by SIPMOTOR after upgradefrom R9.0 to R10.1 ..................................................................................................... 138

13.1.28 Remote extension issue in ringing phase ................................................... 139

13.1.29 Overflow on Remote Extension impossible when SIP Extension seen Out ofService 139

13.1.30

Country Code is not added on Calling Number when call is performed since aGSM 139

13.1.31 Call Back issue on Open Touch ................................................................. 140

13.1.32 only 62 simultaneous calls are sent out of the OXE, all other calls are released

7/26/2019 TG0069_Ed12

6/155

6

141

BEFORE CALLING ALCATEL-LUCENTS SUPPORT CENTER .............. 142

NOTE........................................................................................... 142

14. ANNEXE: REGISTER / INVITE WITH OR WITHOUTAUTHENTICATION.................................................................. 143

14.1 Register of set ..................................................................................... 143

14.1.1 Classical management of SIP on the OXE .................................................. 143

14.1.2 Register of set without authentication ........................................................ 144

14.1.3 Register of set with authentication ............................................................. 144

14.2 INVITE of set ...................................................................................... 145

14.2.1

INVITE of set without authentication .......................................................... 145

14.2.2 INVITE of set with authentication ............................................................... 145

14.3 Register of an external gateway .......................................................... 146

14.3.1 Register of an external gateway without authentication ............................ 146

14.3.2 Register of an external gateway with authentication ................................. 149

14.4 INVITE of an external gateway with authentication .............................. 152

7/26/2019 TG0069_Ed12

7/155

OmniPCX Enterprise

TROUBLESHOOTING GUIDE No. 0069 Session Iniation Protocol (SIP)

Ed. 12 7 TG0069

1. INTRODUCTION

This Troubleshooting Guide deals with SIP (Session Initiation Protocol) and its implementation in OmniPCXEnterprise (OXE), which allows the OXE to connect to SIP phones, SIP trunks and SIPapplications like external Voicemail.

The goal is of this document is to explain the functioning of the SIP, to facilitate the troubleshootingand resolution of issues related to SIP

2. DOCUMENT HISTORY Ed01: first edition Ed02: add Traces analyses chapter Ed03: add chapter 12 and update 7.11 section Ed04: update SIP Device issueschapter Ed05: update chapter 12 Ed06: update 7.7.3 chapter, add new chaper Timer Usage for SIP Trunking Ed07: add Restriction onSupport of Re-Invite wo SDP, see 7.7.3 chapter Ed08: add new section ANNEXE: Register / INVITE with or without authentication Ed09: update chapter 12 Ed10: update chapter 12 Ed11: R9.1 obsolete, update of the document for R11 (new SIP parameters, RFCs, licences)

Ed12: R10.x obsolete, update of the document for R11.0.1 (new SIP parameters)

3. REFERENCES

OmniPCX Enterprise Technical Documentation

4. ABBREVIATIONS AND NOTATIONS

4.1 Abbrevations

OXE : OmniPCX Enterprise

SIP : Session Initiation Protocol

URI : Uniform Resource Identifier

4.2 Notations

We suggest to pay attention to this symbol, which indicates some possible risks or gives important

information.

7/26/2019 TG0069_Ed12

8/155

OmniPCX Enterprise


Ed. 12 8 TG0069

5. PROTOCOL

5.1 SIP Overview

The SIP protocol is designed to establish, to maintain and to end multimedia sessions between differentparties. This protocol is based on the HTTP 1.1

SIP does not provide an integrated communication system. SIP is only in charge of initiating a dialogbetween interlocutors and of negotiating communication parameters, in particular those concerning themedia 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 usesG7xx audio codecs for voice coding and compression.

5.2 SIP Terminology

User Agent (UA)

o User Agent Client (UAC): Initiator of the SIP requestso User Agent Server (UAS): Receiver of the SIP requests (end point)

A SIP equipment can be UAC or UAS according to the direction of the call

Registrar: A registrar is a server that accepts REGISTER requests and places the information itreceives in those requests into the location service for the domain it handles.The OmniPCX Enterprise incorporates the function of registrar.

Location Service: A location service is used by a SIP redirect or proxy server to obtain informationabout a callee's possible location(s). It contains a list of bindings of address-of-record keys to zeroor more contact addresses.

The OmniPCX Enterprise incorporates the function of location service. Proxy, Proxy Server: An intermediary entity that acts as both a server and a client for the purpose of

making requests on behalf of other clients. A proxy server primarily plays the role of routing, which

Alice Bob

Alice Bob

UAC UAS

UAS UAC

Call Direction

Call Direction

IP

TCP UDP

RTP/RTCP

MEDIA

SIP

SDP

Network Layer

Transport Layer

Application

7/26/2019 TG0069_Ed12

9/155

OmniPCX Enterprise


Ed. 12 9 TG0069

means its job is to ensure that a request is sent to another entity "closer" to the targeted user.

Proxies are also useful for enforcing policy (for example, making sure a user is allowed to make acall). A proxy interprets, and, if necessary, rewrites specific parts of a request message beforeforwarding it. The SIP proxy is the central actor and first contact for any SIP end user device thatwants to initiate a request.

Note: In the OmniPCX Enterprise, the logical functions of registrar, location service and proxy serverare co-located and running on the OmniPCX Enterprise call server (CPU/CS/AS) board. TheOmniPCX Enterprise proxy server is stateful (it remembers transaction state), call-stateful (stays inthe signaling path) and forking (it can redirect requests to multiple destinations).The name of the SIP domain handled by an OXE node is its node name concatenated with the DNSlocal domain name defined in SIP/SIP gateway. The main IP address can be substituted whereverappropriate.

Redirect Server: Provides the client with information about the next hop or hops that a message

should take and then the client contacts the next hop server or UAS directly. OmniPCX Enterprisedoes NOT provide a redirect server.

Gateway: A gateway is a SIP user agent that provides a bridging function between the SIP world andother signaling and telephony systems.

5.3 SIP structure

The SIP is based on the RFC 3261 (previous RFC 2543). Its implementation is the following:

5.4 SIP Messages

The main types of requests are:

REGISTER: message sent by an agent to indicate his current address. This information can bestored in the location server and is used for call routing.

INVITE: message sent systematically by the client for any connection request.

ACK: message sent by the client to confirm (acknowledge) the connection request.

BYE: terminates a call, RTP packet exchange is stopped. CANCEL: terminates a call currently being set up.

UDP TCP

Syntax/Encoding

Transport

Transaction

Transaction user

A lication

Trans ort rotocol

Analyse of the messages (Parsing)

Emission, rece tion of the messa es

Treatment, retransmission of messa es

Session, dialogTraitement of the services

7/26/2019 TG0069_Ed12

10/155

OmniPCX Enterprise


Ed. 12 10 TG0069

SUBSCRIBE - NOTIFY: message used to subscribe to/notify an event (for example: new voicemail

message). REFER: message requesting an agent to call an address (used for transfers).

UPDATE: message sent to change the SDP information in early dialog or confirmed dialog.

MESSAGE: message used to send a message.

OPTIONS: Requests information about the capabilities of a caller, without setting up a call. Alsoused for supervision purpose between two UAs.

PRACK: (Provisional Response Acknowledgement): PRACK improves network reliability by addingan acknowledgement system to the provisional Responses (1xx). PRACK is sent in response toprovisional response (1xx).

The remote endpoint answers with a response of one of the following types (main messages answered byOXE):

1xx: informational (transaction in progress).

o The 100 Tyring is particular regarding the other informational answers, used to avoidretransmission of INVITE.

o The 180 Ringing is used for ring back tone (RBT).

o The 183 Progress is used to broadcast voice guides.

2xx: success (transaction completed successfully).

o 200 OK indicates the request was successfull

o 202 Accepted indicates that the request has been accepted for processing, but theprocessing has not been completed

3xx: forward (the transaction is terminated and prompts the user to try again in other conditions).

o 301 Moved Permanently

o 302 Moved Temporarily

4xx: The request contains bad syntax or cannot be fulfilled at the server.

5xx:The server failed to fulfill an apparently valid request

6xx: The request cannot be fulfilled at any server

Regarding the unsuccessfull answers, for their meaning, use the RFC 3261.

5.5 SIP Transaction, Dialog & Session

5.5.1 Transaction

The transactions have to separated: The INVITE transaction

The INVITE transaction is composed of three ways INVITE sends from the client to the server Answers send from the server to the client Client must send an ACK

If these three steps are respected, a INVITE transaction is done

7/26/2019 TG0069_Ed12

11/155

OmniPCX Enterprise


Ed. 12 11 TG0069

Example

UAC UAS| INVITE ||--------------->|| 100 Trying ||

7/26/2019 TG0069_Ed12

12/155

OmniPCX Enterprise


Ed. 12 12 TG0069

Examples for SIP URIs:

sip:[email protected]



In OmniPCX Enterprise, the more specific term URL (Uniform Resource Locator) is generally used instead ofURI, since OXE is more concerned about location aspects rather than identification aspects.

For OXE uses on the username part numbers and no names.

6. SIP LICENSINGHere the next licenses for SIP (under spadmin):

The license 177corresponds to the maximum number of SIP users (SIP Extension & SIP Device). The license 185corresponds to the use of the SIP on the OXE (activation). The license 188 corresponds to the maximum number of SIP Calls available all the SIP elements

(SIP calls thru Trunk group and SIP extension). The license 345corresponds to the maximum number of SIP Extension users. The license 386corresponds to the activation of the UCaaService.

o When UCaaS lock is 0: control of SIP Trunking call establishment is not modified and usesexisting SIP Network Links lock; new system option is not considered, whatever its value

(current OXE behavior)o When UCaaS lock is not 0, SIP Network Links is no more considered but is replaced with

a new system option Number of SIP Trunks (UCAAS) A new system option Number of SIP Trunks (UCAAS)is added from R11under System / Other

System Params / SIP Parametersand replaces the lock 188 when lock 386 is activated. Customers

or Carriers can allocate a number of SIP Trunks Channels for all SIP External Gateways configuredon the system. Voicemail and OpenTouch calls are not considered.

In case of SIP Registered (aka SIP Device), license are taken at proxy level (for some use cases like aSIP Device calls SIP Voicemail) and counted against license #188 ; so that for UCaaS systems it isbetter to have license #188 greater than 0

Another information link to SIP is important, the PARAMAO 3 used for the creation of the SIP Trunk Group(under cfgUpdate):

This value is calculated according to the number of Trunk Groups managed via ACTIS (including SIP).

177 M SIP users = 13/ 25...185 SIP Gateway = 1...188 SIP network links = 45...345 M SIP extension users = 8/ 25...

386 UC as a Service = 0 From R11

5 Trunks : 5000

7/26/2019 TG0069_Ed12

13/155

OmniPCX Enterprise


Ed. 12 13 TG0069

7. INTERWORKING WITH OXE

Alcatel-Lucent Enterprise provides support:

- for non AAPP/ALU applications, a SIP ISDN or SIP ABC trunk group can be used only under controlof TC1820 : Alcatel-Lucent OmniPCX Enterprise SIP Trunking with 3rd Party ( IVR & ContactCenter ) guideline. This guideline provides configuration and topologies supported by ALE.

- for SIP Carrier, interworking with OXE must be validated by Christophe Haettinger and ALETechnical Support team. A survey must be filled by the carrier and according to the answers, aninterworking test campaign will be proposed

8. SIP OXE IMPLEMENTATION

8.1 RFCs implemented on OXE

8.1.1 SIP

RFC 2543 (obsolete by RFC 3261,3262, 3263,3264, 3265): SIP: Session Initiation Protocol RFC 2782: A DNS RR for specifying the location of services (DNS SRV) RFC 2822: Internet Message Format

RFC 3261: SIP: Session Initiation Protocol RFC 3262: Reliability of Provisional Responses in SIP (PRACK) RFC 3263: SIP: Locating SIP Servers RFC 3264: An Offer / Answer model with SDP RFC 3265: SIP-Specific Event Notification RFC 3311: The SIP UPDATE Method (session timer only) RFC 3323: 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 3265: SIP-specific Event Notification RFC 3515: The Session Initiation Protocol (SIP) Refer method

RFC 3891/3892: The Session Initiation Protocol (SIP) 'Replaces' Header/ Referred-By Mechanism RFC 3398: Integrated Services Digital Network (ISDN) User Part (ISUP) to SIP Mapping RFC 3966: The telephone URI for telephone numbers : since R11 only TEL URI is supported RFC 4497: Inter-working between SIP and QSIG RFC 5373: Requesting Answering Modes for the Session Initiation Protocol

RFC 4244: An Extension to the Session Initiation Protocol (SIP)for Request History Information

RFC 3326: The Reason Header Field for the Session Initiation Protocol (SIP)

RFC 3428: Session Initiation Protocol (SIP) Extension for Instant Messaging (partial)

RFC 3608: Service Route header

RFC 3327: Path Header RFC 1321: Authentication for Outgoing calls

RFC 2246: The TLS Protocol Version 1.0 RFC 3268: Advanced Encryption Standard (AES) Cipher suites for Transport Layer Security (TLS)

7/26/2019 TG0069_Ed12

14/155

OmniPCX Enterprise


Ed. 12 14 TG0069

RFC 3280/5280: Internet X.509 Public Key Infrastructure Certificate and Certificate

Revocation List (CRL) Profile RFC 3842: A message Summary and Message Waiting Indication Event Package RFC 4028: The session timers in the Session Initiation Protocol RFC 3960: Early Media (partial): Gateway model not supported

RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams

RFC 5806: Diversion Indication in SIP

RFC 3725 : Invite without SDP (3pcc in SIP)

RFC 3966 : The tel URI from R11

RFC 5009 : The P-Early-Media header from R11

8.1.2 RTP, T38 & DTMF (used for SIP)

RFC 2617: HTTP Authentication : Basic and Digest Access Authentication RFC 2833/4733: DTMF Transparency. RFC 2833 replaced by RFC 4733 RFC 1889/1890: RTP : A transport protocol for Real-Time applications RFC 2198: RTP Payload for Redundant Audio data RFC 3550: RTP: A Transport Protocol for Real-Time application (audio only) RFC 3551: RTP Profile for Audio and Video Conferences with Minimal Control (audio only) RFC 3711: The Secure Real Time. Supported on A-LU IP Phone and Softphone RFC 3362: T38 ITU-T Procedures for real time Group3 Fax Relay / communications over IP RFC 3711: The Secure Real-time Transport Protocol (SRTP) (media integrity)

8.2 SIPMOTOR processes

In the OmniPCX Enterprise, the logical functions of registrar, location service, proxy server and gateway areco-located in the process called sipmotor, running on the CPU7/CS2/AS board.

You may use the linux pscommand to verify that the SIP processes are running :

Example:

All processes can be forced to reset with the command: dhs3_init -R SIPMOTOR, this command stops properly the SIPMOTOR processes and restarts

them.

They will be automatically relaunched after a few seconds.

The following commands can be used as well:

killall sipmotor, this command kills the SIPMOTOR processes and restarts them. kill -9 father pid, this command kills the SIPMOTOR processes and restarts them.

(1)OXE> dhs3_init R SIPMOTOR

(1)OXE> ps -edf | grep siproot 2202 801 0 2011 ? 00:00:00 [#sipmotor]root 2203 2202 0 2011 ? 00:00:00 [sipmotor_tcl]root 2204 2202 0 2011 ? 00:00:00 [sipmotor]

root 2205 2202 0 2011 ? 00:00:00 [sipmotor_dump]root 2206 2202 0 2011 ? 00:00:00 [sipmotor_presen]

7/26/2019 TG0069_Ed12

15/155

OmniPCX Enterprise


Ed. 12 15 TG0069

Remarks:

If no licenses about SIP are present, the SIPMOTOR processes are not running. If Lock 386 different than 0 and System parameter Number of SIP trunks (UCaaS)is equal to 0, the

SIPMOTOR processes are not running

8.3 OXE duplication

In case of OXE duplication, the SIPMOTOR is completely started on the Stand-By CPU, but acting as Stand-By (cannot handle the SIP requests). The Main CPU puts the Stand-By CPU up to date about the SIPcontexts (Calls, registrations, subscriptions, etc...). In case of CPU switchover, the SIP calls are maintainedand the registration and subscriptions are kept.

In Case of spatial redundancy with dual subnetworks (2 main IP addresses), the SIP uses the FQDN of theOXE (nodename + DNS local domain name) for the SIP messages and also for the responses of the SIP

messages. In that case, the remote SIP equipment must use it. The use of external DNS server isrecommended to resolve this FQDN.

8.4 The OXE contains the following compoments:

8.4.1 Registrar

Registers the SIP terminals addresses (Location Service)

The REGISTRAR is contained in the localize.sipfile under /tmpd. If for any reasons you need toclear all entries in the registrar database, remove this file and then restart the SIPMOTOR:

8.4.2 Proxy

Entity between the Client and the Server, the proxy is used to route the SIP requests.

The call can be routed between 2 SIP terminals. For instance, if Alice calls Bob (both are SIP), Alicesends a SIP request to the proxy, and the proxy sends this request to Bob.

The proxy can be used only for the authentication of the SIP equipment for Registration or SIPrequest.

o The proxy can modify the request by adding information like a Via, Record-route, etc...

The INVITE is the same on each proxy sides, to get this behavior, and the UAC manages the IP address ofthe OXE SIP proxy as the Outbound proxyHere is an example:

UAC IP address: 172.27.143.184 proxy IP address: 172.27.143.186 UAS FQDN: oxe-ov.alcatel.fr (IP address: 172.27.141.151)

Proxy BobAlice

UAC UAS

INIVTE with leg1 INVITE with leg1

(1)OXE> rm /tmpd/localize.sip

(1)OXE> dhs3_init -R SIPMOTOR

7/26/2019 TG0069_Ed12

16/155

OmniPCX Enterprise


Ed. 12 16 TG0069

The OXE SIP proxy receives an INVITE with the information Routecorresponding to the final end point forthe SIP call. In that case, the OXE SIP proxy acts like a proxy (not a back to back). Due to this, the proxysends the following INVITE to the final SIP endpoint.

The proxy adds some information on the INVITE sent to the final SIP end point, but the INVITE is the sameas the one received (same Call-ID, same FROM, same TO, same TAGs, etc...)

o The REQUEST-URI has been modified according to the information from the Route fromthe first INVITE.

INVITE sip:[email protected]

o Information added: Via: SIP/2.0/UDP 172.27.143.186; branch=z9hG4bK1053e27e7fd

Correponding to the proxy identification

Record-Route: Correponding to the path for the answers (the answers must be sent to this

IP address)

Session-Expires: 1800 Corresponding to the session timer used on the proxy

Fri Jun 29 14:08:10 2012 RECEIVE MESSAGE FROM NETWORK (172.27.143.184:5060 [UDP])----------------------utf8-----------------------INVITE sip:172.27.143.186 SIP/2.0Via: SIP/2.0/UDP 172.27.143.184:5060;rport;branch=z9hG4bKPjX7-GJh79mg04nEbZ0yxYsWP3MCiy4C4HMax-Forwards: 70From: ;tag=BJ2er-g.ONc2M.MQJ9qO.wfpLyp8qfQ3To: Contact: Call-ID: L9TrfBGqqYwgo6CR.c9YtaiyulB9OGVUCSeq: 23308 INVITERoute: Route: Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONSSupported: 100rel, norefersubUser-Agent: OmniTouch 1.5.13.7Content-Type: application/sdpContent-Length: 283

Fri Jun 29 14:08:10 2012 SEND MESSAGE TO NETWORK (172.27.141.151:5060 [UDP]) (BUFF LEN = 1130)----------------------utf8-----------------------INVITE sip:[email protected];transport=udp SIP/2.0Route: Record-Route: Via: SIP/2.0/UDP172.27.143.186;branch=z9hG4bK1053e27e7fdda06c573798bc91cd12a29c49e03527107ccdabde727c92e5b987Via: SIP/2.0/UDP 172.27.143.184:5060;received=172.27.143.184;rport=5060;branch=z9hG4bKPjX7-GJh79mg04nEbZ0yxYsWP3MCiy4C4HMax-Forwards: 69From: ;tag=BJ2er-g.ONc2M.MQJ9qO.wfpLyp8qfQ3To: Contact: Call-ID: L9TrfBGqqYwgo6CR.c9YtaiyulB9OGVUCSeq: 23308 INVITEAllow: PRACK,INVITE,ACK,BYE,CANCEL,UPDATE,SUBSCRIBE,NOTIFY,REFER,MESSAGE,OPTIONSSupported: 100rel,norefersubUser-Agent: OmniTouch 1.5.13.7

7/26/2019 TG0069_Ed12

17/155

OmniPCX Enterprise


Ed. 12 17 TG0069

The Proxy can be used as a Back-to-Back. In that case, on each side, two different legs will be

found:

Two different INVITEs on each proxy sides.

There are no specific information on the INVITE because the proxy acts as an UAS for the caller and anUAC for the called party.

8.4.3 Gateway

Entity between SIP world and legacy world, the gateway is used to establish a call from a SIP equipment toan ISDN link, to a legacy set, etc and vice versa.

Do not confuse the SIP gateway with the OmniPCX Enterprise media gateway boards:o The SIP gateway is a logical entity that resides within the call server (CS) and is responsible

for the SIP signaling for the conversation setup,o The media gateway boards (GD, GA, INTIP) are the physical devices where the media

session will be established when calling to a classic PBX set.

There is one and only one internal SIP gateway. But there can be many different external SIP

gateways (we will come back to this in a later section).

The SIP gateway is associated to a SIP trunk group. Although there can be many SIP Trunk Groups,there is only one SIP trunk group which is associated to the local SIP gateway. We call this specialtrunk group the local SIP trunk group.

8.4.4 Dictionnary

Contains the SIP users created on the OXE, it is the database that holds the mapping between SIP URLsand PBX directory numbers (MCDUs). Each registered SIP terminal is automatically added to thedictionnary. Classic PBX terminals are added only if a SIP URL is defined for them in the user management.

Most of the time you shouldnt do anything with the Dictionnary. Everything will be handledautomatically. You need to access the SIP Dictionnary configuration only for configuration of aliases.

8.4.5 SIP users

On the OXE , there are two types of SIP users:

SIP Device

o A SIP device is considered as an external SIP user. It means that the SIP device is linked tothe local SIP gateway and uses its configuration

o The phone features are limited

SIP Extension(or SEPLOS)

Proxy BobAlice

UAC UAS

INVITE with leg1 INVITE with leg2

UAS UAC

7/26/2019 TG0069_Ed12

18/155

OmniPCX Enterprise


Ed. 12 18 TG0069

o A SIP extension is considered as an internal SIP user. It means that the SIP extension can

access to some OmniPCX Enterprise services and phone featureso It can use some OmniPCX Enterprises prefixes, can be declared as a room set, etco The available phone features depends also on the SIP phone itself.o A SIP extension is attached to a virtual UA board, like an IPtouch.

On OXE, it is necessary to understand that a SIP extension user is different from the SIP phone associatedto this user.For instance:

- If the SIP phone is forwarded, it doesnt mean that the user is forwarded.- If the user is forwarded, it doesnt mean that the SIP phone is forwarded.

It is very important to remember this behaviour.

The declaration of a SIP user binds the information configured in the SIP set with the information stored intothe database of the OmniPCX Enterprise.

If you dont fill in the SIP part in the OmniPCX Enterprise user configuration, the default values will be :

URL User Name = MCDU of the user.

URL Domain = SIP domain name of the OmniPCX Enterprise, i.e. the SIP set is considered asregistered on the OmniPCX Enterprise.

This is usually exactly what we want so you shouldnt modify anything here.After the creation of the user a corresponding entry will automatically be added to the SIP Dictionnary.

Note: The value for the URL (@) configured on the SIP set and in the OmniPCX

Enterprise SIP Dictionnary MUST match. This can be an issue if you modified one of these parameters byhand and not the other one.

8.4.6 SIP External Voice Mail

On the OXE, it is possible to connect external voice mail, as the OmniTouch 8440, to be able to manage itand use it. The local SIP gateway must be managed first.

Enhancement with OXE R11: Device ringing when SIP VoiceMail is Out of Service Behavior before R11: if any set is forwarded to an SIP External Voicemail and if that SIP Voicemail is

Out of Service, the call is disconnected Enhancement from R11: When the SIP External Voicemail is Out of Service, the last set which has

activated the forward is ringing. It works in local, network and with external (SIP trunking forexample). For external calls, this feature will allow the terminal to ring till the trunk overflow timer andafter which it will overflow to the entity of the last set which is forwarded to SIP Voicemail that is Outof Service

7/26/2019 TG0069_Ed12

19/155

OmniPCX Enterprise


Ed. 12 19 TG0069

8.5 Overview of Interaction between Components

The following diagram shows the relationship between the functional SIP modules in OmniPCX Enterprise :

8.6 Network number rules

The OXE uses network (or subnetwork or routing tables) for different applications. The network must beunique for each application. It is very important for SIP to respect the following configuration:

The ABC-F network uses its own network number (managed in System parameter). The VPN uses different network numbers according to the configuration. The local Hybrid Link (for CCD) uses its own network number. The local SIP gateway must use a dedicated network number. Do not use a network number used by

another application. Each external ABC-F gateways use their own network numbers.

These rules must be enforced to avoid SIP issues.

8.7 Overview of Remote Extension feature

Enhancement with OXE R11: Overflow to associate set if REX user is unavailable Behavior before R11: when the mobile set of a Remote Extension user receives a call from OXE and

the mobile is in one of the following states (swithed off, busy, Out of Coverage area, Out of Service,the REX user may reject the call), OXE will receive a DISCONNECT message from the REX isunavailable due to the above mentioned reasons. When an Associate Set is managed in OXE for theRemote Extension, on receiving a DISCONNECT message, the behavior in OXE depends on thevalue of a system parameter System -> Descend Hierarchy -> Other System Parameters ->Descend Hierarchy -> External Signaling Parameter -> Review/Modify -> Listen to guide on

DISCONNECTAccording to the existing implementation of Remote Extension, when the parameter Listen to guideon DISCONNECT is set to:

sip :[email protected]

sip :[email protected]

Registrar

Proxy

Dictionnary

Gateway

sip :[email protected] reachable at

phone1.alcatel-lucent.com

sip :[email protected] reachable at

phone2.alcatel-lucent.com

Legacy
mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]

7/26/2019 TG0069_Ed12

20/155

OmniPCX Enterprise


Ed. 12 20 TG0069

o TRUE the incoming call to Remote Extension overflows to its Associate Set only after no

answer timer expires.o FALSE the incoming call to Remote Extension overflows to its Associate Set immediately Enhancement from R11: When REX user is configured as Non-Tandem set, then the call will

overflow to the associate set of the REX immediately irrespective of the value of parameter Listen toguide on Disconnect. Whenever REX user is configured as Tandems secondary set, the overflowwill depend upon the state when the DISCONNECT message is received. If OXE receives aDISCONNECT message before ALERT, the call will not overflow to the associate Set immediatelybut will overflow only after the call no answer timer. If OXE receives the DISCONNECT messageafter ALERT, the call will overflow to the associate set of the REX immediately

8.8 Overview of G711 Transparent Fax and T38 fallback G711 feature

In a FAX over IP communication, when a SIP External Gatway is involved, the transmission is done throughT38 Procedure. From OXE R11, the G711 procedure for fax communication is implemented, as well as aFallbackprocedure from T38 to G711.With this feature, OXE will support two more procedures. For SIP calls, FAS support will be done in 3 modes:

o The T38 only procedureo The G711 transparent procedureo The T38 to G711 Fallback procedure (In a first step, fax will try to establish with T38, if remote side

doesnt support it, it will fallback to G711 mode)The configuration of the above options is made in the corresponding External Gateway parameter (Faxprocedure type).

Remark: this feature is applicable for the INTIP3/MG3 couplers only

8.8.1 The T38 only procedure

If the configuration parameter is T38 only, the existing behavior appliesonly T38 mode will be supported. Ifthe remote party doesnt support this mode, the call will be disconnected. IP > Fax Parameters > T38 Onlyoption is kept for compatibility with the previous releases.

8.8.2 The G711 only procedure

After initial call establishment, no signalling should be received for FAX. FAX should be received/sent in

G711.Step1: If the initial call is established with G711 and the IP coupler in front of the FAX areINTIP3/MG3couplers, OXE can detect the FAX sent by SIP External Gateway in G711 mode.Step2: IfOXE receives a Re-INVITE with T38 parameters, the negotiated codec and the IP coupler type ischecked and based on that, the acceptance of the call is decided:

- Case 1: codec is G729/G723. Call proceeds in T38 mode- Case 2: codec G711 and INTIP3/MG3 coupler. When OXE receives Re-INVITE with T38 and if the

initial call is with G711, OXE sends 488 Not Acceptable Hereto the SIP External Gateway. This isbecause, since configuration of Fax mode is G711 Only, Media Gateway prepared to send/receivethe FAX in G711 transparent so Media Gateway is no more able to switch back to T38.

Else, Fax is transmitted in G711 Transparent modeStep3: If OXE receives a Re-INVITE with G711 parameters, FAX is transmitted in G711 Transparent mode

Remark: at the sending of 488 Not Acceptable Here, some carriers may continue the Fax tranmission inG711 transparent mode.

7/26/2019 TG0069_Ed12

21/155

OmniPCX Enterprise


Ed. 12 21 TG0069

OXE SIP Carrier

8.8.3 The T38 to G711 Fallback procedure

If the SIP External Gateway configuration parameter is T38 to G711 Fallback and if the IPCouplers in frontof FAX are INTIP3/MG3 couplers and if the initial call is established with G711, OXE will try to establish theFAX in T38 mode. If the remote SIP Party is not able to support FAX in T38 mode, it will send Errormessage. This will result in OXE to switch the FAX to G711 Mode.

Outgoing callIf OXE receives a RE-INVITE with T38 parameters, the call will proceed in T38. If OXE receives FAX call inG711, it will directly detect and handle it.

Incoming callStep1: When OXE detects a T38 FAX call, it sends Re-INVITE with T38 parameters as usual.Step2: Ifthe SIP Carrier accepts it and 200 OK is received with T38 parameters, then call proceeds in T38mode.

Else if the SIP Carrier does not accept it and sends an Error response, the following cases areenvisaged:

- Case 1: If the negotiated codec is G711 and the IP couplers are INTIP3/MG3 couplers, then OXEwill switch to G711 mode.

- Case 2: If the coupler in front of FAX is other than INTIP3/MG3 coupler, or if the negotiated codecis G729/G723, the call is disconnected.

Remark: If OXE is in transit position, the Error response will be relayed transparently.

At this moment, at the reception of Fax

signal thru G711 flow, step2 can happen

At the reception of the SIP error:

- either transmission is aborted- either transmission continues in G711

mode

- or step3 happens

200 OK : SDP (G711)

ACK

Fax communication starts in G711 mode

RE-INVITE : SDP (T38)

488 Not Acceptable Here

Fax communication continues in G711 mode

RE-INVITE : SDP (G711)

200 OK : SDP (G711)

Fax communication continues in G711 mode

INVITE: SDP (G711)

180 ringing

7/26/2019 TG0069_Ed12

22/155

OmniPCX Enterprise


Ed. 12 22 TG0069

OXE Carrier

8.9 Overview of PrivateSIP Transit modefeature

SIP Calls are handled by the OXE through the following software modules: The SIPMOTOR, it is in charge to relay and receive SIP request to or from the SIP Call handling The SIP Call Handling, it provides a protocol gateway between SIP and Q931 The Call Handling, it is the legacy part of the OXE, which handled the generic telephony features

It appears that, for instance, a call from an OT SIP device cannot call a SIP ABC-F 3rd Party applicationthrough OXE

Enhancement with OXE R11.0.1: Possibility to reach or being reachable from Open Touch by usingan OXE routing prefix, or also, between two OXE routing prefixes

Behavior before R11.0.1: for instance, when a call from an OT SIP device was performed atdestination of a 3rd Party Application (through SIP-ABC trunking), OXE uses the mode 4.2 and

generates a301 Moved Permanently

response. In some cases, if direct Trunk Group is notavailable to reach remote application, the call fails. Enhancement from R11.0.1: a Private SIP Transit Mode is added on the OXE management and can

take three different values

At this moment, OXE detects T38 mode

At the reception of Re-INVITE (T38),Carrier can:

- either accepts it with a 200 OK(T38)

-

INVITE : SDP (G711)

ACK

Fax communication starts in G711 mode

RE-INVITE : SDP (T38)

4xx / 5xx Response

Fax communication in G711 mode

180 RINGING

200 OK : SDP (G711)

ACK

OXE switches to

G711 mode

7/26/2019 TG0069_Ed12

23/155

OmniPCX Enterprise


Ed. 12 23 TG0069

o Proxy or redirect mode (prior functioning)

o Mixed mode (default value), 301 Moved Permanently

7/26/2019 TG0069_Ed12

24/155

OmniPCX Enterprise


Ed. 12 24 TG0069

o Full Call Handling mode

When an INVITE arrives to the SIP Motor, depending on its origin (UAC or calling user) and its destination, itcan be handled in four different ways :

mode 1 : Call Handling delivery

The call is delivered to the SIP Call Handling, and finally delivered to the Call Handling itself. This is themost usual way. In this case, the call inherits of various collateral features such as barring, metering, generalcall routing, and so on.

mode 2 : CAC SIP Call handling

The call is delivered to the SIP Call Handling, and remains in the SIP Call Handling, which relays the callthrough the SIP Motor. The call may be redirected as described in mode 4.1, and mode 3 would then apply.

mode 3 : Stateless proxy behavior

The call is directly relayed to the destination SIP End Point. The Call Handling is not involved in the call,which remains in the OXE as a proxy call.

mode 4 : Redirect proxy behavior

The call is first delivered to the SIP Call Handling ; there is then two different modes :

o mode 4.1 : 305.Use ProxyA 305.Use Proxy is sent back from the SIP Call Handling to the SIP Motor, which acts at that timeas a Stateless Proxy (mode 3).

o mode 4.2 : 301.Moved permanentlyA 301.Moved Permanently is sent back from the SIP Call Handling to the SIP Motor, and is relayedto the UAC. Consequently, the call is no more handled by the OXE. In other words, the UAC

7/26/2019 TG0069_Ed12

25/155

OmniPCX Enterprise


Ed. 12 25 TG0069

(calling user) is in charge to reach directly the destination user, by analyzing the Contact headers

URI of the 301.Moved Permanently.

8.10 SIP parameters explanation / under the object SIP:

8.10.1 SIP Trunk Group

WARNING : If you add additional SIP access to your SIP trunk group you MUST reboot thecall server, if you don't the newly added access will show F (free) in trkstat command BUTthey won't be used by the Call Server until next reboot.

The SIP Trunk Group is mandatory if you want to use the Local SIP gateway or an external SIP gateway (notnecessary for SEPLOS users).

The Trunk Group is used to give channels for SIP calls. According to its type and configuration, the availablefeatures are different.

Remark: for non AAPP/ALU applications, a SIP ISDN or SIP ABC trunk group can be used only undercontrol of TC1820 : Alcatel-Lucent OmniPCX Enterprise SIP Trunking with 3rd Party ( IVR & ContactCenter ) guideline. This guideline provides configuration and topologies supported by ALE.

Remark: for SIP Carrier, interworking with OXE must be validated by Christophe Haettinger and ALETechnical Support team. A survey must be filled by the carrier and according to the answers, an interworkingtest campaign will be proposed

Maximum number of SIP Trunk Groups : 300

Maximum number of pair of accesses per SIP Trunk Group : 16

Different types of SIP trunk Groups are available on OXE:

o The SIP ABCF Trunk Group. 992 simultaneous communications (62 per pair of access)

o The SIP ISDN Trunk Group. 992 simultaneous communications (62 per pair of access)

o The Mini SIP ABCF Trunk Group. 64 simultaneous communications (4 per pair of access)

o The Mini SIP ISDN Trunk Group. 64 simultaneous communications (4 per pair of access)

Level of service depending on used trunk group :o Call transfer

ISDN :Using re-INVITE in the opened dialog. ABC-F :Via REFER, referred-by and replaces .

o Call forward ISDN :Done internally. ABC-F :Redirecting with 3xx. New call has to be performed by remote party.

o Call barring ISDN :Same as ISDN.

ABC-F :No barring.

To create a SIP Trunk Group, go under /Trunk Groups

7/26/2019 TG0069_Ed12

26/155

OmniPCX Enterprise


Ed. 12 26 TG0069

Trunk Group Type : Select T2 for all the different types of SIP Trunk Group

Trunk Group Name : Manage a name for the SIP Trunk Group

Number Compatible With : Keep -1everytime, dont manage another value

Remote Network : Enter a Remote network number, for an ABCF TG, use the dedicated number, for ISDN TGkeep 255 (idem as legacy T2 ISDN Trunk group)

Node number : Enter the node number of your OXE

Q931 Signal variant : - For an ABCF SIP Trunk group, select ABC-F- For an ISDN SIP Trunk Group, select ISDN

Number Of Digits To Send : Keep 0everytime, dont manage another value

T2 Specification : - Select SIP for a SIP Trunk Group (ISDN or ABCF)- Select Mini SIP for a Mini SIP Trunk group (ISDN or ABCF)

Public Network COS : According to the value manage, the OXE will use the rights of the associated category

DID transcoding : This parameter is set to Trueonly in case of ISDN SIP Trunk Group (or Mini SIP ISDN TrunkGroup)

Associated Ext SIP gateway : Enter the external SIP gateway used if there is no DCT managed on the ARS route, the DCTfrom the ARS route is used in priorityFrom R10.1

To create a SIP Trunk Group, go under /Trunk Groups/Trunk Group

IP Compression Type : - Defaultmeans only the system algorithm used on SDP- G711means the use of the sytem algorithm and the PCM with the system lawParameter disappears from R11

Trunk COS : According to the value manage, the OXE will use the rights of the associated category

IE External Forward : Select Diverting leg informationif you want to use the History-Info or Diversion header FromR10.1

Max ABCF-IP and SIP connections : Maximum number of simultaneous voice connections allowed for this trunk group. 0 (defaultvalue) means no limitation. This parameter applies only to ABCF-IP and SIP trunk groups.Trkstattool is updated to indicate the value in real time (Max. Voice calls). From R11.0.1

To create a SIP Trunk Group, go under /Trunk Groups/Trunk Group/Virtual accesses for SIP

Number of SIP Accesses : Enter the number of SIP accesses needed on the SIP TG (value from 2 to 32)

8.10.2 The local SIP gateway

Used for the local SIP users (SIP Device) and the external Voice mail

To manage the Local SIP gateway, go under /SIP/SIP Gateway

SIP Subnetwork : Corresponds to the local SIP network (different than the ABC-F network and usedonlyfor thelocal SIP gateway).

SIP Trunk Group : Corresponds to the SIP Trunk group (better to use an ABCF SIP Trunk group)

IP Address : Corresponds to the IP address of the CPU (autofill)

Machine nameHost : Corresponds to the nodename associated to the main IP address (managed via netadmin -

autofill).

SIP Proxy Port Number : Corresponds to the SIP port number (by default 5060).

7/26/2019 TG0069_Ed12

27/155

OmniPCX Enterprise


Ed. 12 27 TG0069

SIP Subscribe Min Duration : Corresponds to the minimum duration of a SIP subscription (for message waiting indication orfor result of a transfer).

SIP Subscribe Max Duration : Corresponds to the maximum duration of a SIP subscription (for message waiting indication orfor result of a transfer).

Session Timer : Corresponds to the timer value to supervise an active SIP session. A RE-INVITE or UPDATEmessage is sent before SIP Session Timer expiry (for all SIP elements).

Min Session Timer : Corresponds to the mimimum session timer value accepted by the OXE. When a SIP call isestablished, the session timer is negociated between the two parties.

Session Timer Method : Corresponds to the method used for session timer, the OXE sends a RE-INVITE or anUPDATE message.

DNS local domain name : Corresponds to local DNS suffix used for SIP. The FQDN of the OXE is the nodename + thisdomaine name (mandatory in case of spatial redondancy).

DNS type : Corresponds to the DNS mode (A or SRV).

SIP DNS1 IP Address : IP address of the first DNS server. Dont manage the CPU IP address

SIP DNS2 IP Address : IP address of the second DNS server.Dont manage the CPU IP address

SDP in 18x : Used to put SDP information on th 18x sent by the OXE.

Cac SIP-SIP : To allow or not, the domains control in SIP to SIP communications.

INFO method for remote extension : Using the INFO method for DTMF in case for the Nokia Call Connect (NCC) only.

Dynamic Payload type for DTMF : Payload value used for DTMF, default value 97 (used by the SIP device for instance).

8.10.3 The external SIP gateways

Maximum number of External Gateways : 1000Maximum number of External Gateway Pool : 5Maximum number of External Gateway per Pool : 2

Used to connect external SIP equipments // applications (SIP provider, Call centre application, etc).

SIP External Gateway ID : Id of the gateway

Gateway Name : Name given to the gateway

SIP Remote domain : IP address or FQDN of the remote SIP equipment (if FQDN, need to use a DNS server)

PCS IP Address : PCS IP address used to backup this gateway in case of link failure with the CPU

SIP Port Number : SIP port number used to send SIP messages on the remote gateway

SIP Transport Type : Transport type for SIP messages (UDP or TCP)

Belonging Domain : Used to define the domain part of the URI (FROM and PAI) on the SIP message

Registration ID : Registration id used on the user part if the remote gateway needs it

Registration ID P_Asserted : Used the registration ID on the P_Asserted Identity (PAI)

Registration timer : Timer used for registration (0 = no registration)

SIP Outbound Proxy : Send the messages (INVITE and REGISTER) on this address

Supervision timer : Used to supervised the remote gateway (OPTION message sent)Trunk group number : SIP trunk group used for this SIP gateway

Pool Number : Can associate 2 external SIP gateways in one pool (Load Balancing)

7/26/2019 TG0069_Ed12

28/155

OmniPCX Enterprise


Ed. 12 28 TG0069

Outgoing realm : Realm of the remote gateway (Outgoing messages authentication)

Outgoing username : Username from the remote gateway (Outgoing messages authentication)

Outgoing Password : Password from the remote gateway (Outgoing messages authentication)

Incoming username : Username used by the remote gateway (Incoming messages authentication)

Incoming Password : Password used by the remote gateway (Incoming messages authentication)

RFC 3325 supported by the distant : PAI supported for Outgoing calls

DNS type : DNS requests types (A or SRV)

SIP DNS1 IP Address : IP address of the first DNS server Dont manage the CPU IP address

SIP DNS2 IP Address : IP address of the second DNS server Dont manage the CPU IP address)

SDP in 18x : Used to put SDP information on the 18x sent by the OXE. Recommended value is False whenPRACK/UPDATE methods are not supported by remote domain

Minimal authentication method : Used to activate or not the authentication (DIGEST or SIP none)

INFO method for remote extension : Using the INFO method for DTMF in case of remote extension

Send only trunk group algo : Used to send only the algorithm managed on the SIP TGParameter disappears from R11

To EMS : Used to activate the RFC4916 (Add specific fields for identification on EMS)

SRTP : Used in case of SIP TLS to select the RTP mode (secured or not)

Routing Application : - False: SDP sets on the SIP messages (INVITE, 200ok...)- True: No SDP on the SIP messages, this parameter is used for some specific configuration forcarriers

Ignore inactive/black hole : Only for SIP ABC-F.- False means that the receipt of a Re-INVITE, whose SDP indicates either inactive or c=0.0.0.0is handled as an Hold request.- True means that the same kind of Re-INVITE leads the RTP flow towards the remote party tobe cut.

Contact with IP address : In case of spatial redundancy with dual subnetworks, the IP address of the main Call Server isput on the Contact field instead of the FQDN of the OXE

Dynamic Payload type for DTMF : Corresponds to the payload value for DTMF must be the same than value from the remote SIPequipment.

100 REL for Outbound Calls :- Not supported : Outbound INVITE doesnt indicate 100Rel parameter.- Supported : Default Value. Outbound INVITE indicates 100Rel in Supported header.- Required : Outbound INVITE indicates 100Rel in Requiredheader.

100 REL for Incoming Calls : - Not requested : Default value. 18x response triggered from OXE doesnt indicate 100Rel inRequireheader.- Required mode1 : 18x response triggered from OXE indicates 100Rel in Requireheader

only if it provides SDP.- Required mode2 : 18x provisional response triggered from OXE indicates 100Rel in Require

header.

Gateway type : Use to define if the remote SIP gateway is un Open Touch or not, keep default configuratiuon ifit is not a Open Touch

Re-Trans No. for REGISTER/OPTIONS : Number of retransmission of SIP REGISTERs/OPTIONs messages, from 1 to 10

P-Asserted-ID in Calling Number : - If True, Calling Number is filled from P-Asserted-ID header- If False, Calling Number is filled from FROM header.

Trusted P-Asserted-ID header : Octet3a_Calling is filled based on this parameter (Used, only when there is P-Asserted-IDheader)

To EMS parameter must be set to false

7/26/2019 TG0069_Ed12

29/155

OmniPCX Enterprise


Ed. 12 29 TG0069

Diversion Info to provide via : In the Outbound INVITE the selected Header is added to provide information about Call

deflection/forward. The OXE can use History-Info (RFC 4244) or Diversion (RFC 5806)

Proxy identification on IP address :- ifTrue, a dynamic DNS cacheper SIP External Gateway is handled by OXE to store the IPaddress(es) where Register and further INVITE may be sent. At the beginning of the procedure,this DNS cache is empty. From R10.1

Outbound calls only :-if False, the existing procedure applies.- If True, the External Gateway is skipped during the lookup procedure of the origin of the call.

The way to determine the origin of an inbound call, e.g. the External Gateway it comes from, ismade in such a way that in that topology, the lowest External Gateway, in term of numbering, ischosen. From R10.1

SDP relay on Ext. Call Fwd : In case of SIP trunk to SIP trunk call rerouting (essentially external to external call forward), inorder to adapt specific SIP profile, OXE offers the possibility to transit SDP answers received in180 or 183 on outgoing leg only in 180 answer on incoming leg.- Default : normal procedure apply. SDP can transit with 183 message depending on call flow.

- 180 only : any SDP received in 180 and 183 on outgoing leg will not transit on incoming leg in183 provisional answer but only in 180 ringing one.From R10.1

SDP Transparency override : if TRUE, the SDP offer received from SIP leg1 is enhanced towards SIP leg2 in the followingway:- G729 only received from SIP leg1, a G729/G711 offer is relayed to SIP leg2- G729 is not received from SIP leg1, in that case, the original offer received might be single

(G711 A or G711 Mu) or multiple (G711 A + G711 Mu, or G722 + G711 ) G729 is added inthe offer provided to leg2 From R10.1More details on section 9.6

RFC 5009 supported / Outbound call :support of the P-Early-Media header in the SIP-ISDN call, can be configured at:- Not supported: for outgoing call, P-Early Media header will not be included- Mode1: for outgoing call, P-Early-Media: Supported header will be added in INVITE

method. If OXE receives a provisional response without P-Early-Media in this message orbefore, the SDP, if any, in the provisional response will not be connected to OXE user

- Mode 2: for outgoing call, P-Early-Media:Supported header will be added in INVITE

method. If OXE receives a provisional response without P-Early-Media in this message orbefore, the SDP, if exists, in the provisional response will be connected to OXE user FromR11

Nonce caching activation when authentication is activated on SIP Carrier side, then depending on this parameter value:- No: the OXE does not provide any Authorization header, neither in Register, nor in INVITE- Yes: the OXE provides in each REGISTER and INVITE an Autorization header, containing

the last nonce received from the carrier, and increments the associated nonce counteraccordinglyFrom R11

Fax procedure type choose the mode of Fax transmission :- T38 only: Fax will be transmitted in T38 mode. If the remote party did not support this

mode, the call will be disconnected- G711 only: if the initial call is established with G711 Mode and if the IP Coupler of the

compressor is NGP coupler, Fax will be established with G711. Otherwise, Fax will beestablished in T38.

- T38 to G711 fallback: the FAX will try to establish in T38 Mode. If the remote party doesnot support T38 mode, it will send Error message. In this case, if the initial call isestablished with G711 and the IP coupler of the compressor is NGP coupler, FAX willswitch to G711 Mode. Otherwise, call will be disconnected. From R11More details onsection 8.7

Trusted From header : Octet3a_Calling is filled based on this parameter (Used only when there is no P-Asserted-IDheader). To be used when calling number is found in FROM header and should be consideredas trusted by the system.

Support Re-invite without SDP :- ifTrue, the OXE will send a RE-INVITE without SDP to provide transfer, depending on theOXE release:

From R10.1, it applies to transfer of two SIP ISDN remote parties. From R10.1.1, it applies to transfer of two SIP ISDN remote parties, and to SIP

TLS / sRTP. From R11, it applies to each transfer involving at least one SIP ISDN remote part.

- ifFalse, the OXE will send a REINVITE with SDP.

Type of codec negotiation : this is the type of format of SDP offer for outgoing calls on this gateway:

Restriction with R10.x: When PRACK is supported, this parameter must be set to False

7/26/2019 TG0069_Ed12

30/155

OmniPCX Enterprise


Ed. 12 30 TG0069

- Default: everything is allowed- Single codec G711, only G711 is offered (sometimes with G722)- Single codec G729, only G729 is offered- From domain, if coming from a restricted domain, only G729 is offered, else a list is offeredFrom R11More details on section 9.5

Registration on proxy discovery :- ifTrue, used when SIP Carrier provides more than one outbound proxy. As soon as, oncarrier side a switch happens from one proxy to another, calls can be neither delivered to OXE,nor accepted by the carrier as long as a new registration is not triggered by OXE. From R11

DNS SRV/Call retry on busy server :- if0, the receipt of 486 Busy Here response from the relevant external gateway launches therelease procedure.- if different than 0, and DNS SRV is supported, the relevant external gateway re-launches theINVITE to the next IP@ of the current DNS cache.- Else, the release procedure applies. From R11.0.1

Unattended Transfer for RSI :- ifFalse, the normal mechanism service remains and the signaling path is kept between OXEand Carrier as a transit call.

- if True, in case where incoming call is coming from SIP-ISDN and route select occurs whencall is established (play guide), if target transfer is reachable through SIP-ISDN, REFER methodis used and the OXE leaves the signaling path.- Else, the normal mecanishm with RE-INVITE occurs.From R11.0.1

Redirection functionality :This parameter applies only for customers with a private SBC.- If True, all incoming calls whose destination indicates another node of the network, arererouted to the SBC with a 301 Moved Permanently response, to avoid the use of the IP-ABCFlink. The SBC must be able to resolve the contact Domain Part which is hardcodec like this:oxe_node_xx where xx is the remote node number- If False, all incoming calls are handled by the local node, whatever the location of thedestination user. From R11.0.1

Attended Transfer - If True, the REFER method applies for SIP offnet/offnet attended transfer and the OXE leavesthe signalling path.- If False, the RE-INVITE method applies for SIP offnet/offnet attended transfer and OXE

remains in the signalling path. From R11.0.1

8.10.4 Timer usage for SIP Trunking (Trunk Categoy, by default 31)

This only applies to SIP Trunking Call Handling where generic timers are used

Timer Value MeaningTimer T302 15s Related to SETUP_ACKTimer T303 10s Related to Call ProcessTimer T304 90s Related to INFOTimer T305 4s Related to DisconnectTimer T308 4s Related to Release CompleteTimer T309 90s

Timer T310 20s Related to ALERTTimer T313 4s Related to Connect_ACKTimer T306 6s Related to BYETimer T314 2sTimer T383 5sTimer T389 8sTimer T392 1sTimer T397 5s

8.10.5 The SIP proxy

Used to activate some parameters linked to the Proxy (SIP authentication for instance)

SIP initial time-out : This attribute specifies the initial value in milliseconds of the request/reply SIP messageretransmission timeout corresponding to T1. Default value 500ms

SIP timer T2 : This attribute specifies the maximum time in milliseconds between two SIP messageretransmissions. Default value 4000ms

7/26/2019 TG0069_Ed12

31/155

OmniPCX Enterprise


Ed. 12 31 TG0069

Dns Timer overflow : Timer used to overflow from DNS 1 to DNS 2

Timer TLS : This attribute is used to define the keep alive for TLS

Recursive search : This attribute is used to define the behavior of the proxy on reception of a redirection message.(NOT CURRENTLY USED)

- YES: the proxy handles redirection.- NO: the proxy leaves the caller to handle redirection.

Minimal authentication method : Activation of the Proxy authentication- SIP none, there is no authentication- SIP Digest, the authetication is validated

Authentication realm : Corresponds to the authentication SIP domain on the OXE

Only authenticated incoming calls : Activation of the SIP authentication for incoming calls

Framework Period : Indicates the basic time for an observation period before to put the IP address in quarantine (3s bydefault).

Framework Nb Message By Period : Indicates the maximum number of received messages during the time of the observationperiods which may put the IP address in quarantine (25 messages by default).

Framework Quarantine Period : Indicates the periods number before to put the IP address in quarantine (1800s by default)

TCP when long messages : This parameter is used when UDP is used as transport protocol, to allow or not the use of TCP forlong messages. This parameter applies to external gateways, SIP extensions, SIP devices and SIPexternal voice mails.

- True (default value): TCP is used, rather than UDP, when the message size is higher than themaximum size (1300 bytes)- False: UDP is used, whatever the size of messages.

Retransmission number for INVITE : This Attribute corresponds to the number of INVITE retransmission, from 1 to 6

SIP timers explanation:

Timer Value Meaning

Timer 1 500 ms Round-trip time (RTT) estimate

Timer 2 4000 msThe maximum retransmit interval for non-INVITE requestsand INVITE responses

Timer 4 5000 ms Maximum duration a message will remain in the networkTimer A Initially T1 INVITE request retransmit interval, for UDP onlyTimer B 64 *T1 INVITE transaction timeout timerTimer C > 3 min Proxy INVITE transaction timeout

Timer D32s for UDP0s for TCP

Wait time for response retransmits

Timer E Initially T1 Non-INVITE request retransmit interval, UDP only

Timer F 64 *T1 Non-INVITE transaction timeout timerTimer G Initially T1 INVITE response retransmit intervalTimer H 64 *T1 Wait time for ACK receipt

Timer IT4 for UDP0 s for TCP

Wait time for ACK retransmits

Timer J64* T1 for UDP0 s for TCP

Wait time for non-INVITE request retransmits

Timer KT4 for UDP0 s for TCP

Wait time for response retransmits

8.10.6 SIP Registrar

Used to manage the registration timers

SIP Min Expiration Date : Minimum lifetime of a record accepted by the Registrar (in secondes). Default value 1800.

SIP Max Expiration Date : Maximum lifetime of a record accepted by the Registrar (in secondes). Default value 86400.

7/26/2019 TG0069_Ed12

32/155

OmniPCX Enterprise


Ed. 12 32 TG0069

The minimum value must not be under 420 (7 minutes). The REGISTER must not be used asa keep alivemechanism. 900 (15 minutes) is a minimum acceptable value.

8.10.7 SIP Dictionnary

Corresponds to the SIP users created on the OXE, this dictionnary is fill up automatically when a SIP user iscreated, entries on this dictionnary can be created manually if needed (Not used), but the purpose of thisobject is to be able to modify one entry already created or to add aliases

Directory Number : Corresponds to the directory number of Station, Network number or Vmail number.

Alias No. : Can create different alias for the same directory number

SIP URL Username :User part of the URL. SIP identifies users by their URLs (Universal Resource Locator), composed ofa user part and a domain part (user@domain).

SIP URL Domain : Domain part of the URL. SIP identifies users by their URLs, composed of a user part and a domainpart (user@domain). If the domain part is omitted on creation of a set, the domain part of theinstallation URL is used (SIP/SIPgateway).

SIP URL Type : Corresponds to the user type (SIP extension or SIP Device).

SIP URL Origin : Corresponds to the origin node.

8.10.8 SIP Authentication

Used to modify the password of a entry created automatically (SIP user for instance)Directory Number : Directory number of the entry selected (not modifiable)

SIP Authentication : SIP login associated to the entry (not modifiable)

SIP Passwd : Enter a new password if needed

Confirm : Confirmation of the new password entered

8.10.9 Quarantined IP Addresses

Used to put the IP addresses of the SIP equipments you want to put in quarantined manually, SIP messagesfrom these addresses are dropped silently.

8.10.10 Trusted IP Addresses

Used to put the IP addresses of the SIP equipments not affected by the quarantined mechanism. If aftermanagement the communication with this SIP equipments is still rejected by the OXE, restart theSIPMOTOR processes.

7/26/2019 TG0069_Ed12

33/155

OmniPCX Enterprise


Ed. 12 33 TG0069

8.10.11 SIP To CH Error Mapping

Used to link the error SIP messages to the ISDN Q850 causes, for each error SIP message, you select oneQ850 cause

A default configuration is done. Without specific needs, no modifications have to be made.

8.10.12 CH To SIP Error Mapping

Used to link the ISDN Q850 causes to the error SIP messages, for each Q850 cause, you select error SIPmessage.

A default configuration is done. Without specific needs, no modifications have to be done.

8.11 SIP parameters explanation / under the object USERS:

8.11.1 SIP Device

The SIP Device is used for voice SIP calls and FAX SIP calls. The SIP Device is considered as an ExternalSIP user, so the features are limited (same as SIP TG)

SIP Device creation

Directory Number : Corresponds to the directory number of the SIP Device

Set Type : Select SIP device for the type of set

URL UserName : The user name corresponds to the SIP Device directory number - autofill

Unallocated numberUser busyNo user respondingCall rejectedInvalid number formatNo circuitTemporary failureBearer cap. not implementedIncompatible destinationOthers

Unallocated number Channel type not implementedNo route to specify transit NW Req facility not implementedNo route to destination Only Rest Digi Info Becap AvailFrance Specific Option not implementedDenmark Specific Invalid call reference value

Channel unacceptable Identified channel does not existCall awarded - deliv in estab channel Susp Call Exists But Call IdentReserved MLPP Call Identity in useNormal call clearing No call suspendedUser busy Call having req call ID clearedNo user responding Japan SpecificNo answer from user Incompatible destinationCall rejected Invalid transit network selectionNumber changed Invalid messageNonselected user clearing Mandatory info element missingDestination out of order Msg type non-exist or not implInvalid number format Message not compat with call stateFacility rejected Info element non-exist or not implResponse To STATUS INQUIRY Invalid info element contentNormal unspecified Recovery on timer expirationNo circuit Protocol error

Network out of order InterworkingTemporary failure...

Not foundGoneTemporarily unavailableAddress IncompleteBusy hereNot acceptable hereServer internal errorNot implementedBad gatewayService unavailableDecline

Bad request Request terminatesUnauthorized Not acceptable herePayment required Server internal errorForbidden Not implementedNot found Bad gatewayMethod not allowed Service unavailableNot acceptable Server timeoutProxy authentication required Version not supportedRequest timeout Busy everywhereConflict DeclineGone Does not exist anywhereLength required Not acceptRequest entity...

7/26/2019 TG0069_Ed12

34/155

OmniPCX Enterprise


Ed. 12 34 TG0069

URL Domain : Corresponds to the OXE domaine name (nodename) - autofill

SIP Authentication : The user name corresponds to the SIP Device directory numberautofill

External Gateway Number : Used in case of Open Touch configuration. Defines the external Gateway number to reach the OT

Gateway type : Used in case of Open Touch configuration. Defines the gateway type to reach the OT

In normal use, only the Directory Number and the set type are managed, the other parameters canbe modified only if needed

The SIP device is linked to the local SIP gateway

The local SIP gateway must be managed and is in service to be able to make and receive calls

With the current Linux OS, OXE has a limitation in handling more than 1000 data equipment if itis connected in the same sub-network. So we need to have a seperate VLAN in between tohandle this. OXE CS must be placed under separate subnet and the IP Phones distributed over

different other subnets

All unnecessaries subscriptions must be deactivated on SIP Devices when service is notavailable on OXE. Example: Voicemail notifications

8.11.2 SIP Extension (or SEPLOS)

The SIP Extension is used only for voice calls. It is considered as an Internal SIP user so it is possible to usephone features and facilities from the OXE.

It is not necessary to manage the local SIP gateway if you want to use it. Only the proxy has to be (for

authentication)

SIP Extension creation

Directory Number : Corresponds to the directory number of the SIP Extension

Set Type : Select SIP extension for the type of set

URL UserName : The user name corresponds to the SIP Extension directory number - autofill

URL Domain : Corresponds to the OXE domain name (nodename) - autofill

SIP Authentication : The user name corresponds to the SIP Extension directory numberautofill

Other SIP extension parameters

- Under /users/ IP SIP Extension:

Set Type : Type of set displayed (SIP extension or SIP device)

IP Address : IP address of the SIP equipment displayed (information retrevies from the registrar)

- Under /users/ SIP Extension Parameters:

Phone COS : Corresponds to the SIP phone class of service and not the normal phone class of service(explanation later)

The SIP extension can be created as a businessuser or roomuser in case of hospitality. Oneof the difference it that in case of business mode, the SIP extension is multiline (not

manageable) and in case of roommode , the SIP extension is monoline.

7/26/2019 TG0069_Ed12

35/155

OmniPCX Enterprise

TROUBLESHOOTING GUIDE No. 0069

Date post:	02-Mar-2018
Category:	Documents
Upload:	dhexter-villa
View:	379 times
Download:	32 times

TG0069_Ed12

Documents