Receta "magica" para la correcta deteccion de los DTMF
fcoibague
Tengo tres troncales....
una linea analogica, una que genera una planta gsm, y otra voip..
con la linea analogica no tengo ningun problema en la deteccion de los
dtmf...
pero con las otras dos.. he probado de todo...
relaxdtmf... dtmfmode en todos sus sabores...
y aun persiste el problema...
se repiten los digitos.!!!!!
El caso que mas me interesa solucionar es este:
genero una llamada via actionvoip o otro proveedor voip a un celular
se contesta dicha llamada y se solicita que ingrese el numero de
destino,
se ingresa un numero de destino y se conecta con el destino..
Claroo que mas de la mitad de las veces el numero de destino es mal
detectado... casi siempre se repiten los digitos...
Alguien conoce alguna receta "magica" para solucionar este
problema ???
Raúl Alexis Betancor Santana
> Cordial saludo,
>
> Tengo tres troncales....
>
> una linea analogica, una que genera una planta gsm, y otra voip..
> con la linea analogica no tengo ningun problema en la deteccion de los
> dtmf...
>
> pero con las otras dos.. he probado de todo...
> relaxdtmf... dtmfmode en todos sus sabores...
> y aun persiste el problema...
> se repiten los digitos.!!!!!
>
> El caso que mas me interesa solucionar es este:
> genero una llamada via actionvoip o otro proveedor voip a un celular
> se contesta dicha llamada y se solicita que ingrese el numero de
> destino,
> se ingresa un numero de destino y se conecta con el destino..
Osea ...
Usuario -> Asterisk -> Internet -> Proveedor Voip -> GSM -> IVR -> A saber pa'
donde ...
La de dios! .. la latencia que tiene que tener eso!!!
> Claroo que mas de la mitad de las veces el numero de destino es mal
> detectado... casi siempre se repiten los digitos...
>
> Alguien conoce alguna receta "magica" para solucionar este
> problema ???
Para el enlace GSM ... pues que sigas probando hasta que encuentre la
combinación adecuada.
Para el enlace IP, que le pidas al proveedor cual es la configuración correcta
del modo DTMF.
Para los enlaces SIP, lo mejor es usar el modo SIP-INFO para los DTMF, hay que
huir de usar inband ... y el modo RFC no es muy fiable según con que
proveedores trabajes.
--
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
fcovoip
On 20 ago, 10:10, Raúl Alexis Betancor Santana <r...@dimension-
> On Jueves, 20 de Agosto de 2009 14:47:37 fcoibague escribió:
>
>
>
> > Cordial saludo,
>
> > Tengo tres troncales....
>
> > una linea analogica, una que genera una planta gsm, y otra voip..
> > con la linea analogica no tengo ningun problema en la deteccion de los
> > dtmf...
>
> > pero con las otras dos.. he probado de todo...
> > relaxdtmf... dtmfmode en todos sus sabores...
> > y aun persiste el problema...
> > se repiten los digitos.!!!!!
>
> > El caso que mas me interesa solucionar es este:
> > genero una llamada via actionvoip o otro proveedor voip a un celular
> > se contesta dicha llamada y se solicita que ingrese el numero de
> > destino,
> > se ingresa un numero de destino y se conecta con el destino..
>
> Osea ...
>
> Usuario -> Asterisk -> Internet -> Proveedor Voip -> GSM -> IVR -> A saber pa'
> donde ...
>
Usuario -> GSM -> Asterisk (se repiten los digitos)
o
Usuario -> LINEA ANALOGA -> Asterisk (asi funciona perfecto)
o
Asterisk -> VoIP Provider -> Usuario (se repiten los digitos)
> La de dios! .. la latencia que tiene que tener eso!!!
>
> > Claroo que mas de la mitad de las veces el numero de destino es mal
> > detectado... casi siempre se repiten los digitos...
>
> > Alguien conoce alguna receta "magica" para solucionar este
> > problema ???
>
> Para el enlace GSM ... pues que sigas probando hasta que encuentre la
> combinación adecuada.
halla funcionado bien...?????
>
> Para el enlace IP, que le pidas al proveedor cual es la configuración correcta
> del modo DTMF.
halla funcionado bien...?????
> Para los enlaces SIP, lo mejor es usar el modo SIP-INFO para los DTMF, hay que
> huir de usar inband ... y el modo RFC no es muy fiable según con que
> proveedores trabajes.
>
Iñaki Baz
> Para los enlaces SIP, lo mejor es usar el modo SIP-INFO para los DTMF, hay que
> huir de usar inband ... y el modo RFC no es muy fiable según con que
> proveedores trabajes.
Sólo un comentario al respecto:
El uso de SIP INFO para envío de DTMF *no* está estandarizado en absoluto (ningún RFC define el SIP INFO para DTMF). En realidad su uso proviene de su empleo por algunos cacharros Cisco y otras marcas, cada cuál poniendo su propio "Content-Type" no estandarizado.
Pero eso no es lo peor. Aún en el caso de que se estandarizase su uso, no hay forma de que dos UA's negocien que van a usar SIP INFO para DTMF (en cambio sí existe esta negociación a nivel SDP para el DTMF en RTP usando la especificación RFC 2833). Un caso fácil que describe esta problemática:
- UA1 establece un diálogo con UA2.
- UA1 envía "1" vía DTMF modo RFC 2833 (RTP).
- Casi al instante envía "1" vía DTMF SIP INFO.
- ¿Qué debe interpretar UA2? ¿que ha enviado "11" o "1" de dos formas?
De hecho algunos tfnos envían SIP INFO y RFC2833 *a la vez* creando esta problemática que, como decía antes, no está definida en ningún sitio.
Saludos.
Ronald Urbano
>
>
>
> On 20 ago, 10:10, Raúl Alexis Betancor Santana <r...@dimension-
> virtual.com> wrote:
>> On Jueves, 20 de Agosto de 2009 14:47:37 fcoibague escribió:
>>
> No sr. la cuestion es de la siguiente manera:
>
>
>
> Usuario -> GSM -> Asterisk (se repiten los digitos)
>
Puedes probar regulando el volumen de tu gateway GSM, probando hasta
que ya no ocurra tu problema( yo lo tengo hasta ahora, pero regulando
el volumen del Hypermedia que tengo, ya he podido reducir bastante
éste efecto indeseado) finalmente es jugar con tu gateway gsm...
>
> Asterisk -> VoIP Provider -> Usuario (se repiten los digitos)
>
>> Para los enlaces SIP, lo mejor es usar el modo SIP-INFO para los DTMF, hay que
>> huir de usar inband ... y el modo RFC no es muy fiable según con que
>> proveedores trabajes.
>
Con inband a mi me funciona en muchos proveedores sip, pero cuando
enlazo 2 asterisk sip mios siempre con rfc... asi que todo es
coordinación con tu proveedor.
Saludos
Ronald -
Raúl Alexis Betancor Santana
> > La de dios! .. la latencia que tiene que tener eso!!!
>
> Es mas bien poca o ninguna...
Me refería al caso que yo describí no al escenario tal cual lo has descrito
ahora.
> > Para el enlace GSM ... pues que sigas probando hasta que encuentre la
> > combinación adecuada.
>
> Le he probado de todoo.... alguien tiene alguna configuracion que le
> halla funcionado bien...?????
De todo no has probado, porque sino ya hubieras dado con la combinación que te
funcionase.
Como ya te dije no hay "recetas mágicas", en los temas de líneas analógicas (y
este caso lo es, porque da igual que lo que tengas al otro lado sea una línea
analógica o un gateway GSM o un teléfono o lo que te de la gana, al final lo
tienes conectado a una TDM que es lo que te importa), si para el puerto donde
tienes conectada la linea PSTN te funciona pero para el puerto donde tienes
la línea GSM no, está claro que te tocará jugar con las ganancias del puerto
gsm o la duración de los tonos DTMF (aunque eso es estandar).
> > Para el enlace IP, que le pidas al proveedor cual es la configuración
> > correcta del modo DTMF.
>
> Le he probado de todoo.... alguien tiene alguna configuracion que le
> halla funcionado bien...?????
Volvemos a lo mismo, sino te funciona es que lo tienes mal configurado tú o tu
proveedor, osea que no os habéis puesto de acuerdo en que método usar par los
DTMF.
> > Para los enlaces SIP, lo mejor es usar el modo SIP-INFO para los DTMF,
> > hay que huir de usar inband ... y el modo RFC no es muy fiable según con
> > que proveedores trabajes.
>
> ya lo utilice y sucede igual... se repiten los digitos..
¿Has realizado las pertinentes capturas SIP y RTP para ver porqué el proveedor
te ha enviado dos veces el DTMF?
Raúl Alexis Betancor Santana
> > Para los enlaces SIP, lo mejor es usar el modo SIP-INFO para los DTMF,
> > hay que huir de usar inband ... y el modo RFC no es muy fiable según con
> > que proveedores trabajes.
>
> Sólo un comentario al respecto:
>
> El uso de SIP INFO para envío de DTMF *no* está estandarizado en absoluto
> (ningún RFC define el SIP INFO para DTMF). En realidad su uso proviene de
> su empleo por algunos cacharros Cisco y otras marcas, cada cuál poniendo su
> propio "Content-Type" no estandarizado.
Yo no dije que estuviera estandarizado .. dije que era la forma más
recomendable ... ;-)
> Pero eso no es lo peor. Aún en el caso de que se estandarizase su uso, no
> hay forma de que dos UA's negocien que van a usar SIP INFO para DTMF
Si la hay ... yo proveedor le pongo en las instrucciones de configuración de
la cuenta al cliente un bonito y grandote aviso de que el DTMF solo funciona
en modo SIP-INFO, ale ! .. ya tienes negociación ;-)
> (en
> cambio sí existe esta negociación a nivel SDP para el DTMF en RTP usando la
> especificación RFC 2833).
Umm ... que yo sepa esa negociación no existe, lo que existe es un anuncio a
nivel SDP del playload RTP que se usará para los DTMF, y no es la primera vez
que veo que un cacharro sip usa como playload DTMF un valor distinto de 101
(el habitual para los DTMF RTP) y el otro lado ni se entera luego.
> Un caso fácil que describe esta problemática: -
> UA1 establece un diálogo con UA2.
> - UA1 envía "1" vía DTMF modo RFC 2833 (RTP).
> - Casi al instante envía "1" vía DTMF SIP INFO.
> - ¿Qué debe interpretar UA2? ¿que ha enviado "11" o "1" de dos formas?
>
> De hecho algunos tfnos envían SIP INFO y RFC2833 *a la vez* creando esta
> problemática que, como decía antes, no está definida en ningún sitio.
Si un UAC envía SIP-INFO + RFC2833 yo lo consideraría TOTALLY BROKEN, ¿en que
cabeza cabe que uses dos formas de notificar lo mismo? (ya, ya ... en la de
los ingenieros del IETF ... XD, pero esos no cuentan).
Hasta ahora, todos los UAC/UAS con los que he trabajado, al a hora de definir
el modo DTMF, cuando lo fuerzas a SIP-INFO ... así se queda.
Incluso en los nuevos HT503 de Grandstream, permite configurar
una "preferencia" para los DTMF, si los pones en 1 SIP-INFO, 2 RFC2833, 3
INBAND ... lo que hace es mandar primero el DTMF como SIP-INFO, sino recibe
el 200, lo manda como RTP y a último remedio como INBAND, pero no lo envía de
dos formas distintas al mismo tiempo
Iñaki Baz Castillo
> > Pero eso no es lo peor. Aún en el caso de que se estandarizase su uso, no
> > hay forma de que dos UA's negocien que van a usar SIP INFO para DTMF
>
> Si la hay ... yo proveedor le pongo en las instrucciones de configuración de
> la cuenta al cliente un bonito y grandote aviso de que el DTMF solo funciona
> en modo SIP-INFO, ale ! .. ya tienes negociación ;-)
permita *recibir* un tipo concreto de DTMF usando SIP... ;)
> > (en
> > cambio sí existe esta negociación a nivel SDP para el DTMF en RTP usando la
> > especificación RFC 2833).
>
> Umm ... que yo sepa esa negociación no existe, lo que existe es un anuncio a
> nivel SDP del playload RTP que se usará para los DTMF, y no es la primera vez
> que veo que un cacharro sip usa como playload DTMF un valor distinto de 101
> (el habitual para los DTMF RTP) y el otro lado ni se entera luego.
algunos tonos DTMF usando el RTP con payload tal y tal". En cambio con
SIP INFO no hay nada, ni anuncio ni ná.
> > Un caso fácil que describe esta problemática: -
> > UA1 establece un diálogo con UA2.
> > - UA1 envía "1" vía DTMF modo RFC 2833 (RTP).
> > - Casi al instante envía "1" vía DTMF SIP INFO.
> > - ¿Qué debe interpretar UA2? ¿que ha enviado "11" o "1" de dos formas?
>
> > De hecho algunos tfnos envían SIP INFO y RFC2833 *a la vez* creando esta
> > problemática que, como decía antes, no está definida en ningún sitio.
>
> Si un UAC envía SIP-INFO + RFC2833 yo lo consideraría TOTALLY BROKEN, ¿en que
> cabeza cabe que uses dos formas de notificar lo mismo? (ya, ya ... en la de
> los ingenieros del IETF ... XD, pero esos no cuentan).
INFO y RTP a la vez, y hasta te diría que viene así por defecto... (no
lo aseguro).
Y los del IETF nada más lejos de la realidad: precisamente hay algunos
drafts y cosas muy raras proponiendo un sistema de subscripción para
la notificación de DTMF usando noséqué body XML que es para echarles a
comer a parte...
> Hasta ahora, todos los UAC/UAS con los que he trabajado, al a hora de definir
> el modo DTMF, cuando lo fuerzas a SIP-INFO ... así se queda.
> Incluso en los nuevos HT503 de Grandstream, permite configurar
> una "preferencia" para los DTMF, si los pones en 1 SIP-INFO, 2 RFC2833, 3
> INBAND ... lo que hace es mandar primero el DTMF como SIP-INFO, sino recibe
> el 200, lo manda como RTP y a último remedio como INBAND, pero no lo envía de
> dos formas distintas al mismo tiempo
que se ha formado alrededor de los DTMF :(
Germán Aracil Boned
que funcione.
Raúl Alexis Betancor Santana escribió:
> On Thursday 20 August 2009 23:17:04 Iñaki Baz wrote:
>>> Para los enlaces SIP, lo mejor es usar el modo SIP-INFO para los DTMF,
>>> hay que huir de usar inband ... y el modo RFC no es muy fiable según con
>>> que proveedores trabajes.
>> Sólo un comentario al respecto:
>>
>> El uso de SIP INFO para envío de DTMF *no* está estandarizado en absoluto
>> (ningún RFC define el SIP INFO para DTMF). En realidad su uso proviene de
>> su empleo por algunos cacharros Cisco y otras marcas, cada cuál poniendo su
>> propio "Content-Type" no estandarizado.
>
> Yo no dije que estuviera estandarizado .. dije que era la forma más
> recomendable ... ;-)
Raúl, como podemos recomendar algo no estandarizado ? :)
Yo uso rfc2833 en todo, y nunca tengo problemas con los dtmf. Perdón ..
sí, si no descuelgo la llamada antes de recibir tonos dtmf, hay
operadores que no los hacen llegar. Pero descolgando primero, va todo
perfecto. Eso cuando soy yo quien recibe los tonos claro.
a comer todos !!!
Iñaki Baz Castillo
> Yo uso rfc2833 en todo, y nunca tengo problemas con los dtmf. Perdón ..
> sí, si no descuelgo la llamada antes de recibir tonos dtmf, hay
> operadores que no los hacen llegar. Pero descolgando primero, va todo
> perfecto. Eso cuando soy yo quien recibe los tonos claro.
no está contemplado que el llamante pueda emitir RTP mientras una
llamada está en progreso (aún no descolgada). Como dices, algunos lo
permiten y otros no. En SIP sí que está permitido. De hecho, en algún
RFC que trata de interoperabilidad ISUP-SIP, se ve claramente unas
gráficas en las que, durante el estado "early" de la llamada, existe
(o puede existir) tráfico RTP bidireccional en el tramo SIP, pero sólo
unidireccional (del llamado al llamante) en el tramo PSTN.
Saludos.