Thanks for posting the solution. I was following the issue with much curiosity!<br><br><div class="gmail_quote">On Thu, Jan 8, 2009 at 1:47 PM, Matthew Kaufman <span dir="ltr">&lt;<a href="mailto:matthew@matthew.at">matthew@matthew.at</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Anthony Minessale wrote:<br>
&gt; This is a very unique problem as many people get this basic situation<br>
&gt; working daily so<br>
&gt; it must be a network issue of some sort.<br>
As I said yesterday, a network problem makes the most sense, but the<br>
behavior was still very strange.<br>
<br>
I have now tracked down the problem, and the issue also explains why<br>
changing firmware and changing FreeSWITCH settings *appeared* to make a<br>
difference while not actually having any effect on the root cause.<br>
<br>
The server running FreeSWITCH also had tunneling software enabled that,<br>
when traffic for RFC1918 space was detected coming from the machine,<br>
installed a policy route that forced traffic to exit via that tunnel<br>
(but had no effect on any RFC1918 coming in from the outside). The same<br>
software also ensured that if traffic from RFC1918 space came in first,<br>
a policy would instead be installed (on a per address/port basis) that<br>
allowed that traffic to flow via the native interface. As it happened,<br>
this conflicted with my routing configuration, which is that my phones<br>
were on a network using RFC1918 addresses. There was no NAT, so it<br>
should have worked to use RFC1918 addresses, but the tunnel policy<br>
routing choice of trigger addresses overlapped the actual addresses of<br>
my phones, thus the problem.<br>
<br>
This tunnel policy routing causes the following behavior:<br>
&nbsp;1) SIP works (phone always sends first packet when registering,<br>
bidirectional policy installed)<br>
&nbsp;2) RTP works *if* the phone sent the first RTP packet (phone sends<br>
first, bidirectional policy installed)<br>
&nbsp;3) RTP is received successfully from the phone at the switch, and RTP<br>
appears to be sent (via tcpdump) from the switch to the phone but does<br>
not actually arrive at the phone *if* FreeSWITCH sends first (FreeSWITCH<br>
sends first, tunnel outbound policy is installed forcing traffic to be<br>
routed into the tunnel instead of towards the phone).<br>
<br>
As a result, things where the phone always gets the first RTP out (e.g.,<br>
calling local voicemail box, where the recording-playback is being<br>
clocked by the RTP coming in) work. Things where the switch always gets<br>
the first RTP out (often the case with early media for ringback, for<br>
instance) always cause the calling party to never hear anything for the<br>
rest of the call (which also explains why transfer from ringback to<br>
voicemail greeting still isn&#39;t audible... even though there&#39;s new<br>
signalling when it goes from early media to answered by voicemail, the<br>
same &nbsp;(blocked-in-one-direction) RTP port is in use)<br>
<br>
Interestingly, with the old firmware the switch sent early media to the<br>
caller (breaking its ability to hear the called party) and the called<br>
party always sent RTP first when the phone was picked up... the new<br>
firmware doesn&#39;t send RTP instantly upon picking up the ringing phone,<br>
and so the incoming RTP audio from the switch triggers the same policy<br>
routing issue, thus making it impossible for either end to hear the other.<br>
<br>
Likewise, making changes to settings like inbound-proxy-media causes<br>
changes in who sends RTP first for each end of the call, also changing<br>
the behavior.<br>
<br>
Thanks to the folks who reviewed my traces and configurations to make<br>
sure that everything seemed reasonable on the switch side. As it was<br>
determined yesterday, the best next step was the verify that the packets<br>
really arrived at the phone, which as described above, they don&#39;t.<br>
<br>
Hopefully this information will be helpful to someone who encounters the<br>
same problem in the future, rare as it might be.<br>
<br>
Matthew Kaufman<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Freeswitch-users mailing list<br>
<a href="mailto:Freeswitch-users@lists.freeswitch.org">Freeswitch-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</blockquote></div><br>