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