What if you store the register/unregister event with username/alias username, useragent in a custom table? In case if the useragent matches with their ua.
If a new call arrives and location lookup doesn't return anything, you can query your custom table against the $rU and check the stored useragent. And then you can run your notify stuff or you can do anything with the call. Just an idea. -Laszlo 2013.06.22. 3:34, "microx" <[email protected]> ezt írta: > Hi all, > > I encounter a particular case as follows. I set up a SIP proxy server using > OpenSIPS. An iOS VoIP app is developed to make video calls via the SIP > proxy > server. Due to the Apple's policy, the VoIP app is unable to receive SIP > messages when it enters the background mode. Specifically, a VoIP app in > the > background mode is only allowed to received notifications from the Apple > push notification service server (APNS server). > > So, to make the VoIP app in the background mode receive INVITEs, the SIP > proxy server needs to request the APNS server to notify the app first. My > current approach is below. > > 1. When the VoIP app enters the background mode, it sends a message to make > its registration expire. > > 2. When the SIP proxy receives an INVITE and fails to find the callee from > the location table, the proxy server executes a shell script (via > exec_avp()) that checks whether the callee is using iOS VoIP app in the > background mode and sends a request the APNS server if necessary. > 2.1 If the shell script says the callee is using iOS VoIP app in the > background mode, the INVITE is dropped. > 2.2 Otherwise, "404 not found" response is returned. > > My problem is that INVITEs from caller will be repeatedly sent to the SIP > proxy server (before timeout) if the callee is using iOS VoIP app in the > background mode. Thus, the shell script will be invoked multiple times. I > wonder what mechanism can be used to store the check result of running the > shell script for the first time, leading the shell script to be run "once". > Since such a case is not yet a transaction, avp variable is not applicable. > Any suggestion is greatly appreciated. > > Best regards, > Chen-Che > > > > -- > View this message in context: > http://opensips-open-sip-server.1449251.n2.nabble.com/What-variable-mechanism-is-applicable-to-a-not-yet-transaction-case-tp7586962.html > Sent from the OpenSIPS - Users mailing list archive at Nabble.com. > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
