Hi,
I have a requirement for setting a default codec for a confbridge session. e.g. when i make a call using “ulaw”, the moment i transfer that call in the conference, it will switch to g729 codec.
I searched but wasn’t able to find any option for setting codec in confbridge app… Can someone help please.
Thanks
There isn’t really a way to accomplish what you want to do. The formats that a channel can use and what is in use on a channel are negotiated during the call setup, and typically aren’t re-negotiated unless the endpoint chooses to do so. Applications - such as ConfBridge - don’t typically attempt to change the formats that a channel is using. They’ll simply set up a translation using a codec if it is necessary.
If you want to restrict a channel to use g722, or prefer to use it, you would need to do that in the channel driver configuration - but there isn’t currently a way to do this from the dialplan.
Thanks for your reply, I feared this but you mentioned that codecs aren’t re-negotiated unless endpoint chooses so how endpoint chooses to do so and how we can mimic/hack it and force it manually?
Secondly you mentioned that Confbridge will setup a translation using a codec if necessary… I would love to know how to accomplish it. I have done such things by editing the source code of Asterisk and achieving/developing functions/applications which are not available in dialplan so I would like to hear an idea if I can accomplish any such thing by editing the souce?
Thanks
You can’t. An endpoint is generally not going to send a re-INVITE to change the codecs mid-call, and if it does or exposes that in some fashion, it will be a device specific attribute.
Technically, ConfBridge always transcodes, since it has to mix the audio from all the participants. In its case, it transcodes the audio to signed linear, mixes it, then transcodes it back to the write format of each particular participant. It maintains a special set of transcoders in bridge_softmix for this purpose.
That doesn’t really help you, however, since it doesn’t force the participants to all use a particular format, e.g., g722.
The notion of having ‘on-the-fly switching to different formats’ has been discussed a few times at AstriDevCons. If I were going to go about doing something like this, I’d use the PJSIP stack in Asterisk, as it will be far easier than attempting to do it chan_sip (in fact, I wouldn’t even bother trying in chan_sip, given its structure). res_pjsip_session already exposes a function to initiate a media session refresh via an UPDATE or re-INVITE - res_pjsip_session_refresh - which will do the job we need. Furthermore, we already have a dialplan function PJSIP_MEDIA_OFFER that allows you to change the formats we’d offer in a session refresh. There really just needs to be a new dialplan function - say PJSIP_SEND_SESSION_REFRESH - that invokes res_pjsip_session_refresh. Then you could do something like this to change the formats on the fly:
same => n,Set(PJSIP_MEDIA_OFFER(audio)=!all,g722)
same => n,Set(PJSIP_SEND_SESSION_REFRESH()=invite)
Note that I’m glossing over some details, as I’m pretty sure you’d have to update the formats on the channel if the refresh succeeded, but it shouldn’t be a lot of code thanks to the APIs the PJSIP stack in Asterisk exposes.
I should note that if you did write this functionality, do use dialplan functions. That allows them to be invoked through Asterisk’s APIs (namely, AMI and ARI) 
Really detailed and well written explanation. So hopes are less on chan_sip …
I was wondering if a method like this could be useful http://forums.asterisk.org/viewtopic.php?p=203015
Thanks
The issue in this case is less about selecting the formats from the dialplan via SIP_CODEC, and more about triggering the re-INVITE or UPDATE back to the UA from Asterisk. The PJSIP stack exposes an API to do this exact task; chan_sip doesn’t really even have an API to speak of.
hmmm… sadly we need it on chan_sip … so I guess there is no way to do it.
Well, if you do decide to go with PJSIP, I put together a patch that should do it here:
Very interesting and useful this new function added to the PJSIP channel driver
Thanks mjordan, I would remember it when using with pjsip…