OnSIP Blog

  • OnSIP
  • OnSIP Blog
  • Our evaluation of Android Gingerbread's native SIP calling with the Nexus S
05
JAN 2011

Posted by Leo Zheng at 01:56 PM EST

36380 reads

Share this

Tags

Google, Gingerbread, Nexus S

Our evaluation of Android Gingerbread's native SIP calling with the Nexus S

This post is now outdated. Please check out our follow-up to this: Android SIP update, published 05/11/11.

About a month ago, I wrote a blog post Google announces native SIP internet calling with Gingerbread. We were excited to see the announcement, but I couldn't suppress my inner skeptic when I read that support for the platform's SIP and internet calling features on devices would be determined by manufacturers and associated carriers.

We got our hands on the Nexus S, and here are some of our initial thoughts on Google's native mobile internet calling:
To make an internet call, you must first have contacts with SIP addresses because the native dialer only allows you to input 10 digit numbers. The Nexus S also does not allow you to do transfers when you're on an internet call. You can have 2 calls up at once, switch between them, and merge them; but, the transfer function is nowhere to be found. I also found that if you have simultaneous internet calls going, and you hang up on one of them, the other call hangs up soon after.

We decided to run the native SIP client on the Nexus S through a full lab test, and here's what we found... This gets a bit technical: In summary, Android 2.3 provides basic SIP functionality, but does not yet implement enough SIP features to support interoperability with OnSIP. The four main issues for OnSIP interoperability are as follows:

  1. The auth user name is not configurable, which is required for registration.
  2. Proxy authentication is not supported, which is required for calls to the PSTN.
  3. SIP Replaces header is not supported, which is required for attended transfers.
  4. INVITES without SDP are not supported, which is required for music on hold.

1) SIP Authentication username not configurable - RFC 3261 Section 22.1

The Android 2.3 supplants the authorization user name with the AOR username. This means that only users who have the same authentication and AOR usernames will register with OnSIP. The inability to configure an authentication username is extremely limiting and is effectively incompatible with OnSIP.

View the trace [click again to close]

2) SIP Proxy-to-User Authentication - RFC 3261 Section 22.3

When Android 2.3 receives the 407 Proxy Authentication Required, it should, if it is able, re-originate the request with the proper credentials. It does not. As OnSIP utilizes this method, services that require authentication (e.g. calling the PSTN) do not work.

We use the authentication request to determine whom to bill. Blocking outbound calls to the PSTN may be an intentional move by Google as it makes it more difficult, although not much more difficult, for people to circumvent cell phone carriers and cut them out of the money loop entirely. If you do not want cell phone carriers' getting any of your money on outbound PSTN calls, there are always downloadable SIP clients, like Bria.

View the trace

3) SIP “Replaces” header not supported - RFC 3891

Android 2.3 does not support the SIP Replaces header. Because OnSIP utilizes this header during attended transfers, Android 2.3 cannot function as the target of attended transfers. Instead, the native app treats the transferee’s call as an additional call. Support for the Replaces header is not a core SIP requirement, but it is a requirement for OnSIP to support attended transfers.

View the trace

4) Rejecting INVITE without session offer - RFC 3261 Section 13.3.1.3

Android 2.3 rejects re-invites when the INVITE does not contain the Session Description Protocol, or SDP. OnSIP Music on Hold utilizes this functionality. In the following SIP trace, a Polycom 550 attempts to place Android 2.3 on hold (where we re-invited for our Hold Music) and Android 2.3 rejects the call with a 486 Busy Here.

View the trace

So what have we learned today? Native SIP support in Android 2.3 in its current form is fine if you just want to make/receive SIP calls. Additional features for business users will require some updates to the software.

Comments

Mark Murphy (not verified)

Wed, 01/05/2011 - 20:15

Filed as issues

I have taken the liberty of filing your four points as issues on the public issue tracker. #3 I filed as a feature request, the others as bugs, since it appears that Android 2.3 incompletely supports the SIP spec, from what I can decipher of what you have here. You can find the issues on http://b.android.com as 13740 through 13743.

