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

[Simon D. <s.a...@di...>]

Daniel Thanks for setting up the list on your site. 

I've started to port kb2kskype to qt4 and I'll avoid kde libs this time, I can see why it took skype a while to make the switch! As ever I'm sort on time but I'll keep at it. 

I like the idea for the generic layers, let me know if I can help with anything.

Marcos well done on the b3k. What are you trying to do with DTMF? Is this trying to make a deamon make a conference call via pstn? It should be easy enough to generate the tones via alsa if thats all your after, I have a fair bit of sound card signal gen code aroundand can help if you like.

Simon 



> Message Received: Oct 27 2007, 09:28 PM
> From: "Daniel Ribeiro" <dr...@gm...>
> To: eas...@li...
> Cc: 
> Subject: Re: [Easyb2k-devel] USB   B3G protocol sniffed!
> 
> -----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-----
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Easyb2k-devel mailing list
> Eas...@li...
> https://lists.sourceforge.net/lists/listinfo/easyb2k-devel
> 
>