Acano solution. Acano Server & VM Release Release Notes. September P

Transcription

1 Acano solution Acano Server & VM Release Release Notes September P

2 Contents Contents 1 Introduction New Features/Changes in R New Features for Lync meetings Dual Homed Conferencing RDP transmission Multiple video encoder support Improved TURN server Using TLS Multi-tenancy XMPP multi-domains Tenanted dial plans Forwarding rules Outbound dial plan rules Tenant call limits H.323 Gateway changes Change to h323_gateway sip_proxy command and Outbound Dial Plan rule H323 Gateway Certificates H.323 Gateway address handling for older gatekeepers and endpoints Support for multiple CDR Receivers Changes to voice prompts Customizing the text shown in invitations Screen layout control using DTMF Additional custom layouts Locking and unlocking a meeting lobby Support for XMPP resiliency SIP and Lync call traversal Extension of certificate based access to client logins Miscellaneous improvements Summary of additional MMP commands Additional MMP commands for TURN server Additional MMP commands to support XMPP multi-domains Additional MMP commands for the H.323 Gateway Addition of ciphers to tls Additional MMP commands to support XMPP resiliency in multi-server deployments Summary of API Additions & Changes Affecting Tenants Determining type of Lync call Overriding port number for TCP media on TURN server Support for multiple CDR receivers Improvements to screen layout handling via the API Locking and unlocking a meeting lobby Customizing the text within invitations Acano Solution: Acano Server R1.8.1 Release Notes P Page 2

3 Contents Media traversal changes Improved error diagnostics Notes on Installing and Upgrading to R R1.8 Deployments Deployments using a single host server Deployments using a single split server hosted on a Core server and an Edge server Deployments for scalability and resilience Upgrading to Release R Downgrading Resolved Issues Resolved in R Resolved in R1.8.0 (formerly released as RC4) Known Limitations Acano Solution: Acano Server R1.8.1 Release Notes P Page 3

4 1 Introduction This release note describes the new features, improvements and changes in Release 1.8 of the Acano solution software for both Acano Server and virtualized deployments. Throughout this document the term Lync refers to Lync 2010, Lync 2013 and Skype for Business. When functionality exists only for a specific version then this will be highlighted. Before upgrading to R1.8, you are advised to take a configuration backup using the backup snapshot <filename> command, and save the backup safely on a different device. See the MMP Command Reference document for full details. Release 1.8 introduces the requirement for certificates for the H.323 Gateway, see section NOTE: Release was formerly released as RC4. Acano Solution: Acano Server R1.8.1 Release Notes P Page 4

5 2 New Features/Changes in R1.8 Release 1.8 comprises: new features for Lync meetings, improved TURN server, support for multi-tenancy, XMPP multi-domains on a single Acano server, tenanted dial plans, tenant call limits, new functionality and changes to the H.323 Gateway, support for two CDR receivers, additional voice prompts and more sampling rates supported, customizing the text within invitations, further improvements to screen layout handling, locking and unlocking a meeting lobby, and a few miscellaneous improvements. Based on beta feedback from our partners, the following features are undergoing some revision: firewall traversal for SIP and Lync devices, XMPP resiliency extension of certificate based access to client logins Partners are advised to wait for a future release before conducting any further testing on these features. 2.1 New Features for Lync meetings Release 1.8 improves the user experience in Lync meetings: providing improved layouts to Acano users providing familiar layouts to Lync users both Lync users and Acano users receive a full combined list of all participants in the meeting, regardless of where they are connected Lync client users now see a non-square aspect ratio for video from SIP endpoints and Acano clients. Previously, video was always cropped to a square format to match video from other Lync clients. Lync client users will now see content in a separate area of their Lync client rather than in the main video area. Acano Solution: Acano Server R1.8.1 Release Notes P Page 5

6 by sending video using the best quality codec supported by each participant in Lync meetings. This optimizes the experience when using a mixture of Lync client versions. These improvements are provided via three new features: Dual Homed Conferencing RDP support Multiple video encoder support Dual Homed Conferencing Dual homed conferencing improves the user experience for both Lync users and Acano users in Lync scheduled meetings and in Lync drag and drop style meetings (also known as ad hoc calls). Lync participants can use drag and drop to add Acano users to a Lync meeting, and can use conference controls to mute Acano users or disconnect them. For Acano users joining a Lync scheduled conference, they will see the video from up to five Lync participants, as well as video from the Acano users. Lync users now see video in a gallery format from all of the Acano users, as well as the Lync users in the meeting. Both Lync users and Acano users receive a full combined list of participants in the meeting. Lync participants can also directly dial into a cospace or use drag and drop to add a cospace to a Lync meeting. These are useful if a large meeting is being held in an Acano cospace which the Lync user wants to join. In the first case they will receive a composed layout of multiple participants. When adding a complete cospace to a Lync meeting, the Lync user will receive only one video stream from the cospace (the main speaker) and will not receive a full combined participant list. They can continue to add additional Lync participants as normal. Note: Prior to R1.8, Acano users joining a Lync conference only received video from one Lync participant (the main speaker), other Lync participants were not shown. In addition, Acano users did not receive a list of Lync participants RDP transmission Release 1.8 provides support for transmission of RDP (Microsoft s Remote Desktop Protocol), improving the experience for Skype for Business and Lync client users when they participate in the same calls and conferences as users of other systems. When a non-lync client user, for example an Acano client user or SIP endpoint user, shares an application, or their desktop, with Lync client users, the Acano Call Bridge encodes the content as RDP and sends the content to the Lync client in a separate RDP channel from the H.264 video stream. This results in both the content and video being displayed in separate areas on the Lync client. Prior to R1.8, both video and content were shown in the same area on the Lync client. Figure 1 shows a call from a non-lync client sharing to multiple Lync clients. Note: From R1.8, sharing from non-lync clients is supported to both Lync clients and to Lync conferences. Note: there is a known limitation with sharing content from Acano Mac clients in a Lync conference. Lync clients do not receive the shared content, but it is received by other endpoints in the Lync meeting. Acano Solution: Acano Server R1.8.1 Release Notes P Page 6

