Closed GoogleCodeExporter closed 9 years ago
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
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
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
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
Issue 1092 has been merged into this issue.
Original comment by r3gis...@gmail.com
on 22 Jun 2011 at 6:36
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
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
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
Original issue reported on code.google.com by
jad...@gmail.com
on 5 Apr 2011 at 10:39