kphone-devel — Mailing list for KPhone developers

Re: Re No 2: [kphone-devel] New Features available

[<kgf...@t-...>]

Mika Mustikkamaki wrote:

> Hi.
>
>
> On Sep 29, 2005, at 10:48 PM, Klaus Fleischmann wrote:
>
>> Klaus Fleischmann wrote:
>>
>>> Juha Heinanen wrote:
>>>
>>>> Klaus Fleischmann writes:
>>>>
>>>> > What I WANT, is to let the develloppement become a part of the 
>>>> KPhone .
>>>> > What I NEED - if the KPhone Project is interested - is a place to 
>>>> > dump my code to.
>>>> > There are to many changes to make diffs.
>>>>
>>>> klaus,
>>>>
>>>> how about hosting further kphone development at your site? people who
>>>> have done it earlier don't anymore have enough resources to properly
>>>> maintain the code.
>>>>
>>>> -- juha
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email is sponsored by:
>>>> Power Architecture Resource Center: Free content, downloads, 
>>>> discussions,
>>>> and more. http://solutions.newsforge.com/ibmarch.tmpl
>>>> _______________________________________________
>>>> kphone-devel mailing list
>>>> kph...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/kphone-devel
>>>>
>>>>
>>> Sorry, I have no side! Please do not missjudge,"@t-online.de" does 
>>> not mean I've something to do with Telecom! I'm interested in 
>>> supporting you concerning maintenace, but granting resources is 
>>> somewhat too expensive for me!
>>> KFl
>>>
>>
>> If I understand Juha correctly, Wirlab lacks on resources to maintain 
>> the KPhone. Giben, this is correct, I see two possibilities:
>>
>> 1. Wirlab continues hosting, but opens the server for an external 
>> maintenance team
>> 2. Kphone is dumped into the SoureForge (which is multi-hosted, if I 
>> understand correctly)
>>
>> In both cases I'd be willing to join the maintenace team.
>>
>> Hoping, I started a discussion with these lines,
>>
>> yours
>>
>> KFl
>
>
> I'd be happy to add new members to the SourceForge KPhone project and, 
> preferrably, appoint someone to admin the project. We already have a 
> SourceForge project for KPhone (obviously, since we're using these 
> mailing lists) but we haven't been uploading the releases to the web 
> site / CVS.
>
> Transferring the current KPhone CVS from Wirlab to SourceForge 
> shouldn't be a problem either.
>
> Cheers,
> Mika
>
>
Mika,
At first I am interested in joining the SourceForge KPhone project. As I 
told earier I have some extensions to the existing
KPhone, I intend to bring in. So would you tell be what i have to do!
I am not shure, if I can do the administration ALONE. I work full time + 
have a family, so time is rare.

Yours

KFl

Re: Re No 2: [kphone-devel] New Features available

[Jan J. <ja...@ip...>]

On 30-09-2005 09:44, Mika Mustikkamaki wrote:
> >
> >If I understand Juha correctly, Wirlab lacks on resources to  
> >maintain the KPhone. Giben, this is correct, I see two possibilities:
> >
> >1. Wirlab continues hosting, but opens the server for an external  
> >maintenance team
> >2. Kphone is dumped into the SoureForge (which is multi-hosted, if  
> >I understand correctly)
> >
> >In both cases I'd be willing to join the maintenace team.
> >
> >Hoping, I started a discussion with these lines,
> >
> >yours
> >
> >KFl
> 
> I'd be happy to add new members to the SourceForge KPhone project  
> and, preferrably, appoint someone to admin the project. We already  
> have a SourceForge project for KPhone (obviously, since we're using  
> these mailing lists) but we haven't been uploading the releases to  
> the web site / CVS.
> 
> Transferring the current KPhone CVS from Wirlab to SourceForge  
> shouldn't be a problem either.

  I would be interested in CVS access too. In addition to that I can
  offer the iptel.org infrastructure if needed.

  We are trying to convert the site to the resource hub for ser, sems,
  rtpproxy, serweb and other freely available SIP software. The site
  will be running Drupal CMS where anyone can easily contribute the
  contents: http://iptel.org/drupal (just testing, no contents)
  http://www.drupal.org

  The free SIP service at iptel.org should become the reference
  implementation of a SIP service, along with documentation of how does it
  work and what software is needed to run something like this (and how
  to configure it).

    Jan.

Re: Re No 2: [kphone-devel] New Features available

[Mika M. <mt...@sj...>]

Hi.


On Sep 29, 2005, at 10:48 PM, Klaus Fleischmann wrote:

> Klaus Fleischmann wrote:
>
>> Juha Heinanen wrote:
>>
>>> Klaus Fleischmann writes:
>>>
>>>  > What I WANT, is to let the develloppement become a part of the  
>>> KPhone .
>>>  > What I NEED  - if the KPhone Project is interested -  is a  
>>> place to  > dump  my code to.
>>>  > There are to many  changes  to make diffs.
>>>
>>> klaus,
>>>
>>> how about hosting further kphone development at your site?   
>>> people who
>>> have done it earlier don't anymore have enough resources to properly
>>> maintain the code.
>>>
>>> -- juha
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by:
>>> Power Architecture Resource Center: Free content, downloads,  
>>> discussions,
>>> and more. http://solutions.newsforge.com/ibmarch.tmpl
>>> _______________________________________________
>>> kphone-devel mailing list
>>> kph...@li...
>>> https://lists.sourceforge.net/lists/listinfo/kphone-devel
>>>
>>>
>> Sorry, I have no side! Please do not missjudge,"@t-online.de" does  
>> not mean I've something to do with Telecom! I'm interested in  
>> supporting you concerning maintenace, but granting resources is  
>> somewhat too expensive for me!
>> KFl
>>
>
> If I understand Juha correctly, Wirlab lacks on resources to  
> maintain the KPhone. Giben, this is correct, I see two possibilities:
>
> 1. Wirlab continues hosting, but opens the server for an external  
> maintenance team
> 2. Kphone is dumped into the SoureForge (which is multi-hosted, if  
> I understand correctly)
>
> In both cases I'd be willing to join the maintenace team.
>
> Hoping, I started a discussion with these lines,
>
> yours
>
> KFl

I'd be happy to add new members to the SourceForge KPhone project  
and, preferrably, appoint someone to admin the project. We already  
have a SourceForge project for KPhone (obviously, since we're using  
these mailing lists) but we haven't been uploading the releases to  
the web site / CVS.

Transferring the current KPhone CVS from Wirlab to SourceForge  
shouldn't be a problem either.

Cheers,
Mika

Re No 2: [kphone-devel] New Features available

[Klaus F. <kgf...@t-...>]

Klaus Fleischmann wrote:
> Juha Heinanen wrote:
> 
>> Klaus Fleischmann writes:
>>
>>  > What I WANT, is to let the develloppement become a part of the 
>> KPhone .
>>  > What I NEED  - if the KPhone Project is interested -  is a place to 
>>  > dump  my code to.
>>  > There are to many  changes  to make diffs.
>>
>> klaus,
>>
>> how about hosting further kphone development at your site?  people who
>> have done it earlier don't anymore have enough resources to properly
>> maintain the code.
>>
>> -- juha
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by:
>> Power Architecture Resource Center: Free content, downloads, discussions,
>> and more. http://solutions.newsforge.com/ibmarch.tmpl
>> _______________________________________________
>> kphone-devel mailing list
>> kph...@li...
>> https://lists.sourceforge.net/lists/listinfo/kphone-devel
>>
> 
> Sorry, I have no side! Please do not missjudge,"@t-online.de" does not 
> mean I've something to do with Telecom! I'm interested in supporting you 
> concerning maintenace, but granting resources is somewhat too expensive 
> for me!
> 
> KFl
> 

If I understand Juha correctly, Wirlab lacks on resources to maintain 
the KPhone. Giben, this is correct, I see two possibilities:

1. Wirlab continues hosting, but opens the server for an external 
maintenance team
2. Kphone is dumped into the SoureForge (which is multi-hosted, if I 
understand correctly)

In both cases I'd be willing to join the maintenace team.

Hoping, I started a discussion with these lines,

yours

KFl

Re: [kphone-devel] New Features available

[Klaus F. <kgf...@t-...>]

Juha Heinanen wrote:
> Klaus Fleischmann writes:
> 
>  > What I WANT, is to let the develloppement become a part of the KPhone .
>  > What I NEED  - if the KPhone Project is interested -  is a place to 
>  > dump  my code to.
>  > There are to many  changes  to make diffs.
> 
> klaus,
> 
> how about hosting further kphone development at your site?  people who
> have done it earlier don't anymore have enough resources to properly
> maintain the code.
> 
> -- juha
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> kphone-devel mailing list
> kph...@li...
> https://lists.sourceforge.net/lists/listinfo/kphone-devel
> 

Sorry, I have no side! Please do not missjudge,"@t-online.de" does not 
mean I've something to do with Telecom! I'm interested in supporting you 
concerning maintenace, but granting resources is somewhat too expensive 
for me!

KFl

[kphone-devel] New Features available

[Juha H. <jh...@tu...>]

Klaus Fleischmann writes:

 > What I WANT, is to let the develloppement become a part of the KPhone .
 > What I NEED  - if the KPhone Project is interested -  is a place to 
 > dump  my code to.
 > There are to many  changes  to make diffs.

klaus,

how about hosting further kphone development at your site?  people who
have done it earlier don't anymore have enough resources to properly
maintain the code.

-- juha

[kphone-devel] New Features available

[Klaus F. <kgf...@t-...>]

Hi,

during the last year I made a lot of  KPhone changes. Now the result is 
ready for  beeing
published. Some topics:

- Call Forwarding on no Reply
- Auto Answer
- a (almost) complete implementation of REFER
- some changes to the "non-dissipate2" call control (to achieve better 
parallelity,
   I concentrated that stuff into the CallWidget, CallAudio now  is only 
responsible for
 (switching audio on and off)
- freely configurable sessions (I tested that with a whiteboard over Pulver)
- Speex
- "digital"  DTMF - works great with some adaptors
- some improvements on TCP
- a new interface
and other things.

What I WANT, is to let the develloppement become a part of the KPhone .
What I NEED  - if the KPhone Project is interested -  is a place to 
dump  my code to.
There are to many  changes  to make diffs.

Yours

Klaus Fleischmann


P

[kphone-devel] kphone is in some kind of busy loop

[Peter E. <pe...@gm...>]

As soon as kphone is running (connected or not), it is in some kind of 
busy loop:

select(6, [3 4 5], [], [], {0, 555})    = 0 (Timeout)
gettimeofday({1127768530, 766020}, NULL) = 0
select(8, [7], NULL, NULL, {0, 0})      = 0 (Timeout)
gettimeofday({1127768530, 766076}, NULL) = 0
ioctl(3, FIONREAD, [0])                 = 0
gettimeofday({1127768530, 766125}, NULL) = 0
select(6, [3 4 5], [], [], {0, 555})    = 0 (Timeout)
gettimeofday({1127768530, 767021}, NULL) = 0
select(8, [7], NULL, NULL, {0, 0})      = 0 (Timeout)
gettimeofday({1127768530, 767076}, NULL) = 0
ioctl(3, FIONREAD, [0])                 = 0
gettimeofday({1127768530, 767125}, NULL) = 0
select(6, [3 4 5], [], [], {0, 555})    = 0 (Timeout)
gettimeofday({1127768530, 768096}, NULL) = 0
select(8, [7], NULL, NULL, {0, 0})      = 0 (Timeout)
gettimeofday({1127768530, 768153}, NULL) = 0
ioctl(3, FIONREAD, [0])                 = 0
gettimeofday({1127768530, 768203}, NULL) = 0

etc.

This can't be good, especially for a laptop battery.

Re: [kphone-devel] proposed changes to dspoutrtp.cpp

[D. H. R. <hu...@mi...>]

| From: Andreas Steffen <and...@hs...>

Hi Andreas!

| The SRTP support in kphone-4.2 was written by my students Christian
| H=F6hn and Silvan Geser who are going to tackle the integration of the
| MIKEY key exchange protocol as part of their diploma thesis in
| October 2005.

Small world.  And one that needs more crypto.

| I've just noticed that there is a new release of
| Cisco's libsrtp library available after more than a year's break.
| I hope that it fixes the 64-bit issues on my Athlon 64.

Not yet.  See my whining on the srtp list :-)

There have been postings of patches to fix this, before the latest
release, but they were not adopted (yet?).

Re: [kphone-devel] proposed changes to dspoutrtp.cpp

[Andreas S. <and...@hs...>]

Hi Hugh,

nice to meet you in another project after FreeS/WAN :-)

The SRTP support in kphone-4.2 was written by my students Christian
H=F6hn and Silvan Geser who are going to tackle the integration of the
MIKEY key exchange protocol as part of their diploma thesis in
October 2005. I've just noticed that there is a new release of
Cisco's libsrtp library available after more than a year's break.
I hope that it fixes the 64-bit issues on my Athlon 64.

Kind regards

Andreas

D. Hugh Redelmeier wrote:
> I've made some changes to dspoutrtp.cpp that are larger than
> necessary.  I think that they are worthwhile to improve the quality of
> the code.  As with my previous posting, this code is untested beyond
> compilation.
>=20
> I find the notation
> 	if(!wrapper =3D=3D 0)
> very odd.  I admit that I'm a C programmer, not a C++ programmer, so
> perhaps this is a C++ convention of which I do not know.
>=20
> wraper is a pointer.  !wrapper treats it as a boolean (standard in C
> and C++) and negates it.  !wrapper =3D=3D 0 then compares the result of
> the negation to an integer that happens to equal false.  Surely a less
> startling equivalent would be !!wrapper.  Which ought to be the same
> as just plain "wrapper".  As a conservative, I changed the test from
> 	!wrapper =3D=3D 0
> to
> 	wrapper !=3D 0
> I think that this is cleaner -- it does not require a mulimodal double
> negation.
>=20
> There is a cascading "if" that really was more naturally expressed as
> a switch.  So I switched it.
>=20
> Inside one branch of that if/switch was a switch that caused GCC4 to
> complain about a possible undefined reference.  Reluctantly, I recoded
> the inner switch as an if.  This calmed GCC4 down in a portable way.
>=20
> I made a slight change to the contents of several similar #ifdefs.
> Each branch ended with a "{" so the number of "{" in the source file
> was larger than the number of "}".  This confused my text editor so I
> moved the "{" out of the #ifdefs.
>=20
> On some of the lines that I touched, I made the leading whitespace
> more consistent.
>=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: kphone/RCS/dspoutrtp.cpp,v
> retrieving revision 1.1
> diff -u -r1.1 kphone/dspoutrtp.cpp
> --- kphone/dspoutrtp.cpp	2005/09/26 03:19:26	1.1
> +++ kphone/dspoutrtp.cpp	2005/09/26 04:17:35
> @@ -92,7 +92,7 @@
>  	delete[] static_cast<unsigned char *>( quebuf );
>  	if (destroySocket) delete socket;
>  	#ifdef SRTP
> -	if(!wrapper =3D=3D 0){
> +	if(wrapper !=3D 0){
>  		wrapper->dispose();
>  	}
>  	#endif
> @@ -138,14 +138,9 @@
>  		videoPortnum =3D portnum + 20;
>  //------------------------------
> =20
> -	} else {
> -          if( socket->connect( portnum ) ) {
> -            if ( socket->SetTOS() )
> -              return false ; =20
> -          }
> -          else=20
> -            return false;
> -        }
> +	} else if (!socket->connect( portnum ) || socket->SetTOS()) {
> +		return false;
> +	}
>  	devstate =3D DeviceOpened;
>  	return true;
>  }
> @@ -174,7 +169,9 @@
>  	fromsize =3D audio_buf.getSize() / sizeof( short );
>  	inbuf =3D (unsigned char*)audio_buf.getData();
>  	frombuf =3D (short *)inbuf;
> -	if( codec =3D=3D codecGSM ) {
> +	switch (codec) {
> +	case codecGSM:
> +	  {
>  		short *frombuf_test;
>  		frombuf_test =3D frombuf;
>  		s =3D (short *)inbuf;
> @@ -200,20 +197,24 @@
>  			}
>  			#ifdef SRTP
>  			int* length =3D new int(sizeof( rtp_hdr_t ) + tmpsize);
> -			if(!wrapper =3D=3D 0){
> +			if(wrapper !=3D 0){
>  				wrapper->protect(packetbuf, length);
>  			}
> -			if( socket->send( (char *) packetbuf, *length) < 0 ) {
> +			if( socket->send( (char *) packetbuf, *length) < 0 )
>  			#else
> -			if( socket->send( (char *) packetbuf, sizeof( rtp_hdr_t ) + tmpsize=
 ) < 0 ) {
> +			if( socket->send( (char *) packetbuf, sizeof( rtp_hdr_t ) + tmpsize=
 ) < 0 )
>  			#endif
> +			{
>  				printf("DspOutRtp::writeBuffer: %s\n", strerror(errno));
>  				return false;
>  			}
>  			tmpsize =3D writeGSMBuffer( gsmInstEnc, inbuf, outbuf, tmpbuf, queb=
uf, &qlen, 0 );
>  		}
> -	}
> -	else if( codec =3D=3D codecILBC_20 || codec =3D=3D codecILBC_30 ) {
> +		break;
> +	  }
> +	case codecILBC_20:
> +	case codecILBC_30:
> +	  {
>  		short *frombuf_test;
>  		frombuf_test =3D frombuf;
>  		s =3D (short *)inbuf;
> @@ -247,13 +248,14 @@
>  			}
>  			#ifdef SRTP
>  			int* length =3D new int(sizeof( rtp_hdr_t ) + tmpsize);
> -			if(!wrapper =3D=3D 0){
> +			if(wrapper !=3D 0){
>  				wrapper->protect(packetbuf, length);
>  			}
> -			if( socket->send( (char *) packetbuf, *length) < 0 ) {
> +			if( socket->send( (char *) packetbuf, *length) < 0 )
>  			#else
> -			if( socket->send( (char *) packetbuf, sizeof( rtp_hdr_t ) + tmpsize=
 ) < 0 ) {
> +			if( socket->send( (char *) packetbuf, sizeof( rtp_hdr_t ) + tmpsize=
 ) < 0 )
>  			#endif
> +			{
>  				printf("DspOutRtp::writeBuffer: %s\n", strerror(errno));
>  				return false;
>  			}
> @@ -263,8 +265,11 @@
>  				tmpsize =3D writeILBCBuffer_30( &ilbcEncInst_30, inbuf, outbuf, tm=
pbuf, quebuf, &qlen, 0 );
>  			}
>  		}
> -	}
> -	else if( codec =3D=3D codecPCMA || codec =3D=3D codecPCMU ) {
> +		break;
> +	  }
> +	case codecPCMU:
> +	case codecPCMA:
> +	  {
>  		cb_t callb;
>  		wlbuf =3D bufunsend;
>  		h->version =3D 2;
> @@ -272,16 +277,14 @@
>  		h->x =3D 0;
>  		h->cc =3D 0;
>  		h->m =3D 0;
> -		switch ( codec ) {
> -          case codecPCMU:
> -			  h->pt =3D PCMUCODEC;
> -			  callb.func =3D &linear2ulaw;
> -			  break;
> -		  case codecPCMA:
> -			  h->pt =3D PCMACODEC;
> -			  callb.func =3D &linear2pcma;
> -		  default:
> -			  break;
> +		if ( codec =3D=3D codecPCMU ){
> +			h->pt =3D PCMUCODEC;
> +			callb.func =3D &linear2ulaw;
> +		}
> +		else {
> +			/* codec =3D=3D case_codecPCMA */
> +			h->pt =3D PCMACODEC;
> +			callb.func =3D &linear2pcma;
>  		}
>  		while(bytesnew+numunsend >=3D fixedrtplen){
>  			++deb_rtp;
> @@ -308,13 +311,14 @@
>  			}
>  			#ifdef SRTP
>  			int* length =3D new int(sizeof( rtp_hdr_t ) + fixedrtplen);
> -			if(!wrapper =3D=3D 0){
> +			if(wrapper !=3D 0){
>  				wrapper->protect(packetbuf, length);
>  			}
> -			if( socket->send( (char *) packetbuf, *length ) < 0 ) {
> +			if( socket->send( (char *) packetbuf, *length ) < 0 )
>  			#else
> -			if( socket->send( (char *) packetbuf, sizeof( rtp_hdr_t ) + fixedrt=
plen ) < 0 ) {
> +			if( socket->send( (char *) packetbuf, sizeof( rtp_hdr_t ) + fixedrt=
plen ) < 0 )
>  			#endif
> +			{
>  				printf("DspOutRtp::writeBuffer: %s\n", strerror(errno));
>  				return false;
>  			}
> @@ -330,10 +334,11 @@
>  			}
>  		}
>  		++deb_frag;
> -	}
> -	else {
> -       printf("DspOutRtp::writeBuffer: unknown Codec %i\n",codec);
> -	   return false;
> +		break;
> +	  }
> +	default:
> +		printf("DspOutRtp::writeBuffer: unknown Codec %i\n",codec);
> +		return false;
>  	}
> =20
>  	return true;
> @@ -377,7 +382,7 @@
>  	recvsize =3D socket->receive( (char *) packetbuf, sizeof( rtp_hdr_t )=
 + dsize );
>  	rtp_hdr_t *h =3D (rtp_hdr_t *) packetbuf;
>  	#ifdef SRTP
> -	if(!wrapper =3D=3D 0){
> +	if(wrapper !=3D 0){
>  		int* length =3D new int(recvsize);
>  		wrapper->unprotect(packetbuf, length);
>  		recvsize =3D *length;
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Andreas Steffen                         e-mail: and...@hs...
Institut fuer Internet-Technologien und Anwendungen
Hochschule fuer Technik Rapperswil      phone:  +41 55 222 42 68
CH-8640 Rapperswil (Switzerland)        mobile: +41 76 340 25 56
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D[ITA-HSR]=3D=3D

[kphone-devel] proposed changes to dspoutrtp.cpp

[D. H. R. <hu...@mi...>]

I've made some changes to dspoutrtp.cpp that are larger than
necessary.  I think that they are worthwhile to improve the quality of
the code.  As with my previous posting, this code is untested beyond
compilation.

I find the notation
	if(!wrapper == 0)
very odd.  I admit that I'm a C programmer, not a C++ programmer, so
perhaps this is a C++ convention of which I do not know.

wraper is a pointer.  !wrapper treats it as a boolean (standard in C
and C++) and negates it.  !wrapper == 0 then compares the result of
the negation to an integer that happens to equal false.  Surely a less
startling equivalent would be !!wrapper.  Which ought to be the same
as just plain "wrapper".  As a conservative, I changed the test from
	!wrapper == 0
to
	wrapper != 0
I think that this is cleaner -- it does not require a mulimodal double
negation.

There is a cascading "if" that really was more naturally expressed as
a switch.  So I switched it.

Inside one branch of that if/switch was a switch that caused GCC4 to
complain about a possible undefined reference.  Reluctantly, I recoded
the inner switch as an if.  This calmed GCC4 down in a portable way.

I made a slight change to the contents of several similar #ifdefs.
Each branch ended with a "{" so the number of "{" in the source file
was larger than the number of "}".  This confused my text editor so I
moved the "{" out of the #ifdefs.

On some of the lines that I touched, I made the leading whitespace
more consistent.

===================================================================
RCS file: kphone/RCS/dspoutrtp.cpp,v
retrieving revision 1.1
diff -u -r1.1 kphone/dspoutrtp.cpp
--- kphone/dspoutrtp.cpp	2005/09/26 03:19:26	1.1
+++ kphone/dspoutrtp.cpp	2005/09/26 04:17:35
@@ -92,7 +92,7 @@
 	delete[] static_cast<unsigned char *>( quebuf );
 	if (destroySocket) delete socket;
 	#ifdef SRTP
-	if(!wrapper == 0){
+	if(wrapper != 0){
 		wrapper->dispose();
 	}
 	#endif
@@ -138,14 +138,9 @@
 		videoPortnum = portnum + 20;
 //------------------------------
 
-	} else {
-          if( socket->connect( portnum ) ) {
-            if ( socket->SetTOS() )
-              return false ;  
-          }
-          else 
-            return false;
-        }
+	} else if (!socket->connect( portnum ) || socket->SetTOS()) {
+		return false;
+	}
 	devstate = DeviceOpened;
 	return true;
 }
@@ -174,7 +169,9 @@
 	fromsize = audio_buf.getSize() / sizeof( short );
 	inbuf = (unsigned char*)audio_buf.getData();
 	frombuf = (short *)inbuf;
-	if( codec == codecGSM ) {
+	switch (codec) {
+	case codecGSM:
+	  {
 		short *frombuf_test;
 		frombuf_test = frombuf;
 		s = (short *)inbuf;
@@ -200,20 +197,24 @@
 			}
 			#ifdef SRTP
 			int* length = new int(sizeof( rtp_hdr_t ) + tmpsize);
-			if(!wrapper == 0){
+			if(wrapper != 0){
 				wrapper->protect(packetbuf, length);
 			}
-			if( socket->send( (char *) packetbuf, *length) < 0 ) {
+			if( socket->send( (char *) packetbuf, *length) < 0 )
 			#else
-			if( socket->send( (char *) packetbuf, sizeof( rtp_hdr_t ) + tmpsize ) < 0 ) {
+			if( socket->send( (char *) packetbuf, sizeof( rtp_hdr_t ) + tmpsize ) < 0 )
 			#endif
+			{
 				printf("DspOutRtp::writeBuffer: %s\n", strerror(errno));
 				return false;
 			}
 			tmpsize = writeGSMBuffer( gsmInstEnc, inbuf, outbuf, tmpbuf, quebuf, &qlen, 0 );
 		}
-	}
-	else if( codec == codecILBC_20 || codec == codecILBC_30 ) {
+		break;
+	  }
+	case codecILBC_20:
+	case codecILBC_30:
+	  {
 		short *frombuf_test;
 		frombuf_test = frombuf;
 		s = (short *)inbuf;
@@ -247,13 +248,14 @@
 			}
 			#ifdef SRTP
 			int* length = new int(sizeof( rtp_hdr_t ) + tmpsize);
-			if(!wrapper == 0){
+			if(wrapper != 0){
 				wrapper->protect(packetbuf, length);
 			}
-			if( socket->send( (char *) packetbuf, *length) < 0 ) {
+			if( socket->send( (char *) packetbuf, *length) < 0 )
 			#else
-			if( socket->send( (char *) packetbuf, sizeof( rtp_hdr_t ) + tmpsize ) < 0 ) {
+			if( socket->send( (char *) packetbuf, sizeof( rtp_hdr_t ) + tmpsize ) < 0 )
 			#endif
+			{
 				printf("DspOutRtp::writeBuffer: %s\n", strerror(errno));
 				return false;
 			}
@@ -263,8 +265,11 @@
 				tmpsize = writeILBCBuffer_30( &ilbcEncInst_30, inbuf, outbuf, tmpbuf, quebuf, &qlen, 0 );
 			}
 		}
-	}
-	else if( codec == codecPCMA || codec == codecPCMU ) {
+		break;
+	  }
+	case codecPCMU:
+	case codecPCMA:
+	  {
 		cb_t callb;
 		wlbuf = bufunsend;
 		h->version = 2;
@@ -272,16 +277,14 @@
 		h->x = 0;
 		h->cc = 0;
 		h->m = 0;
-		switch ( codec ) {
-          case codecPCMU:
-			  h->pt = PCMUCODEC;
-			  callb.func = &linear2ulaw;
-			  break;
-		  case codecPCMA:
-			  h->pt = PCMACODEC;
-			  callb.func = &linear2pcma;
-		  default:
-			  break;
+		if ( codec == codecPCMU ){
+			h->pt = PCMUCODEC;
+			callb.func = &linear2ulaw;
+		}
+		else {
+			/* codec == case_codecPCMA */
+			h->pt = PCMACODEC;
+			callb.func = &linear2pcma;
 		}
 		while(bytesnew+numunsend >= fixedrtplen){
 			++deb_rtp;
@@ -308,13 +311,14 @@
 			}
 			#ifdef SRTP
 			int* length = new int(sizeof( rtp_hdr_t ) + fixedrtplen);
-			if(!wrapper == 0){
+			if(wrapper != 0){
 				wrapper->protect(packetbuf, length);
 			}
-			if( socket->send( (char *) packetbuf, *length ) < 0 ) {
+			if( socket->send( (char *) packetbuf, *length ) < 0 )
 			#else
-			if( socket->send( (char *) packetbuf, sizeof( rtp_hdr_t ) + fixedrtplen ) < 0 ) {
+			if( socket->send( (char *) packetbuf, sizeof( rtp_hdr_t ) + fixedrtplen ) < 0 )
 			#endif
+			{
 				printf("DspOutRtp::writeBuffer: %s\n", strerror(errno));
 				return false;
 			}
@@ -330,10 +334,11 @@
 			}
 		}
 		++deb_frag;
-	}
-	else {
-       printf("DspOutRtp::writeBuffer: unknown Codec %i\n",codec);
-	   return false;
+		break;
+	  }
+	default:
+		printf("DspOutRtp::writeBuffer: unknown Codec %i\n",codec);
+		return false;
 	}
 
 	return true;
@@ -377,7 +382,7 @@
 	recvsize = socket->receive( (char *) packetbuf, sizeof( rtp_hdr_t ) + dsize );
 	rtp_hdr_t *h = (rtp_hdr_t *) packetbuf;
 	#ifdef SRTP
-	if(!wrapper == 0){
+	if(wrapper != 0){
 		int* length = new int(recvsize);
 		wrapper->unprotect(packetbuf, length);
 		recvsize = *length;
===================================================================

[kphone-devel] Some patches for kphone 4.2 (mostly for GCC4)

[D. H. R. <hu...@mi...>]

[None of these changes have been tested beyond clean building.]

I've explained the patches to Makefile.in already.  They cause the
top-level make to fail as soon as a subdirectory make fails.

The changes to iCVSearch.cpp are meant to elimitate a race condition
withing an expression.  Prompted by a gcc4 warning.

The change to callaudio is the fix for the gcc4 sentinel warning message.
I mentioned this in an earlier posting.

The change to dspoutalsa.cpp fixes another gcc4 warning.  This assumes
that the chunk_size and buffer_size never exceed what can be held in
an unsigned int.  Is this correct?  It is better than the status quot.

I'm not at all sure of the changes to SRTPWrapper.cpp and
SRTPWrapper.h.  They did quiet down gcc4.

- It looks as though libsrtp 1.4.1 now uses the name "stream_template"
  in place of "template".  My #define change attempts to support
  this transition.

- gcc acted as if "protected" was a g++ keyword, so I defined a
  k_protected.  Just like k_template and k_new had been introduced.

It would be good to convince the libsrtp project to make the few
small changes necessary to make their library C++-friendly.

===================================================================
RCS file: RCS/Makefile.in,v
retrieving revision 1.1
diff -u -r1.1 Makefile.in
--- Makefile.in	2005/09/26 06:53:43	1.1
+++ Makefile.in	2005/09/26 06:55:05
@@ -7,7 +7,7 @@
 SUBS	:=$(foreach sub,$(SUBDIRS), $(sub)/$(sub).a)
 
 all dep:
-	@for T in $(SUBDIRS); do make -C $$T $@; done
+	@set -e; for T in $(SUBDIRS); do make -C $$T $@; done
 
 install:	all
 	make -C po install
===================================================================
RCS file: ilbc/RCS/iCBSearch.cpp,v
retrieving revision 1.1
diff -u -r1.1 ilbc/iCBSearch.cpp
--- ilbc/iCBSearch.cpp	2005/09/26 03:13:51	1.1
+++ ilbc/iCBSearch.cpp	2005/09/26 06:56:47
@@ -127,7 +127,8 @@
                *ppe=0.0;
                pp=buf+LPC_FILTERORDER+lMem-lTarget;
                for (j=0; j<lTarget; j++) {
-                   *ppe+=(*pp)*(*pp++);
+                   float t = *pp++;
+                   *ppe += t * t;
                }
 
                if (*ppe>0.0) {
@@ -322,7 +323,8 @@
 
                pp=cbvectors+lMem-lTarget;
                for (j=0; j<lTarget; j++) {
-                   *ppe+=(*pp)*(*pp++);
+                   float t = *pp++;
+                   *ppe += t * t;
                }
 
                ppi = cbvectors + lMem - 1 - lTarget;
===================================================================
RCS file: kphone/RCS/callaudio.cpp,v
retrieving revision 1.1
diff -u -r1.1 kphone/callaudio.cpp
--- kphone/callaudio.cpp	2005/09/26 07:20:15	1.1
+++ kphone/callaudio.cpp	2005/09/26 07:20:25
@@ -233,7 +233,7 @@
 				QString::number( local.getVideoPort() );
 			printf( "CallAudio: execlp( %s, %s, %s, 0)\n",
 				videoSW.latin1(), SW.latin1(), videoSWParam.latin1() );
-			execlp( videoSW.latin1(), SW.latin1(), videoSWParam.latin1(), 0 );
+			execlp( videoSW.latin1(), SW.latin1(), videoSWParam.latin1(), (void *)0 );
 			printf( tr("error executing ") + videoSW + "\n" );
 			exit(1);
 		}
===================================================================
RCS file: kphone/RCS/dspoutalsa.cpp,v
retrieving revision 1.1
diff -u -r1.1 kphone/dspoutalsa.cpp
--- kphone/dspoutalsa.cpp	2005/09/26 03:15:50	1.1
+++ kphone/dspoutalsa.cpp	2005/09/26 03:16:29
@@ -113,7 +113,8 @@
 	snd_pcm_hw_params_get_period_size( hw_params, &chunk_size, &dir );
 	snd_pcm_hw_params_get_buffer_size( hw_params, &buffer_size );
 
-	fprintf (stderr, "\n\n\n----------<%d - %d>--------------\n\n\n", chunk_size, buffer_size );
+	fprintf (stderr, "\n\n\n----------<%u - %u>--------------\n\n\n",
+		(unsigned int)chunk_size, (unsigned int)buffer_size );
 
 	audio_buf.resize( chunk_size*2 );
 
===================================================================
RCS file: srtp/RCS/SRTPWrapper.cpp,v
retrieving revision 1.1
diff -u -r1.1 srtp/SRTPWrapper.cpp
--- srtp/SRTPWrapper.cpp	2005/09/26 02:14:29	1.1
+++ srtp/SRTPWrapper.cpp	2005/09/26 02:14:35
@@ -108,7 +108,7 @@
 	}
 	#endif
 	else if(!outboundStreamActive){
-		session->k_template->direction = dir_srtp_sender;
+		session->stream_template->direction = dir_srtp_sender;
 		outboundStreamActive = true;
 	}
 	
@@ -140,7 +140,7 @@
 	}
 	#endif
 	else if(!inboundStreamActive){
-		session->k_template->direction = dir_srtp_receiver;
+		session->stream_template->direction = dir_srtp_receiver;
 		inboundStreamActive = true;
 	}
 	
===================================================================
RCS file: srtp/RCS/SRTPWrapper.h,v
retrieving revision 1.1
diff -u -r1.1 srtp/SRTPWrapper.h
--- srtp/SRTPWrapper.h	2005/09/26 01:58:58	1.1
+++ srtp/SRTPWrapper.h	2005/09/26 02:16:52
@@ -14,10 +14,12 @@
  * some C++ keywords which are used as variable names in the library
  */
 #define new k_new
-#define template k_template
+#define template stream_template    // this is the name used in srtp-1.4.1
+#define protected k_protected
 #include "srtp.h"
 #undef new
 #undef template
+#undef protected
 #ifdef __cplusplus
 };
 #endif

Re: [kphone-devel] diagnostics from gcc 4 on x86_64

[D. H. R. <hu...@mi...>]

Another diagnostic.  This occurred for each compilation in the
kphone/srtp and kphone/kphone subdirectories:

  c++ -I/usr/local/include/srtp -I- -I/usr/lib/qt-3.3/include -Wall -O3 -I. -I.. -DHAVE_CONFIG_H -DQT_THREAD_SUPPORT   -c -o SRTPWrapper.o SRTPWrapper.cpp
  cc1plus: note: obsolete option -I- used, please use -iquote instead

I have no idea if this is a sensible change to gcc flags, one that
kphone should follow.  Perhaps if kphone used the new form, it could
no longer be built on old or non-gcc systems.  Anyone know?

[kphone-devel] kphone build should stop on error

[D. H. R. <hu...@mi...>]

[I've borrowed an i386 box running Fedora Core 4 so I can continue my
exploration of kphone.]

In Makfile.in, the following recipe is used to build each
subdirectory:

all dep:
        @for T in $(SUBDIRS); do make -C $$T $@; done

A failure in any but the last subdirectory will not stop the top-level
make.  This means that any earlier subdirectory's build failure will
get lost in the log output and it won't be obvious.  (I know this
because it happened to me.)

A small change in the rule will cause the normally expected behaviour:
make will stop on the first failure.

all dep:
        @set -e; for T in $(SUBDIRS); do make -C $$T $@; done
         ^^^^^^^

I recommend making this change to Makefile.in.

[kphone-devel] diagnostics from gcc 4 on x86_64

[D. H. R. <hu...@mi...>]

I decided that I'd like to try SIP VoIP from my Linux box.  kphone
looks to be a good choice.  So here are my first experiences with it.

I downloaded kphone-4.2.tar.gz, unpacked it, and read INSTALL.

I decided to pause to get and install libsrtp.  That was a dead-end
since it won't build on x86_64.

I then did ./configure and make of kphone.  There were a bunch of
errors.  I subscribed to this list and scanned the archive -- I did
not see error reports.  So here is mine.

I'm using Fedora Core 4 on x86_64.  The C++ compiler is gcc 4 -- perhaps
pickier than what most people use for kphone.

================
There were a bajillion errors of the form:
/usr/lib64/qt-3.3/include/private/qucom_p.h:69: warning: 'struct QUBuffer' has virtual functions but non-virtual destructor
/usr/lib64/qt-3.3/include/private/qucom_p.h:77: warning: 'struct QUType' has virtual functions but non-virtual destructor
/usr/lib64/qt-3.3/include/private/qucom_p.h:104: warning: 'struct QUType_Null' has virtual functions but non-virtual destructor
/usr/lib64/qt-3.3/include/private/qucom_p.h:287: warning: 'struct QUType_enum' has virtual functions but non-virtual destructor
/usr/lib64/qt-3.3/include/private/qucom_p.h:307: warning: 'struct QUType_ptr' has virtual functions but non-virtual destructor
/usr/lib64/qt-3.3/include/private/qucom_p.h:326: warning: 'struct QUType_iface' has virtual functions but non-virtual destructor
/usr/lib64/qt-3.3/include/private/qucom_p.h:345: warning: 'struct QUType_idisp' has virtual functions but non-virtual destructor
/usr/lib64/qt-3.3/include/private/qucom_p.h:364: warning: 'struct QUType_bool' has virtual functions but non-virtual destructor
/usr/lib64/qt-3.3/include/private/qucom_p.h:383: warning: 'struct QUType_int' has virtual functions but non-virtual destructor
/usr/lib64/qt-3.3/include/private/qucom_p.h:403: warning: 'struct QUType_double' has virtual functions but non-virtual destructor
/usr/lib64/qt-3.3/include/private/qucom_p.h:423: warning: 'struct QUType_charstar' has virtual functions but non-virtual destructor
/usr/lib64/qt-3.3/include/private/qucom_p.h:444: warning: 'struct QUType_QString' has virtual functions but non-virtual destructor
/usr/lib64/qt-3.3/include/private/qucomextra_p.h:65: warning: 'struct QUType_QVariant' has virtual functions but non-virtual destructor
/usr/lib64/qt-3.3/include/private/qucomextra_p.h:87: warning: 'struct QUType_varptr' has virtual functions but non-virtual destructor

I don't know C++, so I don't know what is going on here.  Is this a
problem that only TrollTech can address?

See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162150
Especially comment #2.

================

iCBSearch.cpp:130: warning: operation on 'pp' may be undefined

                   *ppe+=(*pp)*(*pp++);
This warning is correct: the result of this expression is undefined.
The reason is that the C++ standard does not specify what happens when a
variable is referenced and also modified without an intervening
sequence point (that's not the precise rule).

One of the following was probably intended (probably the first).  But
even if both would be OK, this would be a violation of the C++
standard.

	{
		float t = *pp++;

		*ppe += t * t;
	}
or
	{
		float t = *pp++;

		*ppe += *pp * t;
	}

Recommendation: pick the one meant and use it.

================

iCBSearch.cpp:325: warning: operation on 'pp' may be undefined

This is essentially the same problem.

================

dspoutalsa.cpp:116: warning: format '%d' expects type 'int', but argument 3 has type 'snd_pcm_uframes_t'
dspoutalsa.cpp:116: warning: format '%d' expects type 'int', but argument 4 has type 'snd_pcm_uframes_t'

        fprintf (stderr, "\n\n\n----------<%d - %d>--------------\n\n\n", chunk_size, buffer_size );

This warning is correct too.  There is an error lurking here.

snd_pcm_uframes_t is declared in /usr/include/alsa/pcm.h:
  typedef unsigned long snd_pcm_uframes_t;

On x86_64, unsigned long is 8 bytes whereas int is 4 bytes.  So this
fprintf needs to be fixed.  Here is one fix.  This assumes that the
chunk_size and buffer_size never exceed what can be held in an
unsigned int:

        fprintf (stderr, "\n\n\n----------<%u - %u>--------------\n\n\n",
		(unsigned int) chunk_size, (unsigned int)buffer_size );

================

In compilation of dspoutrtp.cpp:

rtpdataheader.h:35: warning: '__packed__' attribute ignored

I don't know why the attribute is ignored.  I've never used that
feature of GCC.

================

dspoutrtp.cpp:268: warning: 'callb$func' may be used uninitialized in this function

I think that the problem is that the func member is initialized in a
case, starting at line 276, but it is not initialized in all branches.
So I'd say this warning is correct.

================

callaudio.cpp:236: warning: missing sentinel in function call
                        execlp( videoSW.latin1(), SW.latin1(), videoSWParam.latin1(), 0 );

To be correct portable C, the last arg should be (void *)NULL.  I'm
not sure about C++, but I imagine that you might write (void *)0.

================

I hope that this report is useful.

[kphone-devel] Gouranga

[Neateye <nit...@ao...>]

Call out Gouranga be happy!!!
Gouranga Gouranga Gouranga ....
That which brings the highest happiness!!

[kphone-devel] Installing kphone as non-root user

[Hendrik K. <hen...@gm...>]

I tried to install kphone on a machine where I do not have root access.=20
The problem is that I can not get it to find the icons used in the UI.
I used --prefix to specify the install directory, set KDEDIRS to that
directory and then (re)run kbuildsycoca before starting kphone. This
procedure works for all sorts of other KDE applications that I have
installed before, but apparently not for kphone. Could it be that the
default KDE paths are hardcoded in so that KDEDIRS has no effect?

Thanks,
Hendrik

[kphone-devel] Use kphone for room monitoring

[Christian v. <c.v...@we...>]

Hi, 
I am looking for  means for room monitoring - in other words, I want to use 
VoIP as an alternate babyphone!

An easy solution could be threshold-triggered call initiation: 
If the microphone volume exceeds a configured threshold, a call is initiated 
to a pre-defined phone number/SIP adress. 

I could try to implement this in kphone myself... but the days I wrote my last 
piece of C code are eight years ago - this would certainly be write-only 
code!
Has anyone of you plans to implement a feature such that you can configure a 
postponed call which will be initiated when a threshold is exceeded?

Alternatively, can anyone give me a hint where to start looking in the source 
code just in case I'm desperate enough to try it myself?

Kind regards,
Christian 

[kphone-devel] (no subject)

[<agg...@wp...>]

Hi there,

Would you send me the info how I should configure my KPhone to be able to use a VoIP software i. e. Babble?
What do I need to do?

Regards,
Agnieszka

----------------------------------------------------
BATMAN - POCZĄTEK (29 LIPCA). Wyst: Christiane Bale, 
Michael Caine, Liam Neeson, Katie Holmes, Gary Oldman, 
Ken Watanbe, Rutger Hauer i Morgan Freeman.
http://klik.wp.pl/?adr=www.film.wp.pl%2Ffilm.html%3Fid%3D24647&sid=446

Re: [kphone-devel] CallAudio::checkCodec bug?

[Carl-Daniel H. <c-d...@gm...>]

Carl-Daniel Hailfinger schrieb:
> Hi,
> 
> the following snippet from CallAudio::checkCodec seems
> to be slightly wrong:
> 
> if( mstr.lower().contains( "ilbc/8000" ) ) {
>   ilbc = mstr.mid( mstr.lower().find( "ilbc/8000" ) - 7, 6 );
> 
> Asterisk sends "iLBC/8000" for iLBC (notice the different
> capitalization). Which program is right?

Ahem. I should have read that code properly. Sorry for the
noise.


> Besides that, checkCodec seems not to care about local
> preferences and only honour the remote preferences.

Attached is a patch which will fix the preferences bug.
This should fix debian bug 265124 at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265124

If anyone wants kphone-4.2 packages with above bugfix
for SUSE 9.3 I'll put them online.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

[kphone-devel] CallAudio::checkCodec bug?

[Carl-Daniel H. <c-d...@gm...>]

Hi,

the following snippet from CallAudio::checkCodec seems
to be slightly wrong:

if( mstr.lower().contains( "ilbc/8000" ) ) {
  ilbc = mstr.mid( mstr.lower().find( "ilbc/8000" ) - 7, 6 );

Asterisk sends "iLBC/8000" for iLBC (notice the different
capitalization). Which program is right?

Besides that, checkCodec seems not to care about local
preferences and only honour the remote preferences.

If I'm right, please tell me and I'll send patches.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

[kphone-devel] [PATCH] Support for bluetooth headsets

[Jan J. <ja...@ip...>]

Hello,

I got a new laptop with bluetooth support built-in and I decided to give
it a try. I bought a bluetooth headset and extended kphone with support
for bluetooth headsets. Two patches are attached to this email,
bt-new.patch adds new files to kphone with bluetooth support classes and
bt-modify.patch modifies existing kphone sources. The patches are
against CVS head.

It uses the Bluez protocol stack which is included in recent 2.6.x
kernels. Kphone is linked with -lbluetooth library, on debian this
library is provided by libbluetooth1-dev.

I only tried with Bluetake BT400 G3 headset, with that one it seems to
work fine, but it should work with any bluetooth headset.

Installation:

- Make sure you have bluetooth support in the linux kernel (modules
  bluetooth, rfcomm, sco, l2cap, and hci_usb if you have USB bluetooth
  dongle). Note that most laptops with bluetooth support seem to have a
  USB dongle.

- Make sure you have bluez-utils installed and running, on debian you
  can start it using /etc/init.d/bluez-utils start
  You need to have hcid and sdpd daemons running.

- Verify that you have bluetooth interface up and running using
  hciconfig -a
  You should see hci0 interface UP RUNNING

- Switch your bluetooth headset into pairing mode

- Run hcitool scan
  This should show your bluetooth headset and its address, write down
  the address.

- Try to ping the headset using
  l2ping <bdaddr>

  You will be asked for the pin for the first time.

- start kphone, go to Audio options, click on bluetooth and enter the
  address of the headset in the edit window below.

- You will see bluetooth related debug messages in terminal window if
  you started kphone from terminal

There is no need to repeat the steps above once you have the headset
paired with the computer. They will remember each other and next time
you can only turn on the headset and start kphone and it should work.

The shared secret negotiated during paring is stored in
/etc/bluetooth/link_key on debian. If you delete the file then you will
be prompted for the pin again once you try to establish a connection to
the headset. Try to delete the file if you get "Permission denied" when
trying to either ping or connect the headset.

Pressing the button on the headset will bring up "New Call" dialog in
kphone. Setting microphone/speaker volume does not work yet because
there is no widget for this in kphone. Well setting speaker volume works
beucase this is done by the headset internaly, setting microphone volume
does not work yet because we would need a control for that in kphone.

It works fine for me, bluetooth headset is quite convenient replacement
of traditional headsets and also it does not block your soundcard when
making phone calls (although alsa can be configured this way too).

If you decided to buy a bluetooth headset, go for a headset that uses
+5V for charging. Such headsets can be easily re-charged directly from USB 
ports and you do not have to carry extra charger when travelling :-).

   Jan.

[kphone-devel] videoprobelm resolved

[y w <lil...@ya...>]

kphone-vic/vic/video/grabbre_video4linux.cpp

line 330 
     vid_mmap.width = PAL_WIDTH;CIF_WIDTH       
   vid_mmap.height = PAL_HEIGHT;
width and height are beyong my camera capability so
ioctl failed . I tried a CIF_WIDTH and CIF_HEIGHT
which define as 
 352 and  288 .These right width and height was given
by the output information :
Z-star Vimicro zc0301p     <<----my camera type
 V4l: color; size: 176x144 => 640x480 
 V4l: ports: ZC301-2 
 V4l: depth=24, palette=rgb24 


mydriver is spca5xx



__________________________________________________
赶快注册雅虎超大容量免费邮箱?
http://cn.mail.yahoo.com

[kphone-devel] 4.2 compiles but won't install

[Allan <am...@sy...>]

The installation fails with the error message lrelease not found.  But 
lrelease is in my qt3/bin directory so why isn't it found.

[kphone-devel] a video problem

[y w <lil...@ya...>]

hi ,I 'am a linux fan . I plan to adjust some function
of kphone .however the video can't work  while I tried
a video all to other one. the video  screen is just
green mozac .

i found a macro define:QC_GET in lin 191
kphone-vic/vic/video/grabber-qcam.cpp .but i found no
where it was defined and the "qcam-os.h" doesn't exist
in my linux . first ,  i copy qcam-os.h from other
packet to /usr/include/ .. but it no use.

by the way ,my camera can work well while using other
video softerware  in linux  for example gqcam



my os :  kernel 2.6.12.1 .     Dehualinux


		
___________________________________________________________ 
雅虎免费G邮箱－No.1的防毒防垃圾超大邮箱 
http://cn.mail.yahoo.com/?id=77072