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!