26 Mar
2010
26 Mar
'10
11:06 a.m.
Hola,
un duda que tengo (desde hace tiempo y que no he aclarado hasta la fecha) es
si es posible configurar un sistema de control de acceso con Kamailio para
limitar el ancho de banda consumido entre sites distribuidos. La idea es un
SIP Proxy centralizado dando servicio a terminales en sites remotos. Esta
funcionalidad de control de acceso es una funcionalidad realizada por los
gatekeepers en H.323 o incluso la solución de CUCM de Cisco tiene
Locations/Regions, ...
La idea es: tengo una WAN y en las llamadas remotas quiero limitar a x
llamadas con un determinado codec para evitar pasar de un determinado ancho
de banda y que la calidad de las conversaciones voip se degraden. Para ello
necesitaríamos:
- Forzar a usar un codec de low bitrate cuando las llamadas son por la WAN
(pero seguir usando un codec de high bitrate en la LAN)
* Hay algún modulo que permita modificar la negociación SDP entre
terminales SIP para forzar el uso de unos codecs cuando se llamen a unas
extensiones locales (misma LAN) o a otras extensiones (salida por la WAN).
* Esta negociación selectiva de codecs se puede hacer con los teléfonos
directamente o es necesario hacerlo en el SIP Proxy?
- Limitar a X llamadas cuando las llamadas salen por la WAN
* Creo que con el mismo módulo dialog se podría hacer un seguimiento de
las conversaciones en activo ¿algun otro modulo?
Saludos,
--
Christian Pinedo Zamalloa (zako)
PGP keyID: 0x828D0C80
Fingerprint: 7BFF 4105 F46B 7977 BD96 348C 1007 4FF8 828D 0C80
26 Mar
26 Mar
12:12 p.m.
Aupa,
2010/3/26 Christian Pinedo Zamalloa <chr.pinedo(a)gmail.com>om>:
Hola,
un duda que tengo (desde hace tiempo y que no he aclarado hasta la fecha) es
si es posible configurar un sistema de control de acceso con Kamailio para
limitar el ancho de banda consumido entre sites distribuidos. La idea es un
SIP Proxy centralizado dando servicio a terminales en sites remotos. Esta
funcionalidad de control de acceso es una funcionalidad realizada por los
gatekeepers en H.323 o incluso la solución de CUCM de Cisco tiene
Locations/Regions, ...
La idea es: tengo una WAN y en las llamadas remotas quiero limitar a x
llamadas con un determinado codec para evitar pasar de un determinado ancho
de banda y que la calidad de las conversaciones voip se degraden. Para ello
necesitaríamos:
- Forzar a usar un codec de low bitrate cuando las llamadas son por la WAN
(pero seguir usando un codec de high bitrate en la LAN)
* Hay algún modulo que permita modificar la negociación SDP entre
terminales SIP para forzar el uso de unos codecs cuando se llamen a unas
extensiones locales (misma LAN) o a otras extensiones (salida por la WAN).
* Esta negociación selectiva de codecs se puede hacer con los teléfonos
directamente o es necesario hacerlo en el SIP Proxy?
Hacer esto es un poco 'sucio' en el proxy, pero poderse se puede
intentar. Tienes funciones de manipulación de codecs en el módulo
textops (creo que Kamailio tb tiene, sino el port de OpenSIPS no tiene
que ser complicado AFAIK).
La idea sería que siempre ofrezcas ambos codecs y si en el proxy eres
capaz de saber que ambos users son de la misma LAN, haces la ñapa en
el SDP y a correr.
Eso sí, si solo ofreces un codec y vas y lo quitas igual explota algo... :)
- Limitar a X llamadas cuando las llamadas salen por
la WAN
* Creo que con el mismo módulo dialog se podría hacer un seguimiento de
las conversaciones en activo ¿algun otro modulo?
Creo que hay algo en el kamailio nuevo, pero con el dialog lo puedes
hacer, aunque tiene limitaciones en escenarios con parallel forking.
Saludos,
--
/Saúl
http://saghul.net | http://sipdoc.net
12:16 p.m.
El día 26 de marzo de 2010 12:12, Saúl Ibarra <saghul(a)gmail.com> escribió:
Módulo qos de Kamailio.
Aunque coincido con Saghul plenamente: hacer esto en un proxy es
"sucio" y acabarás teniendo problemas.
Usa "profles with value" del módulo dialog, siendo el "value" el id
de
cliente asociado.
No es 100% fiable, ojo, pero más o menos sirve. Lo uso en producción y
sin problema.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
- Forzar a
usar un codec de low bitrate cuando las llamadas son por la WAN
(pero seguir usando un codec de high bitrate en la LAN)
* Hay algún modulo que permita modificar la negociación SDP entre
terminales SIP para forzar el uso de unos codecs cuando se llamen a unas
extensiones locales (misma LAN) o a otras extensiones (salida por la WAN).
* Esta negociación selectiva de codecs se puede hacer con los teléfonos
directamente o es necesario hacerlo en el SIP Proxy?
Hacer esto es un poco 'sucio' en el proxy, pero poderse se puede
intentar. Tienes funciones de manipulación de codecs en el módulo
textops (creo que Kamailio tb tiene, sino el port de OpenSIPS no tiene
que ser complicado AFAIK). La idea sería que siempre ofrezcas ambos codecs y si
en el proxy eres
capaz de saber que ambos users son de la misma LAN, haces la ñapa en
el SDP y a correr.
Si sólo es eso croe que el módulo qos te podría valer (aunque
reconozco que nunca lo he usado).
- Limitar a X
llamadas cuando las llamadas salen por la WAN
* Creo que con el mismo módulo dialog se podría hacer un seguimiento de
las conversaciones en activo ¿algun otro modulo?
Creo que hay algo en el kamailio nuevo, pero con el dialog lo puedes
hacer, aunque tiene limitaciones en escenarios con parallel forking.
12:47 p.m.
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.
El 26 de marzo de 2010 12:16, Iñaki Baz Castillo <ibc(a)aliax.net> escribió:
El día 26 de marzo de 2010 12:12, Saúl Ibarra
<saghul(a)gmail.com> escribió:
Módulo qos de Kamailio.
Aunque coincido con Saghul plenamente: hacer esto en un proxy es
"sucio" y acabarás teniendo problemas.
Usa "profles with value" del módulo dialog, siendo el "value" el id
de
cliente asociado.
No es 100% fiable, ojo, pero más o menos sirve. Lo uso en producción y
sin problema.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
_______________________________________________
SR-Users-ES mailing list
SR-Users-ES(a)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
> - Forzar a usar un codec de low bitrate
cuando las llamadas son por la
WAN
> (pero seguir usando un codec de high bitrate
en la LAN)
> * Hay algún modulo que permita modificar la negociación SDP entre
> terminales SIP para forzar el uso de unos codecs cuando se llamen a unas
> extensiones locales (misma LAN) o a otras extensiones (salida por la
WAN).
> * Esta negociación selectiva de codecs se
puede hacer con los
teléfonos
directamente o es necesario hacerlo en el SIP Proxy?
Hacer esto es un poco 'sucio' en el proxy, pero poderse se puede
intentar. Tienes funciones de manipulación de codecs en el módulo
textops (creo que Kamailio tb tiene, sino el port de OpenSIPS no tiene
que ser complicado AFAIK). La idea sería que siempre ofrezcas ambos codecs y
si en el proxy eres
capaz de saber que ambos users son de la misma LAN, haces la ñapa en
el SDP y a correr.
Si sólo es eso croe que el módulo qos te podría valer (aunque
reconozco que nunca lo he usado).
> - Limitar a X llamadas cuando las llamadas
salen por la WAN
> * Creo que con el mismo módulo dialog se podría hacer un seguimiento
de
las
conversaciones en activo ¿algun otro modulo?
Creo que hay algo en el kamailio nuevo, pero con el dialog lo puedes
hacer, aunque tiene limitaciones en escenarios con parallel forking.
1:01 p.m.
El día 26 de marzo de 2010 12:47, Christian Pinedo Zamalloa
<chr.pinedo(a)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(a)aliax.net>
27 Mar
27 Mar
9:49 a.m.
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(a)aliax.net> escribió:
El día 26 de marzo de 2010 12:47, Christian Pinedo
Zamalloa
<chr.pinedo(a)gmail.com> escribió:
--
Christian Pinedo Zamalloa (zako)
PGP keyID: 0x828D0C80
Fingerprint: 7BFF 4105 F46B 7977 BD96 348C 1007 4FF8 828D 0C80
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(a)aliax.net>
_______________________________________________
SR-Users-ES mailing list
SR-Users-ES(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users-es
10:39 a.m.
Aupa Christian,
2010/3/27 Christian Pinedo Zamalloa <chr.pinedo(a)gmail.com>om>:
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 tema es que tu el INVITE lo mandas a christian(a)empresa.com, y no
sabes cómo va a ser el SDP que venga de vuelta. Puede que el usuario
se encuentre en el exterior con un softphone en un portátil, pero
luego esté en la oficina, y por lo tanto su SDP sí que pueda contener
una IP del rango de la LAN.
Por otro lado, también habría que tener en cuenta el tratamiento de
NAT, porque si al lanzar el INVITE el proxy ve que estás detrás de NAT
no habitual es 'manglear' (?cómo de dice esto en castellano?) el SDP,
po lo que tampoco tendría una IP privada al llegar al terminal
destino.
Supongo que todo esto no aplica a tu escenario, ya que tu tienes el
control y sabes qué te va a llegar y desde que IPs, pero lo que
comentas no lo veo como algo que se pudiera aplicar 'in the wild', por
las razones que he comentado.
Saludos,
--
/Saúl
http://saghul.net | http://sipdoc.net
10:44 a.m.
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(a)aliax.net> escribió:
El día 26 de marzo de 2010 12:47, Christian Pinedo Zamalloa
<chr.pinedo(a)gmail.com> escribió:
Saludos
JesusR.
------------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr(a)voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------
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(a)aliax.net>
_______________________________________________
SR-Users-ES mailing list
SR-Users-ES(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users-es
3:08 p.m.
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(a)voztele.com> escribió:
Hola,
Saludos
JesusR.
------------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr(a)voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------
_______________________________________________
SR-Users-ES mailing list
SR-Users-ES(a)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
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(a)aliax.net>
escribió:
El día 26 de marzo de 2010 12:47, Christian
Pinedo Zamalloa
<chr.pinedo(a)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(a)aliax.net>
_______________________________________________
SR-Users-ES mailing list
SR-Users-ES(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users-es
3:14 p.m.
El día 27 de marzo de 2010 15:08, Christian Pinedo Zamalloa
<chr.pinedo(a)gmail.com> escribió:
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".
Eso es lo que más "mola" de SIP :)
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
Sólo por si acaso: lo de limitar las llamadas concerrentes por
usuario, IP origen o lo que sea, se hace (se puede hacer) con el
módulo "dialog". :)
Saludos.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
3:17 p.m.
El 27 de marzo de 2010 15:14, Iñaki Baz Castillo <ibc(a)aliax.net> escribió:
El día 27 de marzo de 2010 15:08, Christian Pinedo
Zamalloa
<chr.pinedo(a)gmail.com> escribió:l final no te queda más que utilizar un
codec de bajo bitrate siempre e
Gracias, otra corrección para el carro :D Saludos!
--
Christian Pinedo Zamalloa (zako)
PGP keyID: 0x828D0C80
Fingerprint: 7BFF 4105 F46B 7977 BD96 348C 1007 4FF8 828D 0C80
intentar limitar las llamadas simultáneas como ha
dicho Iñaki con el
modulo
qos
Sólo por si acaso: lo de limitar las llamadas concerrentes por
usuario, IP origen o lo que sea, se hace (se puede hacer) con el
módulo "dialog". :)
5143
days inactive
5144
days old
sr-users-es@lists.kamailio.org
10 comments
4 participants
participants (4)
-
Christian Pinedo Zamalloa -
Iñaki Baz Castillo -
Jesus Rodriguez -
Saúl Ibarra