[Easyb2k-devel] USB B3G protocol sniffed!

[Marcos D. <ma...@un...>]

Hello Everybody!


First of all, Daniel, I am sorry for thinking that you did not want to 
participate on a complicated project. Believe, I am glad you are 
participating!

I have good and bad news. The good news is that I believe I have 
finished modeling the USB B3G. The bad news is that it can not send DTMF 
to the PSTN itself (whenever it grabs the PSTN line and dials). That 
means we have to send it to the audio output of the Yealink device. I 
know that Skype has this feature already, so perhaps we could just not 
implement the DTMF on the daemon/libyealink, to make it ligher. I hope 
to send the full protocol (for now, still as usbb2k_api today). The 
second problem is that when I call a busy number, I do not receive 
(using Yealink's API) a PSTN_BUSY event... I will try at somebody else's 
phone line, to see why that happens...

What I meant  in my last email as the glue would be exactly the peace of 
software between our daemon and the VoIP program. The glue could be 
either developed by us, by the writer of the software or even by a third 
party.

The idea of having one daemon per device is great, but it has a little 
problem.... If you have more than one device per machine, how do you 
choose which device will control which daemon ? Remember that all 
Yealink devices have the same USB manufactore and model ID, and what 
changes is only the model and serial number (one has to know the 
protocol to extract the model and serial number). That pretty much means 
we need a manager to manage all that.

Or does anybody has any better idea ?
I agree with the KISS philosophy, but how to handle multiple devices on 
the same machine ? If we find a solution for that, we will be better 
than Yealink, that does not support more than one hardware per machine.

Marcos

Daniel Ribeiro wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Marcos wrote:
>> Therefore the idea of implementing a libYealink is not a solution, if one plans to have multiple
>> devices on the same computer. What would be optimal is a USB Phone Spooler, so every VoIP app
>> could use the same Yealink device(s), as long as they do it at a different time.
> 	I think it is more a "switcher" than a "spooler". A queue is not
> appropriate as there should be no concurrent use.
> 
>> That pretty much means I could receive from my Telephone not only PSTN and Skype but also Ekiga
>> calls. Also, the USB Phone spooler could in the future take care of Non Yealink hardware. ( the
>> concept is quite simple for answering phone calls. To make a phone call using a specifc VoIP
>> software will be discussed later)
> 	Making a phone call is as easy as assigning a button to cycle among
> voip software.
> 
>> With the exception of Skype, I believe most OpenSource apps will want to implement compatibility
>> with our USB Phone Spooler, i.e. will have the glue included on them. Glues would talk to the
>> phone app through UNIX Sockets, with a protocol very similar protocol of usb b2k daemon (from
>> kb2kskype) (any better ideas ?) (that would me multi platform and programming language agnostic)
> 	D-bus. Unix sockets is too old, and by nature will exclude windows of
> the future development.
> 
> 	You should not rely on other software including a glue to our daemon.
> There may be very different (not only commercial like skype) interests
> involved. If we really want to support different voip software, then we
> need to support pluggable code on the daemon to different application
> control protocols. And this doesnt stops you from defining an API that
> you *hope* that others use, you simply plug the API as any other
> voip_plugin. Or, even better, you just let people interested on your
> daemon write his own plugin.
> 	This solves the issue for skype and any other commercial voip
> application that may became the standard in the future.
> 
>> The phone spooler would handle the lock and release of each USB device to one glue at a time. If
>> one wants to use more VoIP apps than Yealink devices, with a wired logic, (routing, call waiting
>> between many USB devices, asterisk, etc), than one should use a glueMultiplexer, an optional, in
>> the future developed layer, which should talk to the USB Phone Spooler and the glues.
> 	I dont think that the switcher/spooler should handle more than one
> telbox. If you want to handle more than one telbox, you just run another
> instance of the daemon, each instance with his own voip software setup.
> 	There is no need to make things complicated. If you want to run X
> yealink boxes, you register Y skype accounts and another Z ekiga
> accounts, depending on each instance configuration.
> 	If you want all the phones to share the same voip line, then there is
> no need for multiple yealink boxes. Just plug the phone jack to all the
> phones.
> 
>> On the other hand, Daniel will say: Well, that is exactly what I did NOT want. Than I just ask you
>> to use libYealink on your software, so we could have some bug reports, ideas, suggestions and etc.
>>  Also, you could already prepare your software to use the extended b3g features, since they will
>> be soon implemented by libYealink.
> 	I dont want complicated stuff, but, i havent said that i am quitting.
> Please do not speak for me, neither exclude me from the main project.
> 
>> a) to add treitmayr and bugshideout ( Simon already did it) as their project developers
> 	Fine.
>> b) to go to options, turn off the CVS repository and turn on the SVN repository
> 	Mine is already svn.
> 
> 1) If i got it right, your proposal is:
> 
> Skype---|             |---Box1
> Ekiga---|---Spooler---|---Box2
> Other---|             |---Box3
> 
> 	Will the spooler really handle "one glue at a time"? Or can it support
> Box2<->Ekiga concurrently with Box1<->Skype?
> 
> 
> 2) Why not use:
> Skype1---Switcher1---Box1
> 
> And concurrently:
> Skype2---|---Switcher2---Box2
> Ekiga1---|
> 
> And more:
> Skype3---|
> Ekiga2---|---Switcher3---Box3
> Other1---|
> 
> 
> 	I believe that "2" has some advantages.
> 	It will drastically reduce the code compĺexity by eliminating the queue
> and simplifying the route logic to a simple voip_plugin select.
> 	It will improve user experience by not allowing "xxx voip line busy" or
> "wait 10 minutes until your brother finish using skype or use ekiga
> instead".
> 
>> --- Thomas Reitmayr <tre...@ya...> schrieb:
>>> I guess each one of us has his own motivation behind his personal project. Mine was to work on
>>> closing the gap in linux-supported hardware which becomes apparent when trying to use any type
>>> of (USB) handset. Like some projects use the closed-source YLUSBTEL.dll or USBPHONE.ocx, there
>>> should be a piece of software for linux/unix providing an abstract interface to Yealink's or
>>> other vendor's handsets.
> 	At first my intention was to write something nice to allow skype calls
> on my headless server. But after i met you guys, i foresee that we can
> write a kick-ass solution to all usb phones on *nix.
> 
>>> If I understood Marcos correctly, he suggests:
>>> 1. libyealink would need more complete support of the phones' features.
> 	And KISS. (http://en.wikipedia.org/wiki/KISS_principle).
> 	Instead of breaking KISS, trying to support every possible protocol,
> another lib is preferable. The "middleware" may load the libs as necessary.
> 
>>> 2. Daniel could use libyealink for his Skype-"middleware".
>>>    In parallel we would improve libyealink further.
> 	Great!
> 
>>> 3. An additional layer would be added on top of libyealink providing a socket interface, for
>>> example.
> 	I believe that this would be the "middleware".
> 
>>> What I can provide is
>>> * some c programming skills
>>> * libyealink in its currently incomplete state
>>> * a low-level model able to simulate various P1K-compatible devices (B3G not working right now)
>>>   (see http://www.devbase.at/svn/view.cgi/phone-models/trunk/?root=experimental)
>>>   for sniffing and testing purposes.
>>>   It could be improved by adding a simple GUI.
> 	Altough lately i only did embedded kernelspace coding, i believe that
> my contribution may be valuable to the whole project.
> 
>>> So I guess the next step should be some discussion about the whole concept,
>>> layers, interfaces, abstraction levels before starting off. Eg. Simon, you talked about udev
>>> (does this work without a kernel driver?)...
> 	My ideas are expressed above.
> 	Additionally, i think that we should ask on LKML to deprecate the
> yealink input driver.
> 	We should use HAL for the hotplug handling. (http://hal.freedesktop.org).
> 	And, at last, we need a mailing list to avoid such long mails ;)
> 
> - --
> Daniel Ribeiro
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> 
> iD8DBQFHIrBaw3OYl0G0liQRAqrhAJ9iTgiEFEZ7B/majp3Ch3GvaRdgoQCePaCp
> M1ARHwJSmUjMF1TpdKVjoIQ=
> =j+C7
> -----END PGP SIGNATURE-----
>