easyb2k-devel — EasyB2k development.

Re: [Easyb2k-devel] Application Structure

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

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

Thomas Reitmayr wrote:
>   VoIP application
>         ^
>         |   (any protocol, depending on VoIP application)
>         v
>   Glue Software (most likely a separate component, like gnomemeeting
>  connector)
>         ^
>         |   (D-BUS)
>         v
>   Our Daemon
	Originally my idea was:

        VoIP app
            ^
            |   (any protocol, preferably D-BUS)
            v
- ---------------------------
|      Glue PLUGIN        |
|           ^             |
|           |   (libdl)   |----> Our Daemon
|           v             |
|      Daemon Core        |
- ---------------------------

	All GPL software will most likely use a "standard" protocol using D-BUS
as transport, but the glue on a plugin keeps it flexible enough to
support everything else.
	The Daemon Core needs to support _multiple glue plugins_, to allow us
to use N Voip applications with one hardware device.

> Now a question:
> You discussed that there could be a "single device" mode (i.e. grab the one device available) and a "multi-device" mode, which requires a command-line argument to the daemon or, if missing, asks for for it.
> Now what I am not 100% understanding in this setup is:
> 1. Who starts the daemon, i.e. who is responsible for supplying the command-line argument?
> 2. How can a user select the right device without diving into the guts of some startup file?
	Config files should only be avoided on the "typical" use case. eg *one*
device. (in fact, a config file would be used even when just one device
is connected, but with a "broad" default configuration, that tries every
glue supported).
	People using more than one device would use a .conf file for each
device, and run multiple instances of the daemon, each using a different
.conf.
	There is no way to guess what VoIP applications the user wants for each
device, nor the order at which HAL will call the daemons, so, for the
multiple device case we cant escape the manual configuration.
	A variation of this idea would be using the same config file for all
the daemons, and defining config sections with the box serial number as
index, this way the daemon can decide which section to use.

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

iD8DBQFHJ+59w3OYl0G0liQRAvLpAJ48CUnZhgqU5TGo1VohqYY53HeQeACggUjv
hNHKooyt0tKJqiFmC0GpWpg=
=x31O
-----END PGP SIGNATURE-----

Re: [Easyb2k-devel] Application Structure

[Thomas R. <tre...@ya...>]

Hi Marcos,=0AI can see how the daemon is launched as soon as a device is pl=
ugged in, via HAL.=0ABut how can the daemon start a certain glue software (=
and maybe the associated VoIP app)? How can one determine how many VoIP app=
s are installed? And what is a VoIP ping?=0AYour pt. 3b looks more practica=
l than 3a but glue software might be part of the VoIP app and started with =
it, not by the daemon, couldn't it?=0AAs long as we do not have nailed down=
 the top-level design and the interfaces between the components (at least t=
o some point) I do not think checking in libyealink makes much sense! It su=
re can serve as one of the sources for the device plugin but probably does =
not resemble the future device plugin. (BTW, I would also like the plugin t=
o be renamed a bit.)=0ARegards,=0A-Thomas=0A=0A=0A----- Original Mail ----=
=0AVon: Marcos <ma...@un...>=0AAn: eas...@li...urceforg=
e.net=0AGesendet: Dienstag, den 30. Oktober 2007, 21:38:21 Uhr=0ABetreff: R=
e: [Easyb2k-devel] Application Structure=0A=0AHi!=0A=0AFirst of all, I beli=
ve the yealink devices can be abstracted to a=0A generic yealink devices, w=
ith=0Acapabilities. Thomas did a great job on his libYealink about that. =
=0A=0AOur design is by now it extremely complicated. Skypemate is simple=0A=
 because it just work with one=0Adevice at the same time.=0A=0AIf you plug =
two devices, it will just pick one at random and ignore the=0A other.=0AThe=
refore you can not have two devices on the same machine. I don't=0A like th=
at.=0ANevertheless you can have more glues (SkypeMate,YahooMate, etc ) on t=
he=0A same machine. The user=0Ajust load the specific WHATEVERmate, and whi=
chever gets loaded first=0A "owns" the device. =0AIn such a scenario, there=
 is always one device and one glue, so the=0A choice is trivial. I don't=0A=
