SPA 962 -- Intermittently no audio (RTP port closed/unreachable)

[maxjar2012]

Greetings all!

We recently purchased 21 Linksys SPA 962 phones for our office. We are running these directly from our PoE switch (Cisco 300) to our sipx box which is on the same subnet and switch (sipx is not running iptables). Most of our phone calls work correctly but we are finding that periodically (say 1 in 10 phone calls) we have no audio. There is no NAT in the setup so this should all be relatively straightforward.

The most interesting part of the problem is that it appears to be the phone itself. The reason I believe that it is the phone is because of the attached pcap trace. You can see the first call in this trace is bad and the second one is actually completed correctly.

The negotiation over SIP all seems to work correctly and the phone says what RTP port to use but when sipx tries to communicate to that RTP port the phone returns an ICMP port unreachable! From attaching a syslog to the phone as a debug server it appears that the phone believes it has opened up the receiving port but further down it attempts to send rtp back to sipxecs and it cannot send rtp back but this is because I believe the port failed to allocate/open in the first place.

I have tried all four of the available Cisco firmwares that I could find and they all produce the same issue. I also have tried putting the phone on it's own VLAN, tried SRTP, tried symmetric RTP, tried Sticky 183 and nothing seems to fix the behavior.

Did we get bad phones???

We also have a Grandstream ATA gateway with polycoms attached and all of those phone calls work 100% of the time.

Thanks in advance!

[nseto]

That is unusual.    If those were recently purchased, see if you can exchange for a spa5xx phone. 

I only found a parameter that would disconnect the call if it sees the icmp port unreachable.  Described below.  Parameter is in the SIP/RTP Parameters section.

Max RTP ICMP Err—Number of successive ICMP errors allowed when

transmitting RTP packets to the peer before the Cisco IP phone terminates

the call. If the value is set to 0 (the default), the Cisco IP phone ignores the

limit on ICMP errors, disabling the feature.

[maxjar2012]

It's also unusual that it's happening on all 5 of the 21 phones that I have tested to make sure it wasn't just one of them that seemed to have the issue. All of them have a manufacture date of March 2010. I too have seen the Max RTP ICMP Err parameter and it is zero so it shouldn't be a factor.

Also, as you can see from the pcap dump there is no RTP packet that ever gets sent from the phone to the pbx so there isn't an opportunity to receive an ICMP Port Unreachable response from the pbx which would trigger the shutoff.

Unfortunately, we threw away the boxes since this purchase was part of an office move and the cleanup crew thought we didn't need them anymore so returning them is likely not an option. The seller on Amazon stated that manufacturer remedies need to be pursued.

Do I have any other options? I know the EOL announcement states that August 17, 2012 is the last date for a failure analysis which is rapidly approaching.

Thanks,

Jarrod

[nseto]

When I was reading the parameter description, it looks like it's describing the Cisco phone as sending the ICMP errors, the part where it says 'transmitting...to the peer before the Cisco IP phone terminates'.  So I figure, if you set that parameter to 1, then when the phone sends 1 ICMP error, it will terminate the call.

Was the purchase less than a year from the Amazon seller?  If so, you can contact our phone support on doing a possible RMA, so this can be looked at.  http://www.cisco.com/en/US/support/tsd_cisco_small_business_support_center_contacts.html 

[kirfogcisco]

I have exactly the same problem. Have you found a solution yet?

[kirfogcisco · Accepted solution]

I got it. Disable CDP on system page. That's it.

[maxjar2012]

Thanks Kirill. I can confirm that at least initially this appears to have corrected the issue on the phone I am testing right now.

[rchochelinski]

Hi Jarrod,

Was it CDP ? Did you solve this problem ?

Thank you

[maxjar2012]

Yes, it was CDP for me. Turning it off corrected my issues.

[kirfogcisco]

http://en.wikipedia.org/wiki/Cisco_Discovery_Protocol