Leo Zheng

Thu, 01/06/2011 - 11:03

Thanks

We'll be keeping an eye on those.

Curly (not verified)

Sat, 01/15/2011 - 02:47

More observations

Hi Leo, thank you for posting this excellent article. I hope the Nexus S / Android 2.3 SIP stack implementation improves because I found that using Google's very own Google Voice with the Nexus S SIP settings configured to use SIP via Gizmo5 and Google Voice, along with the Nexus S as a speaker phone, people who I would speak with would complain that they couldn't hear the beginning of what I was stating every time I would begin to speak. This may be more of a Nexus S speaker phone / microphone issue and might have nothing to do with the SIP stack implementation. However, I also have an unlocked Nokia E71 (with the Symbian SIP stack implementation) to compare with (am about to do this). That being said and done, have you tested OnSIP with the Nexus S / Android 2.3 with its built-in SIP stack on calls using the Nexus S as a speakerphone? What about latency issues? note: I'm grandfathered into the legacy via Gizmo5 SIP service which Google no longer is accepting signups for (after Google acquired Gizmo5). This isn't to take anything away from OnSIP, but in the philosophy of being "open" (open source, open protocols), we all need to keep Google in check especially since Google (particularly with Nexus devices) purports open standards. Thank you for keeping Google on its toes! -Curly

Guest (not verified)

Tue, 02/01/2011 - 06:36

Codec and latency

Hi, I wish to know the LATENCY with Speex codec at 8kbps and 16kbps Also wish to know why XMPP-Jingle-VoIP isn't implemented yet on gTalk ? Cheers, Guillermo

Frank Shearar (not verified)

Fri, 02/04/2011 - 07:58

Rejecting bodiless INVITEs

It looks like Gingerbread's badly misinterpreting that INVITE: it's treating the INVITE as a new call (486 Busy Here), but it's clearly an in-dialog INVITE. So either it will reject other in-dialog INVITEs (like renegotiating media) or it's returning the incorrect Status-Code, which should be 488 Not Acceptable Here. (See section 14.2)

Guest (not verified)

Sun, 02/20/2011 - 00:27

is there a way that someone could re-engineer this native sip

Hi Leo read your post, and loved the commentary that you gave on this sip stack that google announced for android. I must admit when I heard about this, I thought wow, google and the mobile carriers are going to actually free people up on minutes as this would allow informed people the ability to make free calls through there mobile networks on there phone but I guess i didn't see the fine print that the sip stack would be kept in check by manufacturers and mobile phone companies, as I thought we would get a full sip stack that allowed us to do fully compatible conference calling and not just one on one, also thought that we would be able to call pstn from sip but as your article pointed out they blocked that feature and as another person commented; why haven't they allowed the calling feature in gtalk for android mobile devices. All in all as I am fed up with this mockery of google or the mobile phone companies for not implementing a fully capable sip stack that allows you the full capabilities of a sip phone, is there a way that someone would be able to take gingerbread source and re-engineer sip stack to have full capabilities of a sip phone, or is it possible to take the sip stack and have it engineered with sipdroid or another sip phone app as the native sip phone built into the core of android and is always on, like lets say the native sip on nokia devices.

Guest (gggirlgeek) (not verified)

Sun, 02/20/2011 - 09:40

Sad because Nokia smart

Sad because Nokia smart phones' new native sip client works wonderfully (I have 5530 with custom C6 firmware.) Android phone's are much more advanced than Symbian. It is obvious Google either does not want the feature or is bowing to pressure from cell providers. (Even iPhone has better apps for this.) Even more humorous: T-mobile stuck a new feature on my G2 -- Wifi Calling. It is simply a setting to reroute your calls to your personal internet service rather than their cell phone network -- supposedly to give you phone access in dead zones, which it does. This saves them bandwidth and money. But they still charge you for normal cell phone minutes! (Some carries even charge you a monthly fee for the "convenience.") But of course they don't share these profits with the ISP who's actually providing the connection. What a tease. What a rip-off! Somebody is bound to hack these settings, in a custom Rom, to allow you to add your own Voip service. Hint hint, modders!

