Howto:Kirk Wireless Server 300 - Polycom - SIP Test Report: Difference between revisions
(New page: ==Summary== This report describes the operation of a KWS300 as an IP gateway registered to an innovaphone PBX. Handsets used were * Gigaset S79H * Kirk 5050 a.k.a. IP55 ==Certification...) |
|||
(27 intermediate revisions by 3 users not shown) | |||
Line 3: | Line 3: | ||
* Gigaset S79H | * Gigaset S79H | ||
* Kirk 5050 a.k.a. IP55 | * Kirk 5050 a.k.a. IP55 | ||
* Kirk 4020 a.k.a. IP52 | |||
DECT performance was not part of this evaluation. | |||
Overall SIP compatibility is good. However, lack of support for registration redirects is a problem in multi-site PBX installations. Furthermore, no SRTP is supported. While this may be acceptable, calls which offer SRTP always fail. This implies that SRTP needs to be disabled for all endpoints. | |||
==Certification Status== | ==Certification Status== | ||
{{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 "tested"}} --> | <!-- {{Template:Compat Status "tested"}} --> | ||
<!-- {{Template:Compat Status "rejected"}} --> | <!-- {{Template:Compat Status "rejected"}} --> | ||
Testing of this product has been finalized May 14th, 2010. | |||
==Version== | ==Version== | ||
innovaphone PBX:<br> | innovaphone PBX:<br> | ||
IP800 8.00 | IP800 8.00 hotfix5 IP800[80500.12] | ||
KWS300:<br> | KWS300:<br> | ||
Hardware PCS10Aa<br> | Hardware PCS10Aa<br> | ||
Firmware | Firmware PCS05D_ Build 26239<br> | ||
Wireless Firmware | Wireless Firmware 26239 | ||
== Test Setup == | |||
[[Image:Kirk Wireless Server 300 - Polycom - SIP Test - Setup.PNG]] | |||
All handset related tests were done with IP55! | |||
==Device Setup== | ==Device Setup== | ||
Device is setup is straight forward with the documentation at hand. | |||
{| border="1" | {| border="1" | ||
Line 37: | Line 44: | ||
|---- | |---- | ||
|Register Device w/o specific configuration (requires DHCP) | |Register Device w/o specific configuration (requires DHCP) | ||
| | | No, no discovery/registration multicast | ||
|---- | |---- | ||
|DHCP is default | |DHCP is default | ||
| | | yes | ||
|---- | |---- | ||
|DHCP yields | |DHCP yields time-server and time displays correctly | ||
| | | yes. | ||
|---- | |---- | ||
|SNTP config has TZ string for timezone/dst autoconfig | |SNTP config has TZ string for timezone/dst autoconfig | ||
| | | yes | ||
|---- | |---- | ||
|DHCP yields correct default gateway | |DHCP yields correct default gateway | ||
| | | yes | ||
|---- | |---- | ||
|Device supports magic registration (e.g. by serial) | |Device supports magic registration (e.g. by serial) | ||
| | | yes, with limitation. <internal>Auto-creation of users creates <code>IPEIxxxxxxx</code> as registration name which can be used as device name in PBX config. Limitation: user are initially disabled, requires manual intervention in DUT configuration UI.</internal> | ||
|---- | |---- | ||
|Fixed registrations works | |Fixed registrations works | ||
| | |yes | ||
|---- | |---- | ||
|Device registers w/o Extension (just by name) | |Device registers w/o Extension (just by name) | ||
| | |yes | ||
|---- | |---- | ||
|Device registers by extension | |Device registers by extension | ||
| | |yes | ||
|---- | |---- | ||
|Device registers with password | |Device registers with password | ||
| | |yes, with limitations. Does not work with auto-creation of users. | ||
|---- | |---- | ||
|Device registers multiple identities | |Device registers multiple identities | ||
| | | Yes | ||
|---- | |---- | ||
|Device supports STUN protocol | |Device supports STUN protocol | ||
| | | not tested | ||
|---- | |---- | ||
|Device sends NAT - keepalive messages | |Device sends NAT - keepalive messages | ||
| | | not tested | ||
|---- | |---- | ||
|Device refreshes the PBX registration | |Device refreshes the PBX registration | ||
| | | yes | ||
|---- | |---- | ||
|Device supports SIP over TCP | |Device supports SIP over TCP | ||
| | | no | ||
|---- | |---- | ||
|Device supports SRTP | |Device supports SRTP | ||
| | | no | ||
|---- | |---- | ||
|Device supports SIPS (SIP over TLS) | |Device supports SIPS (SIP over TLS) | ||
| | | no | ||
|---- | |---- | ||
|Device supports HTTPS | |Device supports HTTPS | ||
| | | yes, with limitations. UI works with https. No https when retrieving provisioning files <internal>(''Download: 'https://172.16.10.62/kws300.config/0013d180216d-config.xml' - tftp: https: Unknown host''</internal> | ||
|---- | |---- | ||
|Device supports VAD (Voice activity detection) | |Device supports VAD (Voice activity detection) | ||
| | | not configurable | ||
|---- | |---- | ||
|Supported menu languages | |Supported menu languages | ||
| | | English | ||
|} | |} | ||
Line 106: | Line 113: | ||
|---- | |---- | ||
|call using g711a | |call using g711a | ||
| | | yes | ||
|---- | |---- | ||
|call using g711u | |call using g711u | ||
| | | yes | ||
|---- | |---- | ||
|call using g729 | |call using g729 | ||
| | | not supported | ||
|---- | |---- | ||
|Overlapped sending | |Overlapped sending | ||
| | | No | ||
|---- | |---- | ||
|Early media channel | |Early media channel | ||
| | | Yes | ||
|---- | |---- | ||
|Device shows called id number | |Device shows called id number | ||
| | | yes | ||
|---- | |---- | ||
|Device shows called id name | |Device shows called id name | ||
| | | No | ||
|---- | |---- | ||
|Device shows called id display info | |Device shows called id display info | ||
| | | No | ||
|---- | |---- | ||
|Fax using T.38 | |Fax using T.38 | ||
| | | n/a | ||
|---- | |---- | ||
|CGPN can be supressed | |CGPN can be supressed | ||
| | | No | ||
|---- | |---- | ||
|Reverse Media Negotiaton | |Reverse Media Negotiaton | ||
| | | yes | ||
|---- | |---- | ||
|Device shows CDPN/CGPN on incoming call | |Device shows CDPN/CGPN on incoming call | ||
| | | yes | ||
|---- | |---- | ||
|Device shows CDPN/CGPN on outgoing call | |Device shows CDPN/CGPN on outgoing call | ||
| | | no, CDPN only | ||
|---- | |---- | ||
|Device shows connected number | |Device shows connected number | ||
| | | no, originally typed number remains <internal>(DUT calls to 30, cfu to 20, 20 picks, phone shows ''connected to 20'')</internal> | ||
|---- | |---- | ||
|Device shows diverting number | |Device shows diverting number | ||
| | | no | ||
|---- | |---- | ||
|Device supports distinctive ringing | |Device supports distinctive ringing | ||
| | | not tested | ||
|---- | |---- | ||
|Device supports | |Device supports asymmetric codec negotiation | ||
| | | not tested | ||
|---- | |---- | ||
|Device supports codec renegotiation during a conversation | |Device supports codec renegotiation during a conversation | ||
| | | no (e.g. renegotiation from g711a to g711u for MOH fails) | ||
|---- | |---- | ||
|Device shows correct display message in case of busy CDPN | |Device shows correct display message in case of busy CDPN | ||
| | | yes | ||
|---- | |---- | ||
|Device shows correct display message in case of not existing CDPN | |Device shows correct display message in case of not existing CDPN | ||
| | | yes (not found) | ||
|---- | |---- | ||
|Device shows correct display message in case that the call is declined | |Device shows correct display message in case that the call is declined | ||
| | | yes (busy) | ||
|---- | |---- | ||
|SOAP Call works? | |SOAP Call works? | ||
| | | yes (outgoing) | ||
|---- | |---- | ||
|Device supports display updates during call(needed for Directory Search object) | |Device supports display updates during call(needed for Directory Search object) | ||
| | | no | ||
|---- | |---- | ||
|Long Time Call (>30 min) works? | |Long Time Call (>30 min) works? | ||
| | | yes | ||
|---- | |---- | ||
|Voice Quality OK? | |Voice Quality OK? | ||
| | | yes | ||
|- | |||
| SRTP call to DUT | |||
| no | |||
|- | |||
| SRTP call from DUT | |||
| no (SRTP not supported) | |||
|} | |} | ||
Line 188: | Line 201: | ||
|---- | |---- | ||
|DTMF tones sent correctly | |DTMF tones sent correctly | ||
| | | yes | ||
|---- | |---- | ||
|DTMF tones received correctly | |DTMF tones received correctly | ||
| | | no (no incoming DTMF tones are presented to user) | ||
|} | |} | ||
Line 202: | Line 215: | ||
|---- | |---- | ||
|Device handles incoming hold correctly | |Device handles incoming hold correctly | ||
| | | yes | ||
|---- | |---- | ||
|Device can put a call on hold | |Device can put a call on hold correctly(inactive or sendonly) | ||
| | | yes | ||
|} | |} | ||
Line 216: | Line 229: | ||
|---- | |---- | ||
|inno1 calls inno2. inno2 transfers to testphone. | |inno1 calls inno2. inno2 transfers to testphone. | ||
| | | yes <internal>display info not updated on the testphone</internal> | ||
| | | | ||
|---- | |---- | ||
||inno1 calls inno2. inno1 transfers to testphone. | ||inno1 calls inno2. inno1 transfers to testphone. | ||
| | | yes | ||
| | | | ||
|---- | |---- | ||
|inno1 calls testphone. inno1 transfers to inno2. | |inno1 calls testphone. inno1 transfers to inno2. | ||
| | |yes | ||
| | | yes | ||
|---- | |---- | ||
|inno1 calls testphone. testphone transfers to inno2. | |inno1 calls testphone. testphone transfers to inno2. | ||
| | | yes | ||
| | | | ||
|---- | |---- | ||
|testphone calls inno1. inno1 transfers to inno2. | |testphone calls inno1. inno1 transfers to inno2. | ||
| | | yes | ||
| | | yes | ||
|---- | |---- | ||
|testphone calls inno1. testphone transfers to inno2. | |testphone calls inno1. testphone transfers to inno2. | ||
| | | yes | ||
| | | | ||
|} | |} | ||
Line 248: | Line 261: | ||
|---- | |---- | ||
|inno1 calls inno2. inno2 transfers to testphone. | |inno1 calls inno2. inno2 transfers to testphone. | ||
| | | yes | ||
| | | | ||
|---- | |---- | ||
||inno1 calls inno2. inno1 transfers to testphone. | ||inno1 calls inno2. inno1 transfers to testphone. | ||
| | | yes | ||
| | | | ||
|---- | |---- | ||
|inno1 calls testphone. inno1 transfers to inno2. | |inno1 calls testphone. inno1 transfers to inno2. | ||
| | | yes | ||
| | | yes | ||
|---- | |---- | ||
|inno1 calls testphone. testphone transfers to inno2. | |inno1 calls testphone. testphone transfers to inno2. | ||
| | | no <internal>(DUT looks like it terminated the call, but calls still exists in PBX. Subsequent calls fail). <code>consxfer-alerting-only-inno1 calls testphone-testphone transfers to inno2.cap</code></internal> | ||
| | | | ||
|---- | |---- | ||
|testphone calls inno1. inno1 transfers to inno2. | |testphone calls inno1. inno1 transfers to inno2. | ||
| | | yes | ||
| | | yes | ||
|---- | |---- | ||
|testphone calls inno1. testphone transfers to inno2. | |testphone calls inno1. testphone transfers to inno2. | ||
| | | no (see above) | ||
| | | | ||
|} | |} | ||
Line 279: | Line 292: | ||
|---- | |---- | ||
|inno1 calls inno2. inno2 transfers to testphone. | |inno1 calls inno2. inno2 transfers to testphone. | ||
| | | yes | ||
|---- | |---- | ||
||inno1 calls inno2. inno1 transfers to testphone. | ||inno1 calls inno2. inno1 transfers to testphone. | ||
| | | yes | ||
|---- | |---- | ||
|inno1 calls testphone. inno1 transfers to inno2. | |inno1 calls testphone. inno1 transfers to inno2. | ||
| | | yes | ||
|---- | |---- | ||
|inno1 calls testphone. testphone transfers to inno2. | |inno1 calls testphone. testphone transfers to inno2. | ||
| | | n/a | ||
|---- | |---- | ||
|testphone calls inno1. inno1 transfers to inno2. | |testphone calls inno1. inno1 transfers to inno2. | ||
| | | yes | ||
|---- | |---- | ||
|testphone calls inno1. testphone transfers to inno2. | |testphone calls inno1. testphone transfers to inno2. | ||
| | | n/a | ||
|} | |} | ||
Line 304: | Line 317: | ||
|---- | |---- | ||
|inno1 calls inno2. inno2 transfers to testphone. | |inno1 calls inno2. inno2 transfers to testphone. | ||
| | | yes | ||
|---- | |---- | ||
|inno1 calls testphone. testphone transfers to inno2. | |inno1 calls testphone. testphone transfers to inno2. | ||
| | | n/a | ||
|---- | |---- | ||
|testphone calls inno1. inno1 transfers to inno2. | |testphone calls inno1. inno1 transfers to inno2. | ||
| | | yes | ||
|} | |} | ||
Line 320: | Line 333: | ||
|---- | |---- | ||
|testphone makes call to a Broadcast Group. inno1 picks up. | |testphone makes call to a Broadcast Group. inno1 picks up. | ||
| | | ok | ||
|---- | |---- | ||
|inno1 makes call to a Broadcast Group. testphone picks up. | |inno1 makes call to a Broadcast Group. testphone picks up. | ||
| | | ok | ||
|---- | |---- | ||
|testphone makes call to a Waiting Queue. inno1 picks up before announcement is played. | |testphone makes call to a Waiting Queue. inno1 picks up before announcement is played. | ||
| | | ok | ||
|---- | |---- | ||
|testphone makes call to a Waiting Queue. inno1 picks up after announcement is played. | |testphone makes call to a Waiting Queue. inno1 picks up after announcement is played. | ||
| | | ok | ||
|---- | |---- | ||
||inno1 makes call to a Waiting Queue. testphone picks up. | ||inno1 makes call to a Waiting Queue. testphone picks up. | ||
| | | ok | ||
|} | |} | ||
Line 346: | Line 359: | ||
|---- | |---- | ||
|Exists | |Exists | ||
| | | yes | ||
|---- | |---- | ||
|Can be dialled from | |Can be dialled from | ||
| | | not tested <internal>(could not be tested, phone freezed whenever accessing the internal phone book)</internal> | ||
|---- | |---- | ||
|Does CLI resolution | |Does CLI resolution | ||
| | | not tested | ||
|- | |||
|PBX Directory Object | |||
|- | |||
|Device shows Display Info Feedback (current selected user) | |||
| no | |||
|} | |} | ||
=== | == Configuration == | ||
=== innovaphone configuration === | |||
There is no special configuration required on PBX side. Each single DECT user must be present in PBX. Password may be used but needs to be set manually then in the KWS300 (default password does not work). | |||
=== 3rd party product configuration === | |||
==== Configuration / SIP ==== | |||
* ''Default Domain'' must be set to the PBX's ''System Name'' | |||
* ''Registration expire(sec)'' should be set to a short period, we recommend 60 (the lowest value allowed by the UI) | |||
* ''Proxy 1'' must be set to the master/primary PBX | |||
* ''Proxy 2'' must be set to the standby/secondary PBX | |||
* ''Play on hold tone'' must be switched off | |||
Anything else can be left as defaults. | |||
[[Image:Kirk Wireless Server 300 - Polycom - SIP Test Report-1.png]] | |||
==== Configuration / Wireless ==== | |||
* ''Authenticate Calls'' needs to be turned on | |||
* For auto-deployment, ''Subscription allowed'' and ''Autocreate users'' should be turned on | |||
[[Image:Kirk Wireless Server 300 - Polycom - SIP Test Report-2.png]] | |||
== Documents == | |||
[[Media:KIRK2010_Handset_Subscription_Guide_for_KIRK_Wireless_Server_300.pdf]] | |||
[[Media:KWS300_insta_config_guide.pdf]] | |||
[[Media:Provisioning_guide_KWS300_6000.pdf]] | |||
<internal> | |||
<h2> Internal Remarks </h2> | |||
<h3>In-House Test Setup </h3> | |||
<h4>KWS 300</h4> | |||
ARI 000046572042 [00 04 d7 a1 10] | |||
Config UI: http://172.16.0.49 (<code>admin, kws300</code> default) | |||
<h3>Observations</h3> | |||
; Device Discovery (unclear): DHCP Server -> find IP Address (MAC on label) -> account (default): admin/kws300. Looks as if the idea is to discover the devices IP address via UPnP. | |||
; UPnP : there is a "UPnP" flag : unclear what this does (apparently device discovery should be done so, unclear how) | |||
; UI/config params: does not show its own IP, shows only configured values, not those received by DHCP | |||
; Log: Log files and config can be retrieved from the box as a .tar file :-) (config, logs, sysinfo as a file tree). | |||
; Remote Log : Remote logging possible to a syslog server | |||
; NTP : NTP works and is configured from DHCP. | |||
; Wireshark : packet capture is possible, but is stored internally and needs to be retrieved later from the box (via download). No "endless" capturing via rpcap. | |||
; Feature Codes : there are only two which are triggered via DTMF sequences (configurable). CFU enable and CFU disable ;-) Should be obsolete in favor of PBX DTFM feature object (not tested) | |||
; SIP transport: strange choice: either "UDP only" or "DNS SRV" (ist in jedem Fall UDP) | |||
; SIP proxy: 4 proxies can be defined | |||
; time : doesn't seem to send current to Gigaset handset when it registers (non-issue, works with Polycom handsets) | |||
; display name : SIP display name can be set, but does not have an effect with us (as we obviously override the display name on calls). When registered as gateway, the display name set in the KWS300 works fine | |||
; Re-registration : looks as if by default re-registrations timeouts are very long (''Registration expire(sec)'' is by default 3600s!). If e.g. the master reboots, this is not detected, even if a call is attempted and fails. No re-registration is tried in this case. Minimum expire time allowed is 60s which yields acceptable behaviour. | |||
; user synchronization : can be done via xml-file retrieval. Can be triggered through a SIP call or done on a regular basis. XML data includes password in clear, no HTTPS supported for retrieval. Questionable. | |||
; user provisioning : user settings can be changed (via http retrieval of user xml data) without disturbing current registration or calls | |||
; user provisioning : there is a race condition when an auto-created user is available and not yet registered with the PBX. KWS will then retrieve (e.g. on a per-minute base) the current user database which does not include the new user so it gets removed from KWS. | |||
<h3>Subscription</h3> | |||
Easy. | |||
* Enable Subscriptions (''Configuration / Wireless Server / Subscription allowed'') and Autocreation of users (''Configuration / Wireless Server / Autocreate users'')on KWS300 | |||
* Search base on handset, subscribe, works right away | |||
* If necessary, change user id (''Users / List Users / Username / Extension'') to match PBX name or number | |||
* Enable user in KWS300 user list! | |||
Authentication: | |||
* User may have a password and the password works (except if the user name contains an umlaut, see bugs below) | |||
* SIP config allows to set a default SIP authentication password. Doesn't work though (inconsistent authentication used for registrations and calls) | |||
Devices: | |||
* registering with the default user name generated during subscription (<code>IPEIxxx</code>) works | |||
Autosubscription is sort of simple: | |||
* handsets subscribes with base with subscription and auto-creation of user enabled | |||
* auto-generated user name based on IPEI sent to PBX | |||
* admin adds this name to the devices list of the repsective user | |||
Autosubscription with ''zero admin deployment'' is even simpler | |||
* handsets subscribes with base with subscription and auto-creation of user enabled | |||
* auto-generated user name based on IPEI sent to PBX | |||
* name unknown, so device is registered as ''UNKNWOWN'' | |||
* user calls own extension | |||
Unfortunately, there are 2 issues which make it more or less useless: a) users are initially disabled b) passwords (which practically are required) must be set individually | |||
= | <h3> Bugs found </h3> | ||
; SIP user name : no umlaut possible in user name. Is entirely removed from config form | |||
; Authenticated registrations : do not work always. Registration works, but subsequent calls fail. This depends on how the password and authenticating user is configured according to the following table | |||
<table border=1> | |||
<tr> | |||
<td> Configuration / SIP / Default password </td><td> User / Authentication user </td><td> User / Authentication password </td><td> Registration </td><td>Call from DECT </td><td> Call to DECT </td> | |||
<tr> | |||
<td> ''empty'' </td><td> same as ''Username / Extension'' </td><td> password </td><td> works </td><td> works </td><td> works</td> | |||
<tr> | |||
<td> ''empty'' </td><td> different but valid device name </td><td> password </td><td> works </td><td> Error 407, <code>auth-reg-call-fail-1.pcap</code> </td><td>works</td> | |||
<tr> | |||
<td> ''empty'' </td><td> ''empty'' </td><td> password </td><td> fails, <code>auth-reg-call-fail-2.pcap</code> </td> | |||
<tr> | |||
<td> password </td><td> ''empty'' </td><td> ''empty'' </td><td> works </td><td> Error 407, <code>auth-reg-call-fail-3.pcap</code> </td><td> works </td> | |||
<tr> | |||
<td> password </td><td> ''empty'' </td><td> same as ''Username / Extension'' </td><td> Error 407, <code>auth-reg-call-fail-4.pcap</code> </td> | |||
</table> | |||
The only way authenticated registrations work is with explicit configuration of user/password for each user. So no auto-deployment is possible. The reason for these problems is that the KWS300 sends the value configured in ''Configuration / Sip /Default user'' (<code>someone</code>) (which is marked as a mandatory field) as ''username'' | |||
<pre> | |||
Proxy-Authorization: Digest | |||
username="someone", | |||
realm="172.16.10.62", | |||
nonce="a8c263cbe909d311", | |||
uri="sip:20@172.16.10.62", | |||
response="94312ca7a9347c809d68163bcd181a18", | |||
algorithm=MD5, | |||
cnonce="23ba7bba", | |||
qop=auth, | |||
nc=00000001 | |||
</pre> | |||
It should rather allow an empty value for both ''Configuration / Sip / Default user'' and ''User / Authentication user'' and if both are empty use the value in ''User / Username / Extension'' for authentication. This would enable ''zero-administration-deployment'' with a shared password (taken from ''Configuration / Sip / Default password''). | |||
; auto creation of users : after auto-creation, the new user entry is disabled. This defeats the purpose of zero-administration-deployment | |||
; reboot : does not unregister endpoints on reboot. This creates unsynchronized situations prior to the registration timeout for the previously subscribed users (doubled registrations) | |||
; unregistrations : unregistrations received from the PBX are not handled correctly. The user list on the KWS300 still lists the user as "registered". | |||
; registration redirects : are done using SIP 301 Status responses. Doesn't seem to be implemented in KWS300. While this is not a show-stopper for normal SIP endpoints, it is one for DECT gateways as these will send registrations of all base users to the same PBX. As a result, with KWS300, all users ''must'' be registered on the same single PBX | |||
; authentication with umlaut : works for registration, but does not work for calls (<code>umlaut-reg-ok-call-notok.cap</code>). | |||
; HTTP client : If user provisioning should be used, there must be a mechanism to retrieve the XML user file encrypted and password protected, that is, HTTP authentication and HTTPS must be supported. Otherwise user password are sent in clear over the network and can be retrieved by anyone without access protection (HTTP password) | |||
<h3>Suggested Enhancements</h3> | |||
; DECT idle state name (standby text) : is set to the IPEI when auto-creating a user. Should be left empty and set to the first type 1 <code>P-Alias:</code> registration return code that is not the IPEI (a.k.a. registration user). We send this in the registration response | |||
<pre> | |||
Status-Line: SIP/2.0 200 OK | |||
P-Alias: 1,17,IPEI0275009881422 | |||
P-Alias: 1,8,DECT%F61 | |||
P-Alias: 0,2,11 | |||
</pre> | |||
<h3>Potential innovaphone Software Enhancements</h3> | |||
; syslogd : sends log messages to a syslog server. We should have one as a LOG sink to be able to concentrate log messages | |||
; provisioning : KWS300 can retrieve user data from an .xml file using http. This can be done manually, or be polled every x minutes of triggered using a special SIP call (see chapter ''3.2.2 SIP NOTIFY check-sync'' in the provisioning guide (<code>Provisioning_guide_KWS300_6000.pdf</code>). | |||
; provisioning : built-in DHCP server should support option 66 for provisioning URL (for config) | |||
; user provisioning : automated user provisioning is not strictly required as the only data that needs to be synchronized is the handsets IPEI which is used as registration name. This is generated during KWS user auto-creation and then passed to the PBX using zero-administration-deployment. It then will never change again. The idle display text is usually set different from the users display name, it can thus be set in the KWS UI anyway. So there is no need to sync. However, for this scheme to work, PBX must allow an unauthenticated registration per configured device, not per user. Also, zero-administration-deployment does not work for user which already have a registration (twin-phone scenario).<br> | |||
</internal> | |||
< |
Latest revision as of 15:05, 23 August 2012
Summary
This report describes the operation of a KWS300 as an IP gateway registered to an innovaphone PBX. Handsets used were
- Gigaset S79H
- Kirk 5050 a.k.a. IP55
- Kirk 4020 a.k.a. IP52
DECT performance was not part of this evaluation.
Overall SIP compatibility is good. However, lack of support for registration redirects is a problem in multi-site PBX installations. Furthermore, no SRTP is supported. While this may be acceptable, calls which offer SRTP always fail. This implies that SRTP needs to be disabled for all endpoints.
Certification Status
The tests for this product have been completed.
Testing of this product has been finalized May 14th, 2010.
Version
innovaphone PBX:
IP800 8.00 hotfix5 IP800[80500.12]
KWS300:
Hardware PCS10Aa
Firmware PCS05D_ Build 26239
Wireless Firmware 26239
Test Setup
All handset related tests were done with IP55!
Device Setup
Device is setup is straight forward with the documentation at hand.
Tested feature | Result |
---|---|
Register Device w/o specific configuration (requires DHCP) | No, no discovery/registration multicast |
DHCP is default | yes |
DHCP yields time-server and time displays correctly | yes. |
SNTP config has TZ string for timezone/dst autoconfig | yes |
DHCP yields correct default gateway | yes |
Device supports magic registration (e.g. by serial) | yes, with limitation. <internal>Auto-creation of users creates IPEIxxxxxxx as registration name which can be used as device name in PBX config. Limitation: user are initially disabled, requires manual intervention in DUT configuration UI.</internal>
|
Fixed registrations works | yes |
Device registers w/o Extension (just by name) | yes |
Device registers by extension | yes |
Device registers with password | yes, with limitations. Does not work with auto-creation of users. |
Device registers multiple identities | Yes |
Device supports STUN protocol | not tested |
Device sends NAT - keepalive messages | not tested |
Device refreshes the PBX registration | yes |
Device supports SIP over TCP | no |
Device supports SRTP | no |
Device supports SIPS (SIP over TLS) | no |
Device supports HTTPS | yes, with limitations. UI works with https. No https when retrieving provisioning files <internal>(Download: 'https://172.16.10.62/kws300.config/0013d180216d-config.xml' - tftp: https: Unknown host</internal> |
Device supports VAD (Voice activity detection) | not configurable |
Supported menu languages | English |
Test Results
Basic Call
Tested feature | Result |
---|---|
call using g711a | yes |
call using g711u | yes |
call using g729 | not supported |
Overlapped sending | No |
Early media channel | Yes |
Device shows called id number | yes |
Device shows called id name | No |
Device shows called id display info | No |
Fax using T.38 | n/a |
CGPN can be supressed | No |
Reverse Media Negotiaton | yes |
Device shows CDPN/CGPN on incoming call | yes |
Device shows CDPN/CGPN on outgoing call | no, CDPN only |
Device shows connected number | no, originally typed number remains <internal>(DUT calls to 30, cfu to 20, 20 picks, phone shows connected to 20)</internal> |
Device shows diverting number | no |
Device supports distinctive ringing | not tested |
Device supports asymmetric codec negotiation | not tested |
Device supports codec renegotiation during a conversation | no (e.g. renegotiation from g711a to g711u for MOH fails) |
Device shows correct display message in case of busy CDPN | yes |
Device shows correct display message in case of not existing CDPN | yes (not found) |
Device shows correct display message in case that the call is declined | yes (busy) |
SOAP Call works? | yes (outgoing) |
Device supports display updates during call(needed for Directory Search object) | no |
Long Time Call (>30 min) works? | yes |
Voice Quality OK? | yes |
SRTP call to DUT | no |
SRTP call from DUT | no (SRTP not supported) |
DTMF
Tested feature | Result |
---|---|
DTMF tones sent correctly | yes |
DTMF tones received correctly | no (no incoming DTMF tones are presented to user) |
Hold/Retrieve
Tested feature | Result |
---|---|
Device handles incoming hold correctly | yes |
Device can put a call on hold correctly(inactive or sendonly) | yes |
Transfer with consultation
Tested feature | Voice Ok? | MoH Ok? |
---|---|---|
inno1 calls inno2. inno2 transfers to testphone. | yes <internal>display info not updated on the testphone</internal> | |
inno1 calls inno2. inno1 transfers to testphone. | yes | |
inno1 calls testphone. inno1 transfers to inno2. | yes | yes |
inno1 calls testphone. testphone transfers to inno2. | yes | |
testphone calls inno1. inno1 transfers to inno2. | yes | yes |
testphone calls inno1. testphone transfers to inno2. | yes |
Transfer with consultation (alerting only)
Tested feature | Voice Ok? | MoH Ok? |
---|---|---|
inno1 calls inno2. inno2 transfers to testphone. | yes | |
inno1 calls inno2. inno1 transfers to testphone. | yes | |
inno1 calls testphone. inno1 transfers to inno2. | yes | yes |
inno1 calls testphone. testphone transfers to inno2. | no <internal>(DUT looks like it terminated the call, but calls still exists in PBX. Subsequent calls fail). consxfer-alerting-only-inno1 calls testphone-testphone transfers to inno2.cap </internal>
|
|
testphone calls inno1. inno1 transfers to inno2. | yes | yes |
testphone calls inno1. testphone transfers to inno2. | no (see above) |
Blind Transfer
Tested feature | Voice Ok? |
---|---|
inno1 calls inno2. inno2 transfers to testphone. | yes |
inno1 calls inno2. inno1 transfers to testphone. | yes |
inno1 calls testphone. inno1 transfers to inno2. | yes |
inno1 calls testphone. testphone transfers to inno2. | n/a |
testphone calls inno1. inno1 transfers to inno2. | yes |
testphone calls inno1. testphone transfers to inno2. | n/a |
Blind Transfer (alerting only)
Tested feature | Voice Ok? |
---|---|
inno1 calls inno2. inno2 transfers to testphone. | yes |
inno1 calls testphone. testphone transfers to inno2. | n/a |
testphone calls inno1. inno1 transfers to inno2. | yes |
Broadcast Group & Waiting Queue
Tested feature | Result |
---|---|
testphone makes call to a Broadcast Group. inno1 picks up. | ok |
inno1 makes call to a Broadcast Group. testphone picks up. | ok |
testphone makes call to a Waiting Queue. inno1 picks up before announcement is played. | ok |
testphone makes call to a Waiting Queue. inno1 picks up after announcement is played. | ok |
inno1 makes call to a Waiting Queue. testphone picks up. | ok |
Other Features
Directory
Tested feature | Result |
---|---|
Device built-in directory | |
Exists | yes |
Can be dialled from | not tested <internal>(could not be tested, phone freezed whenever accessing the internal phone book)</internal> |
Does CLI resolution | not tested |
PBX Directory Object | |
Device shows Display Info Feedback (current selected user) | no |
Configuration
innovaphone configuration
There is no special configuration required on PBX side. Each single DECT user must be present in PBX. Password may be used but needs to be set manually then in the KWS300 (default password does not work).
3rd party product configuration
Configuration / SIP
- Default Domain must be set to the PBX's System Name
- Registration expire(sec) should be set to a short period, we recommend 60 (the lowest value allowed by the UI)
- Proxy 1 must be set to the master/primary PBX
- Proxy 2 must be set to the standby/secondary PBX
- Play on hold tone must be switched off
Anything else can be left as defaults.
Configuration / Wireless
- Authenticate Calls needs to be turned on
- For auto-deployment, Subscription allowed and Autocreate users should be turned on
Documents
Media:KIRK2010_Handset_Subscription_Guide_for_KIRK_Wireless_Server_300.pdf
Media:KWS300_insta_config_guide.pdf
Media:Provisioning_guide_KWS300_6000.pdf
<internal>
Internal Remarks
In-House Test Setup
KWS 300
ARI 000046572042 [00 04 d7 a1 10]
Config UI: http://172.16.0.49 (admin, kws300
default)
Observations
- Device Discovery (unclear)
- DHCP Server -> find IP Address (MAC on label) -> account (default): admin/kws300. Looks as if the idea is to discover the devices IP address via UPnP.
- UPnP
- there is a "UPnP" flag : unclear what this does (apparently device discovery should be done so, unclear how)
- UI/config params
- does not show its own IP, shows only configured values, not those received by DHCP
- Log
- Log files and config can be retrieved from the box as a .tar file :-) (config, logs, sysinfo as a file tree).
- Remote Log
- Remote logging possible to a syslog server
- NTP
- NTP works and is configured from DHCP.
- Wireshark
- packet capture is possible, but is stored internally and needs to be retrieved later from the box (via download). No "endless" capturing via rpcap.
- Feature Codes
- there are only two which are triggered via DTMF sequences (configurable). CFU enable and CFU disable ;-) Should be obsolete in favor of PBX DTFM feature object (not tested)
- SIP transport
- strange choice: either "UDP only" or "DNS SRV" (ist in jedem Fall UDP)
- SIP proxy
- 4 proxies can be defined
- time
- doesn't seem to send current to Gigaset handset when it registers (non-issue, works with Polycom handsets)
- display name
- SIP display name can be set, but does not have an effect with us (as we obviously override the display name on calls). When registered as gateway, the display name set in the KWS300 works fine
- Re-registration
- looks as if by default re-registrations timeouts are very long (Registration expire(sec) is by default 3600s!). If e.g. the master reboots, this is not detected, even if a call is attempted and fails. No re-registration is tried in this case. Minimum expire time allowed is 60s which yields acceptable behaviour.
- user synchronization
- can be done via xml-file retrieval. Can be triggered through a SIP call or done on a regular basis. XML data includes password in clear, no HTTPS supported for retrieval. Questionable.
- user provisioning
- user settings can be changed (via http retrieval of user xml data) without disturbing current registration or calls
- user provisioning
- there is a race condition when an auto-created user is available and not yet registered with the PBX. KWS will then retrieve (e.g. on a per-minute base) the current user database which does not include the new user so it gets removed from KWS.
Subscription
Easy.
- Enable Subscriptions (Configuration / Wireless Server / Subscription allowed) and Autocreation of users (Configuration / Wireless Server / Autocreate users)on KWS300
- Search base on handset, subscribe, works right away
- If necessary, change user id (Users / List Users / Username / Extension) to match PBX name or number
- Enable user in KWS300 user list!
Authentication:
- User may have a password and the password works (except if the user name contains an umlaut, see bugs below)
- SIP config allows to set a default SIP authentication password. Doesn't work though (inconsistent authentication used for registrations and calls)
Devices:
- registering with the default user name generated during subscription (
IPEIxxx
) works
Autosubscription is sort of simple:
- handsets subscribes with base with subscription and auto-creation of user enabled
- auto-generated user name based on IPEI sent to PBX
- admin adds this name to the devices list of the repsective user
Autosubscription with zero admin deployment is even simpler
- handsets subscribes with base with subscription and auto-creation of user enabled
- auto-generated user name based on IPEI sent to PBX
- name unknown, so device is registered as UNKNWOWN
- user calls own extension
Unfortunately, there are 2 issues which make it more or less useless: a) users are initially disabled b) passwords (which practically are required) must be set individually
Bugs found
- SIP user name
- no umlaut possible in user name. Is entirely removed from config form
- Authenticated registrations
- do not work always. Registration works, but subsequent calls fail. This depends on how the password and authenticating user is configured according to the following table
Configuration / SIP / Default password | User / Authentication user | User / Authentication password | Registration | Call from DECT | Call to DECT |
empty | same as Username / Extension | password | works | works | works |
empty | different but valid device name | password | works | Error 407, auth-reg-call-fail-1.pcap | works |
empty | empty | password | fails, auth-reg-call-fail-2.pcap |
||
password | empty | empty | works | Error 407, auth-reg-call-fail-3.pcap | works |
password | empty | same as Username / Extension | Error 407, auth-reg-call-fail-4.pcap |
The only way authenticated registrations work is with explicit configuration of user/password for each user. So no auto-deployment is possible. The reason for these problems is that the KWS300 sends the value configured in Configuration / Sip /Default user (someone
) (which is marked as a mandatory field) as username
Proxy-Authorization: Digest username="someone", realm="172.16.10.62", nonce="a8c263cbe909d311", uri="sip:20@172.16.10.62", response="94312ca7a9347c809d68163bcd181a18", algorithm=MD5, cnonce="23ba7bba", qop=auth, nc=00000001
It should rather allow an empty value for both Configuration / Sip / Default user and User / Authentication user and if both are empty use the value in User / Username / Extension for authentication. This would enable zero-administration-deployment with a shared password (taken from Configuration / Sip / Default password).
- auto creation of users
- after auto-creation, the new user entry is disabled. This defeats the purpose of zero-administration-deployment
- reboot
- does not unregister endpoints on reboot. This creates unsynchronized situations prior to the registration timeout for the previously subscribed users (doubled registrations)
- unregistrations
- unregistrations received from the PBX are not handled correctly. The user list on the KWS300 still lists the user as "registered".
- registration redirects
- are done using SIP 301 Status responses. Doesn't seem to be implemented in KWS300. While this is not a show-stopper for normal SIP endpoints, it is one for DECT gateways as these will send registrations of all base users to the same PBX. As a result, with KWS300, all users must be registered on the same single PBX
- authentication with umlaut
- works for registration, but does not work for calls (
umlaut-reg-ok-call-notok.cap
). - HTTP client
- If user provisioning should be used, there must be a mechanism to retrieve the XML user file encrypted and password protected, that is, HTTP authentication and HTTPS must be supported. Otherwise user password are sent in clear over the network and can be retrieved by anyone without access protection (HTTP password)
Suggested Enhancements
- DECT idle state name (standby text)
- is set to the IPEI when auto-creating a user. Should be left empty and set to the first type 1
P-Alias:
registration return code that is not the IPEI (a.k.a. registration user). We send this in the registration response
Status-Line: SIP/2.0 200 OK P-Alias: 1,17,IPEI0275009881422 P-Alias: 1,8,DECT%F61 P-Alias: 0,2,11
Potential innovaphone Software Enhancements
- syslogd
- sends log messages to a syslog server. We should have one as a LOG sink to be able to concentrate log messages
- provisioning
- KWS300 can retrieve user data from an .xml file using http. This can be done manually, or be polled every x minutes of triggered using a special SIP call (see chapter 3.2.2 SIP NOTIFY check-sync in the provisioning guide (
Provisioning_guide_KWS300_6000.pdf
). - provisioning
- built-in DHCP server should support option 66 for provisioning URL (for config)
- user provisioning
- automated user provisioning is not strictly required as the only data that needs to be synchronized is the handsets IPEI which is used as registration name. This is generated during KWS user auto-creation and then passed to the PBX using zero-administration-deployment. It then will never change again. The idle display text is usually set different from the users display name, it can thus be set in the KWS UI anyway. So there is no need to sync. However, for this scheme to work, PBX must allow an unauthenticated registration per configured device, not per user. Also, zero-administration-deployment does not work for user which already have a registration (twin-phone scenario).
</internal>