like that either.=0A=0ANow how are going to manage multiple devices and glu=
es without a=0A configuration file ?=0AI can not see any simpler design tha=
n:=0A=0A1) The user plugs a device. =0A2) The daemon is automatically launc=
hed.=0A3a) If there is just one device and one VoIP program, the specific g=
lue=0A is loaded with the device=0Aas a configuration.=0A( a VoIP ping shou=
ld be implemented by the glues....)=0A3b) The daemon gets the device's seri=
al number and launches/loads the=0A right glue (informing which=0Adevice th=
e glue should use) according to the configuration file.=0A=0ANotes:=0A- If =
the glue talks to the device thought the deamon, it will talk=0A through a =
generic device, with=0Acapabilities.=0A- If the glue talks directly ( and I=
 can not see a reason for that, the=0A daemon closes )=0A=0ATo make things =
simple for the user, a configuration program could be=0A implemented and po=
p up=0Awhenever the second device gets plugged. We could have two special=
=0A devices called "GLUE DISABLE"=0Aand "ANY DEVICE". Any newly installed g=
lue will be by default connected=0A to the "any device"=0Adevice.=0A=0A=0AI=
 still have not seen/understood anything simpler.... Daniel, your=0A sugges=
tion does not handle=0Amultiple glues per device.=0A=0ABy the way, I implem=
ented a program called lsYealink, which list the=0A yealink devices. It is =
in the=0ASVN. (sf.net/easyb2k) =0AThomas, please upload libyealink to the s=
vn, so I can add my code to=0A it.=0A=0A=0AMarcos=0A=0A=0A--- Thomas Reitma=
yr <tre...@ya...> schrieb:=0A=0A> Hi,=0A> after reading through the =
various emails I missed before, I have a=0A few=0A>  comments / suggestions=
 / thoughts:=0A> =0A> * Using D-BUS instead of UNIX sockets sounds like a g=
ood idea. Using=0A>  David's drawing the structure would look like=0A> =0A>=
   VoIP application=0A>         ^=0A>         |   (any protocol, depending =
on VoIP application)=0A>         v=0A>   Glue Software (most likely a separ=
ate component, like gnomemeeting=0A>  connector)=0A>         ^=0A>         =
|   (D-BUS)=0A>         v=0A>   Our Daemon=0A> =0A> * Also I love the idea =
of using HAL, it provides enough information=0A for=0A>  the daemon to load=
 the appropriate low-level device plugin (i.e.=0A>  libyealink) and notifie=
s the daemon about new or removed devices.=0A The retrieval of the serial=
=0A> number (or any other distinctive value) could then be implemented in=
=0A the driver plugin.=0A> =0A> Now a question:=0A> You discussed that ther=
e could be a "single device" mode (i.e. grab=0A the one device available)=
=0A> and a "multi-device" mode, which requires a command-line argument to=
=0A the daemon or, if missing,=0A> asks for for it.=0A> Now what I am not 1=
00% understanding in this setup is:=0A> 1. Who starts the daemon, i.e. who =
is responsible for supplying the=0A command-line argument?=0A> 2. How can a=
 user select the right device without diving into the=0A guts of some start=
up file?=0A> =0A> What I have in mind would be a daemon which consists of t=
he following=0A components:=0A> =0A> a. The daemon core which is only respo=
nsible for =0A>    - providing the D-BUS object any glue initially connects=
 to=0A>    - tracking available devices via HAL=0A>    - dynamically loadin=
g the device plugin depending on HAL's device=0A properties=0A>    - spawni=
ng a daemon device manager (see b.) for a specific device=0A by request of =
glue software=0A>    - providing a list of available devices by request of =
glue=0A software=0A> =0A> b. The daemon device manager, which is instantiat=
ed for each device=0A when it is requested by glue=0A> software and which=
=0A>    - provides the main D-BUS interface for the phone functionality on=
=0A one side=0A>    - talks to the device plugin on the other side=0A>    -=
 could also implement DTMF or Bell 202 signaling if required by=0A phone (i=
mplementation=0A> detail)=0A>    - also (via D-BUS) provides information ab=
out configuration=0A parameters and methods for=0A> setting/getting these p=
arameters (Note: The parameters depend on the=0A selected phone model.)=0A>=
 =0A> The device plugin(s) could have the following tasks:=0A> - provide a =
defined interface to the daemon, including advertising=0A some low-level ca=
pabilities=0A> if that makes sense for easier implementation of the daemon =
device=0A manager=0A> - provide a unique ID for a specific phone to be pass=
ed on all the=0A way up to the glue software=0A> to later identify the phon=
e=0A> - implement the low-level USB calls to the device.=0A> =0A> With this=
 infrastructure the glue software would register with the=0A daemon core an=
d if it does=0A> not know about a previously selected specific device, ask =
the daemon=0A core for the first=0A> available device. It could also prompt=
 the user to select one of the=0A available devices. If the=0A> glue softwa=
re has found an already selected device ID in its=0A configuration, it coul=
d ask for=0A> that specific device only.=0A> >From this point on it would o=
nly talk to the newly created daemon=0A device manager about=0A> configurat=
ion parameters and then about the general phone operation.=0A> =0A> Did I m=
iss KISS?=0A> Is this too complicated, is there a simpler structure allowin=
g=0A similar convenience like=0A> SkypeMate?=0A> =0A> Regards,=0A> -Thomas=
=0A>  =0A> =0A> =0A>       Machen Sie Yahoo! zu Ihrer Startseite. Los geht'=
s: =0A> http://de.yahoo.com/set=0A> =0A>=0A -------------------------------=
------------------------------------------=0A> This SF.net email is sponsor=
ed by: Splunk Inc.=0A> Still grepping through log files to find problems?  =
Stop.=0A> Now Search log events and configuration files using AJAX and a=0A=
 browser.=0A> Download your FREE copy of Splunk now >> http://get.splunk.co=
m/=0A> _______________________________________________=0A> Easyb2k-devel ma=
iling list=0A> Eas...@li...=0A> https://lists.source=
forge.net/lists/listinfo/easyb2k-devel=0A> =0A=0A=0A-----------------------=
--------------------------------------------------=0AThis SF.net email is s=
ponsored by: Splunk Inc.=0AStill grepping through log files to find problem=
s?  Stop.=0ANow Search log events and configuration files using AJAX and a =
browser.=0ADownload your FREE copy of Splunk now >> http://get.splunk.com/=
=0A_______________________________________________=0AEasyb2k-devel mailing =
list=0AE...@li...=0Ahttps://lists.sourceforge.net/=
lists/listinfo/easyb2k-devel=0A=0A=0A=0A=0A=0A      Heute schon einen Blick=
 in die Zukunft von E-Mails wagen? Versuchen Sie=B4s mit dem neuen Yahoo! M=
ail. www.yahoo.de/mail

Re: [Easyb2k-devel] Application Structure

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

Hi!

First of all, I belive the yealink devices can be abstracted to a generic yealink devices, with
capabilities. Thomas did a great job on his libYealink about that. 

Our design is by now it extremely complicated. Skypemate is simple because it just work with one
device at the same time.

If you plug two devices, it will just pick one at random and ignore the other.
Therefore you can not have two devices on the same machine. I don't like that.
Nevertheless you can have more glues (SkypeMate,YahooMate, etc ) on the same machine. The user
just load the specific WHATEVERmate, and whichever gets loaded first "owns" the device. 
In such a scenario, there is always one device and one glue, so the choice is trivial. I don't
like that either.

Now how are going to manage multiple devices and glues without a configuration file ?
I can not see any simpler design than:

1) The user plugs a device. 
2) The daemon is automatically launched.
3a) If there is just one device and one VoIP program, the specific glue is loaded with the device
as a configuration.
( a VoIP ping should be implemented by the glues....)
3b) The daemon gets the device's serial number and launches/loads the right glue (informing which
device the glue should use) according to the configuration file.

Notes:
- If the glue talks to the device thought the deamon, it will talk through a generic device, with
capabilities.
- If the glue talks directly ( and I can not see a reason for that, the daemon closes )

To make things simple for the user, a configuration program could be implemented and pop up
whenever the second device gets plugged. We could have two special devices called "GLUE DISABLE"
and "ANY DEVICE". Any newly installed glue will be by default connected to the "any device"
device.


I still have not seen/understood anything simpler.... Daniel, your suggestion does not handle
multiple glues per device.

By the way, I implemented a program called lsYealink, which list the yealink devices. It is in the
SVN. (sf.net/easyb2k) 
Thomas, please upload libyealink to the svn, so I can add my code to it.


Marcos


--- Thomas Reitmayr <tre...@ya...> schrieb:

> Hi,
> after reading through the various emails I missed before, I have a few
>  comments / suggestions / thoughts:
> 
> * Using D-BUS instead of UNIX sockets sounds like a good idea. Using
>  David's drawing the structure would look like
> 
>   VoIP application
>         ^
>         |   (any protocol, depending on VoIP application)
>         v
>   Glue Software (most likely a separate component, like gnomemeeting
>  connector)
>         ^
>         |   (D-BUS)
>         v
>   Our Daemon
> 
> * Also I love the idea of using HAL, it provides enough information for
>  the daemon to load the appropriate low-level device plugin (i.e.
>  libyealink) and notifies the daemon about new or removed devices. The retrieval of the serial
> number (or any other distinctive value) could then be implemented in the driver plugin.
> 
> Now a question:
> You discussed that there could be a "single device" mode (i.e. grab the one device available)
> and a "multi-device" mode, which requires a command-line argument to the daemon or, if missing,
> asks for for it.
> Now what I am not 100% understanding in this setup is:
> 1. Who starts the daemon, i.e. who is responsible for supplying the command-line argument?
> 2. How can a user select the right device without diving into the guts of some startup file?
> 
> What I have in mind would be a daemon which consists of the following components:
> 
> a. The daemon core which is only responsible for 
>    - providing the D-BUS object any glue initially connects to
>    - tracking available devices via HAL
>    - dynamically loading the device plugin depending on HAL's device properties
>    - spawning a daemon device manager (see b.) for a specific device by request of glue software
>    - providing a list of available devices by request of glue software
> 
> b. The daemon device manager, which is instantiated for each device when it is requested by glue
> software and which
>    - provides the main D-BUS interface for the phone functionality on one side
>    - talks to the device plugin on the other side
>    - could also implement DTMF or Bell 202 signaling if required by phone (implementation
> detail)
>    - also (via D-BUS) provides information about configuration parameters and methods for
> setting/getting these parameters (Note: The parameters depend on the selected phone model.)
> 
> The device plugin(s) could have the following tasks:
> - provide a defined interface to the daemon, including advertising some low-level capabilities
> if that makes sense for easier implementation of the daemon device manager
> - provide a unique ID for a specific phone to be passed on all the way up to the glue software
> to later identify the phone
> - implement the low-level USB calls to the device.
> 
> With this infrastructure the glue software would register with the daemon core and if it does
> not know about a previously selected specific device, ask the daemon core for the first
> available device. It could also prompt the user to select one of the available devices. If the
> glue software has found an already selected device ID in its configuration, it could ask for
> that specific device only.
> >From this point on it would only talk to the newly created daemon device manager about
> configuration parameters and then about the general phone operation.
> 
> Did I miss KISS?
> Is this too complicated, is there a simpler structure allowing similar convenience like
> SkypeMate?
> 
> Regards,
> -Thomas
>  
> 
> 
>       Machen Sie Yahoo! zu Ihrer Startseite. Los geht's: 
> http://de.yahoo.com/set
> 
> -------------------------------------------------------------------------
> 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
> 

[Easyb2k-devel] Application Structure

[Thomas R. <tre...@ya...>]

Hi,=0Aafter reading through the various emails I missed before, I have a fe=
w=0A comments / suggestions / thoughts:=0A=0A* Using D-BUS instead of UNIX =
sockets sounds like a good idea. Using=0A David's drawing the structure wou=
ld look like=0A=0A  VoIP application=0A        ^=0A        |   (any protoco=
l, depending on VoIP application)=0A        v=0A  Glue Software (most likel=
y a separate component, like gnomemeeting=0A connector)=0A        ^=0A     =
   |   (D-BUS)=0A        v=0A  Our Daemon=0A=0A* Also I love the idea of us=