7 Figure 1 Content sharing from a SIP endpoint to a Lync client/conference Multiple video encoder support Different versions of Lync support different video codecs, and this affects the quality of the video they can receive. Lync 2013 and Skype for Business support H.264 SVC which gives the best quality while Lync 2010 and Lync for Mac 2011 support RTV but not H.264 SVC. In previous releases the Call Bridge only sent a single video stream to the Lync AVMCU. In the 1.8 release the Call Bridge can send both RTV and H.264 SVC streams to the AVMCU. This then allows the AVMCU to send RTV to clients that don t support H.264 SVC while sending higher quality H.264 SVC to clients that support it. Figure 2 Multiple video encoders for different Lync clients 2.2 Improved TURN server Release 1.8 introduces an improved TURN server which supports TCP to UDP interworking. This allows TCP media from browser clients to be received which the TURN server converts back to UDP media. This is useful when UDP traffic from browsers is blocked. Acano Solution: Acano Server R1.8.1 Release Notes P Page 7

8 In addition there is a new parameter tcpportnumberoverride for the API object /turnservers allowing the port number to be overridden when using the new TURN server to receive TCP media from browsers. This allows you to set a non-standard port for TCP on the TURN server. Figure 3 TURN server supporting TCP and UDP Use the MMP command turn tls <port none> to select the port for the TURN server to listen on. For example: turn listen a turn tls 443 turn enable Note: the Web Bridge and TURN Server cannot listen on the same interface:port combination. To run both on port 443 requires them to be run on separate servers/vms, or if on the same server/vm they need to be on different interfaces and different subnets. For maximum connectivity from external locations, Acano recommends that port 443 is used for both the Web Bridge and TURN Server Using TLS If you plan to use TLS (a cryptographic protocol), then you will need a certificate on each TURN server that will be used for TLS communication. You do not require a certificate on TURN servers that are not being used for TLS. You are advised to create a similar private key and signed certificate to the one created for the Web Bridge, using the same CA to sign the certificate. Remember to restart the TURN server after you have assigned the certificate (and certificate bundle) and private key pair. 2.3 Multi-tenancy Release 1.8 supports additional multi-tenancy functionality by allowing the hosting of: multiple deployments on the same server. Acano Solution: Acano Server R1.8.1 Release Notes P Page 8

9 This enhancement is provided via the following new features: tenants can be assigned to a tenant group. This provides a mechanism for splitting tenants into separate independent groups. Each group consists of one or more tenants. Set tenant groups up through the API, see section IVRs and web bridges can now be created for a group of tenants as well as for an individual tenant through the API. See section tenanted dial plans, this enables the outgoing dial plan to have rules set that are tenant specific. Outbound connections can have tenant specific Local From Domain to allow call back to reach the correct tenant. See section 2.5. tenanted call IDs. Prior to R1.8, Call IDs had to be unique across the system. In this release, Call IDs must still be unique within a tenant group, but maybe reused for different tenant groups. 2.4 XMPP multi-domains XMPP multi-domain enables a single Acano server to host multiple XMPP domains. For example, both example.com and example.org can exist on the same Acano server. It is possible to configure multiple tenants with the same XMPP domain (as in previous releases), or each tenant with their own domain, or mix these schemes. Use the MMP commands in section to configure multiple domains for the XMPP server to listen to. 2.5 Tenanted dial plans Different dial plan rules for forwarding calls and for outbound calls can be setup for tenants through the API, see section This is applicable to single tenant and multi-tenant deployments Forwarding rules Forwarding rules can have a tenant associated with them. When a forwarding rule with an associated tenant is used, the call (conference) spawned by that rule is associated with the same tenant Outbound dial plan rules You can associate an outbound dial plan rule with a tenant. Once associated, the only call legs that can be placed using that rule are those that originate from calls (conferences) associated with the same tenant, or associated with no tenant. 2.6 Tenant call limits This feature enables an administrator to limit the number of calls a tenant can make to ensure that a tenant does not consume all of the resources. This feature works across distributed deployments and is applicable to single tenant and multi-tenant deployments. Acano Solution: Acano Server R1.8.1 Release Notes P Page 9

