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

Sab Mar 27 15:08:55 CET 2010

Gracias por la explicación me lo habéis dejado claro claro :D Sobre todo
algun tema de SDP que tenía colgando y ahora entiendo mejor.

Saúl es un escenario controlado, de una empresa con varios sites
interconectados mediante una solución WAN de interlan con conocimiento de
las redes IP te daría mucha flexibilidad.

Al final esta paranoia me viene del mundo de Cisco con el CUCM. Con una
solución CUCM veo fácil implementar un control centralizado de llamadas con
teléfonos en sitios remotos colgando de este site central. Y lo veo fácil
porque tiene temas como los location y regions. Con las locations defines el
ancho de banda máxima que tiene un site en su parte de acceso WAN y con las
regions se definen los codecs que se van a hablar entre telefonos que esten
en la misma region o en diferentes regions. De esta forma tienes un control
del codec utilizado y del máximo de llamadas simultáneas (ancho de banda)
que se pueden hacer sin que se degrade la calidad de la voz.

Eso es lo que le veo complicado de gestionar con kamailio/Asterisk/SIP donde
la logica de elección de los codecs reside en los teléfonos y no en el
"proxy". Y ni siquiera hay un mecanismo de control de acceso y de control
del ancho de banda como en H.323 con los gatekeepers.

Al final no te queda más que utilizar un codec de bajo bitrate siempre e
intentar limitar las llamadas simultáneas como ha dicho Iñaki con el modulo
qos

Saludos y gracias a todos por vuestras respuestas,

El 27 de marzo de 2010 10:44, Jesus Rodriguez <jesusr en voztele.com> escribió:

> Hola,
>
>
> > 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
>
>
> Así es.
>
>
>
> > - 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 no es así. En la negociación "habital" un UAC no sabe la ip y puerto a
> la que enviar el RTP hasta que no recibe un 200OK por lo que no puede hacer
> esa elección de codec que comentas desde el inicio. El UAC podría hacer un
> re-INVITE nada más recibir el 200OK y enviar el ACK para cambiar el codec si
> tiene lógica para saber que la red de destino de su RTP es "local" o
> "externa", por ejemplo.
>
> Otra opción es disponer de un b2bua intermedio de forma que cambie la
> negociación de los SDP: para el UAC se usa el "habitual" INVITE/200OK pero
> para el UAS envía un INVITE sin SDP y negocia el codec en el 200OK/ACK. Así,
> el b2bua sabe la localización y codec propuesto por ambos extremos y
> "forzar" el uso de un codec determinado.
>
>
>
> > 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.
>
>
> Algún softphone para móvil con wifi y 3G usa codecs diferentes en función
> de si la llamada sale por un lado o por otro.
>
> Saludos
> JesusR.
>
>
>
> > 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
> > _______________________________________________
> > 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
>
>
>
>
>
> Saludos
> JesusR.
>
> ------------------------------------
> Jesus Rodriguez
> VozTelecom Sistemas, S.L.
> jesusr en voztele.com
> http://www.voztele.com
> Tel. 902360305
> -------------------------------------
>
>
>
>
>
> _______________________________________________
> 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/0531709d/attachment.htm>