iConverged

Hola,

continuing the “season of giving” for Google’s Android, HSC has also ported the popular java stun stack, JSTUN for the android platform. Download it here. 

Update: Nov-20-2008: Updated SDK + UA for 1.0 SDK released here. Also released jSTUN port for android here.

Hi folks, as promised, HSC released the ported SIP UA including the stack. This is an update to our previous ’stack only’ release. We have overwritten the old release with this new one in our download area. You can get it from here (look for the post titled “SIP UA + Stack for Google Android).

This release includes a short illustrative manual on how to use the SIP client and some things you need to do to configure it (mostly because of the limitation of the android emulator and what it does(not) support as of the current date). We have also included a ported RTP stack with this release. Theoretically, this release is all set for a signalling + media use case. I say theoretically, because it seems the android emulator does not support audio capture, so everytime one tries to start a media conversation, the emulator crashes. Folks @ the android-dev group have confirmed this is currently not supported in the emulator (but works on their actual phone).

Read the rest of this entry »

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

 Update: April 2 2008: Source code of stack released here 

Update: Mar 17 2008

See here for a screencast

Update: Mar 12 2008

Some other sites linking here seem to be reporting this news with their own verbiage. Lets be specific on what we are doing:

• We have taken the GPL’d mjsip SIP stack and our objective is to make it work on android (this is mostly a porting activity). We are not writing our own stack.
• We are not doing any optimizations, etc. The scope is exactly what I wrote - make mjsip work on android, so developers can use the mjsip APIs to build apps in android.
• It is a very straighforward ‘take from community (GPL/mjsip), give back to community (post ported code back to GPL/mjsip)’ activity.
• We are targetting to release the port in a week or so… (as-is - as I mentioned the objective is straighforward -a port of mjsip - if it has bugs when you do funky stuff , fix it yourself when we release it )

We (my company) had started an internal project to get SIP working on Android and some smart folks belted out some nifty code to get SIP working on android. We hope to release the ported SIP stack on android pretty soon. We used the GPL’d mjSIP stack and will be releasing the modifications as per GPL, obviously - so other developers have a good SIP API to build apps. This should happen pretty soon. Some time ago, we did a rss-to-presence implementation stub (concept here) over Google Mashup editor. I look forward to seeing the “google-phone” talk SIP to the “google-server” and other cool stuff.

Stay tuned!

Update: I have now created a sidebar widget titled “Tech Blogs I read” instead of updating this post. Please continue sending me quality tech blogs (with more focus on concepts and less on marketing) as you come across them and refer to the sidebar for updates and not this post - thx.

Total number of ‘market reporting’ VoIP blogs = k+1

where k=number of times you can blink in a day.

However, there are very few blogs that talk about more technology & architecture details and less market details for all things VoIP, SIP, IMS, web 2.0 (with focus on telecom).

So here is a call to unite!

We need a list of what I call ‘geek-talk’ - those that provide more technical insight into how things are.

Here is my list so far. Please update me /comment here with more tech-blogs and I will update this list

Many of these blogs are a mix of techno-marketing, but are written by people who are neck-deep in actually developing/architecting many of the talked about solutions themselves, and hence offer a more detailed insight.

last updated: Apr-30-2008

1. TurnGeek - focus on P2P, SBC, etc.
2. IMS Lantern - IMS architecture related
3. Voice of VoIPSA - VoIP Security
4. IMS Quality - Testing and Monitoring with focus on IMS
5. VoIP Survivor - general voip, with significant focus on their company products
6. TelCAB - IMS B/OSS
7. iConverged - this blog

I spoke at the Internet Telephony conference in Los Angeles last week on IMS, hWiMAX, how they all work together (or not) and what it really means to applications. You can see a copy here

Folks, I just wanted to let you know that my company has started a new IMS blog. This is part of our overall IMS consulting services. For now, you will find common posts, so please don’t panic and press the plagiarize button. Both blogs are controlled by me, and I will continue to cross-post as I see fit. The company blog, however, may have some additional posts related to our IMS Standards Tracking package or other such stuff.

Are you surprised by the title? Well, that is really how I see things as it stands today. Based on my discussions with most OEMs and ISVs who have themselves been trialing all over the world for a few years now, we are just about at the phase when most trials are getting out into real deployment. Incidentally, incase you think that IMS all-IP ‘live’ deployments have not yet happened, think again. Remember, in 2006, there was an announcement that Wateem Telecom selected Motorola for a wimax deployment ? Well, that network does data and is ready for voice. Not sure if you knew, but that entire network is over an IMS subsystem (yes, you guessed it – WiMAX on its own is not a session specific architecture, while IMS is, so it makes sense to have IMS on WiMAX, huh ?). And yes, I mean R5+, which is all IP for both signaling and media.

Several green field operators are already deploying or have deployed IMS driven networks (we work with many of them), but very few are touting the IMS name around right now, since IMS has been a long used, much abused and somewhat delayed technology. But make no mistake, IMS powered networks are on the rise. Based on my discussions with several players, IMS deployments are on a steep rise, partly also due to ongoing WiMAX trials. It is worthy to note that most of the WiMAX trials today are to do with ‘high speed data’ and not voice. In other words, WiMAX as it stands today, and defined by WiMAX Forum is only at the IP-CAN level – all the blazing speed for an internet connection. But not voice calls, voice features or the other session level services. And please, don’t tell me “why do we need anything? P2P solves everything!”. Well it doesn’t. You need centralized services for technical and non-technical reasons. For example:

a) Technical: How on earth you do reliably implement a voice mail system and retrieve it when a person is offline ? What happens if the peer node who stored your VM is offline when you come online ?
b) Technical: How do you implement feature interaction ? (example A forwards to B to C, but by mistake C sets a forward to A) since in a P2P network no one has an idea of what service the other has provisioned
c) Technical: How do you implement dial-plans?
d) Non-Technical: What do you do if your “spectrum provider” (you know, in a wireless world, someone is paying for expensive spectrum) blocks VoIP ?

And again, this goes back to my original statement I had made in an earlier post – “IMS is the only architecture that is out there today which supports mobile, fixed and nomadic networks” from a session, policy and interworking perspective. Admittedly some of these areas are still ‘in progress’ from a standards perspective, but it’s the farthest out there in terms of maturity. It was also good to know that Verizon has decided to open up A-IMS and push it to standards bodies. A lot of vendors and operators have done good (but till date proprietary) work on enhancing IMS and filling in gaps, so it is good to see it get more public.

And finally, if you are wondering about my post because you hardly hear IMS being talked about today, this is because we are in the stage between “Hype is Over” to “Deployment is reality”. Here is how is describe it to many: