TC2875en-Ed01 SIP Trunk Deutsche-Telekom Company-Flex-with-SIPTLS ConfigurationGuideline R12.4

Technical Bulletin OmniPCX Enterprise
TC2875 ed.01 Release 12.4 and above
SIP Trunk Solution: Deutsche Telekom –

Company Flex with TLS - Configuration
Guideline and Interworking tests
This document details how to set up an OmniPCX ® Enterprise R12.4 for enabling a public SIP trunk with the SIP Provider.
This document describes also the interworking tests between the OmniPCX® Enterprise and the SIP Provider.
Revision History
Edition 1: June 7, 2021 creation of the document
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. Neithe r
ALE Holding nor any of its affiliates assumes any responsibility for inaccuracies contained herein. © Copyright 2021 ALE
International, ALE USA Inc. All rights reserved in all countries.
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 .......................................................................................................................... 7
2 Summary of tests results ......................................................................................................................... 8

2.1 Summary of main functions supported ............................................................................................... 8
2.2 Summary of problems ..................................................................................................................... 10
2.3 Summary of limitations ................................................................................................................... 10
2.4 Notes, remarks ............................................................................................................................... 10
3 Tests results ......................................................................................................................................... 12

3.1 REGISTRATION, AUTHENTICATION & KEEP ALIVE ........................................................................... 15
3.1.1 Registration .............................................................................................................................. 17
3.1.1.1 Registration on SIP Provider without authentication ..............................................................................17
3.1.1.2 Registration on SIP Provider with authentication ..................................................................................18
3.1.2 Authentication on basic calls ...................................................................................................... 20
3.1.2.1 Authentication on outgoing calls .........................................................................................................20
3.1.2.2 Authentication on incoming calls .........................................................................................................22
3.1.2.3 Incorrect Authentication on outgoing calls ...........................................................................................23
3.1.3 Keep Alive ................................................................................................................................ 24
3.1.4 Transport type (UDP & TCP) and Switch UDP to TCP .................................................................. 25
3.1.5 Service Route and Path headers ................................................................................................ 26
3.2 BASIC OUTGOING VOICE CALLS ...................................................................................................... 27
3.2.1 Outgoing calls to PSTN / GSM sets (national and international) .................................................... 27
3.2.1.1 Outgoing calls to PSTN / GSM sets: Establishment of call, Audio & Display ..............................................27
3.2.1.2 Outgoing calls to PSTN / GSM sets: The Early media SDP negotiation (ringing state) ...............................30
3.2.1.3 Outgoing calls to PSTN / GSM sets: The Codecs Media SDP negotiation ..................................................33
3.2.1.4 Outgoing calls to external sets: Local user ends the conversation...........................................................34
3.2.1.5 Outgoing calls to external sets: external set ends the conversation ........................................................35
3.2.2 Outcall phase and call clearing before answer ............................................................................. 36
3.2.3 Call to an incorrect number ....................................................................................................... 37
3.2.4 Call to a busy set ...................................................................................................................... 38
3.2.5 Outgoing calls from Anonymous Calling ...................................................................................... 39
3.2.6 Outgoing long calls ................................................................................................................... 40
3.3 BASIC INCOMING VOICE CALLS....................................................................................................... 41
3.3.1 Incoming public calls from PSTN / GSM sets (national & international) ......................................... 41
3.3.1.1 Incoming public calls with CLI: establishment of call, audio & display .....................................................41
3.3.1.2 Incoming public calls with CLI: The Early media SDP negotiation ...........................................................44
OmniPCX Enterprise - Release 12.4 and above

SIP Trunk Solution: Deutsche Telekom – Company Flex with TLS - Configuration Guideline and
Interworking tests TC2875 ed.01
Copyright © ALE International 2021 page 2/117
3.3.1.3 Incoming public calls with CLI: The Codecs Media SDP negotiation ........................................................46
3.3.2 Ringing phase and call clearing before answer ............................................................................ 47
3.3.3 Incoming calls from Anonymous Calling ..................................................................................... 48
3.3.4 Incoming long calls ................................................................................................................... 50
3.4 OXE User in forward (internal or external) ........................................................................................ 51
3.4.1 Incoming calls: Immediate forward to internal user .................................................................... 51
3.4.2 Incoming calls: OXE User in immediate forward to external set .................................................... 52
3.4.3 Incoming calls: Forward on no answer to external set ................................................................. 56
3.5 OXE User not available .................................................................................................................... 58
3.5.1 Incoming public call: OXE user in “Do Not Disturb” ..................................................................... 58
3.5.2 Incoming public call: OXE non-attributed number ....................................................................... 59
3.5.3 Incoming public call: OXE user is Busy ....................................................................................... 60
3.6 Advanced features for communications ............................................................................................ 61
3.6.1 Call on Hold / Retrieve .............................................................................................................. 61
3.6.2 Call on Mute ............................................................................................................................. 63
3.6.3 Early Attended transfer (on ringing): transfer to internal user ...................................................... 64
3.6.4 Early Attended transfer (on ringing): transfer to external set ....................................................... 65
3.6.5 Supervised call transfer (after answer): transfer to internal user .................................................. 68
3.6.6 Supervised call transfer (after answer): transfer to external set ................................................... 69
3.6.7 Conference (3-Party) ................................................................................................................. 72
3.6.8 DTMF ....................................................................................................................................... 73
3.6.8.1 DTMF for outgoing call .......................................................................................................................73
3.6.8.2 DTMF for incoming call ......................................................................................................................75
3.6.9 Call Admission Control ............................................................................................................... 76
3.7 FAX Transmission............................................................................................................................ 77
3.7.1 FAX Transmission with analog FAX machine attached on OXE ...................................................... 77
3.7.2 FAX Reception with analog FAX machine attached on OXE .......................................................... 79
3.7.3 FAX Transmission from FAX Server ............................................................................................ 81
3.7.4 FAX Reception from FAX Server ................................................................................................. 82
4 “Deutsche Telekom Company Flex with TLS” SIP Trunk Solution Configuration ......................................... 83
4.1 OmniPCX Enterprise configuration .................................................................................................... 83
4.1.1 Signaling protocol and number of physical channels .................................................................... 83
4.1.2 Trunk Configuration .................................................................................................................. 83
4.1.2.1 Trunk Group .....................................................................................................................................83
4.1.2.2 Trunk Group local parameters.............................................................................................................84
4.1.2.3 Trunk Group NPD selector ..................................................................................................................84
4.1.2.4 Trunk Group COS and Timers .............................................................................................................85
4.1.3 ARS Configuration ..................................................................................................................... 85
4.1.3.1 ARS Prefix.........................................................................................................................................85
4.1.3.2 ARS Route list and ARS Route.............................................................................................................85
4.1.3.3 Time Based Route List .......................................................................................................................86
4.1.3.4 Numbering Command Table ...............................................................................................................86
4.1.3.5 NPD .................................................................................................................................................87
4.1.4 External Callback Translator ...................................................................................................... 87

