4 Dec
2008
4 Dec
'08
6:08 p.m.
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