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

[Mark Greene]

Thanks for posting the solution. I was following the issue with much
curiosity!

On Thu, Jan 8, 2009 at 1:47 PM, Matthew Kaufman <matthew at matthew.at> wrote:

> 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
>
>
>
>
>
> _______________________________________________
> Freeswitch-users mailing list
> Freeswitch-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20090108/9905ad30/attachment.html