Re: dtmf tones failing (SIP-->H323)

hassanalirazi · ‎12-16-2013

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

Suresh Subramanian · ‎12-16-2013

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

//Suresh Please rate all the useful posts.

hassanalirazi · ‎12-16-2013

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

Ayodeji Okanlawon · ‎12-16-2013

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

hassanalirazi · ‎12-16-2013

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

Ayodeji Okanlawon · ‎12-16-2013

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

Sambit Khuas · ‎12-16-2013

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.

hassanalirazi · ‎12-16-2013

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.

Ayodeji Okanlawon · ‎12-16-2013

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

Sambit Khuas · ‎12-17-2013

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

hassanalirazi · ‎12-17-2013

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

Sambit Khuas · ‎12-18-2013

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