TC2824 OpenIP France SIP Trunk Solution Configuration ...

Legal notice:

www.al-enterprise.com The Alcatel-Lucent name and logo are trademarks of Nokia used under license by ALE. To view other

trademarks used by affiliated companies of ALE Holding, visit: www.al-enterprise.com/en/legal/trademarks-copyright. All

other trademarks are the property of their respective owners. The information presented is subject to change without notice.

Neither ALE Holding nor any of its affiliates assumes any responsibility for inaccuracies contained herein.

© Copyright 2020 ALE International, ALE USA Inc. All rights reserved in all countries.

Technical Bulletin OmniPCX Enterprise

TC2824 ed.01 Release 12.4 and above

OpenIP France SIP Trunk Solution

Configuration Guideline and Interworking tests

This document details how to set up an OmniPCX® Enterprise R12.4 for enabling a public SIP trunk with OpenIP France.

This document describes also the interworking tests between the OmniPCX® Enterprise and the SIP Provider.

Revision History

Edition 1: November 30, 2020 creation of the document

OmniPCX Enterprise - Release 12.4 and above

OpenIP France SIP Trunk Solution Configuration Guideline and Interworking tests TC2824 ed.01 © Copyright 2020 ALE International, ALE USA page 2/98

Table of contents

1 General .................................................................................................................................................. 5

1.1 References ....................................................................................................................................... 5

1.2 Scope & usage of the configuration guide .......................................................................................... 5

1.3 Scope of Alcatel-Lucent Enterprise’s support ..................................................................................... 5

1.4 Software/ Hardware components on customer's infrastructure ........................................................... 5

1.5 Supported topology .......................................................................................................................... 6

2 Summary of tests results ......................................................................................................................... 7

2.1 Summary of main functions supported ............................................................................................... 7

2.2 Summary of problems ....................................................................................................................... 9

2.3 Summary of limitations ..................................................................................................................... 9

2.4 Notes, remarks ................................................................................................................................. 9

3 Tests results ......................................................................................................................................... 10

3.1 REGISTRATION, AUTHENTICATION & KEEP ALIVE ........................................................................... 13

3.1.1 Registration .............................................................................................................................. 15 3.1.1.1 Registration on SIP Provider without authentication ..............................................................................15 3.1.1.2 Registration on SIP Provider with authentication ..................................................................................16

3.1.2 Authentication on basic calls ...................................................................................................... 17 3.1.2.1 Authentication on outgoing calls .........................................................................................................17 3.1.2.2 Authentication on incoming calls .........................................................................................................19 3.1.2.3 Incorrect Authentication on outgoing calls ...........................................................................................20

3.1.3 Keep Alive ................................................................................................................................ 21

3.1.4 Transport type (UDP & TCP) and Switch UDP to TCP .................................................................. 22

3.1.5 Service Route and Path headers ................................................................................................ 23 3.2 BASIC OUTGOING VOICE CALLS ...................................................................................................... 24

3.2.1 Outgoing calls to PSTN / GSM sets (national and international) .................................................... 24 3.2.1.1 Outgoing calls to PSTN / GSM sets: Establishment of call, Audio & Display ..............................................24 3.2.1.2 Outgoing calls to PSTN / GSM sets: The Early media SDP negotiation (ringing state) ...............................27 3.2.1.3 Outgoing calls to PSTN / GSM sets: The Codecs Media SDP negotiation ..................................................30 3.2.1.4 Outgoing calls to external sets: Local user ends the conversation...........................................................31 3.2.1.5 Outgoing calls to external sets: external set ends the conversation ........................................................32

3.2.2 Outcall phase and call clearing before answer ............................................................................. 33

3.2.3 Call to an incorrect number ....................................................................................................... 34

3.2.4 Call to a busy set ...................................................................................................................... 35

3.2.5 Outgoing calls from Anonymous Calling ...................................................................................... 36

3.2.6 Outgoing long calls ................................................................................................................... 37 3.3 BASIC INCOMING VOICE CALLS....................................................................................................... 38

3.3.1 Incoming public calls from PSTN / GSM sets (national & international) ......................................... 38 3.3.1.1 Incoming public calls with CLI: establishment of call, audio & display .....................................................38 3.3.1.2 Incoming public calls with CLI: The Early media SDP negotiation ...........................................................41 3.3.1.3 Incoming public calls with CLI: The Codecs Media SDP negotiation ........................................................43



3.3.2 Ringing phase and call clearing before answer ............................................................................ 44

3.3.3 Incoming calls from Anonymous Calling ..................................................................................... 45

3.3.4 Incoming long calls ................................................................................................................... 46 3.4 OXE User in forward (internal or external) ........................................................................................ 47

3.4.1 Incoming calls: Immediate forward to internal user .................................................................... 47

3.4.2 Incoming calls: OXE User in immediate forward to external set .................................................... 48

3.4.3 Incoming calls: Forward on no answer to external set ................................................................. 52 3.5 OXE User not available .................................................................................................................... 54

3.5.1 Incoming public call: OXE user in “Do Not Disturb” ..................................................................... 54

3.5.2 Incoming public call: OXE non-attributed number ....................................................................... 55

3.5.3 Incoming public call: OXE user is Busy ....................................................................................... 56 3.6 Advanced features for communications ............................................................................................ 57

3.6.1 Call on Hold / Retrieve .............................................................................................................. 57

3.6.2 Call on Mute ............................................................................................................................. 59

3.6.3 Early Attended transfer (on ringing): transfer to internal user ...................................................... 60

3.6.4 Early Attended transfer (on ringing): transfer to external set ....................................................... 61

3.6.5 Supervised call transfer (after answer): transfer to internal user .................................................. 64

3.6.6 Supervised call transfer (after answer): transfer to external set ................................................... 65

3.6.7 Conference (3-Party) ................................................................................................................. 68

3.6.8 DTMF ....................................................................................................................................... 69 3.6.8.1 DTMF for outgoing call .......................................................................................................................69 3.6.8.2 DTMF for incoming call ......................................................................................................................71

3.6.9 Call Admission Control ............................................................................................................... 72 3.7 FAX Transmission............................................................................................................................ 73

3.7.1 FAX Transmission with analog FAX machine attached on OXE ...................................................... 73

3.7.2 FAX Reception with analog FAX machine attached on OXE .......................................................... 75

3.7.3 FAX Transmission from FAX Server ............................................................................................ 77

3.7.4 FAX Reception from FAX Server ................................................................................................. 78

4 “SIP-Provider name” SIP Trunk Solution Configuration ............................................................................ 79

4.1 OmniPCX Enterprise configuration .................................................................................................... 79

4.1.1 Signaling protocol and number of physical channels .................................................................... 79

4.1.2 Trunk Configuration .................................................................................................................. 79 4.1.2.1 Trunk Group .....................................................................................................................................79 4.1.2.2 Trunk Group local parameters.............................................................................................................80 4.1.2.3 Trunk Group NPD selector ..................................................................................................................80 4.1.2.4 Trunk Group COS and Timers .............................................................................................................80

4.1.3 ARS Configuration ..................................................................................................................... 81 4.1.3.1 ARS Prefix .........................................................................................................................................81 4.1.3.2 ARS Route list and ARS Route .............................................................................................................81 4.1.3.3 Time Based Route List .......................................................................................................................82 4.1.3.4 Numbering Command Table ...............................................................................................................82 4.1.3.5 NPD .................................................................................................................................................82

4.1.4 External Callback Translator ...................................................................................................... 83

4.1.5 SIP Gateway and SIP Proxy Configuration .................................................................................. 84 4.1.5.1 SIP Gateway .....................................................................................................................................84



4.1.5.2 SIP Proxy ..........................................................................................................................................84 4.1.5.3 SIP Registrar .....................................................................................................................................85 4.1.5.4 Trusted IP addresses .........................................................................................................................85

4.1.6 SIP External Gateway Configuration ........................................................................................... 85

4.1.7 System Parameters Configuration .............................................................................................. 87 4.2 OTSBC configuration ....................................................................................................................... 88

4.2.1 Initial OTSBC configuration using Wizard .................................................................................... 89

4.2.2 Additional parameters ............................................................................................................... 94

4.2.3 Message Manipulation ............................................................................................................... 94

4.2.4 OTSBC Configuration INI file ..................................................................................................... 94

5 Appendix A: RFCs supported by OmniPCX Enterprise and general limitations ............................................ 95

5.1 RFCs supported by OmniPCX Enterprise ........................................................................................... 95

5.2 General Limitations ........................................................................................................................ 96



1 General

This document details the process for configuring from scratch a public SIP Trunk of the SIP provider on a

system OXE R12.4.

1.1 References

Alcatel-Lucent documentation available on the Business Partner Web Site: [1] Alcatel-Lucent OmniPCX Enterprise Communication Server R12.4 – Technical Documentation [2] Technical Bulletin TC2005 – Certified SIP providers for OpenTouch and/or OmniPCX Enterprise [3] Troubleshooting Guide TG0069 – OmniPCX Enterprise – Session Initiation Protocol (SIP) [4] Alcatel-Lucent OpenTouch Session Border Controler R2.3 – Recommended Security Guidelines

Configuration Note

1.2 Scope & usage of the configuration guide

This guide is intended for engineers who are familiar with mgr, OmniVista 8770, OpenTouch and with the

very basic set up of the IPBX. Therefore, well-known configurations like that for the IP-LAN or for "Traffic

Sharing and Barring" are just reminded without any details.

1.3 Scope of Alcatel-Lucent Enterprise’s support

The support delivered for this SIP Trunk solution is strictly delimited by the approval context and the system

configuration detailed in this document. The protocol and the functional aspects of the SIP trunk are in the

scope, but not the audio quality of calls for the part incumbent on the SIP provider or on the client's

infrastructure.

1.4 Software/ Hardware components on customer's infrastructure

INFRA COMPONENT MODEL VERSION (min compatible)

OXE OmniPCX Enterprise

R12.2-M3.402.27.a

Tests and parameters in document

R12.4-M5.202.7.c

OTSBC (if part of Topology) Not used

For OXE Users, all tests are done with:

- Alcatel-Lucent Enterprise IP Phone (Noe mode : 8xx8 series)

- One analog FAX

- One FAX Server.



Following user sets have been used during validation:

Directory Number Type Description Entity

70011 IP phone IPDSP 2

70013 IP phone Micro-SIP 2

Analog Fax FAX copieur Canon IR ADV C3525 2

FAX Server

Depending on the suggested tests, external user could be one of the 4 set types:

- A PSTN National set

- A PSTN International set

- A GSM National set

- A GSM International set

Important remark: when in tests the “external set” term is used, it means that any of these

above set types is used for the tests.

1.5 Supported topology

Topology C



2 Summary of tests results

2.1 Summary of main functions supported

Test

# Features Result Comments

REGISTRATION, AUTHENTICATION, KEEP ALIVE AND

SYSTEM PARAMETERS

Registration on SIP Provider:

#111 Registration without authentication NA

#112 Registration with authentication OK

Authentication on basic calls:

#121 Authentication for outgoing calls OK DIGEST method

#122 Authentication for incoming calls NA

#123 Incorrect Authentication on outgoing calls OK

System Parameters:

#131 Keep Alive OK

#141 Session Timer RFC 4028 OK

#151 Transport type and Switch UDP to TCP OK UDP only

#161 Service Route and Path headers OK

BASIC VOICE CALLS

Outgoing calls to PSTN/ GSM sets:

#211

#212

#213

Simple call:

- Call establishment, audio & display set

- Early Media SDP negotiation (ringing state)

