Sinch Voice and Video SDK Migration Guide
Follow this migration guide to start using the latest Sinch mobile Voice and Video SDKs.
Intended Audience
This migration guide provides an overview of adaptions required to migrate from the Sinch legacy platform to the Sinch cloud-native platform. We assume that you're familiar with key concepts, operations, and glossary of the Sinch Voice and Video SDK. Here we provide a comprehensive list of the changes required both in the application and on your backend to get started with the new cloud-based Sinch mobile SDKs.
Otherwise, if you had never used Sinch Voice and Video SDK before, please refer to the respective platform documentation:
Client / User Registration Changes
When you initiate the Sinch client you have to provide user identity and also authorize the client to register for the given user identity by providing a registration token. In the legacy Sinch SDKs, user authentication and authorization were based on credentials provided in a way of an opaque token that was based on the SHA1 digest of Sinch Application Secret. There was also a way to provide Application Secret directly to the SinchClient.
In the new SDK, to authorize the registration of a user, the application must provide a registration token to the client (SINClient/SinchClient) or UserController. This token should be in the form of a JSON Web Token (JWT) signed with a signing key derived from the Application Secret. The recommended way to implement this authentication scheme is that the Application Secret should be kept securely on your server-side backend, and the signed token should be created and signed on your server, then passed via a secure channel to the application and Sinch client running on a device.
Thus, registration is made both more simple and secure:
- Application Secret must never be stored in the application, and there is no way to provide Application Secret to the SinchClient that could encourage that, instead:
- Authentication and Authorization is granted by JWT tokens.
Both iOS and Android documents provide the same coverage on how to create and sign these JWT registration token, including links to the server-side sample code.
️ Server-side changes required
Android and UserController
There is a new way to register User on Android: UserController API. UserController provides a way independently from the SinchClient lifecycle, to register a User for incoming calls via push notifications. You can also use it to unregister push token if receiving of incoming calls is no longer desirable (example on logout, or changing users).
UserController provides two types of callbacks:
- Callbacks for basic User registration with the Sinch backend.
- Callbacks for push device token registration with the Sinch backend.
The action flow diagram of the User registration via UserController is provided below. UserController's callbacks are highlighted in pale blue.
️
Though the use of UserController is optional for the FCM Push Notification case, since the SinchClient can register itself to receive FCM Push, it's mandatory for the Huawei Push Notifications, since the push device token have to be acquired by the Application before constructing UserController. Thus, it's highly recommended to use UserController in both cases.
iOS APNs Signing Keys
New Sinch iOS SDK only support APNs Token-based authentication. In other words, we no longer support APNs certificate-based functionality. Therefore, to enable Sinch to act as APNs Provider on your behalf, you must provide Sinch with an APNs Authentication Token Signing Key. You create this signing key in your Apple Developer Account and upload the key file to your Sinch Developer Account. Please find more details here.
