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

Answered Question

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



Correct Answer by paolo bevilacqua about 9 years 3 months ago

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.



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Brian Carscadden Thu, 01/17/2008 - 09:32
User Badges:

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.

paolo bevilacqua Thu, 01/17/2008 - 13:46
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

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)


paolo bevilacqua Thu, 01/17/2008 - 14:00
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

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.

paolo bevilacqua Thu, 01/17/2008 - 14:25
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

Ah, interesting. Can you try:


voice service voip

no supplementary-service sip moved-temporarily


Hope this helps, please rate post if it does!

paolo bevilacqua Thu, 01/17/2008 - 14:33
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

Ok. Please collect "debug ccsip message" then.

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

paolo bevilacqua Thu, 01/17/2008 - 14:43
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

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

paolo bevilacqua Thu, 01/17/2008 - 15:15
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

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.


Correct Answer
paolo bevilacqua Fri, 01/18/2008 - 05:24
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

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.



paolo bevilacqua Fri, 01/18/2008 - 06:24
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

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".

Actions

This Discussion