Howto:SilverServer SIP Provider Compatibility Test: Difference between revisions

From innovaphone wiki
Jump to navigation Jump to search
 
(23 intermediate revisions by the same user not shown)
Line 1: Line 1:
'''Innovaphone Compatibility Test Report'''
'''Innovaphone Compatibility Test Report'''
{{Template:Compat Status "tested"}}


== Summary ==
== Summary ==
Line 8: Line 6:


* Features:
* Features:
** Direct Dial In
** Direct Dial In
** DTMF
** DTMF
Line 14: Line 13:
** G711
** G711


The provider supports all required innovaphone features and is therefore qualified as [[Howto:What_is_a_%22recommended_product%22%3F#SIP_Provider|recommended SIP Provider]].
The provider does support all required innovaphone features and is therefore qualified as [[Howto:What_is_a_%22recommended_product%22%3F#SIP_Provider|recommended SIP Provider]].  
 
The configuration on innovaphone side is difficult, since you must use the VoIP-GW to connect to the provider. More on this topic in chapter [[#Configuration|SilverServer SIP Compatibility Test]]
 
SilverServer does not support the hold feature correctly. When making a transfer the remote end will not hear a MOH/dialtone.


SilverServer has achieved 78% of all possible test points. For more information on the test rating, please refer to [[Howto:SIP_Interop_Test_Description#Summary|Test Description]]
SilverServer has achieved 85% of all possible test points. For more information on the test rating, please refer to [[Howto:SIP_Interop_Test_Description#Summary|Test Description]]


== Current test state ==
== Current test state ==
{{Template:Compat Status "tested"(sip provider)}}
{{Template:Compat Status "tested"}}
<!-- {{Template:Compat Status "in progress"}} -->
<!-- {{Template:Compat Status "in progress"}}-->
<!--{{Template:Compat Status "certified"|certificate=Tpl_sip.business_Toplink_SIP_Provider_-_product-cert.pdf}}-->
<!--{{Template:Compat Status "certified"|certificate=Tpl_sip.business_Toplink_SIP_Provider_-_product-cert.pdf}}-->
<!-- {{Template:Compat Status "rejected"}} -->
<!--{{Template:Compat Status "rejected"}} -->


Testing of this product has been finalized October 21th, 2007.
Testing of this product has been finalized June 20th, 2011.


== Testing Enviroment ==
== Testing Enviroment ==


=== Scenario ===
=== Scenario ===
This scenario tries to be as simple as possible. The IP - PBX and the phones are all in the same network, having public IP - adresses.
[[Image:HFO_SIP_Compatibility_Test_5.PNG]]
The signalling channel will pass through the PBX, the media channel will go from endpoint (phone) to endpoint (provider).


[[Image:CompatProviderSIP-1.JPG]]
This scenario describes a setup where the PBX and phones are in a private network. The IP800 must use a stun server, in order to send correct SIP - messages. The IP800 works as media relay, all RTP - streams go through the PBX.


== Test Results ==
== Test Results ==
Line 68: Line 62:
|No
|No
|----
|----
|CGPN can be supressed
|CGPN can be suppressed
|No
|----
|CLIP no screening
|No
|No
|----
|----
|'''Reverse Media Negotiaton'''
|'''Reverse Media Negotiation'''
|'''Yes'''
|----
|'''Long time call possible'''
|'''Yes'''
|----
|'''External Transfer'''
|'''Yes'''
|'''Yes'''
|----
|----
Line 98: Line 101:
|----
|----
|'''DTMF tones sent correctly'''
|'''DTMF tones sent correctly'''
|'''Yes'''
|----
|'''DTMF tones sent correctly via SIP-Info'''
|'''Yes'''
|'''Yes'''
|----
|----
Line 114: Line 120:
|----
|----
|Held end hears music on hold / announcement from PBX
|Held end hears music on hold / announcement from PBX
|No
|Yes
|----
|----
|Held end hears music on hold / announcement from provider
|Held end hears music on hold / announcement from provider
|No
|Yes
|}
|}


Line 126: Line 132:
!Result  
!Result  
|----
|----
|'''Call can be transfered'''
|'''Call can be transferred'''
|'''Yes'''
|'''Yes'''
|----
|----
|Held end hears music on hold
|Held end hears music on hold
|No
|Yes
|----
|----
|'''Call returns to transferring device if the third Endpoint is not available'''
|'''Call returns to transferring device if the third Endpoint is not available'''
Line 142: Line 148:
!Result  
!Result  
|----
|----
|'''Call can be transfered'''
|'''Call can be transferred'''
|'''Yes'''
|'''Yes'''
|----
|----
|Held end hears music on hold or dialing tone
|Held end hears music on hold or dialling tone
|No
|Yes
|----
|----
|'''Call returns to transferring device if the third Endpoint is not available'''
|'''Call returns to transferring device if the third Endpoint is not available'''
Line 158: Line 164:
!Result  
!Result  
|----
|----
|Call can be transfered
|Call can be transferred
|Yes
|Yes
|----
|----
|Held end hears dialing tone
|Held end hears dialling tone
|No
|Yes
|}
|}


Line 188: Line 194:




*IP800: 6.00 dvl-sr1 IP800[07-60600.74]
*IP800: 9.00 hotfix1
*IP22: 6.00 sr1-hotfix4 IP22[07-60600.72]
*IP22: 8.00 hotfix16 - build 805005400
*IP200: 6.00 dvl-sr1 IP230[07-60600.58]
*IP200: 9.00 hotfix1
*IP230: 6.00 dvl-sr1 IP230[07-60600.58]
*IP230: 9.00 hotfix1


=== SIP - Trunk ===
=== SIP - Trunk ===


First of all the SIP Trunk must be configured. Since SilverServer authenticates a user account only by IP - Address, you cannot use the normal SIP-Gateway object. You need to configure a GW without registration and route the calls to the PBX. Also SilverServer uses different servers for load balancing reasons. You must make an GW without registration object for every possible IP-destination(e.g. SilverServer SIP Server).
First of all the SIP Trunk must be configured. Since SilverServer authenticates an user account by IP - Address and additionally by registration, so you must use the normal SIP-Interface and also a Gateway - Interface without registration.  


Outgoing calls to the SIP provider must be sent via the SIP - Interface.


[[Image:SilverServer SIP Compatibility Test 1.PNG]]
[[Image:SilverServer SIP Compatibility Test 1.PNG]]


A important setting is to change the SIP Interop Tweak 'From Header when Sending INVITE' to ''CGPN in user part of URI'' and '''Identity Header when Sending INVITE'''  to 'Fixed AOR'. You have to do this, because SilverServer does not read the ''Preferred identity'' header information but looks directly in the ''FROM'' header for DDI information.


Since no NAT - detection is performed by the provider, 'Media-Relay' must be activated and a STUN server entry must be made, when the PBX is in a private IP - network - behind a NAT router. The NAT router must be STUN capable.


Like described, before you need a Gateway for every possible SilverServer SIP Server. Note that the Server Adrress on the two GWs changes, while the Domain entry does not. Another important setting is to change the SIP Interop Tweak from ''AOR'' to ''AOR with CGPN as display'' on '''both''' GWs(i.e. GW1 & GW3). You have to do this, because SilverServer does not read the ''Preffered identity'' header information but looks directly in the ''FROM'' header for DDI information.
The 'Gateway without registration' interface is needed to route the calls to the PBX.
 
Again, the interface settings are done similar to the SIP interface. Most important is that, 'Media-Relay' must be activated and a STUN server entry must be made, when the PBX is in a private IP - network - behind a NAT router. The Gateway interface must have the 'Local Domain' configured with the public IP - address of the customer NAT - router.
 
The calls are sent and received from different servers on Silverserver site. As a result, you will have a different entry as 'AOR'/'Remote Domain' on the SIP interface compared to the 'Gateway without registration' interface.
 
[[Image:SilverServer SIP Compatibility Test 2.PNG]]


=== Number Mapping ===
=== Number Mapping ===
Line 208: Line 223:
The complicated part on this issue is the correct mapping of the outgoing and incoming numbers.  
The complicated part on this issue is the correct mapping of the outgoing and incoming numbers.  


[[Image:SilverServer SIP Compatibility Test 2.PNG]]
[[Image:SilverServer SIP Compatibility Test 3.PNG]]


=== Route Settings ===
=== Route Settings ===


Because SilverServer, as most SIP - Providers too, doesn't support overlap sending, you must enable the blockwise sending of the phone number. You can do this by enabling ''Force enblock'' in your routes.
Because SilverServer, as most SIP - Providers too, doesn't support overlap sending, you must enable the block-wise sending of the phone number. You can do this by enabling ''Force enblock'' in your routes.


The second setting you must check is Interworking(QSIG,SIP). This feature must be enabled to properly relay suplementary services, like Hold over the SIP Trunk. If this checkbox is unchecked only basic call Information like connect and disconnect will be forwarded by the Gateway.
The second setting you '''can''' check is 'Interworking(QSIG,SIP)'. When enabling this feature, you will hear the MoH offered by the provider. If 'Interworking(QSIG,SIP)' is disabled, a 'Call Hold' will not be forwarded to the provider. As a result, you will hear in this case the MoH provided by the PBX. It is recommended to leave the 'Interworking(QSIG,SIP)' unchecked, as shown in the screenshot below.


[[Image:SilverServer SIP Compatibility Test 3.PNG]]
[[Image:SilverServer SIP Compatibility Test 4.PNG]]





Latest revision as of 10:07, 27 June 2011

Innovaphone Compatibility Test Report

Summary

SIP Provider: SilverServer(Austria)

  • Features:
    • Direct Dial In
    • DTMF
  • Supported Codecs by the provider
    • G711

The provider does support all required innovaphone features and is therefore qualified as recommended SIP Provider.

SilverServer has achieved 85% of all possible test points. For more information on the test rating, please refer to Test Description

Current test state

The tests for this product have been completed.

Testing of this product has been finalized June 20th, 2011.

Testing Enviroment

Scenario

HFO SIP Compatibility Test 5.PNG

This scenario describes a setup where the PBX and phones are in a private network. The IP800 must use a stun server, in order to send correct SIP - messages. The IP800 works as media relay, all RTP - streams go through the PBX.

Test Results

For more information on the test procedure, please read the following wiki article: SIP Interop Test Description. Bold lines in the test results indicate a KO-criteria.

Basic Call

Tested feature Result
call using g711a Yes
call using g711u Yes
call using g723 No
call using g729 No
Overlapped sending No
early media channel Yes
Fax using T.38 No
CGPN can be suppressed No
CLIP no screening No
Reverse Media Negotiation Yes
Long time call possible Yes
External Transfer Yes
Voice Quality OK? Yes

Direct Dial In

Tested feature Result
Inbound(Provider -> Innovaphone) Yes
Outbound(Innovaphone -> Provider) Yes

DTMF

Tested feature Result
DTMF tones sent correctly Yes
DTMF tones sent correctly via SIP-Info Yes
DTMF tones received correctly Yes

Hold/Retrieve

Tested feature Result
Call can be put on hold Yes
Held end hears music on hold / announcement from PBX Yes
Held end hears music on hold / announcement from provider Yes

Transfer with consultation

Tested feature Result
Call can be transferred Yes
Held end hears music on hold Yes
Call returns to transferring device if the third Endpoint is not available Yes

Transfer with consultation (alerting only)

Tested feature Result
Call can be transferred Yes
Held end hears music on hold or dialling tone Yes
Call returns to transferring device if the third Endpoint is not available Yes

Blind Transfer

Tested feature Result
Call can be transferred Yes
Held end hears dialling tone Yes

Broadcast Group & Waiting Queue

Tested feature Result
Caller can make a call to a Broadcast Group Yes
Caller can make a call to a Waiting Queue Yes
Announcement if nobody picks up the call Yes

Configuration

General Information

Firmware version


  • IP800: 9.00 hotfix1
  • IP22: 8.00 hotfix16 - build 805005400
  • IP200: 9.00 hotfix1
  • IP230: 9.00 hotfix1

SIP - Trunk

First of all the SIP Trunk must be configured. Since SilverServer authenticates an user account by IP - Address and additionally by registration, so you must use the normal SIP-Interface and also a Gateway - Interface without registration.

Outgoing calls to the SIP provider must be sent via the SIP - Interface.

SilverServer SIP Compatibility Test 1.PNG

A important setting is to change the SIP Interop Tweak 'From Header when Sending INVITE' to CGPN in user part of URI and Identity Header when Sending INVITE to 'Fixed AOR'. You have to do this, because SilverServer does not read the Preferred identity header information but looks directly in the FROM header for DDI information.

Since no NAT - detection is performed by the provider, 'Media-Relay' must be activated and a STUN server entry must be made, when the PBX is in a private IP - network - behind a NAT router. The NAT router must be STUN capable.

The 'Gateway without registration' interface is needed to route the calls to the PBX.

Again, the interface settings are done similar to the SIP interface. Most important is that, 'Media-Relay' must be activated and a STUN server entry must be made, when the PBX is in a private IP - network - behind a NAT router. The Gateway interface must have the 'Local Domain' configured with the public IP - address of the customer NAT - router.

The calls are sent and received from different servers on Silverserver site. As a result, you will have a different entry as 'AOR'/'Remote Domain' on the SIP interface compared to the 'Gateway without registration' interface.

SilverServer SIP Compatibility Test 2.PNG

Number Mapping

The complicated part on this issue is the correct mapping of the outgoing and incoming numbers.

SilverServer SIP Compatibility Test 3.PNG

Route Settings

Because SilverServer, as most SIP - Providers too, doesn't support overlap sending, you must enable the block-wise sending of the phone number. You can do this by enabling Force enblock in your routes.

The second setting you can check is 'Interworking(QSIG,SIP)'. When enabling this feature, you will hear the MoH offered by the provider. If 'Interworking(QSIG,SIP)' is disabled, a 'Call Hold' will not be forwarded to the provider. As a result, you will hear in this case the MoH provided by the PBX. It is recommended to leave the 'Interworking(QSIG,SIP)' unchecked, as shown in the screenshot below.

SilverServer SIP Compatibility Test 4.PNG


Now the PBX and the phones are setup correctly. You should be able to make call in both directions and send and receive fax messages.