Support Push Notifications for mobile Restcomm SDKs

[atsakiridis]

Right now mobile SDKs cannot receive events when the App is not active or not running, which means that they cannot receive incoming calls or text messages from Restcomm unless the App is active. To aid in that we want to implement Push notifications that work even when the App is not active or even not running and the impact in mobile battery life is minimal. That needs additional functionality on the server side (either Restcomm Core or maybe a new 'hybrid' SIP element, we need to discuss that).

The way this roughly works is that if a SIP request arrives to Restcomm (i.e. INVITE or MESSAGE for now) and the recipient is a mobile device where the App (using our mobile SDK) is deemed inactive, then instead of sending the INVITE to App that won't be able to handle it, send a Push notification to the App via an APN (Apple Push Notification) server that will wake the App and with some additional logic will deliver the call or message properly. We'll discuss how that could be accomplished next and break it to two iterations: 1. text messages and 2. calls, as there are differences in the handling between them and text messages are simpler to implement. Notice that this is a very rough 'architecture' that we need to better investigate from a server perspective to see if it suits us and make more detailed.

1st Iteration: Implement text messages functionality

1. When the mobile SDK detects that the App is going to be suspended it should signal the server side (i.e. Restcomm or another server element depending on how that will be implemented) that from now on it cannot receive regular SIP messages and can only handle Push notifications.
2. From that point on if the server side receives a SIP MESSAGE that is destined for the App it should send a Push notification to Apple's servers (see https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html for details) using as payload the text of the message.
3. That way the device will get notified of the message and be able to show it right away in the notification center. Another logic could be for the Push notification to not contain the actual text message and be just an indication that the server side wants to tell us something so that the App is opened and receives the actual text message via SIP MESSAGE request. This is how Iteration 2 will probably implement INVITEs and we could have common handling. BUT: the problem is that in that case the message wouldn't be shown in the notification center as the user is accustomed with other Apps like Hangouts, Messenger, etc, which I think is a big issue and we should avoid it. And that's the main logic.
4. Keep in mind that if the user opens the App it should signal the server side so that it resumes normal SIP operations where the App is reached through regular SIP message and not Push notification. Again this could be signified by a REGISTER that would happen anyway.

   2nd Iteration: Implement call functionality

5. Same as (1) in 1st iteration
6. From that point on if the server side receives an INVITE that is destined for the App it should send a Push notification to Apple's APN servers (see https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html for details) using as payload an indication that the server side wants to send us an incoming call.
7. Then, if the user acts on the Push notification, the App should somehow tell the server side that 'here I am, I'm ready to receive your call'. Maybe this could be conveyed via a REGISTER that is sent anyway when the App is opened.
8. Then the server side would take the hint that the App is alive and kicking and resume the regular INVITE processing. If the App doesn't notify the server side timely, the server side should time out and send back to the caller an unreachable event probably (this will be a usual case actually, given that people often ignore notifications) and that's it.
9. Notice that same as (4) in 1st iteration the App should signal the server side when it is opened by the user so that it resumes normal SIP operations where the App is reached through regular SIP message and not Push notification.

@deruelle, @gvagenas: could you have a look since you have a much better understanding of the server side and can evaluate if and how we can realize/implement this?

Some additional notes:

• This plan started out for iOS, but I think it also makes sense for Android (using Google Cloud Messaging instead), and even Android though is much more permissive than iOS on how long an App can run, I think it is still a good idea for battery preservation and to have a common behavior among both architectures.
• I got most of the ideas from others implementing such functionality such as: https://www.acrobits.net/hesk/knowledgebase.php?article=52

[gvagenas]

@atsakiridis My thoughts and comments on this issue

The best way to support mobile clients and push notification services at Restcomm but still not mess with the core SIP functionality, would be to introduce a new Restcomm plugin (a new module) that will be responsible for the calls/messages with all mobile clients.

This new module should be able to handle both iOS and Android devices.

An important requirement here is to find a way to identify that a client is running on a mobile device and thus bypass the normal call flow Restcomm will follow for regular sip clients. We can use User-Agent header or better a custom header. Using a custom header will allow 3rd party applications to seamlessly integrate with Restcomm.

Using this new module we will be able to:

1. Keep registration open without ping messages (SIP OPTIONS) for a mobile client
2. Send mobile push notifications to wake up device and application.
3. Send/receive sip traffic as normal.

Important for phase 2 is that there must be an update for the network details.

For example

1. application starts on WiFi with IP Address A, port B, registers with Restcomm and sends existing IP/Port plus the specific identifier that will be used later for push notifications
2. Next the app goes inactive and the mobile device switch to mobile data (LTE/3G etc), new IP / Port
3. When Restcomm has a new call/message for this client will use push notification services to wakeup application. During this it is important to discover the new IP Address and port that the application can be reached and to update the Restcomm database
4. Restcomm sends SIP traffic to the proper IP Address/port

@atsakiridis You should start working on that new module and I will assist you on the design and the integration with the Restcomm-core

George

[deruelle]

Linked to https://github.com/RestComm/Restcomm-Connect/issues/1843

[erikroloff]

Any updates on this?

My company is looking to develop an app using Restcomm and this would be a very helpful feature.

[deruelle]

@erikroloff would you like to contribute to the effort in implementing / designing this ?