Our evaluation of Android Gingerbread's native SIP with the Nexus S - PART 2

Early this year, we wrote a blog post entitled Our evaluation of Android Gingerbread's native SIP calling with the Nexus S. We ran Android's native SIP client through a series of tests and discovered several interoperability issues with OnSIP. Here are the issues we ran into back in January:

1. The auth user name is not configurable, which is required for registration. [RFC 3261 Section 22.1]
2. Proxy authentication is not supported, whih is required for calls to the PSTN. [RFC 3261 Section 22.3]
3. SIP Replaces header is not supported, which is required for attended transfers. [RFC 3891]
4. INVITES without SDP are not supported, which is required for music on hold. [RFC 3261 Section 13.3.1.3]

We're happy to report that we got a response from a member of the Android SIP team:

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.

We redid our tests and had no issues easily configuring an OnSIP account (#1. The auth user name is not configurable, which is required for registration.). We were also able to dial PSTN numbers (#2. Proxy authentication is not supported, which is required for calls to the PSTN.). I will note that there still doesn't seem to be support for calling SIP addresses without first associating them with your contacts. The native SIP client also only works over Wifi (but you can root your Android and download a custom app as a workaround - not for everyone), and there is no transfer functionality. You can add calls when you're already on the line with someone and start a conference, but transfer isn't supported.

It's understandable that the SIP replaces header is not supported (#3. SIP Replaces header is not supported, which is required for attended transfers), but it would be very cool if they added this.

We do, however, insist that rejecting re-invites when the INVITE does not contain the Session Description Protocol, or SDP, is still an issue that needs to be addressed (#4. INVITES without SDP are not supported, which is required for music on hold).

From Erick J, one of our engineers:

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).

We're thrilled that the Android SIP team has been working on improving their built in SIP client in Gingerbread. It's gotten to the point where you don't even need to download a SIP client to make and receive Internet calls, and that's very exciting. Thanks for taking some feedback from the little guys, and keep up the good work.

What does this mean for you?

If you're running Gingerbread 2.3.3 or later, you have a built-in SIP client in your phone, which makes VoIP that much more accessible. Think of it as another phone within your phone that doesn't use your cellular minutes, and isn't limited by international borders. If VoIP and SIP are completely foreign to you, you can get started immediately by creating an OnSIP account for your business or creating a personal 'Get on SIP' account for yourself.