I have successfully integrated Sinch and everything works great except when the App is terminated. The first Call never gets registered by -[SINCallClient client:didReceiveIncomingCall:] or -[SINCallClient client:willReceiveIncomingCall:]
If I answer that call - the app opens - Sinch Client gets initiated but never recognises any incoming calls.
I have tried numerous ways and have isolated my SinchClient to be owned by the AppDelegate.
This issue can be reproduced by not initiating the SinchClient until Sinch Managed Push delegate receives the VOIP push notification.
Steps to reproduce the issue:
Step 1: Don't initiate the sinch client on App Launch
Step 2: Setup your Sinch Push Delegate
Step 3: Initiate a call and receive the VOIP Push token
Step 4: Report to CallKit in accordance with Apples iOS13 guidelines
Step 5: Initiate your SinchClient
The Sinch Client gets initiated and never receives any incoming calls therefore making it impossible to connect that call.
Here is my SinchClient init
convenience init(_ id: String) {
self.init()
self.userId = id
self.sinchClient = Sinch.client(withApplicationKey: "xxxxxxxx",
applicationSecret: "xxxxxxxx",
environmentHost: "clientapi.sinch.com",
userId: self.userId)
self.sinchClient.setSupportCalling(true)
self.sinchClient.enableManagedPushNotifications()
self.sinchClient.delegate = self
self.sinchClient.start()
self.sinchClient.startListeningOnActiveConnection()
}
func clientDidStart(_ client: SINClient!) {
print("SINCH CLIENT DID START")
self.sinchClient.call().delegate = self
}
This is my log when receiving my first call while Sinch Client is not started. The Sinch client gets initiated immediately after reporting to CallKit, I can't start it before since that would cause the app to crash.
Sinch Managed Push! Received
New Sinch Client Init
(adm_helpers.cc:57): Failed to set stereo playout mode.
(adm_helpers.cc:77): Failed to set stereo recording mode.
(audio_device_generic.cc:17): BuiltInAECIsAvailable: Not supported on this platform
(audio_device_generic.cc:27): BuiltInAGCIsAvailable: Not supported on this platform
(audio_device_generic.cc:37): BuiltInNSIsAvailable: Not supported on this platform
2020-07-02 16:01:31.820653+1000 Josari[1370:334218] Metal GPU Frame Capture Enabled
2020-07-02 16:01:31.820814+1000 Josari[1370:334218] Metal API Validation Enabled
SINCH CLIENT DID START
Related
How to retrieve and handle the payload data from the app in background & foreground in iOS. I got the push notifications working, but I don't know how to extract the response.
notificationCallbackIOS: (message: any) => {
console.log("Message : " + JSON.stringify(message));
}
"nativescript-push-notifications": "^1.1.3"
This callback is not working. I am unable to extract the payload data like action, title.
You could try to use this plugin https://github.com/EddyVerbruggen/nativescript-local-notifications
it has a addOnMessageReceivedCallback event for listening for incoming notifications. I also used it on my app that i'm developing now. Even its for local notification, it also listens for remote notification you can call it on your app.component.ts.
Although HTTP is a stateless protocol, there's this PushStreamContent class that facilitates server-sent events, as you can read here. A Web API implementation may store client streams and periodically send push updates. However, it's a bit of a problem to detect when the client disconnects.
In this discussion, Henrik Nielsen states that:
Detecting that the TCP connection has been reset is something that the Host (ASP, WCF, etc.) monitors but in .NET 4 neither ASP nor WCF tells us (the Web API layer) about it. This means that the only reliable manner to detect a broken connection is to actually write data to it. This is why we have the try/catch around the write operation in the sample. That is, responses will get cleaned up when they fail and not before.
In .NET 4.5 there is a mechanism for detecting client disconnect but I haven't tried it out.
Fast forward two and a half years to today. Does anyone have any idea what this mechanism is, and whether it works?
An interesting response was post on this link : link to the article
this is a part of the answer
In .NET 4.5 there is a mechanism for detecting client disconnect but I haven't tried it out.
This (simplified) code works for me:
public HttpResponseMessage Get(HttpRequestMessage request)
{
// Register for client disconnect notifications
object clientId = ...; // this is the object passed to the callback
System.Web.HttpContext.Current.Response.ClientDisconnectedToken.Register(
delegate (object obj)
{
// Client has cleanly disconnected
// obj is the clientId passed in to the register
// handle client disconnection
//...
}
, clientId );
// Normal code from the sample continues
response.Content = new PushStreamContent(...);
}
The ClientDisconnect callback is called back if e.g. you close the client browser page cleanly, but if you pull the network cable out, it does not get notified. So for this unclean disconnection, we still need some other way of detecting this, such as monitoring failures during the timer callback.
/*Get the URI that the Microsoft Push Notification Service returns to the Push Client when creating a notification channel.
Normally, a web service would listen for URIs coming from the web client and maintain a list of URIs to send
notifications out to. */
string subscriptionUri = TextBoxUri.Text.ToString();
Further information on how the pushclient would then sync the URI with a webservice lacks in the description given on MSDN.
So, does anyone know how to make my app send its URI to the MPNS using the push notification client of the Windows Phone, iso having to manually copy-paste them into my web application?
Greetz GP
See MSDN Windows Phone Code Samples at:
http://msdn.microsoft.com/en-us/library/ff431744(v=vs.92).aspx
The following code snippet from the 'sdkToastNotificationCS' example show a possible location to store the uri or send to your webservice:
void PushChannel_ChannelUriUpdated(object sender, NotificationChannelUriEventArgs e)
{
Dispatcher.BeginInvoke(() =>
{
// Display the new URI for testing purposes. Normally, the URI would be passed back to your web service at this point.
System.Diagnostics.Debug.WriteLine(e.ChannelUri.ToString());
MessageBox.Show(String.Format("Channel Uri is {0}",
e.ChannelUri.ToString()));
// Instead of showing the URI in a message box, POST to your web service
});
}
Execute an HTTP POST request to send the URI and an identifier for you push user. Receive this POST data on your web service and store the user/URI so you can push notifications to that user from your web service.
You just need an endpoint on your server that the app can send the PNS uri (and any other relevant information) to.
After successfully sent the URI to the web service from the push client, I send a toast notification from web service by using the URI, in web service I get the response as :
Push status 200,
NotificationStatus : Received,
DeviceConnectionStatus : Connected,
NotificationChannelStatus : Active.
But no message is received in the push client. The same scenario used to work fine earlier today. Can anyone tell me what is going wrong?
Is the message you are sending the same (ie. identical)? I seem to remember that some instances of a malformed message would get through the service OK, but then be suppressed on the device.
Do you have code to handle toast messages that arrive while your app is running? If you do, put a breakpoint in there and send a toast to the app while you're debugging and see what comes out. In this way you can make sure that the toast is making it to the device, and also see what the content is or what the problem might be.
channel.ShellToastNotificationReceived += channel_ShellToastNotificationReceived;
where channel is your channel object, and then
void channel_ShellToastNotificationReceived(object sender, NotificationEventArgs e)
{
Dispatcher.BeginInvoke(() => MessageBox.Show(e.Collection["wp:Text1"] + Environment.NewLine + e.Collection["wp:Text2"]));
}
or something similar to pop the message out to the display.
In web service, if a wrong setRequestProperty is set for example, setting wrong X-WindowsPhone-Target and wrong X-NotificationClass, then web service will receive notification received status, but the push client will not receive any message.
In my case I was sending a toast message with X-WindowsPhone-Target as token and X-NotificationClass as 1. After giving correct value it has started working fine.
My push client sends the URI to my web service, by using the URI, from my web service, I am able to send toast notification to my app installed on Emulator. But if I use the device URI and try to send a message to the device from web service, I get 404 as response. Can anyone tell me What the issue could be ?
Assuming you aren't having any problems receiving and storing the URL your physical device sends to your service, and that you are sending messages to this URL, the only thing I can think of is something I noticed during testing. On occasion, if a malformed message is sent to the URL, it appears to go into a faulted state and any subsequent message (even if well-formed) sent to the service returns a 404.
I don't know if this is expected behaviour or a bug - I resolved it by fixing the malformed messages I was trying to send, and refreshing the channel from the device.