Re: [Freeswitch-users] codec and vad and cng configuration
----- Original Message ---- From: Mark D. Anderson <mda@discerning.com> To: freeswitch-users@lists.freeswitch.org Sent: Saturday, June 9, 2007 1:18:09 PM Subject: [Freeswitch-users] codec and vad and cng configuration It seems FS will simply go through the rtpmap offers in an incoming INVITE, in the incoming order, and pick the first one that is in the codec-prefs in my sofia.conf.xml (see end of this message for trace). But I was expecting that FS (or sofia underneath) would instead negotiate by checking codecs in my configured list, and pick the first matching one in *my* list, not the first matching one in *their* list. --------------------------------------------------------------------------------------------------------------- That is correct. This was done intentionally. Since you asked *sooo* nicely 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). --------------------------------------------------------------------------------------------------------------- I see there is a "inbound-late-negotiation" param, but I don't know how this would be used -- nor do I think i'd want to use it, if the priority can just be taken from my list. --------------------------------------------------------------------------------------------------------------- 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"/> --------------------------------------------------------------------------------------------------------------- Regarding VAD, I'm wondering why there is an "in" or "both" setting -- isn't VAD chosen by the sender? Also, it seems kind of limiting to have to enable VAD regardless of who is connecting (what UA) and regardless of what codec is in use. And I see no way to control CNG at all? --------------------------------------------------------------------------------------------------------------- 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. 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. 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. --------------------------------------------------------------------------------------------------------------- -mda example trace, showing how it picks PCMU since it is first in their list, when the first match in my list would have been iLBC ---- 2007-06-09 13:03:43 [DEBUG] sofia.c:1028 sofia_handle_sip_i_state() Remote SDP: v=0 o=root 12720 12720 IN IP4 67.55.159.156 s=session c=IN IP4 67.55.159.156 t=0 0 m=audio 12104 RTP/AVP 0 8 3 111 5 10 7 97 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 a=rtpmap:111 G726-32/8000 a=rtpmap:5 DVI4/8000 a=rtpmap:10 L16/8000 a=rtpmap:7 LPC/8000 a=rtpmap:97 iLBC/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - 2007-06-09 13:03:43 [DEBUG] sofia_glue.c:1157 sofia_glue_negotiate_sdp() Audio Codec Compare [PCMU:0:8000]/[speex:98:8000] 2007-06-09 13:03:43 [DEBUG] sofia_glue.c:1157 sofia_glue_negotiate_sdp() Audio Codec Compare [PCMU:0:8000]/[iLBC:97:8000] 2007-06-09 13:03:43 [DEBUG] sofia_glue.c:1157 sofia_glue_negotiate_sdp() Audio Codec Compare [PCMU:0:8000]/[GSM:3:8000] 2007-06-09 13:03:43 [DEBUG] sofia_glue.c:1157 sofia_glue_negotiate_sdp() Audio Codec Compare [PCMU:0:8000]/[PCMA:8:8000] 2007-06-09 13:03:43 [DEBUG] sofia_glue.c:1157 sofia_glue_negotiate_sdp() Audio Codec Compare [PCMU:0:8000]/[PCMU:0:8000] 2007-06-09 13:03:43 [DEBUG] sofia_glue.c:817 sofia_glue_tech_set_codec() Set Codec sofia/profile1/8572337508@67.55.159.156:5060 PCMU/8000 20 ms _______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org ____________________________________________________________________________________ Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. http://farechase.yahoo.com/
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
participants (2)
-
Anthony Minessale
-
Mark D. Anderson