ETSI TS V1.1.1 ( )

Transcription

1 TS V1.1.1 ( ) TECHNICAL SPECIFICATION Satellite Earth Stations and Systems (SES); Family SL Satellite Radio Interface (Release 1); Part 4: Enhanced Services and Applications; Sub-part 1: Multiple Voice Services

2 2 TS V1.1.1 ( ) Reference DTS/SES Keywords 3GPP, GPRS, GSM, GSO, interface, MSS, radio, satellite, TDM, TDMA, UMTS 650 Route des Lucioles F Sophia Antipolis Cedex - FRANCE Tel.: Fax: Siret N NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N 7803/88 Important notice The present document can be downloaded from: The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of. In case of any existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the print of the Portable Document Format (PDF) version kept on a specific network drive within Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other documents is available at If you find errors in the present document, please send your comment to one of the following services: Copyright Notification No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of. The content of the PDF version shall not be modified without the written authorization of. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute All rights reserved. DECT TM, PLUGTESTS TM, UMTS TM and the logo are Trade Marks of registered for the benefit of its Members. 3GPP TM and LTE are Trade Marks of registered for the benefit of its Members and of the 3GPP Organizational Partners. GSM and the GSM logo are Trade Marks registered and owned by the GSM Association.

3 3 TS V1.1.1 ( ) Contents Intellectual Property Rights... 5 Foreword... 5 Modal verbs terminology... 5 Introduction Scope References Normative references Informative references Symbols and abbreviations Symbols Abbreviations General Overview System architecture Access to the VoIP domain Mobile PBX Requirements General Requirements Number of Concurrent Calls Support for Direct Inward Dialling Support for Short Code Dialling Support for Call Barring Configuration Requirements Functional Requirements Domain Selection Requirements Circuit Switched Call Handling Requirements CS Domain Supplementary Services Requirements Support for Direct Inward Dialling in the CS Domain Call Waiting in the CS Domain General CS Voice Calls Domain Independent Supplementary Services Settings Protocol Requirements General Session Management Requirements General Primary PDP Context Activation Secondary PDP Context Definition Secondary PDP Context Activation, Modification and Deactivation SIP Protocol Requirements General SIP Registration SIP Options SIP Call Setup (originating from PBX) SIP Call Setup (terminating on PBX) SIP Call Maintenance Media Handling Requirements Codec Codec Frame Packetization DTMF Handling SIP Domain Supplementary Services Requirements Calling Number Presentation on Inbound Calls Calling Number Presentation on Outbound Calls Supplementary Services Settings related to Calling Number Delivery Call Waiting and Call Hold in the SIP Domain... 15

4 4 TS V1.1.1 ( ) Annex A (normative): VoIP Domain Call Service Codes History... 17

