Howto:Kirk Wireless Server 300 - Polycom - SIP Test Report
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
File:Kirk Wireless Server 300 - Polycom - SIP Test Report - Wireless Config.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>
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>