HGI-RD026 IP-PBX MODULE REQUIREMENTS

HGI-RD026 IP-PBX MODULE REQUIREMENTS May, 2014 P a g e 1

1 CONTENTS 2 Important notices, IPR statement, disclaimers and copyright... 4 2.1 About HGI... 4 2.2 This may not be the latest version of This HGI Document... 4 2.3 There is no warranty provided with This HGI Document... 4 2.4 Exclusion of Liability... 4 2.5 This HGI Document is not binding on HGI nor its member companies... 4 2.6 Intellectual Property Rights... 5 2.7 Copyright Provisions... 5 2.7.1 Incorporating HGI Documents in whole or part within Documents Related to Commercial Tenders 5 2.7.2 Copying This HGI Document in its entirety... 5 2.8 HGI Membership... 6 3 Acronyms... 7 4 Introduction... 9 4.1 Scope And Purpose... 9 4.2 Definitions Of Terms... 9 5 Definitions... 10 6 IP-PBX Overview... 11 7 IP-PBX configuration... 13 8 Baseline IP-PBX Module Requirements... 16 8.1 Registration and management... 16 8.2 Call control features... 16 8.3 Miscellaneous features... 18 8.4 PBX Management... 19 8.5 SIP phone configurations... 19 8.6 Voice Related Storage... 19 9 High-end IP-PBX Module Requirements... 20 9.1 Registration and management... 20 P a g e 2

9.2 Call control features... 20 9.3 Miscellaneous features... 22 9.4 SIP phone configuration... 22 9.5 Voice Related Storage... 23 10 References... 24 11 APPENDIX 1... 25 11.1 IP Centrex... 25 P a g e 3

2 IMPORTANT NOTICES, IPR STATEMENT, DISCLAIMERS AND COPYRIGHT This chapter contains important information about HGI and this document (hereinafter This HGI Document ). 2.1 ABOUT HGI The Home Gateway Initiative (HGI) is a non-profit making organization which publishes guidelines, requirements documents, white papers, vision papers, test plans and other documents concerning broadband equipment and services which are deployed in the home. 2.2 THIS MAY NOT BE THE LATEST VERSION OF THIS HGI DOCUMENT This HGI Document is the output of the Working Groups of the HGI and its members as of the date of publication. Readers of This HGI Document should be aware that it can be revised, edited or have its status changed according to the HGI working procedures. 2.3 THERE IS NO WARRANTY PROVIDED WITH THIS HGI DOCUMENT The services, the content and the information in this HGI Document are provided on an "as is" basis. HGI, to the fullest extent permitted by law, disclaims all warranties, whether express, implied, statutory or otherwise, including but not limited to the implied warranties of merchantability, non-infringement of third parties rights and fitness for a particular purpose. HGI, its affiliates and licensors make no representations or warranties about the accuracy, completeness, security or timeliness of the content or information provided in the HGI Document. No information obtained via the HGI Document shall create any warranty not expressly stated by HGI in these terms and conditions. 2.4 EXCLUSION OF LIABILITY Any person holding a copyright in This HGI Document, or any portion thereof, disclaims to the fullest extent permitted by law (a) any liability (including direct, indirect, special, or consequential damages under any legal theory) arising from or related to the use of or reliance upon This HGI Document; and (b) any obligation to update or correct this technical report. 2.5 THIS HGI DOCUMENT IS NOT BINDING ON HGI NOR ITS MEMBER COMPANIES This HGI Document, though formally approved by the HGI member companies, is not binding in any way upon the HGI members. P a g e 4

