[Freeswitch-users] polycom one-way audio problem (solved)

[Matthew Kaufman]

Anthony Minessale wrote:
> This is a very unique problem as many people get this basic situation 
> working daily so
> it must be a network issue of some sort.
As I said yesterday, a network problem makes the most sense, but the 
behavior was still very strange.

I have now tracked down the problem, and the issue also explains why 
changing firmware and changing FreeSWITCH settings *appeared* to make a 
difference while not actually having any effect on the root cause.

The server running FreeSWITCH also had tunneling software enabled that, 
when traffic for RFC1918 space was detected coming from the machine, 
installed a policy route that forced traffic to exit via that tunnel 
(but had no effect on any RFC1918 coming in from the outside). The same 
software also ensured that if traffic from RFC1918 space came in first, 
a policy would instead be installed (on a per address/port basis) that 
allowed that traffic to flow via the native interface. As it happened, 
this conflicted with my routing configuration, which is that my phones 
were on a network using RFC1918 addresses. There was no NAT, so it 
should have worked to use RFC1918 addresses, but the tunnel policy 
routing choice of trigger addresses overlapped the actual addresses of 
my phones, thus the problem.

This tunnel policy routing causes the following behavior:
 1) SIP works (phone always sends first packet when registering, 
bidirectional policy installed)
 2) RTP works *if* the phone sent the first RTP packet (phone sends 
first, bidirectional policy installed)
 3) RTP is received successfully from the phone at the switch, and RTP 
appears to be sent (via tcpdump) from the switch to the phone but does 
not actually arrive at the phone *if* FreeSWITCH sends first (FreeSWITCH 
sends first, tunnel outbound policy is installed forcing traffic to be 
routed into the tunnel instead of towards the phone).

As a result, things where the phone always gets the first RTP out (e.g., 
calling local voicemail box, where the recording-playback is being 
clocked by the RTP coming in) work. Things where the switch always gets 
the first RTP out (often the case with early media for ringback, for 
instance) always cause the calling party to never hear anything for the 
rest of the call (which also explains why transfer from ringback to 
voicemail greeting still isn't audible... even though there's new 
signalling when it goes from early media to answered by voicemail, the 
same  (blocked-in-one-direction) RTP port is in use)

Interestingly, with the old firmware the switch sent early media to the 
caller (breaking its ability to hear the called party) and the called 
party always sent RTP first when the phone was picked up... the new 
firmware doesn't send RTP instantly upon picking up the ringing phone, 
and so the incoming RTP audio from the switch triggers the same policy 
routing issue, thus making it impossible for either end to hear the other.

Likewise, making changes to settings like inbound-proxy-media causes 
changes in who sends RTP first for each end of the call, also changing 
the behavior.

Thanks to the folks who reviewed my traces and configurations to make 
sure that everything seemed reasonable on the switch side. As it was 
determined yesterday, the best next step was the verify that the packets 
really arrived at the phone, which as described above, they don't.

Hopefully this information will be helpful to someone who encounters the 
same problem in the future, rare as it might be.

Matthew Kaufman