Hi,
On 07/24/2012 03:53 PM, Klaus Darilion wrote:
In the failure route check if the reply code is 404 and if yes, trigger the APNS logic and then put the call e.g. on a stack and resume e.g. every second and ofrward to the "SIP server" again to see if the client is registered meanwhile.
For the asynchronous processing take a look at these functions: t_suspend(),t_resume()[1]. For example you can call t_resume in a timer route every second. For the timer route, to know which transactions are currently suspended and are waiting for further processing, you could put the transaction identifiers in a message-queue [2] and read the queue from the timer route.
We've looked into that a year ago. Not sure how much the asynch processing progressed in the meanwhile, but back then there were a couple of show stoppers which prevented us to go this path.
As a plan B we instead opted for sending via uac module the invite to an oversip instance (it's open-source since a week or two), which triggers an HTTP request towards APNS, and on kamailio check with inv-timers every few seconds whether the client came online in the meanwhile, then complete the call. The drawback is that you can wait only for so many loop interations due to the max branch limitation in kamailio (you'd need to recompile it to set it higher).
In any case it's not optimal either because of the unnecessary call setup delays, so in our latest sip:provider PRO version we just relay the invite to sems, which triggers an HTTP request to APNS, sends back 183 with early media, sends a subscribe to pua_reginfo module, and once the subscriber comes online, pua_reginfo sends a notify to sems, which in turn passes back a 3xx, and then the call setup completes on kamailio. Not trivial either, but there are no call setup delays, there is media to tell the caller it might take a bit longer (or not), and the call flow is perfectly clean. Yeah, SIP/SIMPLE has its cases where it shines, even though not too many :)
Andreas