![PXM IMS Corporate Voip – UNI Specification – General [1]](http://data.docslib.org/img/a306954bceb85d20b3d462c883e8702f-1.webp)
This specification describes the situation of the Proximus network and services. It will be subject to modifications for corrections or when the network or the services will be modified. Please take into account that modifications can appear at any moment. Therefore, the reader is requested to check regularly with the most recent list of available specifications that the document in one's possession is the latest version.
Proximus can't be held responsible for any damages due to the use of an outdated version of this specification.
Whilst every care has been taken in the preparation and publication of this document, errors in content, typographical or otherwise, may occur. If you have remarks concerning its accuracy, please send a mail to the following address [email protected] and your remark will be transmitted to the right Proximus department.
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 1 of 39
Sensitivity: Confidential
IMS CORPORATE VoIP SIP SIGNALING
Wireless Office Extended
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 2 of 39
Sensitivity: Confidential
TABLE OF CONTENTS
0. Document History ...... 5
1. Scope...... 6
2. References ...... 7
2.1. Normative references ...... 7 2.2. Informative references ...... 8
3. Symbols, Definitions and Abbreviations...... 9
3.1. Symbols ...... 9 3.2. Definitions ...... 9 3.3. Abbreviations ...... 10
4. General ...... 11
4.1. Structure of the document ...... 11 4.2. Reference point ...... 11
5. SIP Profile ...... 12
5.1. Introduction ...... 12 5.2. 3GPP standards...... 12 5.3. ETSI TISPAN standards ...... 12 5.4. IETF RFCs ...... 12 5.4.1. Supported methods ...... 13 5.4.2. Supported responses ...... 14 5.4.3. Supported headers ...... 15 5.4.4. Unsupported headers ...... 16 5.4.5. Supported bodies ...... 16 5.4.6. Timer values...... 16 5.4.7. Transport protocol ...... 17 5.4.8. Handling of the Retry-After header ...... 17
6. SIP Behaviour ...... 18
6.1. Introduction ...... 18
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 3 of 39
Sensitivity: Confidential
6.2. Registration/Authentication ...... 18 6.3. Basic call ...... 18 6.3.1. Public off-net originating call set-up ...... 20 6.3.2. Public off-net terminating call set-up ...... 26 6.3.3. Forward call tear down ...... 30 6.3.4. Backward call tear down ...... 31 6.4. Supplementary services ...... 32 6.4.1. Calling Line Identity Presentation (CLIP) ...... 32 6.4.1.1. Incoming call to the IP-P(A)BX...... 32
6.4.1.2. Outgoing call from the IP-P(A)BX ...... 34
6.4.2. Calling Line Identity presentation Restriction (CLIR) ...... 36 6.4.2.1. Incoming call to the IP-P(A)BX...... 36
6.4.2.2. Outgoing call from the IP-P(A)BX ...... 36
6.4.3. Call Forwarding Services ...... 37 6.4.4. Outgoing Call Barring ...... 37 6.4.5. Call Hold ...... 37 6.4.6. Conference call...... 37 6.4.7. Call transfer ...... 37 6.5. CLI screening...... 38 6.6. FAX support ...... 38 6.7. Emergency calls ...... 38 6.8. DTMF ...... 38 6.9. Codec changes during a call/session ...... 39
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 4 of 39
Sensitivity: Confidential
0. Document History
Every update of this document results in a complete new version with new version number and release date.
Version Date Main or important changes since previous version
1.0 February 15, 2011 First version
1.1 February 16, 2011 Corrections regarding emergency call number formats
Addition emphasizing the importance to use a domain in the Request- 1.2 March 02, 2011 URI (rather than an IP address)
1.3 May 16, 2011 Corrections to the cover sheet
References added for support of multipart message bodies 1.4 June 29, 2011 Updates regarding P-Asserted-ID handling
1.5 December 20; 2011 Domain replaced by IP-address of IP-PBX for call towards IP-PBX
1.6 March 26, 2012 Addition regarding proprietary SIP headers
Additional info on Retry-After header 1.7 March 08, 2013 Guidelines for sending re-INVITE
1.8 Januari 13, 2016 Changed “Belgacom” in “Proximus”
1.9 September 05, 2016 Made support of both DTMF transport methods mandatory
Update due to name change “Bizz IP telephony multi” into “Enterprise 1.10 November 24, 2016 voice multi”
Clarification concerning the initial value of the Max-Forwards header 1.11 June 28, 2018 The use of Diversion header added.
Correction: mobile.ims.belgacom.be changed in woe.proximus.be
2.0 May 25, 2019 Document name changed from BGC to PXM
2.1 June 06, 2019 Small update based on comments from IP-PBX team
2.2 September 19, 2019 Update of SW versions in Scope
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 5 of 39
Sensitivity: Confidential
2.3 November 20, 2020 Update concerning the use of the Privacy header
Table 1: document history
1. Scope
This document defines the SIP signalling over the VoIP interface between the Proximus IMS Network and large IP-P(A)BXs, connected as SIP Wireless Office Trunk. The specifications listed in this document are not exhaustive but have to be interpreted as “minimal requirements for compliance to the Proximus IMS Corporate VoIP services”. The specifications are applicable for the following IMS equipment and software packages: Alcatel-Lucent ISC - software package Release 13 Oracle SBC 4600 – Software Version SCZ8.1.0 MR-1 patch 12 Broadsoft application server – BroadWorks R22
This document is part of a set of documents describing the UNI interface of the Proximus IMS Network, for IP-P(A)BXs. Other documents in this set are: PXM IMS Corporate VoIP – UNI specification – General [1]
PXM IMS Corporate VoIP – UNI specification – SIP signalling – Business Trunking with IMS services [2]
PXM IMS Corporate VoIP – UNI specification – SIP signalling – Enterprise Voice Multi [3]
PXM IMS Corporate VoIP – UNI specification – Testing
PXM IMS VoIP – UNI specification – Fax support [36]
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 6 of 39
Sensitivity: Confidential
2. References
Whenever a date of edition is mentioned, the document with this date should be consulted. If no date is present, the latest version of this document should be consulted.
2.1. Normative references
1 Proximus PXM IMS Corporate VoIP – UNI specification – General
2 Proximus PXM IMS Corporate VoIP – UNI specification – SIP signalling – Business Trunking with IMS services
3 Proximus PXM IMS Corporate VoIP – UNI specification – SIP signalling – Enterprise Voice Multi
4 3GPP TS 24.229 IP Multimedia call control protocol based on SIP and SDP, Stage 3 Release 9
5 3GPP TS 23.167 IP Multimedia Subsystem (IMS) emergency sessions, Release 9
6 SIP forum The SIP connect 1.1 technical recommendation (draft)
7 ETSI TS 182 025 Business Trunking; architecture and functional description v2.1.1
8 ITU-T E.164 The international telecommunication numbering plan
9 IETF RFC 3261 SIP: Session Initiation Protocol
10 IETF RFC 3262 Reliability of Provisional Responses in the Session Initiation Protocol (SIP)
11 IETF RFC 3264 An Offer/Answer Model with the Session Description Protocol (SDP)
12 IETF RFC 3265 Session Initiation Protocol (SIP)-Specific Event Notification
13 IETF RFC 4566 SDP: Session Description Protocol
14 IETF RFC 2976 The SIP INFO Method
15 IETF RFC 3311 The Session Initiation Protocol (SIP) UPDATE Method
16 IETF RFC 3323 A Privacy Mechanism for the Session Initiation Protocol (SIP)
17 IETF RFC 3325 Private Extensions to SIP for Asserted Identity within Trusted Networks
18 IETF RFC 3326 The Reason Header Field for the Session Initiation Protocol (SIP)
19 IETF RFC 3455 Private header extensions for SIP for 3GPP
20 IETF RFC 3515 The Session Initiation Protocol (SIP) REFER Method
21 IETF RFC 3891 The Session Initiation Protocol (SIP) "Replaces" Header
22 IETF RFC 3892 The Session Initiation Protocol (SIP) Referred-By Mechanism
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 7 of 39
Sensitivity: Confidential
23 IETF RFC 3960 Early Media and Ringing Tone Generation in SIP
24 IETF RFC 4028 Session Timers in the Session Initiation Protocol (SIP)
25 IETF RFC 2617 HTTP Authentication: Basic and Digest Access Authentication
26 IETF RFC 1321 The MD5 Message-Digest Algorithm
27 IETF RFC 3550 RTP: A Transport Protocol for Real-Time Applications
28 IETF RFC 3551 RTP Profile for Audio and Video Conferences with Minimal Control
29 IETF RFC 4733 RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals
30 IETF RFC 4734 Definition of Events for Modem, FAX and Text Telephony signals
31 IETF RFC 5806 Diversion indication in SIP
32 IETF RFC 6044 Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in the Session Initiation Protocol (SIP)
33 IETF RFC 4244 An Extension to SIP for Request History Information
34 IETF RFC 3966 The Tel URI for Telephone Numbers
35 IETF draft Applying Loose Routing to Session Initiation Protocol (SIP) User Agents (UA)” (expired)
36 Proximus PXM IMS VoIP – UNI specification – Fax support
37 IETF RFC 5621 Message body handling in SIP
38 IETF RFC 5876 Updates to Asserted Identity in the Session Initiation Protocol (SIP)
Table 2: normative references
2.2. Informative references
Table 3: informative references
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 8 of 39
Sensitivity: Confidential
3. Symbols, Definitions and Abbreviations
3.1. Symbols
For the purpose of the present document, the following symbols apply: None.
3.2. Definitions
For the purpose of the present document, the following definitions apply: IP-P(A)BX: The IP P(A)BX constitutes an Enterprise’s collection of network elements that provides packetized voice call origination and termination services using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP) for signalling and the Real-time Transport Protocol (RTP) for media traffic.
pbxPUID: The public user identity referring to the IP P(A)BX as a whole. The pbxPUID will/can be used as host part of the SIP URI used by the IP-P(A)BX.
PBXName: The same as pbxPUID.
Dialled-SubB-dn: destination number as dialled by the originating user. The format can be:
• +32
Note: Emergency call (i.e 1AB) and shortcode calls (i.e. 1ABC) are not accepted on a wireless office trunk.
Norm-SubB-dn: destination E.164 number in international format (i.e. +
Norm-SubA-dn: originating E.164 number in international format (i.e. +
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 9 of 39
Sensitivity: Confidential
DisplayName: the name of the user.
EnterpriseDomain: the public domain name used by the enterprise. Currently the default domain name is ims.belgacom.be. The possibility for the IP-P(A)BX to use, in the future, as public domain name it’s own domain name e.g. mycompany.com is under study.
Note: EnterpriseDomain can also be an IPaddress instead of a domain name.
IP-addr-PBXName: the IP address of the PBX with name PBXName.
IP-addr-IMS: the IP address of the Proximus IMS network access point (i.e. the SBC).
1AB: called emergency service e.g. 100,112, etc.
1ABC: called short code service
3.3. Abbreviations
See §2.2 of “PXM IMS Corporate VoIP – UNI specification – General” [1] Additionally for the purpose of the present document, the following abbreviations apply: CLIP Calling Line Identification Presentation
CLIR Calling Line Identification Presentation Restriction
CFU Call Forwarding Unconditional
CFB Call Forwarding on Busy
CFNR Call Forwarding on No Reply
DN Directory Number
DTMF Dual Tone Multi-Frequency iDN Individual directory number i.e. a particular DN within the range of the IP-P(A)BX
OCB Outgoing Call Barring
MobNSN Mobile national significant number
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 10 of 39
Sensitivity: Confidential
4. General
4.1. Structure of the document
The general structure of this document mainly covers the following aspects: • SIP profile: this chapter will contain the list of RFCs and standards to which the Proximus IMS network complies, relevant for IP-P(A)BX interconnection. • SIP behaviour: besides the protocol support also the expected behaviour is important. E.g. how do supplementary services behave. Main topics to be covered in this chapter: o Registration/authentication o Basic Call o Supplementary services o CLI screening o Fax support o Emergency calls o DTMF
4.2. Reference point
See §4.3.1 of [1] : “PXM IMS Corporate VoIP – UNI specification – General”.
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 11 of 39
Sensitivity: Confidential
5. SIP Profile
5.1. Introduction
The following clauses list the SIP related 3GPP and ETSI standards and IETF RFCs to which the IP- P(A)BX shall be compliant.
5.2. 3GPP standards
The Proximus IMS network implements and supports SIP protocol in accordance with: • TS 24.229 IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP), stage 3 Release 7 [4] • TS 23.167 IP multimedia subsystem (IMS) emergency sessions, Release 7 [5] Although this is a registration configuration, emergency registrations are not applicable.
5.3. ETSI TISPAN standards
The Proximus IMS network implements and supports SIP protocol in accordance with: • TS 182 025 Business Trunking; architecture and functional description”, v2.1.1 (2008-09) [7]
5.4. IETF RFCs
The Proximus IMS network implements and supports SIP/SDP protocol in accordance with: • RFC 3261 SIP: session initiation protocol [9] • RFC 3262 Reliability of provisional responses in SIP [10] • RFC 3264 an offer/answer model with SDP [11] • RFC 3265 SIP-specific event notification [12] Only the NOTIFY method is supported, the SUBSCRIBE method and the 489 “bad event” response are not supported.
Because the NOTIFY method is a rather generic method usable in many different functions (e.g. message waiting indication) it can not be guaranteed that the behaviour will be correct for every possible functionality using the NOTIFY method.
• RFC 4566 SDP: session description protocol [13] • RFC 2976 SIP INFO method [14]
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 12 of 39
Sensitivity: Confidential
Because the INFO method is a rather generic method usable in many different functions it can not be guaranteed that the behaviour will be correct for every possible functionality using the INFO method. For example DTMF transport in the INFO method doesn’t work properly. Therefore it is mandatory to support the mechanisms for DTMF transport listed in § 6.9
• RFC 3311 SIP UPDATE Method [15] • RFC 3323 A Privacy Mechanism for the Session Initiation Protocol (SIP) [16] • RFC 3325 Private Extensions to SIP for Asserted Identity within Trusted Networks [17] • RFC 3326 SIP reason header [18] • RFC 3455 3GPP P-headers [19] • RFC 3515 SIP REFER Method [20] • RFC 3891 The Session Initiation Protocol (SIP) "Replaces" Header [21] • RFC 3892 The Session Initiation Protocol (SIP) Referred-By Mechanism [22] • RFC 3960 Early Media and Ringing Tone Generation in SIP [23] • RFC 4028 Session Timers in the SIP [24] • RFC 2617 HTTP Authentication: Basic and Digest Access Authentication [25] • RFC 1321 The MD5 Message-Digest Algorithm [26] • RFC 3550 RTP: A Transport Protocol for Real-Time Applications [27] • RFC 3551 RTP Profile for Audio and Video Conferences with Minimal Control [28] • RFC 4733 RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals [29] • RFC 4734 Definition of Events for Modem, FAX and Text Telephony signals [30] • RFC 5806 Diversion indication in SIP [31] • RFC 6044 Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in the Session Initiation Protocol (SIP) [32] • RFC 4244 An Extension to SIP for Request History Information [33] • RFC 3966 The Tel URI for Telephone Numbers [34] • Draft Applying Loose Routing to Session Initiation Protocol (SIP) User Agents (UA)” (expired) [35] • RFC 5621 Message Body Handling in SIP [37] Since more and more SIP applications use multipart message bodies, the correct support and handling of multipart message bodies is very important.
• RFC 5876 Updates to Asserted Identity in the Session Initiation Protocol (SIP) [38]
5.4.1. Supported methods
The following methods shall be supported on the Wireless Office Extended interface: • INVITE according to [4] and [9] • ACK according to [4] and [9] • BYE according to [4] and [9] • CANCEL according to [4] and [9] • REGISTER according to [4] and [9] • OPTIONS according to [4] and [9] • PRACK according to [4] and [10] • NOTIFY according to [4] and [12] • REFER according to [4] and [20] • UPDATE according to [4] and [15] • INFO according to [4] and [14]
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 13 of 39
Sensitivity: Confidential
5.4.2. Supported responses
The following responses shall be supported on the Wireless Office Extended interface: Provisional responses (1xx) • 100 Trying according to [4] and [9] • 180 Ringing according to [4] and [9] • 181 Call Is Being Forwarded according to [4] and [9] • 182 Queued according to [4] and [9] • 183 Session Progress according to [4] and [9]
Successful responses (2xx): • 200 OK according to [4] and [9] • 202 Accepted according to [4] and [12]
Redirection responses (3xx): • 302 Moved Temporarily according to [4] and [9]
Request Failure responses (4xx): • 400 Bad Request according to [4] and [9] • 401 Unauthorized according to [4] and [9] • 402 Payment Required according to [4] and [9] • 403 Forbidden according to [4] and [9] • 404 Not Found according to [4] and [9] • 405 Method Not Allowed according to [4] and [9] • 406 Not Acceptable according to [4] and [9] • 407 Proxy Authentication Required according to [4] and [9] • 408 Request Timeout according to [4] and [9] • 410 Gone according to [4] and [9] • 413 Request Entity Too Large according to [4] and [9] • 414 Request-URI Too Long according to [4] and [9] • 415 Unsupported Media Type according to [4] and [9] • 416 Unsupported URI Scheme according to [4] and [9] • 420 Bad Extension according to [4] and [9] • 421 Extension Required according to [4] and [9] • 423 Interval Too Brief according to [4] and [9] • 480 Temporarily Unavailable according to [4] and [9] • 481 Call/Transaction Does Not Exist according to [4] and [9] • 482 Loop Detected according to [4] and [9] • 483 Too Many Hops according to [4] and [9] • 484 Address Incomplete according to [4] and [9] • 485 Ambiguous according to [4] and [9] • 486 Busy Here according to [4] and [9] • 487 Request Terminated according to [4] and [9] • 488 Not Acceptable Here according to [4] and [9] • 491 Request Pending according to [4] and [9] • 493 Undecipherable according to [4] and [9]
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 14 of 39
Sensitivity: Confidential
Server Failure responses (5xx): • 500 Server Internal Error according to [4] and [9] • 501 Not Implemented according to [4] and [9] • 502 Bad Gateway according to [4] and [9] • 503 Service Unavailable according to [4] and [9] • 504 Server Time-out according to [4] and [9] • 505 Version Not Supported according to [4] and [9] • 513 Message Too Large according to [4] and [9]
Global Failures responses (6xx): • 600 Busy Everywhere according to [4] and [9] • 603 Decline according to [4] and [9] • 604 Does Not Exist Anywhere according to [4] and [9] • 606 Not Acceptable according to [4] and [9]
5.4.3. Supported headers
The following headers shall be supported on the Wireless Office Extended interface: • Via according to [4] and [9] • To according to [4] and [9] • From according to [4] and [9] • CSeq according to [4] and [9] • Call-Id according to [4] and [9] • Contact according to [4] and [9] • Max-Forwards according to [4] and [9] As recommended in RFC 3261 [9] clause 20.22 the IP-PBX shall use as initial value of the Max- Forwards header the value 70. • Route according to [4] and [9] • Record-Route according to [4] and [9] • Content-Type according to [4] and [9] • Content-Disposition according to [4] and [9] • Content-Length according to [4] and [9] • MIME-Version according to [4] and [9] • Supported according to [4] and [9] • Require according to [4] and [9] • Expires according to [4] and [9] • Unsupported according to [4] and [9] • Allow according to [4] and [9] • Retry-After according to [4] and [9] • In-Reply-To according to [4] and [9] • Authorization according to [4] and [9] • Proxy-Authenticate according to [4] and [9] • WWW-Authenticate according to [4] and [9] • Min-Expires according to [4] and [9] • Proxy-Authorization according to [4] and [9] • Alert-Info according to [4] and [9] • Warning according to [4] and [9]
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 15 of 39
Sensitivity: Confidential
• Accept according to [4] and [9] • Call-Info according to [4] and [9] • RSeq according to [4] and [10] • RAck according to [4] and [10] • Allow-Events according to [4] and [12] • Event according to [4] and [12] • Subscription-State according to [4] and [12] • Refer-To according to [4] and [20] • Privacy according to [4] and [16] • P-Asserted-Identity according to [4] and [17] • Reason according to [4] and [18] • P-Called-Party-ID according to [4] and [19] • P-Access-Network-Info according to [4] and [19] • P-Associated-URI according to [4] and [19] • Replaces according to [4] and [21] • Referred-By according to [4] and [22] • Session Expires according to [4] and [24] • Min-Se according to [4] and [24]
5.4.4. Unsupported headers
Proprietary SIP headers (i.e. headers starting with “X-“ or “x-“) are never supported and shall not be sent on the interface.
5.4.5. Supported bodies
Multipart message bodies are supported and used in the Proximus IMS network. Therefore message body handling according to RFC 5321 [37] is mandatory. In any case correct support and usage of SIP response 415 “Unsupported Media type” as specified in RFC 3261 [9] is mandatory.
5.4.6. Timer values
The Proximus IMS network supports the timers described in [4] and [9] with the following (default) settings: • T1 = 500 msec • T2 = 4 seconds • T4 = 5 seconds • Timer D = 32 seconds • Timer H = 32 seconds
All other timers are derived from these, according to [4] and [9].
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 16 of 39
Sensitivity: Confidential
5.4.7. Transport protocol
The Proximus IMS network supports SIP over UDP only. Important remark: In case SIP message length approaches the MTU size, [4] and [9] specify that UDP transport should be replaced by TCP transport. This shall NOT be applied by the IP-P(A)BX.
5.4.8. Handling of the Retry-After header
In some cases the IP-PABX may receive a final (error) response containing a Retry-after header. A typical example is a 500 “Internal server error” with Retry-after header with a value of X seconds. A typical value of X would be 1.
The IP-PABX shall correctly handle the Retry-after header according to IETF RFC 3261 [9] and 3GPP TS 24.229 [4] and hence not send new traffic during the interval indicated in the Retry-after header.
In some cases of failure the IP-PABX might send a final (error) response containing a Retry-after header. A typical example is a 500 “Internal server error” with Retry-after header with a value of X seconds. In this case the Proximus IMS network (i.e. the SBC) applies the normal handling of the Retry-After header and consider the SIP link with the IP-PABX as out-of-service for the duration of the Retry-After header.
Warning: The SBC will not sent/receive any traffic over the SIP link during this out-of-service period causing a temporary total outage !
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 17 of 39
Sensitivity: Confidential
6. SIP Behaviour
6.1. Introduction
Besides the standards and RFCs describing the protocol supported, also the expected behaviour is important. E.g. how does registration exactly take place, which information is expected in the “From” header, etc.
IMPORTANT:
SIP signalling serves the call set-up/teardown of calls/sessions as well as the description of session parameters (through the use of SDP) and the invocation of features and services. This means that the exchange of SIP signalling between an IP-PBX and the Proximus network shall serve one of the above purposes. In other words, SIP signalling shall be meaningful and the sending of useless SIP messages shall to be avoided !
Example of useless SIP signalling: A re-INVITE in an established session without any SDP included is often useless because typically re-INVITE is used to re-negociate/change the session parameters. So, if there is no need to re- negociate/change the session parameters no re-INVITE should be transmitted.
6.2. Registration/Authentication
IP-P(A)BX devices connected to the Proximus IMS network by use of Wireless Office Extended shall not use registration. The identification and authentication of the IP-P(A)BX is done by making use of the one- to-one mapping of fixed IP-addresses. This is done through configuration in the Session Border Controller (SBC) of the Proximus IMS network. Internal in the corporate network SIP end devices e.g. SIP phones, may register with the IP-P(A)BX itself. These registrations with the IP P(A)BX shall remain invisible to the Proximus IMS network. Each IP-P(A)BX will be assigned one PBX public user identity (pbxPUID), aka Pilot ID aka PBXName. This is a non-dialable public identity. An IP-P(A)BX has usually allocated to it one or more contiguous DN ranges. Authentication procedures will not be requested for INVITE (session authentication).
6.3. Basic call
In Wireless Office extended several call types are possible: • Private on-net calls are completely treated by the IP-P(A)BX and hence out of scope of this document.
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 18 of 39
Sensitivity: Confidential
• Public off-net calls are transited by the Proximus IMS network. This is a call between an IP- P(A)BX extension and a mobile IP-P(A)BX extension or a normal external (mobile) user.
Basic call set-up and tear down complies with normal SIP behaviour as described in the relevant Standards and RFCs [4][9][10][11][13]. Basic call set-up in the SIP Wireless Office extended case happens without authentication. Since fixed IP addresses are used the Proximus IMS network identifies and authorizes the IP-P(A)BX based on the IP address. Basic call set-up may use the mechanism for reliable transport of 1XX responses according to IETF RFC 3262 “Reliability of Provisional Responses in the Session Initiation Protocol (SIP)” [10], but it is not mandatory. The procedures for announcing the capability and use are described in [10]. Basic call set-up may use the mechanism for session timer according to IETF RFC 4028 “Session Timers in the Session Initiation Protocol (SIP)” [24], but it is not mandatory. The procedures for announcing the capability and use are described in [24]. The IP-P(A)BX shall use the following Request-URI to originate a call: • Request-URI: o sip:[email protected];user=phone Note: using an IP address instead of a domain in the host part of the URI will result in call failure. The IP-P(A)BX shall use the following own identity to originate a call: • From header: o sip: Norm-SubA-dn@EnterpriseDomain;user=phone
The From header shall always contain a valid PUID, even when the CLIR service is to be invoked.
• Contact header o sip:Norm-SubA-dn@IP-addr-PBXName, or o sip:PBXName@IP-addr-PBXName
The IP address of the IP-P(A)BX in the Contact header MUST be the same as used in the configuration of the Proximus SBC because the Proximus IMS network uses this for admission control.
• P-Asserted-ID header: o sip:Norm-SubA-dn@EnterpriseDomain;user=phone
According to SIP Connect 1.1 [6], it is recommended that the IP-P(A)BX includes a P-Asserted-ID header in the INVITE request. The Proximus IMS network does not expect to receive this header and if received this header will be overwritten by the Proximus IMS network with the correct P-Asserted- ID. Note: as “Norm-SubA-dn” any DN within the range of the IP-P(A)BX can be used.
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 19 of 39
Sensitivity: Confidential
6.3.1. Public off-net originating call set-up
Figure 1 shows the expected message flow for a public on-net originating call set-up. Note: depending on the call scenario (e.g. whether reliability of provisional responses is used or not) differences may occur.
Figure 1 : Basic call/session set-up example public on-net
To set-up a public off-net call the IP-P(A)BX sends an INVITE message to the Proximus IMS network with the following headers: • Request-URI = sip:[email protected];user=phone • To =
Note: The DisplayName in the From, Contact and P-Asserted-id header is optional Live example
Request-Line: INVITE sip:[email protected];user=phone SIP/2.0 Message Header Route:
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 20 of 39
Sensitivity: Confidential
From: "TEL 027979380"
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 21 of 39
Sensitivity: Confidential
Media Format: 106 [telephone-event] Media format specific parameters: 0-15 Media Attribute (a): fmtp:4 annexa=no Media Attribute Fieldname: fmtp Media Format: 4 [telephone-event] Media format specific parameters: annexa=no Media Attribute (a): maxptime:90 Media Attribute Fieldname: maxptime Media Attribute Value: 90 Media Attribute (a): silenceSupp:off - - - - Media Attribute Fieldname: silenceSupp Media Attribute Value: off - - - -
The INVITE contains SDP information regarding the proposed call parameters (e.g. codec, IP address and port number on which the IP-P(A)BX user wants to receive RTP). The Proximus IMS network first returns a 100 Trying response. When the destination is reached a 180 Ringing response is returned to the IP-P(A)BX. Remark: Because the initial INVITE sent by the IP-P(A)BX announced support for 100rel in the Supported header, the Proximus IMS network agrees to apply this mechanism. The 180 Ringing response contains SDP information regarding the accepted call parameters and the following headers: • Require = 100rel • Rseq =
Live example
Status-Line: SIP/2.0 100 Trying Message Header To:
Status-Line: SIP/2.0 180 Ringing Message Header To:
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 22 of 39
Sensitivity: Confidential
Contact:
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 23 of 39
Sensitivity: Confidential
The IP-P(A)BX shall send a PRACK request to the Proximus IMS network in order to acknowledge the receipt of the 180 response.
The PRACK request contains the following headers: • Rack =
Live example
Request-Line: PRACK sip:[email protected];user=phone SIP/2.0 Message Header Route:
The Proximus IMS network shall send a 200 OK response to the IP-P(A)BX in order to finalize the PRACK transaction. Live example
Status-Line: SIP/2.0 200 OK Message Header To:
When the call is answered the Proximus IMS network returns a 200 OK response for the INVITE transaction.
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 24 of 39
Sensitivity: Confidential
Remark: Because the initial INVITE sent by the IP-P(A)BX announced support for session timer in the Supported header and Session-Expires header, the Proximus IMS network reacts with a Session –Expires header granting the proposed expiration time and indicating that the user agent server (i.e. the Proximus IMS network) will be responsible to refresh the session. Live example
Status-Line: SIP/2.0 200 OK Message Header To:
The IP-P(A)BX sends an ACK message to the Proximus IMS network in order to properly close the INVITE transaction. Live example
Request-Line: ACK sip:10.127.249.190:5060;transport=udp SIP/2.0 Message Header Route:
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 25 of 39
Sensitivity: Confidential
6.3.2. Public off-net terminating call set-up
Figure 2 shows the expected message flow for a public off-net originating call set-up. Note: depending on the call scenario (e.g. whether reliability of provisional responses is used or not) differences may occur.
Figure 2: Basic call/session set-up example public off-net
To set-up a call to the IP-P(A)BX, the Proximus IMS network sends an INVITE message to the IP-P(A)BX with the following headers: • Request-URI = sip:Norm-SubB-dn@IP-addr-PBXName;user=phone • To =
• Via = IP-addr-IMS • Contact =
Note: The DisplayName in the From, Contact and P-asserted-id header is optional Remark: Any incoming basic call to an IP-P(A)BX may have undergone diversion before it reaches the IP- P(A)BX. Therefore a diverting number can be present in the INVITE message in the Diversion header (the Diversion Top header contains the Redirecting Number, while the Diversion Bottom header contains the Original Called Number). The Diversion header has been documented in IETF RFC 5806 Diversion indication in SIP [31]. The INVITE contains SDP information regarding the proposed call parameters (e.g. codec, IP address and port number on which the Proximus IMS network wants to receive RTP).
Live example
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 26 of 39
Sensitivity: Confidential
Request-Line: INVITE sip:[email protected]:5060;user=phone SIP/2.0 Message Header Via: SIP/2.0/UDP 10.127.249.190:5060;branch=z9hG4bKkqotd0nduhrdr90k3nauqe15l4 Call-ID: [email protected] To:
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 27 of 39
Sensitivity: Confidential
Media Attribute (a): rtpmap:101 TELEPHONE-EVENT/8000 Media Attribute Fieldname: rtpmap Media Format: 101 MIME Type: TELEPHONE-EVENT Media Attribute (a): ptime:20 Media Attribute Fieldname: ptime Media Attribute Value: 20 Media Attribute (a): maxptime:30 Media Attribute Fieldname: maxptime Media Attribute Value: 30
The Proximus IMS network expects a 100 Trying response, followed by a 180 Ringing, when the destination user is reached.
Live example
Status-Line: SIP/2.0 100 Trying Message Header To:
Status-Line: SIP/2.0 180 Ringing Message Header Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, PRACK, REFER, NOTIFY, UPDATE Contact: "TEL 027979380"
When the call is answered the Proximus IMS network expects a 200 OK response containing SDP information regarding the accepted call parameters (e.g. codec, IP address and port number on which the destination wants to receive RTP).
Live example
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 28 of 39
Sensitivity: Confidential
Status-Line: SIP/2.0 200 OK Message Header Content-Type: application/sdp Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, PRACK, REFER, NOTIFY, UPDATE Contact: "TEL 027979380"
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 29 of 39
Sensitivity: Confidential
Media Format: 101 [telephone-event] Media format specific parameters: 0-15 Media Attribute (a): silenceSupp:off - - - - Media Attribute Fieldname: silenceSupp Media Attribute Value: off - - - - Media Attribute (a): ptime:20 Media Attribute Fieldname: ptime Media Attribute Value: 20 Media Attribute (a): maxptime:30 Media Attribute Fieldname: maxptime Media Attribute Value: 30
The Proximus IMS network sends an ACK message to the IP-P(A)BX in order to properly close the INVITE transaction.
Live example
Request-Line: ACK sip:[email protected];user=phone SIP/2.0 Message Header Via: SIP/2.0/UDP 10.127.249.190:5060; branch=z9hG4bKb7ekt8dekqmq15u0eedlcc7oe1-g0g5 P-Charging-Vector: icid-value=S9C80-20101222152015-00000909; icid-generated-at=149.204.0.1; orig-ioi=sub.alcatel-ngnvoice.com CSeq: 1 ACK To:
6.3.3. Forward call tear down
Message flow example
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 30 of 39
Sensitivity: Confidential
Figure 6 : Basic call/session teardown example
To end a public off-net call the IP-P(A)BX sends a BYE message to the Proximus IMS network. • CallID = matches the CallID of the concerned call • Cseq = is incremented with regard to the previous transaction related to this call
Live example
Request-Line: BYE sip:10.127.249.190:5060;transport=udp SIP/2.0 Message Header Route:
The Proximus IMS network returns a 200 OK response. Live example
Status-Line: SIP/2.0 200 OK Message Header To:
6.3.4. Backward call tear down
Message flow example
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 31 of 39
Sensitivity: Confidential
Figure 7 : Basic call/session teardown example
To end a public on-net or a public off-net call the Proximus IMS network sends a BYE message to the IP- P(A)BX. • CallID = matches the CallID of the concerned call • Cseq = is incremented with regard to the previous transaction related to this call
6.4. Supplementary services
All supplementary services shall be executed at -and managed by- the IP-P(A)BX. The Proximus IMS network serves as transit network towards the mobile network only. No services are offered nor executed in the Proximus IMS network.
However, some services executed by the IP-P(A)BX involving external users may need particular interaction with the Proximus IMS network. The expected behaviour is discussed in the following clauses.
6.4.1. Calling Line Identity Presentation (CLIP)
6.4.1.1. Incoming call to the IP-P(A)BX
The CLIP service sends the identity of the calling line to the IP-P(A)BX. The calling line identity can be provided by the network or it can include identity information supplied by the caller and validated by the network. The calling line identity can be contained in the From and P-Asserted-Id headers in the INVITE message sent to the IP-P(A)BX. The presentation information of the calling line identity, which establishes the identity type (Presentation Allowed or Presentation Restricted) is contained in the Privacy header in the INVITE message. The format of the calling line identity information in the From and P-Asserted-Id headers in the INVITE message is:
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 32 of 39
Sensitivity: Confidential
• From = DisplayName sip:[email protected];user=phone or DisplayName tel:Norm-SubA-dn
• P-asserted-id = DisplayName
Note 1: The DisplayName in the From header and P-Asserted-ID header is optional Note 2: The Norm-SubA-dn in the From header and P-Asserted-ID header is not necessarily the same. For example in case of interworking with legacy ISDN two calling line identities may be delivered. The Privacy header in the INVITE message has the value “none”. The absence of the Privacy header equally means “no privacy”. Live example
Request-Line: INVITE sip:[email protected]:5060;user=phone SIP/2.0 Message Header Via: SIP/2.0/UDP 10.127.249.190:5060;branch=z9hG4bKkqotd0nduhrdr90k3nauqe15l4 Call-ID: [email protected] To:
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 33 of 39
Sensitivity: Confidential
Owner Address Type: IP4 Owner Address: 10.127.249.190 Session Name (s): SDP Data Connection Information (c): IN IP4 10.127.249.190 Connection Network Type: IN Connection Address Type: IP4 Connection Address: 10.127.249.190 Time Description, active time (t): 0 0 Session Start Time: 0 Session Stop Time: 0 Media Description, name and address (m): audio 10002 RTP/AVP 8 18 101 Media Type: audio Media Port: 10002 Media Proto: RTP/AVP Media Format: ITU-T G.711 PCMA Media Format: ITU-T G.729 Media Format: 101 Media Attribute (a): rtpmap:101 TELEPHONE-EVENT/8000 Media Attribute Fieldname: rtpmap Media Format: 101 MIME Type: TELEPHONE-EVENT Media Attribute (a): ptime:20 Media Attribute Fieldname: ptime Media Attribute Value: 20 Media Attribute (a): maxptime:30 Media Attribute Fieldname: maxptime Media Attribute Value: 30
6.4.1.2. Outgoing call from the IP-P(A)BX
The calling line identity shall be contained in the From and P-Asserted-Id headers in the INVITE message sent by the IP-P(A)BX.
• From = DisplayName
Note: The DisplayName in the From and P-Asserted-Id header is optional Live example
Request-Line: INVITE sip:[email protected];user=phone SIP/2.0 Message Header Route:
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 34 of 39
Sensitivity: Confidential
Session-Expires: 43200 P-Asserted-Identity: "027979380"
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 35 of 39
Sensitivity: Confidential
Media Format: 106 MIME Type: telephone-event Media Attribute (a): fmtp:106 0-15 Media Attribute Fieldname: fmtp Media Format: 106 [telephone-event] Media format specific parameters: 0-15 Media Attribute (a): fmtp:4 annexa=no Media Attribute Fieldname: fmtp Media Format: 4 [telephone-event] Media format specific parameters: annexa=no Media Attribute (a): maxptime:90 Media Attribute Fieldname: maxptime Media Attribute Value: 90 Media Attribute (a): silenceSupp:off - - - - Media Attribute Fieldname: silenceSupp Media Attribute Value: off - - - -
Note: According to SIP Connect 1.1 [6], it is recommended that the IP-P(A)BX includes a P-Asserted-ID header in the INVITE request. The Proximus IMS network does not expect to receive this header but the call will not fail if received.
6.4.2. Calling Line Identity presentation Restriction (CLIR)
6.4.2.1. Incoming call to the IP-P(A)BX
In case the CLIR service has been invoked by the calling user of an incoming call to the IP-P(A)BX, the From header in the INVITE will not contain the identity information of the calling user and the P- Asserted-Id header will not be present in the INVITE. The presentation information of the calling line identity, which establishes the identity type (Presentation Allowed or Presentation Restricted) is contained in the Privacy header in the INVITE message. • From = DisplayName
Note: if present DisplayName will have the value “Anonymous”.
6.4.2.2. Outgoing call from the IP-P(A)BX
In order to prevent the presentation of the calling user’s identity (invoke CLIR) the IP-P(A)BX can include a Privacy header in the INVITE. The value of the Privacy header in the INVITE shall be id and/or header and/or User. In any case the From header shall always contain a valid URI (not anonymous), even when the CLIR service is to be invoked.
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 36 of 39
Sensitivity: Confidential
6.4.3. Call Forwarding Services
The call forwarding feature(s) shall be managed and handled by the IP-P(A)BX. The following behaviour is valid for all flavours (e.g. unconditional (CFU), on busy (CFB), on no reply (CFNR), …) of call forwarding executed by the IP-P(A)BX. In case an incoming call to the IP-P(A)BX is forwarded to a destination external to the IP-P(A)BX, the IP- P(A)BX shall create the forwarding by setting-up a new (forwarded) call. The incoming call and the outgoing (forwarded) call are considered being 2 separate calls. A Diversion header may be included in the outgoing (forwarded) call in which case the calling line identity possibly shown to the forwarded-to destination will be the original calling line identity, else the calling line identity possibly shown to the forwarded-to destination will be the identity of the forwarding IP-P(A)BX user (or the IP-P(A)BX general number). The History-info header MUST NOT be included in the outgoing (forwarded) call. Remark: The IP-P(A)BX shall not use a 302 Moved Temporarily response.
6.4.4. Outgoing Call Barring
The OCB service is not offered to the IP-P(A)BX. No network Outgoing Call Barring can be programmed for the complete IP-P(A)BX and/or for each iDN. In case the IP-P(A)BX applies Outgoing Call Barring to one of his users, the call shall not be sent to the Proximus IMS network.
6.4.5. Call Hold
The call hold feature shall be managed and handled by the IP-P(A)BX. An IP-P(A)BX user may place an active call on hold and may retrieve a held call. The IP-P(A)BX shall provide “music on hold” or play an announcement for the held user. For these purposes, the Proximus IMS supports the use of re-INVITE transactions to modify the media description parameters for a call according to the held/retrieved state. An IP-P(A)BX user involved in an active call may be placed on hold and may be retrieved. Depending on the holding user (external to the IP-P(A)BX) either the Proximus IMS or the holding user’s equipment is responsible to provide “music on hold” or to play an announcement for the held IP-P(A)BX user. For these purposes, the Proximus IMS supports the use of re-INVITE transactions to modify the media description parameters for a call according to the held/retrieved state.
6.4.6. Conference call
The conference feature shall be managed and handled by the IP-P(A)BX. In case external users are involved in a conference call, the incoming and/or outgoing calls to/from the IP-P(A)BX will be treated like normal basic calls by the Proximus IMS.
6.4.7. Call transfer
The call transfer feature shall be managed and handled by the IP-P(A)BX.
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 37 of 39
Sensitivity: Confidential
The following behaviour is valid for all flavours (e.g. with or without consultation) of call transfer executed by the IP-P(A)BX. In case a call involving an IP-P(A)BX user is transferred (by that IP-P(A)BX user) to a destination external to the IP-P(A)BX, the IP-P(A)BX shall set-up a new call to the transferred-to destination, and: o either use a re-INVITE to transfer the RTP stream of the original call to the new destination. No Diversion header nor History-info header shall be included in the outgoing call. The calling line identity possibly shown to the transferred-to destination will be the identity of the forwarding IP-P(A)BX user (or the IP-P(A)BX general number). o or not use a re-INVITE and handle the transfer of the RTP streams autonomously.
The IP-P(A)BX shall not use a REFER message to redirect the call to the transferred-to-number.
6.5. CLI screening
The Proximus IMS network will not verify the identity of the calling user received from the IP-P(A)BX in the From header and P-asserted-ID.
6.6. FAX support
See “PXM IMS VoIP – UNI specification – Fax over IP” [36]
6.7. Emergency calls
Emergency calls will not be accepted by the Proximus IMS network on a wireless office trunk. The IP- P(A)BX shall route all emergency calls over the Business Trunk with IMS services (aka fixed Business Trunk).
6.8. DTMF
For transport of DTMF the following capabilities exist:
• Usage of RFC 2833 (inband signalling in RTP by use of events) • Usage of G.711 codec (inband signalling in RTP)
Both methods of transporting DTMF shall be supported.
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 38 of 39
Sensitivity: Confidential
Evolution: Usage of the SIP INFO message (outband signalling: the info follows the path of signalling) is currently under study and may be announced in a later version of this document
6.9. Codec changes during a call/session
Codec changes during an established call/session are allowed using the re-INVITE mechanism. However it should be noted that sending a re-INVITE to the Proximus IMS network very fastly after the establishment of the call/session may result in an error response with Retry-after header.
Therefore it is advised to not sent a re-INVITE faster then 50 mseconds after the ACK request finalising the previous INVITE transaction.
Proximus PLC under Belgian Public Law, Bd. du Roi Albert II 27, B-1030 Brussels, Belgium VAT BE 0202.239.951, Brussels Register of Legal Entities, Giro BE50 0001 7100 3118 BPOTBEB1 Page 39 of 39
Sensitivity: Confidential