SIP Debugging

[cmparish5]

I'm seeing tons of the following error in my CUBE log...

 %VOICE_IEC-3-GW: SIP: Internal Error (INVITE, invalid IE content): IEC= ...  on callID -1

I understand to properlky troubleshoot I need to run debugs.

How intrusive are the various SIP debug commands...

Debug voice ccapi inout

debug voice dialpeer inout

debug ccsip Command Options

SIP-GW#debug ccsip ?
  all        Enable all SIP debugging traces
  calls      Enable CCSIP SPI calls debugging trace
  error      Enable SIP error debugging trace
  events     Enable SIP events debugging trace
  info       Enable SIP info debugging trace
  media      Enable SIP media debugging trace
  messages   Enable CCSIP SPI messages debugging trace
  preauth    Enable SIP preauth debugging traces
  states     Enable CCSIP SPI states debugging trace
  transport  Enable SIP transport debugging traces

[Maren Mahoney · Accepted solution]

debug voip ccapi inout is very verbose and I wouldn't run that on a production system except as a last resort, debug voice dialpeer is not as verbose. However, you can limit the output of both of those debugs by using a Generic Call Filter Module. Here is a link for information on that:  Cisco IOS Voice Troubleshooting and Monitoring -- Voice Call Debug Filtering on Cisco Voice Gateways

For the 'debug ccsip' debugs, the one you will want to start with is 'debug ccsip messages'. With the output, there might be others to run to help better define your problem.

Hopefully one of the other smart people on the boards can help with that specific error message.

Maren

[cmparish5]

Thank you Maren, I appreciate your reply.  

[Dennis Mink]

I tend to agree with Maren,

i have always run debug ccsip messages on prod systems, and never had any adverse effects, debug ccapi i dont run very often, because i dont find it that useful

---

---

[Jonathan Schulenberg]

FWIW I consider ccsip messages dangerous under load, though call filtering helps - if you can get it to work. The commands “logging rate-limit” and “logging queue-limit” will also blunt the impact of a very noisy debug, usually avoiding a performance impact; however, they also make any debugs you’re attempting to read potentially incomplete. That took me a few hours to learn the hard way once.