4.1.5 SIP Gateway and SIP Proxy Configuration .................................................................................. 88
4.1.5.1 SIP Gateway .....................................................................................................................................88
4.1.5.2 SIP Proxy ..........................................................................................................................................88
4.1.5.3 SIP Registrar .....................................................................................................................................89
4.1.5.4 Trusted IP addresses .........................................................................................................................89
4.1.6 SIP External Gateway Configuration ........................................................................................... 89
4.1.7 System Parameters Configuration .............................................................................................. 91
4.2 OTSBC configuration ....................................................................................................................... 93
4.2.1 Initial OTSBC configuration using Wizard .................................................................................... 93
4.2.2 Additional parameters ............................................................................................................... 98
4.2.3 Security Settings ..................................................................................................................... 106
4.2.4 Message Manipulation ............................................................................................................. 108
4.2.5 OTSBC Configuration INI file ................................................................................................... 114
5 Appendix A: RFCs supported by OmniPCX Enterprise and general limitations .......................................... 115
5.1 RFCs supported by OmniPCX Enterprise ......................................................................................... 115
5.2 General Limitations ...................................................................................................................... 116

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 with SIP-TLS and SRTP between OTSBC and SIP Provider.
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.4 m5.204.2b
OTSBC (if part of Topology) Mediant SW 7.20A.204.108
For OXE Users, all tests are done with:

- Alcatel-Lucent Enterprise IP Phone (Noe mode : 8xx8 series)
- One analog FAX
Following user sets have been used during validation:

Directory Number Type Description Entity
100 IP phone Alcatel-Lucent IPTouch 8078s 10
103 Softphone IPDSP 10
199 SIP- XLITE 10

Softphone
201 IP-Phone Alcatel-Lucent IPTouch 8082 10
250 Analog Fax Fax HP Office Jett 4500 10
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 B:
Architecture: OXE <== SIP without encryption ==> OTSBC <== SIP TLS ==> SIP Provider
Using SIP-TLS is mandatory if the Internet Access is no Deutsche Telekom Access. In Test the
Internet Access is provided by Vodafone (Unitymedia-Cable) with a Deutsche Telekom
CompanyFlex Pure SIP-Trunk.

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
#122  Authentication for incoming calls NA
#123  Incorrect Authentication on outgoing calls OK Call is rejected

System Parameters:
#131 Keep Alive OK
#141 Session Timer RFC 4028 OK Update Method

#151 Transport type and Switch UDP to TCP NA
#161 Service Route and Path headers OK
BASIC VOICE CALLS

Outgoing calls to PSTN/ GSM sets:
 Simple call:
#211 - Call establishment, audio & display set
OK
#212 - Early Media SDP negotiation (ringing state)
#213 - Codecs Media SDP negotiation
#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
#241  Outgoing call to a User Busy OK
#251  Outgoing call from OXE anonymous set OK
#261  Outgoing long call OK

Incoming calls from PST/ GSM sets:
 Simple call:
#311 - Establishment & release, audio & display
OK
#312 - Early Media SDP negotiation (ringing state)
#313 - Codecs Media SDP negotiation
#321  Incoming phase & call clearing before answer OK
#331  Anonymous incoming calls OK
#341  Incoming long call OK
Forward:
#411  Immediate Forward to internal user OK
#421  Immediate forward to external user OK
#431  Forward on no answer to external user OK
Subscriber not available:

#511  User in “Do not disturb” OK
#521  Non-attributed OXE user number OK
#531  User busy OK
ADVANCED FEATURES FOR COMMUNICATION

#611  Enquiry call (call hold / call retrieve) OK a=sendrecv
#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 RE-INVITE with SDP
#651  Supervised call transfer to internal user OK
#661  Supervised call transfer to external set OK RE-INVITE with SDP

#671  Conference OK
#681  DTMF for outgoing call

OK RFC 4733
#682  DTMF for incoming call (Immediate forward to VM)
#691  CAC OK
FAX TRANSMISSION
#711  Fax Machine transmission OK G711 Only
#721  Fax Machine reception OK G711 Only
#731  Fax Server transmission NT
#741  Fax Server reception NT
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).

2.2 Summary of problems
2.3 Summary of limitations

Deutsche Telekom published in External Spec for Company Flex 1TR119-v1.8.0, indicating that REFER method
for Transfer is no more supported. In older editions of this document this restriction was not mentioned.
Generally speaking: very often possible limitations are dependent on the user at the far end
behind the provider’s network. Frequently problems appeared if far end is a SIPGate user.
2.4 Notes, remarks

 Using SIP-TLS is mandatory if the Internet Access is no Telekom Access.
 REGISTER, AUTHENTICATION (and Nonce Caching): Done by the OTSBC
 System parameters:
- Transport type: UDP from OXE to SBC & TCP from SBC to SIP Provider
- Session Timer RFC 4028: UPDATE method
- “Service Route” and “Path” are supported
 Incoming calls:
- SIP Provider provides several codecs depending on caller. OXE will support G711, G729
- Early media: OXE doesn’t provide SDP in 18x. In INVITE, there is always “Allow: UPDATE” and
“Supported: 100rel”
- Numbering Format from SIP Provider: canonical (+e164)
- The association to the SIP external gateway is done thanks to the “Via” header in the received
INVITE
 Outgoing calls:
- Supported codecs in OXE: G711, G729.
It is highly recommended not to use G729 as single codec only.
- Early media: Depending on destination, the SIP Provider provides the RBT or NOT. In 18x, there is
always “Allow: UPDATE” and “100rel” in “supported” or “required” headers.
- Numbering Format from OXE: canonical (+e164)
 Outgoing calls to incorrect number: Early media announcement is played.
 External Transferred calls: RE-INVITE WITH SDP method supported
 External Forwarded calls: “302 Moved Temporarily” supported and “181 Forwarded” supported
with History-info header
 On Hold feature: “a=sendrecv” method used

 DTMF: RFC 4733 method
 FAX: G711 Only

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
Test Case #xxx N/A OK NOK Comment
Case Id
Configuration
 Action 1
1  Action 2
 Action n
Test scenario
 Action 1
2  Action 2
 Action n
Check
 Action 1
3  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
N/A OK NOK Comment
Case Id
Check
 Action 1
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
N/A OK NOK Comment
Case Id
Check
 Action 1
1  Action 2
 Action n
The result:
Test
N/A OK NOK Comment
Case Id
Check
 Action 1
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
Test Case #111 N/A OK NOK Comment
Case Id
 Configure the external SIP gateway (belonging
domain, registration Id, registration timer)
1
Configuration for topology B:
 Configure the SBC
Registering
2  Validate the OXE (or SBC) configuration
Check
3  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
Case Id
 Configure the external SIP gateway
1 Topology B used
Registering
2  Validate the OXE (or SBC) configuration
Check
 Check the REGISTER messages
3 REGISTER by OTSBC
 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
Case Id
 Configure the external SIP gateway SBC configured for
1 nonce cashing for
 Configure the SBC INVITE
Outgoing call
 An OXE user makes an outgoing call to an
external user
2  The external user answers the call
 The conversation stays at least 10 seconds
 Someone hangs up the call

Check DIGEST method
 That the call is well established
 The different SIP exchanges between OXE and Digest-Authentication
3 SIP Provider
done by SBC
 Which system does the DIGEST authentication
(OXE or SBC)?
Check Nonce caching (for topology A or C)

 Does the SIP Provider support Nonce caching?
4  If yes, check that the call is well established Nonce caching by SBC
 If yes, check the different SIP exchanges
between OXE and SIP Provider
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
Case Id
 Configure the external SIP gateway and Proxy
No incoming Digest-
1
Configuration for topology B: Authentication
Incoming call
 Incoming call from an external to an OXE user
2  The OXE user answers the call
Check
3  The different SIP exchanges between OXE and
SIP Provider
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
Case Id
 Configure the external SIP gateway with
1 incorrect pwd
 Configure the SBC (with incorrect pwd)
Outgoing call
2 An OXE user makes an outgoing call to an
external user
Check
 That the call is refused by the SIP Provider
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
Case Id
Configuration
 Configure the external SIP gateway (OPTIONS Timer Set to 60 sec in
1
required and supervision timer) external SIP Gateway
Check
 Does the SIP Provider support OPTIONS? If yes,
see below the tests. OPTIONS are sent
 The OXE sends OPTIONS to the SIP Provider
