cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1466
Views
15
Helpful
8
Replies

When does CUBE require transcoding resources for DTMF and when doesn't

david.alfaro1
Level 1
Level 1

Hello Dears,

 

I am a little bit confused about the usage of media resources (in particular xcoding). In the following documentation

 

www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/200412-DTMF-Relay-and-Interworking-on-CUBE.html#anc35

 

Before to continue, I would like to clarify I understand it is not possible in scenarios like NTE to SIP-INFO, or SIP-KPML/NOTIFY to/from SIP-INFO cause the nature of these protocols so it is normal and understandable.

 

Documentation says CUBE requires xcoding resources in scenarios like Interworking between an OOB method and RFC2833 for flow-around calls, what it is also OK and understandable.

 

However, in flow-through scenarios, documentation says CUBE is able to interwork between all other DTMF relay methods without the need of a transcoder, even though for the sake of Interworking between RFC2833 and Voice In-band xcoding is required; therefore I do not understand how in flow-through scenarios xcoding is not requiered for example to interwork between dtmf-relay signal/alphanumeric and dtmf-relay kpml/notify, in other words, how it is possible that xcoding resources is not necessary for DTMF in connections H.323-SIP and viceversa if these are different in syntax and rules, etc. so when yes and when not, I am confused.

 

Another idea I have is CUBE signaling plane does not require xcoding resources whether H323-SIP signaling interworking or viceversa be, and another different stuff is CUBE media plane that it could require xcoding recources for interoperability. Therefore it could be the answer but I am not sure.

 

Could you help me to understand please, I would appreciate your help.

 

Kind regards,

 

1 Accepted Solution

Accepted Solutions

My opinion:

As DTMF via SIP-messages, RTP-NTE and H.245 messages are already dedicated messages (and not any messages coded into the audio streams), CUBE has the ability to just convert between those message types.

And since those messages are not audio streams, CUBE doesn't need any DSPs for that (MTP).

 

On the other side, when CUBE needs to convert those DTMF-messages to In-Band (or vice-versa), any identity needs to take the messag and generate an audio stream (like a normal call). So therefore, you would need DSPs.

 

Tables 3 to 7 probably give you a better overview of this:

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/dtmf-relay.html#concept_264617919921874995299551391601561

View solution in original post

8 Replies 8

Transcoding is required when you are going between different codecs (One side G.711, the other G.729). DTMF internetworking is usually done via an MTP (media termination point). This can be software in CUCM, software in the gateway, or hardware in the gateway. If you do hardware in the gateway, it requires PVDM modules.

Hello Elliot,

 

Thank you for your answer. I understand it from the point of view of a Gateway, but what about when the ISR is playing like B2BUA (CUBE). Actually I would like to understand what about the Cisco documentation says CUBE is able to interwork between all other DTMF relay methods without the need of a transcoder.

For example, in CUBE flow-through it is possible to interwork between h323 dtmf-relay signal/alphanumeric and sip-notify/kpml, but what I do not understand is why documentation says no transcoder is needed.

 

www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/200412-DTMF-Relay-and-Interworking-on-CUBE.html#anc35

 

Best regards,

My opinion:

As DTMF via SIP-messages, RTP-NTE and H.245 messages are already dedicated messages (and not any messages coded into the audio streams), CUBE has the ability to just convert between those message types.

And since those messages are not audio streams, CUBE doesn't need any DSPs for that (MTP).

 

On the other side, when CUBE needs to convert those DTMF-messages to In-Band (or vice-versa), any identity needs to take the messag and generate an audio stream (like a normal call). So therefore, you would need DSPs.

 

Tables 3 to 7 probably give you a better overview of this:

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/dtmf-relay.html#concept_264617919921874995299551391601561

Hello B. Winter

 

Thank you newly for your help I appreciate

 

Where you wrote "when CUBE needs to convert those DTMF-messages to In-Band (or vice-versa)" in, did you mean In-Band as either NTE In-Band or Raw In-Band, or only Raw In-Band?

 

Kind regards,

Hi,

 

I just meant Raw In-Band.

Hello BWinter

 

Newly thanks for your help, now it is more clear,

 

Kind regards,

I don't have a full blown explanation, but transcoding is primarily for the audio stream itself. @b.winter also makes an excellent point about CUBE DTMF internetworking handle most of that stuff on its own.I did an really early deployment for a customer before Cisco worked with SIP. It did the SIP to H.323 DTMF conversion fine back then (early 2000's). There are commands in the "voice service voip" section for "dtmf-interworking" that can help with that.

Hello Elliot,

 

Many thanks for your help, now all is right

 

Kind regards,

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: