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 &quot;m=&quot; 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&#39;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&#39;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">&lt;<a href="http://tzury.by">tzury.by</a>@<a href="http://reguluslabs.com">reguluslabs.com</a>&gt;</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">&lt;<a href="mailto:anthony.minessale@gmail.com" target="_blank">anthony.minessale@gmail.com</a>&gt;</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&#39;t force codecs in the dynamic range and if properly implemented, it won&#39;t matter what number either side chooses.</p>



<p></p><blockquote type="cite"><div><div></div><div>On Jul 8, 2010 8:34 AM, &quot;Tzury Bar Yochay&quot; &lt;<a href="http://tzury.by" target="_blank">tzury.by</a>@<a href="http://reguluslabs.com" target="_blank">reguluslabs.com</a>&gt; 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>