- Codecs Media SDP negotiation

OK

#214 Trunk released by local user OK

#215 Trunk released by external set OK

#221 Outgoing phase & call clearing before answer OK

#232 Outgoing call to an Incorrect Number OK 480 Temporarily not available

#241 Outgoing call to a User Busy OK

#251 Outgoing call from OXE anonymous set OK Privacy: user

#261 Outgoing long call OK RFC 4028/ RE-INVITE

Incoming calls from PST/ GSM sets:



Remark: results are marked as "OK" (for full support), or "WR" (support With Restriction), or "NOK" (for Not OK), or “NA” (for Not Applicable) or "NT" (for Not Tested).

#311

#312

#313

Simple call:

- Establishment & release, audio & display set

- Early Media SDP negotiation (ringing state)

- Codecs Media SDP negotiation

OK

#321 Incoming phase & call clearing before answer OK

#331 Anonymous incoming calls OK

#341 Incoming long call OK Method: Re-INVITE

Forward:

#411 Immediate Forward to internal user OK

#421 Immediate forward to external user OK 181 Forwarded/ History-Info

#431 Forward on no answer to external user OK 181 Forwarded/ History-Info

Subscriber not available:

#511 User in “Do not disturb” OK 486 Busy Here

#521 Non-attributed OXE user number OK 404 Not Found

#531 User busy OK 486 Busy Here

ADVANCED FEATURES FOR COMMUNICATION

#611 Enquiry call (call hold / call retrieve) OK a=sendonly

#621 Call on Mute OK

#631 Early attended transfer to internal user (on ringing) OK

#641 Early attended transfer to external set (on ringing) OK

#651 Supervised call transfer to internal user OK

#661 Supervised call transfer to external set OK

#671 Conference OK

#681

#682

DTMF for outgoing call

DTMF for incoming cal (Immediate forward to VM) OK RFC4733

#691 CAC OK

FAX TRANSMISSION

#711 Fax Machine transmission OK G711 transparent

#721 Fax Machine reception OK G711 transparent

#731 Fax Server transmission NT

#741 Fax Server reception NT



2.2 Summary of problems

2.3 Summary of limitations

2.4 Notes, remarks

Initial tests have been done with OXE release R12.2-M3.402.27.a. This is the minimum version guaranteed

for this interoperability certification.

Otherwise, the same tests have been performed with OXE release R12.4-M5.202.7.c. Configuration

parameters in current document is based on this R12.4 release.



3 Tests results

This chapter is a test descriptive to be used to validate the SIP trunking interface of the Alcatel-Lucent

OmniPCX Enterprise systems.

The test suite here will allow to check the behavior of SIP system features (Registration, Authentication,

Keep Alive …) and SIP user services (Basic call, CLIP/CLIR, Call Forwarding, Call Hold, Transfer, DTMF …) in

OXE / SIP provider interworking i.e check the compliance of the SIP implementation with OXE and the SIP

provider network.

Please carefully read the following if you have to complete this interworking report, as SIP Provider

certifier.

There are two kinds of tests:

1- Test performed WITH the “Test Case #xxx”, as indicated in the example below:

Test

Case Id Test Case #xxx N/A OK NOK Comment

1

Configuration

Action 1

Action 2

Action n

2

Test scenario

Action 1

Action 2

Action n

3

Check

Action 1

Action 2

Action n

In these tests, it is indicated “Test Case #xxx”

There are in general the “configuration” part, then “test scenario” part and then, “Check” part.

For these tests, sipmotor traces are requested for the certification.

For each test, sipmotor traces have to be done as below:

motortrace 3

traced >/tmpd/traceSIP_#xxx.txt & where xxx indicates the test number

If topology B is used ( topologies are explained in chapter 3.1), 2 cases:

o If eSBC = OTSBC, syslog traces are mandatory

o If eSBC = Another eSBC, eSBC’s wireshark traces on Public side are mandatory

2- Test performed WITHOUT the “Test Case #xxx”, as indicated in the example below:



Test

Case Id N/A OK NOK Comment

1

Check

Action 1

Action 2

Action n

In these tests, it is NOT indicated “Test Case #xxx”

There is ONLY “Check” part.

For these tests, NO sipmotor traces are requested for the certification.

For each test, as SIP Provider certifier, the result is indicated in the filled document:

“PublicSIPtrunking_TechnicalQuestionnaire_OXE.doc”

Information for both tests:

Test Case Id: a feature testing may comprise multiple steps depending on its complexity. Each step has to be completed successfully in order to be conform to the test. Test Case #: describes the test case number #xxx with the detail of the main steps to be executed (each test case #xxx matches the trace #xxx provided in certification deliverables) N/A: when checked, means the test case is not applicable in the scope of the SIP Trunk Provider OK: when checked, means the test case performs as expected NOK: when checked, means the test case has failed. In that case, describe in the field “Comment” the reason for the failure and the reference number of the issue Comment: to be filled in with any relevant comment Expected behavior: That helps to decide what is the result of the test Important remark:



To activate the “OK” or “NOK” check box, double click the check box and change the default value to “Checked” as below:

Test


1

Check

Action 1

Action 2

Action n

The result:

Test


1

Check

Action 1

Action 2

Action n



3.1 REGISTRATION, AUTHENTICATION & KEEP ALIVE

The tests described below should be performed in case of the SIP Trunk provider supports those

mechanisms (Registration, authentication and keep alive(OPTIONS)).

3 cases: it depends on the certified topology (see in chapter 1.5):

============================================================

1- In case of topology A (see below), we recommend:

- Required REGISTER in OXE side

- Required AUTHENTICATION in OXE side

- Required KEEP ALIVE (REQUIRED OPTIONS) in OXE side

Topology A:

2- In case of topology B (see below), we recommend:

- Required REGISTER in eSBC side

- Required AUTHENTICATION in eSBC side


Topology B:

3- In case of topology C (see below), we recommend:



- REGISTER in OXE side if required by SIP Provider

- AUTHENTICATION in OXE side if required by SIP Provider


Topology C:



3.1.1 Registration

3.1.1.1 Registration on SIP Provider without authentication

3.1.1.1.1 Tests objectives

Objective:

OXE (or SBC in topology B) will send a register request to the SIP Provider relative to the URI corresponding

to the installation number.

Check REGISTER messages exchanged (check particularly "expires" values in request and answer)

Configuration for topology A or C:

From OXE side, the involved parameters:

SIP/ SIP External gateway / Belonging domain:

SIP/ SIP External gateway / Registration Id:

SIP/ SIP External gateway / Registration timer (timer parameter is in second):

Configuration for topology B: See specifications / configuration of the SBC

3.1.1.1.2 Tests results

Test

Case Id Test Case #111 N/A OK NOK Comment

1


Configure the external SIP gateway (belonging domain, registration Id, registration timer)

Configuration for topology B:

Configure the SBC

Authentication

required

2 Registering

Validate the OXE (or SBC) configuration

3

Check

Check the REGISTER messages

Which system (OXE or SBC) does the REGISTER?

Expected behavior (topology A or C):



3.1.1.2 Registration on SIP Provider with authentication


Objective:

OXE (or SBC in topology B) will send a register request relative to the URI corresponding to the installation

number. Authentication will be requested by the SIP Provider.

Check REGISTER messages exchanged (check particularly "expires" values in request and answer)



SIP/ SIP External gateway / Belonging domain:

SIP/ SIP External gateway / Registration Id:

SIP/ SIP External gateway / Registration timer (timer parameter is in second):

SIP/ SIP External gateway / Outgoing realm:

SIP/ SIP External gateway / Outgoing username:

SIP/ SIP External gateway / Outgoing password:



Test


1


Configure the external SIP gateway


Configure the SBC

2 Registering

Validate the OXE (or SBC) configuration

3

Check

Check the REGISTER messages

Which system (OXE or SBC) does the REGISTER?

Expected behavior (topology A or C):



3.1.2 Authentication on basic calls

3.1.2.1 Authentication on outgoing calls


Objective:

An OXE user will make an outgoing call in the DIGEST authenticated mode for the SIP Provider. Check the

call is well established.

The SIP Provider may support also the Nonce caching method. Please check it if available


Configure OXE to have SIP trunk in authenticated mode towards the SIP Provider (DIGEST authenticated on SIP Provider side).

From OXE side, the involved parameters: SIP/ SIP External gateway /remote domain:

SIP/ SIP External gateway /outgoing realm:

SIP/ SIP External gateway / outgoing username:

SIP/ SIP External gateway / outgoing password:

The OXE supports also nonce caching (RFC 2617), meaning that it avoids challenging each INVITE. The OXE

provides directly in the INVITE the header: Proxy-authorization

From OXE side, the involved parameters: SIP/ SIP External gateway /Nonce caching activation: YES or NO



Test


1


Configure the external SIP gateway


Configure the SBC

2

Outgoing call

An OXE user makes an outgoing call to an external user

The external user answers the call

The conversation stays at least 10 seconds

Someone hangs up the call



3

Check DIGEST method

That the call is well established

The different SIP exchanges between OXE and SIP Provider

Which system does the DIGEST authentication (OXE or SBC)?

OXE

4

Check Nonce caching (for topology A or C)

Does the SIP Provider support Nonce caching?

If yes, check that the call is well established

If yes, check the different SIP exchanges between OXE and SIP Provider

Even if we activate

Nonce Caching on

OXE, OpenIP sends

401 Unauthorized

message and requires

authentication

Expected behavior (DIGEST method) for topology A or C:

Expected behavior (Nonce caching method) for topology A or C:



3.1.2.2 Authentication on incoming calls

This test should be performed in case of SIP Trunk provider requires SIP digest authentication.


Objective:

An OXE user will receive an incoming call in the DIGEST authenticated mode for the OXE. Check the call is

well established.



SIP/ SIP External gateway / incoming username:

SIP/ SIP External gateway / incoming password:

SIP/ SIP External gateway /minimal authentication method: SIP DIGEST

SIP / SIP Proxy / authentication realm:



Test


1


Configure the external SIP gateway and Proxy


Configure the SBC

2

Incoming call

Incoming call from an external to an OXE user

The OXE user answers the call



3

Check



Expected behavior for topology A or C:



3.1.2.3 Incorrect Authentication on outgoing calls


Objective:

An OXE user will make an outgoing call in the DIGEST authenticated mode for the SIP Provider. The OXE will

send an incorrect password in the INVITE message. Check the call is refused by SIP Provider.



SIP/ SIP External gateway /remote domain, outgoing realm & outgoing username & outgoing password



Test


1


Configure the external SIP gateway with incorrect pwd


Configure the SBC (with incorrect pwd)

2

Outgoing call

An OXE user makes an outgoing call to an external user

3

Check

That the call is refused by the SIP Provider


Expected behavior for topology A or C:



3.1.3 Keep Alive


Objective:

The OXE is able to send OPTIONS to the SIP Provider for the Keep Alive. Check the OPTIONS are well

accepted by the SIP Provider with a 200 OK.

Configuration:

The Keep Alive is done for all topologies (A, B & C). Configure OXE to have OPTIONS in SIP external gateway.


SIP/ SIP External gateway / OPTIONS required: YES or NO

SIP/ SIP External gateway / Supervision timer (timer parameter is in second):


Test


1

Configuration

Configure the external SIP gateway (OPTIONS required and supervision timer)

2

Check

Does the SIP Provider support OPTIONS? If yes, see below the tests.

The OXE sends OPTIONS to the SIP Provider

The SIP Provider answers with a 200 OK

The OXE sends OPTION after the superv. timer

The SIP Provider answers with a 200 OK

Expected behavior:



