Add GTalk/XMPP/Jabber client functionality

[GoogleCodeExporter]

The GTalk peering at PBXes.org recently stopped working. This was the only way 
to use GTalk (and thus Google Voice) as a voice connection on Android.

What if CSipSimple were to work as a voice client for GTalk/XMPP/Jabber? Then 
we could skip PBXes and just connect to our GTalk account directly. It seems 
like the biggest use of SIP is to enable incoming VOIP connections from Google 
Voice anyways. I know it's not SIP and maybe doesn't belong here but there's a 
heck of a lot of overlap and it sure would be nice.

http://xmpp.org/xmpp-protocols/rfcs/

Original issue reported on code.google.com by jad...@gmail.com on 5 Apr 2011 at 10:39

[GoogleCodeExporter]

The goal of CSipSimple is just to provide a full featured SIP client, not to 
support all protocols of the creation.

Besides, SIP allows chat through SIP Message, so up to the service provider 
(google) to do a gateway SIP messages <-> XMPP payloads.

The android OS is very well designed and should allow apps to work together. 
Each app should do one thing but do it well and allow other apps to plug its 
features.

So this feature request is not relevant at all of this project. You should ask 
developpers of the project Beem : http://www.beem-project.com/projects/beem.
If the feature should be somewhere it is the correct place to have it. Not in 
CSipsimple which aim is to be a SIP client, not a XMPP / Jingle client.

Besides : 
> It seems like the biggest use of SIP is to enable incoming VOIP connections 
from Google Voice 

==> No ! You are probably on a contry where google voice is available, but for 
example in my country it's not available, besides our ISP in france provide us 
a SIP account for free that allow free landline calls. So we do not need Google 
Voice at all. Other countries has other telephony states, and SIP is *FAR* to 
be used only with combination of Google Voice. Besides in CSipSimple this 
appearing is not fully tested (obviously I can't test it here).
SIP is also used in Companies with IP-PBXes. So really the goal is not only to 
support Google Voice at all. 

It's to do a SIP client and let users free to choose the provider they want ! 
The approach is just to implement the open protocol. And in android another 
protocol support should be another application ! 
Both apps could interacts through the powerful intents and bindings mechanism 
of android, but one app that do anything is a bad idea.

Original comment by r3gis...@gmail.com on 6 Apr 2011 at 9:33

• Changed state: WontFix

[GoogleCodeExporter]

OK, I am guilty of US-centrism. Sorry! 

I completely understand your desire to do one thing well. But you should 
realize you're currently doing TWO things well--the cip tech and the user 
interface, and the two are somewhat arbitrarily related.

From a user's perspective, "SIP" is just an implementation detail. The part of 
your project that we interact with--the integration, the screens--could work 
(theoretically) just as well with any back-end implementation, SIP, XMPP, 
Skype, whatever. 

And furthermore, your interface is a lot better than the alternatives, which is 
why I want to use it no matter what back-end tech I end up using!

Anyways, thanks for your thoughtful reply.

Original comment by jad...@gmail.com on 6 Apr 2011 at 12:59

[GoogleCodeExporter]

Yes you're absolutely right, there is two parts in the project. 

I try to make things as separate as possible in code so that the SIP User Agent 
+ its android integration is independent from the SIP backend. 
However it's still very linked (at least in terms of features). My goal in the 
future is too allow several SIP backends. For now we use only pjsip-pjsua (it's 
a sip library in C code). In a very near future, I'll allow to use the google 
gingerbread SIP if available on the phone. And in the future hopefully other 
SIP implementations.

For now, my plan is only to support SIP. However, CSipSimple is opensource, so 
if some want to use parts of the code and release a GPL application based on 
different backend it's absolutely possible.

But I think that the feature for the backend should be done in a separate 
project. Beem is a good candidate (GPL license + active devs). As soon as 
they'll get a well featured application, we will consider to allow from 
CSipSimple to access their service. As I said in android UI and service can be 
two different apps. 

For now I release CSipSimple as a block with everything in it (SIP service + 
UI) but it can be split. 
There is already some partners that use CSipSimple in a plugin mode. In this 
case CSipSimple only provide the SIP service and can provide some UI to control 
the communication for example.
If all apps has this kind of level of API and split service and UI as it is 
done in CSipSimple, it will be easy for every app to integrate all other apps 
and services.

So the support of this feature "inside" csipsimple is not relevant yet. As soon 
as an other app will provide this service it will become relevant.
If you ask now to developpers of a GPL xmpp/jabber/jingle application to 
integrate a SIP service, I'll be pleased to help them to provide through the 
CSipSimple API the service inside their app.

Also, just to try to make a comparison with another voip service that can 
already be integrated in csipsimple : CSipSimple support Skype. (Even if I had 
to reverse engineer how to plug to skype application). But you can, inside 
csipsimple, if you have skype installed, make skype calls.
Obviously the integration is limited (cause skype close its application so that 
no others can control their calls). But what is done with skype is already some 
proof of concept that csipsimple could integrated a feature provided by another 
app.

Original comment by r3gis...@gmail.com on 6 Apr 2011 at 1:29

[GoogleCodeExporter]

You are saying that other apps can use the CSip engine, but could a separate 
"GTalk engine" be used by the CSipSimple front-end? 

Ideally, and this is simply from one user's perspective, GTalk could be a type 
of account within CSipSimple alongside the SIP accounts.

Original comment by jad...@gmail.com on 7 Apr 2011 at 12:15

[GoogleCodeExporter]

Issue 1092 has been merged into this issue.

Original comment by r3gis...@gmail.com on 22 Jun 2011 at 6:36

[GoogleCodeExporter]

With ZRTP, SIP TLS and SRTP security included, csipsimple would be outstanding 
if it had implemented the XMPP protocol. 

Original comment by Ingmar.Z...@gmail.com on 14 Aug 2011 at 8:17

[GoogleCodeExporter]

Hi R3gis,

I completely understand your principle of software doing one thing and doing it 
well.  CSipSimple has succeeded very well at that and I hope that stays so.

What it does particularly well is open, standards compliant VoIP, excellent 
platform integration, clean UI, great codec support, ZRTP, polished UX, etc.  
Bare with me, but I think Jingle completely aligns with this.

1. Jingle was specifically designed to have core session management semantics 
that are compatible with SIP.
2. It's also based on open, internet standards protocols.
3. Everything from RTP up stays the same?

Because of those three things, I really believe it's in a completely different 
class to Skype, etc.  The excellent voice & video support, which is 
CSipSimple's focus, aren't something available in Gaim or anything else that 
I'm aware of.  Apart from SIP/RTP, Jingle is the only mainstream open VoIP 
protocol stack.

I think the request might have been better phrased "support Jingle".  The 
requirement isn't particularly about GTalk (G's really just any another 
provider), neither do I think it's meant to focus on IM, which is the immediate 
first thought when people say XMPP.

