I have two Polycom phones (one 550 and one 650) successfully registered to the switch. If I call from either extension to the other and answer, audio flows from the calling party to the called party, but audio does not flow from the called party back to the calling party. Even more strange, the called party does not answer, then when the call is sent to voicemail, the calling party *also* does not hear any of the voicemail greeting, though they are recorded successfully. Calling the voicemail box directly from either phone *does* work, and the calling party can hear the prompts just fine in that case. There is no NAT between the phones and FreeSWITCH. Suggestions? Matthew Kaufman matthew@matthew.at
What FS revision and is this a default Dialplan? Please pastebin the output of the CLI while making test calls. Be sure to press F8 to enable debug messages. Also, if you can do so turn on SIP messages by launching FreeSWITCH with TPORT_LOG=1. -MC Sent from my iPhone On Jan 6, 2009, at 10:22 PM, Matthew Kaufman <matthew@matthew.at> wrote:
I have two Polycom phones (one 550 and one 650) successfully registered to the switch. If I call from either extension to the other and answer, audio flows from the calling party to the called party, but audio does not flow from the called party back to the calling party. Even more strange, the called party does not answer, then when the call is sent to voicemail, the calling party *also* does not hear any of the voicemail greeting, though they are recorded successfully. Calling the voicemail box directly from either phone *does* work, and the calling party can hear the prompts just fine in that case.
There is no NAT between the phones and FreeSWITCH.
Suggestions?
Matthew Kaufman matthew@matthew.at
_______________________________________________ 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
Updated to current a couple days ago, default dialplan, extensions are registered as 1001 and 1002. tcpdump on the freeswitch host shows RTP going both ways to/from both phones. This is running on CentOS, so your log and debug instructions don't make much sense, but I do have SIP tracing enabled... see http://pastebin.freeswitch.org/6694 The phones are on the 10.10.155.0/24 subnet, the switch is on 198.202.199.1, but there's no NAT between, just a router... from the POV of the switch, it can see all the phones on the 10.10.155.0/24 network directly. Matthew Kaufman Michael S Collins wrote:
What FS revision and is this a default Dialplan? Please pastebin the output of the CLI while making test calls. Be sure to press F8 to enable debug messages. Also, if you can do so turn on SIP messages by launching FreeSWITCH with TPORT_LOG=1.
-MC
Sent from my iPhone
On Jan 6, 2009, at 10:22 PM, Matthew Kaufman <matthew@matthew.at> wrote:
I have two Polycom phones (one 550 and one 650) successfully registered to the switch. If I call from either extension to the other and answer, audio flows from the calling party to the called party, but audio does not flow from the called party back to the calling party. Even more strange, the called party does not answer, then when the call is sent to voicemail, the calling party *also* does not hear any of the voicemail greeting, though they are recorded successfully. Calling the voicemail box directly from either phone *does* work, and the calling party can hear the prompts just fine in that case.
There is no NAT between the phones and FreeSWITCH.
Suggestions?
Matthew Kaufman matthew@matthew.at
_______________________________________________ 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
_______________________________________________ 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
What svn rev and what firmware rev on the phone? On Jan 7, 2009, at 12:33 PM, Matthew Kaufman wrote:
Updated to current a couple days ago, default dialplan, extensions are registered as 1001 and 1002.
tcpdump on the freeswitch host shows RTP going both ways to/from both phones.
This is running on CentOS, so your log and debug instructions don't make much sense, but I do have SIP tracing enabled... see http://pastebin.freeswitch.org/6694
The phones are on the 10.10.155.0/24 subnet, the switch is on 198.202.199.1, but there's no NAT between, just a router... from the POV of the switch, it can see all the phones on the 10.10.155.0/24 network directly.
Matthew Kaufman
Please update the phone to 3.1.1.0137 http://downloads.polycom.com/voice/voip/sp_ss_sip/spip_ssip_3_1_1_release_si... We can't support anything but the latest firmware... the same applies to most phones since we routinely report, fix and work around issues. 2.1.2 is very old. /b On Jan 7, 2009, at 12:46 PM, Matthew Kaufman wrote:
Brian West wrote:
What svn rev and what firmware rev on the phone? Looks like 1.0 trunk 11009M for the switch, 2.1.2.0078 SIP on the phone (what it shipped with, haven't updated to latest firmware)
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
Brian West wrote:
Please update the phone to 3.1.1.0137
http://downloads.polycom.com/voice/voip/sp_ss_sip/spip_ssip_3_1_1_release_si...
We can't support anything but the latest firmware... the same applies to most phones since we routinely report, fix and work around issues. 2.1.2 is very old.
/b
I'll do that. I wanted to change as few things at a time as possible, so I'll make that the next test and let you know. Do note that 2.1.2, while old, is still the current ship version from Polycom, per their matrix. Matthew Kaufman
Matthew Kaufman wrote:
Brian West wrote:
Please update the phone to 3.1.1.0137
http://downloads.polycom.com/voice/voip/sp_ss_sip/spip_ssip_3_1_1_release_si...
We can't support anything but the latest firmware... the same applies to most phones since we routinely report, fix and work around issues. 2.1.2 is very old.
/b
I'll do that. I wanted to change as few things at a time as possible, so I'll make that the next test and let you know.
I have upgraded to the latest boot roms and SIP firmware, 3.1.1.0137. I get the same one-way audio between the polycom and x-lite, and now on a polycom-polycom call I get no audio in *either* direction. (Not much of an improvement, but different) Trace of the call using the newest firmware is at http://pastebin.freeswitch.org/6695 Matthew Kaufman
could you use a pcap util like tcpdump or wireshark to capture the traffic so we can see the rtp too that may help to figure it out. On Wed, Jan 7, 2009 at 1:44 PM, Matthew Kaufman <matthew@matthew.at> wrote:
Matthew Kaufman wrote:
Brian West wrote:
Please update the phone to 3.1.1.0137
http://downloads.polycom.com/voice/voip/sp_ss_sip/spip_ssip_3_1_1_release_si...
We can't support anything but the latest firmware... the same applies to most phones since we routinely report, fix and work around issues. 2.1.2 is very old.
/b
I'll do that. I wanted to change as few things at a time as possible, so I'll make that the next test and let you know.
I have upgraded to the latest boot roms and SIP firmware, 3.1.1.0137. I get the same one-way audio between the polycom and x-lite, and now on a polycom-polycom call I get no audio in *either* direction. (Not much of an improvement, but different)
Trace of the call using the newest firmware is at http://pastebin.freeswitch.org/6695
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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
Anthony Minessale wrote:
could you use a pcap util like tcpdump or wireshark to capture the traffic so we can see the rtp too that may help to figure it out. Dump at the switch side of all traffic to/from the originating Polycom is at http://pastebin.freeswitch.org/6696
I kept the call short to keep the total amount of RTP to a reasonable size. Matthew Kaufman
is it possible to get a binary pcap? That way we can look at it in wireshark. you can email it direct to me and brian On Wed, Jan 7, 2009 at 3:21 PM, Matthew Kaufman <matthew@matthew.at> wrote:
Anthony Minessale wrote:
could you use a pcap util like tcpdump or wireshark to capture the traffic so we can see the rtp too that may help to figure it out. Dump at the switch side of all traffic to/from the originating Polycom is at http://pastebin.freeswitch.org/6696
I kept the call short to keep the total amount of RTP to a reasonable size.
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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
Matthew Kaufman wrote:
I have upgraded to the latest boot roms and SIP firmware, 3.1.1.0137. I get the same one-way audio between the polycom and x-lite, and now on a polycom-polycom call I get no audio in *either* direction. (Not much of an improvement, but different)
For those following on the list, a successful workaround is to set "inbound-proxy-media" to true. Why that should be necessary, and why it behaves the way it does when that is set to false (the strangest part being that calls that go directly to VM have good audio, but calls that ring the far end for a time and then go to VM have no audio *even* when they've gone over to VM), I still don't understand. Matthew Kaufman
Matthew Kaufman wrote:
Matthew Kaufman wrote:
I have upgraded to the latest boot roms and SIP firmware, 3.1.1.0137. I get the same one-way audio between the polycom and x-lite, and now on a polycom-polycom call I get no audio in *either* direction. (Not much of an improvement, but different)
For those following on the list, a successful workaround is to set "inbound-proxy-media" to true. Why that should be necessary, and why it behaves the way it does when that is set to false (the strangest part being that calls that go directly to VM have good audio, but calls that ring the far end for a time and then go to VM have no audio *even* when they've gone over to VM), I still don't understand.
I spoke too soon. If I turn on "inbound-proxy-media", then it goes back to "called party can hear calling party, but calling party calling party cannot hear called party" (the same as it was before upgrading to the latest Polycom firmware), and additionally the calling party now gets ringback (didn't before), but if the called party doesn't answer instead of dropping to voicemail it goes to fast busy. The last is probably related to: "[ERR] sofia_glue.c:1608 sofia_glue_tech_set_codec() No audio codec available" which then fires INCOMPATIBLE_DESTINATION. I also picked up version 11089 *and* threw out all the conf directory and regenerated it from the sample source, so this is 100% today-build, default-settings (except for the adjustments to inbound-proxy-media). Matthew Kaufman
Did you ever find out if the rtp was making it to your phone? Did you get around to testing the echo exten? That is the most basic call you can do it is 1 leg call just playing your own audio back. Also 9998 plays the tetris song with the tone generator. We for sure can see rtp packets in the pcap bound for your phone. 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. Can we rule out your network where the phones live by testing some phones on the same network as FS? Do you have a hub you could put the phones on so you can packet sniff the traffic to them? On Thu, Jan 8, 2009 at 12:51 AM, Matthew Kaufman <matthew@matthew.at> wrote:
Matthew Kaufman wrote:
Matthew Kaufman wrote:
I have upgraded to the latest boot roms and SIP firmware, 3.1.1.0137. I get the same one-way audio between the polycom and x-lite, and now on a polycom-polycom call I get no audio in *either* direction. (Not much of an improvement, but different)
For those following on the list, a successful workaround is to set "inbound-proxy-media" to true. Why that should be necessary, and why it behaves the way it does when that is set to false (the strangest part being that calls that go directly to VM have good audio, but calls that ring the far end for a time and then go to VM have no audio *even* when they've gone over to VM), I still don't understand.
I spoke too soon. If I turn on "inbound-proxy-media", then it goes back to "called party can hear calling party, but calling party calling party cannot hear called party" (the same as it was before upgrading to the latest Polycom firmware), and additionally the calling party now gets ringback (didn't before), but if the called party doesn't answer instead of dropping to voicemail it goes to fast busy.
The last is probably related to: "[ERR] sofia_glue.c:1608 sofia_glue_tech_set_codec() No audio codec available" which then fires INCOMPATIBLE_DESTINATION.
I also picked up version 11089 *and* threw out all the conf directory and regenerated it from the sample source, so this is 100% today-build, default-settings (except for the adjustments to inbound-proxy-media).
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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
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
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> 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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (5)
-
Anthony Minessale
-
Brian West
-
Mark Greene
-
Matthew Kaufman
-
Michael S Collins