3.1.4 Transport type (UDP & TCP) and Switch UDP to TCP


Objective:

SIP protocol is supported over UDP and TCP.

OXE is able to fragment SIP packets on UDP when exceeding 1300 bytes or switch to TCP.

Configuration:


- SIP/ SIP External Gateway/ Transport type: UDP or TCP

- SIP/ SIP Proxy / TCP when long messages: True or False

True (default value): TCP is used, rather than UDP, when the message size is higher than the

maximum size (MTU), e.g. 1300 bytes.

False: UDP is used, whatever the size of messages.

Remarks:

- The SIP Motor process must be restarted to take into account this modification

- As it is a SIP Proxy system parameter, the modification will be taken into account for all SIP

external gateways, SIP extensions, SIP devices and SIP external voice mails.


Test


1

Check

Which transport type is used? UDP or TCP?

UDP

2

Check

Does the SIP Provider support the switch to TCP?

No



3.1.5 Service Route and Path headers


Objective:

Does the SIP Provider support “Service Route” and “Path” headers?

Configuration:

Natively, OXE supports:

- RFC 3608: Service Route header

- RFC 3327: Path Header

For path header, OXE provides “Supported: path” and can also have path header

For Service Route header, the OXE provides Service route header for REGISTER and route header for INVITE

If carrier does not support these RFCs, it should not send “Service Route” header to PBX.


Test


1

Check

Are these RFC supported by the SIP Provider?

If SIP Provider doesn’t support these RFCs, no Service Route header should be sent to OXE. OK?



3.2 BASIC OUTGOING VOICE CALLS

3.2.1 Outgoing calls to PSTN / GSM sets (national and international)

3.2.1.1 Outgoing calls to PSTN / GSM sets: Establishment of call, Audio & Display


Objective:

An OXE user will make an outgoing call to PSTN / GSM sets (national AND international).

Check the normal audio during conversation.

Check the numbering format from OXE and SIP Provider sides.

Check the display of the calling number on PSTN / GSM sets.

Remark:

The Early SDP negotiation (during ringing state), the Codecs media negotiation and the trunk releasing for

outgoing basic calls will be checked in next chapters.

Configuration:

For more information, see the official documentation in:

Alcatel-Lucent OmniPCX Enterprise Communication Server – Technical Documentation =>

“System Documentation” part / Document containing “IP_PCXNetworks_8AL91007” => chapter SIP

1- The numbering plan for outgoing call:

OXE uses the canonical form (for example: [email protected]_Provider.com) for public

numbering to fill the Req URI, From, P-asserted-identity and To headers in SIP URIs.

Canonical form (=international numbers): “+” character and CC (Country Code) and NSN (national nb)

Canonical form has the advantage of being totally unambiguous whatever the type of call.

Note 1: Non-canonical form can also be used.

Note 2: Emergency numbers and special numbers are typically not sent using the canonical form.

Limitation: OXE does not provide Tel URI format.

2- The outgoing call routing: The OXE uses ARS. The configuration of the OXE outgoing call routing is

explained in the chapter «SIP-Provider SIP Trunk Solution Configuration»

3- The CLIP (Calling Line Information Presentation) sent to the SIP Provider:

OXE fills the display-name and the user in the “From” and “P-asserted-identity” headers:

From: “John” <sip:+33390677700@localdomain>

P-asserted_identity: “John” <sip:+33390677700@localdomain>

The CLIP is done thanks to:

- The NPD (in SIP trunk): The Type Of Number (TON) and the Numbering Plan Identification (NPI) are

used from the ISDN SETUP message received by the Call Handling OXE side.

The NPI/TON = ISDN Unknown / ISDN International or ISDN National, etc…

- Then, it is completed by the system Country Code.



4- The COLP/CONP are supported by the OXE and sent to the SIP Provider:

The Connected Line Presentation (COLP) and the Connected Name Presentation (CONP) services

allow to transmit the number or the name (if available) of the connected party (set on SIP Provider

side). OXE uses the P-Asserted-Identity header in 200 OK to identify the connected number and name.


Test


1 Configuration

Configure the OXE for the SIP outgoing call.

2

Outgoing calls (4 tests will be done):

OXE user to GSM National set #211-1

OXE user to GSM International set #211-2

OXE user to PSTN National set #211-3

OXE user to PSTN International set #211-4

In each test:

An OXE user makes an outgoing call to a SIP Provider PSTN/GSM set

The SIP Provider PSTN/GSM set answers the call



3

Check numbering formats from OXE and SIP Provider

Which numbering format (canonical or not) is used from OXE side?

Which numbering format (canonical or not) is used from SIP Provider side?

To:

<sip:06093471xx@94.

From: "Lenny"

<sip:+33973790173@

4

Check: OXE user to GSM National set #211-1


The normal audio during conversation

What is displayed on PSTN/GSM Provider set?

+33973790173

5

Check: OXE user to GSM InterNational set #211-2




Couldn’t test (not

authorized)

6

Check: OXE user to PSTN National set #211-3




0973790173

7

Check: OXE user to PSTN InterNational set #211-4




Couldn’t test (not

authorized)



Expected behavior:



3.2.1.2 Outgoing calls to PSTN / GSM sets: The Early media SDP negotiation (ringing state)


Objective:

An OXE user will make an outgoing call to PSTN / GSM sets (national AND international).

Check the ring back tone on the OXE user.

Check SDP Offer/Response exchanges between OXE and SIP Provider during the Early media SDP negotiation.

Configuration:




1- After INVITE with SDP from OXE, OXE will receive 18x provisional answer that may support SDP.

If SDP in 18x, OXE will play the media associated with this. Otherwise will play Local Ring Back Tone.

This behavior is not compatible with RFC 3960 gateway model, where having SDP does not mean there is

early media: OXE connects the remote IP@ in the SDP, regardless of presence or not of the RTP flow.

2- PRACK: OXE supports also RFC3262, to acknowledge answer to 18x answers (PRACK).

PRACK can also be with SDP, so that SDP can be renegotiated in that phase for some call flows. The use of

PRACK is negotiated through the 100 rel parameter.

The method UPDATE (in early media phase) can be used by OXE to negotiate media.

As PRACK and UPDATE are not methods supported by some carriers, the use of it is optional.

3- OXE supports also P-Early-Media (RFC 5009). When the SIP Provider supports the feature, the OXE INVITE includes the header: P-Early-Media: Supported The answer is transmitted by the SIP Provider in the P-Early-Media header:

• P-Early-Media: sendonly or sendrecv, the OXE user is connected to the SIP Provider SDP.

• P-Early-Media: recvonly or inactive, the OXE user is connected locally.

The Early Media feature can also be controlled via SDP offer and SDP answer with UPDATE method.

4- RE-INVITE method can only be used after the 200 OK to the initial invite, not before.

Practically from OXE side:



- Ring back tone (RBT)

Does the SIP provider play the RBT to the OXE calling user? In other words, does the SIP provider provide SDP

in 18x responses? Yes

- PRACK

If SIP provider plays the RBT for outgoing calls (180 with SDP), does the SIP provider require the provisional

response to be acknowledged by the OXE with PRACK? No


SIP/ SIP External gateway / Outbound calls 100 REL: Not Supported / Supported / Required

- UPDATE with SDP from SIP provider

If SIP provider plays the RBT for outgoing calls (180 with SDP) and PRACK is required, may the SIP provider

change the media before the called party answers (200OK): codec or point of connection?

Remark: to accept the UPDATE from the SIP Provider, the 18x message MUST contain the following:

- The “Allow: UPDATE” header

- The “Require: 100rel” header

- A SDP content

- UPDATE with SDP from OXE

If SIP provider plays the RBT for outgoing calls (180 with SDP) and PRACK is required, OXE may need to

change the media before the called party answers (200OK): codec or point of connection. OXE uses UPDATE

message in early media phase to change media.

Does the SIP provider support the reception of UPDATE with SDP?

- P-Early-Media

OXE supports P-early-media (RFC 5009). Does the SIP provider request the support of P-early-media header

by the OXE? No

From OXE side, the involved parameter: SIP/ SIP External gateway /RFC 5009 supported / Outbound calls:

- Not Supported

- Mode 1: if P-Early-Media header not present in the response => OXE user connected locally.

- Mode 2: if P-Early-Media header not present in the response => OXE user connected remotely if SDP

is present in the response.




Test


1

Check RBT

Does the SIP provider provide SDP in 18x responses? If yes, does the OXE user hear it?

Yes

2

Check PRACK

Does the SIP provider require the provisional response to be acknowledged with PRACK?

Not required

3

Check UPDATE from SIP Provider

Does the SIP Provider send UPDATE message in early media phase to change media?

4

Check UPDATE from OXE

Does the SIP Provider support the reception of UPDATE message with SDP in Early Media?

5

Check P-Early-Media

Does the SIP provider request the support of P-early-media header by the OXE?



3.2.1.3 Outgoing calls to PSTN / GSM sets: The Codecs Media SDP negotiation


Objective:

An OXE user will make an outgoing call to PSTN / GSM set (national AND international).

Check the SDP Offer/Response exchanges between OXE and SIP Provider regarding the codecs negotiation.

Configuration:

The configuration of the OXE outgoing call routing is explained in the chapter «SIP-Provider SIP Trunk

Solution Configuration».




The OXE supports G711A, G711U, G722, G723 & G729.

For optimization of RTP flow purpose, in case both G729A and G711 are supported, in some cases OXE sends

INVITE offer with G729A only. Would this offer be accepted?

If Yes, the configuration is SIP/ SIP External gateway / Type of codec negotiation: From domain


Test


1

Check the supported codecs of the SIP Provider

Which codecs are supported by the SIP Provider?

G711 and G729

2

Check the multi-codecs

in case both G729A and G711 are supported, in some cases OXE sends INVITE offer with G729A only. Would this offer be accepted?



3.2.1.4 Outgoing calls to external sets: Local user ends the conversation


Objective:

An OXE user will make an outgoing call to external sets.

Local user ends the conversation.

Check the conversation and trunk are properly released.

Configuration:

The configuration of the OXE routing is explained in the chapter «SIP-Provider SIP Trunk Solution

Configuration»


Test


1

Configuration


2

Outgoing call

An OXE user makes an outgoing call to a SIP Provider external set.

The SIP Provider external set answers the call


Local user hangs up the call

To:<sip:00336093471x

x@ 94.143.87.150

From: "Lenny"

<sip:+33973790173@

94.143.87.150

3

Check

The call is well established and released


Expected behavior:



3.2.1.5 Outgoing calls to external sets: external set ends the conversation


Objective:

An OXE user will make an outgoing call to external set.

The external set ends the conversation.

Check the conversation and trunk are properly released.

Configuration:


Configuration»


Test


1

Configuration


2

Outgoing call

An OXE user makes an outgoing call to a SIP Provider external set



External set set hangs up the call

3

Check

The call is well established and released


Expected behavior:



3.2.2 Outcall phase and call clearing before answer


Objective:

An OXE user will make an outgoing call to external set.

The OXE user hangs up the call before answer (during ring back tone).

Check the SIP signaling and trunk is properly released.

Configuration:


Configuration»


Test


1

Configuration


2

Outgoing call

An OXE user makes an outgoing call to a SIP Provider external set

The SIP Provider external set rings

The OXE user hangs up the call.

3

Check

The call is well released


Expected behavior:



3.2.3 Call to an incorrect number


Objective:

An OXE user will make an outgoing call to an incorrect external set number.

Check the correct display, the heart tone and that trunk is properly released.

Configuration:


Configuration»


Test


1

