Bria Push Service

When Bria Mobile is in the foreground, Bria Mobile registers directly with your VoIP service provider. If the Bria Push Service is enabled and you place Bria Mobile in the background, the Bria Push Service will register with your VoIP service provider on Bria Mobile’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 Mobile and Bria Mobile 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 Mobile.

After the call ends, the push server may unregister depending on your Registration Method. Bria Mobile 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 Mobile in the background again.

When you turn on Use Push Notification, the following settings are revealed:

• Registration Mode
• Nat Emulation
• Advanced Settings
  • SIP Proxy
  • Insert RInstance
  • Disable Hash Token
  • Auto Send 180
  • Disable Override Domain
  • Server Refresh Interval

Registration Mode

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.

• Continuous

  The Continuous registration mode ensures that the Bria Push server is always registered on behalf of the Bria Mobile client. The Bria Mobile 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 Mobile 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 Mobile client. In the event of a call to the SIP account while the Bria Mobile client is in the foreground, the Bria Mobile client will receive an INVITE directly from the SIP server and via the Bria Push server. The Bria Mobile client will filter out these duplicate events and only allow one of the call attempts to progress.

• Single Device Takeover

  The Single Device Takeover mode is an enhanced option of the Single Device Emulation mode. The Bria Mobile client and the Bria Push server take over registrations from each other without unregistering first. Neither the Push server or the Bria Mobile 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.

• Standard

  The Standard registration mode allows both the Bria Push servers and the Bria Mobile 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 Mobile 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

  The Single Device Emulation registration mode ensures that both the Bria Mobile client and the Bria Push server unregister before the other one registers. In other words, the Bria Mobile client and the Bria Push server never register to a PBX, SIP server, or SIP service at the same time. The Bria Mobile client controls the registrations by requesting the Bria Push server to register only after the Bria Mobile client has de-registered and alternately, by receiving confirmation that the Bria Push server has de-registered before the Bria Mobile client registers directly to the SIP server. The Bria Mobile 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 Mobile 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.

Nat Emulation

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.

More details

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.

Advanced Settings

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.

• SIP Proxy

  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 Mobile clients would use a different SIP Proxy either internally to a customer’s local network or external to the customer’s network.

• Insert RInstance

  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 Mobile 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.

  More details

  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 Mobile 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.

  More details

  With Bria Push enabled, the Bria Mobile 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 Mobile client. The Bria Mobile 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 Mobile 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.

Only IPv4 SIP servers are currently supported for calls involving the Bria Push server. Bria Mobile only supports IPv6 only networks using DNS64/NAT64 when communicating with IPv4 SIP servers for these calls.

• Your mobile device must have public Internet access to Apple’s APNS push notification system.

  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 Mobile Push Checklist.

If you are unsure of any of these requirements, contact your server administrator or your VoIP service provider.

• The SIP server must allow registration from the Bria Push server. If the SIP server is running inside of the restricted network of an organization, the organization must provide access to the Bria Push server and set the SIP Proxy parameter. For a complete list of servers, visit the Bria Mobile Push Checklist.

• 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.

• For the best user experience, the SIP server should support multiple SIP registrations for each SIP account. If the SIP server can support multiple registrations, the Bria Push server and Bria Mobile can be registered with the SIP server at the same time. If your SIP server does not support multiple registrations, set Settings > Accounts (SIP) - Bria Push Service > Registration Mode to Single Device Emulation. You may notice a momentary pause in service when Bria Mobile transitions from the background to the foreground.
• If the SIP service uses server managed NAT traversal or follows industry best practices where the SIP server sends responses to the originating IP address and port, leave Settings > Accounts (SIP) – Bria Push Service > NAT Emulation disabled. If the SIP service does not use server managed NAT traversal or send the responses to the originating IP address and port, enable Settings > Accounts (SIP) – Bria Push Service > NAT Emulation. If you do not receive push notifications or there is no audio on push registered calls, turn Settings > Accounts (SIP) – Bria Push Service > NAT Emulation off.

• 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 Mobile 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.

  If your SIP server is running inside a restricted network of an organization

  You must do both:

  1. set the which is a separate item from the one configured as part of regular SIP settings.
  2. provide access to the Bria Push servers CounterPath has deployed. See the Bria Mobile Push Checklist for a list of IP address and DNS names used by the Bria Push Service. Note that this information may change over time; customers should monitor the content.
  If you are not sure about the network you are using

  Verify the SIP server reachability by testing if the Bria Mobile client can register to the SIP server, with the Bria Push Service disabled, in the following networks:

  • from a Wi-Fi network that is not associated with your own corporate/home network, such as a coffee shop or public library, and
  • from an LTE / 4G mobile network. Make sure to disable the Wi-Fi network on the mobile device.

  This test is effective when verifying the SIP server reachability because the Bria Mobile 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 Mobile 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

• Apple APNs reachability from the Bria Mobile clients

  Apple requires a set of ports to be open in your firewall. If you have a restricted network, see Apple APNs to make sure the traffic is allowed. The Test Push Service button can verify this.

• 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.

  1. If you can only use one SIP device at a time, then CounterPath classifies this as supporting a single registration. In Bria Push configuration, the registration mode should be either Single Device Emulation or Single Device Takeover. Try Single Device Takeover unless Single Device Emulation is already working for you. It might require some testing to figure out which is better for your deployment. 
  2. If you can use multiple SIP devices at the same time and specifically receive calls on all devices for a single inbound call (meaning that all devices are able to maintain a registration and the SIP server supports call forking), then CounterPath classifies this as supporting multiple registrations. The registration mode should be either Standard or Continuous. Try Continuous unless Standard is already working for you. It might require some testing to figure out which is better for your deployment. 

• 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.

  More details

  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 Mobile client on mobile devices with or without using push notifications. Make sure:

• Push notifications are enabled in the SIP account on the Bria Mobile 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 Mobile client can reach the CounterPath push servers from behind any firewalls. Try the Test Push Service button on the Bria Mobile 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 Mobile 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 Mobile 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 Mobile and the SIP server. Try solving the issue with push notifications disabled. After addressing the issue, try testing push notifications again.