Howto:HFO NGN Connect - HFO - SIP Provider: Difference between revisions

From innovaphone wiki
Jump to navigation Jump to search
 
(32 intermediate revisions by one other user not shown)
Line 1: Line 1:
'''Innovaphone Compatibility Test Report'''
'''Innovaphone Compatibility Test Report'''
{{Template:Compat Status "in progress"}}


== Summary ==
== Summary ==
Line 9: Line 7:
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 supports all required innovaphone features and is therefore qualified as [[Howto:What_is_a_%22recommended_product%22%3F#SIP_Provider|recommended SIP Provider]].  


HFO does not support the remote hold feature. When making a blind transfer(using redial key) the remote end will not get a MOH/dialtone from the provider.  
Only if the Mobility-feature or WebRTC is desired by the customer, you must enable Media-Relay on the SIP-Trunk. Opposed to a SIP trunk not needing Media-Relay, the transport of all RTP packets by the gateway will result in a higher CPU load for a call. As a result, the amount of concurrent calls is considerably lower compared to a SIP-Provider that doesn't require Media-Relay.
 
The provider doesn't support the G.729 coder, this might be an issue in locations with low-bandwidth Internet connection.
 
The PBX is connected to the provider through the public Internet, the tested product "HFO NGN Connect" comes without a dedicated Internet Access Device.
According to the provider the amount of concurrent calls is limited when ordering the trunk, currently max. 220 concurrent calls are possible.
 
The provider offers an additional SIP-trunk product called [http://www.hfo-telecom.de/produkte/geschaeftskunden/hfo-ngn-business HFO NGN Business]. This product comes with a dedicated Internet Access, used only for telephony. According to HFO, it uses the same SIP server as the tested product "HFO NGN Connect". As a result, the configuration on innovaphone side should be equal. For more details on the product "HFO NGN Business", please contact the provider directly.


HFO has achieved x% of all possible test points. For more information on the test rating, please refer to [[Howto:SIP_Interop_Test_Description#Summary|Test Description]]
NAT - Detection doesn't work for all private networks, see [[Howto:HFO_NGN_Connect_-_HFO_-_SIP_Provider#Known_Problems | Known Problems]] for more information.
 
That being said, the provider has achieved 92% of all possible test points. For more information on the test rating, please refer to [[Howto:SIP_Interop_Test_Description#|Test Description]]


* Features:
* Features:


** Direct Dial In
** Direct Dial In
** Fax over IP (T.38)
** DTMF
** DTMF
** Clip No Screening


* Supported Codecs by the provider
* Supported Codecs by the provider
** G711
** G711
** G729
** G722
** T.38 UDP


== Current test state ==
== Current test state ==
{{Template:Compat Status "tested"}}
 
<!--{{Template:Compat Status "planned"}} -->
<!-- {{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_"referral_prod."|certificate=Tpl_sip.business_Toplink_SIP_Provider_-_product-cert.pdf}} -->
<!-- {{Template:Compat_Status_"engineered_prod."|certificate=Tpl_sip.business_Toplink_SIP_Provider_-_product-cert.pdf}} -->
{{Template:Compat_Status_"rec._prod."|certificate=HFO_NGN_Connect_HFO_SIP_Provider_-_product-cert.pdf}}
<!-- {{Template:Compat Status "tested"(sip provider)}} -->
<!-- {{Template:Compat Status "rejected"}} -->
<!-- {{Template:Compat Status "rejected"}} -->
<!-- {{Template:Compat_Status_"referral_prod."-no-certificate}} -->
Testing of this product has been finalized June 23th, 2015.


Testing of this product has been finalized October 22th, 2007.
== Testing Environment ==


== Testing Enviroment ==
[[Image:SIPProviderTestTopology1.PNG]]


This scenario describes a setup where the PBX and phones are in a private network.


=== Scenario NAT ===


[[Image:HFO_SIP_Compatibility_Test_5.PNG]]
* the SIP trunk is configured without Media Relay and without exclusive coder. Media-Relay must be only activated if ''Mobility'' is used.


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 ==


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


=== Basic Call ===
=== Basic Call ===
The purpose of  the ''Basic Call'' tests is to verify some standard provider features, like supported codecs and their overall voicequality. Also tested is the early media channel capabilities of the provider. Most SIP - Provider will not support early media, they will send SIP Status Messages (e.g. 404 User Not Found) instead of a Voice Stream(RTP) containing the same information.


{| border="1"  
{| border="1"  
!Tested feature
!Tested feature
!Result
!Result  
|----
|SIP over TLS(SIPS)
|Nok
|----
|SIP over TCP
|Nok
|----
|----
|call using g711a
|SRTP
|Yes
|Nok
|----
|----
|call using g711u
|'''call using g711a'''
|Yes
|'''Ok'''
|----
|----
|call using g723
|'''call using g711u'''
|No
|'''Ok'''
|----
|----
|call using g729
|call using g729
|Yes
|Nok
|----
|call using g722
|Ok
|----
|----
|Overlapped sending
|Overlapped sending
|No
|Nok
|----
|----
|early media channel
|'''early media channel'''
|?
|'''Ok'''
|----
|----
|Fax using T.38
|Fax using T.38
|No
|Ok
|----
|T.38 Transcoding by the provider
|Ok
|----
|Reverse Media Negotiation
|Ok
|----
|CGPN can be suppressed
|Ok
|----
|CLIP no screening
|Ok
|----
|'''Long time call possible(>30 min)'''
|'''Ok'''
|----
|'''External Transfer'''
|'''Ok'''
|----
|NAT Detection
|Ok*
|----
|Redundancy
|Ok
|----
|----
|Voice Quality OK?
|'''Voice Quality OK?'''
|Yes
|'''Ok'''
|}
|}
* NAT - Detection doesn't work for all private networks, see section [[Howto:HFO_NGN_Connect_-_HFO_-_SIP_Provider#Known_Problems | Known Problems]] for more information.


=== Direct Dial In ===
=== Direct Dial In ===
This test verifys if the providers supports the Direct Dial In(DDI) feature. This is very important, without DDI the provider cannot be used in company enviroments. The provider offers the customer a trunk number and a phone extenion intervall.


{| border="1"  
{| border="1"  
!Tested feature
!Tested feature
!Result
!Result  
|----
|----
|Inbound(Provider -> Innovaphone)
|'''Inbound(Provider -> Innovaphone)'''
|Yes
|'''Ok'''
|----
|----
|Outbound(Innovaphone -> Provider)
|'''Outbound(Innovaphone -> Provider)'''
|Yes
|'''Ok'''
|----
|'''Loop In call(Innovaphone -> Provider -> Innovaphone)'''
|'''Ok'''
|}
|}
When configuring the IP800 it is very important to make the correct number mappings. You will find out more on this issue by scrolling to chapter "Configuration" .


=== DTMF ===
=== DTMF ===
DTMF is also a must have feature for a company. DTMF is crucial for the use of a voicemail system. Currently there are two methods of transfering DTMF signals, by SIP - INFO message or encapsulated in the RTP - packet. Innovaphone supports both types of DTMF signalling.


{| border="1"  
{| border="1"  
!Tested feature
!Tested feature
!Result
!Result  
!Comments
|----
|----
|DTMF tones sent correctly
|'''DTMF tones sent correctly via RTP-events(RFC 2833)'''
|Yes
|'''Ok'''
|HFO acceps both RTP - Packets and SIP-INFO Messages for DTMF Tones
|----
|----
|DTMF tones received correctly
|DTMF tones sent correctly via SIP-Info
|Yes
|Nok
|HFO acceps both RTP - Packets and SIP-INFO Messages for DTMF Tones
|----
|----
|DTMF tones audible in both directions
|'''DTMF tones received correctly via RTP-events(RFC 2833)'''
|Yes
|'''Ok'''
|
|}
|}


=== Hold/Retrieve ===
=== Hold/Retrieve ===


{| border="1"
!Tested feature
!Result
|----
|'''Call can be put on hold'''
|'''Ok'''
|----
|Held end hears music on hold / announcement from PBX
|Ok
|}


When a call is put on hold, users normally expect to hear some kind of music/announcment signalling them that they should wait. However there are two possibilities. The PBX generates the announcement or the provide generates it.
=== Transfer with consultation ===


If you want to test a PBX generated announcement, then use the ''R'' - key to hold a conversation. This type of holding is tested in the Hold/Retrieve , Transfer with consultation and Transfer with consultation (alerting only) scenario.
{| border="1"
 
!Tested feature
If you want to test a provider generated announcement, then use the redial key to hold the conversation. This is used when doing a blind transfer.
!Result
|----
|'''Call can be transferred'''
|'''Ok'''
|----
|Held end hears music on hold
|Ok
|}


The following tests are made to test if call transfer is working.


{| border="1"  
{| border="1"  
!Tested feature
!Tested feature
!Result
!Voice Ok?
!MoH Ok?
|----
|----
|Call can be put on hold
|inno1 calls inno2. inno2 transfers to PSTN-phone.
|Yes
|Ok
|Ok
|----
|----
|Held end hears music on hold / announcement from PBX
|inno1 calls PSTN-phone. inno1 transfers to inno2.
|No
|Ok
|Ok
|----
|inno1 calls PSTN-phone. PSTN-phone transfers to inno2.
|Ok
|Ok
|----
|PSTN-phone calls inno1. inno1 transfers to inno2.
|Ok
|Ok
|----
|----
|Held end hears music on hold / announcement from provider
|PSTN-phone calls inno1. PSTN-phone transfers to inno2.
|No
|Ok
|Ok
|----
|----
|Either call can be terminated or be retrieved
|PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2.
|Yes
|Ok
|Ok
|}
|}


 
=== Transfer with consultation (alerting only) ===
=== Transfer with consultation ===


{| border="1"  
{| border="1"  
!Tested feature
!Tested feature
!Result
!Result  
|----
|----
|Call can be transfered
|'''Call can be transferred'''
|Yes
|'''Ok'''
|----
|----
|Held end hears music on hold
|Held end hears music on hold or dialling tone
|No
|Ok
|----
|----
|Call returns to transferring device if the third  
|'''Call returns to transferring device if the third'''
Endpoint is not available
'''Endpoint is not available'''
|Yes
|'''Ok'''
|}
|}


The following tests are made to test if call transfer is working.
=== Transfer with consultation (alerting only) ===
 


{| border="1"  
{| border="1"  
!Tested feature
!Tested feature
!Result
!Voice Ok?
!MoH Ok?
|----
|inno1 calls inno2. inno2 transfers to PSTN-phone.
|Ok
|Ok
|----
|inno1 calls PSTN-phone. inno1 transfers to inno2.
|Ok
|Ok
|----
|----
|Call can be transfered
|inno1 calls PSTN-phone. PSTN-phone transfers to inno2.
|Yes
|Ok
|Ok
|----
|----
|Held end hears music on hold or dialing tone
|PSTN-phone calls inno1. inno1 transfers to inno2.
|No
|Ok
|Ok
|----
|----
|Call returns to transferring device if the third
|PSTN-phone calls inno1. PSTN-phone transfers to inno2.
Endpoint is not available
|Ok
|Yes
|Ok
|----
|PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2.
|Ok
|Ok
|}
|}


=== Blind Transfer ===
=== Blind Transfer ===
When using a blind transfer, the accepts the call and relays it to another callee. This is done by pressing the redial key, typing the desired phone number, followed by the ''OK'' key (IP110 & IP230) or the Enter key (IP200).


{| border="1"  
{| border="1"  
!Tested feature
!Tested feature
!Result S1
!Result  
|----
|----
|Call can be transfered
|Call can be transferred
|Yes
|Ok
|----
|----
|Held end hears dialing tone
|Held end hears dialling tone
|No
|Ok
|}
|}


=== Broadcast Group & Waiting Queue ===
The following tests are made to test if call transfer is working.
 
From the technical point of view, this features have been tested already. The provider must be able to switch between Music on Hold, announcements and the responding caller. The heavy load of the callswitching is done by the PBX.


{| border="1"  
{| border="1"  
!Tested feature
!Tested feature
!Result
!Voice Ok?
|----
|inno1 calls inno2. inno2 transfers to PSTN-phone.
|Ok
|----
|----
|Caller can make a call to a Broadcast Group
|inno1 calls PSTN-phone. inno1 transfers to inno2.
|Yes
|Ok
|----
|----
|Caller can make a call to a Waiting Queue
|inno1 calls PSTN-phone. PSTN-phone transfers to inno2.
|Yes
|Ok
|----
|----
|Announcement if nobody picks up the call
|PSTN-phone calls inno1. inno1 transfers to inno2.
|Yes
|Ok
|----
|PSTN-phone calls inno1. PSTN-phone transfers to inno2.
|Ok
|----
|PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2.
|Ok
|}
|}


=== Calling Party Number ===
=== CFU / CFB Transfer ===


Here we tested if the provider accepts the phone extension (DDI) and forwards the calling number correctly. Also CGPN suppresion was tested. You can enable CGPN suppresion, directly at the IP200. You can suppress your number by enabling the checkbox "Hide own Number" found under
{| border="1"  
Configuration -> "Registration x" -> Preferences -> "Hide own Number".
!Tested feature
!Result
|----
|'''Call can be forwarded'''
|Ok
|----
|'''Held end hears dialling tone'''
|Ok
|}
 
=== CFNR / Blind Transfer (alerting only)===


{| border="1"  
{| border="1"  
!Tested feature
!Tested feature
!Result S1
!Result  
|----
|----
|CGPN is displayed correctly
|'''Call can be transferred or forwarded'''
|Yes
|'''Ok'''
|----
|----
|CGPN can be supressed
|'''Held end hears dialling tone'''
|No
|'''Ok'''
|}
|}


== Configuration ==
The following tests are made to test if call transfer is working.


=== General Information ===
{| border="1"
!Tested feature
!Voice Ok?
|----
|inno1 calls inno2. inno2 transfers to PSTN-phone.
|Ok
|----
|inno1 calls PSTN-phone. PSTN-phone transfers to inno2.
|Ok
|----
|PSTN-phone calls inno1. inno1 transfers to inno2.
|Ok
|----
|PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2.
|Ok
|}


'''Basic Provider Infomation: HFO'''
=== Broadcast Group & Waiting Queue ===


{| border="1"
!Tested feature
!Result
|----
|'''Caller can make a call to a Broadcast Group'''
|'''Ok'''
|----
|'''Caller can make a call to a Waiting Queue'''
|'''Ok'''
|----
|'''Announcement if nobody picks up the call'''
|'''Ok'''
|}


*described in Mantis Case: 16505
== Configuration ==


'''Firmware version'''
===Firmware version===


 
All innovaphone devices use V11r2 SR1 as firmware.
*IP800: 6.00 dvl-sr2 IP800[07-60600.58]
*IP22: 6.00 dvl-sr1 IP230[07-60600.58]
*IP200: 6.00 dvl-sr1 IP230[07-60600.58]
*IP230: 6.00 dvl-sr1 IP230[07-60600.58]


=== SIP - Trunk ===
=== SIP - Trunk ===
First of all the SIP Trunk must be configured. Here an example of our HFO - Trunk. If the Mobility-feature is desired by the customer, you must enable ''Media-Relay'' on the SIP-Trunk.


First of all the SIP Trunk must be configured. Here an example of our HFO - Trunk. If you want that the Gateway should act as Medialrelay, you must exchange the Gatekeeper Address (blue marking) to an private network address (see [[Howto:HFO_SIP_Compatibility_Test#Media Relay | Media Relay ]]); for example 127.0.0.1. HFO awaits in the From Header the complete Calling Party Number(CGPN). The default innovaphone setting is to not send the complete CGPN in  the FROM - Header, but in the Preffered Identity Header. Change the setting ''From Header:'' to ''CGPN in user part of URI''.
[[Image:HFO SIP.PNG]]


=== Number Mapping ===
The provider uses a CDPN in national format for incoming call. Therefore the SIP-interface maps must be configured accordingly.


[[Image:HFO SIP Compatibility Test 1.PNG]]
[[Image:HFO SIP Compatibility Test 2.PNG]]
 
=== Number Mapping ===


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


[[Image:HFO SIP Compatibility Test 2.PNG]]


=== Route Settings ===
=== Route Settings ===
Because HFO, 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 the automatically generated Routes.
Because HFO, 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 the automatically generated 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.


[[Image:HFO SIP Compatibility Test 3.PNG]]
[[Image:HFO SIP Compatibility Test 3.PNG]]


=== Media Relay ===
If there is a problem with the number format, make sure to read also [[Howto:Create_ClipNoScreening_Maps_for_SIP_Interfaces]]
 
By enabling Media Relay on the PBX, The IP800 will work as an RTP - Proxy, so all RTP Streams will travel through the IP800. This mode poses a much greater load on the PBX, so the number of concurrent calls will be heavy limited.
 
[[Image:HFO SIP Compatibility Test 4.PNG]]
 
You may wonder about the usefullness of putting the localhost address as a private network. However you must insert this entry, if the IP800 SIP GW registers at the PBX on localhost interface.
 


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.
=== Fax ===
The provider supports T.38, make sure to enable it on the SIP-interface and also on all analogue - interfaces used for fax-machines .


== Known Problems ==
HFO doesn't support NAT Traversal for clients using private addresses in 172.16.0.0/24 to 172.31.0.0/24 networks. In case that this private networks are used, STUN must be used at the RTP endpoints.  In order for NAT-Traversal using STUN to work, the [[Reference11r1:Concept_Using_PBX_services_from_public_internet#Detecting_the_NAT_style |NAT-Router must support full-cone or restricted NAT]].


[[Category:Compat|{{PAGENAME}}]]
[[Category:Compat|{{PAGENAME}}]]

Latest revision as of 14:40, 30 September 2020

Innovaphone Compatibility Test Report

Summary

SIP Provider: HFO

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

Only if the Mobility-feature or WebRTC is desired by the customer, you must enable Media-Relay on the SIP-Trunk. Opposed to a SIP trunk not needing Media-Relay, the transport of all RTP packets by the gateway will result in a higher CPU load for a call. As a result, the amount of concurrent calls is considerably lower compared to a SIP-Provider that doesn't require Media-Relay.

The provider doesn't support the G.729 coder, this might be an issue in locations with low-bandwidth Internet connection.

The PBX is connected to the provider through the public Internet, the tested product "HFO NGN Connect" comes without a dedicated Internet Access Device. According to the provider the amount of concurrent calls is limited when ordering the trunk, currently max. 220 concurrent calls are possible.

The provider offers an additional SIP-trunk product called HFO NGN Business. This product comes with a dedicated Internet Access, used only for telephony. According to HFO, it uses the same SIP server as the tested product "HFO NGN Connect". As a result, the configuration on innovaphone side should be equal. For more details on the product "HFO NGN Business", please contact the provider directly.

NAT - Detection doesn't work for all private networks, see Known Problems for more information.

That being said, the provider has achieved 92% of all possible test points. For more information on the test rating, please refer to Test Description

  • Features:
    • Direct Dial In
    • Fax over IP (T.38)
    • DTMF
    • Clip No Screening
  • Supported Codecs by the provider
    • G711
    • G722
    • T.38 UDP

Current test state

Recprod.PNG The tests for this product have been completed and it has been approved as a recommended product (Certification document).

Testing of this product has been finalized June 23th, 2015.

Testing Environment

SIPProviderTestTopology1.PNG

This scenario describes a setup where the PBX and phones are in a private network.


  • the SIP trunk is configured without Media Relay and without exclusive coder. Media-Relay must be only activated if Mobility is used.


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
SIP over TLS(SIPS) Nok
SIP over TCP Nok
SRTP Nok
call using g711a Ok
call using g711u Ok
call using g729 Nok
call using g722 Ok
Overlapped sending Nok
early media channel Ok
Fax using T.38 Ok
T.38 Transcoding by the provider Ok
Reverse Media Negotiation Ok
CGPN can be suppressed Ok
CLIP no screening Ok
Long time call possible(>30 min) Ok
External Transfer Ok
NAT Detection Ok*
Redundancy Ok
Voice Quality OK? Ok 
* NAT - Detection doesn't work for all private networks, see section  Known Problems for more information.

Direct Dial In

Tested feature Result
Inbound(Provider -> Innovaphone) Ok
Outbound(Innovaphone -> Provider) Ok
Loop In call(Innovaphone -> Provider -> Innovaphone) Ok

DTMF

Tested feature Result
DTMF tones sent correctly via RTP-events(RFC 2833) Ok
DTMF tones sent correctly via SIP-Info Nok
DTMF tones received correctly via RTP-events(RFC 2833) Ok

Hold/Retrieve

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

Transfer with consultation

Tested feature Result
Call can be transferred Ok
Held end hears music on hold Ok

The following tests are made to test if call transfer is working.

Tested feature Voice Ok? MoH Ok?
inno1 calls inno2. inno2 transfers to PSTN-phone. Ok Ok
inno1 calls PSTN-phone. inno1 transfers to inno2. Ok Ok
inno1 calls PSTN-phone. PSTN-phone transfers to inno2. Ok Ok
PSTN-phone calls inno1. inno1 transfers to inno2. Ok Ok
PSTN-phone calls inno1. PSTN-phone transfers to inno2. Ok Ok
PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2. Ok Ok

Transfer with consultation (alerting only)

Tested feature Result
Call can be transferred Ok
Held end hears music on hold or dialling tone Ok
Call returns to transferring device if the third

Endpoint is not available

Ok

The following tests are made to test if call transfer is working.

Tested feature Voice Ok? MoH Ok?
inno1 calls inno2. inno2 transfers to PSTN-phone. Ok Ok
inno1 calls PSTN-phone. inno1 transfers to inno2. Ok Ok
inno1 calls PSTN-phone. PSTN-phone transfers to inno2. Ok Ok
PSTN-phone calls inno1. inno1 transfers to inno2. Ok Ok
PSTN-phone calls inno1. PSTN-phone transfers to inno2. Ok Ok
PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2. Ok Ok

Blind Transfer

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

The following tests are made to test if call transfer is working.

Tested feature Voice Ok?
inno1 calls inno2. inno2 transfers to PSTN-phone. Ok
inno1 calls PSTN-phone. inno1 transfers to inno2. Ok
inno1 calls PSTN-phone. PSTN-phone transfers to inno2. Ok
PSTN-phone calls inno1. inno1 transfers to inno2. Ok
PSTN-phone calls inno1. PSTN-phone transfers to inno2. Ok
PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2. Ok

CFU / CFB Transfer

Tested feature Result
Call can be forwarded Ok
Held end hears dialling tone Ok

CFNR / Blind Transfer (alerting only)

Tested feature Result
Call can be transferred or forwarded Ok
Held end hears dialling tone Ok

The following tests are made to test if call transfer is working.

Tested feature Voice Ok?
inno1 calls inno2. inno2 transfers to PSTN-phone. Ok
inno1 calls PSTN-phone. PSTN-phone transfers to inno2. Ok
PSTN-phone calls inno1. inno1 transfers to inno2. Ok
PSTN-phone calls inno1. inno1 transfers to other PSTN-phone-2. Ok

Broadcast Group & Waiting Queue

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

Configuration

Firmware version

All innovaphone devices use V11r2 SR1 as firmware.

SIP - Trunk

First of all the SIP Trunk must be configured. Here an example of our HFO - Trunk. If the Mobility-feature is desired by the customer, you must enable Media-Relay on the SIP-Trunk.

HFO SIP.PNG

Number Mapping

The provider uses a CDPN in national format for incoming call. Therefore the SIP-interface maps must be configured accordingly.

HFO SIP Compatibility Test 2.PNG


Route Settings

Because HFO, 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 the automatically generated Routes.

HFO SIP Compatibility Test 3.PNG

If there is a problem with the number format, make sure to read also Howto:Create_ClipNoScreening_Maps_for_SIP_Interfaces

Fax

The provider supports T.38, make sure to enable it on the SIP-interface and also on all analogue - interfaces used for fax-machines .

Known Problems

HFO doesn't support NAT Traversal for clients using private addresses in 172.16.0.0/24 to 172.31.0.0/24 networks. In case that this private networks are used, STUN must be used at the RTP endpoints. In order for NAT-Traversal using STUN to work, the NAT-Router must support full-cone or restricted NAT.

Retrieved from "https://wiki.innovaphone.com/index.php?title=Howto:HFO_NGN_Connect_-_HFO_-_SIP_Provider&oldid=57217"