VoIP Mailing List Archives
Mailing list archives for the VoIP community |
|
| View previous topic :: View next topic |
| Author |
Message |
matthew at matthew.at
Guest
|
 Posted: Thu Jan 08, 2009 3:28 pm Post subject: [Freeswitch-users] polycom one-way audio problem (solved) |
 |
|
Anthony Minessale wrote:
| Quote: | 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@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org |
|
| Back to top |
|
 |
markgreene at gmail.com
Guest
|
| Posted: Thu Jan 08, 2009 5:17 pm Post subject: [Freeswitch-users] polycom one-way audio problem (solved) |
|
|
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@matthew.at (matthew@matthew.at)> wrote:
| Quote: | Anthony Minessale wrote:
| Quote: | 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@lists.freeswitch.org (Freeswitch-users@lists.freeswitch.org)
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
|
|
|
| Back to top |
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
Search
