From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4 Description of problem: When using kphone with UDP protocol behind a NAT firewall the STUN protocol is used to correctly report the outside IP address/port number of the local UDP ports to the remote site. Starting with kphone 4.1.0 the STUN functionality is broken for RTP sockets, ie. the SIP communication and audio local->remote works OK, but incoming audio doesn't work anymore Version-Release number of selected component (if applicable): kphone-4.1.1-1.fc4 How reproducible: Always Steps to Reproduce: 1. setup kphone to use a STUN server 2. kphone | tee kphone.log 3. make a phone call Actual Results: From the log: Found 2 interfaces. SipClient: Listening UDP on port: 5060 SipClient: Our address: 192.168.2.2 SipClient: STUN request SipClient: Receiving message... SipClient: STUN response address_port: 22207 address: <outside IP address of the NAT firewall> ... KCallWidget: Switching calls... CallAudio: listening for incomming RTP UDPMessageSocket: Listening on 32800 CallAudio: Opening ALSA device for Output CallAudio: Creating RTP->ALSA Diverter ... Expected Results: From the log: Found 2 interfaces. SipClient: Listening UDP on port: 5060 SipClient: Our address: 192.168.2.2 SipClient: STUN request SipClient: Receiving message... SipClient: STUN response address_port: 22207 address: <outside IP address of the NAT firewall> ... KCallWidget: Switching calls... CallAudio: listening for incomming RTP UDPMessageSocket: Listening on 32800 DspOutRtp: STUN request SipClient: Receiving message... SipClient: STUN response for RTP CallAudio: Opening ALSA device for Output CallAudio: Creating RTP->ALSA Diverter ... Additional info:
Created attachment 116790 [details] Correct initialization of useStun instance variable in CallAudio constructor The constructor for the class CallAudio first sets useStun instance variable according to the user settings but then overwrites it with "false". The patch moves the initialization with "false" to the correct place. Note: This patch is against the kphone-4.2 source code but should be applicable to 4.1.x too...
It seems that Denis Gilmore, the new maintainer for kphone, found a problem with the patch. Reopening.
With the patch applied kphone segfaulted 95% of the time when making a call. strace of segfault munmap(0xb7d88000, 4096) = 0 fcntl64(11, F_SETLKW64, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}, 0xbf9d0378) = 0 close(11) = 0 bind(10, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 getsockname(10, {sa_family=AF_INET, sin_port=htons(33160), sin_addr=inet_addr("0.0.0.0")}, [16]) = 0 write(1, "UDPMessageSocket: Listening on 3"..., 37UDPMessageSocket: Listening on 33160 ) = 37 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++
Sorry, I fail to see why the patch should cause SIGSEGV, as a variable initialization is moved inside the same routine by about 10 lines. I haven't noticed any problems on my computer with kphone-4.2.
I dont see why it would cause it the segfault either however i tried it on 3 different machines all with the same result. I could not make calls. i removed the patch and kphone worked as expected for me. All my machines are running rawhide or FC4 i tested on both. i do not have any FC3 boxes i could test on. i will look into this further but i didnt want others to have kphone in an unworkable state. It could be a bug with asterisk. My test calls were all on the same lan and all going through asterisk. I tested on two different asterisk servers. i will try some calls dirrectly between two machines both with the patch applied.
Just a FYI i queued a new build that reenables the STUN patch. my quick testing it did not segfault on rawhide. i also patched configure so it uses standard CFLAGS and not -O3