cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Walkthrough Wednesdays
602
Views
10
Helpful
11
Replies
Highlighted
Beginner

dtmf tones failing (SIP-->H323)

Hi.

I have a DDI(SIP) mapped onto an IVR i am using h323 protocol between us and the customer. When i run the debugs h245 asn1 and voip rtp session named-event i can see that the SIP provider is forwarding us the right dtmf (rtp-nte) but when we send them out via h245 alphanumeric not all dtmf tones are transmitted.

This is an intermittent issue which has been failing a lot lately. Is there anyway to fix this can we use a reliable mode for dtmf transmissions?

I am attaching the logs for your reference.

The digits pressed on this call was

Choose Language ( Pressed 1) -----> Transmitted

Dial-Extension (1011921) -----------> Failed ( not all tones transmitted).

Thanks

Hassan

11 REPLIES 11
Highlighted
Rising star

have you configured the dtmf-relay rtp-nte digit-drop command on the incoming SIP dial-peer?

//Suresh Please rate all the useful posts.
Highlighted

I didnt have the command in but tried with this command and the same issue...

Highlighted

Please share your config with us...current running config

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts
Highlighted

Attaching the incoming and outgoing dial-peer would that be ok?

INCOMING

dial-peer voice 76 voip

translation-profile incoming SIP-INBOUND

media flow-around

signaling update from gtd  calling

session protocol sipv2

session target sip-server

incoming called-number 4486105695xxxx

voice-class codec 1 

dtmf-relay rtp-nte digit-drop

dtmf-interworking rtp-nte

no vad

OUTGOING

dial-peer voice 861572 voip

destination-pattern 86105695xxxx

session target ipv4:2.3.xxx.xxx

dtmf-relay h245-alphanumeric

no vad

Highlighted

I am not sure if this is okay..it all depends on if these are the dial-peers matched for the calls...You need to use debug voip ccapi inout to check if these are the dial-peers matched...If they are then please do the ff:

dial-peer voice 76 voip

no dtmf-interworking rtp-nte

Remove that command and test again...

May I ask why you are using media-flow around?

Can you also post the full output of

debug voip rtp named session-event

debug h225 asn1

debug h245 asn1

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts
Highlighted
Beginner

Hello,

In addition to the above, I would request you to kindly share the complete call-flow as in the following example:

PSTN--SIP TRUNK--CUBE---H323--CUCM--IP PHONE

Also to narrow down the issue I would request you to collect sniffers from the egress and ingress interfaces of the CUBE and check if the DTMF tones are passing through the CUBE properly.

If the end device is a CUCM then while making the test call also collect the detailed SDI/SDL traces for the call.

Highlighted

Hi Guys,

The flow is

PSTN----SIP-TRUNK------CUBE-----H323------CUCM-----IVR

I have tried removing the configuration but it did not help. Is there anyway to send reliable DTMF?

I am attaching the logs thank you so much for the help.

Highlighted

Looking at the logs, the DTMF packets appear not to be properly formatted..Each digit pressed should generate 7 packets..lets look at the digit 9 pressed here and used that to explain how this should work..I will be looking at the receive direction for explanation purposes

Dec 16 12:35:28.755 GMT:          s=DSP d=VoIP payload 0x65 ssrc 0x44F5236F sequence 0xB898 timestamp 0x32A0

Dec 16 12:35:28.755 GMT:          Pt:101    Evt:9       Pkt:0A 06 40  >>

Dec 16 12:35:28.775 GMT:          s=VoIP d=DSP payload 0x65 ssrc 0x44F5236F sequence 0xB899 timestamp 0x32A0

Dec 16 12:35:28.775 GMT:  << Pt:101    Evt:9       Pkt:0A 06 E0

Dec 16 12:35:28.775 GMT:          s=DSP d=VoIP payload 0x65 ssrc 0x44F5236F sequence 0xB899 timestamp 0x32A0

Dec 16 12:35:28.775 GMT:          Pt:101    Evt:9       Pkt:0A 06 E0  >>

Dec 16 12:35:28.795 GMT:          s=VoIP d=DSP payload 0x65 ssrc 0x44F5236F sequence 0xB89A timestamp 0x32A0

Dec 16 12:35:28.795 GMT:  << Pt:101    Evt:9       Pkt:0A 07 80

Dec 16 12:35:28.795 GMT:          s=DSP d=VoIP payload 0x65 ssrc 0x44F5236F sequence 0xB89A timestamp 0x32A0

