[SR-Users] Kamailio with APNS

[Klaus Darilion]

On 24.07.2012 16:32, Andreas Granig wrote:
> 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

interesting ....

> 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).

Or on the last branch spiral the INVITE to Kamailio again (dirty :-)

>
> 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 :)

Indeed nice :-)

Klaus