08-05-2015 07:21 AM - edited 03-17-2019 03:53 AM
In an effort to add more DSP resources to our CUBE, we added the offer-all option on the voice-class command in the dial-peer interface.
I need clarification on why the following configuration results in the codecs being used for G711 to G711 calls.
voice class codec 2
codec preference 1 g711ulaw
codec preference 2 g729r8
dspfarm profile 4 transcode universal
codec g729abr8
codec g729ar8
codec g711alaw
codec g711ulaw
codec g729br8
codec g729r8
maximum sessions 10
associate application CUBE
What is the best practice for configuring hardware DSPs? Would it be accurate to believe that because the codec preference in our voice class codec 2 - could force the g711 to g711 calls?
Thanks in advance for your help and guidance.
Rainee
08-05-2015 04:05 PM
Yes the voice class codes provides a list of codecs for negotiation on call legs and with a set preference. There is no best practice in terms of codecs, it based on your requirements.
Let me know if you have more questions, and probably best if you can explain your call flow as well.
-Terry
Please rate all helpful posts
08-06-2015 06:10 AM
Terry,
I guess I wasn't very clear. What does the offer-all option on the dial-peer interface voice-class command do? What would be the effects of having it configured as opposed to not having it configured based on the configuration above?
Thanks,
Rainee
08-06-2015 09:14 AM
The offer-all keyword allows the device to offer all codecs configured in a codec voice class.
08-06-2015 10:01 AM
That's what I believed to be the case but when I look at the INVITE/SDP both codecs are advertised with or without the offer-all.
04-07-2017 10:11 AM
'offer-all' applies to the following case:
When the incoming INVITE have SDP in it (called Offer), SIP early offer forced doesn’t have any impact on the outgoing INVITE, whatever SDP offer comes in, goes out unless the codec class applied on the outgoing dial peer gets applied with offer-all.
In my setup, we were receiving delayed offer INVITE, and using
voice-class sip early-offer forced
to send the early offer with SDP.
But there was a use case when incoming INVITE has sdp in it, early offer forced didn't do anything, and because of that, only incoming SDP is sent out in the outgoing INVITE, using the:
voice-class codec 3000 offer-all
actually now sends all codecs defined in the codec class 300 instead of just the received sdp.
08-06-2015 10:45 AM
>>> I need clarification on why the following configuration results in the codecs being used for G711 to G711 calls.
voice class codec 2
codec preference 1 g711ulaw
codec preference 2 g729r8
The Voice Class Codec is the configuration that allows you to use the preferred Codecs in the Dial-Peers and else where (where ever applicable) and is always explicitly configured. If you do not configure them, then it takes the default Codec in the Dial-Peers (I think it is G.729)
>>>dspfarm profile 4 transcode universal
codec g729abr8
codec g729ar8
codec g711alaw
codec g711ulaw
codec g729br8
codec g729r8
maximum sessions 10
associate application CUBE
The DSPFarm Profiles always by default add all the variations of G.729 hence you get the above configuration, which means you automicaly enable the High Complextiy Codecs as well. Hence It is recommended that you remove all the default codecs and add only the required codec.
Most of the ITSPs use G.729 and G711ulaw and G711alaw codecs and your config should look like this if you are not using any of the other codecs.
dspfarm profile 4 transcode universal
No codec g729abr8
No codec g729ar8
codec g711alaw
codec g711ulaw
No codec g729br8
codec g729r8
maximum sessions 10
associate application CUBE
HTH
08-06-2015 12:04 PM
Thank you for the response.
So what is the purpose of the offer-all option on the voice-class command in the dial-peer interface? It doesn't seem to prevent connections using G711 or G729.
08-06-2015 01:06 PM
Hi,
I dont think I understood your question. I tried to check offer-all on voice class as well as dial-peer voice and I didnt see that as an option.
Could you please show us the context of the command?
Regards
08-06-2015 01:13 PM
Below is the dial-peer configuration -
dial-peer voice 3000 voip
translation-profile incoming V-IN
translation-profile outgoing V-OUT
destination-pattern 987654321T
session protocol sipv2
session target ipv4:xxx.xxx.xxx.xxx:xxxx
session transport udp
incoming called-number .T
incoming uri to vOPTIONS
voice-class codec 2 offer-all
voice-class sip copy-list 100
voice-class sip bind control source-interface GigabitEthernet0/1.1962
voice-class sip bind media source-interface GigabitEthernet0/1.1962
dtmf-relay rtp-nte
no vad
08-06-2015 01:31 PM
I've seen a few of the responses to your question, but no one has really asked you what you are trying to accomplish.
Remember, cisco phones can all natively support g.729 and g.711. Newer ones also support ilbc, and g.722.
Assuming you are using one of the native codecs, you will not need any transcoding from you cube. If you are using a cube, your carrier will likely be using g711, so again, no transcoding required.
You said you want to get more DSP resources, and then said your trying to hand out ever possible codec. That is counterproductive. The more complex a codec you offer to transcode, the more DSP resources your going to gobble up.
The real question is, what model router are you using? If its older, you can pick up DSP modules for next to nothing. If its newer, its a different story.
08-06-2015 01:46 PM
I have CUBE that connects my network to the Carrier Network. Our CUBE configuration did not support G729 when calling some Carrier destinations that only had G729. When trying to call a DID on the Carrier's network that only supported G729, the CUBE would send a 503 Response to CUCM.
I added the dspfarm profile (transcode universal). I was able to make the calls. Then one of our engineers stated that I needed to code the offer-all parameter on the voice-class codec 2 command in the dial-peer.
It did not seem to make a difference so I was wondering what this parameter does. The captures don't show anything different.
Thank you so much for the time that you have spent
08-06-2015 01:50 PM
Okay, so for clarification, you are using a CUCM -> CUBE -> ITSP. Is that correct?
If thats correct, and your carrier only supports G.729, you need to set up your regions so that off net calls are G.729. That way you wont need any resources. Every cisco phone can do G.729 natively.
08-06-2015 01:56 PM
Yes we are CUCM -> CUBE -> ITSP.
Our carrier supports both, but there are some DIDs that we found to be running their own VoIP platform (typically small businesses) that only support G729 for cost purposes.
So we added more DSPs to our CUBE and created the dspfarm profile (transcode universal). This has resolved the issues, but we were not clear what the purpose of the offer-all parameter is. It doesn't seem to have an impact one way or the other.
08-06-2015 02:03 PM
Honestly, I've never seen that nomenclature used. Your cube actually doesnt use the DSP's as part of its dial peers. Instead, CUCM requests them as needed. Under the dspfarm profile, you only need to list off the codecs you could potentially use. I prefer to go with the minimum config that meets all requirements. With that you only need to have g711u and g729r listed.
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