Call or message not received when application is removed from recent apps

[ognjenns]

When Olympus application is not active, its in the recent apps, and push notification is sent; The RCDevice is initialized and call/message is received. When application is not in the recent apps, the RCDevice is initialized but call/message is not received.

[atsakiridis]

Managed to reproduce the issue. Scenario:

1. Open Android Olympus and setup push notifications; verify it's good by testing an incoming call after hitting home button
2. Kill Android Olympus from recents
3. Try a second incoming call (from web olympus) and at this point there's no INVITE coming in and in the caller side we get:

2017-13-12 17:11:34.359 INFO SIP message received: SIP/2.0 404 Cannot complete P2P call
To: <sip:antonis@cloud.restcomm.com>;tag=85454476_04905836_57a5b08a_7d9f64ce
Via: SIP/2.0/WSS 141.237.152.226:55125;branch=z9hG4bK-313035-9a58204ba8ac03d52f536655f026d734;rport=55125;received=141.237.152.226
CSeq: 2 INVITE
Call-ID: 1513177888911
From: "totos" <sip:totos@cloud.restcomm.com>;tag=1513177889567
Server: Restcomm 8.3.0-54
Contact: <sip:52.55.231.191:5060;transport=tcp>
Content-Length: 0

Analysis:

• I see that REGISTER is successful and even after ~8 seconds I receive the OPTIONS from RC without issues
• This means that the signaling/transport channel seems clear
• The only weird thing is Connection attempt already in progressbut still this might show up in good scenarios as well
• Also the fact that OPTIONS comes properly after so many seconds means that signaling channel in Olympus/SDK is still open/healthy
• It doesn't seem to be android/sdk issue. Server somehow decides not to forward the call and returns 404 to the caller
• I'd suggest that you try to debug with @agafox to see why the 404 is issued from the server

Here are the logs

[ognjenns]

Also to add that settings for the ICE Server where somehow mess up.

[atsakiridis]

I'm pushing this issue to next sprint because it needs to be investigated in a different way. Here are the conclusions we reached today with @agafox and @ognjenns:

• The problem here is the 3 second timeout in the server side, which means that if it takes more than 3 seconds for the REGISTER to come in after the push has gone out, then the call is cancelled.
• This problem can also occur on a regular push scenario where the App isn't killed; it's just more easily reproducible if the App has been killed as it takes more time.

Action plan:

• As a first step we need to investigate if we can make the client come up faster. Mainly profile it and see if we have any big issues that we can fix easily
• If that isn't possible we need to see how we can improve the server design so that this delay isn't needed.

[atsakiridis]

Assigning to myself now that the scope of this issue changed to profiling the SDK

[atsakiridis]

Did some profiling and provided my input here

[atsakiridis]

There's on action on our side on this. But I'm leaving this open so that when server side is ready we can verify that the issue is fixed

[SlobodanPrijic]

@atsakiridis any update regarding this issue? Seems that calls are still cancelled to early (current cloud service).