2 every 48 sec (80% of
 The SIP Provider answers with a 200 OK
 The OXE sends OPTION after the superv. timer 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
N/A OK NOK Comment
Case Id
From OXE to SBC:
Check UDP is used
1  Which transport type is used? UDP or TCP?
From SBC to Provider:
TCP is used
Check Fixed TCP used
2  Does the SIP Provider support the switch to TCP?
towards Provider

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
N/A OK NOK Comment
Case Id
Check
 Are these RFC supported by the SIP Provider? Header are used by
1  If SIP Provider doesn’t support these RFCs, no
eSBC
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: +33155664000@sip.mySIP_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
Case Id
Configuration
1
 Configure the OXE for the SIP outgoing call.
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
2 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
Check numbering formats from OXE and SIP Provider

 Which numbering format (canonical or not) is
used from OXE side? Canonical number
3
 Which numbering format (canonical or not) is format is used
used from SIP Provider side?
Check: OXE user to GSM National set #211-1 Checked with D1, O2
 That the call is well established (Telefonica)
4  The normal audio during conversation
Display is Canonical
 What is displayed on PSTN/GSM Provider set?
number +49 6151 ….
Check: OXE user to GSM InterNational set #211-2
 That the call is well established No international call
d  The normal audio during conversation with test trunk
 What is displayed on PSTN/GSM Provider set? possible - prohibited
Check: OXE user to PSTN National set #211-3

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

7  That the call is well established with test trunk
 The normal audio during conversation
possible - prohibited

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?
- 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?

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?
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
N/A OK NOK Comment
Case Id
Check RBT
 Does the SIP provider provide SDP in
Depending on destination:
1 18x responses? If yes, does the OXE Yes on GSM calls
user hear it? No on PSTN calls
Check PRACK
 Does the SIP provider require the Depending the destination, PRACK
2 provisional response to be
is required even if no SDP in 18x
acknowledged with PRACK?
Check UPDATE from SIP Provider

 Does the SIP Provider send UPDATE
3 message in early media phase to
change media?
In 18x, there is always “Allow :

UPDATE” and “100rel” supported
Check UPDATE from OXE or required.
 Does the SIP Provider support the If needed, setting needs to be SIP/
4 reception of UPDATE message with
SIP External gateway /Outbound
SDP in Early Media?
calls 100 REL: Required to
authorize the OXE to send
UPDATE
Check P-Early-Media
 Does the SIP provider request the
5 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
With encryption it is necessary to set Parameter “SBC Performance Profile” to “Optimized for
Transcoding”, otherwise OTSBC messages towards OXE result in “488 Not acceptable here”.
Depending on configuration other codec could be used by Re-Invite: switch to G711.
Furthermore this is dependent on the destination: if answer, depending on destination, is with G729
call is disconnected in many cases with “500 internal server error” from Provider.
So it is highly recommended not to use G729 as single codec only.
Test
N/A OK NOK Comment
Case Id
Check the supported codecs of the SIP Provider
1  Which codecs are supported by the G711A, G729
OXE/SIP Provider?
Depending on destination
Check the multi-codecs
capability
 in case both G729A and G711 are
supported, in some cases OXE sends Type of codec negotiation =
2
INVITE offer with G729A only. Would this Default or G711 only
offer be accepted? + OXE system parameter:
G722 for SIP Trunking= False

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
Case Id
Configuration
1  Configure the OXE for the SIP outgoing call.
Outgoing call
Provider external set.
2  The SIP Provider external set answers the call
 Local user hangs up the call
Check
 The call is well established and released
SIP Provider
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
Case Id
Configuration
Outgoing call
Provider external set
2  The SIP Provider external set answers the call
 External set set hangs up the call
Check
 The call is well established and released
SIP Provider
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
Case Id
Configuration
Outgoing call
2 Provider external set
 The SIP Provider external set rings
 The OXE user hangs up the call.
Check
 The call is well released Call is properly
released
SIP Provider
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
Case Id
Configuration
Outgoing call
2  An OXE user makes an outgoing call to an
incorrect SIP Provider external set number
Here the Provider sends an

announcement: “Die gewählte
Rufnummer ist nicht gültig …” or
Check
„Die Verbindung kann zur Zeit
 The display of the OXE user set
 The heart tone of the OXE user set nicht hergestellt werden …“
3
 The different SIP exchanges between OXE and Later Provider sends „487
SIP Provider Request Terminated“
Display shows „Überlastung“
Trunk is properly released
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
Case Id
Configuration
Outgoing call
 The SIP Provider external set is busy
2  An OXE user makes an outgoing call to this SIP
Provider external set
Check
 The display of the OXE user set The SIP Provider sends “486
3  The busy tone heart of the OXE user set Busy here”
 The different SIP exchanges between OXE and
SIP Provider
Display shows “besetzt”
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:+anonymous@anonymous.invalid>
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
Case Id
Configuration
 Configure the SIP external gateway for
1 anonymous outgoing call (RFC 3325 supported
by the distant)
Outgoing call
 An OXE user uses the secret identity
 This OXE user makes an outgoing call to a SIP
2 Provider external set
 The SIP Provider external set answers the call
Check
 The display of the external set Display on opposite side
indicates privacy.
SIP Provider
From OXE point of view

Check method both methods can be used.
4  Which method is used for anonymous? Outbound Manipulation in
eSBC forces
RFC3325,3324,3323

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
Case Id
Configuration Provider indicates:
 In SIP external gateway, modify the Session Session Interval too
Timer to a value as 200 or a small value to see short and accepts
the RE-INVITE / UPDATE more quickly.
1 900. SBC makes
 BE CAREFUL: this value is just for this test. At
the end of the test, come back to the previous INVITE then with
value Session Timer 900,
Min-SE 900
Check the SIP messages
2  Does the SIP Provider support RFC 4028? UPDATE method used
 If yes, which method is used, INVITE or UPDATE?
OXE continues
sending Updates with
Check the call session timer 200
3  Is the call well established after the session after 100 sec. Call
timer expiry? keeps well
established.

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: +33155664000@sip.mycompany.com) 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
Case Id
Configuration The association to SIP
 Configure the OXE (SIP ext gateway, trunk EXT GW is done
1
group, NPD, country code, ext. callback thanks to the Via
translator…) header
Inbound call: 4 tests
 GSM National set to OXE user #311-1
2  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
 The OXE user answers the call
Check numbering formats from SIP Provider and OXE

 Which numbering format (canonical or not) is Canonical Format
3 used from SIP Provider side? used from Provider
 Which numbering format (canonical or not) is
used from OXE side? and OXE
Check: GSM National set to OXE user

 That the call is well established and released Display of GSM set
4  The normal audio during conversation shows number as
 What is displayed on PSTN/GSM Provider set? dialed
Check: GSM InterNational set to OXE user

 That the call is well established and released
Check: PSTN National set to OXE user

 That the call is well established and released Display of PSTN set
6  The normal audio during conversation shows number as
 What is displayed on PSTN/GSM Provider set? dialed
Check: PSTN InterNational set to OXE user

 That the call is well established and released
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: YES or NO
- 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?

SIP/ SIP External gateway / Inbound calls 100 REL: Not Requested / Required 1 / Required 2
- 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?
Test
N/A OK NOK Comment
Case Id
Check RBT SDP in 18x = False: RBT
1  Does the OXE provide SDP in 18x responses? provided by provider
If yes, does the PSTN/GSM set hear it?
Check PRACK
 If the OXE plays the RBT for incoming calls
2 (180 with SDP), is the 100rel header in Supported
INVITE sent by SIP provider absent,
supported or required?
Yes. If needed, setting

Check UPDATE from OXE needs to be SIP/ SIP
 Does the SIP Provider support UPDATE External gateway / Inbound
3 message with SDP in early media phase to
calls 100 REL: Required
change media?
Mode 1

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
N/A OK NOK Comment
Case Id
Check the supported codecs of the SIP Provider Depending on caller
1  Which codec are provided in INVITE? side various Codecs
are received.
Depending on caller’s
media offer G729 is
accepted.
Check the multi-codecs
 In case both G729A and G711 are supported, in
Type of codec
2 some cases OXE sends INVITE offer with G729A negotiation = Default
only. Would this offer be accepted? or G711 only
+ OXE system
parameter: G722 for
SIP Trunking= False

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
Case Id
Configuration
1  Configure the OXE for the SIP incoming call.
Incoming call
 A SIP Provider external set makes an incoming
2 call to an OXE user
 The OXE user rings
 The external set hangs up the call.
Check
 The call is well released
SIP Provider
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:+anonymous@anonymous.invalid>
 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
Case Id
Configuration
1  Configure an external set in secret
identity
Incoming call
 This set makes an incoming call to an
OXE user
2  The OXE user answers the call
 The conversation stays at least 10
seconds
Check Display in ringing state and

 The display of the OXE user set (in conversation state shows Trunk
3
ringing state and in conversation state) Group Name as entered in
configuration

Provider uses “trusted mode”
with privacy headers - at the
same time From header is:
anonymous@anonymous.invalid
Check method with no PAI
4  Which method is used for CLIR?
SBC turns From header into

“Anonymous”
<sip:+anonymous@ SBC -
Address plus Privacy headers

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
Case Id
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
1 for the session timer of the SIP Provider Refresher is uac
 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
Check the SIP messages

2  Does the SIP Provider support RFC 4028? UPDATE Method
 If yes, which method is used, INVITE or UPDATE?
Session Update is received
Check the call after 15 min i.e. 900 sec.
3  Is the call well established after the session timer
This his half session timer
expiry?
or equal: Min-SE

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
Case Id
Configuration
1  Configure an OXE user in Forwarded to other internal user
immediate forward to Voicemail
Incoming call to the OXE

2  The external set makes an
incoming call to an OXE user
Check Callers Display shows originally

 The display of the external set called number in conversation
3  Check the SIP messages
Internal user destination is provided
exchanges
in PAI-Header of 200 OK message

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
Test Case #421-1 N/A OK NOK Comment
Case Id
Configuration
 Configure an OXE user in immediate External Gateway:
1 forward to an external set 2. Support Redirection Response =
 Configure the OXE for the “181
Forwarded” method No

2  The external set 1 makes an incoming
call to an OXE user
Check External 1 shows dialed number

 The display of the external set 1 External 2 shows caller’s
3  The call audio
number (i.e. External 1)
 The release of the call
Release from both sides ok
Check method 181 Forwarded
 Which method is used: History-Info or Method History Info is used
4 Diversion header? Message exchange as described
 The SIP messages exchanges above
3.4.2.1.3 Tests results for the “302 Moved Temporarily” method IF SUPPORTED BY SIP PROVIDER
Test
Case Id
Configuration
 Configure an OXE user in immediate External Gateway:
1 forward to an external set 2. Support Redirection Response =
 Configure the OXE for the “302 Moved
temporarily” method Yes

call to an OXE user
Check External 1 shows dialed number

 The display of the external set 1 External 2 shows caller’s number
(i.e. External 1)
Check method 302 Moved Temporarily Message exchange as described
4  The SIP messages exchanges
above
Remark: Same behavior with External Forward on busy. History shows different cause in this case.

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
Case Id
Configuration
 Configure an OXE user in forward on External Gateway:
1 no answer to an external set 2. Support Redirection Response =
 Configure the OXE for the “181
Forwarded” method No

call to an OXE user
External 1 shows dialed number

Check No display change after switching
 The display of the external set 1 to external call.
External 2 shows caller’s number
(i.e. External 1)
Check method 181 Forwarded
 Which method is used: History-Info or
4 Diversion header? History Method used
 The SIP messages exchanges
3.4.3.1.3 Tests results for the “302 Moved Temporarily” method IF SUPPORTED BY SIP PROVIDER
Test
Case Id
Configuration
 Configure an OXE user in forward on External Gateway:
1 no answer to an external set 2. Support Redirection Response =
 Configure the OXE for the “302 Moved
temporarily” method Yes

call to an OXE user
External 1 shows dialed number

Check No display change after switching
 The display of the external set 1 to external call.
External 2 shows caller’s number
(i.e. External 1)
Check method 302 Moved Temporarily

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
Case Id
Configuration
1  Configure an OXE user in Do Not
Disturb.

2  The external set makes an
incoming call to this OXE user
Display is different, depending on

Check
caller.
 The display of the external set Tone can be busy-tone or
3  The heart tone on external set announcement depending on caller
 The SIP messages exchanges side.
Message is as described with 480
Temporary Unavailable

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
Case Id
 The external set makes an incoming
1 call to an OXE non-attributed
number
Display of external set shows

Check
dialed number
 The display of the external set Heard Tone or voice guide
2  The heart tone on external set (announcement) is dependent on
 The SIP messages exchanges calling Provider network
Concerning SIP-Messages
exchanges see remark below
Remark:
Behavior is dependent on DDI-Translator settings:
if called number is not in a DDI Range – OXE sends 404 Not Found
If called number is within DDI-Range but not existing – OXE sends 484 Address incomplete (Default).
This could be changed in SIP > CH to SIP Error Mapping: Invalid Number Format -> change “Address
incomplete“ into “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.
Check the SIP messages exchanges
Test
Case Id
Configuration
1  Put an OXE user in busy state.

2  The external set makes an incoming
call to this OXE user.
Check
Caller’s display dependent on
 The display of the external set network and capability.
3  The heart tone on external set Sometimes busy is shown,
 The SIP messages exchanges sometimes there is only busy
tone.

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 Test Case #611 N/A OK NOK Comment
Id
Configuration
1 A=sendrecv
 Configure the OXE
Test call
 The external set makes an incoming call to an OXE user.
2  After several seconds, the OXE user puts the call on hold
 After several seconds, the OXE user retrieves the call
Check
 The call is OK from audio side
 SIP/ SIP Ext Gateway / Send only for Hole = YES or NO


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
Case Id
Test call
 The external set makes an incoming call to an