Dec 16 12:35:28.795 GMT:          Pt:101    Evt:9       Pkt:0A 07 80  >>

Dec 16 12:35:28.815 GMT:          s=VoIP d=DSP payload 0x65 ssrc 0x44F5236F sequence 0xB89B timestamp 0x32A0

Dec 16 12:35:28.815 GMT:  << Pt:101    Evt:9       Pkt:0A 08 20

Dec 16 12:35:28.815 GMT:          s=DSP d=VoIP payload 0x65 ssrc 0x44F5236F sequence 0xB89B timestamp 0x32A0

Dec 16 12:35:28.815 GMT:          Pt:101    Evt:9       Pkt:0A 08 20  >>

Dec 16 12:35:28.835 GMT:          s=VoIP d=DSP payload 0x65 ssrc 0x44F5236F sequence 0xB89C timestamp 0x32A0

Dec 16 12:35:28.835 GMT:  << Pt:101    Evt:9       Pkt:0A 08 C0

Dec 16 12:35:28.835 GMT:          s=DSP d=VoIP payload 0x65 ssrc 0x44F5236F sequence 0xB89C timestamp 0x32A0

Dec 16 12:35:28.835 GMT:          Pt:101    Evt:9       Pkt:0A 08 C0  >>

Dec 16 12:35:28.855 GMT:          s=VoIP d=DSP payload 0x65 ssrc 0x44F5236F sequence 0xB89D timestamp 0x32A0

Dec 16 12:35:28.855 GMT:  << Pt:101    Evt:9       Pkt:8A 09 60

Dec 16 12:35:28.855 GMT:          s=DSP d=VoIP payload 0x65 ssrc 0x44F5236F sequence 0xB89D timestamp 0x32A0

Dec 16 12:35:28.855 GMT:          Pt:101    Evt:9       Pkt:8A 09 60  >>

Dec 16 12:35:28.855 GMT:          s=VoIP d=DSP payload 0x65 ssrc 0x44F5236F sequence 0xB89E timestamp 0x32A0

Dec 16 12:35:28.855 GMT:  << Pt:101    Evt:9       Pkt:8A 09 60

Dec 16 12:35:28.855 GMT:          s=DSP d=VoIP payload 0x65 ssrc 0x44F5236F sequence 0xB89E timestamp 0x32A0

Dec 16 12:35:28.855 GMT:          Pt:101    Evt:9       Pkt:8A 09 60  >>

Dec 16 12:35:28.855 GMT:          s=VoIP d=DSP payload 0x65 ssrc 0x44F5236F sequence 0xB89F timestamp 0x32A0

Dec 16 12:35:28.855 GMT:  << Pt:101    Evt:9       Pkt:8A 09 60

Dec 16 12:35:28.855 GMT:          s=DSP d=VoIP payload 0x65 ssrc 0x44F5236F sequence 0xB89F timestamp 0x32A0

Dec 16 12:35:28.855 GMT:          Pt:101    Evt:9       Pkt:8A 09 60  >> Dec 16 12:35:28.755 GMT:         

The first packet says that it is the start of a new NTE digit because it does not have the endbit set (Pkt:0A 06 40 )

  • The second and third packets are repeats of the first packet for redundancy.
  • The fourth packet is a refresh packet with a duration of 50ms (0×0190 = 400 samples * 1sec / 8000 samples).
  • The fifth packet is the endbit packet (84) with a duration of 100ms (0×0320 = 800 samples * 1sec / 8000 samples) (Pkt:8A 09 60)
  • The sixth and seventh packets are redundant packets for packet five.

As you can see on digit 9, this looks okay however this is not the same for the other digits..It  may be that the router is truncating your logs...

So please take a new log and only enable

debug voip rtp named session-event

Also let us know the exact digits pressed

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts
Highlighted
Beginner

As mentioned above, the output doesnt seem to show all the logs. If needed, please try the following steps to collect the debugs for a test call:

1)            Enter the following commands on the gateway:

                Configure terminal

                No logging console

                No logging monitor

                Logging buffered 5000000 debugging

                no logging rate-limit

                Logging on

                Service timestamp debug datetime local msec

                Service sequence-numbers

                Exit

                Undebug all

                clear log

                term len 0

                debug voip rtp named session-event

2)            Make a test call.

3)            After the test call is made then enter the following commands:

                Un all

                Sh log