10 To set the tenant call limit, set participantlimit on the /tenants/<tenant id>/ API object. See section Note: Call limits may be exceeded when simultaneous calls occur to different Call Bridges. 2.7 H.323 Gateway changes R1.8 introduces the following changes that affect the H.323 Gateway: change in IP address to use in h323_gateway sip_proxy command and Outbound Dial Plan rule (see section 2.7.1). requirement to install certificates for the H.323 Gateway (see section 2.7.2). improvements in the way the H.323 Gateway handles outgoing and incoming dial plans for legacy gatekeepers and endpoints (see section 2.7.3). See Section 0 for additional MMP commands for the H.323 Gateway Change to h323_gateway sip_proxy command and Outbound Dial Plan rule In R1.7, if the H.323 Gateway and the Call Bridge were running on the same host (X series or VM), then the IP address specified in the h323_gateway sip_proxy command was the IP address of one of the external interfaces that the Call Bridge was listening on. Similarly, the entry in the outbound dial plan relating to the H.323 Gateway also needed to point to one of these external interfaces listened to by the Call Bridge In R1.8, if the H.323 Gateway and the Call Bridge are running on the same host (X series or VM) then the IP address specified in the h323_gateway sip_proxy command needs to be set to , and the SIP Proxy to Use in the Outbound Dial Plan Rule needs to be set to :6061. If the H.323 Gateway and the Call Bridge are running on different hosts, then the IP address of the external interfaces that the Call Bridge is listening on may still be used H323 Gateway Certificates From R1.8, a certificate is required on each H.323 Gateway. The certificate can be signed by an internal CA. Follow these steps: Generate a private key and the Certificate Signing Request (.csr) file for the Acano H.323 Gateway application. For information on how to generate a private key and.csr file, refer to one of the Certificate Guidelines on Note: the public key is created and held within the.csr file. Submit the.csr file to the CA (public CA or internal CA) for signing You can use the pki command on the Acano server to generate the private key and.csr file, and submit the pair to an internal CA such as an Active Directory server with the Active Directory Certificate Services Role installed. SSH into the MMP Acano Solution: Acano Server R1.8.1 Release Notes P Page 10

11 Upload the signed certificate and intermediate CA bundle (if any) to the Acano server using SFTP. Check that the certificate (and certificate bundle) and the private key match pki verify <certicate> <cert bundle/ca cert> [<CA cert>] Assign the certificate (and certificate bundle) and private key pair to the H.323 Gateway h323_gateway certs <keyfile> <certificatefile> [<cert-bundle>] Restart the H.323 Gateway h323_gateway restart Note: if you perform TLS certificate verification by using the command: tls SIP verify enable then certificate verification will be undertaken against the TLS SIP trust store on the Call Bridge and the SIP service on the H.323 Gateway. Use the tls SIP trust <crt bundle> command to set up the TLS SIP trust store H.323 Gateway address handling for older gatekeepers and endpoints Release 1.8 introduces improvements in the way that the H.323 Gateway handles outgoing and incoming dial plans for legacy gatekeepers and endpoints. Some old H.323 gatekeepers do not provide the domain in destination addresses for outgoing calls, and cannot handle a domain for incoming calls. These gatekeepers supply and require an E.164 address or H.323 ID for the address. Release 1.8 provides new commands to support these devices, see section 0. Figure 4 illustrates how the destination address for calls from legacy gatekeepers can be accepted by appending a domain to the destination address using MMP command h323_gateway sip_domain <sip_domain_uri >. The source address can also have a domain added which can aid dial-back of that user. Using command h323_gateway h323_domain <h323_domain_uri>, appends a domain which enables the Call Bridge to identify where the call originates, and hence support call back. H.323 Endpoint Legacy H.323 Gatekeeper Acano H.323 Gateway Call Bridge H225 setup Destination address: cospace Source address: h323 INVITE To: cospace@sip_domain From: h323@h323_domain Incoming call From endpoint "h323" Figure 4 Adding the domain to the source address Figure 5 illustrates how call back can be made to work for calls originating from legacy H.323 gatekeepers. Using command h323_gateway h323_domain_strip yes removes the domain from the destination if it matches h323_domain and using command h323_gateway sip_domain_strip yes removes the domain from the source address if it matches sip_domain, when making a call to the legacy gatekeeper. Acano Solution: Acano Server R1.8.1 Release Notes P Page 11

12 H.323 Endpoint Legacy H.323 Gatekeeper Acano H.323 Gateway Call Bridge To endpoint "h323" H225 setup Destination address: h323 Source address: cospace INVITE To: Outgoing call Figure 5 Removing the domain for call back Note: dialing an IP address does not require removal of the domain, as the Call Bridge recognizes that it is an IP address and does not append the domain. 2.8 Support for multiple CDR Receivers From R1.8, the Acano server supports up to two CDR receivers, enabling you to deploy two different management tools or two instances of the same management tool for resiliency. If you are using Acano Manager, the Acano Manager server must be one of your CDR receivers, you can either add a second Acano Manager server or add a different management platform. Note: The list of CDR receivers is held locally to an individual call bridge, it is not stored in the database shared between clustered call bridges. To enable configuration of the multiple CDRs, R1.8 has two new API objects: /system/cdrreceivers/ /system/cdrreceivers/<cdr receiver id> and a new mechanism to index records using the correlatorindex ; correlatorindex replaces the recordindex object which is deprecated and may be removed in a future release. In addition, for deployments with clustered Call Bridges there is a new Call Bridge GUID which identifies which Call Bridge is sending the record, and which remains the same across all restarts of the system. Alternatively, you can configure the multiple CDRs through the Web Admin Interface, Configure > CDR settings, enter each receiver s HTTP or HTTPS URI. For more information on the correlatorindex and configuring multiple CDR receivers, see the R1.8 Call Detail Records Guide. Note: From R1.8 the retrieved alarm condition for cdrconnectionfailure has changed. The "cdrreceiver" element now holds the GUID of the configured object, and there is an additional URI element. Prior to R1.8, the response data included an element called "cdrreceiver" that held the configured CDR receiver URI. Legacy alarm processors will now see the textual rendering of a GUID whereas before they saw the URI of the CDR receiver. Acano Solution: Acano Server R1.8.1 Release Notes P Page 12

