Hacer que el RTP no pase por el Asterisk
Raúl Alexis Betancor Santana
La respuesta fácil sería, canreinvite = yes ... pero Asterisk es un poco
puñeta y si activas la opción t ó T del Dial, pues no vale de nada el
canreinvite = yes
¿Alguien sabe de alguna forma de hacer que el RTP vaya directo entre
terminales SIP y que el Asterisk se encargue solo de la señalización y el
accounting?
En teoría mientras los DTMF no seán in-band, no hace falta que el RTP pase por
el Asterisk.
--
Saludos.
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
Iñaki Baz Castillo
> La respuesta fácil sería, canreinvite = yes ... pero Asterisk es un poco
> puñeta y si activas la opción t ó T del Dial, pues no vale de nada el
> canreinvite = yes
> ¿Alguien sabe de alguna forma de hacer que el RTP vaya directo entre
> terminales SIP y que el Asterisk se encargue solo de la señalización y el
> accounting?
>
> En teoría mientras los DTMF no seán in-band, no hace falta que el RTP pase
> por el Asterisk.
Tú mismo te estás dando la respuesta: no uses t ó T en el "Dial" ni uses
DTMF "in-band". XD
--
Iñaki Baz Castillo
i...@in.ilimit.es
Saúl Ibarra
Raúl Alexis Betancor Santana
> Tú mismo te estás dando la respuesta: no uses t ó T en el "Dial" ni uses
> DTMF "in-band". XD
Buscaba otra opción, si se desactiva el t T o se usa in-band DTMF, se
desperdicia ancho de banda y cpu.
El estandar SIP lo soporta, lo que está claro es que Asterisk no ... me va a
tocar parchear
Raúl Alexis Betancor Santana
> No veo otra manera... tendrás que utilizar las transferencias con los
> teléfonos...
No es viable, quiero que se ejecute el dialplan, lo único que quiero es que
cuando se establezca la conexión entre los extremos SIP, el RTP sea directo.
Iñaki Baz Castillo
> El Thursday 17 May 2007 10:35:14 Iñaki Baz Castillo escribió:
> > Tú mismo te estás dando la respuesta: no uses t ó T en el "Dial" ni uses
> > DTMF "in-band". XD
>
> Buscaba otra opción, si se desactiva el t T o se usa in-band DTMF, se
> desperdicia ancho de banda y cpu.
¿Podrías explicar un poco esto?
Davidcsi
tenga que estar de por medio no sirve el canreinvite.
saludos
On 17 mayo, 11:14, Raúl Alexis Betancor Santana <r...@dimension-
Raúl Alexis Betancor Santana
> > Buscaba otra opción, si se desactiva el t T o se usa in-band DTMF, se
> > desperdicia ancho de banda y cpu.
>
> ¿Podrías explicar un poco esto?
Pues veamos .. si asterisk ha de estar "en medio" de una conversación entre
dos terminales SIP (para simplificar, cuando son más se desperdicia mucho más
ancho de banda), eso supone 4 fujos de RTP por la red, dos de ida y dos de
vuelta hacia/desde los terminales-asterisk, cuando si funcionase SIP2SIP
serían solo 2.
A esto súmale que si el DTMF es in-band, Asterisk tiene que procesar los 4
flujos para "buscar" posibles DTMF's y procesarlos.
Todo esto significa mucho ancho de banda y mucha CPU cuando la cantidad de
terminales empieza a crecer.
Imagina incluso una configuración donde algunos de los terminales sean remotos
(otras sedes), para hablar el usuario 1 con el termina A en la sede1 con el
usuario2 con el terminal B de la sede1, su tráfico ha de llegar y volver a la
central solo para que hablen esos dos terminales que son remotos y que encima
están en la misma red, si el canreinvite funcionase correctamente (de la
forma que yo considero correcta), solo el tráfico de señalización iría entre
los terminales y la central, el RTP iría directo entre los terminales,
ahorrando una barbarida de CARO ancho de banda entre sedes.
Iñaki Baz Castillo
Sí, vale, todo eso es muy cierto pero no te acabo de entender bien. ¿Acaso no
te vale la sencilla solución de no usar T ni t en el "Dial" ni
DTMF "in-band"?
Piensa que usar la transferencia a través de Asterisk (T o t) implica
comunicación RTP de voz con Asterisk para escuchar la palabra "transferir".
De todas formas, en teoría un "canreinvite=yes" n osignifica necesariamente
que el flujo pase por Asterisk, sino que Asterisk podría retomar el flujo RTP
cuando sea necesario (transferencia, etc).
Mira este texto completo:
http://www.voip-info.org/wiki-Asterisk+sip+canreinvite
Pego la parte más relevante a nuestro caso:
"The last thing, which took me a while to figure out, is why the option which
means "I prefer to use a direct RTP media path" is called "canreinvite=yes".
Even if the normal audio path for a call can be set up with native bridging,
Asterisk sometimes needs to be able to re-insert itself into the media path
in the middle of a call - to provide services such as music on hold,
transfer, parking and so on when they are requested.
The SIP mechanism for this is called re-INVITE. Two phones which are happily
talking to each other can have the media stream changed mid-call using this
mechanism, so Asterisk can unstitch the direct link and re-connect the two
legs to itself.
However, not all phones support this mechanism. If you set canreinvite=no on a
SIP channel, it's saying "this phone doesn't support the re-INVITE mechanism
for reconnecting the audio mid-call". Asterisk therefore decides that it must
insert itself into the media stream for the whole duration of the call, so
that it is already there if later on one of the parties requests one of these
in-call features."
De todas formas, me temo que eso es mentira. He hecho estas pruebas:
exten => 50,1,Dial(SIP/prueba)
exten => 51,1,Dial(SIP/prueba)
Todos los teléfonos SIP configurados como "canreinvite=yes". Monitorizo con
tcpdump y veo que:
a) llamando al 50 el audio efectivamente va de teléfono a teléfono sin pasar
por Asterisk.
b) llamando al 51 el audio va a través de Asterisk desde EL PRINCIPIO.
Esto tira para atrás eso de "The SIP mechanism for this is called re-INVITE.
Two phones which are happily talking to each other can have the media stream
changed mid-call using this mechanism, so Asterisk can unstitch the direct
link and re-connect the two legs to itself."
Saludos.
Julian J. M.
marcar 50 que 51. Estás llamando al mismo dispositivo SIP.
Podrías poner aquí la configuración completa? es decir, el dialplan
que interviene en el ejemplo, y las definiciones de cada peer en
sip.conf.
Yo tengo una instalación de asterisk en 1 sede, y otras 3 sedes
remotas (con ATA's de Linksys), y las llamadas de una sede remota a
otra _no_ pasan por la principal.
Para conseguir esto, claro, hay que seguir algunos puntos:
1) No usar parámetros en el comando Dial, como t,T,w,W, o cualquier
otro que requiera que asterisk supervise el dtmf.
2) Tener nat=never en los peers remotos. Como no, canreinvite=yes.
3) Configurar los dispositivos para que tengan conocimiento de la IP
pública (la que tiene el router) y que la usen en lugar de la IP
privada.
4) Abrir en el router los puertos en los que están escuchando los
dispositivos (5060 y los que tengan de RTP).
He de decir también, que cuando monté este tinglado tuve muchos
problemas, pero causados por el router. En todas las sedes instalé
WRT54G's en monopuesto (y utilizando el router ADSL como un simple
modem). El mejor firmware que he probado ha sido el openwrt, sin
interfaz web ni otras florituras... nada como configurar desde 0 y a
mano todos los parámetros. Tengo el procedimiento medio documentado
por si a alguien le interesa.
Por cierto, el firmware dd-wrt no funciona bien en este escenario.
Tiene que ver con el conntrack, pero no di con la causa. :-?
Saludos
Julián J. M.
On 5/17/07, Iñaki Baz Castillo <i...@in.ilimit.es> wrote:
> Mira este texto completo:
> http://www.voip-info.org/wiki-Asterisk+sip+canreinvite
>
Iñaki Baz Castillo
> Hay algo que no me cuadra con el ejemplo que has puesto. Da igual
> marcar 50 que 51. Estás llamando al mismo dispositivo SIP.
Perdón perdón, lo pego bien:
exten => 50,1,Dial(SIP/prueba)
exten => 51,1,Dial(SIP/prueba||tT)
> Podrías poner aquí la configuración completa? es decir, el dialplan
> que interviene en el ejemplo, y las definiciones de cada peer en
> sip.conf.
Creo que con lo de arriba es suficiente. Además los teléfonos implicados
(quien llama y "prueba") tienen canreinvite=yes y están en la misma LAN que
Asterisk sin problemas de firewalls ni nada.
> Yo tengo una instalación de asterisk en 1 sede, y otras 3 sedes
> remotas (con ATA's de Linksys), y las llamadas de una sede remota a
> otra _no_ pasan por la principal.
> Para conseguir esto, claro, hay que seguir algunos puntos:
> 1) No usar parámetros en el comando Dial, como t,T,w,W, o cualquier
> otro que requiera que asterisk supervise el dtmf.
> 2) Tener nat=never en los peers remotos. Como no, canreinvite=yes.
> 3) Configurar los dispositivos para que tengan conocimiento de la IP
> pública (la que tiene el router) y que la usen en lugar de la IP
> privada.
> 4) Abrir en el router los puertos en los que están escuchando los
> dispositivos (5060 y los que tengan de RTP).
Ok, entonces estamos diciendo lo mismo. La duda que me queda es ese texto que
citaba, en el que se decía que una llamada podía iniciarse en modo brigde
entre los teléfonos (el RTP) me refiero y en medio de la llamada Asterisk
recoger el flujo RTP para que pase por él al pulsar el usuario la acción de
transferir y demás. Pero claro, para que pueda transferir debe ser un Dial
con "tT" y en ese caso yo he comprobado que desde el PRINCIPIO el flujo RTP
pasa por Asterisk.
Julian J. M.
a la otra parte (B) en espera (Hold). En ese caso, asterisk hará el
reinvite al teléfono B, para enviarle música en espera. Cuando A quite
desactive el Hold, asterisk hará otro reinvite a ambos teléfonos para
que se envíen el audio directamente.
Lo que no puedes hacer es utilizar la transferencia de llamadas
integrada en asterisk (marcando lo que hayas puesto en features.conf),
y pretender que el tráfico RTP vaya de punto a punto.
Utiliza en este caso la transferencia SIP nativa que incorporan los
teléfonos. Yo es la que utilizo:
1) Hago una llamada
2) La pongo en espera
3) Marco otra extensión, o cualquier número de teléfono que permita
mi dialplan
4) Dependiendo de teléfono, hago la transferencia... es decir,
comunicar la primera llamada con la segunda. El teléfono hace un
ReInvite, si no me equivico, indicándole a asterisk "Comunica estos
dos canales y déjame a mi fuera".
Saludos
Julián J. M.
On 5/17/07, Iñaki Baz Castillo <i...@in.ilimit.es> wrote:
Raúl Alexis Betancor Santana
> Sí, vale, todo eso es muy cierto pero no te acabo de entender bien. ¿Acaso
> no te vale la sencilla solución de no usar T ni t en el "Dial" ni
> DTMF "in-band"?
> Piensa que usar la transferencia a través de Asterisk (T o t) implica
> comunicación RTP de voz con Asterisk para escuchar la palabra "transferir".
FALSO, es un error de implementación de Asterisk, usar T o t NO IMPLICA pasar
el RTP por asterisk A NO SER que el DTMF sea IN-BAND.
En teoría (la práctica demuestra lo contrario), si tienes DTMF como SIP-INFO o
RFC1488 (he puesto el RFC de cabeza), para autorizar las transferencias (T ó
t), Asterisk no tiene porqué interceptar el RTP, puesto que la petición de
Transfer será un paquete de señalización SIP, no un audio codificado in-band.
> De todas formas, en teoría un "canreinvite=yes" n osignifica necesariamente
> que el flujo pase por Asterisk, sino que Asterisk podría retomar el flujo
> RTP cuando sea necesario (transferencia, etc).
>
> Mira este texto completo:
> http://www.voip-info.org/wiki-Asterisk+sip+canreinvite
Yo no he dicho eso, he dicho que AUN poniendo canreinvite=yes, si se usa T o t
ó señalización DTMF in-band, Asterisk captura el tráfico RTP, cuando en
realidad SOLO debería de capturarlo desde el principio si la codificación del
DTMF es in-band
> Pego la parte más relevante a nuestro caso:
>
>
> "The last thing, which took me a while to figure out, is why the option
> which means "I prefer to use a direct RTP media path" is called
> "canreinvite=yes".
[...]
Abrevio, es mentira, con T o t puesto Asterisk SIEMPRE captura el tráfico RTP.
> De todas formas, me temo que eso es mentira. He hecho estas pruebas:
>
> exten => 50,1,Dial(SIP/prueba)
> exten => 51,1,Dial(SIP/prueba)
>
> Todos los teléfonos SIP configurados como "canreinvite=yes". Monitorizo con
> tcpdump y veo que:
>
> a) llamando al 50 el audio efectivamente va de teléfono a teléfono sin
> pasar por Asterisk.
>
> b) llamando al 51 el audio va a través de Asterisk desde EL PRINCIPIO.
>
> Esto tira para atrás eso de "The SIP mechanism for this is called
> re-INVITE. Two phones which are happily talking to each other can have the
> media stream changed mid-call using this mechanism, so Asterisk can
> unstitch the direct link and re-connect the two legs to itself."
Tal como yo te decía, es mentira, no cumple lo que dice la documentación.
Para Asterisk en el código actual .. T o t IMPLICA captura del RTP.
Raúl Alexis Betancor Santana
> Ok, entonces estamos diciendo lo mismo. La duda que me queda es ese texto
> que citaba, en el que se decía que una llamada podía iniciarse en modo
> brigde entre los teléfonos (el RTP) me refiero y en medio de la llamada
> Asterisk recoger el flujo RTP para que pase por él al pulsar el usuario la
> acción de transferir y demás. Pero claro, para que pueda transferir debe
> ser un Dial con "tT" y en ese caso yo he comprobado que desde el PRINCIPIO
> el flujo RTP pasa por Asterisk.
Exacto, eso es lo que me dice a mí la experiencia, esa parte no funciona como
debe en Asterisk.
Raúl Alexis Betancor Santana
> No se refiere a eso. Se refiere a que un teléfono SIP (A) puede poner
> a la otra parte (B) en espera (Hold). En ese caso, asterisk hará el
> reinvite al teléfono B, para enviarle música en espera. Cuando A quite
> desactive el Hold, asterisk hará otro reinvite a ambos teléfonos para
> que se envíen el audio directamente.
Pero el caso es que Asterisk no lo hace, no se comporta así. Si lo hiciera no
estaríamos teniendo esta conversación ;-)
> Lo que no puedes hacer es utilizar la transferencia de llamadas
> integrada en asterisk (marcando lo que hayas puesto en features.conf),
> y pretender que el tráfico RTP vaya de punto a punto.
Se puede si Asterisk respetase el comportamiento de los re-invites, cosa que
no hace.
Resumiendo:
El comportamiento definido por el estandar es:
-A llama a B a través de Asterisk
-Asterisk notifica a B
-B negocia RTP con A
- A y B hablan
- B pulsa hold
- B envia hold a Asterisk
- Asterisk reinvita a A al music on hold
- B hace cualquier cosa (marca la extensión o lo que sea)
- B decide llamar a C
- B negocia RTP con C
- B transfiere la llamada de C a A
- Asterisk recibe la petición de transferencia
- Asterisk comunica a A que negocie RTP con C
- Asterisk para music on hold
- B cuelga
- A y C negocian RTP y hablan
....
Asteris no se comporta así, si tienes activada la opción de tT .. asterisk
SNIFA todo el RTP en todos los sentidos desde el principio, sobrecargandose
de manera inútil.
> Utiliza en este caso la transferencia SIP nativa que incorporan los
> teléfonos. Yo es la que utilizo:
> 1) Hago una llamada
> 2) La pongo en espera
> 3) Marco otra extensión, o cualquier número de teléfono que permita
> mi dialplan
> 4) Dependiendo de teléfono, hago la transferencia... es decir,
> comunicar la primera llamada con la segunda. El teléfono hace un
> ReInvite, si no me equivico, indicándole a asterisk "Comunica estos
> dos canales y déjame a mi fuera".
Pero no podrás usar música en espera, además al no haber tráfico RTP, si por
algún motivo dejas en "espera" más de 30 segundos al interlocutor, la mayoría
de los teléfonos SIP colgarán la llamada por inactividad.
Para que haya música en espera, se ha de indicar tT en las opciones de Dial,
sino Asterisk JAMAS se entera y no inicia la música.
Elio Rojano
Puede que el comportamiento tan extraño que observamos pueda deberse a la versión de Asterisk.
Un saludo,
Iñaki Baz Castillo
> > Lo que no puedes hacer es utilizar la transferencia de llamadas
> > integrada en asterisk (marcando lo que hayas puesto en features.conf),
> > y pretender que el tráfico RTP vaya de punto a punto.
>
> Se puede si Asterisk respetase el comportamiento de los re-invites, cosa
> que no hace.
> Resumiendo:
> El comportamiento definido por el estandar es:
>
> -A llama a B a través de Asterisk
> -Asterisk notifica a B
> -B negocia RTP con A
> - A y B hablan
> - B pulsa hold
> - B envia hold a Asterisk
> - Asterisk reinvita a A al music on hold
> - B hace cualquier cosa (marca la extensión o lo que sea)
> - B decide llamar a C
> - B negocia RTP con C
> - B transfiere la llamada de C a A
> - Asterisk recibe la petición de transferencia
> - Asterisk comunica a A que negocie RTP con C
> - Asterisk para music on hold
> - B cuelga
> - A y C negocian RTP y hablan
Gracias por la explicación, aporto una nueva cosilla abajo.
>
> Asteris no se comporta así, si tienes activada la opción de tT .. asterisk
> SNIFA todo el RTP en todos los sentidos desde el principio, sobrecargandose
> de manera inútil.
>
> > Utiliza en este caso la transferencia SIP nativa que incorporan los
> > teléfonos. Yo es la que utilizo:
> > 1) Hago una llamada
> > 2) La pongo en espera
> > 3) Marco otra extensión, o cualquier número de teléfono que permita
> > mi dialplan
> > 4) Dependiendo de teléfono, hago la transferencia... es decir,
> > comunicar la primera llamada con la segunda. El teléfono hace un
> > ReInvite, si no me equivico, indicándole a asterisk "Comunica estos
> > dos canales y déjame a mi fuera".
>
> Pero no podrás usar música en espera, además al no haber tráfico RTP, si
> por algún motivo dejas en "espera" más de 30 segundos al interlocutor, la
> mayoría de los teléfonos SIP colgarán la llamada por inactividad.
>
> Para que haya música en espera, se ha de indicar tT en las opciones de
> Dial, sino Asterisk JAMAS se entera y no inicia la música.
No no, lo acabo de comprobar en aun Asterisk 1.4.4 y al menos esto SI lo hace
bien Asterisk. Me explico:
- Un softphone Twinkle y un tfno Thomsom 2030, ambos con canreinvite=yes y
DTMFmode = rfc2833, en la misma LAN que Asterisk.
- Llamo de uno a otro con T y/o t y efectivamente el tráfico RTP pasa a través
de Asterisk desde el principio (error en la implementación de Asterisk).
- Llamo de uno a otro sin T ni t y el tráfico RTP es de uno a otro, PERO si
presiono "hold" en uno de los teléfonos el otro comienza a escuchar la música
en espera de Asterisk y de hecho compruebo con tcpdump que ha comenzado a
recibir paquetes UDP/RTP del Asterisk. Así que esto SI lo hace bien,
PD: Una sugerencia a quienes estamos conversando en este hilo: propongo que
cuando tengamos unas conclusiones śólidas lo documentemos en woip-info y
donde fuere, este tema es desde luego un gran tema tabú. ¿Qué os parece?
Saúl Ibarra
esperado, y aquí por lo menos, el ancho de banda es un bien muy
preciado...
El 18/05/07, Iñaki Baz Castillo <i...@in.ilimit.es> escribió:
--
Saúl -- "Some people say why, other just say, why not."
----------------------------------------------------------------
http://www.saghul.net/
Raúl Alexis Betancor Santana
> > Pero no podrás usar música en espera, además al no haber tráfico RTP, si
> > por algún motivo dejas en "espera" más de 30 segundos al interlocutor, la
> > mayoría de los teléfonos SIP colgarán la llamada por inactividad.
> >
> > Para que haya música en espera, se ha de indicar tT en las opciones de
> > Dial, sino Asterisk JAMAS se entera y no inicia la música.
>
> No no, lo acabo de comprobar en aun Asterisk 1.4.4 y al menos esto SI lo
> hace bien Asterisk. Me explico:
Umm, voy a volver comprobarlo con un Asterisk 1.2, yo el 1.4 aún no lo he
usado.
> - Un softphone Twinkle y un tfno Thomsom 2030, ambos con canreinvite=yes y
> DTMFmode = rfc2833, en la misma LAN que Asterisk.
>
> - Llamo de uno a otro con T y/o t y efectivamente el tráfico RTP pasa a
> través de Asterisk desde el principio (error en la implementación de
> Asterisk).
Ese punto lo teníamos claro, por lo menos yo, :-)
> - Llamo de uno a otro sin T ni t y el tráfico RTP es de uno a otro, PERO si
> presiono "hold" en uno de los teléfonos el otro comienza a escuchar la
> música en espera de Asterisk y de hecho compruebo con tcpdump que ha
> comenzado a recibir paquetes UDP/RTP del Asterisk. Así que esto SI lo hace
> bien,
Umm, habrá que probar a combinarlo con NAT para empezar a ver mayores
desastres .. XD
> PD: Una sugerencia a quienes estamos conversando en este hilo: propongo que
> cuando tengamos unas conclusiones śólidas lo documentemos en woip-info y
> donde fuere, este tema es desde luego un gran tema tabú. ¿Qué os parece?
Por mí perfecto.
Iñaki Baz Castillo
> > - Un softphone Twinkle y un tfno Thomsom 2030, ambos con canreinvite=yes
> > y DTMFmode = rfc2833, en la misma LAN que Asterisk.
> >
> > - Llamo de uno a otro con T y/o t y efectivamente el tráfico RTP pasa a
> > través de Asterisk desde el principio (error en la implementación de
> > Asterisk).
>
> Ese punto lo teníamos claro, por lo menos yo, :-)
Pero me pregunto cuánta gente lo tendrá realmente claro dada la caótica
información existente al respecto.
> > - Llamo de uno a otro sin T ni t y el tráfico RTP es de uno a otro, PERO
> > si presiono "hold" en uno de los teléfonos el otro comienza a escuchar la
> > música en espera de Asterisk y de hecho compruebo con tcpdump que ha
> > comenzado a recibir paquetes UDP/RTP del Asterisk. Así que esto SI lo
> > hace bien,
>
> Umm, habrá que probar a combinarlo con NAT para empezar a ver mayores
> desastres .. XD
Eso no se me había ocurrido, anda que no hay escenarios y posibles
conflictos.... ¡ maldito NAT, via IPv6 !
> > PD: Una sugerencia a quienes estamos conversando en este hilo: propongo
> > que cuando tengamos unas conclusiones śólidas lo documentemos en
> > woip-info y donde fuere, este tema es desde luego un gran tema tabú. ¿Qué
> > os parece?
>
> Por mí perfecto.
Vale, yo intentaré hacer alguna prueba más y nos lo vamos contando en este
mismo hilo y cuando tengamos algo concluyente lo subimos a voip-info :)
Saludos.
Davidcsi
¿Qué más da que los RTP pasen por asterisk? si el reenvío de RTPs no
consume casi CPU (siempre y cuando no hagas transcoding, claro) Si
todos los telefonos están en la misma red y todos tienen el mismo
codec, ¿qué ganas con que se envíen directamente los RTPs? yo tengo
varios asterisk pasando RTPs de 20K minutos de llamadas al día y
consume como mucho 2% del CPU...
Saludos.
David
Iñaki Baz Castillo
> Y yo tengo una pregunta:
>
> ¿Qué más da que los RTP pasen por asterisk? si el reenvío de RTPs no
> consume casi CPU (siempre y cuando no hagas transcoding, claro) Si
> todos los telefonos están en la misma red y todos tienen el mismo
> codec, ¿qué ganas con que se envíen directamente los RTPs? yo tengo
> varios asterisk pasando RTPs de 20K minutos de llamadas al día y
> consume como mucho 2% del CPU...
Imagina este caso:
Una empresa con una delegación central y dos satélites remotas y con apenas 4
personas cada una y un ancho de banda medianamente digno y simétrico entre
todas las delegaciones.
Les pones un Asterisk en la principal y en los satélites SOLO teléfonos IP que
se registran en Asterisk. De acuerdo, si se fastidia el Asterisk o la
conexión de internet los satélites no podrían hacer llamadas (pero ese es
otro problema, como si se estropea el RDSI).
Ahora imagina que alguien llama a la empresa, le sale un IVR y finalmente se
le pasa con un teléfono de una delegación satélite donde le atienden, y que
quien atiende dice "sí, un momento le paso", y le transfiere la llamada a un
compañero dentro de esa misma delegación satélite.
Sería algo absurdo que el tráfico de voz tuviese que ir y volver al Asterisk
de la oficina central, sería realmente triste. El SIP por supuesto SI que
tendría que hacerlo, pero apenas son 20 mensajes IP.
Resumiendo, no se puede ver este tema bajo la premisa de que los todos
teléfonos y el Asterisk estén siempre juntitos.
Saúl Ibarra
El 18/05/07, Davidcsi <david.v...@gmail.com> escribió:
tylerd
planteada en este post? A mi entender en este caso asterisk solo
señalizaría y el trafico rtp sería establecido entre los puntos a y b,
sin recargar nuestra capacidad de procesamiento de manera
significativa. Esto se logra si asterisk no tiene que intervenir en la
llamada para algo diferente a señalizacion. Si un terminal a inicia
una llamada con g.729 con destino terminal b que tambien puede usar
este codec propietario, y nuestra maquina asterisk no tiene licencias
para este tipo de codificacion, hay que suprimir cualquier mandato en
el dialplan del tipo T,t,R,r, etc..asi asterisk no tocara la llamada y
el bridging será transparente para el usuario. Por favor, repito,
haganme saber si estoy equivocado..a mi esto me ha funcionado
perfectamente y nunca he tenido sobrecargas en los servidores de
produccion. Pero con todo lo que he leido en este post, me quedan
dudas..
Saludos desde Colombia..
On 18 mayo, 04:29, "Saúl Ibarra" <sag...@gmail.com> wrote:
> Y si tienes internet en medio? El ancho de banda sí que hay que preservarlo...
>
> El 18/05/07, Davidcsi <david.villas...@gmail.com> escribió:
Saúl Ibarra
t o T en el Dial, el trafico pasa por Asterisk, para que el pueda
"escuchar" si tienes que hacer una transferencia, y ponerte el sonido
correspondiente... por ejemplo.
El 22/05/07, tylerd <intelin...@gmail.com> escribió:
tylerd
transcoding porque no tiene las licencias para esos codecs, solo
señaliza y hace un puente trasnparente entre los puntos que se quieren
comunicar sin importar el codec con el que quieran hablar solo si no
toca la llamada(pass-trough). La duda planteada en el post es si el
trafico rtp se puede establecer entre dos puntos directamente sin que
asterisk lo procese. A mi parecer sí lo hace de esa manera, como lo
hace tambien cuando no transcodifica. Ese es mi punto.
On 22 mayo, 15:51, "Saúl Ibarra" <sag...@gmail.com> wrote:
> Cual es tu duda exactamente? El tema es que cuando tienes las opciones
> t o T en el Dial, el trafico pasa por Asterisk, para que el pueda
> "escuchar" si tienes que hacer una transferencia, y ponerte el sonido
> correspondiente... por ejemplo.
>
> El 22/05/07,tylerd<intelinetwo...@gmail.com> escribió:
Saúl Ibarra
pasar por asterisk, en ese caso no podrías cursar la llamada...
El 24/05/07, tylerd <intelin...@gmail.com> escribió:
Saúl Ibarra
;----------------------------------- MEDIA HANDLING
--------------------------------
; By default, Asterisk tries to re-invite the audio to an optimal
path. If there's
; no reason for Asterisk to stay in the media path, the media will be
redirected.
; This does not really work with in the case where Asterisk is outside and have
; clients on the inside of a NAT. In that case, you want to set
canreinvite=nonat
;
;canreinvite=yes ; Asterisk by default tries to redirect the
; RTP media stream (audio) to go directly from
; the caller to the callee. Some devices do not
; support this (especially if one of them is behind a NAT).
; The default setting is YES. If you have all clients
; behind a NAT, or for some other reason wants Asterisk to
; stay in the audio path, you may want to turn this off.
; This setting also affect direct RTP
; at call setup (a new feature in 1.4 - setting up the
; call directly between the endpoints instead of sending
; a re-INVITE).
;directrtpsetup=yes ; Enable the new experimental direct RTP setup.
This sets up
; the call directly with media peer-2-peer without re-invites.
; Will not work for video and cases where the callee sends
; RTP payloads and fmtp headers in the 200 OK that does not match the
; callers INVITE.
;canreinvite=nonat ; An additional option is to allow media path redirection
; (reinvite) but only when the peer where the media is being
; sent is known to not be behind a NAT (as the RTP core can
; determine it based on the apparent IP address the media
; arrives from).
;canreinvite=update ; Yet a third option... use UPDATE for media path
redirection,
; instead of INVITE. This can be combined with 'nonat', as
; 'canreinvite=update,nonat'. It implies 'yes'.
Como se puede observar, ha cambiado la manera de gestionar esto,
habeis probado con 1.4 o con 1.2? Por otro lado, me ha parecido
"interesante" la segunda opción, habrá que probarla...