VoIP Providers released for Unify Enterprise Platforms > table
The connection of communication systems to the public
network via SIP Trunking can be used instead or in
addition to traditional PSTN trunks. Many VoIP Providers,
also known as ITSPs, are offering corresponding services.
The following article gives an overview of the SIP trunking
features and limitations and lists the Providers, which
have been tested and released with the enterprise platforms.
You did not find your provider? Find out how to get it released!
You are looking for certified providers on SME platforms? Collaboration with VoIP Providers on SME Platforms
You need further information on consulting services or the latest events?
Visit our Homepage
The enterprise platforms have been tested with a large number of internet telephony providers that support SIP. Continuously new providers are tested, released and included within administration. As the SIP recommendations leave some room for interpretation, there are differences in the range of features supported with a specific provider. In this chapter general information is given which is valid for all platforms and all SIP Providers.
SIP trunking features for all enterprise platforms
- Up to 10 active SIP Providers
- Operation behind another router using STUN(can be configured per provider with current software)
- Optional SBC funcitonality
- SIP trunking with single numbers (MSN)
- Direct Inward Dialing (DID)
- Comprehensive feature set available e.g.
- Hold, Consultation, Toggle
- Transfer (attended, semi-attended)
- Ringing group, Call pickup
- Call Forwarding
- DTMF transmission e.g. for voicemail access
- Simultaneous VoIP connections depending on system and available DSL bandwidth, used Codec and system. G.711 needs up to 92 kbit/s, G.729A needs up to 36 kbit/s in both directions.
- Automatic fallback to ISDN at SIP trunk failure
- Voice Codecs G.711 and G.729
- Fax over IP via T.38
| Security Warning - Malicious attacks from the Internet may lead to reduced service quality or toll fraud!|
Please strictly follow these basic rules:
- Never open up the firewall in an internal or external router e.g. by forwarding port 5060.
The SBC takes care of opening the firewall for traffic with the selected VoIP providers. Attacks from other internet addresses are therefore blocked. Opening up the router's firewall would invalidate this security measure.
- Never configure SIP subscribers at a HiPath / OpenScape system without a strong password.
Authentication blocks registration of unauthorised SIP clients. See http://wiki.unify.com/wiki/Features_and_Configuration_of_SIP_Devices
General Requirements for VoIP
- LAN with 10/100/1000 MBit/s and no more than 40% network load
- Separate port on the switch or router for every component in the IP network (no hubs as concentrators)
- Not more than 50 ms delay in one direction (One Way Delay); not more than 150 ms total delay
- Not more than 3% packet loss and 20 ms jitter
- Quality of Service (QoS) support - IEEE 802.p, DiffServ (RFC 2474) or ToS (RFC 791)
- Sufficient WAN bandwidth (uplink and downlink) for intended simultaneous calls and CODEC
- External modem, such as a DSL modem
- Intermediate routers shall support quality of service and bandwidth control mechanisms if the WAN link is used for voice and data simultaneously. SIP messages have to be routed transparently.
For interworking with different network configurations and edge devices and how to use STUN please see Network Configuration for VoIP Providers.
Restrictions for all Providers and enterprise Platforms
- Special call numbers and emergency calls
- Special call numbers (e.g. 0800, 0900, 0137) or analog fax/modem connections are not supported by all SIP providers.
- Emergency call numbers (e.g. 110, 112) are not supported by all providers. These connections must be implemented via TDM trunks.
- For DTMF transmission outband transport via RFC 2833/RFC4733 is highly recommended. The ITSP MUST support outband DTMF (RFC2833) if UC Suite functions via SIP trunk (e.g. auto attendant, voicemail control) shall be used.
- For DTMF transmission inband transport may be used, but the functionality cannot be guaranteed as endpoints (e.g. UC-Suite) may not support inband DTMF.
- For Fax transmission the T.38 protocol is highly recommended. The ITSP MUST support T.38 if UC Suite fax via SIP trunk shall be used. From ... UC Suite is able to proceed T.38 and G.711 faxes as well.
- If your provider does not support Fax T.38, Fax pass-through with G.711 is possible but transmission quality depends on network infrastructure in this case.
- An incoming ITSP call can be transferred or forwarded to another public subscriber via ITSP. Concatenation of such 'trombone scenarios' is not supported. So 2 lines (one incoming and one outgoing) are used while the call is active.
How to get a new VoIP provider released
The native SIP Subscriber interface is an open interface for SIP applications and can be used for the integration of other partner products after successful OpenScape Ready Certification. Such certifications are an essential requirement to minimize the project risks associated with integrating non- Unify products into our Open Communications solutions. The certifications confirm the functionality of the scenarios described in the relevant test reports, providing assurance to sales for quotes to customers in the field. In addition, the OpenScape Ready certifications guarantee that our support organization will provide service in case of faults in customer solutions, in which certified non- Unify products are included (Global Vendor Support & Development Support).
For the interoperability tests with required Service Provider in your local region, following interoperability and release process has been established:
- Creation of a Change Request for OpenScape 4000 (incl. provider name, contact person etc.).
- The configuration and commissioning is coordinated with the SIP Provider Team.
- As soon as the basic connectivity has been established, further test cases from the OpenScape 4000 Interop test guide are carried out.
- When the interoperability tests are completed, a test report (including trace logs) is sent to the SIP Provider Team.
- The SIP Provider Team evaluates the test report and the traces.
- If this evaluation is positive, the SIP Provider connection is released with the tested range of features. In the case of a negative evaluation, the SIP Provider Team will propose appropriate measures: fault correction, creation of a Change Request, …
- New released SIP Service Provider connectivity’s will be described in the Release Note for new Fixed/Minor Releases. In the Web Based Management you will find an individual SIP Trunking Profile for this SIP Service Provider.
In order to implement SIP connections in a fast and competent fashion, Unify PH LS DEV 1 has formed a SIP Provider Team, offering the following services:
- Questionnaire (catalog of questions) to find out initial configuration
- Analysis of SIP Provider specifications
- Support for initial configuration
- Error diagnosis / Checking of test results
- Release of SIP Service Provider and documentation in the Release Note
The costs for installation and testing must be borne by the region or project.
The following process allows for SIP trunk interoperability testing with OpenScape Voice to be conducted by an LC/local region or by a channel partner and, assuming the test results are successful, be recognized by the Product House as a valid certification and therefore be supported by Unity Large Enterprise IP Product Management, Development and Service organizations. This process is supported for the current (latest) released version of OpenScape Voice. It is also supported for older versions of OpenScape Voice up until that version reaches the M44 milestone, in order to fulfill the SIP trunking needs of customers still using the older version. For further information, see
SIP Trunk Interoperability Testing by LC-Region or Channel Partner Process Flow - latest update: 2015-07-06
| Note: The LC, local region, or channel partner must ensure it has all of the necessary local technical resources with proper skills and training to perform the testing and to produce the required deliverables upon conclusion of the testing BEFORE beginning this process. If it does not have the resources to do this then an alternative would be to engage a CSL (by NPR process) to perform the certification testing instead.
- To initiate this process, the LC/local region or channel partner shall submit a PSR (via OSIRIS) to request support of the SIP trunk interoperability testing to be performed.
- Upon receipt of the PSR, the responsible Product Manager will obtain the necessary approvals from Unity Large Enterprise IP Development/System Test and Service HQ.
- The LC/local region or channel partner shall use the Unify Large Enterprise IP generic SIP-Trunk tests with SIP-Provider Test List as the MINIMUM set of test cases to be run. The LC/local region or channel partner shall also run any and all additional tests cases that are required by the SSP. This may include the requirement to execute a second complete test plan as supplied by the SSP.
- Testing shall be conducted in the LC/local region or channel partner’s test lab or at the customer site with the desired type and version of the Unify Large Enterprise IP platform and customer-premises SBC, using test resources supplied by the LC/local region or channel partner. All time and material costs for the testing shall be borne by the LC/local region or channel partner.
- Local service engineers and technical support shall be used for all necessary setup and testing.
- The LC/local region or channel partner shall use the latest software load released by Unify Large Enterprise IP Product House (on SWS) for the version of customer-premises equipment (e.g. platform and SBC) that is being tested.
- If problems (defects) associated with the Unify Large Enterprise IP software are discovered during testing, GSI.flow ticket(s) shall be created. Only legitimate defects reported by GSI.flow tickets will be fixed.
- If any enhancements to the Unify Large Enterprise IP software are required, for example, to develop a new configurable option or SIP method to allow interworking with the SSP being tested, an RQ will need to be created in TopInfo-R.
- If as a result of the testing fixes are provided to the customer-premises equipment (e.g. platform or SBC), or if fixes are provided to the SSP’s SIP trunk interface, the LC/local region or channel partner shall be responsible for re-testing the fixes as part of the interoperability testing and documenting the results based on the fixes in the test report.
- Upon completion of testing, the LC/local region or channel partner shall send (e.g. by email) a copy of the following deliverables to the responsible Product Manager:
- Test Report
- Parameter Settings
- Trace Files
- Customer Configuration Guide or Application Note (optional)
- The responsible Product Manager will arrange to have the test report reviewed by Unify Large Enterprise IP Development/System Test. If the test report is missing required information or is otherwise deemed to be inadequate, the LC/local region or channel partner will be notified of the issues, and then they must fix the issues and resubmit the corrected test report.
- Once the test report is approved by Unify Large Enterprise IP Development/System Test, the submitter of the PSR will be informed by Product Management (e.g. by email) that the SIP trunk can be deployed in the customer project(s) and, if applicable, also be informed of any restrictions or conditions that may apply.
| Applicabaility of approval to other SIP trunk configurations/versions |
This process (or another equivalent supported SIP trunk certification process) usually needs to be repeated whenever a new major release of the SSP’s SIP Trunk service or a new major release of Unify Large Enterprise IP platform version (or a different SIP trunk interface configuration, e.g. using a different customer-premises SBC) needs to be supported.
| Note: Since the SIP trunk interface supported by Unify Large Enterprise IP platforms are designed to be backwards compatible with previous versions, repeating this (or an equivalent) process for a new version of the Unify Large Enterprise IP platform (assuming the SIP trunk interface configuration is the same) may be waived if recertification is not mandated by the SSP. In this case, a PSR requesting a waiver together with a certificate or written statement from the SSP indicating that they accept the previous certification as being applicable to the new release of the Unify Large Enterprise IP platform needs to be submitted (via OSIRIS) for approval by Unify Large Enterprise IP Product House.
General Information by platform
- Concurrent calls via ITSP (depending on the available bandwidth and used Codec):
- HG3500 Common Gateway (max. 120 SIP trunking sessions per module)
- vHG3500 SIP in SoftGate applications (max. 240 SIP trunking sessions per SoftGate server)
- vHG3500 SIP in OpenScape Access 500 (max. 240 SIP trunking sessions per OpenScape Access 500)
- Available native SIP Trunking functionalities:
- Basic Call conform to RFC3261 SIP
- Sending and receiving E.164 Telephone Numbers (e.g. +498972237729)
- Number Identification
- Name Display
- Call Hold, Call Retrieve, Call Toggle
- Call Transfer (Attended/Semi-Attended/Blind)
- Sending of Call Forwarding information (Diversion Header)
- Message Waiting Indication activation from voicemail systems
- Locating SIP Servers using DNS SRV
- SIP Proxy Failover and Recovery
- Addressing SIP Server/Proxies using IP-Addresses or Full Qualified Domain Names
- Registration to SIP Service Provider
- Session Border Controller Connectivity
- Digest Authentication
- L2 and L3 QoS for Signaling and Payload
- T.38 Fax transmissions (New Enhancements)
- DTMF inband or conform RFC2833
- Voice Codecs G.729 and G.711
- Silence Suppression
- Inband / Outband Proxy Configuration
- Flexible and individual native SIP Trunking Profiles
- UDP and TCP Transport for native SIP Trunking
- TLS V1.2 Support for native SIP Trunking signaling
- SRTP Support using SDES Key Management for native SIP Trunking
- Native SIP Trunking in IPv6 Networks
- IPv6 support for native SIP Trunking: IPv4/IPv6 Dual-Stack (ICE-mL and ANAT) and IPv6 only (PSR Required)
Tested VoIP Providers by Countries
The main SIP trunking functions of the enterprise platforms have been tested with the following Internet telephony providers. For detailed information see the document Overview about Released SIP Providers below.
= has been successfully tested by development or customer
DID = accounts for PBX-trunking / Direct Inward Dialling
MSN = accounts for single number(s)
- Please check provider home page for supported countries.
- Skype Connect is a fee-based business service from Skype. It allows voice communication between Skype clients and office phones using the standard SIP trunking interface. Other Skype client features like chat or video are currently not supported.
Our enterprise platforms have been officially certified by Skype.
United Arab Emirates (UAE)
United Kingdom (UK)
United States (US)
Released SIP Providers in Detail
The table above shows the ITSPs that passed successfully a connectivity test. More details about test results, supported features and restrictions for a specific ITSP are listed in following PDF document.
The following scenarios are covered within the connectivity test:
- Basic Calls from / to ITSP
- Feature Tests
- Consultation, transfer, toggle, conference
- Call Pickup / ringing group scenarios
- Call forwarding scenarios
- Special Tests
- Emergency calls
- Service calls
- Long duration calls
- Calls handled via UC application
The connectivity tests are performed using various endpoints (for details see test list).
Frequently asked Questions