CUBE - New Deployment Issue - Not working DTMF Relay

[StewieGriffin]

Hello,

Scheme:

Cisco SCCP-based IP Phone > CUCM 9.1 w/ SIP Trunk > CUBE (28XX, 151-4.M7) > SIP ITSP

CUCM Active Call Proc. Node IP: 10.10.10.9
CUBE Inside Interface IP: 10.10.10.10
CUBE Outside Interface IP: 20.20.20.20
Cisco IP Phone: 10.10.10.8
ITSP SBC IP: 30.30.30.30
ITSP SIP domain: itsp.domain
Calling Pty: 9017654321 (translated in CUCM's route pattern which addresses CUBE)
Called Pty: 9011234567

While call was connected calling party dialed consequently 0,1,2,3,4 but far-end IVR does not react :(

Symptom:

While outbound call is connected calling party (IP Phone) dials digits which are not detected by any far-end PSTN (non-corporate) IVR at all.

Thoughts:

ITSP support only inband relay (RFC2833, Named Telephone Events or NTEs).
Using NTE provides a standard way to transport DTMF tones in RTP packets.
Thus rtp-nte is configured for both CUCM and ITSP dial-peers on CUBE.

While initial troubleshooting found that for the active call inbound CUBE's leg shows rtp-nte, but outbound inband-voice.

A have an assumption that ITSP doesn't give us 101=rtp-nte payload in 183 Response but I'm not sure.

m=audio 10318 RTP/AVP 8
b=AS:64
a=rtpmap:8 PCMA/8000
a=ptime:20
a=maxptime:20

Questions:

1.How to make CUBE to successfully relay DTMF in according to ITSP requirement?

2. Why 'show call act/hist voice brief' doesn't show call id? All my attempts are identified as 2... )
It is hard to differentiate b/w call active/history records..

[Suresh Subramanian]

in CUCM SIP Trunk settings, can you set the DTMF signaling method only to RFC2833 and save the config, reset the trunk & check the behaviour?

[Ayodeji Okanlawon]

From the logs your provider is not advertising any DTMF in their answer..

This could be because your inbound dial-peer is matching the default dial-peer 0 or your provider is not sending any answer. So to confirm what it is please do a test and send only the ff log debug voip ccapi inout..We need to see which inbound dial-peer this call is matching

Received:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 20.20.20.20:5060;branch=z9hG4bKCD2349
From: <sip:79017654321@itsp.domain>;tag=162189F8-1F82
To: <sip:79011234567@itsp.domain>;tag=01CD3246313536414BB55C00
Call-ID: FECCC591-B07111E4-82EBE759-B8B0000E@20.20.20.20
CSeq: 101 INVITE
Timestamp: 1423582838
Content-Length: 154
Supported: 100rel,precondition,timer
Content-Type: application/sdp
Content-Disposition: session;handling=required
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK
Contact: <sip:79011234567@30.30.30.30:5060;transport=udp>

v=0
o=- 0 0 IN IP4 30.30.30.30
s=-
c=IN IP4 30.30.30.30
t=0 0
m=audio 10318 RTP/AVP 8---no DTMF caps advertised here
b=AS:64
a=rtpmap:8 PCMA/8000
a=ptime:20
a=maxptime:20
 

[StewieGriffin]

 Ayodeji,

Thanks for your feedback.
If you look through the already attached output 'show call act voice' of the file 'case-no-dtmf_-_cube-show-20140210-1.txt' you will find the following:

...
PeerId=101
CallOrigin=2
tx_DtmfRelay=rtp-nte
CallDuration=00:00:05 sec

PeerId=201
CallOrigin=1
tx_DtmfRelay=inband-voice
CallDuration=00:00:05 sec
...

2    : 230 18:40:38.048 MSK Tue Feb 10 2015.1 +1890 pid:101 Answer 79017654321 active
 dur 00:00:04 tx:234/37440 rx:233/37280
 IP 10.10.10.8:22688 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711alaw TextRelay: off
 media inactive detected:n media contrl rcvd:n/a timestamp:n/a
 long duration call detected:n long duration call duration:n/a timestamp:n/a

2    : 231 18:40:38.068 MSK Tue Feb 10 2015.1 +1860 pid:201 Originate 79011234567 active
 dur 00:00:04 tx:233/37280 rx:307/49120
 IP 30.30.30.30:10318 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711alaw TextRelay: off
 media inactive detected:n media contrl rcvd:n/a timestamp:n/a
 long duration call detected:n long duration call duration:n/a timestamp:n/a

This means that the target dial-peers (inbound and outbound are matched as designed).

!
dial-peer voice 101 voip
 description -= inbound leg from CUCM to CUBE =-
 session protocol sipv2
 incoming called-number x
 voice-class codec 1  
 voice-class sip bind control source-interface Loopback0
 voice-class sip bind media source-interface Loopback0
 dtmf-relay rtp-nte
 no vad
!
dial-peer voice 201 voip
 description -= outbound leg from CUBE to ITSP =-
 translation-profile outgoing cdpn-delete-prefix-00XX7
 max-conn 40
 destination-pattern x
 session protocol sipv2
 session target dns:sbc.itsp.domain
 voice-class codec 1  
 voice-class sip profiles 1
 voice-class sip bind control source-interface Vlan100
 voice-class sip bind media source-interface Vlan100
 dtmf-relay rtp-nte
 no vad
 
Now I have an argue with ITSP to make them send me NTE in their 183/200 response..

I've also:

1. Tried to disable dtmf-relay at all on dial-peers (trying inband-voice) but this doesn't work and also not recommended AFAIK.
2. Changed the value for SIP Trunk DTMF Signaling Method from 'No preference' to 'RFC 2833' w/ reset applied recommended by Suresh. No luck.

[Ayodeji Okanlawon]

Okay you need to get your provider to correct their switch and get them to advertise dtmf-relay using rtp-nte to you. There is nothing else you can do on CUBE or CUCM if the far end is not sending any dtmf capabilities..

Take your traces and send it to them. Tell them you are not receiving any DTMF attributes

[StewieGriffin]

 Ayodeji, Suresh,

I've already showed em these logs w/ explanation, but they do not understand these logs at all.
So ITSP still cannot make their SBC to offer RTP-NTE DTMF relay as they initially stated.

I've made CUCM's trunk to use MTP after all and DTMF is working for now (it is actual inband in the g.711a voice path).

[Suresh Subramanian]

not only in 183, but also in 200 OK message, the provider is not sending the dtmf relay.

so good to talk to them with these logs.

004575: Feb 10 18:40:39.930 MSK: //231/27F5A4800002/SIP/Msg/ccsipDisplayMsg:
Received: 
SIP/2.0 200 OK
Via: SIP/2.0/UDP 20.20.20.20:5060;branch=z9hG4bKCD2349
From: <sip:79017654321@itsp.domain>;tag=162189F8-1F82
To: <sip:79011234567@itsp.domain>;tag=01CD3246313536414BB55C00
Call-ID: FECCC591-B07111E4-82EBE759-B8B0000E@20.20.20.20
CSeq: 101 INVITE
Timestamp: 1423582838
Content-Length: 154
Supported: 100rel,precondition
Content-Type: application/sdp
Content-Disposition: signal;handling=required
Content-Transfer-Encoding: binary
MIME-version: 1.0
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK
Min-SE: 1800
Session-Expires: 1800
Contact: <sip:79011234567@30.30.30.30:5060;transport=udp>

v=0
o=- 0 0 IN IP4 30.30.30.30
s=-
c=IN IP4 30.30.30.30
t=0 0
m=audio 10318 RTP/AVP 8
b=AS:64
a=rtpmap:8 PCMA/8000
a=ptime:20
a=maxptime:20

[BalajiSivaraj49175]

Configuring the DTMF relay for CUBE messages

Configure DTMF Relay for SIP
Router(config)#dial-peer voice 1 voip
Router(config-dial-peer)#dtmf-relay ?
cisco-rtp Cisco Proprietary RTP
h245-alphanumeric DTMF Relay via H245 Alphanumeric IE
h245-signal DTMF Relay via H245 Signal IE
rtp-nte RTP Named Telephone Event RFC 2833
sip-kpml DTMF Relay via KPML over SIP SUBCRIBE/NOTIFY
sip-NOTIFY DTMF Relay via SIP NOTIFY messages
You can configure more than one method per dial-peer, depending on the requirements of the terminating ends.

Router(config-dial-peer)#dtmf-relay rtp-nte ?
cisco-rtp Cisco Proprietary RTP
digit-drop Digits to be passed out-of-band and in-band digits dropped
h245-alphanumeric DTMF Relay via H245 Alphanumeric IE
h245-signal DTMF Relay via H245 Signal IE
sip-kpml DTMF Relay via KPML over SIP SUBCRIBE/NOTIFY
sip-NOTIFY DTMF Relay via SIP NOTIFY messages

[Prassha]

If they are unable to understand SIP signalling other way is to showcase them via PCAP. This is something provider understand easily.

Collecting PCAP is the only option left to proove them that they are not sending any digits.

From CUBE collect PCAP from Incoming and outgoing interface and bring them on call and show them if they are passing the digits where are the digits and DTMF method?

Should be an easy option.

If they are sending the DTMF method ask them to share the snippet.