cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
11629
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

1 Accepted Solution

Accepted Solutions

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.

View solution in original post

18 Replies 18

Not sure of how you're accomplishing direct transfers to voicemail. An approach I've used with great success is to create a Voicemail profile with a mask of xxxx (for 4-digit extensions, xxx for 3, etc.). Then create a CTI route point with extension *xxxx (again, based on the length of your extension dial plan). In the CTI *xxxx extension assign it to the voicemail profile above and set to CallForwardAll to voicemail. When you receive a call and want to transfer directly to voicemail hit Transfer-*xxxx-tranfer (where xxxx is the extension of the recipient). The call routes to the CTI port, then directly to Unity, using the xxxx voice mailbox mask.

I followed the document linked here (http://www.cisco.com/en/US/products/sw/voicesw/ps5520/products_tech_note09186a00802ab979.shtml ) in order to set this up. I'm using Call Manager Express, so I don't think CTI Route Points are an option. It does sound like essentially the same procedure though, masked by differed nomenclature. So to transfer a call to voicemail, we would just prefix do as we normally would but prepend a '4' to the extension number.

Hi,

the reason why the debugs are confusing, is because certain "features" are poorly or not documented at all, for example, on inbound DP, "destination-pattern" matches the calling number, although more logically "answer-address" is referenced in documentation.

Now, I don't think your problem is due to DP.

The fact that it works for internal calls but not external hints to some kind of bug.

Can you let us know, which exact IOS are you using ?

That makes me feel good to hear someone else echo my thoughts of Cisco's poor documentation. For the most part Cisco is great about it. I can more often than not find an explicit walkthrough when I'm trying to do a common setup, but I've found it sorely lacking in helping to understand debug logs.

Anyway, here is the info on my IOS version:

AdageCME#show version

Cisco IOS Software, 2800 Software (C2800NM-SPSERVICESK9-M), Version 12.4(15)T1, RELEASE SOFTWARE (fc2)

Yes. Many many things in documentation could be improved, however if you compare cisco to other vendors, you will find they practically have nothing.

Now, can you try 12.4(11)XJ4 that is the most stable release ? Also, how the call fail exactly, can you take an isdn q931 debug of when the call drops as I suppose it does ?

I'm not sure what the exact terminology is here, but I don't have an ISDN circuit. We're pure SIP. I don't know if those are mutually exclusive (and would appreciate corrections if what just said makes no sense), but I do know that the "debug isdn" commands aren't available to me.

[Edit: I just realized you asked several more questions that I neglected to answer, so here goes...

I could try the 12.4(11)XJ4 release, but I'd like to do that as a last resort.

There are two very distinct ways this scenario is handled depending on whether or not the initial caller used the 4 digit extension or the 10 digit DID. If the caller used the 4 digit extension (inside caller), the transferor hits "Transfer - 4 - EXT# - Transfer" and after hitting the second transfer button, the caller is dropped into the voice mailbox of whatever EXT# was entered. If the 10 digit DID was used to call (internally or externally), the transferor hits "Transfer - 4 - EXT#" (at this point the transferor hears the voicemail greeting on their phone) and then when they complete the transfer sequence by hitting "Transfer" for the second time, the call is dropped on all sides.

Ah, interesting. Can you try:

voice service voip

no supplementary-service sip moved-temporarily

Hope this helps, please rate post if it does!

Already got that in there. Here's the entire section:

voice service voip

clid network-provided

allow-connections sip to sip

no supplementary-service sip moved-temporarily

no supplementary-service sip refer

sip

outbound-proxy dns:mcleod-sbc13.mcleodusa.net

outbound-proxy dns:mcleod-sbc13.mcleodusa.net

Ok. Please collect "debug ccsip message" then.

Alos, I would still recommend trying 12,4(11)XJ4.

Are there things in this log that I should blur or edit? I don't care about my phone numbers...

I'll post it when I hear back.

Best practice is to XXX numbers, ip's, usernames and password.

Hmm, look at line 3920. Where it says

<>5989@chcg.global.voip.mcleodusa.net>

it should probably say

<>XXXXXX5989@chcg.global.voip.mcleodusa.net>

right?

If I'm right, how do I go about making that change?

Hmm for sure you blurred a lot. I cannot tell what are the CUE addresses (private) and what not.

Anyway, if you just want to change the (called ?) number going to CUE, that is a translation-rprofile and rule under CUE DP. But I have to say, reading the debug, cannot tell what is what, sorry.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: