[SR-Users-ES] control de acceso con Kamailio

Christian Pinedo Zamalloa chr.pinedo en gmail.com
Sab Mar 27 09:49:49 CET 2010


Iñaki igual se me escapa el procedimiento de negociación de codecs por SDP
pero mi idea era esta:
- en SDP cada terminal detalla la IP, puerto y codecs que soporta para la
sesión RTP de audio
- 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)

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.

El 26 de marzo de 2010 13:01, Iñaki Baz Castillo <ibc en aliax.net> escribió:

> El día 26 de marzo de 2010 12:47, Christian Pinedo Zamalloa
> <chr.pinedo en gmail.com> escribió:
> > Volviendo al tema de la selección del codec... ¿los teléfonos SIP no
> tienen
> > mecanismos para la selección selectiva de codecs no?
> >
> > Vamos yo por lo menos no conozco ningún teléfono/protocolo/mecanismo que
> > soportase preferencias de codecs en función de redes IP. Por ejemplo,
> redes
> > IP local y x redes (192.168.0.0/16) preferencia de codecs de high
> quality
> > pero resto de redes (0.0.0.0/0) preferencia de codecs de low bitrate.
> Aunque
> > por SDP el telefono anunciase todos los codecs utilizaría las
> preferencias
> > de codecs anteriores.
> >
> > Al final es buscar algo más potente que el puñetero codec preferido para
> > cualquier comunicación independiente de la red LAN/WAN.
>
> Piensa que cuando un tfno SIP envía un INVITE nunca va a saber la red
> de la IP de media que va a recibir en la respuesta a ese INVITE
> (bueno, realmente deberíamos hablar de SDP offer y SDP response).
>
> Lo que sí podrían hacer los UA's es renegociar los codecs con
> re-INVITE una vez establecida la llamada y adecuarlos a la red de
> media seleccionada por ambas partes.
> El método UPDATE posibilita hacer esto mismo durante la fase de
> early-dialog previa al establecimiento, pero ni dios lo implementa y
> sólo lo he visto en exóticos y aburridísimos flows de IMS, en los que
> cuantas maś flechas tenga tu diagrama más molas y más experto eres
> (además de ganar una chapa con imán para la nevera que dice "3GPP
> Professional SMS-Charging World-Dominator Internet-Killer").
>
>
> --
> Iñaki Baz Castillo
> <ibc en aliax.net>
>
> _______________________________________________
> SR-Users-ES mailing list
> SR-Users-ES en lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users-es
>



-- 
Christian Pinedo Zamalloa (zako)
PGP keyID: 0x828D0C80
Fingerprint: 7BFF 4105 F46B 7977 BD96  348C 1007 4FF8 828D 0C80
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://lists.sip-router.org/pipermail/sr-users-es/attachments/20100327/ebe833ee/attachment-0001.htm>


Más información sobre la lista de distribución SR-Users-ES