13 Note:To process cdrreceiver alarms, first look for the "uri" element to determine the configured URI, and, if absent, look for the URI in the "cdrreceiver" element. Alternatively, try parsing the "cdrreceiver" element to see if it a GUID first and, if it is, look then at the "uri" value. 2.9 Changes to voice prompts The default voice prompts, used for the in-call experience when dialing into a cospace from a SIP or Lync endpoint, have been re-recorded, some with new wording. In addition there are 4 new prompts: You have been disconnected from the meeting Your meeting has ended You are the only participant Waiting for your host to join the bottom two in the list play on a loop for audio-only calls. The range of supported sampling rates has increased from 8 and 16 khz, to now supporting 22.05, 32, 44.1 and 48 khz. Refer to the R1.8 Customization Guidelines for details on the prompt wording and their filenames Customizing the text shown in invitations Releases 1.8 of the Acano client and Acano server introduce the ability to customize the text shown in invitations, providing a branding license key is uploaded to the Acano server. Customization of the invitation text is done via the use of a template which the client requests from the server. Note: that the templates are cached by the client so any changes to a template will not immediately appear in the client. Configure the template via the API of the server. Within the existing callbrandingprofile object there is a new invitationtemplate field which needs to point at a URL from which the server retrieves the template. Refer to the R1.8 Customization Guidelines for details on the placeholders within the invitation text that can be changed, and an example of the template. Note: Custom text invitations are not supported by Acano client 1.7 releases or earlier Screen layout control using DTMF This release introduces the ability for SIP endpoint users to scroll through different screen layouts using DTMF. The users need to be assigned the necessary permissions. Use the API to configure: the DTMF tones in dtmfprofile. Configure DTMF tones for 'next layout' and 'prev layout' operations Acano Solution: Acano Server R1.8.1 Release Notes P Page 13

14 permissions to use DTMF in the calllegprofile. Use parameter changelayoutallowed the defaultlayout in calllegprofile. The layouts scroll through in order: 'allequal', 'stacked', 'telepresence', 'speaker only', defaultlayout. If defaultlayout='allequalninths' then the order is 'allequal', 'stacked', 'telepresence', 'speaker only', 'allequalninths'. If the defaultlayout is set to one of the other layouts then only 4 layouts will be in the cycle. For example: if defaultlayout='allequal' then the order is 'allequal', 'stacked ', 'telepresence', ' speakeronly'. Figure 6 Scrolls through allequal, stacked, telepresence (speaker large), speaker only and defaultlayout 2.12 Additional custom layouts Release 1.8 supports 3 additional screen layouts, which may be chosen via the API (see section ) or through the Web Admin interface (Configuration>coSpaces). These new layouts have one main pane for the main speaker and 5, 7, or 9 smaller panes around the main pane. Figure 7 Additional custom layouts 2.13 Locking and unlocking a meeting lobby In previous releases, when an activator (host) was present in a meeting all other participants (guests) would automatically be activated. This release adds the ability to lock and unlock the lobby to stop and start this activation process. Note that members of the cospace and people joining via access methods not needing activation are not affected by this setting. The user who locks and unlocks the meeting lobby needs to be assigned the necessary permission. Use the API to configure: Acano Solution: Acano Server R1.8.1 Release Notes P Page 14

15 the initial un/locked state of a call. Use a POST request containing the locked parameter with value (true or false) to /calls. the current un/locked state of a running call. Use a PUT request containing the locked parameter to /calls/<call id> to alter the state. This state is not preserved between instances of the meeting. the default lock value. This can be set as part of /callprofiles. Set the locked parameter as true or false, this value will apply until it is overriden via the above methods or by a user. This value is used each time the cospace is used. permission to use DTMF in the calllegprofile. Use parameter calllockallowed the DTMF tones in dtmfprofile. Configure DTMF tones for lockcall and unlockcall parameters The behaviour of a locked/unlocked cospace is as follows: Unlocked - anybody can join, those needing activation continue to be activated as before. Locked - new participants who need activation are not automatically activated. Participants not needing activation and members can still get in. When the conference goes from the unlocked state to the locked state, participants that are already activated are not deactivated Support for XMPP resiliency NOTE: Based on beta feedback from our partners, the XMPP resiliency feature is undergoing some revision. Partners are advised to wait for a future release before conducting any further testing on this feature. Release 1.8 supports XMPP resiliency in multi-server deployments. XMPP resiliency provides fail-over protection for a client being unable to reach a specific XMPP server. When setup in resilient mode, the XMPP servers within a deployment are loaded with the same configuration. Each knows the location of the others and they establish links between them. They use keep-alive messages to monitor each other and elect a master. XMPP messages can be sent to any server. Messages will be forwarded to the master XMPP server, see Figure 8. The XMPP servers continue to monitor each other, if the master fails then a new master is elected and the other XMPP servers forward traffic to the new master. Figure 8 XMPP servers electing master XMPP server Acano Solution: Acano Server R1.8.1 Release Notes P Page 15

16 In a resilient deployment, the XMPP server that a Call Bridges connects to is controlled via DNS. This choice is based on the DNS priority and weight given. A Call Bridge only connects to one XMPP server at a time. There is no requirement for all Call Bridges to connect to the same XMPP server since all traffic is forwarded to the master. If a network problem results in the Call Bridge losing connection to the XMPP server, the Call Bridge will attempt to reconnect to another XMPP server, see Figure 9. Figure 9 Call Bridges connecting to XMPP servers Clients connect via the load balancer. Each load balancer can be configured to have trunks from one or more XMPP servers. There is no need for a full mesh of connections, see Figure 10. In cases where the load balancer doesn t have a trunk from the master XMPP Server, the traffic is routed internally via another XMPP server. Figure 10 Load Balancers connecting to XMPP servers Acano Solution: Acano Server R1.8.1 Release Notes P Page 16

17 2.15 SIP and Lync call traversal NOTE: Based on beta feedback from our partners, the Call traversal feature is undergoing some revision. Partners are advised to wait for a future release before conducting any further testing on this feature. R1.8 introduces this beta feature to support traversal of local firewalls for SIP endpoints and Lync calls. The Call Bridge uses a TURN server within the Acano solution to traverse the local firewall and sends the SIP signal via the Load Balancer. A third party SIP firewall traversal device is no longer required. Once the Load Balancer has been configured and enabled, incoming calls from SIP devices are automatically traversed across the firewall. For outgoing calls to SIP devices, you need to add an Outbound dial plan rule. Note: this feature assumes that the remote SIP device can see the TURN server. It does not require the remote SIP device to be ICE aware. It also requires the remote SIP device to be able to contact the Load Balancer, the Load Balancer must have a public IP address and not sit behind a NAT. Figure 11 Firewall traversal for remote SIP devices Note: SIP endpoints or Lync clients external to the network may still need a third party device to route SIP signaling across their firewall Extension of certificate based access to client logins NOTE: if cac enable strict has previously been applied, then users can only log in to the Acano client using a certificate, no password based login to clients will be possible. NOTE: Based on beta feedback from our partners, the Extension of CAC to client logins is undergoing some revision. Partners are advised to wait for a future release before conducting any further testing on this feature. Acano Solution: Acano Server R1.8.1 Release Notes P Page 17

18 Prior to release 1.8, the Acano solution supported administrative logins to the SSH and Web Admin Interface using certificates, this release extends certificate usage to client logins. If enabled, certificate based logins uses a certificate provided by the client to enable access to the system. This certificate replaces the requirement for a password. One source of these certificates is a Common Access Card (CAC), these requires the use of an authentication token combined with a PIN. The CAC contains a private key which cannot be extracted but can be used by on-card cryptographic hardware to prove the identity of the card holder. Other certificate based schemes are available and supported. Note that the standard Acano client does not provide the ability to use certificate based logins Miscellaneous improvements Release 1.8 supports the following new features: Support for TIP 60fps Support for VP8 and OPUS codecs in SIP calls Acano client user locked out for 15 minutes after 20 failed login attempts Addition of ciphers to the tls MMP command The following weak ciphers have been disabled by default: TLSv1.2 3DES-CBC3-SHA 112 bit key TLSv1.1 3DES-CBC3-SHA 112 bit key TLSv1.0 3DES-CBC3-SHA 112 bit key Note: Weak ciphers can potentially lead to the possibility of a session being recorded and decrypted later. License Usage reports. The Acano Server now produces reports of the number of call legs to allow for calculation of port license usage. These reports are sent to the configured syslog server Summary of additional MMP commands From R1.8 the following MMP commands have been added Additional MMP commands for TURN server Command/Examples turn tls <port none> turn certs <keyfile> <certificate file> [<cert-bundle>] Description/Notes Select the port for the TURN server to listen on Note: the Web Bridge and Turn Server cannot listen on the same interface:port combination. To run both on port 443 requires them to be run on separate servers/vms, or on different interfaces on the same server/vm. Defines the name of the private key file and.crt file for the Turn Server application and, optionally, a CA certificate bundle as provided by your CA. See section 2.2. Acano Solution: Acano Server R1.8.1 Release Notes P Page 18

19 turn certs none Removes certificate configuration The new functionality for the TURN server is described in section Additional MMP commands to support XMPP multi-domains Command/Examples xmpp multi_domain add <domain name> <key-file> <crt-file> [<crt-bundle>] xmpp multi_domain del <domain name> xmpp multi_domain list Description/Notes Add another domain that the XMPP server will listen to. Specify the private key, certificate and optional certificate bundle as provided by the CA. Restart the XMPP server for this change to take effect. Note: the XMPP server will not start if the private key or certificate files are missing or invalid. Delete the domain that the XMPP server listens to. List the domain that the XMPP server listens to. Acano Solution: Acano Server R1.8.1 Release Notes P Page 19

20 Additional MMP commands for the H.323 Gateway Command/Examples h323_gateway certs <keyfile> <certificate file> [<cert-bundle>] h323_gateway certs none h323_gateway sip_domain <uri> h323_gateway del sip_domain <uri> h323_gateway sip_domain_strip <yes/no> h323_gateway h323_domain <uri> h323_gateway del h323_domain <uri> h323_gateway h323_domain_strip <yes/no> Description/Notes Defines the name of the private key file and.crt file for the H.323 Gateway application and, optionally, a CA certificate bundle as provided by your CA. See section Removes certificate configuration Optional. If an incoming H.323 call is made to the gateway without a domain in the destination will be appended to the destination address before the SIP call to the Call Bridge is made. If set to "yes" and "h323_gateway sip_domain" is set, when a SIP call is made to the gateway will be stripped from the source address (if present) before making the H.323 call. Optional. If an H.323 call is made to the gateway without including a domain in the source will be appended to the source address before the SIP call is made. If set to "yes" and "h323_gateway h323_domain" is set, when a SIP call is made to the gateway will be stripped from the source address (if present) before making the H.323 call. The new functionality for the H.323 Gateway server is described in section Addition of ciphers to tls By default, the Acano server only uses secure ciphers for any TLS connections, including SIP TLS on tcp port However, this may mean that the Acano server may be unable to make TLS calls with older, less secure devices. If your deployment has older kit, use this tls ciphers command to specify a list of ciphers that is acceptable to the older devices. See the Openssl guide for more information on ciphers. Symptoms that a device cannot handle secure ciphers include: SIP TLS calls failing to the device HTTPS access not working on the device errors will appear in the logs. Command/Examples tls <service> ciphers <cipherstring> Description/Notes The cipher string format is a colon separated list of ciphers as used by OpenSSL ( FORMAT). The current default for cipher support is: "ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256: ECDH +AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RS A +AES:RSA+3DES:!aNULL:!MD5:!DSS" Acano Solution: Acano Server R1.8.1 Release Notes P Page 20

21 Additional MMP commands to support XMPP resiliency in multi-server deployments NOTE: Based on beta feedback from our partners, the XMPP resiliency feature is undergoing some revision. Partners are advised to wait for a future release before conducting any further testing on this feature. Command/Examples xmpp cluster enable disable xmpp cluster trust <trustbundle.pem> xmpp cluster status xmpp cluster initialize xmpp cluster join <cluster> xmpp cluster remove xmpp cluster remove <node> xmpp callbridge add-secret <callbridge> Please enter a secret: <secret> Description/Notes Enables/disables XMPP clustering. Enabling the XMPP cluster must be done before enabling XMPP on a node. If xmpp cluster is disabled and xmpp is started, this will start the xmpp server in standalone mode. Specifies the bundle of certificates that will be trusted by the xmpp cluster. The <trustbundle.pem> should contain all of the certificates for the xmpp servers in the cluster. The certificates must already have been applied to the xmpp servers using the xmpp certs command. This mechanism ensures that the different xmpp nodes in the cluster trust each other, and enables the failover operation and the forwarding of traffic between nodes. Reports the live state of the xmpp cluster. If the cluster has failed, then this command will return the statistics of the xmpp server running on this Acano server only. Use this command to try and help diagnose connectivity problems. Initializes a cluster. This command will create a 1 node live xmpp cluster, you can join other nodes (xmpp servers) to this cluster. Add this node to the cluster. <cluster> is the IP address of the first node in the cluster (see command xmpp cluster initialize). Remove this node from the cluster. This requires the node to be running. Removes the specified node from the cluster, where <node> is either the IP address or a domain name for the node. This allows you to remove a node from the cluster if the node is unresponsive. Add Call Bridge secret to XMPP server. Used to configure the other nodes with the secrets created when connecting the Call Bridges to the first XMPP server node in the cluster. This command allows a Call Bridge to share credentials with many XMPP servers. XMPP resiliency provides fail-over protection for a client being unable to reach a specific XMPP server. The new functionality is described in section 2.8. Acano Solution: Acano Server R1.8.1 Release Notes P Page 21

22 2.19 Summary of API Additions & Changes Affecting Tenants Additional functionality for handling tenants: Dial plan additions (see section 2.4). Tenant parameter for the following methods: forwardingdialplanrules methods outbounddialplanrules methods Applying call limits to tenant. use participantlimit on /tenants/<tenant id>/ Tenant groups Additional objects /tenantgroups and /tenantgroups/<tenant group id> Associating tenants to tenant groups additional parameter tenantgroup for /tenant and /tenants/<tenant id>/ Applying tenant groups to cospaces additional parameter tenantgroup for /webbridges and /webbridges /< webbridge id>/ Note: only cospaces associated with tenants within the specified tenant group can be accessed by call ID through this web bridge. If no tenant group is supplied, only cospaces without a tenant, or associated with a tenant in no tenant group, can be accessed by call ID. Applying tenant groups to ivrs additional parameter tenantgroup for /ivrs and /ivrs/<ivr id>/ Note: calls to this IVR will only be able to join cospaces associated with tenants within the specified tenant group. If no tenant group is supplied, calls to this IVR will only be able to join cospaces without a tenant, or associated with a tenant in no tenant group Determining type of Lync call New response value of lyncsubtype on individual call leg for Lync calls. lyncsubtype can show: audiovideo applicationsharing instantmessaging Overriding port number for TCP media on TURN server Additional tcpportnumberoverride parameter (see section 2.2) for the following method: /turnservers and /turnservers/<turn server id> Acano Solution: Acano Server R1.8.1 Release Notes P Page 22

