Inbound Calls through SBC intermittently dropping

[RAustin70]

CUCM 14SU3, SBC 8300 v17.09.04a

We moved off TDM PRIs over to new SBCs for all calling.  Testing since November with no issues.  We ported our DNs to the carrier on 17 April from our old carrier and I set up inbound calling to come in across the SIP Trunks, and outbound is still routing out over my TDM RGs until I verify inbound is solid.

I have been getting sporadic reports of people getting calls, picking up and the call drops anywhere between 2 seconds to like 2 minutes.  I have attached an example call from this morning, customer states they answer, hear the person on the distant end, and the call just disconnects.

We use SRTP and Secure Profiles as a requirement from the customer and the SIP Provider requires it also.  I'm thinking maybe a Media resource issue, but I am flush with them.  Any ideas on how to attack this?  I am new to SBC, what logs can I dig into?

[AEledge]

---

@RAustin70 wrote:

what logs can I dig into?

---

I would start with the following debugs on the SBC and try to capture an example. Throw the SIP messages into translator X or upload to the collaboration log analyzer and you should get a pretty good idea of where the issue lies. 

debug voip ccapi inout
debug ccsip messages

 Best of luck!

[VoIP Engineer]

I agree with AEledge  that debugs into translator X would be the best way forward.

Having said that, it's often very difficult to replicate these drops.  You could use the CDRs created by CUBE to look for the call termination code.  Both VoIP Detective and Variphy should be able to read CUBE CDRs.

To clarify, I'm referring to the CDRs produced by CUBE, and not those produced by Callmanager.  You can read more about how to enable CUBE CDRs here: Enable CUBE CDRs 

[sjdamme]

With CUBEs on 17.09 you don't really need to run debugs, just enable VoIP Trace. The nice thing about VoIP Trace is it's running all the time, so when your user reports a call that dropped you can find it in VoIP Trace and pull the call signaling and SIP messaging from VoIP Trace to examine directly or drop it into TranslatorX for analysis. Because you're getting the view from the CUBE you can see if the disconnect is coming from the carrier and if so what the disconnect code is.  

[Roger Kallberg]

VoIP traces is enabled by default as stated in the document you referenced.

VoIP Trace for CUBE

The VoIP Trace feature is enabled by default and can be used to help troubleshoot issues, even in deployments with high call volumes.