Polycom IP Soundstation 6000 Dropping calls

[JoeShmo]

I have setup a Polycom Soundstation IP 6000 (Generic SIP), and it works, displays caller/called names, works great, but drops the call randomly.  We have never gotten a call to last more than 5 minutes.  This goes for internal and external calls, including internal calls to other IP sets (Mitel 5330) on the same controller.

I have setup the SIP Capabilities to:
Disable Reliable Provisional Responses (Yes)
Force sending SDP in initial Invite message (Yes)
Suppress Use of SDP Inactive Media Streams (No)
Renegotiate SDP To Enforce Symmetric Codec (No)
Allow Device To Use Multiple Active M-Lines (Yes)
based on various readings on the internet.  And since I cannot logon to MOL, I cannot check the knowledgebase for the guide on Mitels site on exactly how to set it up.

But hopefully, someone might recognize this dropped call bit, and know whats going on.  Speech path is fine, network is fine, calls have lasted anywhere from 2 seconds to 3 minutes, 27 seconds.  Also, immediately after the call is dropped, and both parties hang up, when trying to call the polycom back, we get a reorder and out of service message.  The Polycom will pretend to make a call, but just sit there.  Retrying, it eventually will connect back up.

So pure guess is that is dropped communication to the controller for some reason?  Are there any good logs on the Mitel I can look at?  The "All Maintenance/Software Logs" are kind of useless for this issue.

[markyb73]

Hello,
1st time poster here although joined a while ago 
Attached is the docs for the Polycom 6000.
I can see that some of your settings are wrong.
If you still get the calls cutting off i guess the best thing would be a wireshark trace and see which end is terminating the call and what error you are getting.
Let us know how you get on.

[JoeShmo]

Thank you very much for the Tech Note doc!!  Apparently I cut and pasted the wrong thing, as my settings for SIP Capabilities were correct when verifying with the Tech Notes.

One thing that WAS "wrong" is a setting on the phone itself within SIP for "Expires".  Setting this to 300 (default) or 301 (suggested in note, as anything above 300) resulted in dropped calls under 5 minutes.  Setting this to 3600 causes dropped calls in under an hour.  Last test lasted EXACTLY 55 minutes.
Because Conference calls can last more than 1 hour, this number will need to be even higher.  Worse yet is apparently it'll drop the call on intervals of that Expire setting.
So now that I have the phone in my office, I'll have to mess around to get a capture going on.  sometimes I miss the days of using hubs; made sniffing much easier!  =)

But, at this time, I'm going with the premise that its dropping the call on expire/re-registration.
I have to believe that the thousands of other Polycom IP Conference phones out in the world are not doing this same behavior.  So there must be some other setting somewhere that I'm missing.

[JoeShmo]

Calling from the SIP phone to my 5330 set...
POLYCOM -> MCD  INVITE
MCD -> POLYCOM  Trying
MCD -> POLYCOM  Moved Permanently
POLYCOM -> MCD  ACK
(I answer call, no additional packets after I answer, and stay on the line until dropped).
When dropped:

POLYCOM -> MCD  REGISTER
MCD -> POLYCOM  Trying
MCD -> POLYCOM  401 Unauthorized
POLYCOM -> MCD  REGISTER
MCD -> POLYCOM  Trying
MCD -> POLYCOM  OK

It seems like the first attempt at registering always comes back with an Unauthorized, but second time works.  Wondering if this is what is causing the call to drop?  Its trying to renew, but cant, and instead drops everything and starts the registration process again.

Setting expire to something like a week might help in that the phone will randomly drop a call sometime during a week, and hopefully no one is on a call at that particular time.

Other notes:
  There are no firewalls, proxies, or NATs involved in any way.
  The MCD IP is the IP I normally use to get at the management interface
  The MCD is a VirtualMCD (MSL on ISS (Running in Vmware))
  The packet capture was done from the Linux commandline of the MSL server that runs the MCD.
  Should I be using one of the other IPs for SIP?  (the MSL box has 5 IPs, since thats just the way these things work.  The other IPs are "Reserved", probably used for RTC, etc..

The temporary fix I guess is just to set the Expire on the Polycom to about a week (604800 seconds)

[markyb73]

i guess that would be the conference call from hell if it lasted a week   
I wonder if the sip for expires timer is similar to the session timer on sip trunks.
I could be wrong but if it does the same thing, on some of my sites by setting the session timer to 0 stops calls being dropped, or in other words the pbx doesn't tear the call down after the timer expires.
I wonder if your timer can be set to 0, but i guess a week is enough.
Glad you got it working though!

[ralph]

It seems like the first attempt at registering always comes back with an Unauthorized, but second time works.  Wondering if this is what is causing the call to drop?  Its trying to renew, but cant, and instead drops everything and starts the registration process again.

I think this is normal part of SIP negotiations.  One device says "lets talk G.729" and the other says "no authorized".  So they then try G.711.

Ralph

[acejavelin]

It seems like the first attempt at registering always comes back with an Unauthorized, but second time works.  Wondering if this is what is causing the call to drop?  Its trying to renew, but cant, and instead drops everything and starts the registration process again.

I think this is normal part of SIP negotiations.  One device says "lets talk G.729" and the other says "no authorized".  So they then try G.711.

Ralph

This is completely normal for SIP, but has nothing to do with codec or other settings, it is the "challenge" stage for authorization, the first Invite doesn't contain security credentials (or they are ignored if it does) and the host returns a "Not Authorized" after which the host is awaiting an invite with credentials. Totally normal setup.


In the SIP Device Capabilities form of the 3300, try these setting:

Registration Period Minimum to 300 seconds (In the SIP device should then be no lower than 600 seconds for re-registration because SIP Registrations that occur less than 300 seconds apart will be ignored and most devices use a random reregistration timer between 50%-100% of the programmed setting to prevent multiple devices registering at the same time and overloading the 3300)

Session Timer to Disabled (never clear calls down automatically based on time)

[JoeShmo]

SIP Capabilities already have Registration Period Minimum set to 300.  Session timer is set at 90 currently, but will try disabling it if calls continue to drop.
at the moment, with my silly 604,800 second "Expire" setting on the phone itself, I had a call up overnight that has not dropped yet (15 hours so far).
According to the Polycom docs:
voIpProt.server.x.expires:  The phone's requested registration period in seconds.
Note: The period negotiated with the server may be different.  The phone will attempt to re-register at the beginning of the overlap period.  For example, if "expires"=3600 and "overlap"=60, the phone will re-register after 3540 seconds (3600 - 60).

(note from me: there is no "overlap" variable I can get to in the web interface, but the docs say the default is 60.)

Another note is that during this whole call (16 hours so far), I have not seen any traffic going back to my MCD.  Only the Invite, Trying, Moved Permanantly, and Ack when the call was first established.  I would think that I should see some keep-alives or something going back to the controller from the phone.  but maybe the Mitel phone is doing that?  (I'm filtering on the IP of the polycom, and watching real-time).
(my previous "15 hours so far", and "16 hours so far" just reflects the number of times I've gotten interrupted during this post.. 16:35 on the call timer now).