[Serusers] Deadly embrace with rtpproxy - Is it necessary? Can it be turned off?

[Andres]

Frank Durda IV wrote:

> Sorry for the long delay on this topic.  Personal matters
> prevented me from investigating for a while and the original
> occurrence of the problem went away for the first client
> (because they changed something on their end), but now I
> have another apparently-identical problem with calls
> originating from a big-iron switch who isn't willing to
> change their settings like the first client did.
>
> The problem is easily reproducible for those of you who
> wish to hear (or not hear) it themselves.  (instructions below)
>
>
> To recap, the problem is that per rtpproxys own documentation
> rtpproxy won't pass a packet in either direction for a given session
> until it has received audio from both sides of a given session.
> The README says:
>
> [0]- after the session has been created, the proxy listens on the port 
> it has
> [0]  allocated for that session and waits for receiving at least one UDP
> [0]  packet from each of two parties participating in the call. Once such
> [0]  packet is received, the proxy fills one of two ip:port structures
> [0]  associated with each call with source ip:port of that packet. 
> When both
> [0]  structures are filled in, the proxy starts relaying UDP packets 
> between
> [0]  parties;

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. 

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'.

Andres
http://www.telesip.net