Hi,
>>>> Frank Durda IV
<frank.durda(a)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@portaone.com