[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Linphone-users] linphone on a specific IP address
From: |
Jason A. Pattie |
Subject: |
Re: [Linphone-users] linphone on a specific IP address |
Date: |
Mon, 17 Nov 2003 23:08:24 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.3) Gecko/20030327 Debian/1.3-4 |
Jason A. Pattie wrote:
Well, I just finished compiling the pre4 source tarball. I was not
able to get the graphical gnomeui dependencies installed, so I
couldn't compile the graphical interface, but the console interface
worked; it even chose the correct source IP address to place in the
REGISTER message (now to test it with a sound device; I've been
attempting to use a Plantronics DSP 400 USB headset. I tried getting
it to work with gnophone, but the audio is garbled, so I'm wanting to
get it to work with linphone since linphone has native support for
ALSA drivers which appears to be the only way to get the Plantronics
USB headset to work with Linux).
Now another funny thing is happening. No audio is being transmitted and
calls that I am attempting to make Timeout. I am seeing traffic passing
back and forth between my workstation and the Asterisk server on port
5060, but I don't see any traffic on port 7078 or 8000 (which I changed
the RTP settings to manually in the ~/.gnome2/linphone config file).
There are no dropped packets on those ports in the firewall logs,
either. I am doing a tcpdump on both ends and I don't see any traffic
originating on the RTP port(s) from either end.
Never mind. The Asterisk server is still seeing my local IP address to
respond to instead of my Virtual IP address.
-- Registered SIP 'pattieja' at 192.168.20.1 port 5060 expires 900
instead of 192.168.1.16.
I don't see the output from linphonec like I do from the GUI version
that informs me of the messages being sent. So, apparently, for some
reason, it is still using the incorrect IP address when generating SIP
events and the iptables DNAT rule I had in place on Asterisk is still
rewriting the destination to 192.168.1.16 for any packets going to
192.168.20.1.
Thanks.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.