2.6 INTELLECTUAL PROPERTY RIGHTS Patents essential or potentially essential to the implementation of features described in This HGI Document may have been declared in conformance to the HGI IPR Policy and Statutes (available at the HGI website www.homegateway.org). 2.7 COPYRIGHT PROVISIONS 2013 HGI. This HGI Document is copyrighted by HGI, and all rights are reserved. The contents of This HGI Document are protected by the copyrights of HGI or the copyrights of third parties that are used by agreement. Trademarks and copyrights mentioned in This HGI Document are the property of their respective owners. The content of This HGI Document may only be reproduced, distributed, modified, framed, cached, adapted or linked to, or made available in any form by any photographic, electronic, digital, mechanical, photostat, microfilm, xerography or other means, or incorporated into or used in any information storage and retrieval system, electronic or mechanical, with the prior written permission of HGI or the applicable third party copyright owner. Such written permission is not however required under the conditions specified in Section 2.7.1 and Section 2.7.2 : 2.7.1 INCORPORATING HGI DOCUMENTS IN WHOLE OR PART WITHIN DOCUMENTS RELATED TO COMMERCIAL TENDERS Any or all section(s) of HGI Documents may be incorporated into Commercial Tenders (RFP, RFT, RFQ, ITT, etc.) by HGI and non-hgi members under the following conditions: (a) The HGI Requirements numbers, where applicable, must not be changed from those within the HGI Documents. (b) A prominent acknowledgement of the HGI must be provided within the Commercial document identifying any and all HGI Documents referenced, and giving the web address of the HGI. (c) The Commercial Tender must identify which of its section(s) include material taken from HGI Documents and must identify each HGI Document used, and the relevant HGI Section Numbers. (d) The Commercial Tender must refer to the copyright provisions of HGI Documents and must state that the sections taken from HGI Documents are subject to copyright by HGI and/or applicable third parties. 2.7.2 COPYING THIS HGI DOCUMENT IN ITS ENTIRETY This HGI Document may be electronically copied, reproduced, distributed, linked to, or made available in any form by any photographic, electronic, digital, mechanical, photostat, microfilm, xerography or other means, or incorporated into or used in any information storage and retrieval system, electronic or mechanical, but only in its original, unaltered PDF format, and with its original HGI title and file name unaltered. It may not be modified without the advanced written permission of the HGI. P a g e 5

2.8 HGI MEMBERSHIP The HGI membership list as of the date of the formal review of this document is: Actility, Advanced Digital Broadcast, Arcadyan, Arm, Bouygues Telecom, British Sky Broadcasting Ltd., Broadcom, BT, Celeno, Cisco, Deutsche Telekom, Devolo, Dialog Semiconductor, DSP Group, eflow, EnOcean Alliance, Fastweb SpA, France Telecom, Hitachi, Huawei, Ikanos, Imagination Technologies, Intel, KPN, LAN, Lantiq, LG Electronics, Makewave, Marvell Semiconductor, Mindspeed, MStar, NEC Corporation, Netgear, NTT, Oki Electric Industory, Portugal Telecom, ProSyst, Qualcomm Atheros, Rockethome, Sagemcom, Sercomm Corp., Sigma, SoftAtHome, Stollmann, Sumitomo, Technicolor, Telecom Italia, Telekom Austria, TeliaSonera, Telstra, TNO, Zarlink, ZTE. P a g e 6

3 ACRONYMS B2BUA Back to Back User Agent CAT-iq Cordless Advanced Technology internet and quality CDR CE CFB CFNR CFU CLIP CLIR CSTA CTI DDI DECT DHCP DISA FXO FXS HG HGI HTTP Call Data Record Consumer Electronics Call Forwarding on mobile customer Busy Call Forwarding on No Reply Call Forwarding Unconditional Calling Line Identification Presentation Calling Line Identification Restriction Computer-Supported Telephony Application Computer Telephony Integration Direct Dial-In Digital Enhanced Cordless Telecommunications Dynamic Host Configuration Protocol Direct Inward System Access Foreign exchange Office Foreign exchange Subscriber Home Gateway Home Gateway Initiative HyperText Transfer Protocol HTTPS HyperText Transfer Protocol Secure IMS IP IP Multimedia Subsystem Internet Protocol P a g e 7

IVR LAN Interactive Voice Response Local Area Network LM Remote UI Local Management Remote User Interface MAC MWI PBX PIN POS PSTN RM RMS SIP Media Access Control Message Waiting Indicator Private Branch exchange Personal Identification Number Point-of-Sale Public Switched Telephone Network Remote Management Remote Management System Session Initiation Protocol SOHO Small Office Small Business Office SP SRTP TFTP TLS UA URI URL VoIP WAN Service Provider Secure Real-time Transport Protocol Trivial File Transfer Protocol Transport Layer Security User Agent Uniform Resource Identifier Uniform Resource Locator Voice over IP Wide Area Network P a g e 8

