Hello,
o Andreas Granig on 12/21/2011 01:51 PM:
Hi guys,
I'd like to propose a neat feature for handling mobile clients running
on iphones and androids.
You might be aware that both mobile platforms support a push
notification feature to remotely start certain services/apps. It means
that you can have a mobile sip client provisioned on kamailio, but it
might not be running when a call arrives (that is, it's not registered).
Using the iphone/android notification framework, you can notify the
device to start the client and register the subscriber, then finish call
setup.
There are various ways to hack this together with kamailio and some
third party apps, but here's a proposal for a clean way to do it:
a useful feature!
Some comments
A calls B via kamailio, and kamailio sees that B is not registered.
Either in any case or based on a user preference indicating support for
such a notification, kamailio could send the call to sems. Sems would
subscribe to the registration status on kamailio leveraging the
pua_reginfo module. Sems could play some early announcement (some ring
in the medium term, SEMS SBC should handle REGISTER as well, so that
it already knows which registrations are active, and which not.
If it doesn't do that, subscription to registration status is a good
option.
tone or whatever), send out the push notification to the framework, then
wait for the publish from kamailio to know when the client came online.
Once B is registered, sems could deflect the call back to kamailio (e.g.
with 302), and kamailio would then do the lookup and finish the call
setup. In case of timeout (no PUBLISH within a certain time) it would
unsubscribe and pass back a 4xx error.
Alternatively, the mobile app may be instructed to call back into
SEMS, which could connect the two call legs. This would also lower the
total call setup time.
Not sure about the missing pieces in Sems to do so (support for
SUBSCRIBE/PUBLISH). Comments on that?
Courtesy of TelTech's permission to publish it, I've just added a curl
DSM module, which can be used to access the push API in Cupertino or
Mountain View.
In order to support subscribe and process the notifies, one pretty
easy option is to extend the system DSM, to be able to handle the
subscribe dialog, and pass back the result to the call DSM.
Stefan
Andreas
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
--
tel:+491621366449
sip:[email protected]
mailto/xmpp:[email protected]
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