23 This parameter has been added to allow the port number to be overridden when using the new TURN server to receive TCP media from browsers Support for multiple CDR receivers Two new API objects to support multiple CDR receivers (see section 2.8): /system/cdrreceivers/ /system/cdrreceivers/<cdr receiver id> Note: The object /system/cdrreceiver/ is deprecated in R1.8, and you should use the new objects instead. API object /system/cdrreceiver/ may be removed in a future release. Note: In R1.8 the number of multiple CDR receivers is limited to two Improvements to screen layout handling via the API Additional screen layouts and improvements in screen layout selection for SIP endpoints. New screen layouts (see section 2.11) are available for /calllegs, /calllegprofiles and /cospace methods. The new layouts are: oneplusfive, oneplusseven, oneplusnine. They can be selected through the defaultlayout parameter. In addition there is a new chosenlayout parameter that can be applied to calllegs which overrides the prevailing defaultlayout. The new activelayoutfilter restricts results returned to those calllegs using the specified layout. SIP endpoint users can be allowed to change their screen layout: set changelayoutallowed on /calls, /calllegs and /calllegprofiles (see section 2.11). new parameters for /dtmfprofiles enable scrolling through available screen layouts on SIP endpoints (see section 2.11): nextlayout previouslayout Locking and unlocking a meeting lobby Ability to enable the locking/unlocking of a meeting lobby in order to control the process of activating participants. Participants requiring activation are typically guests to a cospace that have not yet been activated. Members of a cospace are not affected, and can join the cospace at any time. When a meeting is locked, the guests requiring activation wait in the meeting lobby until the host unlocks the cospace, at which point they are activated and join the cospace. Participants that are already activated are NOT deactivated when the conference goes from the unlocked state to the locked state. Initial locked state of meeting lobby. New parameter for /calls locked Acano Solution: Acano Server R1.8.1 Release Notes P Page 23

24 Change current un/locked state of a meeting lobby for a running call. Use a PUT request containing the locked parameter to /calls/<call id>. This state is not preserved between instances of the meeting. Default lock value. New parameter for /callprofiles locked this value will apply until it is overridden via the above methods or by a user. This value is used each time the cospace is used Permission to lock/unlock meeting lobby using DTMF. New parameter for calllegprofile. calllockallowed Configure DTMF tones. New parameter for dtmfprofile lockcall unlockcall Customizing the text within invitations Text within invitations can be customized providing a branding license is loaded on the Acano server Within the existing callbrandingprofile object there is a new invitationtemplate field which needs to point at a URL from which the server retrieves the template Media traversal changes NOTE: Based on beta feedback from our partners, the Call traversal feature is undergoing some revision. Partners are advised to wait for a future release before conducting any further testing on this feature. Additional mediarouting parameter (see section 2.1.3) for the following method: outbounddialplanrules This parameter has been added to support SIP/Lync call traversal for outgoing calls Improved error diagnostics Improvement in diagnostics through new error codes: cdrreceiverdoesnotexist directorysearchlocationdoesnotexist invalidversion tenantgroupcospaceidconflict tenantgroupdoesnotexist toomanycdrreceivers Acano Solution: Acano Server R1.8.1 Release Notes P Page 24

25 Refer to the Acano Solution 1.8 API Reference Guide for further information. For beta, additions to the API guide for R1.8 are shown in red for easy reference. Acano Solution: Acano Server R1.8.1 Release Notes P Page 25

