4 Dec
2008
4 Dec
'08
7:22 p.m.
Andres wrote:
I do not think this readme reflects the code as it works today. At
least that is my observation with version 1.0.2. As soon as the
rtpproxy receives audio from one end, it will start relaying to the
other end (to the port advertised in the SDP). Once it receives audio
from that end it will update the session port and continue relaying the
audio to the updated port. I know you have run tests that show
otherwise, so the only thing I can suggest is to check the actual
rtpproxy version you are running.
I am not entirely sure which version I have got. The tar ball
extracted a directory with the name rtpproxy-1.1,
the Makefile says:
PACKAGE_NAME = rtpproxy
PACKAGE_STRING = rtpproxy 1.1.beta.20071218
PACKAGE_TARNAME = rtpproxy
PACKAGE_VERSION = 1.1.beta.20071218
and there are other random CVS version tags like
* $Id: main.c,v 1.62 2008/02/04 08:38:05 sobomax Exp $
but no obvious "THIS IS VERSION X" message, such
as part of the usage() output.
Based on this I would suspect I have a newer version than
what you have.
A great way to troubleshoot the issue is to run rtpproxy in the
foreground and track the messages that show the port being updated:
(they start with the advertised SDP ports)
pre-filling caller's address with 192.116.246.234:41000
pre-filling callee's address with 192.116.246.235:20000
Then when it sees the actual packets coming in from a different source
port, it updates the address and we see it in the log like:
callee's address filled in: 192.116.246.235:1024
You should track first of all that the 'pre-filling' is done per SDP
Advertised Ports. Then when your end starts sending RTP, you should see
the 'caller's address filled' message and audio should start flowing
from that end to the advertised SDP port of the other end. Finally when
the other end sends Audio, you will see the last 'callee's address
filled message'.
I will see if I can run it this way on a test system. Thanks!