4 INTRODUCTION 4.1 SCOPE AND PURPOSE To date the HGI has focused on the needs of the mass residential market, but it is well known that HGs are already used by some small businesses. However that market does have some additional requirements, particularly with regard to supporting multi-line voice. This document provides a set of requirements that add multiline IP-PBX capability to a Gateway. This is done by defining an IP-PBX module; this module could be implemented in a Home Gateway, or in a Gateway specifically designed and solely intended for the business market, in which case it could be termed a Small Business Gateway. There is additional functionality that would be required to specify a Small Business Gateway in its entirety (for example a backup WAN interface, more LAN ports etc.) and this may be the subject of future work by the HGI. However this approach is in line with the HGI decision to adopt a more modular approach to its specifications, which is expected to broaden their applicability and use. This document covers requirements for the case where the IP-PBX is embedded in the Gateway itself. Another approach to providing multiline voice is to use a network based PBX the so-call IP Centrex architecture. This is also described for completeness. 4.2 DEFINITIONS OF TERMS The definitions of MUST and SHOULD in this document are as follows: MUST A functional requirement which is based on a clear consensus among HGI Service Provider members, and is the base level of required functionality for a given class of equipment. MUST NOT This function is prohibited by the specification. SHOULD Functionality which goes beyond the base requirements for a given class of HG, and can be used to provide vendor product differentiation (within that class). Note: These definitions are specific to the HGI and should not be confused with the same or similar terms used by other bodies. P a g e 9

5 DEFINITIONS IP-PBX: a private branch exchange (i.e. a telephone switching system within an enterprise) that switches calls between VoIP users on local lines while allowing all users to share a certain number of external phone lines. The typical IP PBX can also switch calls between a VoIP user and a traditional telephone user, or between two traditional telephone users in the same way that a conventional PBX does. LM Remote UI (Local Management User Interface): UI (typically, but not limited to, Web-based) to let a user manage the RM client on the gateway from a device on the local network Remote Management System (RMS): the management entity which includes the Auto-Configuration Server capabilities and provides additional management functionalities. The RMS includes resource and device inventory, event notification and alarm management, diagnostics and troubleshooting. Unmanaged Device: device that does not have a remote management client or does not communicate directly or indirectly (via the IP-PBX Module) with an RMS. P a g e 10

6 IP-PBX OVERVIEW Even when used in a small-business context, there will typically be no more than 2 analogue voice ports on a Gateway; these are to support legacy phones, and devices such as fax machines and point of sale (POS) terminals. Additional handsets are provided either via a built-in DECT CAT-iq base station or SIP VoIP phones. For the SOHO market, most service providers offer an enhanced voice service including more voice lines which are provided either by a traditional Centrex, IP Centrex or an embedded IP-PBX. In a traditional Centrex architecture all phones have a dedicated connection to a PBX located in the network, and all calls, including local ones, are routed via the WAN and this PBX this includes both media and signalling. This means that the access has to have sufficient capacity for all the attached phones, even when they are only making local calls. IP Centrex uses an IP-based PBX which is again in the service-provider s network, but while all the signalling goes via this device, the media streams of local calls are routed by the Gateway using normal IP forwarding, and do not enter the service-provider s network. In an embedded IP-based PBX architecture, the signalling is also processed by the Gateway, which hosts the IP-PBX software. In this case, calls between two endpoints located in the LAN of the small business never involve the service provider s network in any way. The technical requirements in this document only concern the Gateway-embedded IP-based PBX architecture. In Appendix 1, the IP Centrex architecture is laid out for information purposes only. As shown in Figure 1, the SIP phones will have to register and signal to the IP-PBX in the Gateway, it can provide a local SIP interface enabling a retail model to apply for CE SIP devices. In this model the IP-PBX does not need to support advanced functions such as billing, and functions such as call forwarding do not to be very sophisticated. P a g e 11

Figure 1 - IP-PBX Functionality P a g e 12