Guest (not verified)

Mon, 02/21/2011 - 01:16

thats the thing though,

thats the thing though, modders/developers who create custom roms might be put at a risk b/c if they do change the sip stack for gingerbread to be a fully functional sip, with sip capabilities with no restrictions, then the carriers might come down on google for making android OS open source and allowing for modders to do that, and can say that they are losing money b/c custom roms allow free calling through internet which they have been trying to block for years. So its a thin line, that i understand, but i don't think cell phone companies should have so much power to influence google on what to do with there own OS, if android users want a feature it should not be a cell phone company who decides whether or not that feature is included in the OS. It should be the people/end users b/c they are the ones paying the cell phone companies not the other way around.

Guest (not verified)

Tue, 05/10/2011 - 16:42

"and can say that they are

"and can say that they are losing money b/c custom roms allow free calling through internet which they have been trying to block for years" They don't have a right to block it. Data is data.

Kirn Gill (not verified)

Sun, 05/08/2011 - 12:33

T-Mobile's Wi-Fi calling isn't SIP

T-Mobile's Wi-Fi calling isn't SIP, it's GAN (Generic Access Network), which is essentially the GSM protocol used with the GSM/UMTS cell network, but over IP. Custom mods would be useless to include custom addresses for the GAN server because the new server needs to fake enough of the GSM core network to trick the phone and the SIM card, as well as authenticate the SIM. This would also require access to the Ki authentication and encryption key stored in the SIM, which is quite a feat on it's own (The SIM is designed to not give out the Ki code)

sirrix (not verified)

Mon, 02/28/2011 - 18:28

Well I've just got SIP

Well I've just got SIP calling running on my Nexus One and I think it's markedly better than you're making it out to be. For starters, you don't need to have any SIP numbers - I can call anyone in the US. How? It's a little bit of a workaround, but you can add a GIZMO SIP number to the phones your Google Voice account will call when you have an incoming call. Once you add that, add the same SIP number to your phone in 2.3's call settings. Now, set up Google Voice on the website to ring both your cell number and your GIZMO number for every incoming call. When you're on wifi, now EVERY incoming call will be a free internet call. Further, if you are on wifi, just go to the Google Voice website from your phone (or PC) and select your GIZMO number as the number on which to call you. Like I said it's a little bit of a workaround, but not enough of a deterrent for me to not be doing it on all halfway-lengthy calls! Essentially, while I'm at home or work, where I'm making most calls anyway, they'll all be free. Excellent upgrade, if you ask me.

Guest (not verified)

Tue, 03/22/2011 - 01:57

In response to the original blog post

I'm from the Android SIP team, we implemented the SIP stack in Gingerbread. I'd just like to point out that of the 4 complaints you raised, 1 & 2 have been fixed in Gingerbread 2.3.3 release update. We have noted 3 & 4 and are considering it. #3 is not a part of the RFC 3261 spec, and so it wasn't originally implemented. #4 as far as we could tell is only proposed under 3725, and there's been no agreement on how to handle 3rd party call control. If there is and you can show it's been ratified as the industry standard, we'd be glad to add it to the support. @another commenter who complained Google blocks sip->pstn calling, this is not true. Gingerbread fully supports pstn termination, as long as your SIP provider supports it. Most SIP providers will charge a fee however, but as long as you pay the fee you should be able to call anyone you want. We've made lots of international calls during our testing and have found no problems.

Erick J Johnson

Tue, 05/10/2011 - 18:26

re: In response to the original blog post

Hi Guest, Glad you stopped by - thanks for reading the post and we're really excited to hear that you guys implemented the work for responding to 407 and configurable auth usernames - that's fantastic. Re: #3 we completely understand that if you guys don't claim to support rfc 3891 (replaces header) then you just don't support it - C'est la vi - however it would be pretty cool if you did ;) Re: #4 perhaps our music on hold implementation has lead to a misunderstanding. The fact that we're using the INVITE w/out SDP signaling mechanism for a MOH implementation is not the issue. The signaling mechanism itself is a legitimate offer/answer model explicitly defined in RFC 3261. The relevant section is quoted here:

13.2.1 Creating the Initial INVITE ... In this specification, offers and answers can only appear in INVITE requests and responses, and ACK. The usage of offers and answers is further restricted. For the initial INVITE transaction, the rules are: o The initial offer MUST be in either an INVITE or, if not there, in the first reliable non-failure message from the UAS back to the UAC. In this specification, that is the final 2xx response. o If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE. For this specification, that is only the final 2xx response to that INVITE. That same exact answer MAY also be placed in any provisional responses sent prior to the answer. The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE. o If the initial offer is in the first reliable non-failure message from the UAS back to UAC, the answer MUST be in the acknowledgement for that message (in this specification, ACK for a 2xx response).

And then later

13.3.1 Processing of the INVITE ... If the INVITE does not contain a session description, the UAS is being asked to participate in a session, and the UAC has asked that the UAS provide the offer of the session. It MUST provide the offer in its first non-failure reliable message back to the UAC. In this specification, that is a 2xx response to the INVITE.

And then even later

14.1 UAC Behavior The same offer-answer model that applies to session descriptions in INVITEs (Section 13.2.1) applies to re-INVITEs. ... Of course, a UAC MAY send a re-INVITE with no session description, in which case the first reliable non-failure response to the re-INVITE will contain the offer (in this specification, that is a 2xx response).

By all means feel free to contact us in the future - and thanks again for replying to the post.

---
Erick J
Junction Networks Engineer

Usman (not verified)

Fri, 05/20/2011 - 17:34

Sip Incoming has a problem on android

I dont know if many of the people have come accross this problem. I have configured a sipgate.co.uk account to my htc desire s. Outgoing seems to work fabulously well but my incoming dies after exact ten minutes. I have tried everything to my knowldege about sip and internet callings and login and authorization codes that i could use but ... the incoming dies after some time. This means my incoming pstn number goes offline and my sip is only active for outgoing and not for incoming. Hopefully, someone from android or htc can rescue the situation. thanks

Guest (not verified)

Tue, 05/24/2011 - 19:05

Android 2.3.3 Sip

Google has done a great work. Regardless to Sip configuration it would also recommended that we can change the Codec (PCMA,PCMU,Speex,GSM etc.)in the stack. For me, it's not working when my WiFi .-) connection is slowly around 64 Kb/s. Dear Guest, you are a Developer from Google. Can you explain how to config this in a file ore some other settings, to resolve my problem. thx

Guest with andr... (not verified)

Fri, 06/03/2011 - 23:08

Hi read your comment and

Hi read your comment and wanted to let you know if you have a root enabled device you can actually use the native sip integration over 3g and wifi, if you know about roms and rooted device you can problem change the sip stack your self or head over to xda developers forum and ask some how to change the sip stack to your liking.

marca56 (not verified)

Fri, 07/01/2011 - 20:10

codec and echo cancelation support

Hi, a few questions... 1. is there any echo cancelation support in the current 2.3.4 implementation? 2. will you support any wide-band codecs like G.722? Thanks. marc.

Guest (not verified)

Thu, 09/22/2011 - 21:26

Sprint blocks voip and

Sprint blocks voip and instead routes calls through their network therefore using minutes instead of data. Any way around that?

mike@junctionne...

Fri, 09/23/2011 - 11:42

Confirmation

Do you have any packet traces to prove it? This would be big news if it can be substantiated.

Add new comment

More information about text formats

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
CAPTCHA
I'm sorry Mr. Turing, but can you please show us that you are a person