We all know a network is only as useful as the number of users.  We can't 
prevent fragmentation between SIP & XMPP, that happened long ago when SIMPLE 
failed to gain broad acceptance.  We can only improve interop.  XMPP is widely 
deployed, which helps Jingle's deployment.  It also offers great features, like 
in-band account registration, that could really allow CSipSimple to compete 
head-on with the simple, user-friendly apps the mainstream users are relying on 
for voice & video instead.  To me and a lot of other users, leveraging the XMPP 
infrastructure for voice and video makes absolute sense to get open VoIP more 
widely deployed.

Free, compatible, software is still losing the fight against the walled-gardens 
of Skype, Line, WhatsApp, etc.  SIP's penetration is in single digits or less 
comparatively.  CSipSimple is currently the best chance that free, open, 
secure, standards compliant telephony on mobile has (at least on Android).  
Trying to get friends to install an alternative VoIP client like CSipSimple is 
hard and managing additional accounts is one of those killers.

Adding Jingle would only strengthens CSipSimple's position, not dilute it.

What do you think?

Dave.

Original comment by dlmetc...@gmail.com on 22 Dec 2012 at 11:45

[GoogleCodeExporter]

Some comment about jingle/libjingle. I'm working a lot with it on my full time 
job (where I port webrtc for android).

And it's not standard implementation for the media part. The ICE implementation 
in libjingle for example is something from google and doesn't match 
specifications (and it is a little bit crappy). But good news... they are 
moving to standard way to do things ! But it's not the current way it works ;)

IMHO the real next big thing for open mainstream voice video over IP is not 
XMPP, it's webRTC. 

SIP is for now the voip standard. And it's already widely deployed in world of 
voice/video over IP (enterprises pbxes, IMS of carriers, various sip providers 
-- there is clearly more than xmpp providers, various sip servers opensource 
also clearly more choices than xmpp, standard analog telephony gateways). And 
XMPP for voice/video is not as mature as SIP in terms of 
standardization/features and in terms of implementation where there is only one 
of reference that sometimes ignores standards (libjingle).

Indeed for some feature xmpp is more advanced and mature. Your example about 
in-band registration (xep-0077) is one of these case where xmpp is better. 
But there is also efforts on sip to have same features 
(http://tools.ietf.org/html/draft-petrie-sipping-profile-datasets-05 , 
http://tools.ietf.org/html/draft-petrie-sipping-identity-dataset-02 and 
http://tools.ietf.org/html/rfc6080 ). The reason why it's slower to land in sip 
is that it's IETF RFC and that it takes more time to land, but as you'll notice 
will be more rich in terms of features than the xmpp spec. It's also reviewed 
by more experts eyes and have to be implemented by more people before having as 
big strength as google have when they release something.

Other point, providers are moving to support both xmpp and sip (and sip over 
websocket). So if you have an voip provider kind they will provide both 
protocol. And the only thing that can be discussed is missing features of one 
protocol vs the other.

Last point, I don't mean to strengthen the position of CSipSimple. 
If better technology than SIP that gives more freedom to users arrives, I'll be 
pleased to spend less of my spare time working on CSipSimple and having other 
open projects landing. If users starts preferring some android XMPP client that 
does its jobs well I'll be fine too. It could even be a fork of csipsimple that 
just takes the user interface part... as said in comment 3, the code is 
designed to allow that with low efforts.
In the choice between adding XMPP (or whatever the other open protocol : IAX, 
H323) inside csipsimple and adding missing parts of SIP protocol in the app, I 
choose adding missing part of SIP protocol (such as stuff to automatically 
configure the account). SIP is what the app does, not yet fully and as clean as 
I wish. So before thinking other protocol, let finalize SIP first.

Original comment by r3gis...@gmail.com on 23 Dec 2012 at 1:39