ing HAL, it provides enough information for=0A the daemon to load the appro=
priate low-level device plugin (i.e.=0A libyealink) and notifies the daemon=
 about new or removed devices. The retrieval of the serial number (or any o=
ther distinctive value) could then be implemented in the driver plugin.=0A=
=0ANow a question:=0AYou discussed that there could be a "single device" mo=
de (i.e. grab the one device available) and a "multi-device" mode, which re=
quires a command-line argument to the daemon or, if missing, asks for for i=
t.=0ANow what I am not 100% understanding in this setup is:=0A1. Who starts=
 the daemon, i.e. who is responsible for supplying the command-line argumen=
t?=0A2. How can a user select the right device without diving into the guts=
 of some startup file?=0A=0AWhat I have in mind would be a daemon which con=
sists of the following components:=0A=0Aa. The daemon core which is only re=
sponsible for =0A   - providing the D-BUS object any glue initially connect=
s to=0A   - tracking available devices via HAL=0A   - dynamically loading t=
he device plugin depending on HAL's device properties=0A   - spawning a dae=
mon device manager (see b.) for a specific device by request of glue softwa=
re=0A   - providing a list of available devices by request of glue software=
=0A=0Ab. The daemon device manager, which is instantiated for each device w=
hen it is requested by glue software and which=0A   - provides the main D-B=
US interface for the phone functionality on one side=0A   - talks to the de=
vice plugin on the other side=0A   - could also implement DTMF or Bell 202 =
signaling if required by phone (implementation detail)=0A   - also (via D-B=
US) provides information about configuration parameters and methods for set=
ting/getting these parameters (Note: The parameters depend on the selected =
phone model.)=0A=0AThe device plugin(s) could have the following tasks:=0A-=
 provide a defined interface to the daemon, including advertising some low-=
level capabilities if that makes sense for easier implementation of the dae=
mon device manager=0A- provide a unique ID for a specific phone to be passe=
d on all the way up to the glue software to later identify the phone=0A- im=
plement the low-level USB calls to the device.=0A=0AWith this infrastructur=
e the glue software would register with the daemon core and if it does not =
know about a previously selected specific device, ask the daemon core for t=
he first available device. It could also prompt the user to select one of t=
he available devices. If the glue software has found an already selected de=
vice ID in its configuration, it could ask for that specific device only.=
=0AFrom this point on it would only talk to the newly created daemon device=
 manager about configuration parameters and then about the general phone op=
eration.=0A=0ADid I miss KISS?=0AIs this too complicated, is there a simple=
r structure allowing similar convenience like SkypeMate?=0A=0ARegards,=0A-T=
homas=0A =0A=0A=0A      Machen Sie Yahoo! zu Ihrer Startseite. Los geht's: =
=0Ahttp://de.yahoo.com/set

Re: [Easyb2k-devel] Currently subscribed emails.

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

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

Daniel Ribeiro wrote:
> Hi guys,
> 
> 	Currently, the following emails are subscribed to this list.
> tre...@us...
Err, Thomas, im sorry, it was a cutnpaste glitch on your email address.
My fault. :/

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

iD8DBQFHJqidw3OYl0G0liQRAsSqAKCHr9Ttbznj0K2rquzowP/HoaYIJwCfUPX5
lrQhg0jEJ0WxUxF7V8HxX5g=
=xjzU
-----END PGP SIGNATURE-----

Re: [Easyb2k-devel] Missed "my" subscription

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

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

Thomas Reitmayr wrote:
> Hi there,
> it looks like some incorrect address was added to the list, because I just noticed a moment ago that the list is already set up. So I subscribed myself - have to catch up with the emails now ;)
Welcome. :)
Sorry, i subscribed your @users.sourceforge.net email.
If you note something wrong with the archives, please let me know. ;)

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

iD8DBQFHJp6hw3OYl0G0liQRAmkkAJwO5LOjEuV3Mp2f5mngtVf6QtPAzgCdEptf
OIvuH2RAP+VkPZlgf6mt3WU=
=l4Yk
-----END PGP SIGNATURE-----

[Easyb2k-devel] Missed "my" subscription

