Doesn't answer after quitting

[brianjmurrell]

According to #538 Linphone is supposed to still answer the phone after quitting if push is enabled.

This doesn't seem to be working on feature/release-4.1. After quitting Linphone, and then calling the device, I see the push being sent from the FCM servers but Linphone is not started up to answer it.

Perhaps this is related to the push content that is being sent to the FCM servers?

My push contains the following data:

{
 
 "to":"[redacted]",
  "data":{
    "body":"incoming call"
    }
}

and I get back:

{
  "multicast_id":[redacted],
  "success":1,
  "failure":0,
  "canonical_ids":0,
  "results":[
    {
      "message_id":"0:[redacted]%[redacted]"
    }
  ]
}

This all works while Linphone is running, just not after it has quitted.

[Viish]

That's because you are using push notification with data.
If I recall correctly when you send a push like this it only displays a notification in the system but the FirebaseMessagingService isn't called in the onMessageReceived callback.
You can check out our proxy implementation for reference: https://github.com/BelledonneCommunications/flexisip/blob/master/src/pushnotification/firebasepush.cc

[brianjmurrell]

My understanding is that a push with type notification is what only displays a notification, and a push with data gives the data value to the application to process.

FWIW, this data key could actually contain the entire INVITE so that linphone wouldn't need to do this dance of REGISTERing once it receives the push only to then wait for the more traditional INVITE on it's SIP port. Assuming a PBX (or proxy wink) which could put the INVITE into the push message. But I digress.

Here's the documentation on notification vs. data:
https://firebase.google.com/docs/cloud-messaging/concept-options

You can check out our proxy implementation for reference: https://github.com/BelledonneCommunications/flexisip/blob/master/src/pushnotification/firebasepush.cc

Interesting that your implementation uses neither notification nor data.

But nn that push body, what is pinfo.mUid, or more precisely what is pinfo? What does linphone do with that uuid key? Oh wait. Linphone probably doesn't get that uuid value. I suppose FCM is consuming that. But what is it doing with it or what is it needed for?

[Viish]

The android app does nothing with the push itself, it simply starts the LinphoneService and a Core it there is not one already. We assume that if there was already a Service, it would have received the INVITE through the socket.
If you want to test, you can add a call to core.setNetworkReachable(false) then core.setNetworkReachable(true) to force recreating the socket.

[brianjmurrell]

So what is the uuid key for in the push body?

[Viish]

As documented in https://github.com/BelledonneCommunications/flexisip/blob/8a28ba7e7ebb7894d9059121266eea76f31ba69c/src/pushnotification/pushnotification.hh:
mUid; // The unique id as used in the ExtendedContact, if available.
So it it's the unique ID in your REGISTER's contact header, in your case 312eea04-3559-00ae-9920-aac6701fd648 from the logs you attached in #537

[brianjmurrell]

What are the ramifications of not including it in the push API request?

[Viish]

Actually none, as I told you we don't read what's inside the push, we just want the information that a push has been received.

[brianjmurrell]

So why does your reference implementation put the uuid in the push? It must serve some purpose doesn't it?

[Viish]

I think it was used at some point, but we don't need it anymore.