Configuration


2

Outgoing call

An OXE user makes an outgoing call to an incorrect SIP Provider external set number

Call 0111111111

3

Check

The display of the OXE user set

The heart tone of the OXE user set


SIP/2.0 480 Temporarily not

available

Expected behavior (for example):



3.2.4 Call to a busy set


Objective:

An OXE user will make an outgoing call to a busy external set.

Check the correct display, the busy tone heart and trunk is properly released.

Configuration:


Configuration»


Test


1

Configuration


2

Outgoing call

The SIP Provider external set is busy

An OXE user makes an outgoing call to this SIP Provider external set

3

Check

The display of the OXE user set

The busy tone heart of the OXE user set


The SIP Provider can send

“486 Busy here”, etc…

The display should be

“Busy”

Expected behavior (for example):



3.2.5 Outgoing calls from Anonymous Calling


Objective:

An OXE user with CLIR will make an outgoing call to external set.

Check the display of the external set.

Configuration:

From OXE side, the involved parameter: SIP/ SIP External gateway / RFC 3325 supported by the distant:

- YES: OXE uses the RFC 3323, 3324, 3325.

The INVITE contains the “From”, “PAI” and “privacy” headers as below:

From: “Anonymous” <sip:[email protected]>

P-asserted_identity: “John” <sip:+33390677700@localdomain>

priacy: user;id

- NO: The RFC 3325 is not supported by the SIP Provider’s proxy.

The INVITE contains the “From” and “privacy” headers as below:

From: <sip:+33390677700@localdomain>

privacy: user


Test


1

Configuration

Configure the SIP external gateway for anonymous outgoing call (RFC 3325 supported by the distant)

RFC 3325 supported

by the distant + False

2

Outgoing call

An OXE user uses the secret identity

This OXE user makes an outgoing call to a SIP Provider external set




3

Check

The display of the external set


4

Check method

Which method is used for anonymous?

Privacy: user



3.2.6 Outgoing long calls


Objective:

The session timer RFC 4028 is the timer value to supervise an active SIP session. OXE can use RE-INVITE or

UPDATE method for the session timer depending the used method by the SIP Provider. The Re-INVITE or the

UPDATE is sent before the SIP Session Timer expiry by OXE or SIP Provider.

An OXE user will make an outgoing call to external set for a long time (time greater than Max Session

Timer). Check the call is well established after the Session expiry.

Configuration:


SIP/ SIP external gateway / Session Timer Method: UPDATE or RE-INVITE

SIP/ SIP external gateway / Session Timer (timer parameter is in second):

SIP/ SIP external gateway / Min Session Timer (timer parameter is in second):

Remark: If topo B is used, do not configure any timer for this in the SBC.


Test


1

Configuration

In SIP external gateway, modify the Session Timer to a value as 200 or a small value to see the RE-INVITE / UPDATE more quickly.

BE CAREFUL: this value is just for this test. At the end of the test, come back to the previous value

Session-Expires:

200;refresher=uac

Min-SE: 200

(only for test,

otherwise,

values=1800 and 900)

2

Check the SIP messages

Does the SIP Provider support RFC 4028?

If yes, which method is used, INVITE or UPDATE?

Yes, RE-INVITE

3

Check the call

Is the call well established after the session timer expiry?

RE-INVITE sent after

100s (half of 200)

Expected behavior:



3.3 BASIC INCOMING VOICE CALLS

3.3.1 Incoming public calls from PSTN / GSM sets (national & international)

3.3.1.1 Incoming public calls with CLI: establishment of call, audio & display


Objectives:

An OXE user will receive an incoming call from PSTN / GSM set (national AND international).

Check the normal audio during conversation.

Check the numbering format from OXE and SIP Provider sides.

Check the display of the calling number on OXE user set.

Remark:

The Early SDP negotiation, codecs negotiation and trunk releasing will be checked in next chapters

Configuration:




1- The numbering plan for incoming call:

ALE recommends the use of the canonical form (for example: [email protected]) in

the REQ URI, From, P-asserted-identity and To headers in SIP URIs. OXE also supports Tel URI format.

2- Several methods can be applied to know the origin of the call (from the SIP Provider) and to reach

the destination of the call (OXE user).

For the destination of the call, the OXE checks if it is the destination proxy (domain part) and after

reaches OXE user thanks to user parts. For the origin of the call, the OXE determines which SIP external

gateway is associated to the calling. Please check the official documentation.

The involved SIP parameters are:

For the destination of the call:

SIP / SIP Gateway / Machine name: => provided by the netadmin

SIP / SIP Gateway / DNS local domain name:

SIP / SIP External Gateway / Registration Id:

SIP / SIP External Gateway / DDI Destination number: “ReqURI” OR “TO”

For the origin of the call:



SIP / SIP External gateway / Remote domain:

SIP / SIP external Gateway / Proxy identification on IP address: True OR False

SIP / SIP external Gateway / Outbound calls only: True or False

System / Other System Parameters / SIP Parameters / Via Header_ Inbound Calls Routing

3- The CLIP (Calling Line Information Presentation) on the OXE user set:

By default, the From header is used. If P-Asserted_Identity exists, OXE can display it.

The calling name is the SIP display name. The calling number is the user part of the SIP URI.

Three parameters to display the “PAI” or the “From” headers in:

SIP/ SIP External gateway / P-Asserted-ID in Calling Number (Default: False)

SIP/ SIP External gateway / Trusted P-Asserted-ID header (Default: True)

SIP/ SIP External gateway / Trusted From header (Default: False)

Then, the display is completed thanks to the NPD (in SIP trunk), to the country code and to the external

call back translator.

4- The COLP/COLR and CONP/CONR are supported by the OXE:

The Connected Line Presentation (COLP) and the Connected Name Presentation (CONP) services

allow to transmit the number or the name (if available) of the connected party (so the OXE user in

inbound call). OXE provides the connected number (COLP) in the P-Asserted-identity header in 200 OK.

Connected name (CONP) is not transmitted by OXE to the network.

If the OXE user is in identity secret, the COLR (Connected Line Restriction) is provided in 200 OK,

thanks to the Privacy header. This header contains the string "user". The CONR (Connected Name

Restriction) is not transmitted by OXE to the network.


Test


1

Configuration

Configure the OXE (SIP ext gateway, trunk group, NPD, country code, ext. callback translator…)

2

Inbound call: 4 tests

GSM National set to OXE user #311-1

GSM International set to OXE user #311-2

PSTN National set to OXE user #311-3

PSTN International set to OXE user #311-4

A SIP Provider PSTN/GSM user calls an OXE user


INVITE

sip:[email protected]

68.20.60

To:


28.146.236:5060



sip:[email protected]:5060

sip:[email protected]:5060





3

Check numbering formats from SIP Provider and OXE

Which numbering format (canonical or not) is used from SIP Provider side?

Which numbering format (canonical or not) is used from OXE side?

From:

<sip:6093471xx@FSFR

.SBC.SFR.NET>

4

Check: GSM National set to OXE user

That the call is well established and released



06093471xx

5

Check: GSM InterNational set to OXE user




6

Check: PSTN National set to OXE user




02308610xx

7

Check: PSTN InterNational set to OXE user




00170940033xx

Expected behavior:



3.3.1.2 Incoming public calls with CLI: The Early media SDP negotiation


Objective:


Check the ring back tone on the PSTN / GSM set.

Check SDP Offer/Response exchanges between OXE and SIP Provider during the Early media SDP negotiation.

Configuration:




1- After INVITE received by the OXE, this one will send 18x provisional answer that may support SDP.

2- PRACK: OXE supports also RFC3262, to acknowledge answer to 18x answers (PRACK).

PRACK can also be with SDP, so that SDP can be renegotiated in that phase for some call flows. The use of

PRACK is negotiated through the 100 rel parameter.

The method UPDATE (in early media phase) can be used by OXE to negotiate media.

As PRACK and UPDATE are not methods supported by some carriers, the use of it is optional.

3- OXE supports also P-Early-Media (RFC 5009). When the SIP Provider supports the feature, it may send an INVITE or an UPDATE to the OXE including the header: P-Early-Media: Supported

In this case, the OXE answers with a provisional response including the header: P-Early-Media header:

sendrecv.

When the OXE receives an INVITE message without the P-Early-Media header, it answers with a provisional

response which does not provide any P-Early-Media header.

The Early Media feature can also be controlled via SDP offer and SDP answer with UPDATE method.

4- RE-INVITE method can only be used after the 200 OK to the initial invite, not before.

Practically from OXE side:

- Ring back tone (RBT)

Does the SIP provider play the RBT to the PSTN / GSM set? In other words, has the OXE to provide SDP in 18x

responses?




SIP/ SIP External gateway / SDP in 18X: True or False (False)

- PRACK

If the OXE plays the RBT for incoming calls (180 with SDP), is the 100rel header in INVITE sent by SIP

provider absent, supported or required? Absent (No SDP in 18x)


SIP/ SIP External gateway / Inbound calls 100 REL: Not Requested / Required 1 / Required 2

- P-Early-Media

OXE supports P-early-media (RFC 5009). Does the SIP provider request the support of P-early-media header

by the OXE? No

- UPDATE with SDP

If OXE plays the RBT for incoming calls (180 with SDP) and PRACK is required, OXE may need to change the

media before the called party answers (200OK): codec or point of connection. OXE uses UPDATE message in

early media phase to change media.

Does the SIP Provider support UPDATE message with SDP in early media phase to change media? NA


Test


1

Check RBT

Does the OXE provide SDP in 18x responses? If yes, does the PSTN/GSM set hear it?

No

2

Check PRACK

If the OXE plays the RBT for incoming calls (180 with SDP), is the 100rel header in INVITE sent by SIP provider absent, supported or required?

3

Check UPDATE from SIP Provider

Does the SIP Provider support UPDATE message with SDP in early media phase to change media?

4

Check P-Early-Media

Does the SIP provider request the support of P-early-media header by the OXE?



3.3.1.3 Incoming public calls with CLI: The Codecs Media SDP negotiation


Objective:


Check the SDP Offer/Response exchanges between OXE and SIP Provider regarding the codecs negotiation.

Configuration:

The configuration of the OXE codecs is explained in the chapter «SIP-Provider SIP Trunk Solution

Configuration».




The OXE supports G711A, G711U, G722, G723 & G729.

In case both G729A and G711 are supported, in some cases OXE sends INVITE offer with G729A only. Would

this offer be accepted?

If Yes, the configuration is SIP/ SIP External gateway / Type of codec negotiation: From domain


Test


1

Check the supported codecs of the SIP Provider

Which codec are provided in INVITE?

G711 and G729

2

Check the multi-codecs

In case both G729A and G711 are supported, in some cases OXE sends INVITE offer with G729A only. Would this offer be accepted?

Yes



3.3.2 Ringing phase and call clearing before answer


Objective:

An OXE user will receive an incoming call from external set.

The external set hangs up the call before answer (during ringing state of OXE user)

Check the SIP signaling and trunk is properly released.


Test


1

Configuration

Configure the OXE for the SIP incoming call.

2

Incoming call

A SIP Provider external set makes an incoming call to an OXE user

The OXE user rings

The external set hangs up the call.

3

Check

The call is well released


Expected behavior:



3.3.3 Incoming calls from Anonymous Calling


Objective:

An OXE user will receive an incoming anonymous call from external set.

Check the display of the OXE user.

Configuration: Several methods can be used.

1- When in trusted mode, the received INVITE in the OXE contains “privacy” headers as below:

privacy: user OR privacy: id

The OXE user display set => Identity Secret