7 IP-PBX CONFIGURATION In IP-PBX mode, SIP phones on the LAN register with the IP-PBX Module. Likewise, the FXS phones register with the IP-PBX Module via the B2BUA. SIP phones typically support multiple registrations corresponding to different line selection buttons on the phone, whereas an FXS phone/b2bua combination can be viewed as a SIP phone having just a single registration. This mode can be viewed rather like a traditional analog PBX - the service provider needs only to supply to the IP-PBX Module a number of: "external accounts, which are often called distinct numbers trunks which are the links used by the IP-PBX Module to reach the SP The on-board PBX registers these trunks against the SP and allocates external accounts to the SIP phones and FXS phones as lines in a many-to-many mapping. This allocation of accounts and the internal call dial plans can both be configured via the LM Remote UI or via TR-069 [1]. Figure 2 - Embedded IP PBX In the embedded IP PBX architecture (Figure 2): the SP provides a number of technical accounts (IP trunks) P a g e 13

the SP provides a number of external accounts (these can be thought of as distinct numbers). IP-PBX Module connects these accounts to a set of SIP and FXS phones IP-PBX Module registers external accounts with SP (e.g. not phones) but phones register only with IP-PBX Module IP-PBX Module maps external accounts onto phones (and onto line buttons on phones) (see Figure 3) IP-PBX Module provides statistics and may support phone configuration IP-PBX Module routes SIP calls (local call routing), SIP signalling is not send to the remote SIP server for local calls. IP-PBX Module provides a number of call features such as call on hold Figure 3 - Sample mapping of external accounts to phone lines Manually configuring an IP phone using its keypad or LM RemoteUI is difficult and so does not fit well with SOHO ease-of-use requirements, and it can be a barrier to deployment of IP telephony. Many IP phones now have the ability to download a configuration file from a remote server to automatically set up all their configuration details. To ensure that the IP-PBX Module can be deployed by a wide range of service providers, it is desirable that the IP-PBX Module supports the following service provider infrastructure use-cases: 1. The service provider has their own configuration server on the Internet which holds configurations for each phone. This requires the service provider to know in advance the unique identifiers (e.g. MAC addresses) of each of the customer's phones. The configuration files would typically have been generated in advance by the service provider's softswitch. P a g e 14

2. The service provider does not have their own configuration server on the Internet, instead they rely on the IP-PBX Module to act as the configuration server. This divides into two cases: a) The service provider knows in advance the unique identifiers of each of the customer's phones and supplies a configuration for each phone to IP-PBX Module via TR-069 [1]. b) The service provider doesn't know the unique phone identifier and instead supplies template configurations for the supported models of phone. IP-PBX Module converts these into configurations on-the-fly when phones are connected. 3. The service provider does not use the phone's auto-configuration mechanisms. This also divides into two cases: a) The SP has preconfigured all the customer's phones prior to distribution. b) The user must manually configure the phones using the keypads or built-in LM Remote UIs. Note that all of these use cases can apply to both IP Centrex and IP PBX modes of operation (although configuration by template is perhaps unlikely in IP Centrex mode). P a g e 15

8 BASELINE IP-PBX MODULE REQUIREMENTS 8.1 REGISTRATION AND MANAGEMENT IPBX1. IPBX2. IPBX3. IPBX4. IPBX5. IPBX6. IPBX7. IPBX8. The IP-PBX Module MUST support at least 4 registered accounts (registration against SP, these accounts are sometime called trunk accounts) The IP-PBX Module MUST support at least 24 external accounts (sometime called distinct numbers) available over the registered accounts The service provider MUST be able to configure the maximum number of external accounts in the IP-PBX Module. Each external account MUST be able to be active at the same time (bandwidth permitting). Any internal SIP UA (FXS/DECT) MUST be able to register with the IP-PBX. The IP-PBX Module MUST support at least two outbound calls for each SIP account. The IP-PBX Module MUST support connection to a backup trunk like PSTN or another SIP server on the WAN side in case the primary server fails. The IP-PBX Module MUST support a local web based management interface. IPBX9. The IP-PBX Module MUST support remote management of the IP-PBX using TR-069 [1] and MUST support management with TR104 [2]. 8.2 CALL CONTROL FEATURES IPBX10. The IP-PBX Module MUST support Call on Hold as defined in IETF RFC 3264 1. IPBX11. IPBX12. IPBX13. The IP-PBX Module MUST support Call Swap (alternate between active call & hold call). The IP-PBX Module MUST be able to generate music on hold when a local SIP UA goes on hold. The IP-PBX Module MUST be able to store the music and support its management and upload by the customer. P a g e 16

