cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
948
Views
0
Helpful
6
Replies

Cisco CUBE - Identifying DTMF tones?

tomc101010
Level 1
Level 1

Hi, 

 

I have a question regarding the DTMF tones on a Cisco CUBE? 

Is it possible to identify what DTMF tones are pressed by calling/called party on a CUBE router during the call? We are using SIP rtp-nte events on both call legs.

I have managed to do that by capturing RTP packets and analyzing them on the Wireshark, but I was wondering if it is possible to do the same thing somehow on the CUBE router (enabling some debug/show commands)?

 

Thank you,

TC

6 Replies 6

b.winter
VIP
VIP

Maybe something like "debug voice rtp session named-event" and "debug voip rtp packet"

Hi B.Winter,

those commands do not provide info about DTMF digits.

BR, 

TC

You could try "debug voip rtp session named-event".

But according to this old post, the only way to check the RTP-NTE events on ISR-4k is taking a packet capture:
https://community.cisco.com/t5/unified-communications-infrastructure/dtmf-is-working-but-quot-show-voip-rtp-session-named-event-quot/td-p/4463978
Which also states the corresponding bug-id.

Which you would have found out yourself, if you would have googled 2 mins.

"Dear" b.winter,

this is my third or fourth post here and on all of them you have the same comment:"...you would have found out yourself, if you would have googled 2 mins".

Before I wrote here, I had been googling and testing a lot of different debugging and show commands (or whatever), but without success. Then I decided to write here and ask for an opinion/solution from more experienced engineers. You are not one of them.

If you have tested or sometimes used these commands that you sent in your answer, you would found that they do not give you any DTMF info for RFC2833  rtp-nte. The last thing I need is someone like you who do two minutes search and send the first answer that could be found on the Internet and try to be clever.  NO, we don't need that kind of engineers here. I wanted to write you this before, but I was thinking It is not fair. But yes, it is fair.

You can continue sending your "two minutes research" google answers if you have some benefits of that, but please skip this stupid comment about googling.

 

Sincerely yours, 

TC

 

IF you would really have googled, then you would have found all debug commands which Bill and I posted and the link to the other forum thread on your own.
It's not like all this info is somewhere in a "private" space in the internet and not visible to you.
And there are a lot of people here, who are lazy asking the forum who aren't not able to search for the simplest answers on their own. The forum is not here, to google things for anybody.

And IF you would have found the commands and maybe the link already on your own, why didn't you include that info in your original post?
I will never understand, why people ask questions here and provide as little information as possible, making helping and solution finding for their own problem even harder^^

For SIP gateways, these are the commands I use to debug DTMF

Debug ccsip message
debug voip ccapi inout
debug voip rtp session named