5 5 TS V1.1.1 ( ) Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to. The information pertaining to these essential IPRs, if any, is publicly available for members and non-members, and can be found in SR : "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to in respect of standards", which is available from the Secretariat. Latest updates are available on the Web server ( Pursuant to the IPR Policy, no investigation, including IPR searches, has been carried out by. No guarantee can be given as to the existence of other IPRs not referenced in SR (or the updates on the Web server) which are, or may be, or may become, essential to the present document. Foreword This Technical Specification (TS) has been produced by Technical Committee Satellite Earth Stations and Systems (SES). The present document is part 4, sub-part 1 of a multi-part deliverable. Full details of the entire series can be found in TS [4]. Modal verbs terminology In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be interpreted as described in clause 3.2 of the Drafting Rules (Verbal forms for the expression of provisions). "must" and "must not" are NOT allowed in deliverables except when used in direct citation. Introduction This multi-part deliverable (Release 1) defines a satellite radio interface that provides UMTS services to users of mobile terminals via geostationary (GEO) satellites in the frequency range 1 518,000 MHz to 1 559,000 MHz (downlink) and 1 626,500 MHz to 1 660,500 MHz and 1 668,000 MHz to 1 675,000 MHz (uplink).

6 6 TS V1.1.1 ( ) 1 Scope The present document specifies the mandatory requirements for User Equipment (UE) implementing multiple voice communications via the Voice-over-IP (VoIP) service for the Family SL satellite radio interface. 2 References 2.1 Normative references References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the reference document (including any amendments) applies. Referenced documents which are not found to be publicly available in the expected location might be found at NOTE: While any hyperlinks included in this clause were valid at the time of publication, cannot guarantee their long term validity. The following referenced documents are necessary for the application of the present document. [1] IETF RFC 3261 (2002): "SIP: Session Initiation Protocol", J. Rosenberg. [2] IETF RFC 4733 (2006): "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", H. Schulzrinne. [3] TS : "Satellite Earth Stations and Systems (SES); Family SL Satellite Radio Interface (Release 1); Part 1: General Specifications; Sub-part 4: Applicable External Specifications, Symbols and Abbreviations". [4] TS : "Satellite Earth Stations and Systems (SES); Family SL Satellite Radio Interface (Release 1); Part 1: General Specifications; Sub-part 1: Services and Architectures". [5] TS : "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (3GPP TS )". 2.2 Informative references References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the reference document (including any amendments) applies. NOTE: While any hyperlinks included in this clause were valid at the time of publication, cannot guarantee their long term validity. The following referenced documents are not necessary for the application of the present document but they assist the user with regard to a particular subject area. Not applicable. 3 Symbols and abbreviations 3.1 Symbols For the purposes of the present document, the symbols given in TS [3], clause 3 apply. 3.2 Abbreviations For the purposes of the present document, the abbreviations given in TS [3], clause 3 apply.

7 7 TS V1.1.1 ( ) 4 General 4.1 Overview The Circuit Switched (CS) domain is designed to carry only one active voice call per subscriber identity at any time. For User Equipment (UE) that is shared among users, e.g. on ships or aircraft, it is desirable to overcome this limitation and to offer the ability to handle more than one concurrent voice call. Additional voice calls can be provided by a Voice-over-IP (VoIP) service domain using the Packet Switched (PS) domain as its transport. The general principle of operation assumes that the first preference is to use the CS domain to set up a call. Only if the CS domain is unavailable (i.e. one voice call is already in progress between the user and another party), will any additional calls be set up using the VoIP domain. The present document specifies the mandatory requirements for equipment implementing a User Agent in the VoIP service domain. This User Agent is essentially providing a Private Branch Exchange (PBX) in the mobile domain, as shown in Figure 4.1, and is therefore referred to as "Mobile PBX" throughout the present document. Figure 4.1: Equipment Configuration for support of Multiple Voice service A Mobile PBX can be implemented either as an integral part of a UE or as external hardware that can be connected to an existing UE. In general, the requirements specified in the present document apply to both implementations unless indicated otherwise. 4.2 System architecture The solution described in the present document is based upon the integration of a VoIP domain containing infrastructure operating in tandem with the Circuit Switched domain and operating via the Packet Switched Domain. A simplified representation of the overall system architecture is represented in Figure 4.2, where the VoIP domain is functionally provided by a VoIP server.

8 8 TS V1.1.1 ( ) Figure 4.2: Overall System Architecture for support of Multiple Voice service A new VoIP Domain, provided via a VoIP server, is introduced into the Family SL ground segment, and provides an interface between the existing Circuit Switched domain and the Packet Switched domain for transport of multiple voice calls when the single CS voice circuit towards a mobile terminal is busy. The interface with the PSTN is handled by the existing Circuit Switched domain for both mobile terminated and mobile originated calls. The existing voice mail system will be used to support per-msisdn voice mail. Multiple MSISDN numbers are allocated to the subscriber. These numbers may be allocated to individual handsets by configuration of the mobile terminal or the external VoIP PBX. Alternatively functionality may be provided in the mobile terminal or VoIP PBX to determine which handset to alert upon Mobile Terminated call initiation utilizing the primary MSISDN. 4.3 Access to the VoIP domain The Mobile Terminal registers with the Radio Access Network and then initiates an Attach procedure towards both the CS and PS domains. During these Attach procedures the MT is authenticated, and Security Mode procedures are initiated to secure the signalling and user-plane between the Radio Access Network and the Mobile Terminal.

9 9 TS V1.1.1 ( ) Figure 4.3: Simplified Presentation of Initial Access Procedure Conditional on successful CS and PS attach procedures, the mobile terminal initiates a background Primary PDP context towards the Inmarsat VoIP APN, which is authorized by the HLR if the subscriber is granted access to Multiple Voice services. Conditional on the Mobile Terminal subscriber being authorized to access VoIP domain infrastructure, an IP address is allocated to the mobile terminal and the PDP context activated. The Mobile Terminal then performs a DNS lookup to obtain the IP address of the SIP server within the VoIP domain (the fully qualified domain name of the SIP server will be configured in the Mobile Terminal). The Mobile Terminal then initiates a SIP registration procedure towards the SIP server. 5 Mobile PBX Requirements 5.1 General Requirements Number of Concurrent Calls The Mobile PBX shall support a minimum of four concurrent voice calls (one call placed via the CS domain and an additional three placed through the PS domain). It should support up to nine concurrent voice calls. NOTE: The maximum number of concurrent voice calls supported is determined by the subscribers' service package and is enforced by the network Support for Direct Inward Dialling Additional MSISDNs (AMISDNs) may be allocated to a UE network subscription to provide support for Direct Inward Dialling (DID) from another network to individual telephone handsets connected to the Mobile PBX. These DID numbers shall be provided to the subscriber when they request a multiple voice service package from the satellite network service provider. The Mobile PBX may optionally support telephone handsets that are not associated with a DID number. Such handsets would typically be used for outbound calls only Support for Short Code Dialling The Mobile PBX shall support Short Code Dialling in both service domains.

10 10 TS V1.1.1 ( ) Support for Call Barring The Mobile PBX should provide means to implement local barring of outgoing calls (whitelist and/or blacklist) to be applied either to individual handsets or to a group of handsets Configuration Requirements The Mobile PBX shall provide a suitable, user friendly interface for its configuration. As a minimum, the interface shall allow the user to change the following parameters through a suitable user interface: Access Point Name (APN) string [apn_name] SIP Domain Name string [sip_domain_name] It is recommended that these parameters are pre-configured by the manufacturer with default strings as advised by the satellite network service provider prior to shipping the equipment. The interface should also allow the user to manually configure the primary and any additional MSISDNs and to associate each MSISDN with a particular telephone handset. This interface shall also provide for one telephone handset to be the default handset to receive incoming calls without a DID number. 5.2 Functional Requirements Domain Selection Requirements When a call is placed from a handset connected to the Mobile PBX, and this handset has been allocated the primary MSISDN (or no MSISDN at all), then the Mobile PBX shall always check whether the CS domain can be used to place a call. Only if the CS domain is not available, then the call shall be placed via the VoIP service domain. When a call is placed from a handset connected to the Mobile PBX, and this handset has been allocated one of the additional MSISDNs, then the call shall always be placed via the VoIP service domain Circuit Switched Call Handling Requirements CS Domain Supplementary Services Requirements The Call Forward on Busy (CFB) and Call Waiting (CW) supplementary services settings for TS11 (speech) calls configured in the network shall not be modified as this may cause the multi voice service to malfunction. Preferably, if a Mobile PBX is integrated with a UE, the user shall not be able to modify CFB and CW settings. Alternatively, for an external Mobile PBX, the user manual shall carry appropriate warnings that any changes to the CFB and CW settings may cause malfunction of the Multi Voice service Support for Direct Inward Dialling in the CS Domain The Network will provide the Destination MSISDN number in the Call Control SETUP message in the "Called party BCD Number" Information Element (IEI 0x5E, see TS [5], clause , Table 9.70). The Mobile PBX shall use the Called Party BCD Number to direct the incoming call to the appropriate handset associated with the DID number. If the Called Party BCD Number IE is absent or if the Called Party BCD Number is not available to the Mobile PBX (e.g. if the Mobile PBX is implemented as an external device connected to a UE), then the handling of such calls shall be specific to the manufacturer's implementation Call Waiting in the CS Domain General The Call Waiting behaviour specified in this clause is mandatory for Mobile PBX integrated with the UE. For a Mobile PBX external to the UE, the functionality may be limited due to the circuit switched interface between the UE and the Mobile PBX, hence the requirements are desirable but not mandatory for external Mobile PBX implementations. For user equipment that does not support Call Waiting in the CS domain, the following subclauses are not applicable. In this case incoming calls will always be routed to the VoIP domain if the CS domain is busy.

11 11 TS V1.1.1 ( ) CS Voice Calls The Call Waiting behaviour shall be as follows: If the CS domain is busy in a call, then the Mobile PBX shall check the Called Party Number in the CC:Setup message and determine whether the handset associated with the Called Party Number is engaged in a call: - If the Handset is busy in the CS domain, then normal CS Call Waiting/Call Hold procedures should be invoked towards the handset, giving the user the choice of accepting or rejecting the call. - If the Handset is busy in the VoIP domain, the call shall automatically be rejected in the CS domain with Cause Code #17 "user busy". In this case the call will then be diverted to the VoIP domain and the call will be again be presented via the VoIP domain, allowing the user to accept or reject the incoming call and/or put the ongoing call on hold. - If the Handset is idle, the call shall automatically be rejected in the CS domain with Cause Code #17 "user busy". In this case the call will then be diverted to the VoIP domain and the call will again be presented via the VoIP domain, for the user to accept or reject Domain Independent Supplementary Services Settings Both the CS and SIP domain network elements (MSC, SIP Server) allow the user to configure supplementary services settings, subject to subscription, to be changed from the UE. As it cannot be determined in advance, which domain will be used to place a call, it is desirable for the same settings to be applied to both domains where applicable. The Mobile PBX shall optionally provide a feature (e.g. through the user interface) which simultaneously applies changes to supplementary services settings to both domains, such that the same feature is provided regardless of the serving domain. Supplementary Service Codes applicable in the VoIP domain are specified in Annex A: VoIP Domain Call Service Codes. 5.3 Protocol Requirements General Several protocol parameters are referenced in the following subclauses. These are shown in italics and surrounded by square brackets, e.g. [sip_domain_name]. Some parameters are explicitly configurable through a user interface (see clause 5.1.5) while others are held inside the UE and need to be retrieved as required either through internal or external interfaces, depending on whether the Mobile PBX is integrated within the UE or external to it. NOTE: An external Mobile PBX would typically obtain such parameters through AT Commands and Responses. This is outside the scope of the present document Session Management Requirements General In order to allow incoming and outgoing calls via the VoIP service domain, the Mobile PBX requires IP connectivity to the SIP Server and to the Media Gateway in the satellite network Primary PDP Context Activation On start-up, the Mobile PBX shall verify whether the UE is attached to the PS domain and if that is the case, initiate the activation of a primary background PDP context towards an APN dedicated to the provision of IP transport to the VoIP service domain. On successful activation of the PDP Context, the Mobile PBX shall retain the IP address assigned to this PDP context [contact_ip] for use in SIP signalling.

12 12 TS V1.1.1 ( ) Secondary PDP Context Definition A secondary streaming PDP context linked to the primary background PDP context referred to above, shall be defined but only activated when a call is being placed via the VoIP service domain. The Traffic Flow Template (TFT) for the secondary streaming PDP context shall be defined such that only the RTP voice stream(s) are carried on the secondary streaming PDP context. The TFT (and equivalent uplink TFT) may use UDP Port Number ranges or DiffServ Code Point (DSCP) values in the filter definition. When using UDP Port Number ranges, then it is recommended to use the destination port number range in the (downlink) TFT filter definition which covers the port number range that will be used by the Mobile PBX for RTP streams. Likewise in the uplink TFT filter definition, a source port number range should be defined with the same values. Using DSCP values in the TFT filters requires the Mobile PBX to use a distinctive DSCP value for IP packets carrying RTP streams. It is strongly recommended for the Mobile PBX to use the same DSCP value for RTP packets as the DSCP value that the Media Gateway is configured to use. If RTCP packets are sent from a Mobile PBX, then the TFT filters shall be configured such that the RTCP packets are carried over the primary (background) PDP Context in order to optimize streaming bandwidth usage. NOTE: The network side Media Gateway is configured not to send RTCP packets to the client Secondary PDP Context Activation, Modification and Deactivation The Mobile PBX shall keep track of VoIP calls being set up and cleared: When the first call is set up in the VoIP service domain, the Mobile PBX shall activate the secondary PDP context with a requested Guaranteed Bitrate as specified in clause below prior to sending a SIP Invite to the SIP server. Whenever another call is set up in the VoIP domain (up to the maximum number of concurrent calls supported by the Mobile PBX), the requested Guaranteed Bitrate shall be modified upwards to accommodate the additional RTP stream over the same secondary PDP Context prior to sending a SIP Invite to the SIP server. Whenever a call is cleared in the VoIP domain, then the Mobile PBX shall first determine whether there are any other calls ongoing in the VoIP domain. - If other calls are still ongoing, then the requested Guaranteed Bitrate shall be modified downwards such that the remaining RTP stream(s) can be carried over the secondary PDP context. - If the call being cleared is the only call in the VoIP domain, then the Mobile PBX shall request the deactivation of the secondary PDP context. If a Secondary PDP Context Activation triggered by an incoming SIP:INVITE (i.e. Mobile Terminated Call Setup) fails, then the Mobile PBX shall clear the call that is being set up by sending a SIP:CANCEL message to the SIP server. If a Secondary PDP Context Modification triggered by an incoming SIP:INVITE (i.e. Mobile Terminated Call Setup) fails, then the Mobile PBX shall clear the call that is being set up by sending a SIP:CANCEL message to the SIP server. If a Secondary PDP Context Activation or Modification triggered by a (Mobile Originated) call setup from a handset connected to the Mobile PBX, fails, then the Mobile PBX shall abandon the call setup and signal the call setup failure to the handset as appropriate for the type of handset (e.g. call failure tone or SIP Error message). A failed Secondary PDP Context Modification may be followed by an immediate Network Initiated PDP Context Deactivation. On receiving Secondary PDP Context Modification failure followed by a Network Initiated PDP Context Deactivation, the Mobile PBX should attempt to re-activate a Secondary PDP Context with a suitable Guaranteed Bitrate to carry all existing calls in the VoIP domain (i.e. reverting to the Guaranteed Bitrate operational before the failed Secondary PDP Context Modification was attempted). If this re-activation fails, the Mobile PBX shall clear all existing calls in the VoIP domain.

13 13 TS V1.1.1 ( ) SIP Protocol Requirements General The Mobile PBX shall implement a SIP User Agent as specified in SIP version 2.0 (see IETF RFC 3261 [1]). Only UDP transport shall be used for all SIP signalling. The PBX shall send all SIP signalling to the SIP server using UDP destination port 5060 but may select a different UDP to receive SIP messages. If using a port number other than 5060, the PBX shall indicate its SIP port in the parameter [port_no] as specified below, otherwise the use of this parameter is optional SIP Registration The International Mobile Subscriber Identity (IMSI) stored on the USIM within the UE shall be used as the SIP User Name [imsi]. After successful activation of the primary PDP Context, the Mobile PBX shall send a SIP:REGISTER message to the SIP Server at the IP address resolved from the SIP Domain Name string. If a valid IP address is specified instead of a SIP Domain Name string, then the IP address shall be used instead. The SIP REGISTER message shall comply with the requirements in clause 10 of IETF RFC 3261 [1], with Table 5.1 specifying those fields which require specific values to be used. Table 5.1: Field Values for SIP REGISTER Message Field Name Field Value From: <sip:[imsi]@[sip_domain_name]> To: <sip:[imsi]@[sip_domain_name]> User-Agent: The field value shall identify the manufacturer and version of the Mobile PBX Contact: <sip:[imsi]@[contact_ip]:[port_no]> Expires: SIP Options The Mobile PBX shall respond to SIP OPTIONS polling from the network SIP Call Setup (originating from PBX) To originate a SIP call from the PBX, the PBX shall send a SIP INVITE message. In addition to the requirements in clause 10 of IETF RFC 3261 [1], Table 5.2 specifies those fields which require specific values to be used. Table 5.2: Field Values for SIP:INVITE Message Field Name From: To: Field Value <sip:[calling_number]@[sip_domain_name]> or <sip:[imsi]@[sip_domain_name]> <sip:[dialled_digits]@[sip_domain_name]> No SDP Offer is required in the SIP:INVITE for Mobile PBX originated calls. The Mobile PBX shall always adhere to the SDP Answer returned by the SIP Server, in particular the ptime parameter (see clause ) shall be applied to the outbound RTP stream. The Mobile PBX shall provide Call Progress Tones towards the calling handset and convert any incoming SIP error messages to appropriate call failure tones (or optionally, voice announcements) SIP Call Setup (terminating on PBX) Incoming SIP INVITEs will carry either the primary or an additional MS-ISDN as the called number in the SIP:To header in the format: <sip:[called_number]@[sip_domain_name]>

14 14 TS V1.1.1 ( ) where the [called_number] is presented in National Number Format, i.e. without the satellite network provider's country code. If individual DID numbers are allocated to specific handsets connected to the Mobile PBX then the incoming call shall be routed to that handset accordingly otherwise the call shall be routed in accordance with the appropriate user configuration. Incoming SIP:INVITEs will always carry an SDP offer, the Mobile PBX shall accept the first codec in the list as well as the ptime parameter specified. The Mobile PBX is not required to provide audible ringback tones towards the caller SIP Call Maintenance The network may send reinvite at regular intervals on every call to check that the SIP User Agent is still contactable and to check that the call is active in order to ensure accurate billing. The network fails the call if the Mobile PBX SIP User Agent does not reply or replies negatively. The Mobile PBX shall respond positively to the re-invite if and only if there is already an active call matching that specified in the re-invite Media Handling Requirements Codec The Mobile PBX shall support G.729 or G.729A and may optionally support variant G.729B Codec Frame Packetization The Mobile PBX shall support sending multiple codec frames in a single RTP packet as determined from the SDP ptime attribute sent by the network to the Mobile PBX in the SIP:INVITE, SIP:183 Session Progress and SIP:200 OK messages. The following ptime values shall be supported: 20 (default), 40, and 80 ms. The Mobile PBX shall determine the required Guaranteed Uplink and Downlink Bitrates for the secondary Streaming PDP Context from the ptime attribute as follows: for ptime = 20 ms: 26 kbit/s for ptime = 40 ms: 18 kbit/s for ptime = 80 ms: 12 kbit/s For mobile terminated calls, the Mobile PBX shall obtain the requested ptime value from the incoming SIP INVITE message to select the appropriate Bitrate for the subsequent Secondary PDP Context Activation or Modification. For mobile originated calls, the Mobile PBX shall assume that the last ptime value provided by the SIP server will also apply to the call which is in the process of being set up, to select the appropriate Bitrate for the Secondary PDP Context Activation. The Mobile PBX shall store the last ptime received from the SIP server in non-volatile memory such that the value is retained during a reset/reboot or power cycling of the mobile PBX DTMF Handling DTMF Tones to and from the Mobile PBX shall be carried over RTP as telephone-events in accordance with IETF RFC 4733 [2] SIP Domain Supplementary Services Requirements Calling Number Presentation on Inbound Calls For Inbound calls the Calling Number is carried in the SIP:From header in the following format: <sip:[calling_number]@[sip_domain_name]> The Calling number on Inbound Calls is normally presented in International Format with a leading "+" or "00". If the caller has withheld their number or if the number is not available for other reasons, then the [calling_number] parameter will contain the word "anonymous". The Mobile PBX should present the Calling Line ID to the handset to which the call is directed (if the handset supports Calling Line ID).

15 15 TS V1.1.1 ( ) Calling Number Presentation on Outbound Calls For Outbound calls the Calling Number is carried in the SIP:From header in the format: If Calling Number Presentation on Outbound Calls is selected by the user then the Mobile PBX shall set the [calling_number] parameter in the SIP:From Header. If individual DID numbers are allocated to the handset connected to the Mobile PBX and it is intended to present the DID number of the handset as the Calling Number, then the corresponding individual number in National Number Format shall be used in the [calling_number] parameter, i.e. without the satellite network provider's country code. If the calling number is not configured in the Mobile PBX, no DID number is allocated to the handset placing the call, or if it is not intended to present the DID number allocated to the handset, then the Mobile PBX shall use the following format: Supplementary Services Settings related to Calling Number Delivery The Mobile PBX shall optionally allow the user to block or unblock Calling Number Delivery for the entire PBX. Annex A: VoIP Domain Call Service Codes provides a list of applicable codes used for this purpose in the SIP domain Call Waiting and Call Hold in the SIP Domain Call Waiting and Call Hold is not supported by the Multi-Voice SIP server in the network. However, a Mobile PBX may support these features locally towards connected handsets.

16 16 TS V1.1.1 ( ) Annex A (normative): VoIP Domain Call Service Codes Call Service Code Confirmation Busy Call Forwarding - enable *90 <number to forward to> Tone Busy Call Forwarding - disable *91 n/a Calling Number Delivery - enable *65 n/a Calling Number Delivery - disable *85 n/a Calling Number Delivery Blocking - single call *67 <called number> n/a Calling Number Delivery Blocking - override *82 <called number> n/a

17 17 TS V1.1.1 ( ) History Document history V1.1.1 October 2015 Publication