IPBX14. IPBX15. IPBX16. IPBX17. IPBX18. IPBX19. IPBX20. The IP-PBX Module MUST support the following Call transfer methods for Inbound calls as defined in IETF RFC 5589 Error! Reference source not found.: blind transfer i.e. during an established call the user can pass on the call without notifying the recipient. consultative transfer i.e. during an established call the user can pass on the call after notifying the recipient. The transferer places the transferee on hold, establishes a call with the transfer target to alert them to the impending transfer, terminates the connection with the transfer target, then proceeds with the transfer. The IP-PBX Module MUST support Call Forwarding Unconditional (CFU), i.e. the IP-PBX redirects calls which are addressed to the served IP-PBX line to another phone number. The IP-PBX Module MUST support the following Call forwarding methods for Inbound calls: Do not disturb i.e. forward all calls to voice mail. Call Forwarding Busy (CFB). The IP-PBX redirects call attempts made to a served IP-PBX line when that line is busy. Call Forwarding No Reply (CFNR). The IP-PBX redirects call attempts made to a served IP-PBX line which are not answered within a defined period of time. Call Forwarding Disconnected. The IP-PBX redirects call attempts made to a disconnected phone. The IP-PBX Module MUST support Scheduled forwarding for inbound calls i.e. call forwarding is turned on or off according to the time of day. For example, the user can automatically forward inbound calls to his mobile phone during the night. The IP-PBX Module MUST support Line Hunting (sometimes called Call forking), where an Inbound call causes several extensions to ring according to a defined policy. This policy MUST be configurable by the end-user and the SP. Example policies are simultaneous (all phones on the incoming number ring at once), sequential (phones ring in turn), most idle phone rings first. The IP-PBX Module MUST support Call Pick up as defined in IETF RFC 3891 4, e.g. allow a user to answer someone else s telephone call on their phone. The IP-PBX Module MUST support Call parking for Inbound calls. During the call, the user can press a specific sequence of keys and the call is placed in a call queue. Another user can then press another sequence of keys to retrieve calls from the call parking queue to his phone. P a g e 17

IPBX21. IPBX22. IPBX23. IPBX24. The IP-PBX Module MUST support Follow me service for Inbound calls. This MUST allow the end-user to define a list of numbers to be called sequentially for a phone number (including external numbers). Once the entire list has been called and no connection made, the IP PBX routes the call to voice mail. The IP-PBX Module MUST support Call back on busy for outbound calls. The IP-PBX Module MUST support Ringback tone. Here the IP-PBX plays a different tone instead of the classical "ring-ring" during the call setup. The IP-PBX Module MUST support management of the tone by the customer. The IP-PBX Module MUST support storing the ringback tone in ITU-T G.729 [6] codec format. The IP-PBX Module MUST NOT route local calls (i.e. calls between internal numbers) via the WAN link. 8.3 MISCELLANEOUS FEATURES IPBX25. IPBX26. IPBX27. The IP-PBX Module MUST support Internal number dialing, e.g. a user can make an internal call using only an extension number. The IP-PBX Module MUST support CLIP/CLIR (Calling Line Identification/Restriction). The IP-PBX Module MUST support the Message waiting and Message Waiting Indicator (MWI) functionality as defined in IETF RFC 3842 7. The MWI is usually indicated by the terminal (phone): when a voice message has arrived, the IP PBX sends a MWI to the terminal. P a g e 18

8.4 PBX MANAGEMENT IPBX28. IPBX29. IPBX30. The IP-PBX Module MUST support a local Web based management interface (LM Remote UI). The IP-PBX Module MUST support remote management. The IP-PBX Module MUST support Call logs (received calls, outgoing calls, missed calls) per user, SIP UA. 8.5 SIP PHONE CONFIGURATIONS IPBX31. The IP-PBX Module MUST support DHCP option 66 (URL to TFTP server in IP-PBX) [8] to supply configuration server details to SIP phones connected in the LAN. IPBX32. The IP-PBX Module MUST be able to be configured for DHCP option 66 [8]. IPBX33. IP-PBX Module MUST support phones which are locally configured by the end user (unmanaged phones). 8.6 VOICE RELATED STORAGE IPBX34. The IP-PBX Module MUST support integrated audio storage to provide Media-on-Hold, e.g. music and/or voice. P a g e 19