OXE user.
1  After several seconds, the OXE user presses the
Mute button
 After 5 minutes, the OXE user devalidates the
Mute
Check
 The display of the external set No SIP message for
2  The silence on external set during the mute
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
Case Id
Test call
 The OXE user A makes an outgoing call to an
external set.
 The external set answers the call
1  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
Check
 The display of the external set Display of external
2
 The audio on external set set unchanged
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
Case Id
Configuration
1  Configure the SIP external gateway for the RE-
INVITE method
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
2 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
 The external set 1 hangs up the call.
Check Display 1 and 2 show
 The display of the external sets 1 & 2 OXE user’s number.
3  The audio on external sets 1 & 2
Not updated after
Transfer.
3.6.4.1.3 Tests results for REFER/REPLACE method IF SUPPORTED BY SIP PROVIDER
Test
Case Id
Configuration
1  Configure the SIP external gateway for the
REFER/REPLACE method
Test call
external set 1.
 The external set 1 answers the call
2 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
Check
 The display of the external sets 1 & 2

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
Case Id
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
1 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
Check
 The display of the external set External set continues
2  The audio on external set to show phone
 The SIP messages exchanges number of user A
Expected behavior:

3.6.6 Supervised call transfer (after answer): transfer to external set
Objectives:
The OXE user makes an outgoing call to an external set 1.
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
Case Id
Configuration
1  Configure the external SIP gateway for the RE-
INVITE method
Test call
external set 1. They are in conversation
enquiry call to an external set 2.
2  External set 2 answers the call.
 The OXE user presses “transfer”
 The external sets 1 & 2 stay in conversation
Check
 The display of the external sets 1 & 2 Both external sets
3  The audio on external sets 1 & 2 show phone number
 The SIP messages exchanges of user A
3.6.6.1.3 Tests results for the REFER/REPLACE method IF SUPPORTED BY SIP PROVIDER
Test
Case Id
Configuration
1  Configure the external SIP gateway for the
REFER/REPLACE method
Test call
external set 1. They are in conversation
enquiry call to an external set 2.
2  External set 2 answers the call.
 The OXE user presses “transfer”
 The external sets 1 & 2 stay in conversation
Check
 The display of the external sets 1 & 2

3.6.7 Conference (3-Party)
Objectives:
The OXE user makes an outgoing call from an external set 1.
After several seconds, the OXE user makes an enquiry call to an external set 2.
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
Case Id
Test call
 The OXE user makes an outgoing call to an If OXE user hangs up
external set 1.
first in the
enquiry call to an external set 2. conference the 2
1
 The OXE user presses “conference” external sets are
 The external sets 1 & 2 and the OXE user stay in connected as in
conference during at least 10 sec.
transfer
 The external sets 1 & 2 and OXE user hang up
the call.
Check
 The display of the external sets and OXE user
3  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
Case Id
Configuration
Outgoing call
 An OXE user makes an outgoing call to an
2 external IVR
 The IVR answers
 The OXE user sends several DTMF
Check
 Which mode is used for DTMF? RFC4733 is used with
3  The different SIP exchanges between OXE and suggested payload
SIP Provider 101

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
Case Id
Configuration
1  Configure an OXE user in immediate forward to No Voicemail possible
Voicemail

2  The external set makes an incoming call to an
OXE user
Check
 The display of the external set
RFC4733 is used
 The audio message and the possibility to
navigate in the menus with DTMF Received telephone
3
 Which mode is used for DTMF? events correctly sent
 The different SIP exchanges between OXE and to destination
SIP Provider

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
Case Id
Configuration
1  Configure the OXE for the SIP incoming call.
Incoming call
2  An external set makes an incoming call to an
OXE user when CAC is saturated.
Heard tone
Check dependant on caller
 The heart tone an display on external set side: Busy Tone or
Announcement.
SIP Provider
Provider repeats
INVITEs.
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
Case Id
Configuration
1  Configure the OXE with analog FAX user
Outgoing transmission from the OXE

2  The analog FAX machine makes an outgoing call
to public FAX user and sends 3 pages.
Check
 The public FAX user receives the 3 pages
3  Which method is used for the FAX transmission? G711 Only

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
Case Id
Configuration
1  Configure the OXE with analog FAX user
Incoming reception on the OXE

2  The public FAX user makes an incoming call to
the OXE FAX user and sends 3 pages.
Check
 The OXE FAX user receives the 3 pages
3  Which method is used for the FAX reception? G711 Only

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
Case Id
Configuration
1  Configure the OXE with a FAX server user
Outgoing transmission from the FAX Server

2  The FAX Server user makes an outgoing call to a
public FAX user and sends 3 pages.
Check
 The public FAX user receives the 3 pages
3  Which method is used for the FAX transmission? Not Tested

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
Case Id
Configuration
1  Configure the OXE with a FAX Server user
Incoming reception on the OXE

2  The public FAX user makes an incoming call to a
FAX Server user and sends 3 pages.
Check
 The FAX Server user receives the 3 pages
3  Which method is used for the FAX reception? Not tested

4 “Deutsche Telekom Company Flex with TLS” 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: -- CompFlex
UTF-8 Trunk Group Name: --------------------
Number Compatible With: -1 -1
Remote Network: 15 15
Node number: -- 1
Q931 Signal variant ISDN FRANCE ISDN all countries
Number of Digits To Send 0 0
T2 Specificity None SIP
Public Network Category: 0 31
DDI transcoding False True
Can support UUS in SETUP True True
Associated Ext SIP gateway: -1 -1
4.1.2.2 Trunk Group local parameters

Mgr  Trunk Groups  Trunk Group

Trunk Group ID: -- 10-
Trunk Group Type T2 T2
T2 Specification None SIP
Entity Number: 0 10
End to end dialing NO No
DTMF end to end signal. NO No
Trunk group used in DISA NO No
Trunk COS 31 31
Nb of digits unused (ISDN): 0 0
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

