The server is required to send the client on the payload it requested regardless of what the server chooses.<div><br></div><div><div>RFC 3264:</div><div> Once the answerer has sent the answer, it MUST be prepared to receive</div>
<div> media for any recvonly streams described by that answer. It MUST be</div><div> prepared to send and receive media for any sendrecv streams in the</div><div> answer, and it MAY send media immediately. The answerer MUST be</div>
<div> prepared to receive media for recvonly or sendrecv streams using any</div><div> media formats listed for those streams in the answer, and it MAY send</div><div> media immediately. When sending media, it SHOULD use a packetization</div>
<div> interval equal to the value of the ptime attribute in the offer, if</div><div> any was present. It SHOULD send media using a bandwidth no higher</div><div> than the value of the bandwidth attribute in the offer, if any was</div>
<div> present. The answerer MUST send using a media format in the offer</div><div> that is also listed in the answer, and SHOULD send using the most</div><div> preferred media format in the offer that is also listed in the answer.</div>
<div> <span class="Apple-style-span" style="background-color: rgb(255, 255, 51);">In the case of RTP, it MUST use the payload type numbers</span></div><div><span class="Apple-style-span" style="background-color: rgb(255, 255, 51);"> from the offer, even if they differ from those in the answer.</span></div>
</div><div><br></div><div><br></div><div>What is pretty amusing though is from the same RFC:</div><div><br></div><div><br></div><div><div> In the case of RTP, if a particular codec was referenced with a</div><div> specific payload type number in the offer, that same payload type</div>
<div> number SHOULD be used for that codec in the answer. Even if the same</div><div> payload type number is used, the answer MUST contain rtpmap</div><div> attributes to define the payload type mappings for dynamic payload</div>
<div> types, and SHOULD contain mappings for static payload types. The</div><div> media formats in the "m=" line MUST be listed in order of preference,</div><div> with the first format listed being preferred. In this case,</div>
<div> preferred means that the offerer SHOULD use the format with the</div><div> highest preference from the answer.</div></div><div><br></div><div><br></div><div>So SHOULD means they have no nerve to enforce it because it's ambiguous and we can choose not to do it.</div>
<div>The MUST in the first example is what we follow.</div><div><br></div><div>MAYBE its possible to find a way to prefer the callers pt like we SHOULD, we'll have to think about it.</div><div><br></div><div><br></div>
<div><br></div><div><br></div><div><br><br><div class="gmail_quote">On Thu, Jul 8, 2010 at 9:28 AM, Tzury Bar Yochay <span dir="ltr"><<a href="http://tzury.by">tzury.by</a>@<a href="http://reguluslabs.com">reguluslabs.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div dir="ltr"><div>Brian and Anthony,</div><div>Dears,</div><div><br></div><div>I am afraid it is a bug in teh FS</div>
<div>See, if during SDP the client declare on payload 98 and fs declare on 99.</div>
<div>Then client expect receiving 99 while sending 98. That is fine.</div><div>However, when both clients are the same (as in our case) since FS is not trans-coding</div><div>clients receives 98 in</div><div>given that same sip client cannot work with previous versions of FS</div>
<div>where there Speex was 98 (and 97 in older) </div><div><div></div><div class="h5"><div><br></div><br><div class="gmail_quote">On Thu, Jul 8, 2010 at 5:08 PM, Anthony Minessale <span dir="ltr"><<a href="mailto:anthony.minessale@gmail.com" target="_blank">anthony.minessale@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p>No, you can't force codecs in the dynamic range and if properly implemented, it won't matter what number either side chooses.</p>
<p></p><blockquote type="cite"><div><div></div><div>On Jul 8, 2010 8:34 AM, "Tzury Bar Yochay" <<a href="http://tzury.by" target="_blank">tzury.by</a>@<a href="http://reguluslabs.com" target="_blank">reguluslabs.com</a>> wrote:<br>
<br>Hi,<br>
<br>
I just download the latest, build and brought up all is fine.<br>
However, our clients are connected via IP over GPRS(UMTS) and thus we<br>
are using Speex codec.<br>
<br>
Is there a way I can enforce speex to have 97 or 98 instead of 99?<br>
Currently as it looks in the vars.xml speex is 99.<br>
see dump (taken from default vars.xml)<br>
<br>
thanks<br>
Tzury<br>
RTP Dynamic Payload Numbers currently used in FreeSWITCH and what for.<br>
<br>
96 - AMR<br>
97 - iLBC (30)<br>
98 - iLBC (20)<br>
99 - Speex 8kHz, 16kHz, 32kHz<br>
100 -<br>
<br></div></div><div>
_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</div></blockquote><p></p>
<br>_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br><br clear="all"><br></div></div>-- <br><div class="im">Tzury Bar Yochay<br><br><a href="http://tzury.by" target="_blank">tzury.by</a>@<a href="http://reguluslabs.com" target="_blank">reguluslabs.com</a><br>
</div>+ 972 52 5133399<br><a href="http://twitter.com/tzury" target="_blank">twitter.com/tzury</a><br>
</div>
<br>_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Anthony Minessale II<br><br>FreeSWITCH <a href="http://www.freeswitch.org/">http://www.freeswitch.org/</a><br>ClueCon <a href="http://www.cluecon.com/">http://www.cluecon.com/</a><br>
Twitter: <a href="http://twitter.com/FreeSWITCH_wire">http://twitter.com/FreeSWITCH_wire</a><br><br>AIM: anthm<br><a href="mailto:MSN%3Aanthony_minessale@hotmail.com">MSN:anthony_minessale@hotmail.com</a><br>GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net">irc.freenode.net</a> #freeswitch<br><br>FreeSWITCH Developer Conference<br><a href="mailto:sip%3A888@conference.freeswitch.org">sip:888@conference.freeswitch.org</a><br><a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org">googletalk:conf+888@conference.freeswitch.org</a><br>
pstn:+19193869900<br>
</div>