Re: [Easyb2k-devel] USB B3G protocol sniffed!

[Daniel R. <dr...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marcos Diez wrote:

> 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!
	Complicated != Big. I am used to work with the Linux Kernel, and i dont
see it as "complicated" (well, some subsystems (v4l for example) are).
But KISS applies just fine to most kernel subsystems.
	Our project may be big, but as long as we keep it modular it will not
break KISS.

> 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...
I still lack proper protocol/b3g knowledge to comment on this. So, i
will retain my comments to a "Thank you, thats great news". :)

> 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.
	Yes, but i believe that you should glue with a different schema. If I
got you right, you proposed:

VoIP application --> Our Fixed Protocol <--> Our Daemon.

	And i am proposing:

VoIP application <--> Any Protocol(via pluggable code) <--> Our Daemon.

	My suggestion keeps *our* code flexible to support any protocol,
instead of requiring other projects to implement our "standard" protocol.
	Remembering (again) that what i proposed still leaves room for your
proposal, the main change is that our "standard" protocol will need to
be implemented inside a plugin.

> 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.
	This is the easy part.
	We scan all the usb buses and respective devices, if *only one* telbox
is found, we simply attach to it and work with a one device configuration.
	If we find *more than one* device, we attach to each not already
attached device, get the serial number, and detach, later we present a
message to the user, requiring a selection of the serial number to
attach to via some option on the commandline, and exit(). Remember that
our daemon *does* know the protocol to extract the serial number.

> 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.
	If by "multiple devices" you meant mutiple *phisical* devices, see above.

	If by "multiple devices" you meant multiple devices *types* (different
hardware), then it depends on the protocol differences. If the protocol
is similar enough, libyealink should implement the "nuances" and provide
an "difference abstracted" API to the daemon. If the protocols are too
different, the daemon itself should detect the *very different* protocol
and dlopen() another library.
	I believe that telboxes from other manufacturers, which will probably
use different protocols will have different manufacturer/product IDs.

- --
Daniel Ribeiro
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHI62xw3OYl0G0liQRAjLVAJ9QKxAURC4cDgBCPYXRTQ/USJ1kugCeJUEB
UcFNrVVSjTDuUBwfVRG47XQ=
=DXvV
-----END PGP SIGNATURE-----