2- If not in trusted mode, the network should preferably send the “From” header as below:

From: “Anonymous” <sip:+anonymous@SIP_Provider_domain>

The origin of the call: the external SIP gateway associated to the remote domain of the “From”

The OXE user display set => the “From” content header: anonymous

3- The received INVITE in the OXE contains the “From” header as below (and no PAI):

From: “Anonymous” <sip:[email protected]>

In this case, system parameter Via Header_ Inbound Calls Routing must be set to True (the via

header is used to determine the origin of incoming calls when other headers do not match with the

RemoteDomain of an External Gateway).

The OXE user display set => the “From” content header: anonymous


Test


1 Configuration

Configure an external set in secret identity

2

Incoming call

This set makes an incoming call to an OXE user




From:

<sip:Anonymous@ano

nymous.invalid>

3

Check

The display of the OXE user set (in ringing state and in conversation state)

4

Check method

Which method is used for CLIR?

Privacy: id



3.3.4 Incoming long calls


Objective:

The session timer RFC 4028 is the timer value to supervise an active SIP session. OXE can use RE-INVITE or

UPDATE method for the session timer depending the used method by the SIP Provider. The Re-INVITE or the

UPDATE is sent before SIP Session Timer expiry by OXE or SIP Provider.

An OXE user will receive an incoming call from an external set for a long time (time greater than Max

Session Timer). Check the call is well established after the Session expiry.

Configuration:


SIP/ SIP external gateway / Session Timer Method: UPDATE or RE-INVITE

SIP/ SIP external gateway / Session Timer (timer parameter is in second):

SIP/ SIP external gateway / Min Session Timer (timer parameter is in second):

Remark: If topo B is used, do not configure any timer for this in the SBC.


Test


1

Configuration

In the INVITE received by OXE, “Session-Expires”header has the parameter refresher= uac OR uas

If “refresher=uac”, this is the SIP Provider which provides the RE-INVITE/UPDATE. You have to wait for the session timer of the SIP Provider

If “refresher=uas”, this is the OXE which provides the RE-INVITE/UPDATE. So in SIP external gateway, modify the Session Timer to a value as 200 or a small value. At the end of the test, come back to the previous value

Session-Expires:

1800;refresher=u

ac

2

Check the SIP messages

Does the SIP Provider support RFC 4028?

If yes, which method is used, INVITE or UPDATE?

Re-INVITE

3 Check the call

Is the call well established after the session timer expiry?

Expected behavior:



3.4 OXE User in forward (internal or external)

3.4.1 Incoming calls: Immediate forward to internal user


Objective:

An external set will make incoming public call to an OXE user which is in immediate forward to an internal

user.


Check the SIP messages exchanges (no SIP message “302” sent to the SIP Provider)

The OXE provides in the 200 OK the new internal user destination in the P-Asserted-ID header.


Test


1

Configuration

Configure an OXE user in immediate forward to Voicemail

2

Incoming call to the OXE

The external set makes an incoming call to an OXE user

3

Check


Check the SIP messages exchanges



3.4.2 Incoming calls: OXE User in immediate forward to external set


Objective:

An external set 1 will make an incoming call to an OXE user (in immediate forward to an external set 2).

Check the display of the external set 1.

Check the SIP messages exchanges. Which forward method is used?

Configuration:

2 ways to implement the external forward:

- Using “302. Moved Temporarily” IF THE SIP PROVIDER supports it

When receiving the incoming call, the OXE sends a “302 Moved Temporarily” with the contact

header containing the end user destination.

Then, the SIP Provider must send an INVITE to the end user destination.

In this case, the SIP signaling is released after the response of the “302 Moved Temporarily”

provided by the SIP Provider (= ACK).

Remark: on the opposite, OXE does not support the receipt of a 302.Moved Temporarily

response. Therefore, the public network must not send a 302.Moved Temporarily response.

To implement this solution:

The involved parameter: SIP / SIP Ext Gateway /Redirection response support: YES

All conditions listed in OXE documentation have to be fulfilled:

Condition 1: The diverted-to number provides an ARS prefix

At that time, the ARS mechanism is analyzed on behalf of the expected OXE user,

i.e. just as if the expected OXE user had directly dialed the diverted-to number -

This mechanism returns a Route List.

The following procedure applies to the first Route of this Route List:

Condition 2: A DCT is available for this Route, and a SIP gateway number is

available for this DCT

Condition 3: The external SIP gateway number of the incoming origin call matches

with the one of the DCT

Condition 4: ARS SIP trunk seizure must be WITHOUT OVERLAPPING

The contact header of the “302 Moved Temporarily” is built as follow:

• User part: The Add and Delete commands, if any, of the ARS route, is applied to

the original diverted-to number. The result might be provided in a canonical form,

depending on the NPD management of the route

• Domain part: It’s built with the Remote Domain parameter of the gateway the call

comes from

The expected behavior:



- OR using “181 Forwarded”:

In this case, the OXE creates a 2nd leg by sending a new INVITE to the external forward

destination.

The SIP signaling in OXE side is so not released during the conversation.

The user part of the “diverted” number is built as explained for 302 Moved Temporarily method

Two options: The SIP Provider may require EITHER the History-Info header OR the Diversion

header depending

To implement this solution:

The common involved parameters:

SIP / SIP Ext Gateway /Redirection response support: NO

Trunk Group / Trunk Group / IE External forward: diversion leg info

System/Other System Param. / External Signaling parameters / NPD for external forward:

must be different from -1 to have EITHER History-Info header OR the Diversion. Its value has

no importance, as the NPD of the ARS route will be used to call the “diverted” number.

If the SIP Provider requires Diversion header:

SIP / SIP Ext Gateway / Diversion Info to provide via: Diversion




If the SIP Provider requires History-Info header:

SIP / SIP Ext Gateway / Diversion Info to provide via: History Info




3.4.2.1.2 Tests results for the “181 Forwarded” method

Test

Case Id Test Case #421-1 N/A OK NOK Comment

1

Configuration

Configure an OXE user in immediate forward to an external set 2.

Configure the OXE for the “181 Forwarded” method

2


The external set 1 makes an incoming call to an OXE user

3

Check

The display of the external set 1

The call audio

The release of the call

4

Check method 181 Forwarded

Which method is used: History-Info or Diversion header?

The SIP messages exchanges

History-Info

3.4.2.1.3 Tests results for the “302 Moved Temporarily” method IF SUPPORTED BY SIP PROVIDER

Test


1

Configuration

Configure an OXE user in immediate forward to an external set 2.

Configure the OXE for the “302 Moved temporarily” method

2



3

Check


The call audio


Call not forwarded by

provider (method not

supported)

4

Check method 302 Moved Temporarily




3.4.3 Incoming calls: Forward on no answer to external set


Objective:

An external set 1 will make an incoming call to an OXE user which is in forward on no answer to an external

set 2.

Check the display of the external sets.

Check the SIP messages exchanges. Which forward method is used?

Configuration:

2 ways to implement the external forward:

- Using “302. Moved Temporarily” IF THE SIP PROVIDER supports it

- OR using “181 Forwarded”. There are then two options: The SIP Provider may require EITHER the

History-Info header OR the Diversion header depending

The explanations are in the previous test (immediate forward to external set) in case of using “302 Moved

temporarily”. The expected behavior is a little different in case of using “181 Forwarded”:

3.4.3.1.2 Tests results for the “181 Forwarded” method



Test


1

Configuration

Configure an OXE user in forward on no answer to an external set 2.

Configure the OXE for the “181 Forwarded” method

2



3

Check


The call audio


4

Check method 181 Forwarded

Which method is used: History-Info or Diversion header?


History-Info

3.4.3.1.3 Tests results for the “302 Moved Temporarily” method IF SUPPORTED BY SIP PROVIDER

Test


1

Configuration

Configure an OXE user in forward on no answer to an external set 2.

Configure the OXE for the “302 Moved temporarily” method

2



3

Check


The call audio


4

Check method 302 Moved Temporarily


method not supported



3.5 OXE User not available

3.5.1 Incoming public call: OXE user in “Do Not Disturb”


Objectives:

An OXE user is in Do Not Disturb

This OXE user will receive an incoming call from external set.

Check the display and the tone of the calling number on external set. The tone has to be handled by the SIP

Provider.

Check the SIP messages exchanges.


Test


1

Configuration

Configure an OXE user in Do Not Disturb.

2


The external set makes an incoming call to this OXE user

3

Check


The heart tone on external set


SIP/2.0 486 Busy Here




3.5.2 Incoming public call: OXE non-attributed number


Objectives:

The OXE will receive an incoming call from external set for an OXE non- attributed number.

Check the display of the calling number and the tone on external set. The tone has to be handled by the SIP

Provider.


Behavior: The call is freed by OXE (404) or overflow to operator (according to OXE config)


Test


1


The external set makes an incoming call to an OXE non-attributed number

2

Check




SIP/2.0 404 Not

Found




3.5.3 Incoming public call: OXE user is Busy


Objectives:

An OXE user is in Busy state

This OXE user will receive an incoming call from external set.

Check the display of the calling number and the busy tone on external set. The tone has to be handled by

the SIP Provider.



Test


1

Configuration

Put an OXE user in busy state.

2


The external set makes an incoming call to this OXE user.

3

Check




SIP/2.0 486 Busy Here




3.6 Advanced features for communications

3.6.1 Call on Hold / Retrieve


Objectives:

The OXE user will receive an incoming call from external set.

The OXE user answers the call. After several seconds, the OXE user puts the call on hold and after

sometimes retrieves the call.

Check the display and the music on hold of the calling number on external set.


Configuration: From OXE side: it means change of codec, IP address and UDP port of the media connection.

- In reception, OXE supports Re-INVITE with any direction attribute or UPDATE with sendrecv direction attribute messages for media change.

- In emission, OXE will send only RE-INVITE for media change. For hold service, if the reception of RE-INVITE with attribute “sendonly” is supported or required by SIP provider: in a next offer/answer exchange starting with the sending of RE-INVITE without SDP by PBX, the SIP provider must answer 200OK with attribute “sendrecv”. Involved parameter: SIP / SIP Ext Gateway /Send only for Hold: YES or NO (by default: NO) If Yes: the direction contains sendonly in outgoing RE-INVITE in case of hold If False: the direction contains sendrecv in outgoing RE-INVITE in case of hold


Test

Case

Id

Test Case #611 N/A OK NOK Comment

1 Configuration

Configure the OXE

2

Test call

The external set makes an incoming call to an OXE user.


After several seconds, the OXE user puts the call on hold

After several seconds, the OXE user retrieves the call


3

Check

The call is OK from audio side


SIP/ SIP Ext Gateway / Send only for Hole = YES or NO

Send only for Hold =

YES

a=sendonly



3.6.2 Call on Mute


Objectives:

The OXE user will receive an incoming call from external set.

The OXE user answers the call. After several seconds, the OXE user presses the Mute button.

Check the display and the no audio on external set.

Check the SIP messages exchanges (no SIP message for the mute)

Behavior:

The SIP signaling doesn’t change with the Mute.

During Mute, no RTP flow sent to external user.

The call remains in progress until hanging up manually.


Test


1

Test call

The external set makes an incoming call to an OXE user.


After several seconds, the OXE user presses the Mute button

After 5 minutes, the OXE user devalidates the Mute


2

Check


The silence on external set during the mute




3.6.3 Early Attended transfer (on ringing): transfer to internal user


Objectives:

The OXE user A will make an outgoing call to external set.

The external set answers the call. After several seconds, the OXE user makes an enquiry call to an internal

