[SR-Users] Kamailio with APNS

Andreas Granig agranig at sipwise.com
Tue Jul 24 16:32:28 CEST 2012


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120724/76a2eefc/attachment.pgp>


More information about the sr-users mailing list