Highlighted

Hi,


I am attaching the logs

Call Hits IVR ------>1-------->101192.

The call fail is intermittent and some how the cube is not transmitting all the DTMF tones.

Thanks for your help guys looking forward to your response.

Thanks

Highlighted

Hello Hassan,

Unless I am missing something, in the debugs I see that for the first digit pressed there are 10 RCV and 5 SND packets.

This digit I assume was passed fine as you were able to get past the IVR.

Also I see similar behaviour for all other digits pressed but the last '1' (fourth in the string 101192) where I see that 7 packets were received and 5 were sent.

Please see the following excerpts from the debugs:

First 1 Pressed:


Dec 17 11:57:44.518 GMT:          s=VoIP d=DSP payload 0x65 ssrc 0x2100EFFC sequence 0xD623 timestamp 0xA0

Dec 17 11:57:44.518 GMT:  << Pt:101    Evt:1       Pkt:0A 00 A0

Dec 17 11:57:44.518 GMT:          s=VoIP d=DSP payload 0x65 ssrc 0x2100EFFC sequence 0xD624 timestamp 0xA0

Dec 17 11:57:44.518 GMT:  << Pt:101    Evt:1       Pkt:0A 01 40

Dec 17 11:57:44.518 GMT:          s=VoIP d=DSP payload 0x65 ssrc 0x2100EFFC sequence 0xD623 timestamp 0xA0

Dec 17 11:57:44.518 GMT:  << Pt:101    Evt:1       Pkt:0A 00 A0

Dec 17 11:57:44.518 GMT:          s=DSP d=VoIP payload 0x65 ssrc 0x2100EFFC sequence 0xD623 timestamp 0xA0

Dec 17 11:57:44.518 GMT:          Pt:101    Evt:1       Pkt:0A 00 A0  >>

Dec 17 11:57:44.518 GMT:          s=VoIP d=DSP payload 0x65 ssrc 0x2100EFFC sequence 0xD624 timestamp 0xA0

Dec 17 11:57:44.518 GMT:  << Pt:101    Evt:1       Pkt:0A 01 40

Dec 17 11:57:44.518 GMT:          s=DSP d=VoIP payload 0x65 ssrc 0x2100EFFC sequence 0xD624 timestamp 0xA0

Dec 17 11:57:44.518 GMT:          Pt:101    Evt:1       Pkt:0A 01 40  >>

Dec 17 11:57:44.778 GMT:          s=VoIP d=DSP payload 0x65 ssrc 0x2100EFFC sequence 0xD625 timestamp 0xA0

Dec 17 11:57:44.778 GMT:  << Pt:101    Evt:1       Pkt:8A 08 10

Dec 17 11:57:44.778 GMT:          s=VoIP d=DSP payload 0x65 ssrc 0x2100EFFC sequence 0xD626 timestamp 0xA0

Dec 17 11:57:44.778 GMT:  << Pt:101    Evt:1       Pkt:8A 08 10

Dec 17 11:57:44.778 GMT:          s=VoIP d=DSP payload 0x65 ssrc 0x2100EFFC sequence 0xD627 timestamp 0xA0

Dec 17 11:57:44.778 GMT:  << Pt:101    Evt:1       Pkt:8A 08 10

Dec 17 11:57:44.778 GMT:          s=VoIP d=DSP payload 0x65 ssrc 0x2100EFFC sequence 0xD625 timestamp 0xA0

Dec 17 11:57:44.778 GMT:  << Pt:101    Evt:1       Pkt:8A 08 10

Dec 17 11:57:44.778 GMT:          s=DSP d=VoIP payload 0x65 ssrc 0x2100EFFC sequence 0xD625 timestamp 0xA0

Dec 17 11:57:44.778 GMT:          Pt:101    Evt:1       Pkt:8A 08 10  >>

Dec 17 11:57:44.778 GMT:          s=VoIP d=DSP payload 0x65 ssrc 0x2100EFFC sequence 0xD626 timestamp 0xA0

Dec 17 11:57:44.778 GMT:  << Pt:101    Evt:1       Pkt:8A 08 10

Dec 17 11:57:44.778 GMT:          s=DSP d=VoIP payload 0x65 ssrc 0x2100EFFC sequence 0xD626 timestamp 0xA0

Dec 17 11:57:44.778 GMT:          Pt:101    Evt:1       Pkt:8A 08 10  >>