26 3 Notes on Installing and Upgrading to R1.8 This release note assumes that you have already upgraded to R1.7.x. If you have not, and are upgrading from 1.6.x, then read the 1.7 release notes first and follow the instructions, before following any instructions in this R1.8 release note. CAUTION: Before upgrading to R1.8 you must take a configuration backup using the backup snapshot <filename> command and save the backup safely on a different device. See the MMP Command Reference document for full details. 3.1 R1.8 Deployments R1.8 supports the new deployments introduced in R1.6: the single combined Acano server, the single split server and the deployment for scalability and resilience Deployments using a single host server If you are installing the Acano solution for the first time on a single host server (a combined deployment), we recommend that you read and follow the documentation in the following order: Appropriate Installation Guide for your Acano Server or virtualized host. The Single Combined Acano server Deployment Guide enabling all the solution components on the single host (. This guide refers out to the Acano Certificate Guidelines for Single Combined Acano Server Deployments for details on obtaining and installing certificates for this deployment. Note: R1.8 of the deployment guide is not yet available Deployments using a single split server hosted on a Core server and an Edge server If you are installing the Acano solution for the first time in a split server model, we recommend that you deploy the XMPP server on the Core server, and deploy the Load Balancer on the Edge server. Read and follow the documentation in the following order: Appropriate Installation Guide for your Acano server or virtualized deployment The Single Split Acano server Deployment Guide. This guide refers out to the Acano Certificate Guidelines for Single Split Acano Server Deployments for details on obtaining and installing certificates for this deployment. Note: R1.8 of the deployment guide is not yet available Deployments for scalability and resilience If you are installing the Acano solution for scalability and resilience using multiple host servers, we recommend that you deploy the XMPP server on Core servers, and deploy Load Balancers on the Edge server. Read and follow the documentation in the following order: Appropriate Installation Guide for your Acano server or virtualized deployment Acano Solution: Acano Server R1.8.1 Release Notes P Page 26

27 The Scalability and Resilience Deployment Guide. This guide refers out to the Acano Certificate Guidelines for Scalable and Resilient Acano Server Deployments for details on obtaining and installing certificates for this deployment. Note: R1.8 of the deployment guide is not yet available. 3.2 Upgrading to Release R1.8 The instructions in this section apply to both Acano Server and virtualized deployments with a previous Acano solution release already installed. CAUTION: Before upgrading to R1.8 you must take a configuration backup using the backup snapshot <filename> command and save the backup safely on a different device. See the MMP Command Reference document for full details. Do NOT use the automatic backup file that is created during the upgrade process. Upgrading the firmware is a two-stage process: first, upload the upgraded firmware image; then issue the upgrade command. (This restarts the Acano solution: the restart process interrupts all active calls running on the Acano solution; therefore, this stage should be done at a suitable time so as not to impact users or users should be warned in advance. To install the latest firmware on the Acano server follow these steps: Obtain the upgrade image from the secure partner section of the Acano website. You should have obtained a file called upgrade.img. If this is not the case rename the file to upgrade.img. Note: If you are using WinSCP for the file transfer, ensure that the Transfer Settings option is binary not text. Using the incorrect setting results in the transferred file being slightly smaller than the original and this prevents successful upgrade. Using a SFTP client, log into the MMP using its IP address. The login credentials will be the ones set for the MMP admin account. If you are using Windows, we recommend using the WinSCP tool. Note 1: You can find the IP address of the MMP s interface with the ipv4 admin command or the equivalent ipv6 command. Note 2: The SFTP server runs on the standard port, 22. Note 3: After copying the upgrade.img file, you will not be able to see it listed as being in the file system; this is normal. Copy the software to the Acano Server/ virtualized server. To apply the upgrade, issue the upgrade command. a. Establish a SSH connection to the MMP and log in. b. Initiate the upgrade by executing the upgrade command. upgrade The Acano Server/ virtualized server restarts automatically: allow 10 minutes for the process to complete. Acano Solution: Acano Server R1.8.1 Release Notes P Page 27

28 Verify that the Acano solution is running the upgraded image by re-establishing the SSH connection to the MMP and typing: version Check the Configuration > Outbound Calls rules updating the Local Contact Domain field and completing the new Local From Domain field if necessary. Update the customization archive file when available. Only if you are deploying a scaled or resilient deployment (with more than one server host Acano server, virtualized host or a combination) read the Scalability & Resilience Deployment Guide and plan the rest of your deployment order and configuration. If you have deployed a database cluster, be sure to run the database cluster upgrade schema command after upgrading the database schema. For instructions on upgrading the database schema refer to the Scalability & Resilience Deployment Guide. You have completed the upgrade. 3.3 Downgrading To return to the older version of the Acano solution, use the regular upgrade procedure to upgrade to the appropriate version. Then restore the configuration backup for the older version, using the backup rollback <name> command. See the MMP Command Reference document for full details. Do not rely on the backup generated automatically during upgrade. Note: The backup rollback <name> command overwrites the existing configuration as well as the license.dat file and all certificates and private keys on the system, and reboots the Acano server. Therefore it should be used with caution. Make sure you copy your existing license.dat file and certificates beforehand because they will be overwritten during the backup rollback process. The.JSON file will not be overwritten and does not need to be re-uploaded. Acano Solution: Acano Server R1.8.1 Release Notes P Page 28

29 4 Resolved Issues Resolved in R1.8.1 Reference Issue Summary 8552 Slaved SIP call dropped after 30 minute timeout 9138 Occasionally Call Bridge will crash when diagnostics sent from the Acano or WebRTC clients 9258 User names presented in the participant list of the WebRTC client are not properly sanitized Pubsub nodes subscription is not properly controlled by a whitelist. Using the SIP and Lync call traversal feature, calls transferred to a SIP endpoint drop after 30 minutes. Fixed in Fixed in This issue is reported as Security Alert 035. Fixed in This issue is reported as Security Alert 034. Fixed in Resolved in R1.8.0 (formerly released as RC4) Reference Issue Summary 3594 Layout PIPs occasionally disappear, and then reappear 7212 SDP o line keeps using 0 for version number 7694 Occasionally the database was reporting internal errors. In certain circumstances these were associated with LDAP sync fails, and provisioning of new users was impacted Invalid characters in SIP headers could cause XMPP disconnection 8315 Outgoing 200OK responses do not include require:timer 8320 Database cluster may fail while doing large LDAP syncs 8442 Video and audio delay seen when H.323 endpoints join a cospace 8447 Connection to Lync meeting drops for H.323 registered endpoint calling via IVR Fixed in R1.8.0 Fixed in R Version number now increments by 1 to indicate that something has changed and that it is a new SDP. Fixed in R1.8.0 Fixed in R1.8.0 Fixed in R1.8.0, require:timer added to outgoing 200K responses when invite from far end indicates that timer is supported. Occasionally a server in a cluster may reboot during large LDAP imports. Fixed in R1.8.0 When two H.323 endpoints join a cospace there is a delay in the audio and video received by the endpoints. Fixed in R1.8.0 H323 registered endpoint calling an IVR on an Acano Server, enters the IVR and then dials into a Lync Meeting. The call connects, but seconds later, the server drops the connection to the Lync meeting. The H323 leg stays up but there is no incoming video. Fixed in R1.8.0 Acano Solution: Acano Server R1.8.1 Release Notes P Page 29