[OpenSIPS-Users] Implementation of RFC 8599

Mon Feb 5 10:33:28 UTC 2024

You must register at least once, so that the server can collect the push token. Then, later you just wait during the Invite for the devices to get the push with t_wait_for_new_branches(). When any device registers again, you will get notified and can add a new branch to fork to. Msilo has no role into such arrangement.

See an example here:

https://github.com/AGProjects/sylk-pushserver/blob/master/config/opensips.cfg

—
Adrian

> On 5 Feb 2024, at 07:15, Volkan Oransoy <voransoy at gmail.com> wrote:
> 
> Hi Adrian
> 
> Thanks for your comment. I got your point. Can you give a hint to handle the the call forking for freshly registered devices? I need to keep calls in a queue until the UA registers. Is msilo right approach?
> 
> Thanks
> 
> Volkan Oransoy
> On 5 Feb 2024 at 10:02 +0000, Adrian Georgescu <ag at ag-projects.com>, wrote:
>> You should fork to any registered contact and send push and later fork to any new devices that registered before a predefined timeout. The only flaw with this logic is that there is jo real progress indicator in SIP, you only know a push was sent but not the SIP device status like 180 Ringing, until the app comes to the foreground. 
>> 
>> If no device is registered you should still send the push otherwise it defies the purpose.
>> 
>> —
>> Adrian
>> 
>> 
>> 
>> 
>>> On 5 Feb 2024, at 05:54, Volkan Oransoy <voransoy at gmail.com> wrote:
>>> 
>>> Yes they are but the implementation looks for a valid registration record to initiate pn. The route snippet at the blog post looks for the pn enabled registrations with return code 2 then pops up the E_UL_CONTACT_REFRESH event, and waits for a registration from the UA to proxy the call. 
>>> # do lookup with method filtering
>>> lookup("location", "m");
>>> $var(rc) = $retcode;
>>> switch ($var(rc)) {
>>> case 1:
>>> # we found at least 1 non-PN contact!
>>> $var(do_relay) = true;
>>> break;
>>> case 2:
>>> # success, but all contacts are PN-enabled, so we're
>>> # sending PNs / awaiting re-registrations from them
>>> $var(do_relay) = false;
>>> break;
>>> default:
>>> xlog("L_INFO", "DBG: no contacts found ($var(rc))\n");
>>> t_reply(404, "Not Found");
>>> exit;
>>> }
>>> ...
>>> if ($var(do_relay) && !t_relay())
>>> send_reply(500, "Internal Server Error");
>>> ...
>>> 
>>> So practically, UA should keeps its registered state active, so needs a registration refresh in regular intervals. That is not the ideal case for a mobile app I believe. So the main idea is to keep power consumption at minimum. 
>>> 
>>> Thanks
>>> 
>>> Volkan Oransoy
>>> On 4 Feb 2024 at 15:01 +0000, Adrian Georgescu <ag at ag-projects.com>, wrote:
>>>> Push notifications were designed exactly for the case when the UA is not registered.  
>>>> 
>>>> —
>>>> Adrian
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On 3 Feb 2024, at 09:19, Volkan Oransoy <voransoy at gmail.com> wrote:
>>>>> 
>>>>> Hi there
>>>>> 
>>>>> @Ronald we use that tool for notification tests and it does the job. 
>>>>> https://github.com/flutter-webrtc/callkeep/tree/master/tools
>>>>> 
>>>>> We managed to work the setup mentioned at the official blog post but that requires the UA to stay registered. This needs periodic communication between the UA and the registrar proxy as the RFC describes. We want the call to be initiated even if the UA is offline but has a valid token stored. I think we will use the msilo method with a bunch of custom configs and scripts. 
>>>>> 
>>>>> Let me know if you have any comments, tips etc. 
>>>>> 
>>>>> Have a great weekend.  
>>>>> 
>>>>> Volkan Oransoy
>>>>> On 2 Feb 2024 at 14:51 +0000, rvg at rvgeerligs.nl, wrote:
>>>>>> Hi Volkan,
>>>>>> 
>>>>>> I implemented the scripting from sip-push-notification-with-opensips-3-1-lts-rfc-8599-supportpart-ii/ in opensips 3.4.0.
>>>>>> As the send pn to apple or googlei s not defined I fail to get the parameters passed to the send pn to apns script which I also have.
>>>>>> 
>>>>>> I seem to have lost the device-ID in opensips or in any INVITE somewhere as I do not understand the RFC certainly not towards the device_ID or token. Or this ID is stored on registration at the proxy?
>>>>>> 
>>>>>> srcipt to directly talk to apple:
>>>>>> https://medium.com/@egzon.arifi/sending-a-push-notification-to-an-ios-device-using-a-bash-script-96c056c1544c
>>>>>> 
>>>>>> Please keep me posted on what you find.
>>>>>> 
>>>>>> Regards, Ronald
>>>>>> 
>>>>>> February 2, 2024 at 6:01 AM, "johan" <johan at democon.be> wrote:
>>>>>> send a query directly to apple or to google for waking them up. I did something like that in an external lua script.
>>>>>> On 2/02/2024 09:49, Volkan Oransoy wrote:
>>>>>> Hi all,
>>>>>> I am working on implementing RFC 8599 and have an architectural question. I followed the blog post https://blog.opensips.org/2020/06/03/sip-push-notification-with-opensips-3-1-lts-rfc-8599-supportpart-ii/ and it works. Based on the rfc and the implementation of Opensips, the UA should have a valid registration throughout the process. When a lookup performed, opensips finds the pn-enabled record, triggers the PN and after a re-registration of the UA, it proxies the call. This process works without an issue. But when we kill the UA on the client device (the client is connected via WSS), after the registration expires, the call can't be proxied since there is no registration. 
>>>>>> I want to wake up the UA even if there is no registration on the proxy and suspend the call until the UA registers to the system. Should I handle this scenario with a custom setup? How do you handle this scenario on your setups? Or do I misinterpret the rfc? 
>>>>>> Thanks
>>>>>> 
>>>>>> Volkan
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users at lists.opensips.org
>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users at lists.opensips.org
>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at lists.opensips.org
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>> 
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> 