[Thomas R. <tre...@ya...>]

Hi there,=0Ait looks like some incorrect address was added to the list, bec=
ause I just noticed a moment ago that the list is already set up. So I subs=
cribed myself - have to catch up with the emails now ;)=0A-Thomas=0A=0A=0A=
=0A=0A      Machen Sie Yahoo! zu Ihrer Startseite. Los geht's: =0Ahttp://de=
.yahoo.com/set

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

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

Hi!

At least with Skype, we do not need to bother about generating DTMF 
tones locally. Skype does it for us: The API implements SET CALL DTMF X 
(where X is [1-9], * ,  # ). So I won't bother with DTMFs for now.

The whole reason I want to port B3G for Linux is that I have a cell 
phone plan which allows everybody in my family to call themselves for 
free. So if I buy another cell phone and install it in my b3g (whith an 
SIM/PSTN adaptor), I could have my Skype phone call forwarded to my cell 
phone. By now one can do this with windows, but one can not attribute on 
specific phone number for each contact. If I could do that, I would add 
my whole family to this Skype account and if a friend of my sister 
called, I could have his skype call forwarded to her cell phone, for 
exemple.

Gottago

Marcos

Simon DIble wrote:
> 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 

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
> 
> 

Re: [Easyb2k-devel] Currently subscribed emails.

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

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

Simon Dible wrote:
> Everything is working ok for me, thanks.
Changed your subscribed email to s.a...@di..., please
ignore the Subscription/Unsubscription email that you received.

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

iD8DBQFHI69Ow3OYl0G0liQRAiwPAJ9Paj3aNFyMQ1CdPsbwBheqcvFqygCcCgms
r43maeTmeWn2VU0jC56eznM=
=DHQf
-----END PGP SIGNATURE-----

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-----

Re: [Easyb2k-devel] Currently subscribed emails.

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

Everything is working ok for me, thanks.

> Message Received: Oct 27 2007, 08:17 PM
> From: "Daniel Ribeiro" <dr...@gm...>
> To: eas...@li...
> Cc: 
> Subject: [Easyb2k-devel] Currently subscribed emails.
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi guys,
> 
> 	Currently, the following emails are subscribed to this list.
> 
> ma...@un...
> sim...@us...
> tre...@us...
> dr...@gm...
> 
> 	Just reply to this email in case some email is wrong, and i will fix
> it. (or, re-subscribe with the correct address).
> 
> 
> Sorry if this email gets duped, i am sending it again after disabling
> the "digest" option for new subscribers.
> 
> - --
> Daniel Ribeiro
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> 
> iD8DBQFHI5v1w3OYl0G0liQRAo7lAKCb6bAq0B+Z461s5PWK8VR4n2T0LACfXFng
> 4zLcImYOb5V/EsfQaiVx9os=
> =e0Vx
> -----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
> 
> 

[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-----
> 

[Easyb2k-devel] Currently subscribed emails.

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

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

Hi guys,

	Currently, the following emails are subscribed to this list.

ma...@un...
sim...@us...
tre...@us...
dr...@gm...

	Just reply to this email in case some email is wrong, and i will fix
it. (or, re-subscribe with the correct address).


Sorry if this email gets duped, i am sending it again after disabling
the "digest" option for new subscribers.

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

iD8DBQFHI5v1w3OYl0G0liQRAo7lAKCb6bAq0B+Z461s5PWK8VR4n2T0LACfXFng
4zLcImYOb5V/EsfQaiVx9os=
=e0Vx
-----END PGP SIGNATURE-----

[Easyb2k-devel] Currently subscribed emails.

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

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

Hi guys,

	Currently, the following emails are subscribed to this list.

ma...@un...
sim...@us...
tre...@us...
wy...@us...

	Just reply to this email in case some email is wrong, and i will fix
it. (or, re-subscribe with the correct address).

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

iD8DBQFHI5buw3OYl0G0liQRAtvhAKCGwRnuKkmBXVFSDcOw+tFFGXcYQQCglg3G
qJT/twNVow/BIYMCa9eChoU=
=dTKk
-----END PGP SIGNATURE-----

[Easyb2k-devel] testing if the list already works

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

testing if the list already works