I'm unsure if anyone else is seeing this but I just wanted to document this publicly in case anyone else has this issue and can steer me in the right direction or add their own experiences.
We've found an issue where perhaps high call volumes are confusing Polycom VVX 350 and 450 phones on 5.8.0 and 5.8.3.
We have a simultaneous ring group of about 5 phones.
Each of those phones has 1 active line and BLF monitoring the other AORs.
The number of phones and lines monitored is LESS than the suggestions outlined in the BLF Benchmarks here:https://support.polycom.com/content/dam/polycom-support/products/voice/polycom-uc/other-documents/en...
We haven't been able to replicate this on VVX 300/310/400/411 phones but can pretty reliably spam group calls until this happens on the VVX 350 and 450 phones.
Granted it takes a LOT of these group calls for it to happen but what I'm reliably seeing is that the phone will start to fail to reflect what the BLF is doing.
I've turned up the logging for Presence and for SIP and it looks like what's happening is that the phone gets a NOTIFY with a Call Sequence similar to an existing Call Sequence and becomes confused as to what it should do so it throws out a Internal Server 500 Error. I believe that the phone is then failing to change the Presence / BLF state.
0318114516|sip |3|00|Bad request either non call CSeq is to high or the state is idle CSeq:40,CSeq:42,State:38
However it looks like it will receive and process the "failed" Cseq packets properly (server info and the specific packets removed for security concerns)
0318114517|sip |0|00|<<<Data Received UDP 0318114517|sip |0|00| </dialog></dialog-info> 0318114517|sip |2|00|active dialog after UPDATE being set here, m_pActiveDialog=0x16dfdc4,this=0x16dfdc4 0318114517|sip |1|00|CStkDialog::OnEvRequest for CSeq 42 deleted NOTIFY Server 1 of 1 CSeq 41 0318114517|sip |2|00|CCallBase::IsChallenged 'NOTIFY' Dialog Tag 'EA007CD3-C8CF37C2' pRequest Tag 'EA007CD3-C8CF37C2' state 'Confirmed' 0318114517|sip |2|00|new UA Server Non-INVITE trans state 'callingTrying', timeout=0 (0x40ef4828) 0318114517|sip |3|00|CCallNoCall::calculateNewExpire new expires = 7070 0318114517|sip |3|00|UA Server Non-INVITE NOTIFY trans state 'callingTrying'->'completed' by 200 resp 65 timeout(0x40ef4828) 0318114517|sip |1|00|doDnsListLookup(udp): doDnsSrvLookupForARecordList for 'xxx.xxx.xxx.xxx' port 5060 returned 1 results 0318114517|sip |1|00|doDnsListLookup(udp): result 0 'xxx.xxx.xxx.xxx' port 5060 isInBound 0 0318114517|sip |2|00|CUser::GetFailBackMode 'Timeout' 0318114517|sip |1|00|CTrans:: SendCommand | this=0x40ef4828, bVQMonMessage=0, m_pCall->m_pUser->m_bOBFailOverReRegOn=0, m_pCall->m_pUser->m_bVQMonFailoverEnabled=1 0318114517|sip |0|00|Trying to send data to Destinationxxx.xxx.xxx.xxx on socket 178 0318114517|sip |0|00|>>> Data Send to xxx.xxx.xxx.xxx:5060 0318114517|sip |0|00| SIP/2.0 200 OK 0318114517|sip |0|00|<<< End of data send 0318114517|sip |2|00|CTrans::InitRetrans for UA Server Non-INVITE NOTIFY state 'completed' Server 1 of 1 (0x40ef4828) 0318114517|sip |1|00|CStkDialog::SetDialogState: Dialog 'firstname.lastname@example.orgG4bK8511.f11fe471.b' State 'Trying'->'Early' 0318114517|sip |2|00|CCallNoCall::Notified full dialog-info 1 of 1 version rx 41 local 40 0318114517|sip |2|00|CCallNoCall::Notified full dialog-info 1 set call state m_nVersion to 41 0318114517|sip |3|00|CCallNoCall::NewDialogList: bIsBLF = 'true', nTotalDialog = '1', justRefresh = 'false', removeFromList = 'false' 0318114517|sip |2|00|New FULL DialogList for 'sip:AOR@xxx.xxx.xxx.xxx' state 'SubscirbeDialogStaticBLF' size 1
Hello @Eric_P ,
welcome to the Polycom Community.
If you can reliable replicate this the next step is to open this with Polycom support.
In order to raise a support ticket you need to work with your Polycom reseller as they need to do this for you.
End Customers are unable to open a ticket directly with Polycom support.
If this is some sort of an Internet discounter providing your MAC address or your Polycom devices serial will enable us to look up who would be able to support you. This may not be who you purchased the Polycom device from.
If the unit is no longer within warranty please be prepared to Pay Per Incident / PPI. This is all outlined in detail here
Please ensure to provide some feedback if this reply has helped you so other users can profit from your experience.