9 HIGH-END IP-PBX MODULE REQUIREMENTS For high end IP-PBX modules, the following requirements apply in addition to the requirements listed in Section 7. 9.1 REGISTRATION AND MANAGEMENT IPBX35. IPBX36. IPBX37. The IP-PBX Module MUST support access permission lists for phones. These MUST be configurable by the SP and specify which phones (or makes of phone) can be registered with the IP PBX. The IP-PBX Module MUST support Call Data Records per SIP account. The Call Data Records MUST include received calls, outgoing calls, missed calls, call length and MUST cover at least 20 entries per user. The CDR MUST be able to be displayed on the Web interface (LM Remote UI) of the PBX ("call history" page) that a local administrator or local user can see. IPBX38. The IP-PBX Module MUST support trunking operations as defined by ETSI TR 183 069 [9]. 9.2 CALL CONTROL FEATURES IPBX39. IPBX40. IPBX41. IPBX42. The IP-PBX Module MUST support a ITU-T G.729 [6] codec for music on hold. The IP-PBX Module MUST support an internal phone directory. The directory can be personal and/or shared between PBX users. The directory MUST store at least short number, external number, mail, first name, and last name (example : 200, +33123456789, user.name@isp.com, User Name). The IP-PBX Module MUST support HTTP [10] to send phone directories (personal and/or shared) to phones. The IP-PBX Module MUST support an IVR (Automated Attendant). The IVR MUST be able to be customized via the Web interface (LM Remote UI) of the PBX, by building a scenario based on at least the following actions: authentication PIN code, wait, answer, play message, voice Menu, listen for KeyPress, dial extension, access to the group directory, check voicemail, hangup, access to DISA. P a g e 20

IPBX43. IPBX44. IPBX45. IPBX46. IPBX47. IPBX48. IPBX49. IPBX50. The IP-PBX Module MUST support DISA (Direct Inward System Access). A remote user calls the IVR or a DDI number and gains access to the IP-PBX as if he was actually on an extension. The IP-PBX Module MUST support mechanisms to secure DISA (Direct Inward System Access), in order to control which external users can call into the IPBX and dial out as if they were using an extension. The IP-PBX Module MUST provide a CTI (Computer telephony integration) CSTA interface. The CTI CSTA interface can be used to develop enriched applications for the IP-PBX functions, e.g. PC widgets to manage a call, click-to-dial from Outlook, etc. The CSTA interface MUST support at least one of the following standards: ECMA TR/87 - Using CSTA for SIP Phone User Agents (uacsta) [11]. ECMA-323 4th edition - XML Protocol for Computer Supported Telecommunications Applications (CSTA) Phase III [12]. The CSTA interface MUST support at least the following methods : MAKE CALL CLEAR CONNECTION MONITORING CALL TRANSFER CALL HOLD CALL PARKING CALL LOG VOICE MAIL The IP-PBX Module MUST support mechanisms to secure CSTA. The IP-PBX Module MUST support customizable phone softkeys. The IP-PBX Module MUST support call profiles for phones. Profiles MUST be configurable by the local administrator. Profiles are default configuration templates used by the local administrator to create a new line on the PBX with the Web interface (LM Remote UI). For example, a template allows or denies services (e.g. call transfer, voice mail), phone numbers (e.g. blacklist) or call types. Another example profile could prevent a user from making any international calls. The IP-PBX Module MUST support SIP-TLS [13] on both the LAN and WAN side. P a g e 21

