04-04-2022 08:25 AM - edited 04-04-2022 08:51 AM
Hello Dears,
I am a little bit confused about the usage of media resources (in particular xcoding). In the following documentation
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,
Solved! Go to Solution.
04-05-2022 02:54 AM
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:
04-04-2022 09:12 AM
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.
04-04-2022 04:18 PM - edited 04-04-2022 04:19 PM
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.
Best regards,
04-05-2022 02:54 AM
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:
04-05-2022 02:48 PM
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,
04-05-2022 10:36 PM
Hi,
I just meant Raw In-Band.
04-06-2022 07:31 AM
Hello BWinter
Newly thanks for your help, now it is more clear,
Kind regards,
04-05-2022 06:09 AM
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.
04-06-2022 07:32 AM
Hello Elliot,
Many thanks for your help, now all is right
Kind regards,
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide