Suite 300, One Bentall Centre 505 Burrard Street, Box 95 Vancouver, BC V7X 1M3 Canada
Telephone: +1.604.320.3344
www.counterpath.com
Release Notes for
CounterPath Softphone SDK
Version 1.5
The CounterPath Softphone SDK 1.5 Release Notes provide information for all 1.5.x releases: SDK 1.5.5 (June 23, 2016) - iOS only
SDK 1.5.4 (April 26, 2016) SDK 1.5.3 (Feb 04, 2016) SDK 1.5.2 (Nov 18, 2015) SDK 1.5.1 (Sept 10, 2015) SDK 1.5 (Aug 10, 2015)
SDK Platforms
The release notes provide information for all of the following platforms: Java for Android
Objective-C for iOS and OS X .NET for Windows
Java for Windows Mac
1 SDK 1.5.5 (June 23, 2016)
This release includes updates to the iOS SDK only. No changes made in other platforms.
1.1 iOS Specific Changes
Auto Discovery of IP Version
This release adds support for automatically discovering an IP version to use. The SDK now provides the ability to specify new enum value of IpVersion_Auto for SipAccountSettings ipVersion setting, which will cause the SDK to attempt auto detection of which IP version (IPv4 or IPv6) should be used. As part of IP version auto detection, the SDK will consider network interfaces available, DNS responses, and connection attempt results.
In order to comply with June 1, 2016 App Store submission requirements by Apple, iOS applications using this SDK should set ipVersion to IpVersion_Auto. An example of this can be seen in the iOS Advanced Audio Call sample, which is included with the iOS SDK package.
Also note that an IPv6-capable SIP server is required for SIP connectivity with this SDK if an iOS device connects to an IPv6-only WiFi or WWAN network. An iOS device connected to an IPv6-only network may be part of Apple App Store submission testing, so ensure any test accounts you give to Apple for App Store
submission testing have support for an IPv4 and IPv6 SIP server. Further, devices running iOS 9 may in the near future begin connecting to IPv6-only LTE networks, which will require an IPv6-capable SIP server.
NAT64 is not supported by the SDK at this time. As a result, connecting to an IPv4 SIP server from an IPv6 network with NAT64 is not supported.
Open SSL
Updated to use OpenSSL 1.0.1t.
Video Improvements
There have been improvements in video quality and performance.
1.2 Resolved Issues
Fixed a defect where playing a sound clip does not work when the default device is selected. Various stability improvements and bug fixes.
1.3 Known Issues
2 SDK 1.5.4 (April 26, 2016)
2.1 Changes
The following changes apply to all platforms. Added support for TLS 1.2 for SIP.
The SDK now supports the ability to establish TLS 1.2 connections for SIP. Applications can:
o set the requested TLS level by adjusting the sslVersion member of the SipAccountSettings struct.
o also note which TLS version was negotiated by examining the SipTLSConnectionInfo struct returned in SipAccountStatusChangedEvent.
For examples, please refer to the Advanced audio call sample application on iOS, OS X, Android or .net Windows SDK.
Updated to use OpenSSL 1.0.1s.
The minimum requirements have been updated. Refer to the respective Developer Guides for details.
2.2 Desktop Specific Changes
The following changes apply to Desktop platforms (Windows and Mac). Added the ability to have the SDK use the default system device.
The SDK now offers the ability to use the default audio device configured in the host operating system. For usage, please see the in-line comments for kAudioDefaultSystemDeviceId and
kAudioDefaultSystemCommDeviceId. For examples, please refer to the Advanced audio call sample application bundled with the OS X or .net Windows SDK.
Introduced a new flag named defaultSystemDevice, which identifies whether a device is the system default. Introduced a new flag named inadvisable on the AudioDeviceInfo struct, which identifies audio devices that
are not recommended to be used (for example, a virtual audio device), especially as a device automatically chosen by the application.
2.3 Windows Specific Changes
Added the ability to have the SDK use the default communication device.
The SDK now offers the ability to use the default audio device configured in the host operating system. For usage, please see the in-line comments for kAudioDefaultSystemDeviceId and
kAudioDefaultSystemCommDeviceId. For examples, please refer to the Advanced audio call sample application bundled with the OS X or .net Windows SDK.
Introduced a new flag named defaultSystemCommDevice, which identifies whether a device is the default communication device.
2.4 Android Specific Changes
Added support for the Android M permission model.
The SDK exposes a new handler class called PermissionsHandler. Apps can implement this handler and receive notifications from the SDK when permission is required from the user to access a particular resource (for example, the microphone).
Added SRTP support in the Android Advanced audio call sample app, to demonstrate how to establish encrypted calls.
2.5 Resolved Issues
Various stability improvements and bug fixes.
2.6 Known Issues
3 SDK 1.5.3 (Feb 04, 2016)
3.1 Resolved Issues
Fixed the audio quality issue on Nexus 6P devices.
Fixed an issue on Android where the SDK would release the active Bluetooth audio device if the VoIP call ended but a native call was still active.
Fixed a DNS-related crash issue. Various stability improvements.
3.2 Changes
Improved echo cancellation on Windows platforms.
Improved reliability when sending a file using SDK’s XMPP file transfer API. Improved bitrate estimation for VP8 video calls.
Removed IPv4 specific functions from all code compiled on iOS, in preparation for Apple’s policy change planned for 2016 mandating support for IPv6.
Removed support for 32-bit version of OS X SDK.
Added the ability to inspect the value of custom headers in incoming INVITE messages. Added a Conversation Call Quality indicator:
o Good
o Fair
o Poor
o Unknown
See page 15 of the CounterPath Softphone SDK Reference Guide for details.
Added a section in the CounterPath Softphone SDK Android Developer Guide, recommending the use of fallback domain name servers. (See Fallback Domain Name Servers on page 19, revision 6 of the guide.)
3.3 Known Issues
4 SDK 1.5.2 (Nov 18, 2015)
4.1 Resolved Issues
Fixed an issue where calling the destroy method on SipAccount in the Android SDK might cause a crash. Fixed crashes with the playSound(..) method on Android.
Fixed for no audio during calls if account registered with useRegistar setting off. Fixed AudioStatistics.averageJitterMs always having a value of 0.
When VAD is enabled, and there is no voice, the SDK will now force send a few RTP packets at the start of a call, instead of sending RTP keep-alives.
Reduced memory usage during VP8 video calls (notably for mobile SDKs). Improvements in H.264 interoperability.
Various stability improvements.
4.2 Changes
Added support for certificate pinning. See the Certificate Pinning section. Addition of GSM codec.
Full IPv6 support.
Support for applications targeting Android API level 23 (Marshmallow). Updated all Android samples to target API level 23.
Added conversation end reason of ConversationEndReason_CallAnsweredElsewhere. Performance enhancements for account initialization.
Added the ability to specify custom RTP payload types. Updated to OpenSSL 1.0.1p.
4.3 Certificate Pinning
CounterPath has exposed the necessary interfaces to allow applications to implement certificate pinning for SIP over TLS or XMPP. Pinning is a process that associates a host with their expected X509 certificate or public key. In the account settings class for either SIP or XMPP, two new entries have been added: acceptedCertPublicKeys and requiredCertPublicKeys. The in-line comments in the API describe how these entries are used by the SDK. The two modes are using:
o acceptedCertPublicKeys so any certificate presented to you is accepted as long as the public key that is set in the settings of the SDK matches. The SDK will accept it, even if it is unsigned, for example. acceptedCertPublicKeys provides flexibility in dealing with certificate issues.
o requiredCertPublicKeys which provide the benefit of extra security.
4.4 Known Issues
5 SDK 1.5.1 (Sept 10, 2015)
5.1 Resolved Issues
Improvements in H.264 video quality for all platforms.
Fixed an issue for all platforms that could result in outgoing packet loss for RTP, the real-time transport protocol.
Fixed issues for Android Bluetooth®.
Fixed crashes on Android devices with Intel® chipsets: Dell Venue 8 and Samsung Galaxy Tab 3, 10.1. Fixed an issue on Windows and Mac where audio could be lost for an active call if a headset was unplugged
and then plugged back in.
Various stability improvements for all platforms.
5.2 Changes
Support for H.264 packetization mode 1 for all platforms. NACK support (RFC 4585) for video for all platforms.
5.3 Known Issues
iOS
For iOS, the 64-bit simulator is not supported yet (x86_64 architecture is not supported yet).
Android
The CounterPath SDK provides basic Android Bluetooth® support only, and is not expected to work with all Android devices. CounterPath has tested Bluetooth against Jawbone ERA and Jabra EasyGo. For this reason, customers are advised to test Bluetooth capabilities for every Android device/Bluetooth device pairing. Android’s Bluetooth system undergoes frequent changes that may create new issues when upgrading a device. Devices also ship their own Bluetooth hardware driver (and sometimes Bluetooth stacks) that can cause issues. Although Bluetooth support is generic and should work with any Android phone and Bluetooth headset combination, CounterPath has only tested a small set of possible device pairings. Basic features are supported, such as incoming/outgoing calls and switching to/from Bluetooth headset to speaker/earpieces. Advanced features, such as switching between multiple Bluetooth devices, aren’t supported in the SDK, and must be done in the app or using the system settings UI.
6 SDK 1.5 (Aug 10, 2015)
6.1 Resolved Issues
Improvements have been made in echo cancellation for Android SIP calls. Fixed VP8 video codec crashes on various Android devices.
Fixed an issue where, when registering against some Avaya IP office systems or Cisco CUCM systems with rport enabled in the SDK, calls could not be received by the SDK.
Various stability improvements
6.2 Changes
Licensing callback no longer occur on the account interface. Instead, SDK applications must listen to events on PhoneErrorHandler.
For the C++ edition SDK, and .net edition SDK, the application must call process(..) on the Phone interface. New XMPP functionality has been exposed in the SDK. Please refer to the SDK Reference Guide for example
diagrams. Additionally, there are sample clients on all platforms that demonstrate these new features.
o + XMPP file transfer
o + XMPP multi user chat
o + XMPP Vcard
Addition of support for Voice Quality Monitoring metrics Addition of HTML API documents for the C# SDK Support for HD resolution VP8 video on mobile platforms Adaptive bitrate support for the OPUS audio codec
Addition of VP9 video codec support on desktop platforms
Minimum version supported for Android SDK is now Android 4.1 (Jelly Bean, API level 16)
Android Bluetooth support in the SDK is experimental. Please see the 0section for more information.
6.3 Windows Specific Changes
The SDK now requires the Visual C++ 2013 redistributable package to be installed for runtime. The Visual C++ 2012 redistributable package is no longer required.
Adjusting media stack settings to set the audio source or use low latency mode has been deprecated; use SipAudioAndroid's setAudioSource(..) and setLowLatencyAudioPlayoutByDevice(..) respectively.
setEchoCancellationMode(..) on SipAudio does not need to be called; by default, the SDK will attempt to use the device's built in hardware AEC if available; otherwise it will fall back to a software AEC implementation. A new method on SipAudioAndroid has been added, setHardwareEchoCancellationByDevice(..), which
allows force disabling of hardware based AEC, and use of software based AEC instead. This method can be used to disable hardware AEC on devices where testing has shown that software AEC performs better Android Bluetooth support in the SDK is experimental. Android's Bluetooth system undergoes frequent
changes which may create new issues when upgrading a device. Devices also ship their own Bluetooth hardware driver (and sometimes Bluetooth stacks) which can cause issues. Although Bluetooth support is generic and should work with any Android phone and Bluetooth headset combination, we have only tested a small set of possible devices. Basic features such as incoming/outgoing calls and switching to/from Bluetooth headset to speaker/earpiece are support while advanced features such as switching between multiple
Bluetooth devices isn't supported in the SDK and must be done in app or using the system settings UI. Please report any issues you encounter.
o To enable Bluetooth, the permission "android.permission.BLUETOOTH" must be added to the app's manifest. In addition, devices running Android 4.0 or 4.1 require the permission
"android.permission.BROADCAST_STICKY".
o Attempting to use a Bluetooth device on the Samsung Galaxy S2 may cause the audio driver to freeze. A device reboot may be required before the audio hardware can be used again.
