[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Linphone-users]TrueSpeech codec

From: Simon Morlat
Subject: Re: [Linphone-users]TrueSpeech codec
Date: 26 May 2003 11:59:50 +0200

> 1. Take the relevant code from Linphone and
> incorporate it into the messaging client.  The
> advantage of this is that the Linphone codebase is
> not "polluted" with support for the TrueSpeech
> codec or anything else. The disadvantage of this
> scheme is the user now has two separate places to
> configure soundcard settings, and there will be
> sound device conflicts when a user has the
> messenger running a voicechat and a Linphone call
> comes in, etc.
Don't worry about the sound device conflict. A sound conflict happens
every time between mp3 players and linphone. The conflict problem will
be solved the day artsd or esd will provide good recording capabilities.

> 2. Remote control of Linphone.  The messaging
> client (Yahoo or in the future MSN messenger,
> etc.) could command an already-running Linphone
> process to initiate or answer a voice call on a
> given port with a given codec, etc.  The messenger
> client would handle all proprietary call setup and
> signalling, and Linphone would just handle fairly
> standard RTP streams carrying voice traffic (but 
> maybe with a proprietary codec).  Linphone then 
> becomes a central place for controlling volume 
> levels, sound setup, etc.  It
> also seems like a nice division of labor between
> the two apps.  Of course Linphone would also need
> to notify the requesting app when the call is
> ended for whatever reason, etc.  For this to work
> the TrueSpeech codec would need to be added into
> Linphone as well as some form of IPC with other 
> apps.  One can even envision the possibility of a 
> 3-way call with another Linphone user via SIP and 
> a Yahoo user via its protocol.
This is a very nice solution. I think the Yahoo messenger should then
initiate a SIP call to linphone and put in the SDP message the correct
settings (port, codec). Then the user would ring and the user would have
to accept the call as normally. The Yahoo messenger would receive the
200 Ok from linphone and then do the necessary signaling to the remote
Yahoo messenger. Doing as this, linphone does not need any modifications
in its interfaces.

> Of course, starting off with option 1 and later
> migrating to option 2 is a possibility as well.
I think this is easyest way for you.
> Assuming I use code from Linphone to do this, with
> either option I will most likely add support for
> the TrueSpeech codec into my copy of Linphone to
> test out the concept.  I would be happy to provide
> this back to the Linphone developers if it is
> wanted.  Having that infrastructure in the
> codebase could also allow other proprietary codecs
> to be used, but only on x86 boxes (since x86 
> Windows .dlls would be used).

I would be very interested in having this dll support in linphone.
That's why I suggest the following:
First step:
* you add support for TrueSpeech codec in linphone, I can take in charge
the signaling side for this codec (all code that is not in
mediastreamer/), if you wish
* you take the linphone code into your messenger to test all that.

Second step:
* you implement the Yahoo-to-SIP call forwarding. If you need help, I'm

What do you think of that ?
I can provide you rw access to linphone's cvs, to avoid wasting time in
merging patches.
Note that linphone-0.11.0 is already deprecated compared to the cvs
code... No changes in mediastreamer, but some important changes in the
way linphone understands codecs.
I'm waiting for your comments.
> Comments and suggestions are appreciated.
> -Rob
> PS.  Yes, I wish all the messengers would get
> together and standardize on SIP and allow various
> codecs to be used.  Until then I'm willing to put 
> some effort in to be able to talk to more people 
> while running Linux.
> _______________________________________________
> Linphone-users mailing list
> address@hidden
Simon Morlat <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]