OXE user B. As soon as this internal OXE user B rings, A hangs up.

Check the display (no change after transfer) and the audio of the calling number on external set.



Test


1

Test call

The OXE user A makes an outgoing call to an external set.

The external set answers the call

After several seconds, the OXE user A makes an enquiry call to an internal OXE user B.

As soon as B rings, the OXE user A hangs up.

B and the external set stay in conversation during at least 10 seconds


2

Check


The audio on external set


Expected behavior:



3.6.4 Early Attended transfer (on ringing): transfer to external set


Objectives:

The OXE user will make an outgoing call to external set 1.

The external set 1 answers the call. After several seconds, the OXE user makes an enquiry call to an

external set 2. As soon as external set 2 rings, the OXE user hangs up.

Check the display (no change after transfer) and the audio on external sets 1 & 2.


Two ways for the implementation:

1- RE-INVITE method

On Public SIP Trunking, the transfer service is usually based on emission/reception of Re-INVITE, whatever

the transferrer (OXE user or PSTN/GSM SIP Provider set).

OXE supports reception of “Re-INVITE without SDP" description. Re-invite without SDP is the preferred

method.

The SIP signaling stays “open” from OXE side until the end of the transferred call.

Involved parameter: SIP / SIP Ext Gateway / Attended transfer: NO

SIP / SIP Ext Gateway /Re-INVITE without SDP: YES or NO



2- REFER WITH REPLACES method:

From OXE R11.0.1, REFER (RFC 3515)/REPLACES (RFC 3891) method can also be enabled on OXE for trunk

to trunk transfer initiated from OXE, in case the SIP provider supports REFER with REPLACE.

From OXE R11.1, according to the SIP external gateway parameter Send BYE on REFER, the OXE or the SIP

carrier sends the BYE message.

When the parameter is set to TRUE, the OXE sends a BYE message to SIP Provider immediately after NOTIFY

successful response.

When the parameter is set to FALSE, a timer is launched which monitors arrival of a BYE message from

external.

The SIP signaling is closed from OXE side as soon as the transfer is done.

Remark: REFER method is still not supported in the reverse way, when OXE receives REFER.

Involved parameter: SIP / SIP Ext Gateway / Attended transfer: YES

SIP / SIP Ext Gateway / Send BYE on REFER: YES or NO



3.6.4.1.2 Tests results for RE-INVITE method

Test


1

Configuration

Configure the SIP external gateway for the RE-INVITE method

2

Test call

The OXE user makes an outgoing call to an external set 1.

The external set 1 answers the call

After several seconds, the OXE user makes an enquiry call to external set 2.

As soon as external set 2 rings, the OXE user hangs up.

Both external sets 1 & 2 stay in conversation during at least 10 seconds

The external set 1 hangs up the call.

3

Check

The display of the external sets 1 & 2

The audio on external sets 1 & 2


3.6.4.1.3 Tests results for REFER/REPLACE method IF SUPPORTED BY SIP PROVIDER

Test


1

Configuration

Configure the SIP external gateway for the REFER/REPLACE method

2

Test call


The external set 1 answers the call

After several seconds, the OXE user makes an enquiry call to external set 2.

As soon as external set 2 rings, the OXE user hangs up.

Both external sets 1 & 2 stay in conversation during at least 10 seconds


Parameter

“Attended transfer:

YES”

requires “Re-INVITE

without SDP” set to

“True” (False is the

recommended value

for OpenIP)

3

Check






3.6.5 Supervised call transfer (after answer): transfer to internal user


Objectives:

The OXE user A will make an outgoing call to external set.

After several seconds, the OXE user A makes an enquiry call to an internal OXE user B. A & B are in

conversation.

Then, the OXE user A transfers the call.

Check the display (no change after transfer) and the audio of the calling number on external set.



Test


1

Test call

The OXE user A makes an outgoing call to an external set

The external set answers the call

After several seconds, the OXE user A makes an enquiry call to an internal OXE user B.

B answers the call. A & B in conversation

The OXE user A transfers the call.

B and the external set stay in conversation during at least 10 seconds


2

Check


The audio on external set


Expected behavior:



3.6.6 Supervised call transfer (after answer): transfer to external set


Objectives:


After several seconds, the OXE user makes an enquiry call to an external set 2, which answers the call.

Then, the OXE user makes the transfer.

Check the display (no change after transfer) and the audio of the calling number on external sets 1 & 2.


Two ways for the implementation:

1- RE-INVITE method

On Public SIP Trunking, the transfer service is usually based on emission/reception of Re-INVITE, whatever

the transferrer (OXE user or PSTN/GSM SIP Provider set).

OXE supports reception of “Re-INVITE without SDP" description. Re-invite without SDP is the preferred

method.

The SIP signaling stays “open” from OXE side until the end of the transferred call.

Involved parameter: SIP / SIP Ext Gateway / Attended transfer: NO

SIP / SIP Ext Gateway /Re-INVITE without SDP: YES or NO



2- REFER WITH REPLACES method:

From OXE R11.0.1, REFER (RFC 3515)/REPLACES (RFC 3891) method can also be enabled on OXE for trunk

to trunk transfer initiated from OXE, in case the SIP provider supports REFER with REPLACE.

From OXE R11.1, according to the SIP external gateway parameter Send BYE on REFER, the OXE or the SIP

carrier sends the BYE message.

When the parameter is set to TRUE, the OXE sends a BYE message to SIP Provider immediately after NOTIFY

successful response.

When the parameter is set to FALSE, a timer is launched which monitors arrival of a BYE message from

external.

The SIP signaling is closed from OXE side as soon as the transfer is done.

Remark: REFER method is still not supported in the reverse way, when OXE receives REFER.

Involved parameter: SIP / SIP Ext Gateway / Attended transfer: YES

SIP / SIP Ext Gateway / Send BYE on REFER: YES or NO



3.6.6.1.2 Tests results for the RE-INVITE method

Test


1

Configuration

Configure the external SIP gateway for the RE-INVITE method

2

Test call

The OXE user makes an outgoing call to an external set 1. They are in conversation

After several seconds, the OXE user makes an enquiry call to an external set 2.

External set 2 answers the call.

The OXE user presses “transfer”

The external sets 1 & 2 stay in conversation during at least 10 seconds


3

Check




3.6.6.1.3 Tests results for the REFER/REPLACE method IF SUPPORTED BY SIP PROVIDER

Test


1

Configuration

Configure the external SIP gateway for the REFER/REPLACE method

2

Test call

The OXE user makes an outgoing call to an external set 1. They are in conversation


External set 2 answers the call.

The OXE user presses “transfer”

The external sets 1 & 2 stay in conversation during at least 10 seconds


3

Check






3.6.7 Conference (3-Party)


Objectives:

The OXE user makes an outgoing call from an external set 1.


Then, the OXE user makes a conference.

Check the display and the audio of the OXE user and the external sets 1 & 2. The display of the external sets

1 & 2 doesn’t change (display 1st call). The OXE user A displays both external sets 1 & 2.



Test


1

Test call



The OXE user presses “conference”

The external sets 1 & 2 and the OXE user stay in conference during at least 10 sec.

The external sets 1 & 2 and OXE user hang up the call.

3

Check

The display of the external sets and OXE user

The audio on external sets and OXE user


Expected behavior:



3.6.8 DTMF

From OXE R12.2, two modes: RFC 4733 (former RFC 2833) OR in band DTMF.

As “In band DTMF” mode needs compressors resources on NGP boards and mandatory G711 codec from OXE

side, the RFC 4733 mode stays the preferred method.

3.6.8.1 DTMF for outgoing call


Objective:

An OXE user will make an outgoing call to an external IVR.

The IVR answers the call. The OXE user presses several DTMF.

Check the DTMF are well accepted by the IVR.

Check which DTMF method is used.

Configuration:

The DTMF mode choice depends on SIP Gateway DTMF mode configuration and SIP Signaling answer content

(SDP content of SIP carrier).

If SIP Gateway DTMF mode configuration is “In Band DTMF”, no telephone-event is used in the SDP of the

outgoing OXE’s INVITE.

Else OXE uses RFC 4733 (former RFC 2833), meaning that a dedicated dynamic payload is proposed in the

SDP part of the INVITE method. Supposing that the dynamic payload type X has been proposed (X is

configurable in OXE), the subsequent behavior is depending on the content of the SDP part which is received

in the 200.OK response:

- Payload X: use of RFC 4733 with the agreed payload X

- Payload Y: OXE uses RFC 4733, sending payload Y, receiving payload Y

- None: No payload in the 200 OK response: OXE switches automatically to DTMF inband (G711 must

be part of SDP offer in the 200 OK response, if not the call is refused)

Involved parameter: SIP / SIP Ext Gateway / In band DTMF: YES or NO

If NO: outgoing INVITE from OXE with telephone-event in SDP (RFC 4733)

If YES: outgoing INVITE from OXE without telephone-event in SDP




Test


1

Configuration


2

Outgoing call

An OXE user makes an outgoing call to an external IVR

The IVR answers

The OXE user sends several DTMF

3

Check

Which mode is used for DTMF?


RFC4733



3.6.8.2 DTMF for incoming call


Objective:

An external set will make incoming public call to an OXE user which is in immediate forward to Voice mail.


Check the audio message and the possibility to navigate in the menus with DTMF

Check which DTMF method is used.

Configuration:

OXE’s behavior is depending on the content of the SDP offer which is received in the INVITE method:

- Payload X: agreement of payload X in the 200 OK response and use of that one: RFC 4733 method is used

- None: No payload received in INVITE and so no payload in the 200 OK response: OXE switches automatically to DTMF inband (G711 must be part of SDP offer in the INVITE, if not the call is refused)


Test


1

Configuration

Configure an OXE user in immediate forward to Voicemail

2


The external set makes an incoming call to an OXE user

3

Check


The audio message and the possibility to navigate in the menus with DTMF

Which mode is used for DTMF?


RFC4733



3.6.9 Call Admission Control


Objective:

Incoming call from external set when CAC is saturated.

Check call is rejected properly. OXE sends a 503 SIP message which is accepted by the SIP Provider.

Check the heart tone and the display on external set.


Test


1

Configuration

Configure the OXE for the SIP incoming call.

2

Incoming call

An external set makes an incoming call to an OXE user when CAC is saturated.

3

Check

The heart tone an display on external set


Expected behavior:



3.7 FAX Transmission

3.7.1 FAX Transmission with analog FAX machine attached on OXE


Objectives:

An analog FAX OXE user will send multiple pages (3 pages) to a public FAX user via the SIP Provider.


Configuration:

A fax call is first established as a voice call. It switches to fax call, when the fax carrier is detected.

There are several ways of transmitting a fax call supported by OXE:

1- Via the T38 protocol:

This protocol, dedicated to fax calls, includes the retry facility, which allows the loss of packets. In

addition, this protocol tolerates transmission delays.

Expected behavior:

2- Via G711 transparent:

FAX signaling are transmitted on a voice channel as it would be done on an analog line. This transmission

does not support loss of packets and requires a lesser transmission delay.

It requires:

- A voice call established with the G711 algorithm

- An INTIP3 board or a GD3 board in front of the fax

3- Via “T38 to G711 Fallback”:

FAX can be transmitted either in T38 or in G711 transparent according to the remote party capabilities.



After FAX detection:

- When the remote party can operate via the T38 protocol, a RE-INVITE message, containing a T38

offer is transmitted.

- When the remote party doesn’t support the T38 protocol, the FAX is transmitted on the voice

channel.


Test


1

Configuration

Configure the OXE with analog FAX user

2

Outgoing transmission from the OXE

