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

[Frank Durda IV]

Greger Viken Teigre wrote:
> Hi Frank, the behavior of rtpproxy is like that because you want to send
> rtp back on source port if it has changed from the sdp, which often 
> happens
> behind a nat.
> Have you tried changing active media in sdp? The gateway has the same
> active media mode as rtpproxy.
> g-)
I don't believe I understand what you are asking re: active media.
Are you talking about some control I can set in SER or rtpproxy?
Because those are the only knobs available to me.  The company
sending the call to us doesn't want to change settings on their
equipment to accomodate what they consider to be our
incompatibility (what rtpproxy is doing), as what they are
doing (not sending audio until they receive audio from us)
isn't a problem when they send calls to other carriers.
If you are suggesting something I have SER patch into the
183/200 SDP payload to trick the calling system to send
audio without waiting to see some audio from us, what exactly
are you suggesting be added and how would that be done?

As a FYI, the PSTN gateway switch behind our SER system has
virtually no SIP controls, as the first thing it does is make
the call look as much like a TDM call as possible, right down
to assigning a pseudo trunk number for the call to be carried
in.  Of course, this is the device that is happily sending RTP
audio which rtpproxy is throwing away, so I don't think I can
fix the problem from that side even if there was a knob to
change something since this side is already working.


And yes, you can create this same problem that I am reporting
by having the audio for a call pass between two SER systems
with rtpproxy on both with no NAT present whatsoever (no
re-routing of audio, just bridging isolated networks).
Neither rtpproxy daemon will blink until the other does,
and so audio never works.   This has got to be wrong.

I'll point out that when I reported this a month of two ago,
someone on the list came out and said rtpproxy does not do what
I was reporting, can't do this, always passes audio in a
given direction the instant the SDP payload for that direction
passes through SER.  I don't find that to be the case and
the demonstration proves that the behavior is different.


I also don't understand the comment above about sending back to
the source port.  From what I can see, rtpproxy opens four
separate ports, two on each interface,   one for incoming and
one for outgoing on each I would assume.  If not, then that
would be a different bug as rtpproxy is opening twice the
number of ports it actually needs.  (I think it is using all
four in the two-interface mode.)

Please clarify what you are saying/suggesting if you can.
Examples appreciated.   Thanks.