Trunk Group ID -- 10
Public NPD ID 10 33
Private NPD ID 0 0
Management Mode Automatic Normal
Public DID transcoding True N/A

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

Trunk COS : 31 31
T2 T0 ABC-F ISDN Trunks
Timer T303 100 100
Timer T304 300 900
Timer T310 200 200
Timer T313 40 40
Timer T305 40 40
Timer T308 40 40
Timer T309 900 900
Timer T302 150 150
Timer T386 200 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

Number : -- 0
Prefix Meaning ARS Prof. Trk Grp Seizure ARS Prof. Trk Grp Seizure
Discriminator No: -- 0
4.1.3.2 ARS Route list and ARS Route
Mgr  Translator  Automatic Route Selection  ARS Route List
Description Carrier’s value Carrier’s value Carrier’s value Carrier’s value

ARS Route list: 10 11 12 13
Name: CompanyFlex Nat CompanyFlex Int CompanyFlex Lok CompanyFlex Not
PIN Code False False False False

And Mgr  Translator  Automatic Route Selection  ARS Route List  ARS Route

Route: 1 1 1 1
Name: CompanyFlex Nat CompanyFlex Int CompanyFlex Lok CompanyFlex Not
Trunk Group Source Route Route Route Route
Trunk Group: 10 10 10 10
Nb.Digits To Be Removed: 1 2 0 0
Digits To Add: 49 -- 496151 --
Numbering Command Tabl.ID 10 10 10 10
VPN Cost Limit: 0 0 0 0
Protocol Type Dependant on Trunk Group Dependant on Trunk Dependant on Trunk Dependant on Trunk
Type Group Type Group Type Group Type
NPD identifier: 33 33 33 34
Route Type Public Public Public Public
ATM Address ID: -1 -1 -1 -1
Preempter False False False False
Quality Speech + Fax Speech + Fax Speech + Fax Speech
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

Time Based Route List ID: 1 1 1 1
Route Number: 1 1 1 1
Waiting Cost Limit: -1 -1 -1 -1
Stopping Cost Limit: -1 -1 -1 -1
4.1.3.4 Numbering Command Table

Mgr  Translator  Automatic Route Selection  Numbering Command Table

Table ID: 1 10
Carrier Reference: 0 0
Command: -- I
Associated Ext SIP gateway: -1 10

4.1.3.5 NPD
Mgr  Translator  External Numbering  Numbering Plan Description (NPD)
Description Carrier’s value Carrier’s value

Description identifier: 33 34
Name: CompanyFlex DTAG CompFlex Not/Sonder
Calling Numbering plan ident. NPI/TON ISDN International NPI/TON ISDN International
Called numbering plan ident. NPI/TON ISDN International Unknown
Authorize personal calling num use True False
Install. number source Entity source Entity source
Default number source Entity source Entity source
Called DID identifier: 10 -1
Calling/Connected DID identifier: 0 0
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

Trunk Group ID: -- --
Trunk Group Type T2 T2
T2 Specification None SIP
Entity Number: 0 10
Mgr  Entity
Entity number: 0 10
External Callback Table 0 0
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 0
Basic Number A A49 DEF
No. Digits To Be Removed 1 3 0
Digits To Add 000 00 00

4.1.5 SIP Gateway and SIP Proxy Configuration
4.1.5.1 SIP Gateway

Mgr  SIP  SIP Gateway

SIP Subnetwork: -- 10
SIP Trunk Group: -- 1
IP Address: -- @IP OXE
Machine name - Host: -- Host OXE
SIP Proxy Port Number: 5060 5060
SIP Subscribe Min Duration: 1800 600
SIP Subscribe Max Duration: 86400 86400
Session Timer: 1800 1800
Min Session Timer: 900 900
Session Timer Method: UPDATE UPDATE
DNS local domain name: Domain name
DNS type DNS A DNS A
SIP DNS1 IP Address: -- IP@ DNS
SIP DNS2 IP Address:
SDP in 18x: True True
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

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: -- oxe
Only authenticated incoming calls: True False
Framework Period: 3 3
Framework Nb Message By Period: 25 25
Framework Quarantine Period: 1800 1800
TCP when long messages: True False
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

Min expiry date: 1800 600
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 @IP OTSBC
4.1.6 SIP External Gateway Configuration

mgr  SIP  SIP Ext Gateway

SIP External Gateway ID: -- 10
Gateway Name: -- CompanyFlex DTAG
SIP Remote domain: -- @IP OTSBC
PCS IP address: --
SIP Port number: 5060 5060
Transport type: UDP UDP
Belonging domain: -- tel.t-online.de
Registration ID: -- +49XXXXXXXXXXX
Registration ID in P_Asserted: False True
Registration timer: 0 0
SIP Outbound Proxy: -- @IP OTSBC
Supervision timer: 0 75
Trunk group number: -1 10
Pool Number: -1 -1
Outgoing realm: -- tel.t-online.de
Outgoing username: -- +49XXXXXXXXXXXXXXX@tel.t-online.de
Outgoing Password: -- ********
Incoming username: --
Incoming Password: --
RFC 3325 supported by the distant: True True
DNS type: DNS A DNS SRV
SIP DNS1 IP Address: --
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 False
Dynamic Payload type for DTMF: 101 101
Outbound Calls 100 REL: Supported 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 True
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 Mode 1
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 Empty always
Session Timer 1800 1800
Min Session Timer 900 900
Session Timer Method UPDATE UPDATE
Trusted From header: False False
Support Re-invite without SDP: True True
Type of codec negotiation Default Default

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 False
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 True
Enhanced Canonical Form False False
SIP UUI Normal Transit False N/A
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 N/A
Mgr  System  Other System Param.  Compression
System compression parameters OXE default Value Carrier’s value