The analog FAX machine makes an outgoing call to public FAX user and sends 3 pages.

3

Check

The public FAX user receives the 3 pages

Which method is used for the FAX transmission?


G711 transparent

(T38 not supported)



3.7.2 FAX Reception with analog FAX machine attached on OXE


Objectives:

An analog FAX OXE user will receive multiple pages (3 pages) from a public FAX user via the SIP Provider.


Configuration:

A fax call is first established as a voice call. It switches to fax call, when the fax carrier is detected.

There are several ways of transmitting a fax call supported by OXE:

1- Via the T38 protocol:

This protocol, dedicated to fax calls, includes the retry facility, which allows the loss of packets. In

addition, this protocol tolerates transmission delays.

Expected behavior:

2- Via G711 transparent:

FAX signaling are transmitted on a voice channel as it would be done on an analog line. This transmission

does not support loss of packets and requires a lesser transmission delay.

It requires:

- A voice call established with the G711 algorithm

- An INTIP3 board or a GD3 board in front of the fax

3- Via “T38 to G711 Fallback”:

When the OXE detects a FAX call, it returns a RE-INVITE message with the T38 offer:

- If the remote party accepts it, the fax is transmitted via the T38 protocol



- If the remote party refuses it, an error message is received and:

o If the coding algorithm is G711 and if an INT-IP3 board or a GD-3 boards is used, the fax is

transmitted transparently

o If the negotiated codec is not G711 or if the used board is not a INT-IP3 board nor a GD-3

board, the call is refused


Test


1

Configuration

Configure the OXE with analog FAX user

2

Incoming reception on the OXE

The public FAX user makes an incoming call to the OXE FAX user and sends 3 pages.

3

Check

The OXE FAX user receives the 3 pages

Which method is used for the FAX reception?


G711 transparent

(T38 not supported)



3.7.3 FAX Transmission from FAX Server


Objectives:

A FAX Server user will send multiple pages (3 pages) to a public FAX user via the SIP Provider.


Configuration:

The FAX Server is a routing number from OXE side. A FAX Server is so associated to a SIP external gateway

and a SIP ABCF Trunk Group.

There are several ways of transmitting a FAX call supported by OXE (explained in previous chapter):

1- Via the T38 protocol

2- Via G711 transparent

3- Via “T38 to G711 Fallback”


Test


1

Configuration

Configure the OXE with a FAX server user

Not tested

2

Outgoing transmission from the FAX Server

The FAX Server user makes an outgoing call to a public FAX user and sends 3 pages.

3

Check

The public FAX user receives the 3 pages

Which method is used for the FAX transmission?




3.7.4 FAX Reception from FAX Server


Objectives:

A FAX Server user will receive multiple pages (3 pages) from a public FAX user via the SIP Provider.


Configuration:

The FAX Server is a routing number from OXE side. A FAX Server is so associated to a SIP external gateway

and a SIP ABCF Trunk Group.

There are several ways of transmitting a FAX call supported by OXE (explained in previous chapter):

1- Via the T38 protocol

2- Via G711 transparent

3- Via “T38 to G711 Fallback”


Test


1

Configuration

Configure the OXE with a FAX Server user

Not tested

2

Incoming reception on the OXE

The public FAX user makes an incoming call to a FAX Server user and sends 3 pages.

3

Check

The FAX Server user receives the 3 pages

Which method is used for the FAX reception?




4 “SIP-Provider name” SIP Trunk Solution Configuration

The configuration on OXE side is the same for all topologies except some parameters in the SIP external

gateway. In case of topology including a Session Controller Border element, only the configuration of OTSBC

(not third part SBC) that is added in this chapter.

4.1 OmniPCX Enterprise configuration

The significant parameters to configure OXE from scratch are presented in this section. Special attention

should be given to parameters in red color. Some parameters are already filled in with mandatory values. If

necessary, additional “Carrier’s value” columns could be added (like for NPD, ARS Route, etc.).

4.1.1 Signaling protocol and number of physical channels

The SIP trunk uses a specific signaling protocol and some physical resources of the IPBX (i.e. DSP channels).

Obviously, it is required a board which provides the system with DSP channels (i.e: OMS board). It is possible

to check the number of DSP channels available in the system by using the command “compvisu lio”.

4.1.2 Trunk Configuration

To enable phone calls over the SIP trunk, it’s mandatory to have an ISDN trunk group declared with SIP

specification. This can be done in mgr: Trunk Groups -> Trunk Group. The following tables gather the overall system configuration. They show the values to be modified, that

means that the values that are not appearing here will be the default system values.

4.1.2.1 Trunk Group

Mgr Trunk Groups

Description Default value Carrier’s value Trunk Group ID: -1 10

Trunk Group Type: T2 T2

Trunk Group Name: -- OpenIP

UTF-8 Trunk Group Name: --------------------

Number Compatible With: -1

Remote Network: 15 15

Node number: -- --

Q931 Signal variant ISDN FRANCE ISDN all countries

Number of Digits To Send 0 0

T2 Specificity None SIP

Public Network Category: 0

DDI transcoding False True

Can support UUS in SETUP True

Associated Ext SIP gateway: -1



4.1.2.2 Trunk Group local parameters

Mgr Trunk Groups Trunk Group

Description Default value Carrier’s value Trunk Group ID: -- 10

Trunk Group Type T2 T2

T2 Specification None SIP

Entity Number: 0 2

End to end dialing NO

DTMF end to end signal. NO

Trunk group used in DISA NO

Trunk COS 31

Nb of digits unused (ISDN): 0 4

IE External Forward None Diverting leg information

4.1.2.3 Trunk Group NPD selector

Remark:

For incoming calls, the used NPD is the trunk group NPD. For outgoing calls, the used NPD is the NPD of the ARS route. If = 255 in ARS route, the trunk Group NPD is used. Mgr Trunk Groups Trunk Group NPD selector

Description Default value Carrier’s value Trunk Group ID -- 10

Public NPD ID 10 36

Private NPD ID 0 0

Management Mode Automatic Normal

Public DID transcoding True True

4.1.2.4 Trunk Group COS and Timers

The trunk COS corresponds to the trunk COS number in the local Trunk group parameters Mgr External Services > trunk COS

Description Default value Carrier’s value Trunk COS : 31

T2 T0 ABC-F ISDN Trunks

Timer T303 100

Timer T304 300 900

Timer T310 200

Timer T313 40

Timer T305 40

Timer T308 40

Timer T309 900

Timer T302 150

Timer T386 200



4.1.3 ARS Configuration

To enable outgoing voice calls via the ARS system, it’s necessary to have ARS Route lists created via the mgr

menu Translator -> Automatic Routing Selection. Several ARS route lists have to be managed for

international, national and city area.

4.1.3.1 ARS Prefix

Mgr Translator Prefix Plan

Description Default value Carrier’s value Number : -- --

Prefix Meaning ARS Prof. Trk Grp Seizure ARS Prof.Trk Grp Seizure

Discriminator No: -- 2

4.1.3.2 ARS Route list and ARS Route

Mgr Translator Automatic Route Selection ARS Route List

Description Default Value Carrier’s value ARS Route list: 0 10

Name: -- OpenIP

PIN Code False

And Mgr Translator Automatic Route Selection ARS Route List ARS Route

Description Default value Carrier’s value ARS Route list: 0 10

Route: 1 1

Name: -- --

Trunk Group Source Route Route

Trunk Group: -1 10

Nb.Digits To Be Removed: 0 0

Digits To Add: -- --

Numbering Command Tabl.ID 0 10

VPN Cost Limit: 0 0

Protocol Type Dependant on Trunk

Group Type

Dependant on Trunk

Group Type

NPD identifier: 255 36

Route Type Public Public

ATM Address ID: -1 -1

Preempter False False

Quality -- Speech + Fax

In each ARS Route, two important parameters:



- NPD Number

