Your Team Voice account is push enabled. There are no push settings for your Team Voice account.
If the primary team member set up additional SIP accounts,
Team Voice is set up for the Bria Push Service. If the Primary Member of your team set up an additional SIP account, this information applies to the additional SIP account.
The Bria Push Service uses push notifications to support inbound calls when Bria Teams is in the background, Bria Teams is not active, or your device is locked. Push notifications are messages reliably delivered from a cloud-based messaging service to your device.
Some
When you use the Bria Push Service, your account configuration is stored on CounterPath’s push notification server. The data is securely transmitted in accordance to our Privacy Policy. In order to use the Bria Push Service, you must accept the Bria Push Service agreement.
When Bria Teams is in the foreground, Bria Teams registers directly with your VoIP service provider. If the Bria Push Service is enabled and you place Bria Teams in the background, the Bria Push Service will register with your VoIP service provider on Bria Teams’s behalf. Inbound calls are directed through the Bria Push server. When there is an incoming call, the push server sends a notification to Bria Teams and Bria Teams is brought to the foreground and creates a secure connection with the push server. The call is routed from the VoIP service provider to the Push Server and then to Bria Teams.
After the call ends, the push server may unregister depending on your Registration Method. Bria Teams re-registers with your VoIP service provider. Any new calls that are made will route directly to your VoIP service provider until you place Bria Teams in the background again.
When you turn on Use Push Notification, the following settings are revealed:
There are four registration modes. Continuous and Standard are used if your VoIP service provider supports multiple registrations. Single Device Takeover and Single Device Emulation are used if your VoIP service provider does not support multiple registrations. Most VoIP service providers do support multiple registrations. The default value for new accounts is Single Device Takeover.
The Continuous registration mode ensures that the Bria Push server is always registered on behalf of the Bria Teams client. The Bria Teams client still registers directly to the SIP server when in the foreground, but the Bria Push server does not de-register from the SIP server. In this mode, all inbound calls and all outbound calls from the Bria Teams client are handled by the Bria Push server.
The Continuous mode, in particular, is used when a SIP server supports multiple registrations at the same time. This mode avoids any gap in SIP registration because the Bria Push server is always registered on behalf of the Bria Teams client. In the event of a call to the SIP account while the Bria Teams client is in the foreground, the Bria Teams client will receive an INVITE directly from the SIP server and via the Bria Push server. The Bria Teams client will filter out these duplicate events and only allow one of the call attempts to progress.
The Single Device Takeover mode is an enhanced option of the Single Device Emulation mode. The Bria Teams client and the Bria Push server take over registrations from each other without unregistering first. Neither the Push server or the Bria Teams client sends SIP de-registration messages when transitioning from one element to the other. It aims to eliminate gaps that are present in the other registration mode. This mode is in some cases beneficial for SIP servers that only support single registration.
The Standard registration mode allows both the Bria Push servers and the Bria Teams clients to register to a customer’s SIP account in an alternating manner. In this mode, there may be short overlaps of registration where both the Bria Push server and the Bria Teams client are registered to the SIP server. Some PBXs, SIP servers or SIP services may have issues with this registration overlap. If you encounter an issue with registering to the SIP server or receiving push notifications, select a different registration mode.
The Single Device Emulation registration mode ensures that both the Bria Teams client and the Bria Push server unregister before the other one registers. In other words, the Bria Teams client and the Bria Push server never register to a PBX, SIP server, or SIP service at the same time. The Bria Teams client controls the registrations by requesting the Bria Push server to register only after the Bria Teams client has de-registered and alternately, by receiving confirmation that the Bria Push server has de-registered before the Bria Teams client registers directly to the SIP server. The Bria Teams clients will also not register while they are in a call delivered through the Bria Push server so that they do not cause potential issues with the call in progress being terminated by the SIP Server.
Note that when in the Single Device Emulation registration mode, there are periods of time (typically fractions of a second) when neither the Bria Teams client or the Bria Push server will be registered to the PBX, SIP server or SIP service. This gap could lead to a missed call if the call is presented to the SIP server at the same time that neither element is actively registered. This is a downside of the requirement of the SIP server that only one element be registered at any one time.
This option instructs the Bria Push server to simulate that the Bria Push server is registering from behind a Network Address Translation (NAT) router or another network element. Enable NAT Emulation if your VoIP service provider uses a session border controller. If enabling NAT Emulation results in no push notifications or no audio, disable NAT Emulation.
The Bria Push server simulates this NAT situation by inserting a SIP VIA header into the SIP REGISTER method that the Bria Push server sends to the SIP server. This VIA header often assists with ensuring that various NAT traversal techniques are enabled on a customer’s Session Border Controller and/or SIP server. Enabling the various techniques supported by these platforms may assist with ensuring that registrations are maintained or may help with issues related to call delivery or RTP stream establishment.
The advanced settings only need to be changed if your VoIP service provider has some limitations or does not follow SIP RFC specifications. In most cases, Bria Push Service will work without changing the advanced settings.
The option allows the customer to specify a SIP Proxy specifically for use by the Bria Push Server. It is important to note that this is an alternative to the SIP proxy configured as part of the regular SIP account configuration. In some very specific customer deployments, the customer would like the Bria Push server to register and receive calls from the SIP Server using a particular proxy while the Bria Teams clients would use a different SIP Proxy either internally to a customer’s local network or external to the customer’s network.
The Insert RInstance option instructs the Bria Push server to use a hash token as the rinstance in the contact header of SIP register. RInstance assists some SIP servers with identifying different clients contact addresses when servers support multiple registrations for a single SIP account. Refer to the Disable Hash Token option for an example of when to use RInstance.
The Bria Push server generates a globally-unique hash token for each customer to avoid possible SIP username collisions. The Bria Push server uses this token when registering to the SIP service on behalf of the Bria Teams client's SIP account. In most cases, using the hash token is beneficial and does not cause any problems for registration and call processing. However, some SIP servers, mainly PBXs that are not compliant to the SIP RFC specifications, cannot handle this token. If this is the case, disable hash token and try using RInstance instead in order to help the Bria Push server identify the clients. Note that some PBXs do not support RInstance either.
When the Disable Hash Token option is off (therefore using the token), the Bria Push server inserts a hash token in the uri.user portion in the contact header of SIP register. However, some SIP servers do not include the hash token in an INVITE message when sending it to the Bria Push server, which does not benefit the Bria Push server.
The Auto Send 180 Ringing option instructs the Bria Push server to issue a SIP 180 RINGING message to the SIP server without waiting for the Bria Teams client to be waken up for an incoming call. This option may help situations where your SIP service may timeout before the push notification is delivered to your device.
With Bria Push enabled, the Bria Teams client establishes a secure WebSocket tunnel with the Bria Push server after the Bria Push server receives an INVITE from the SIP service. Once the tunnel is established, the Bria Push server relays the INVITE to the Bria Teams client. The Bria Teams client then sends 180 Ringing back to the Bria Push server and the Bria Push server relays it to the SIP service. This process takes longer than what occurs during a normal (non-push) foreground call.
When the Auto Send 180 option is enabled, the Bria Push server generates its own 180 ringing response and does not wait for the Bria Teams client to create the secure WebSocket tunnel. This aims to shorten the delay and allows the Bria Push server to respond to the SIP service right away to the incoming INVITE. Note that this option aims to address only a part of the delay; the Bria Push Service involves processing through various elements that result in this time lag.
The Disable Domain Override option stops the Push server from replacing the To Header Domain Part of the INVITE with the domain included in the SIP account information.
The Server Refresh Interval option instructs the Bria Push server to register with the SIP server for a particular requested re-registration interval. Value in seconds. Some SIP servers do not specify minimal refresh time in the registration response and ignore the REGISTER expires value. Note that according to the SIP standards, a SIP server can return a lower value in the 200OK which the Bria Push server will respect by re-registering at or before the lower interval requested.
Only IPv4 SIP servers are currently supported for calls involving the Bria Push server. Bria Teams only supports IPv6 only networks using DNS64/NAT64 when communicating with IPv4 SIP servers for these calls.
To see if you can use the Bria Push Service, check the following on your device and your server.
Your mobile device must have public Internet access to
If you are using your device inside a restricted network, make sure to open ports specified by Apple. Visit Apple APNS for instructions.
Your mobile device must have public Internet access to Bria Push servers. For a list of servers, visit the Bria Teams Push Checklist.
If you are unsure of any of these requirements, contact your server administrator or your VoIP service provider.
The SIP server should map the SIP Address-of-Record (AOR) to the Contact URI when sending the INVITE. The Bria Push server generates a unique Contact URI for each SIP account on each device the account is registered on. The Bria Push server uses this unique Contact URI to determine where to send the push notification for the incoming call. If the SIP server does not pass the unique Contact URI to the Bria Push server in the INVITE, it is likely that the device will not get a push notification for the incoming call because the Bria Push server cannot identify a unique SIP account to route the incoming call.
Is it Push-related?
Determine whether or not the issue is related to push notifications. To verify this, test the same scenarios while the Bria Teams client is in the foreground. If you encounter the same issue while in the foreground as well as in the background, your issue is likely unrelated to the Bria Push Service.
SIP server reachability from CounterPath Push servers
The SIP server (a PBX or a SIP service) must be reachable from the Internet. This is required in order to allow the Bria Push servers to register to your SIP server and receive calls from your SIP server.
You must do both:
Verify the SIP server reachability by testing if the Bria Teams client can register to the SIP server, with the Bria Push Service disabled, in the following networks:
This test is effective when verifying the SIP server reachability because the Bria Teams client registering from an unknown IP address simulates the interaction of CounterPath Push servers with the customer's SIP server.
CounterPath Push server reachability from the Bria Teams clients
Ensure that their mobile devices are on a network that allows them to communicate with the Bria Push Service. Try the Test Push Service button in Settings > Accounts - Bria Push Service with the SIP account enabled and registered. If the test is successful, your device is able to communicate with the Bria Push server and your device is able to receive push notifications
SIP server capabilities: single registration vs multiple registrations
One critical item to understand about a SIP server is if it supports a single registered client per configured SIP account or line. Different manufacturers, software providers, and Unified Communications Services use different terminology for this capability.
SIP server capabilities: setting Contact URI
The SIP server should map the SIP Address-of-Record (AOR) to the Contact URI when sending the INVITE. The Bria Push server generates a unique Contact URI for each SIP account on each device the account is registered on. The Bria Push server uses this unique Contact URI to determine where to send the push notification for the incoming call. If the SIP server does not pass the unique Contact URI to the Bria Push server in the INVITE, it is likely that the device will not get a push notification for the incoming call because the Bria Push server cannot identify a unique SIP account to route the incoming call.
The Bria Push server sets this unique Contact URI in the REGISTER message when registering with the SIP server. For the best interoperability, when the SIP server notifies the Bria Push server of an incoming call, the SIP server should set the Request-URI of the INVITE message to be the same value as the Contact header as specified by the Bria Push server in the REGISTER message. If you think this might be the cause of your issue, try changing the settings for Disable Hash Token and Insert RInstance.
Permissions for push notifications on user's device
Make sure the user has given a permission to receive push notifications on their device. This can be controlled in the same way as you give a permission for the mobile device to access the microphone, camera, contacts etc.
This is one of the most common issues when testing the Bria Teams client on mobile devices with or without using push notifications. Make sure:
Push notifications are enabled in the SIP account on the Bria Teams client.
The user has given a permission to receive push notifications on the device.
Your SIP servers can be reached from the Internet, such as a coffee shop or public library. Try registering to the SIP server with push notifications disabled in such a location using Wi-Fi and/or a mobile data network.
The Bria Teams client can reach the CounterPath push servers from behind any firewalls. Try the Test Push Service button on the Bria Teams client.
Check if your SIP server cancels the incoming call because it does not receive a 180 RINGING message back from the Push server within an expected period of time. If this is the case, turn on the Auto Send 180 Ringing setting (one of the Bria Push advanced settings), or review configurations on your SIP server to increase the interval in which a 180 RINGING is expected.
Review the Bria Teams Push Checklist.
In the CounterPath's experience, no audio or one-way audio has not been related to the Bria Push Service.
Try calling to and from the Bria Teams client while it is in the foreground, which does not leverage the Bria Push Service. If you still experience no audio or one-way audio while the client is in the foreground, it means that the issue is outside the scope of the Bria Push Service and that it is likely related to a configuration in the SIP network or interaction between Bria Teams and the SIP server. Try solving the issue with push notifications disabled. After addressing the issue, try testing push notifications again.
Not required, but having a SIP trace from your SIP server is beneficial. A SIP trace provides information needed to understand the interaction between the Bria Teams client, the push servers, and the SIP server.
Some SIP platforms and providers provide a view of the SIP registration status. This capability can be helpful to determine if the Bria Push Service is able to register on behalf of the Bria Teams client.
CounterPath provides the capability for the user to send the device log from the Bria Teams client to CounterPath Support.
Bria Teams User Guide - iOS - Version 5.5
Publication date: 2019-02-22
Copyright ©2019 CounterPath Corporation. All rights reserved.
This document contains information proprietary to CounterPath Corporation, and shall not be used for engineering, design, procurement, or manufacture, in whole or in part, without the consent of CounterPath Corporation. The content of this publication is intended to demonstrate typical uses and capabilities of Bria Teams from CounterPath Corporation. Users of this material must determine for themselves whether the information contained herein applies to a particular IP-based networking system. CounterPath Corporation makes no warranty regarding the content of this document, including—but not limited to—implied warranties of fitness for any particular purpose. In no case will CounterPath Corporation, its employees, officers or directors be liable for any incidental, indirect or otherwise consequential damage or loss that may result after the use of this publication.
CounterPath®, Bria®, X-Lite®, and the ® logo are registered trademarks of CounterPath Corporation.
Stretto™ and the Stretto Platform™ are trademarks of CounterPath Corporation.
Android and Google Play are trademarks of Google Inc. Eclipse is a trademark of Eclipse Foundation, Inc.
Intel, the Intel logo, Intel Core and Core Inside are trademarks of Intel Corporation in the U.S. and/or other countries.
iOS is a trademark or registered trademark of Cisco in the U.S. and other countries and is used under license.
iPhone, iPad, iPod, Mac, mac OS, App Store, Objective–C , and Xcode are trademarks of Apple Inc., registered in the U.S. and other countries.
Microsoft, Active Directory, Office, Excel, Outlook, and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
Oracle and Java are registered trademarks of Oracle and/or its affiliates.
All other products and services are the registered trademarks of their respective holders.
CounterPath Corporation
Suite 300, One Bentall Centre
505 Burrard Street, Box 95
Vancouver, BC V7X 1M3
Canada