Grab the IMS UA code from the HSC Open Source webpage here

(look for IMS UA for Google Android Entry)

The test bed looked like this:

Caveats

• IMS Sipdroid was tested with a SIPp script for PRACK functionality. Other available IMS clients did not support PRACK functionality.

• PRACK support is implemented for the client side. When the client initiates a call and receives 1xx response with Require: 100rel as header, it will respondwith PRACK. However in case client receives INVITE with Supported:100rel header, it will respond with 180 Ringing without Require: 100relheader.

Usual Disclaimers:

• If something is broken, fix it
• We will try to answer your queries if you are facing problems, but there is no guarantee of timeframes (really, we’d just prefer you debug it yourselves)
• Please don’t ask us for timeframes on what is coming next. It may be tomorrow, it may be next year.

MSRP for Android and RTP stack for Android. And yeah, these releases don’t have additional documentation answering stuff like ‘how do I install’. We hope you know that already :-) And if you need docs on how to use the stacks, please refer to the original open source efforts.

Get them here.

The new SDK changes several things in the UI and well as some APIs. Kudos to the team lead Nitin Khanna (first.last at hsc.com) for continuing the commitment to android. 

Grab a copy of the latest version from here.

(image credit to Engadget)

The biggest problem, however, was not being able to run background applications, which KOed out a lot of neat things one could do, especially for location related apps. At the keynote today at WWDC, Scott Forstall said this:

quoting from engadget’s live blogging:

There has been one feature request that doesn’t currently exist… it’s mainly come from clients like IM, where by their very nature they want to get a notification even if the user isn’t running the app. We absolutely want to solve this problem, the question is how?”

The wrong solution is to enable background processes… to allow an app to continue to run even after their user thinks they quit it.” Windows Mobile, we’re looking at you. Why’s it bad? “First, battery life, it drains power. Second, performance, it sucks up cycles and makes other things feel sluggish.”

“We’ve come up with a far better solution — a push notification service Apple will provide to all developers.

Apple will maintain a persistent IP connection to the phone, where a 3rd party server can ping Apple’s notification service to your device. It can push badges, sounds, and custom textual alerts (like how SMSs look).

“The great thing about this: it scales… it’s a unified push notification service for all devs. It preserves battery life and maintains performance. And it all works over the air — WiFi and cellular. Available in September, but next month we’ll be seeding to devs. This has been an update of the SDK, thank you!”

Ah ha. So Apple is now going to give us developers a means to ‘wake up’ applications based on a trigger that is user defined. So while it’s nowhere as good as offline background processes, at least we can now have an option to ‘wake up’ from external triggers, so I guess we could implement a reverse polling process, at least.

Naturally, it all depends on how well apple manages to keep the IP pipe alive (example, is it _only_ IP? is there any way for that notification to arrive even if IP gets lost, but some other bearer channel (non IP) is open ?

etc. etc.

So let’s see. Time will tell.. when it actually gets rolled out in a few months..

Update: Apr 29 2008: UA+Stack code released here

Hey folks, HSC released the android ported mjsip stack source code.

Grab it from here. Look for the attachment to the post titled “Ported GNU Mjsip stack for Google Android”

If you see a “PDF” icon under that post, don’t worry, its actually a ZIP with source in it. Our website folks will fix that annoyance soon.

Note that this is a “developer’s release”. It will allow you to start building applications using the mjsip stack on android. It’s not an “automatic solution for long distance calling” (as some blogs reported it) – it is a tool for developers within you to make such applications.

We also have a working SIP UA we ported on top of this stack (which we called ‘SIPDroid’ – no points for being imaginative here). We are yet to release that port – will do so in a short while.

Note that this is just a SIP stack. There is no RTP included. We did some initial experiments with porting open source RTP stacks – seems very simple. We may just do it later, or you do it and add to this effort :-)