cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
11708
Views
5
Helpful
18
Replies

Help analyzing "debug voip dialpeer inout", "debug voice ccapi inout" logs

pkluss
Level 1
Level 1

The bigger picture of what I'm doing is trying to ultimately discern what the cause of my "transfer directly to VM" problems are. Along the way, I've decided to try to understand the debug logs in greater detail. In examining them, I have come across many questions about the dial-peer matching process. I've read all of the documentation I could find, but none of it mirrors my personal experience and I'm having trouble making sense of it. Our phone system works, with the exception of this one funky little issue which is the following:

We use four digit extensions internally. I created (using Cisco documentation) a way for people to transfer a caller directly to another recipient's VM. This is done by hitting "Transfer, 4 + EXT#, Transfer". This works if the call was originally placed using the internal 4-digit extension, but does not work if placed (internally or externally) using the 10-digit DID.

So my post is really two-fold:

First, can someone help me understand my debug logs that I've attached? The "debug voip dialpeer inout" is especially perplexing. It seems to try to match many more things than it should. At times the logs seem to be flat out lying, labeling an incorrect number as the "Calling Number" or "Called Number".

Second, can someone help me resolve this issue? I did start a post a while back, but I feel a lot has changed since then so I'm starting this new post.

Let me know if you need anything clarified or extra logs.

Thanks.

pk

18 Replies 18

What, you can't read minds!? Haha, OK, that version was too sanitized, I agree.

Here's a much more useful version.

Thanks for you help so far. I think this is part of what is so great about Cisco, the community, and specifically in this case, you.

Ok. I see that the call is taken in G.729 at line 3859. Then the forward is made with g.711 (the only possible choice with CUE) at line 3912.

So, a codec mismatch problem. Try changing the voice-class on incoming DP from ITSP to accept g.771u only. If it works, my theory is proven. At that point, you should configure transcoding to accept calls in g.729 and do VM in G.711. That is a bit complicated but can be done. The alternative is to run everything in G.711 that beside the larger bandwidth usage, has also advantages.

Thank you for the appreciation, it's a pleasure to deal with someone able to clearly detail a problem and willing to study and work about it.

Wow! It played out just as you suspected. I switched the codec to g.711 and it worked like a charm. I'll spend my morning trying to figure out how to set it up as you mentioned. Looks like I've got some reading to do on codecs. I was totally barking up the wrong tree at the beginning.

Thanks again.

You are very welcome. Thanks for the nice rating and good luck!

PS. How to properly obscure traces - interesting matter for discussion ! I shot myself in the foot with the so-called "best practice".