IPBX51. The IP-PBX Module MUST support SRTP [14] on the LAN side. 9.3 MISCELLANEOUS FEATURES IPBX52. IPBX53. IPBX54. The IP-PBX Module MUST support Internal Voice Mail, e.g. an automated answering machine embedded in the module, which plays and records voice messages. The Voice Mail capacity MUST be at least 10 minutes per user, plus 1 hour shared between all users. The IP-PBX Module MUST support sending missed call alerts to email, including time of call and call id. The IP-PBX Module MUST support sending the voice message attached to an email alert. Each message successfully sent could be removed from the IP-PBX memory. 9.4 SIP PHONE CONFIGURATION IPBX55. The IP-PBX Module MUST support configuration of phones via MAC address identification. IPBX56. The IP-PBX Module MUST support storing configuration files via TR-069 [1]. IPBX57. IPBX58. The IP-PBX Module MUST support pass-through configuration of external SIP phones via TR-069 appendix F [1]. The IP-PBX Module MUST support TFTP [15] or HTTP [10] or HTTPS [16] to configure the SIP phones (passthrough). IPBX59. The IP-PBX Module MUST support storing configuration templates via TR-069 [1]. Configuration templates will have placeholders for some of the configuration information (such as display name/number, hostname or IP address of Proxy, phone URI, username/password etc.). These MUST be filled in locally by the IP-PBX Module. P a g e 22

9.5 VOICE RELATED STORAGE IPBX60. IPBX61. IPBX62. The IP-PBX Module MUST support Integrated Voice Mail per user managed by the IP- PBX. The IP-PBX Module MUST support Voice-mail-to-email (send voice mail as attachment to e-mail, central storage) per user, SIP UA. The IP-PBX Module MUST be able to queue incoming calls, with media-on-hold. P a g e 23

10 REFERENCES 1 Broadband Forum TR-069 Amendment 4 - CPE WAN Management Protocol (2011) 2 Broadband Forum TR-104- DSLHomeTM Provisioning Parameters for VoIP CPE (2005) 3 IETF RFC 3264 - An Offer/Answer Model with Session Description Protocol (SDP) 4 IETF RFC 5589 - Session Initiation Protocol (SIP) Call Control - Transfer 5 IETF RFC 3891 - The Session Initiation Protocol (SIP) 6 ITU-T G.729 - Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear prediction (CS-ACELP) 7 IETF RFC 3842 - A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP) 8 IETF RFC 2132 - DHCP Options and BOOTP Vendor Extensions 9 ETSI TR 183 069 - Business Trunking. NGCN-NGN Interfaces Implementation Guide 10 IETF RFC 2616 Hypertext Transfer Protocol HTTP/1.1 11 ECMA TR/87 - Using CSTA for SIP Phone User Agents (uacsta) 12 ECMA-323 4th edition - XML Protocol for Computer Supported Telecommunications Applications (CSTA) Phase III 13 IETF RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2 14 IETF RFC 3711 - The Secure Real-time Transport Protocol (SRTP) 15 IETF RFC 1350 The TFTP protocol (revision 2) 16 IETF RFC 2818 HTTP over TLS P a g e 24

11 APPENDIX 1 11.1 IP CENTREX Figure 5 shows how a Small Business could be connected in an IP-Centrex scenario. One of the FXS ports is connected to one or more analogue phones which use conventional telephone extension wiring. This can be used to provide an additional line, and provides a backup in the event of a local power failure if the Gateway has a PSTN connection with cut through under such failure. The other FXS port is shared by a fax machine (usage is expected to be rare) and a POS terminal. The Gateway includes a DECT base station which allows multiple handsets to communicate locally with no involvement of the IP Centrex system, and to share access to one or more IP Centrex numbers. The extra voice capacity and capability is provided by SIP devices which are either dedicated VoIP phones or soft clients embedded in PCs etc. These are connected to the Gateway using wired or wireless Ethernet. While the Gateway automatically routes local calls i.e. without any additional forwarding functionality, it does require some specific capabilities to support the IP Centrex scenario. These are not covered by this document, but include: SIP UAs for the FXS ports SIP UAs for the DECT system Local mixing of 3-party calls B2BUA (in the case of IMS, this is already specified in HGI Release 2). Since the SIP phones have to register directly with the SIP Softswitch this requires SIP interoperability, which in practice makes the SIP phones specific to each operator. There is a second WAN IP interface which can be used as a backup, with the ultimate backup being provided by the FXO line. P a g e 25