cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3264
Views
5
Helpful
2
Replies

CUBE DTMF Config for use with CVP / VVB

We are having a bit of trouble in our lab setting up 11.6 VVB with inbound SIP and LumenVox ASR/TTS...

 

It seems like the VVB is not accepting DTMF, although when we go back to our trusty old VXML GW ISR, we have no problem.

 

Our inbound answering dial-peer from the SIP provider in CUBE has this...

dtmf-relay rtp-nte

 

Our outbound dialpeer to CVP has both configured

dtmf-relay sip-kpml

 

Wireshark on the CVP shows the KPML offered in the INVITE received from the CUBE and in the INVITE sent to VVB for the VRU xfer label. So it looks like the CUBE is doing what it is meant to do.

 

‘Show sip-ua calls’ on the cube whilst the prompts are played and you see the negotiated dtmf-relay as rtp-nte with 101 payload on the itsp leg but on the CVP leg you see negotiated dtmf-relay as inband-voice and payload 0

 

This suggests to me that the VVB is not accepting the dtmf-relay offered…

 

Now the fun comes when you set both dial-peers to RTP-NTE.  To debug voip rtp session named event and show sip-ua calls, it would appear that DTMF-relay negotiation has been successful. 

 

The INVITE sent to VVB has

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

 

But still no DTMF is processed by VVB...

 

Any ideas?

1 Accepted Solution

Accepted Solutions

Thank you!  This is very helpful.  

 

As a last resort, we actually looked at the Cisco published documentation from the Collaboration System Release v12.0 which includes contact center with UCCE/CVP/VVB.  Cisco published the CUBE config, which was a very simple, almost out-of-the-box config -- so we dumbed it down with “voice-class sip pass-thru content sdp” on the dial-peer pairs for CVP calls and got it working.

 

This will complicate matters later if we need to transcode to G.729 on agent legs but for now in our demo lab this worked as designed.

 

Thanks!!!

-Chris

View solution in original post

2 Replies 2

Gerry O'Rourke
Spotlight
Spotlight

Chris,

 

When a device uses RFC 2833 (RTP-NTE) the first RTP packet for each key press needs to have the RTP Marker bit set to TRUE. Do a wireshark on the CUBE and see if teh provider is setting this marker bit correctly.

If it is not set - the VVB server will not "see"  / respond to DTMF presses. So it might be a bug on the PSTN provider for DTMF.

 

Try calling in to the CUBE from CUCM. e.g. CUCM-> CUBE-> CVP -> VVB

 

See below for a wireshark extract showing this marker bit (in below - its set to false - each DTMF press first packet requires (by the RFC) to have this set to true.

Gerry

 

RTP-MarkerBit.JPG

Thank you!  This is very helpful.  

 

As a last resort, we actually looked at the Cisco published documentation from the Collaboration System Release v12.0 which includes contact center with UCCE/CVP/VVB.  Cisco published the CUBE config, which was a very simple, almost out-of-the-box config -- so we dumbed it down with “voice-class sip pass-thru content sdp” on the dial-peer pairs for CVP calls and got it working.

 

This will complicate matters later if we need to transcode to G.729 on agent legs but for now in our demo lab this worked as designed.

 

Thanks!!!

-Chris

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: