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

[Valentin Nechayev]

Hi,

>>>>> Frank Durda IV <frank.durda at hypercube-llc.com> wrote:

> I'm running into a problem with rtpproxy on this point,
> quoting from the README:

> - - - - - - - - - - -
> - after the session has been created, the proxy listens on the port it has
>   allocated for that session and waits for receiving at least one UDP
>   packet from each of two parties participating in the call. Once such
>   packet is received, the proxy fills one of two ip:port structures
>   associated with each call with source ip:port of that packet. When both
>   structures are filled in, the proxy starts relaying UDP packets between
>   parties;
> - - - - - - - - - - -

> However, a number of clients frequently fail to emit any audio
> when originating a call until they hear something from the
> TDM gateway, such as ring-back or the called party answering.

If rtpproxy receives a packet from one side, it relays the packet
to other side. But target address for this can be incorrect. Your
problems can be tied with NAT or asymmetric implementation, in
which packets are waited on one address (declared in SDP) but sent
from another address.

> So although rtpproxy is receiving a stream of audio, such as
> a voice mail menu robot, the calling party can't hear any of
> it unless they happen to make some noise or randomly and blindly
> press a DTMF key.

Sounds very similar to incorrect SDP announce or NAT issue.
You should verify this using packet dump.

It shall be also noted that some gateways have some strange policy
against changing remote ("remote" - for them, "local" - for other
side) address. I have seen this on Cisco gateways of 53xx/54xx
series: if address declared in SDP has changed, Cisco rejects to
send to new address (and continues to send to previously known
one) until something is received from new address. Now PortaOne
version of rtpproxy has special runtime option to enable "RTP
invites" which are sent to remote side until some packet is
received from it. This fixes work with Cisco.

> Is there a setting adjustment to get rtpproxy to just pass
> the RTP packets from directed calling and called sources
> even if one party hasn't happened to make noise yet?

As declared above, rtpproxy does it by default.

-- 
Valentin Nechayev
PortaOne Inc., Software Engineer
mailto:netch at portaone.com