Dec 17 11:57:44.778 GMT:          s=VoIP d=DSP payload 0x65 ssrc 0x2100EFFC sequence 0xD627 timestamp 0xA0

Dec 17 11:57:44.778 GMT:  << Pt:101    Evt:1       Pkt:8A 08 10

Dec 17 11:57:44.778 GMT:          s=DSP d=VoIP payload 0x65 ssrc 0x2100EFFC sequence 0xD627 timestamp 0xA0

Dec 17 11:57:44.778 GMT:          Pt:101    Evt:1       Pkt:8A 08 10  >>

Last 1 Pressed:

Dec 17 11:57:52.078 GMT:          s=VoIP d=DSP payload 0x65 ssrc 0x2100EFFC sequence 0xD637 timestamp 0x21D8

Dec 17 11:57:52.078 GMT:  << Pt:101    Evt:1       Pkt:0A 00 A0

Dec 17 11:57:52.078 GMT:          s=DSP d=VoIP payload 0x65 ssrc 0x2100EFFC sequence 0xD637 timestamp 0x21D8

Dec 17 11:57:52.078 GMT:          Pt:101    Evt:1       Pkt:0A 00 A0  >>

Dec 17 11:57:52.078 GMT:          s=VoIP d=DSP payload 0x65 ssrc 0x2100EFFC sequence 0xD638 timestamp 0x21D8

Dec 17 11:57:52.078 GMT:  << Pt:101    Evt:1       Pkt:0A 01 40

Dec 17 11:57:52.078 GMT:          s=DSP d=VoIP payload 0x65 ssrc 0x2100EFFC sequence 0xD638 timestamp 0x21D8

Dec 17 11:57:52.078 GMT:          Pt:101    Evt:1       Pkt:0A 01 40  >>

Dec 17 11:57:52.334 GMT:          s=VoIP d=DSP payload 0x65 ssrc 0x2100EFFC sequence 0xD639 timestamp 0x21D8

Dec 17 11:57:52.338 GMT:  << Pt:101    Evt:1       Pkt:8A 08 30

Dec 17 11:57:52.338 GMT:          s=VoIP d=DSP payload 0x65 ssrc 0x2100EFFC sequence 0xD63A timestamp 0x21D8

Dec 17 11:57:52.338 GMT:  << Pt:101    Evt:1       Pkt:8A 08 30

Dec 17 11:57:52.338 GMT:          s=VoIP d=DSP payload 0x65 ssrc 0x2100EFFC sequence 0xD639 timestamp 0x21D8

Dec 17 11:57:52.338 GMT:  << Pt:101    Evt:1       Pkt:8A 08 30

Dec 17 11:57:52.338 GMT:          s=DSP d=VoIP payload 0x65 ssrc 0x2100EFFC sequence 0xD639 timestamp 0x21D8

Dec 17 11:57:52.338 GMT:          Pt:101    Evt:1       Pkt:8A 08 30  >>

Dec 17 11:57:52.338 GMT:          s=VoIP d=DSP payload 0x65 ssrc 0x2100EFFC sequence 0xD63A timestamp 0x21D8

Dec 17 11:57:52.338 GMT:  << Pt:101    Evt:1       Pkt:8A 08 30

Dec 17 11:57:52.338 GMT:          s=DSP d=VoIP payload 0x65 ssrc 0x2100EFFC sequence 0xD63A timestamp 0x21D8

Dec 17 11:57:52.338 GMT:          Pt:101    Evt:1       Pkt:8A 08 30  >>

Dec 17 11:57:52.338 GMT:          s=VoIP d=DSP payload 0x65 ssrc 0x2100EFFC sequence 0xD63B timestamp 0x21D8

Dec 17 11:57:52.338 GMT:  << Pt:101    Evt:1       Pkt:8A 08 30

Dec 17 11:57:52.338 GMT:          s=DSP d=VoIP payload 0x65 ssrc 0x2100EFFC sequence 0xD63B timestamp 0x21D8

Dec 17 11:57:52.338 GMT:          Pt:101    Evt:1       Pkt:8A 08 30  >>

This is different from the standard behaviour where we expect to see 7 packets in both directions.

Is there a way we can know that what digits in this call were passed correctly and what digits got missed?

Else we can collect packet captures from the IVR's interface and the ingress and egress interface of the router along with the same debugs.

Also you can try resetting the dsp if possible and check if it helps.

Content for Community-Ad