[Serusers] Deadly embrace with rtpproxy - Caused by coding error? Possible fix attached

[Valentin Nechayev]

Hi,

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

> To recap, I have rtpproxy in a two-interface configuration (which based
> on comments here few people actually use), and the problem was that
> rtpproxy was refusing to forward audio to either party until it had
> received at least one audio packet from both parties.  If either
> party also had a similar policy, you had a deadly embrace and
> a dead-air call.  No ring-back (for 183 calls), and no call audio.

We had got the same problem with Cisco gateways. If renegotiation is
made, the gateway sometimes change its port, but didn't start flow
from new port until some packet has received on it. To fix this, we
invented option to do periodical sendings to configured address (which
can differ from real address) - it fixed the problem with Cisco.
Later this customer reported that Cisco agreed this is their bug and
fixed it.

> Attached is the tw-line-change context diff.  I would appreciate if

For most readers it is better to use "unified context" diff format
(diff -u), than "old context" (diff -c).

> ! 	    if (spa->untrusted_addr == 0 && !(spa->addr[pidx] != NULL &&
> ! 	    if (spa->untrusted_addr[pidx] == 0 && !(spa->addr[pidx] != NULL &&

I agree - this looks like simple typo.

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