Iñaki igual se me escapa el procedimiento de negociación de codecs por SDP pero mi idea era esta:<br>- en SDP cada terminal detalla la IP, puerto y codecs que soporta para la sesión RTP de audio<br>- un teléfono ya sabe a que IP/puerto debe enviar el flujo RTP por lo que un telefono un poco más espabilado podría seleccionar de la lista de codecs los mas adecuados (bajo bitrate o alto bitrate) en función de unas configuraciones por IPs de los usuarios en cada telefono (por ejemplo en mi LAN alto bitrate resto bajo bitrate)<br>
<br>Esto siempre daría más juego que la clásica lista de codecs ordenada de mayor preferencia a menor preferencia en el teléfono independientemente del tipo de llamada.<br><br><div class="gmail_quote">El 26 de marzo de 2010 13:01, Iñaki Baz Castillo <span dir="ltr">&lt;<a href="mailto:ibc@aliax.net">ibc@aliax.net</a>&gt;</span> escribió:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">El día 26 de marzo de 2010 12:47, Christian Pinedo Zamalloa<br>
&lt;<a href="mailto:chr.pinedo@gmail.com">chr.pinedo@gmail.com</a>&gt; escribió:<br>
<div class="im">&gt; Volviendo al tema de la selección del codec... ¿los teléfonos SIP no tienen<br>
&gt; mecanismos para la selección selectiva de codecs no?<br>
&gt;<br>
&gt; Vamos yo por lo menos no conozco ningún teléfono/protocolo/mecanismo que<br>
&gt; soportase preferencias de codecs en función de redes IP. Por ejemplo, redes<br>
&gt; IP local y x redes (<a href="http://192.168.0.0/16" target="_blank">192.168.0.0/16</a>) preferencia de codecs de high quality<br>
&gt; pero resto de redes (<a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>) preferencia de codecs de low bitrate. Aunque<br>
&gt; por SDP el telefono anunciase todos los codecs utilizaría las preferencias<br>
&gt; de codecs anteriores.<br>
&gt;<br>
&gt; Al final es buscar algo más potente que el puñetero codec preferido para<br>
&gt; cualquier comunicación independiente de la red LAN/WAN.<br>
<br>
</div>Piensa que cuando un tfno SIP envía un INVITE nunca va a saber la red<br>
de la IP de media que va a recibir en la respuesta a ese INVITE<br>
(bueno, realmente deberíamos hablar de SDP offer y SDP response).<br>
<br>
Lo que sí podrían hacer los UA&#39;s es renegociar los codecs con<br>
re-INVITE una vez establecida la llamada y adecuarlos a la red de<br>
media seleccionada por ambas partes.<br>
El método UPDATE posibilita hacer esto mismo durante la fase de<br>
early-dialog previa al establecimiento, pero ni dios lo implementa y<br>
sólo lo he visto en exóticos y aburridísimos flows de IMS, en los que<br>
cuantas maś flechas tenga tu diagrama más molas y más experto eres<br>
(además de ganar una chapa con imán para la nevera que dice &quot;3GPP<br>
Professional SMS-Charging World-Dominator Internet-Killer&quot;).<br>
<font color="#888888"><br>
<br>
--<br>
</font><div><div></div><div class="h5">Iñaki Baz Castillo<br>
&lt;<a href="mailto:ibc@aliax.net">ibc@aliax.net</a>&gt;<br>
<br>
_______________________________________________<br>
SR-Users-ES mailing list<br>
<a href="mailto:SR-Users-ES@lists.sip-router.org">SR-Users-ES@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users-es" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users-es</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Christian Pinedo Zamalloa (zako)<br>PGP keyID: 0x828D0C80<br>Fingerprint: 7BFF 4105 F46B 7977 BD96  348C 1007 4FF8 828D 0C80<br>