I added a new param to the sofia profile:
<param name="inbound-codec-negotiation" value="greedy"/>
This will do what you *expected*, (sorry for not meeting *all* your needs).
Thanks, that is cool. Oh and by the way thanks again for mod_shout; it worked perfectly the first time for me.
I see there is a "inbound-late-negotiation" param, but I don't ...
This option prevents the codec negotiation from happening until the media is required. You can let calls hit the dialplan and examine the SDP with regular expressions and set an absolute codec string. The point here is to make it possible to control the codec behaviour from the code. Using this technique you can now set the greedy behaviour as a channel variable in the dialplan.
Since you delayed negotation you had the oppurtunity to set the variable before the codec negotiation took place.
<action application="set" data="sip_codec_negotiation=greedy"> <action application="answer"/>
Correct me if I'm wrong, but with inbound-late-negotiation set to true, it would also be possible via dialplan xml logic or more extended script logic, to consider the phase of the moon and then do <action application="set" data="codec-prefs=GSM"/> or // or maybe not? channel vars aren't profile vars.. session.setVariable("codec-prefs", "GSM") where i pick just the one codec i want to use?
We *always* advertise CNG and we *always* set the CNG mode in the RTP if someone we talk to supports it. If they don't support it we turn it off.
oh, ok. I was under the (apparently incorrect) impression that CNG was coupled somehow to VAD, at least for some codecs.
When this takes place you will see a message in the DEBUG log about setting the CNG payload type. This means the RTP stack will send CNG frames whenever it notices an interval take place where no audio was sent. The VAD param is the way it is because we have not worked it into the SDP negotiation yet. The in out or both is if you want to use this nonstandard VAD on the inbound media stream, the outbound streams or both.
My question about inbound VAD reflects what must be a basic ignorance on my part about SIP -- I don't understand what it would mean to turn it on or off -- the sender will just do whatever it wants regardless, and the receiver has to cope, right? speaking of silence, is there any way in FS to make a channel be declared as send-only (for example for an application that is just playing a file and not doing anything with incoming voice). [This is my own ignorance of SIP -- if it is one-way sending, can incoming rfc2833 dtmf tones still be sent in, to control the sending?]
A small TIP. Going forward please take the time to read your email before you send it to make sure your wording or tone does not HIGHLY OFFEND the developers you are asking for help. YOU are asking ME to add functionality YOU want to MY software.
I am perfectly happy without this behaviour and I am adding it for YOU. I'll give you the benefit of the doubt if you did not realize the demanding tone of your email but please pay more attention to your manners in the future.
will do; sorry about any implication of a demand. i only wanted to express confusion :) i'm learning about SIP as i go along. -mda