Allow different pn_skip_pn_interval per device type or per contact

[truong-hua]

Is your feature request related to a problem? Please describe.
The https://opensips.org/docs/modules/3.2.x/registrar.html#param_pn_skip_pn_interval is very useful in case of client device can keep connectivity to OpenSIPS, espcially in case of we are using the foreground service of Android device. But the problem here is that it is not the same for iOS as Apple has native voip push notification which is designed for this purpose and there is no need of a foreground service like Android.

Therefore, it would be great if we can activate pn_skip_pn_interval for just Android device and set it to zero for iOS device. Or letting client to make that decision is good too.

About Foreground Service: https://developer.android.com/guide/components/foreground-services

Describe the solution you'd like
Allow multi values for pn_skip_pn_interval example: fcm: 150, ios: 0

Implementation

• Component: registrar

Describe alternatives you've considered
Client device carefully handle different register message when the app is in foreground and a different one (have PN enabled) before the app is put into background (because it may be late or terminate and can not wait for server response or checking it while app in background). And of course client need to carefully handle deduplication of 2 kind of registration.

[github-actions]

Any updates here? No progress has been made in the last 15 days, marking as stale. Will close this issue if no further updates are made in the next 30 days.

[flaviogoncalves]

I want the same! I have exactly the same problem.

[liviuchircu]

I had a short discussion with Flavio, where he suggested to simply relay the INVITE immediately on an Android PN contact, since the app is in foreground, while on iOS you can just wait for the Re-REGISTER (since the app is in background anyway):

"I think the simplest way to solve is to do the lookup even if all contacts are PN enabled (return code 2) and let to the script writer the decision to send or not the INVITE."

Would this work for you as well, @truong-hua? If yes, I will put together a patch for you to test!

[truong-hua]

I had a short discussion with Flavio, where he suggested to simply relay the INVITE immediately on an Android PN contact, since the app is in foreground, while on iOS you can just wait for the Re-REGISTER (since the app is in background anyway):

"I think the simplest way to solve is to do the lookup even if all contacts are PN enabled (return code 2) and let to the script writer the decision to send or not the INVITE."

Would this work for you as well, @truong-hua? If yes, I will put together a patch for you to test!

Thank @liviuchircu. In my opinion, if I can control the logic, I will fork 2 branches, 1 for push notification and another for normal INVITE relay. As detecting whether the app is on foreground or not based on REGISTER time is not always correct, sending both PN and INVITE relay at the same time in parallel I think will work with all PN related platforms.

Besides, I'm willing to test your patch as we are using our custom build too.

[truong-hua]

Hi @liviuchircu do you have any update regarding this? I think it will be the same for WebPush.

• Perfect solution: send both Push Notification & normal INVITE at the same time and the client usually have their owned loop detection.
• Acceptable solution: using Push Notification for expired REGISTER (but need to be different for iOS).

[flaviogoncalves]

I've created this patch. When all contacts are PN enabled, now you can relay it will send the INVITE after the lookup. For the old behaviour just don't relay. (!!PATCH UPDATED!!), sorry I've send the older version of the patch, this is the one actually working.

lookup.patch

[truong-hua]

@liviuchircu do you think the patch above from @flaviogoncalves is correct? I'm not sure if it can handle correctly the case that there are multiple contacts and some are PN enabled and some are not.