Voice Activity Detect (Comp Bds) False False
Compression Type G 723 G 729
Multi. Algorithms for Compression False False
Voice Activity Detection on G711 False False
G722 data rate 64 K 64 K
G722 Conference With OMS True 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 33
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 49
Mgr  IP  IP Parameters
IP parameters OXE default Value Carrier’s value

Jitter buff size (modem/fax transp) 40 40
G711 VOIP Framing 20 ms 20
Jitter algorithm (voice) 1 1
Jitter buffer size (voice) 30 30
DTMF mode 0 0
CAC with OTMS/OTBE False False
Mgr  IP  Fax parameters
Fax parameters OXE default Value Carrier’s value

T38 only False False
Local T38 port number RTP port number RTP port number + 3
NAT Support for FAX T38 False 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)
For SIP-TLS and SRTP it is necessary to install the “Deutsche Telekom Ceritificate” on the OTSBC.
This certificate is T-TeleSec GlobalRoot Class 2 with fingerprint
590d2d7d884f402e617ea562321765cf17d894e9 and can be downloaded from :
https://www.telesec.de/de/root-programm/informationen-zu-ca-zertifikaten/root-ca-zertifikate/
Furthermore additional headers for TLS and SDP attributes for Media Encryption need to be implemented on
OTSBC. A detailed description can be found in Document:
1TR119 Technical Specification of the SIP-Trunking Interface for CompanyFlex of Deutsche Telekom
that can be downloaded from:
https://www.telekom.de/hilfe/geraete-zubehoer/telefone-und-anlagen/informationen-zu-
telefonanlagen/schnittstellenbeschreibungen-fuer-
hersteller?wt_mc=alias_schnittstellenbeschreibungen&samChecked=true
For implementation screenshots will be provided below

Account - Table

IP-Group

Proxy-Set

IP-Profiles

4.2.3 Security Settings
Here we describe the configuration for implementing the root certificate provided by Deutsche Telekom and
the Media Security Settings
TLS-Contexts

Media Security

4.2.4 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.5 OTSBC Configuration INI file
The final configuration INI file is saved from OTSBC embedded Web server and attached in the pdf doc:
Please rename the .txt file in .ini file to open it.

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.
 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, please be sure:

 The application has been certified via the AAPP if a third party application is involved.
 You have read the release notes that list new features, system requirements, restrictions, and more,
and are available in the Technical Documentation Library.
 You have read through the related troubleshooting guides and technical bulletins available in the
Technical Documentation Library.
 You have read through the self-service information on commonly asked support questions and known
issues and workarounds available in the Technical Knowledge Center.
- END OF DOCUMENT -


TC2875en-Ed01 SIP Trunk Deutsche-Telekom Company-Flex-with-SIPTLS ConfigurationGuideline R12.4

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TC2875en-Ed01 SIP Trunk Deutsche-Telekom Company-Flex-with-SIPTLS ConfigurationGuideline R12.4

Uploaded by

Copyright:

Available Formats

Technical Bulletin OmniPCX Enterprise

TC2875 ed.01 Release 12.4 and above

SIP Trunk Solution: Deutsche Telekom –

2 Summary of tests results ......................................................................................................................... 8

3 Tests results ......................................................................................................................................... 12

OmniPCX Enterprise - Release 12.4 and above

OmniPCX Enterprise - Release 12.4 and above

OmniPCX Enterprise - Release 12.4 and above

1.2 Scope & usage of the configuration guide

1.3 Scope of Alcatel-Lucent Enterprise’s support

1.4 Software/ Hardware components on customer's infrastructure

INFRA COMPONENT MODEL VERSION (min compatible)

OXE OmniPCX Enterprise R12.4 m5.204.2b

OTSBC (if part of Topology) Mediant SW 7.20A.204.108

For OXE Users, all tests are done with:

Following user sets have been used during validation:

OmniPCX Enterprise - Release 12.4 and above

100 IP phone Alcatel-Lucent IPTouch 8078s 10

101 IP phone Alcatel-Lucent IPTouch 8058s 10

102 IP phone Alcatel-Lucent IPTouch 8068s 10

103 Softphone IPDSP 10

199 SIP- XLITE 10

250 Analog Fax Fax HP Office Jett 4500 10

OmniPCX Enterprise - Release 12.4 and above

OmniPCX Enterprise - Release 12.4 and above

2.1 Summary of main functions supported

#112  Registration with authentication OK

Authentication on basic calls:

#122  Authentication for incoming calls NA

#123  Incorrect Authentication on outgoing calls OK Call is rejected

#141 Session Timer RFC 4028 OK Update Method

#161 Service Route and Path headers OK

BASIC VOICE CALLS

#215  Trunk released by external set OK

#221  Outgoing phase & call clearing before answer OK

#232  Outgoing call to an Incorrect Number OK

#241  Outgoing call to a User Busy OK

#251  Outgoing call from OXE anonymous set OK

#261  Outgoing long call OK

OmniPCX Enterprise - Release 12.4 and above

#331  Anonymous incoming calls OK

#341  Incoming long call OK

#421  Immediate forward to external user OK

#431  Forward on no answer to external user OK

Subscriber not available:

#521  Non-attributed OXE user number OK

#531  User busy OK

ADVANCED FEATURES FOR COMMUNICATION

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

#661  Supervised call transfer to external set OK RE-INVITE with SDP

#681  DTMF for outgoing call

OmniPCX Enterprise - Release 12.4 and above

2.3 Summary of limitations

2.4 Notes, remarks

 REGISTER, AUTHENTICATION (and Nonce Caching): Done by the OTSBC

 Outgoing calls to incorrect number: Early media announcement is played.

 External Transferred calls: RE-INVITE WITH SDP method supported

 On Hold feature: “a=sendrecv” method used

OmniPCX Enterprise - Release 12.4 and above

 FAX: G711 Only

OmniPCX Enterprise - Release 12.4 and above

There are two kinds of tests:

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

OmniPCX Enterprise - Release 12.4 and above