- Numbering Command Table Id (used to link ARS route with the external SIP Gateway of the SIP Provider.

4.1.3.3 Time Based Route List

Mgr Translator Automatic Route Selection ARS Route List Time Based Route List

Description Default value Carrier’s value ARS Route list: 0 10

Time Based Route List ID: 1 1

Route Number: -- 1

Waiting Cost Limit: -- -1

Stopping Cost Limit: -- -1

4.1.3.4 Numbering Command Table

Mgr Translator Automatic Route Selection Numbering Command Table

Description Default value Carrier’s value Table ID: 1 10

Carrier Reference: 0 10

Command: -- I

Associated Ext SIP gateway: -1 2

4.1.3.5 NPD

Mgr Translator External Numbering Numbering Plan Description (NPD)

Description Default value Carrier’s value

Description identifier: 0 36

Name: Public_operator public_OpenIP

Calling Numbering plan ident. Unknown NPI/TON ISDN National

Called numbering plan ident. Unknown NPI/TON: ISDN Unknown

Authorize personal calling num use False

Install. number source Entity source Entity source

Default number source Entity source Entity source

Called DID identifier: -1 1

Calling/Connected DID identifier: -1 1



4.1.4 External Callback Translator

The external callback translator rules are linked to the incoming trunk group and so to its associated entity.

Mgr Trunk Groups Trunk Group

Description Default value Carrier’s value Trunk Group ID: -- 10

Trunk Group Type T2 T2

T2 Specification None SIP

Entity Number: 0 2

Mgr Entity

Description Default value Carrier’s value

Entity number: 0 2

External Callback Table 0 0

Installation No. (ISDN) -- 4 first digits (ex. 9737)

Supplement.Install.No. (ISDN) -- Last 5 digits (ex. 90172)

Mgr Translator External Numbering Plan Ext. Callback Translation Tables Ext. Callback

Translation Rules

Description Default value Carrier’s value Carrier’s value Carrier’s value External Callback Table 0 0 0 --

Basic Number A DEF

No. Digits To Be Removed 0 0

Digits To Add 0 00



4.1.5 SIP Gateway and SIP Proxy Configuration

4.1.5.1 SIP Gateway

Mgr SIP SIP Gateway

Description Default value Carrier’s value SIP Subnetwork: -- 15

SIP Trunk Group: -- 15

IP Address: -- 192.168.xx.xx

Machine name - Host: -- xxxx

SIP Proxy Port Number: 5060 5060

SIP Subscribe Min Duration: 1800 900

SIP Subscribe Max Duration: 86400 86400

Session Timer: 1800 1800

Min Session Timer: 900 900

Session Timer Method: UPDATE RE_INVITE (not relevant for

R12.4)

DNS local domain name: 192.168.xx.yy

DNS type DNS A DNS A

SIP DNS1 IP Address: --

SIP DNS2 IP Address:

SDP in 18x: True True (could be False)

CAC SIP-SIP: False False

INFO method for remote extension: False False

Dynamic Payload type for DTMF: 101 101

Overflow Licenses Threshold: 80 80

4.1.5.2 SIP Proxy

Mgr SIP SIP Proxy

Description Default value Carrier’s value SIP initial time-out: 500 500

SIP timer T2: 4000 4000

DNS Timer overflow: 5000 5000

Timer TLS: 30 30

Recursive search: False False

Minimal authentication method: SIP Digest SIP Digest

Authentication realm: -- xxxx

Only authenticated incoming calls: True True

Framework Period: 3 3

Framework Nb Message By Period: 25 25

Framework Quarantine Period: 1800 1800

TCP when long messages: True True

Retransmission number for INVITE: 3 3

Degraded mode Time To Live: 1800 1800

User Agent Identifier: % %



4.1.5.3 SIP Registrar

Mgr SIP SIP Registrar

Description Default value Carrier’s value Min expiry date: 1800 1800

Max expiry date: 86400 86400

4.1.5.4 Trusted IP addresses

Mgr SIP Trusted IP addresses

Note: IP address of SIP carrier or SBC should be added here, otherwise it will be placed automatically in

quarantine for 30 minutes in case of high incoming SIP traffic.

Description Carrier’s value Trusted address 94.143.87.150

4.1.6 SIP External Gateway Configuration

mgr SIP SIP Ext Gateway

Description Default value Carrier’s value SIP External Gateway ID: -- 2

Gateway Name: -- OpenIP

SIP Remote domain: -- 94.143.87.150

PCS IP address: --

SIP Port number: 5060

Transport type: UDP UDP

Belonging domain: -- 94.143.87.150

Registration ID: -- xxxxxxx

Registration ID in P_Asserted: False False

Registration timer: 0 60

SIP Outbound Proxy: --

Supervision timer: 0 60

Trunk group number: -1 10

Pool Number: -1

Outgoing realm: -- 94.143.87.150

Outgoing username: -- xxxxxx

Outgoing Password: -- *****

Incoming username: --

Incoming Password: --

RFC 3325 supported by the distant: True False

DNS type: DNS A DNS A

SIP DNS1 IP Address: -- 192.168.xx.xx

SIP DNS2 IP Address: --

SDP in 18x: False False

Minimal authentication method: SIP Digest SIP None

INFO method for remote extension: False False

To EMS: False False

SRTP: RTP only RTP only



Ignore inactive/black hole: False False

Contact with IP address: False True

Dynamic Payload type for DTMF: 101 101

Outbound Calls 100 REL: Supported Not Supported

Incoming Calls 100 REL: Not Requested Not Requested

Gateway type: Standard type Standard type

Re-Trans No. for REGISTER/OPTIONS: 2 2

P-Asserted-ID in Calling Number: False False

Trusted P-Asserted-ID header: True True

Diversion Info to provide via: History Info History Info

Proxy identification on IP address: False False

Outbound calls only: False False

SDP relay on Ext. Call Fwd: Default Default

SDP Transparency Override: False False

RFC 5009 supported / Outbound call: Not Supported Not Supported

Nonce caching activation: NO NO

FAX Procedure Type: T38 Only G711 only

DNS SRV/Call retry on busy server: 0 0

Unattended Transfer for RSI: NO NO

Redirection functionality: NO NO

Attended Transfer: NO NO

Send BYE on REFER: YES YES

Redirection response support: NO NO

OPTIONS required: YES YES

Support UTF8 characters set: NO NO

Support CSTA User-to-User: NO NO

DDI destination number: ReqURI ReqURI

Video Support Profile: Not Supported Not Supported

UPDATE in Allow header/INVITE: Optional Optional

RFC 4904 supported: NO NO

Bulk registration (RFC 6140): NO NO

RFC3264 m-line: True True

Sendonly for hold: False False

In Band DTMF: NO NO

SIP Trunk recording: NO NO

Send user name in SIP User name else TG name User name else TG number

Session Timer 1800 1800

Min Session Timer 900 900

Session Timer Method UPDATE RE_INVITE

Trusted From header: False False

Support Re-invite without SDP: True False

Type of codec negotiation Default Single codec G711



4.1.7 System Parameters Configuration

The following tables gather the overall system configuration. Important values to be modified are shown here. All other values that are not appearing here will be the default system values.

Mgr System Other System Param. SIP Parameters

System SIP parameters Default Value Carrier’s value

Packetization times per codec True True

Via Header_ Inbound Calls Routing False True

TLS signaling possible False False

Local resources True True

Loose Route with RegID False True

Reject unidentified proxy calls False False

SRTP offer answer mode False False

Hotel doorcam application False False

Transfer : Refer using single step True True

RE-INVITE delay for hold 3 3

SIP Bearer Capability Voice Voice

Number of SIP trunks (UCaaS) 10 10

Enhanced codec negotiation Local Type Local Type

G722 for SIP trunking True True

sipmotor restart delay 5 5

Private SIP transit mode Mixed mode Mixed mode

SIP registered pseudo reservation False False

Blind transfer with direct RTP True True

From Header For Anonymous Calls Anonymous Anonymous

Maximum Trunk Group Overflow 3 3

SIP video transit mode Not Available Not Available

Raise SIP Motor Incidents False False

Enhanced Canonical Form False False

SIP UUI Normal Transit False False

Force NCT on Internal Route False False

SIP diversion info for incoming False False

Accept keys for unsecured GW False False

Use Native SIP TLS False False

Mgr System Other System Param. Compression

System compression parameters OXE default Value Carrier’s value Voice Activity Detect (Comp Bds) False --

Compression Type G 723 G729

Multi. Algorithms for Compression False --

Voice Activity Detection on G711 False --

G722 data rate 64 K --

G722 Conference With OMS True --



Mgr System Other System Param. System Parameters

Additional system parameters OXE default Value Carrier’s value Law A-Law A-Law

Accept Mu and A laws in SIP False False

Mgr System Other System Param. External Signaling Parameters NOTE: for NPD, a value different from -1 is mandatory.

System parameters (external signaling) OXE default Value Carrier’s value NPD for external forward -1 36

Calling Name Presentation : False False

Mgr System Other System Param. Signaling string Note: The country code is recognized and extracted from the number received in canonical form.

System parameters (signaling sring) OXE default Value Carrier’s value

System Option String +SG Country Code +SG Country Code

Country Code 33

Mgr IP IP Parameters

IP parameters OXE default Value Carrier’s value

Jitter buff size (modem/fax transp) 40 --

G711 VOIP Framing 20 ms --



Jitter algorithm (voice) 1 --

Jitter buffer size (voice) 30 --

DTMF mode 0 --

CAC with OTMS/OTBE False --

Mgr IP Fax parameters

Fax parameters OXE default Value Carrier’s value

T38 only False --

Local T38 port number RTP port number --

NAT Support for FAX T38 False --

4.2 OTSBC configuration

This section describes the necessary settings on OTSBC AudioCodes in case it’s a part of the topology.



OTSBC works as border and security element between the local OXE network and the public SIP Trunk

Provider access.

SIP trunk provider only knows the public IP address of OTSBC, so no information about private LAN will be

sent to carrier. In other hands, OXE only knows the private local IP address of OTSBC, so no information

about public SIP trunk provider will be sent to OXE. This topology hiding ability is applied on both the SIP

signaling and RTP Media by using roles configured on OTSBC.

4.2.1 Initial OTSBC configuration using Wizard

For initial configuration of OTSBC from scratch, it’s recommended to use the SBC Configuration Wizard

software or integrated configuration wizard in web interface management.

Step 1: Product configuration

Select Product, version, End Customer, Country, Integrator and Installer

Step 2: General setup

Select:

- Application: (SIP Trunk IP-PBX with SIP Trunk)

- IP- PBX: Alcatel-Lucent OXE



- SIP Trunk: choose the SIP Trunk name from the list if it’s already added to wizard, otherwise,

Generic SIP Trunk

- Network Setup: Select Two ports: LAN and WAN

Step 3: System Configuration

Enter Primary NTP Server (OXE IP address is recommended) and Time Zone and Syslog IP



Step 4: LAN Interface configuration

Step 5: WAN Interface configuration



Step 6: IP-PBX configuration

Step 7: SIP Trunk Provider configuration



Step 8: Number manipulation rules and routing policy

Step 9: Conclusion, select INI file, then click next, load to device and transfer to SBC.



4.2.2 Additional parameters

Some Parameters are not set by the Wizard. They must be managed manually. If necessary, significant

parameters are detailed in this section (NAT, accounts table, IP profile settings, etc)

4.2.3 Message Manipulation

SIP Message Manipulation is configured in the Message Manipulation table in the OTSBC embedded Web

server. In this section, we describe the SIP messages manipulation rules entries added to transform some SIP

messages and SDP offers details received or sent from OXE/ SIP Trunk carrier that are necessary for a good

working solution.

4.2.4 OTSBC Configuration INI file

The final configuration INI file is saved from OTSBC embedded Web server and attached here.



5 Appendix A: RFCs supported by OmniPCX Enterprise and general

limitations

5.1 RFCs supported by OmniPCX Enterprise

SIP RFCs: 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)

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

RFC 5009: The P-Early-Media header



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)

New RFCs in OXE R11.2.1 and R12.x:

RFC 4904: Representing Trunk Groups in tel/sip Uniform Resource Identifiers (URIs)

RFC 6140: “Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP)”

RFC 7433 A Mechanism for transporting User to User Call Control Information in SIP

draft-ietf-cuss-sip-uui-isdn-08 Interworking ISDN Call Control User Information with SIP

5.2 General Limitations

Here, we list the limitations on OXE side. To bypass some of them, the use of OTSBC is mandatory.

Message Waiting Indication is not supported on Public SIP trunk.

Services like MCID (Malicious Call), modem and data quality (RFC 4040) which are available on ISDN

are not available on SIP trunk.

The possibility to configure RTP transit through an IPMG (media relay) is not available. Nevertheless,

some cases force RTP transit like H323/SIP interworking and Cellular Extension.

VAD (Voice Activity Detection) is not supported on G729A on SIP, as OXE will put annexb=no in the

SDP.

In case of incoming call to OXE through SIP trunk, and if CAC is saturated on the IP domain of called

party, overflow private to public is not performed by OXE. OXE will send a SIP release cause to the

network to take appropriate steps: release call with busy tone, overflow to PSTN trunk in called IP

Domain.

In band DTMF is only with G711 codec.

DTMF with G711 audio (in band DTMF) may need IPMG VoiP ressources. Only INTIP3/GD3 models are

supported and not previous generation of boards (GD2/INTIP2).

RFC 3966: OXE does not support phone-context with tel Uris (as well as isub and ext extensions).

G722 codec is not supported through ABC network.

G711 transparent fax is supported only on INTIP3/GD3 and not on previous generation boards

(GD2/INTIP2).

The audio codec must be G711 to enable G711 fax transparent mode (without or with fallback). If

audio codec is G729A only T38 is supported. OXE should be configured so that G711 audio is

enforced for transparent fax calls. Upspeed G729A to G711 is not supported.

Transit of 302 forwarding message is not supported (if SIP device forwards a call with a 302 toward

OXE, OXE will no send 302 on the SIP trunk).



OXE does not support standards for emergency calling SIP standards (mainly RFC 6442). SIP providers

have different methods for compliance to emergency call regulation (OXE calling the right PSAP

number and providing geolocation information of caller) and in some cases OTSBC can be used.



Submitting a Service Request

Please connect to our eService Request application.

Before submitting a Service Request, make sure that:

In case a Third-Party application is involved, that application has been certified via the AAPP

You have read through the Release Notes which lists new features available, system requirements,

restrictions etc. available in the Technical Documentation Library

You have read through the Troubleshooting Guides and Technical Bulletins relative to this subject

available in the Technical Documentation Library

You have read through the self-service information on commonly asked support questions, known

issues and workarounds available in the Technical Knowledge Center (TKC)

- END OF DOCUMENT -

https://businessportal.alcatel-lucent.com/alugesdp/faces/gesdp/customerSupport/CustomerSupport.jspx

https://businessportal.al-enterprise.com/technical_documentation_library

https://businessportal.al-enterprise.com/technical_documentation_library

https://alcatel-lucent-enterprise.secure.force.com/knowledgebp/pkb_Home_ALU

TC2824 OpenIP France SIP Trunk Solution Configuration ...

Documents

Transcript of TC2824 OpenIP France SIP Trunk Solution Configuration ...