[OpenSIPS-Users] Push Notification without registration timers

[Callum Guy]

Quick update, since sending my post I have made a small amount of
progress using event_routing.

My prototype is currently doing the following:

- INVITE arrives targeting unregistered device
- Execute launch(rest_post()) to initiate the notification in another process
- Execute async( wait_for_event("E_UL_AOR_INSERT", "aor=UA at DOM", 10),
RESUME_ON_REG);
- (request exits)
- RESUME_ON_REG called when registration arrives
- send provisional reply
- lookup() (ignoring any advice that the user isn't ready without another PN!)
- t_relay() to forward the INVITE to the new registration

This feels like a workable solution although there is some scope for a
race condition as I'd like to book the event waiter before sending the
POST request however I'm not sure that's possible?

I'm hopeful that I can progress and solve the remaining issues shortly..

Happy SIPing all.

On Mon, 15 Feb 2021 at 15:42, Callum Guy <callum.guy at x-on.co.uk> wrote:
>
> Hi All,
>
> Running 3.1 release.
>
> I'm trying to implement a proxy which *only* supports PN-enabled
> devices however I'm running into some implementation issues for my use
> case.
>
> My project is targeting a very low usage subscriber base (users may be
> idle for months) so I'd like to disable the timer based registration
> refresh and simply collect the PNID at time of registration for later
> use. I don't want to lose devices (which may be turned off) through
> contact purging when they don't respond to PN refresh requests. Is
> this possible? If not I'm happy to manually implement an external
> system for tracking PNID to subscriber relationships if that is
> necessary/simpler. Crucially I want to preserve a list of all the
> PNID's associated with a subscriber (i.e. a user with multiple
> devices) for a long time.
>
> The main problem I am running into is transaction parking without
> using the default module implementation. If the location table does
> not contain contact information for these devices I can't use the
> default park/resume features provided by the registrar module even
> though I can load PRID's from another source. At the point of dial I
> want to park the INVITE and dispatch all the notifications however I
> get the impression that these features are under the hood. Is this
> possible at the script level without the magic behind the registrar
> lookup() method or pn_process_purr()?
>
> Furthermore this project runs on a private network so I'm not sure its
> strictly necessary to generate and track PURR values for active
> sessions, is there any reason I can't just store the PRID against the
> dialog and use that to generate PN mid-dialog? Every call passing
> through this proxy will be for PN-enabled devices so this seems like a
> reasonable implementation even if it doesn't conform to RFC 8599?
>
> Thanks,
>
> Callum

-- 





*0333 332 0000  |  x-on.co.uk <https://www.x-on.co.uk>  |   ** 
<https://www.linkedin.com/company/x-on>   <https://www.facebook.com/XonTel> 
  <https://twitter.com/xonuk> **  |  Coronavirus 
<https://www.x-on.co.uk/service/surgery-connect/coronavirus.htm>*


THE 
ITSPA AWARDS 2020 <http://www.itspa.org.uk/itspa-awards> AND Best ITSP - 
Mid Market, Best Software and Best Vertical Solution are trade marks of the 
Internet Telephony Services Providers' Association, used under licence.

X-on
is a trading name of Storacall Technology Ltd a limited company 
registered in
England and Wales.

Registered Office : Avaland House, 110 
London Road, Apsley, Hemel Hempstead,
Herts, HP3 9SD. Company Registration 
No. 2578478.

The information in this e-mail is confidential and for use by 
the addressee(s)
only. If you are not the intended recipient, please notify 
X-on immediately on +44(0)333 332 0000 and delete the
message from your 
computer. If you are not a named addressee you must not use,
disclose, 
disseminate, distribute, copy, print or reply to this email. Views
or 
opinions expressed by an individual
within this email may not necessarily
reflect the views of X-on or its associated companies. Although X-on 
routinely
screens for viruses, addressees should scan this email and any 
attachments
for
viruses. X-on makes no representation or warranty as to the 
absence of viruses
in this email or any attachments.