Quang Minh Phan wrote:
Hi Vadim,
The main goals of refactoring phapi are:
1. To make it even easier to use.
Great goal,
But i don't really understand the new system of error codes and new API
methods....
I'm affraid with your current approach you are missing this goal
2. To make it more extendable (Easier to add new functionalities with a new
Plugin system. Able to handle all kind of communication sessions (File
transfer, VNC, etc.), not only voice and video.
This is WRONG, WRONG, WRONG.
For the moment there is only 2 sets of RFCs for SIP, which covers
VOIP and IM,
It is simply loss of time to try to implement things as file transfer
or VNC session establishement
using INVITE/200/ACK sequences before there is some standard way to do it.
The best approch is to simply use SIP MESSAGE with an XML payload
describing the session....
and all this stuff should be handled by application itself and not by
phApi....
So there is no reason to extend phApi with plugins in that direction.
Please see more comments inline.
1) Simplicty to design a softphone using the api
Methods to achieve:
- Only one include file
- Very strightforward API with 8 entry points (well at least
initially)
The new APIs are designed to make it even easier to design a softphone. For
example, the old phapi required developer to fill the phcfg global variable
with data before calling phinit. This variable contained many fields that
are not easy to guess. In the new API, we will make this phcfg create setter
and getter functions to modify the values in a much more clearer way, with
error checking, etc.
This is good.
2) Portability
Methods to achieve:
- Using only C ant not C++
- Separation of HW and OS dependent stuff
3) Possibility to run in embedded environement
Methods to achieve:
- choice of oSip eXosip and oRTP -- which gives very low
memeory footprint around 400k
The portability of the code will not be sacrificed.
I believe that i've more or less achieved these goals
I do agree with you.
Of course the with time phApi evolved and in some way drifted from
these intial goals
and additional goals appeared and at least partially reached with the
help of Wengo team and community:
4) video support:
Methods to achive
developement of libwebcam, pixertool and useage of ffmpeg
5) Extensibility with respect to codecs:
Methods to achieve:
developpement of codec plugin framwork
Agree.
I see following additional goals for phApi
5) Support for SRTP and ZRTP
Methods to achieve:
rewamp TUNNEL_XXX set of macros into a notion of stackable
transports for oRTP
so we'll be able to stack one transport on another
We have implemented srtp with phapi. We had to do that by patching eXosip
and oRtp. A goal of the refactoring process is to be able to implement this
kind of feature in the future just by adding a plugin to phAPI. We can
discuss more about this.
6) Extensibility with respect to audio/video devices
Methods to achieve:
developpement of audio/video device plugin framework
7) Simplifying conference API and allowing more than 3 memebers in
the conf call
8) Removing dependencies on C++ when possible:
Methods to achieve:
redesigning libwebcam in C
Effectively, these are also what we would like to have after the refactoring
process.
Another point, wifo should be factored out in separate tree and no to
be part of wengophone....
Best regards,
Minh
Thanks
Vadim
_______________________________________________
Wengophone-devel mailing list
[email protected]
http://dev.openwengo.com/mailman/listinfo/wengophone-devel
