Hi list,
My team are developing a SIP client for mobile running iOS ,
then having to deal with the "back ground mode" problem while this soft is installed on mobiles
One of the solutions is using APNS. (Apple Push Notification Service)
I wanna to use Kamailio as SIP Redirect / Proxy for my current SIP server
The model is like that:
User A <---------> Kamailio <---------> SIP server <--------> User B
IF UserA call UserB, UserB is not available now (not registered yet), normally, SIP server will reply Kamailio with "404 Not found"
In that case, i want to set up Kamailio do the communication with APNS and waiting for UserB "Wake up" then RESEND the Invite message ...... (instead of forwarding this 404 message to UserA)
I am getting stuck at how Kamailio can control "404 Not found" message which it receives from SIP server .
I do searching around several days but still can not get any clearer points.
Please help me with some instruction/ configuration of Kamailio for this case !
Thank you very much.
Hi!
You have to use a failure route (http://kamailio.org/docs/modules/3.3.x/modules/tm.html#t_on_failure).
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.
regards Klaus
[1] http://kamailio.org/docs/modules/3.3.x/modules_k/tmx.html#id2535968 [2] http://kamailio.org/docs/modules/3.3.x/modules/mqueue.html
On 24.07.2012 06:02, Duong Manh Truong wrote:
Hi list,
My team are developing a SIP client for mobile running iOS ,
then having to deal with the "back ground mode" problem while this soft is installed on mobiles
One of the solutions is using APNS. (Apple Push Notification Service)
I wanna to use Kamailio as SIP Redirect / Proxy for my current SIP server
The model is like that:
User A <---------> Kamailio <---------> SIP server <--------> User B
IF UserA call UserB, UserB is not available now (not registered yet), normally, SIP server will reply Kamailio with "404 Not found"
In that case, i want to set up Kamailio do the communication with APNS and waiting for UserB "Wake up" then RESEND the Invite message ...... (instead of forwarding this 404 message to UserA)
I am getting stuck at how Kamailio can control "404 Not found" message which it receives from SIP server .
I do searching around several days but still can not get any clearer points.
Please help me with some instruction/ configuration of Kamailio for this case !
Thank you very much.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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
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