Your Team Voice account is push enabled. There are no push settings for your Team Voice account.
If your administrator set up an additional SIP account, this information applies to the additional SIP account.
Bria offers Bria Push Service to users to allow users to receive incoming calls when Bria is in the background or exited.
Enabling push notifications
If the primary team member set up an additional SIP account, the SIP accounts have the Bria Push Service enabled by default. If the Bria Push Service is not enabled, use the following procedure to turn it on.
Go to Settings > Accounts and tap
More Info besidethe SIP account you want to enable push notifications for.
Turn off Enabled.
Turn on Use Push Notifications.
If required, change the settings for Registration Mode and NAT Emulation.
- For most VoIP service providers, no changes are required in Advanced Settings. If your VoIP service provider requires you to use difference SIP proxies for Bria and the Bria Push server, change the settings for SIP Proxy. If your VoIP service provider does not follow the SIP RFC specifications, find out from your VoIP service provider if you should enable Insert R Instance, Disable Hash Token, Auto Send 180, and Disable Override Domain, and set Service Refresh Interval.
Turn on Enabled.
The Bria Push Service is enabled. You will receive calls if Bria is in the background or exited.
To make sure that push notifications are enabled, look at the icon beside the account in Settings > Accounts. If the account has push enabled, there will be green lines above the SIP account icon .
This option controls how the combination of the Bria client and the Bria Push server interact with the SIP server. For some customer’s SIP servers, the registration mode may not matter or make a substantive difference to the behavior of the SIP Server or the reliability of the reachability of the Bria client. For another customer’s, the registration mode will matter quite a bit because one of the registration modes works best to address the particular limitations of the customer’s SIP Server. Customer administrators and IT staff should carefully understand these registration mode options and their potential impacts.
The Standard registration mode allows both the Bria Push servers and the Bria 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 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.
Single Device Emulation (1)
The Single Device Emulation registration mode ensures that both the Bria client and the Bria Push server unregister before the other one registers. In other words, the Bria client and the Bria Push server never register to a PBX, SIP server, or SIP service at the same time. The Bria client controls the registrations by requesting the Bria Push server to register only after the Bria client has de-registered and alternately, by receiving confirmation that the Bria Push server has de-registered before the Bria client registers directly to the SIP server. The Bria 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 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.
The Continuous registration mode ensures that the Bria Push server is always registered on behalf of the Bria client. The Bria 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 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 client.
In the event of a call to the SIP account while the Bria client is in the foreground, the Bria client will receive an INVITE directly from the SIP server and via the Bria Push server. The Bria client will filter out these duplicate events and only allow one of the call attempts to progress.
Single Device Takeover (3)
The Single Device Takeover mode is an enhanced option of the Single Device Emulation mode. The Bria client and the Bria Push server take over registrations from each other without unregistering first. Neither the Push server or the Bria 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.
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 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 clients would use a different SIP Proxy either internally to a customer’s local network or external to the customer’s network.
Insert R Instance
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.
Disable Hash Token
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 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.
Auto Send 180
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 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 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 client. The Bria 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 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.
Disable Override Domain
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.
Server Refresh Interval
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.
Testing push notifications
After setting up push on your SIP account, you can use the Test Push Service button to make sure that your device can communicate with the Bria Push server and that your device is able to receive push notifications from
Go to Settings > Accounts and tap
More Info besidethe SIP account you to test.
- Tap Test Push Service.
If you see Push test passed, push notifications are working. If push notifications fail, review your push notification settings and check the Bria Mobile Push Checklist to see if your device and your server can be used with the Bria Push Service.
You can also test push notifications by putting Bria in the background and trying to call it from another number. If you receive a notification of an incoming call, you have correctly set up the Bria Push Service.
Stop receiving push notifications
There are multiple ways to stop receiving push notifications.
Log out: Go to Settings and tap Logout.
Disable the Bria Push Service: Go to Settings > Accounts and
tap beside the SIP account and turn off Settings > Accounts > Account (SIP) > Enabled. Turn off Settings > Accounts - Bria Push Service > Use Push Notifications. Make sure to turn on Enabledto use the SIP account.
- Disable the SIP account: Go to Settings > Account and
tap beside the SIP account and turn off Enabled.
Change your presence to Do Not Disturb: When you change your presence to Do Not Disturb, incoming calls are rejected. Calls show in History as a Missed Call entry. To change your presence, see Changing your status.
Turn on Do Not Disturb on your device: When you use the device’s Do Not Disturb setting, the call is shown on the screen but you will not hear an audible alert.
Turn on Client-Side Call Forwarding: Go to Settings > Preferences > Forward Calls. Enter the number you want to forward the calls to in To Number.
- Turn off device notifications for Bria
: Go to the device Settings > Notifications > Bria and clear Show Notifications.
Log out: Go to Settings and tap Logout.
For more detailed information of push notifications, settings, and requirements for using push, see Bria Push Service.