Update del Caller ID en transferencias atendidas en 1.8
410 views
Skip to first unread message
bauer
Jan 28, 2011, 6:59:08 AM1/28/11
to asterisk-es
Hola a todos
Llevamos unos días con asterisk 1.8.2.2 y tengo que decir que el
"feeling" inicial es bastante bueno. Aunque de momento es poco tiempo,
no ha habido problemas de estabilidad ni cosas raras y por lo menos
las funciones básicas no han dado problemas. Con esto funcionando, es
más fácil poder investigar las nuevas funcionalidades.
Lo primero que hemos probado nada más instalar (por la obsesión que
teníamos al respecto) es el tema del update del caller id en
transferencias atendidas. Siguiendo el post del blog de irontec, se
activa fácilmente y es un auténtico placer (y un respiro) ver cómo
cambia el caller id con las transferencias atendidas y en la captura
de llamadas.
Pero también nos hemos encontrado algún problema, y quería aprovechar
para comentarlo aquí y compartir la experiencia con los que estéis
probándolo:
- Por un lado, a nivel de teléfonos sólo hemos conseguido que funcione
con los Cisco SPA50X y SPA303. Hemos revisado la configuración de un
SNOM 360, de un Aastra 55i y de un Linksys 962 (aunque con este
tampoco nos vamos a matar, porque va a desaparecer), pero no hemos
encontrado nada que permita que el teléfono acepte los paquetes
UPDATE. Hemos hecho las correspondientes consultas, y estamos a la
espera de que nos digan algo. También tenemos pendiente probar con
softphones y con un Grandstream, y ya os diré si chuta o no.
- Por otro lado, acabo de darme cuenta de una cosa. Yo cojo el
teléfono y llamo a una línea externa por dahdi, hago transferencia
atendida a un compañero, y entonces el caller id no se actualiza. Es
decir, no funciona cuando eres tú el que haces la llamada (en vez de
recibirla). Pero lo curioso es que si en vez de llamar por dadhi
llamas a una extensión SIP interna, entonces lo hace bien
independientemente de que el que transfiera sea el que ha hecho o
recibido la llamada. Y aún más, si la llamada la haces por un gateway
sip (en nuestro caso, una tarjeta berofix), tampoco lo hace bien
(curioso porque no deja de ser otra extensión sip). Bueno, ahora
tocará hacer trazas y ver qué pasa con los UPDATEs, si los manda o no,
etc. Si alguno de los que lo esté probando me puede confirmar que
también le pasa, estaría genial (no sea que estemos metiendo la pata
en algo).
Bueno, pues eso, sólo quería comentaros las pruebas y contrastar con
la gente que esté probando que si les pasa lo mismo o no.
Un saludo
Llevamos unos días con asterisk 1.8.2.2 y tengo que decir que el
"feeling" inicial es bastante bueno. Aunque de momento es poco tiempo,
no ha habido problemas de estabilidad ni cosas raras y por lo menos
las funciones básicas no han dado problemas. Con esto funcionando, es
más fácil poder investigar las nuevas funcionalidades.
Lo primero que hemos probado nada más instalar (por la obsesión que
teníamos al respecto) es el tema del update del caller id en
transferencias atendidas. Siguiendo el post del blog de irontec, se
activa fácilmente y es un auténtico placer (y un respiro) ver cómo
cambia el caller id con las transferencias atendidas y en la captura
de llamadas.
Pero también nos hemos encontrado algún problema, y quería aprovechar
para comentarlo aquí y compartir la experiencia con los que estéis
probándolo:
- Por un lado, a nivel de teléfonos sólo hemos conseguido que funcione
con los Cisco SPA50X y SPA303. Hemos revisado la configuración de un
SNOM 360, de un Aastra 55i y de un Linksys 962 (aunque con este
tampoco nos vamos a matar, porque va a desaparecer), pero no hemos
encontrado nada que permita que el teléfono acepte los paquetes
UPDATE. Hemos hecho las correspondientes consultas, y estamos a la
espera de que nos digan algo. También tenemos pendiente probar con
softphones y con un Grandstream, y ya os diré si chuta o no.
- Por otro lado, acabo de darme cuenta de una cosa. Yo cojo el
teléfono y llamo a una línea externa por dahdi, hago transferencia
atendida a un compañero, y entonces el caller id no se actualiza. Es
decir, no funciona cuando eres tú el que haces la llamada (en vez de
recibirla). Pero lo curioso es que si en vez de llamar por dadhi
llamas a una extensión SIP interna, entonces lo hace bien
independientemente de que el que transfiera sea el que ha hecho o
recibido la llamada. Y aún más, si la llamada la haces por un gateway
sip (en nuestro caso, una tarjeta berofix), tampoco lo hace bien
(curioso porque no deja de ser otra extensión sip). Bueno, ahora
tocará hacer trazas y ver qué pasa con los UPDATEs, si los manda o no,
etc. Si alguno de los que lo esté probando me puede confirmar que
también le pasa, estaría genial (no sea que estemos metiendo la pata
en algo).
Bueno, pues eso, sólo quería comentaros las pruebas y contrastar con
la gente que esté probando que si les pasa lo mismo o no.
Un saludo
Andoni
Feb 1, 2011, 3:30:36 AM2/1/11
to asterisk-es
Buenas,
Echa un ojo a esto:
https://wiki.asterisk.org/wiki/display/AST/Manipulating+Party+ID+Information
A ver si te ayuda en algo...
Un saludo.
Echa un ojo a esto:
https://wiki.asterisk.org/wiki/display/AST/Manipulating+Party+ID+Information
A ver si te ayuda en algo...
Un saludo.
Andoni
Feb 1, 2011, 7:54:09 AM2/1/11
to asterisk-es
Me auto-respondo en parte:
-La nueva función CONNECTEDLINE no sirve de nada si tenemos audio PtP
mediante UPDATEs, porque nos machacará el CLID una vez que la llamada
se conecte.
-La nueva función REDIRECTING no he conseguido hacerla funcionar en mi
escenario...
Por tanto, no tiene nada que ver con lo que preguntas.. :(
Cuando tenga un rato probaré lo que comentas.
> Echa un ojo a esto:https://wiki.asterisk.org/wiki/display/AST/Manipulating+Party+ID+Info...
-La nueva función CONNECTEDLINE no sirve de nada si tenemos audio PtP
mediante UPDATEs, porque nos machacará el CLID una vez que la llamada
se conecte.
-La nueva función REDIRECTING no he conseguido hacerla funcionar en mi
escenario...
Por tanto, no tiene nada que ver con lo que preguntas.. :(
Cuando tenga un rato probaré lo que comentas.
> Echa un ojo a esto:https://wiki.asterisk.org/wiki/display/AST/Manipulating+Party+ID+Info...
bauer
Feb 2, 2011, 3:58:53 AM2/2/11
to asterisk-es
Sí, ya lo había probado... De hecho, ni siquiera he conseguido que me
funcione el update del CONNECTEDLINE(name) en una llamada saliente (si
me funciona el de CONNECTEDLINE(num)). De todos modos, esa es otra
batalla...
A ver si hoy consigo sacar un rato y puedo sacar unas trazas con ngrep
para ver la diferencia de los UPDATE's. Ya os cuento.
Gracias...
funcione el update del CONNECTEDLINE(name) en una llamada saliente (si
me funciona el de CONNECTEDLINE(num)). De todos modos, esa es otra
batalla...
A ver si hoy consigo sacar un rato y puedo sacar unas trazas con ngrep
para ver la diferencia de los UPDATE's. Ya os cuento.
Gracias...
bauer
Feb 15, 2011, 8:24:35 AM2/15/11
to asterisk-es
A ver... por fin hoy hemos tenido un rato para hacer unas pruebas
sobre este tema, y al menos en nuestra instalación no manda los
paquetes UPDATE cuando la llamada es saliente.
Os cuento, el primer problema que nos hemos encontrado es que hacíamos
la captura con ngrep para la entrada de llamadas y no encontrábamos
ningún paquete UPDATE, a pesar de que el update del callerid sí que lo
hacía bien. Después de darle vueltas e investigar un rato, creemos que
ngrep no entiende estos paquetes, probablemente porque no están en la
RFC3261 sino que es la RFC3311. Revisando la traza, hemos visto que sí
que había unos paquetes INVITE con la cabecera Remote-Party-ID justo
cuando deberían ir los UPDATES, por lo que hemos interpretado que como
el ngrep no entiende el paquete, lo reinterpreta como un INVITE.
Después de varias pruebas hemos visto que justo en el momento que
pulsas xfer para pasar la llamada, sale ese paquete y el callerid
cambia en el teléfono. Por lo tanto, y salvo que alguno digáis lo
contrario, entendemos que a efectos de ver lo que pasa, el UPDATE es
ese "falso" INVITE.
Una vez descubierto esto, hemos hecho varias pruebas tanto en llamadas
internas como en externas, con los siguientes resultados:
- Llamadas entrantes: El callerid se actualiza perfectamente, venga de
donde venga la llamada.
- Llamadas entre extensiones SIP internas: El caller id se actualiza
perfectamente, independientemente de que el teléfono que haga la
transferencia haya hecho o recibido la llamada.
- Llamadas salientes: Aquí está el problema. Hemos probado con una
tarjeta berofix RDSI (que es como un gateway sip) y con una placa de
líneas analógicas (con DAHDI). En ambos casos, si desde una extensión
SIP haces una llamada al exterior por cualquiera de esas dos líneas,
cuando pulsas el xfer NO APARECE NINGÚN PAQUETE UPDATE. Es como si en
ese caso, el asterisk no mandara dicho paquete, por lo que el teléfono
no actualiza el callerid correctamente.
Dicho todo esto, antes de abrir el bug en digium me gustaría confirmar
que no nos pasa sólo a nosotros. Para probarlo basta con hacer una
llamada al exterior y hacer transferencia atendida a otro teléfono, y
el callerid no se debería actualizar.
Si alguno de los que tenéis la 1.8 podéis hacer una prueba y decirme
si os funciona o no os lo agradecería...
sobre este tema, y al menos en nuestra instalación no manda los
paquetes UPDATE cuando la llamada es saliente.
Os cuento, el primer problema que nos hemos encontrado es que hacíamos
la captura con ngrep para la entrada de llamadas y no encontrábamos
ningún paquete UPDATE, a pesar de que el update del callerid sí que lo
hacía bien. Después de darle vueltas e investigar un rato, creemos que
ngrep no entiende estos paquetes, probablemente porque no están en la
RFC3261 sino que es la RFC3311. Revisando la traza, hemos visto que sí
que había unos paquetes INVITE con la cabecera Remote-Party-ID justo
cuando deberían ir los UPDATES, por lo que hemos interpretado que como
el ngrep no entiende el paquete, lo reinterpreta como un INVITE.
Después de varias pruebas hemos visto que justo en el momento que
pulsas xfer para pasar la llamada, sale ese paquete y el callerid
cambia en el teléfono. Por lo tanto, y salvo que alguno digáis lo
contrario, entendemos que a efectos de ver lo que pasa, el UPDATE es
ese "falso" INVITE.
Una vez descubierto esto, hemos hecho varias pruebas tanto en llamadas
internas como en externas, con los siguientes resultados:
- Llamadas entrantes: El callerid se actualiza perfectamente, venga de
donde venga la llamada.
- Llamadas entre extensiones SIP internas: El caller id se actualiza
perfectamente, independientemente de que el teléfono que haga la
transferencia haya hecho o recibido la llamada.
- Llamadas salientes: Aquí está el problema. Hemos probado con una
tarjeta berofix RDSI (que es como un gateway sip) y con una placa de
líneas analógicas (con DAHDI). En ambos casos, si desde una extensión
SIP haces una llamada al exterior por cualquiera de esas dos líneas,
cuando pulsas el xfer NO APARECE NINGÚN PAQUETE UPDATE. Es como si en
ese caso, el asterisk no mandara dicho paquete, por lo que el teléfono
no actualiza el callerid correctamente.
Dicho todo esto, antes de abrir el bug en digium me gustaría confirmar
que no nos pasa sólo a nosotros. Para probarlo basta con hacer una
llamada al exterior y hacer transferencia atendida a otro teléfono, y
el callerid no se debería actualizar.
Si alguno de los que tenéis la 1.8 podéis hacer una prueba y decirme
si os funciona o no os lo agradecería...
Andoni
Feb 16, 2011, 9:14:15 AM2/16/11
to asterisk-es
Buenas,
Te respondo en la medida de los posible:
-Te puedo confirmar que con un ngrep vemos claramente los UPDATEs.
U 10.10.5.1:5060 -> 10.10.5.13:5060
UPDATE sip:CBT14...@10.10.5.13:5060 SIP/2.0.
Via: SIP/2.0/UDP 10.10.5.1:5060;branch=z9hG4bK7a54cca7.
Max-Forwards: 70.
From: "Jon " <sip:51...@10.10.5.1>;tag=as637be323.
To: <sip:CBT14...@10.10.5.13:5060>;tag=73d1a2edc5ebf6ebi0.
Contact: <sip:51...@10.10.5.1:5060>.
Call-ID: 55bc06fe30579064...@10.10.5.1:5060.
CSeq: 103 UPDATE.
User-Agent: "Irontec IVOZ".
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH.
Supported: replaces, timer.
P-Asserted-Identity: "Andoni Izurza" <sip:2...@10.10.5.1>.
Content-Type: application/sdp.
Content-Length: 172.
.
v=0.
o=root 899558662 899558663 IN IP4 10.10.5.1.
s=Asterisk PBX 1.8.2.3.
c=IN IP4 10.10.5.1.
t=0 0.
m=audio 16886 RTP/AVP 8.
a=rtpmap:8 PCMA/8000.
a=ptime:20.
a=sendrecv.
Imagino que tienes directmedia=update ¿no?
Y ahora las pruebas:
-Llamada externa y Xfer interna -> OK
-Llamada interna y Xfer interna -> OK
-Llama interna y Xfer interna malvada (A llama y A transfiere) -> NOK
-->Esto a vosotros si que os funciona ¿no?
En este caso tenemos UPDATEs, pero el PAI enviado por Asterisk no es
correcto. Envía el CLID del que transfiere (y se quita de en medio) a
ambos extremos.
-Llamada externa y Xfer interna malvada -> NOK
En este caso Asterisk también envía un Update, pero con P-Asserted-
ID el CLID del que está transfiriendo WTF¿?
Para las pruebas:
sendrpid=pai
directmedia=update
dtmfmode=info (no en todos los terminales)
De todas formas con esta combinación arriba descrita las
transferencias me tiran Asterisk. (si todos los implicados tiene INFO)
https://issues.asterisk.org/view.php?id=18734
Pero con dtmfmode=rfc2833 (para todos) no tengo audio PtP, ni UPDATEs
para actualizar la sesión... :(
Te respondo en la medida de los posible:
-Te puedo confirmar que con un ngrep vemos claramente los UPDATEs.
U 10.10.5.1:5060 -> 10.10.5.13:5060
UPDATE sip:CBT14...@10.10.5.13:5060 SIP/2.0.
Via: SIP/2.0/UDP 10.10.5.1:5060;branch=z9hG4bK7a54cca7.
Max-Forwards: 70.
From: "Jon " <sip:51...@10.10.5.1>;tag=as637be323.
To: <sip:CBT14...@10.10.5.13:5060>;tag=73d1a2edc5ebf6ebi0.
Contact: <sip:51...@10.10.5.1:5060>.
Call-ID: 55bc06fe30579064...@10.10.5.1:5060.
CSeq: 103 UPDATE.
User-Agent: "Irontec IVOZ".
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH.
Supported: replaces, timer.
P-Asserted-Identity: "Andoni Izurza" <sip:2...@10.10.5.1>.
Content-Type: application/sdp.
Content-Length: 172.
.
v=0.
o=root 899558662 899558663 IN IP4 10.10.5.1.
s=Asterisk PBX 1.8.2.3.
c=IN IP4 10.10.5.1.
t=0 0.
m=audio 16886 RTP/AVP 8.
a=rtpmap:8 PCMA/8000.
a=ptime:20.
a=sendrecv.
Imagino que tienes directmedia=update ¿no?
Y ahora las pruebas:
-Llamada externa y Xfer interna -> OK
-Llamada interna y Xfer interna -> OK
-Llama interna y Xfer interna malvada (A llama y A transfiere) -> NOK
-->Esto a vosotros si que os funciona ¿no?
En este caso tenemos UPDATEs, pero el PAI enviado por Asterisk no es
correcto. Envía el CLID del que transfiere (y se quita de en medio) a
ambos extremos.
-Llamada externa y Xfer interna malvada -> NOK
En este caso Asterisk también envía un Update, pero con P-Asserted-
ID el CLID del que está transfiriendo WTF¿?
Para las pruebas:
sendrpid=pai
directmedia=update
dtmfmode=info (no en todos los terminales)
De todas formas con esta combinación arriba descrita las
transferencias me tiran Asterisk. (si todos los implicados tiene INFO)
https://issues.asterisk.org/view.php?id=18734
Pero con dtmfmode=rfc2833 (para todos) no tengo audio PtP, ni UPDATEs
para actualizar la sesión... :(
bauer
Feb 16, 2011, 11:15:19 AM2/16/11
to asterisk-es
Te respondo abajo...
On 16 feb, 15:14, Andoni <andoni.izu...@gmail.com> wrote:
> Buenas,
>
> Te respondo en la medida de los posible:
>
> -Te puedo confirmar que con un ngrep vemos claramente los UPDATEs.
>
> U 10.10.5.1:5060 -> 10.10.5.13:5060
> UPDATE sip:CBT14100...@10.10.5.13:5060 SIP/2.0.
> To: <sip:CBT14100...@10.10.5.13:5060>;tag=73d1a2edc5ebf6ebi0.
> Contact: <sip:5...@10.10.5.1:5060>.
> Call-ID: 55bc06fe305790641d3eaa854d479...@10.10.5.1:5060.
con la cabecera Remote-Party-ID, que es el que pensábamos que era el
UPDATE, pero que el ngrep no lo interpretaba bien y por eso aparecía
como un invite... ¡Joder! Pero ni con tcpdump, ni con ngrep hemos sido
capaces de que aparezca el UPDATE, sin embargo para los casos en los
aparece es INVITE, el callerid se refresca correctamente, y ese
paquete sale justo cuando pulsamos xfer por segunda vez... ¡Raro,
raro!
> Imagino que tienes directmedia=update ¿no?
>
Sí, sí
> Y ahora las pruebas:
> -Llamada externa y Xfer interna -> OK
> -Llamada interna y Xfer interna -> OK
> -Llama interna y Xfer interna malvada (A llama y A transfiere) -> NOK
> -->Esto a vosotros si que os funciona ¿no?
> En este caso tenemos UPDATEs, pero el PAI enviado por Asterisk no es
> correcto. Envía el CLID del que transfiere (y se quita de en medio) a
> ambos extremos.
> -Llamada externa y Xfer interna malvada -> NOK
> En este caso Asterisk también envía un Update, pero con P-Asserted-
> ID el CLID del que está transfiriendo WTF¿?
>
Me he hecho un poco de lío, a ver si soy capaz de explicarme bien:
- La extensión A hace una llamada a la extensión interna B -> Da igual
quien transfiera, que el callerid se actualiza bien. Vemos el paquete
INVITE con Remote-Party-ID que tiene toda la pinta de ser el que hace
que se actualice el callerid en B, pero no es un UPDATE, es un INVITE.
- La extensión A RECIBE una llamada desde el exterior (desde un DAHDI,
por ejemplo), y hace una transferencia atendida a la extensión B -> El
callerid se actualiza correctamente. Vemos el paquete INVITE con
Remote-Party-ID.
- La extensión A HACE una llamada al exterior (por un DAHDI, por
ejemplo), y hace una transferencia atendida a la extensión B -> El
callerid no se actualiza. No vemos el paquete INVITE con Remote-Party-
ID.
> Para las pruebas:
> sendrpid=pai
> directmedia=update
> dtmfmode=info (no en todos los terminales)
>
Nosotros tenemos:
sendrpid=yes
directmedia=update
dtmfmode=rfc2833
... todo esto en la sección [general] del sip.conf (es correcto,
¿no?). Las extensiones las tenemos en MySQL con Realtime. Lo digo por
comparar con vuestra instalación.
> De todas formas con esta combinación arriba descrita las
> transferencias me tiran Asterisk. (si todos los implicados tiene INFO)https://issues.asterisk.org/view.php?id=18734
asterisk (aunque claro, no usamos DTMF INFO).
Conclusiones (por llamarlas de alguna manera...):
- Lo del UPDATE y ngrep ahora mismo me ha dejado a cuadros. Si no hay
UPDATES, no entiendo por qué el SPA504G lo actualiza bien. Tengo que
pensarlo y probar más...
- En cuanto pueda voy a empezar por probar con sendrpid=pai, y os
cuento qué pasa, para ver si arroja algo de luz.
Bienvenidos a la nave del misterio...
On 16 feb, 15:14, Andoni <andoni.izu...@gmail.com> wrote:
> Buenas,
>
> Te respondo en la medida de los posible:
>
> -Te puedo confirmar que con un ngrep vemos claramente los UPDATEs.
>
> U 10.10.5.1:5060 -> 10.10.5.13:5060
> Via: SIP/2.0/UDP 10.10.5.1:5060;branch=z9hG4bK7a54cca7.
> Max-Forwards: 70.
> From: "Jon " <sip:5...@10.10.5.1>;tag=as637be323.
> Max-Forwards: 70.
> To: <sip:CBT14100...@10.10.5.13:5060>;tag=73d1a2edc5ebf6ebi0.
> Contact: <sip:5...@10.10.5.1:5060>.
> Call-ID: 55bc06fe305790641d3eaa854d479...@10.10.5.1:5060.
> CSeq: 103 UPDATE.
> User-Agent: "Irontec IVOZ".
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
> INFO, PUBLISH.
> Supported: replaces, timer.
> P-Asserted-Identity: "Andoni Izurza" <sip:2...@10.10.5.1>.
> Content-Type: application/sdp.
> Content-Length: 172.
> .
> v=0.
> o=root 899558662 899558663 IN IP4 10.10.5.1.
> s=Asterisk PBX 1.8.2.3.
> c=IN IP4 10.10.5.1.
> t=0 0.
> m=audio 16886 RTP/AVP 8.
> a=rtpmap:8 PCMA/8000.
> a=ptime:20.
> a=sendrecv.
>
Cagüen la leche! Pues y alo flipo. A nosotros nos aparece un invite
> User-Agent: "Irontec IVOZ".
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
> INFO, PUBLISH.
> Supported: replaces, timer.
> P-Asserted-Identity: "Andoni Izurza" <sip:2...@10.10.5.1>.
> Content-Type: application/sdp.
> Content-Length: 172.
> .
> v=0.
> o=root 899558662 899558663 IN IP4 10.10.5.1.
> s=Asterisk PBX 1.8.2.3.
> c=IN IP4 10.10.5.1.
> t=0 0.
> m=audio 16886 RTP/AVP 8.
> a=rtpmap:8 PCMA/8000.
> a=ptime:20.
> a=sendrecv.
>
con la cabecera Remote-Party-ID, que es el que pensábamos que era el
UPDATE, pero que el ngrep no lo interpretaba bien y por eso aparecía
como un invite... ¡Joder! Pero ni con tcpdump, ni con ngrep hemos sido
capaces de que aparezca el UPDATE, sin embargo para los casos en los
aparece es INVITE, el callerid se refresca correctamente, y ese
paquete sale justo cuando pulsamos xfer por segunda vez... ¡Raro,
raro!
> Imagino que tienes directmedia=update ¿no?
>
> Y ahora las pruebas:
> -Llamada externa y Xfer interna -> OK
> -Llamada interna y Xfer interna -> OK
> -Llama interna y Xfer interna malvada (A llama y A transfiere) -> NOK
> -->Esto a vosotros si que os funciona ¿no?
> En este caso tenemos UPDATEs, pero el PAI enviado por Asterisk no es
> correcto. Envía el CLID del que transfiere (y se quita de en medio) a
> ambos extremos.
> -Llamada externa y Xfer interna malvada -> NOK
> En este caso Asterisk también envía un Update, pero con P-Asserted-
> ID el CLID del que está transfiriendo WTF¿?
>
- La extensión A hace una llamada a la extensión interna B -> Da igual
quien transfiera, que el callerid se actualiza bien. Vemos el paquete
INVITE con Remote-Party-ID que tiene toda la pinta de ser el que hace
que se actualice el callerid en B, pero no es un UPDATE, es un INVITE.
- La extensión A RECIBE una llamada desde el exterior (desde un DAHDI,
por ejemplo), y hace una transferencia atendida a la extensión B -> El
callerid se actualiza correctamente. Vemos el paquete INVITE con
Remote-Party-ID.
- La extensión A HACE una llamada al exterior (por un DAHDI, por
ejemplo), y hace una transferencia atendida a la extensión B -> El
callerid no se actualiza. No vemos el paquete INVITE con Remote-Party-
ID.
> Para las pruebas:
> sendrpid=pai
> directmedia=update
> dtmfmode=info (no en todos los terminales)
>
sendrpid=yes
directmedia=update
dtmfmode=rfc2833
... todo esto en la sección [general] del sip.conf (es correcto,
¿no?). Las extensiones las tenemos en MySQL con Realtime. Lo digo por
comparar con vuestra instalación.
> De todas formas con esta combinación arriba descrita las
>
> Pero con dtmfmode=rfc2833 (para todos) no tengo audio PtP, ni UPDATEs
> para actualizar la sesión... :(
>
Nosotros en principio no hemos tenido problemas de audio ni caídas de
> Pero con dtmfmode=rfc2833 (para todos) no tengo audio PtP, ni UPDATEs
> para actualizar la sesión... :(
>
asterisk (aunque claro, no usamos DTMF INFO).
Conclusiones (por llamarlas de alguna manera...):
- Lo del UPDATE y ngrep ahora mismo me ha dejado a cuadros. Si no hay
UPDATES, no entiendo por qué el SPA504G lo actualiza bien. Tengo que
pensarlo y probar más...
- En cuanto pueda voy a empezar por probar con sendrpid=pai, y os
cuento qué pasa, para ver si arroja algo de luz.
Bienvenidos a la nave del misterio...
bauer
Feb 16, 2011, 11:36:43 AM2/16/11
to asterisk-es
Acabo de probar con sendrpid=pai y lo mismo, ni rastro de los updates.
Este es el paquete que nos actualiza el callerid...
U 2011/02/16 17:23:51.063001 192.168.19.20:37444 -> 192.168.19.96:5060
INVITE sip:prueb...@192.168.19.96:5060 SIP/2.0'
Via: SIP/2.0/UDP 192.168.19.20:37444;branch=z9hG4bK57f5e4ea'
Max-Forwards: 70'
From: "Alberto" <sip:prueb...@192.168.19.20:37444>;tag=as2ae36194'
To: <sip:prueb...@192.168.19.96:5060>;tag=8b526c7cdb9b6bf4i0'
Contact: <sip:prueb...@192.168.19.20:37444>'
Call-ID: 31caa1127c1f843a...@192.168.19.20:37444'
CSeq: 103 INVITE'
User-Agent: Asterisk PBX 1.8.2.2'
Supported: replaces, timer'
P-Asserted-Identity: "Manolo" <sip:6999...@192.168.19.20>'
Content-Type: application/sdp'
Content-Length: 234'
'
v=0'
o=root 135183119 135183120 IN IP4 192.168.19.20'
s=Asterisk PBX 1.8.2.2'
c=IN IP4 192.168.19.20'
t=0 0'
m=audio 10036 RTP/AVP 8 101'
a=rtpmap:8 PCMA/8000'
a=rtpmap:101 telephone-event/8000'
a=fmtp:101 0-16'
a=ptime:20'
a=sendrecv'
En busca de los UPDATE's perdidos....
Este es el paquete que nos actualiza el callerid...
U 2011/02/16 17:23:51.063001 192.168.19.20:37444 -> 192.168.19.96:5060
INVITE sip:prueb...@192.168.19.96:5060 SIP/2.0'
Via: SIP/2.0/UDP 192.168.19.20:37444;branch=z9hG4bK57f5e4ea'
Max-Forwards: 70'
From: "Alberto" <sip:prueb...@192.168.19.20:37444>;tag=as2ae36194'
To: <sip:prueb...@192.168.19.96:5060>;tag=8b526c7cdb9b6bf4i0'
Contact: <sip:prueb...@192.168.19.20:37444>'
Call-ID: 31caa1127c1f843a...@192.168.19.20:37444'
CSeq: 103 INVITE'
User-Agent: Asterisk PBX 1.8.2.2'
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO,
PUBLIS
H'
INFO,
PUBLIS
Supported: replaces, timer'
P-Asserted-Identity: "Manolo" <sip:6999...@192.168.19.20>'
Content-Type: application/sdp'
Content-Length: 234'
'
v=0'
o=root 135183119 135183120 IN IP4 192.168.19.20'
s=Asterisk PBX 1.8.2.2'
c=IN IP4 192.168.19.20'
t=0 0'
m=audio 10036 RTP/AVP 8 101'
a=rtpmap:8 PCMA/8000'
a=rtpmap:101 telephone-event/8000'
a=fmtp:101 0-16'
a=ptime:20'
a=sendrecv'
En busca de los UPDATE's perdidos....
Andoni
Feb 16, 2011, 12:30:08 PM2/16/11
to asterisk-es
Buenas,
En otra máquina de pruebas con Asterisk 1.8.2.3:
-Dialplan simple:
exten => _X.,1,NoOp(Llamada pra ${EXTEN})
exten => _X.,n,Dial(SIP/${EXTEN})
-Peers en sip.conf:
[usuario](!)
type=friend
secret=1234
host=dynamic
disallow=all
allow=alaw
context=remoteParty
;;Lo interesante:
;sendrpid=yes ;; => sendrpid=rpid
sendrpid=yes
directmedia=update
;directrtpsetup=yes
dtmfmode=rfc2833
[100](usuario)
[200](usuario)
[300](usuario)
-Llamada de 100 a 200 y después 100 transfiere a 300 -> No hay UPDATE
de CLID!!!! (No se como lo haces...) :P
-Llamada de 100 a 200 y después 200 transfiere a 300 -> UPDATE de CLID
correcto, con el correspondiente SIP UPDATE.
Te pego un trozo de la traza SIP (con Ngrep) del instante en el que se
confirma la Xfer.
U 10.10.0.177:5063 -> 10.10.0.165:5060
REFER sip:1...@10.10.0.165:5060 SIP/2.0.
Via: SIP/2.0/UDP 10.10.0.177:5063;branch=z9hG4bK-127877ab.
From: <sip:2...@10.10.0.177>;tag=27cccb20bc6792cai3.
To: "100" <sip:1...@10.10.0.165>;tag=as5c51b1ea.
Referred-By: <sip:2...@10.10.0.165>.
Call-ID: 11e0dd3543d69a44...@10.10.0.165:5060.
CSeq: 102 REFER.
Max-Forwards: 70.
Contact: <sip:2...@10.10.0.177:5063>.
Refer-To: <sip:3...@10.10.0.165?Replaces=9c5dccba-
c9dbf1e6%4010.10.0.177%3Bfrom-tag%3Db8ea2eaaec3178b6o3%3Bto-tag
%3Das60e8839a>.
User-Agent: Cisco/SPA504G-7.4.3.
Content-Length: 0.
.
U 10.10.0.165:5060 -> 10.10.0.177:5063
SIP/2.0 202 Accepted.
Via: SIP/2.0/UDP
10.10.0.177:5063;branch=z9hG4bK-127877ab;received=10.10.0.177.
From: <sip:2...@10.10.0.177>;tag=27cccb20bc6792cai3.
To: "100" <sip:1...@10.10.0.165>;tag=as5c51b1ea.
Call-ID: 11e0dd3543d69a44...@10.10.0.165:5060.
CSeq: 102 REFER.
Server: Asterisk PBX 1.8.2.3.
Supported: replaces, timer.
Contact: <sip:1...@10.10.0.165:5060>.
Content-Length: 0.
.
U 10.10.0.165:5060 -> 10.10.0.177:5063
NOTIFY sip:2...@10.10.0.177:5063 SIP/2.0.
Via: SIP/2.0/UDP 10.10.0.165:5060;branch=z9hG4bK19772c6b.
Max-Forwards: 70.
From: "100" <sip:1...@10.10.0.165>;tag=as5c51b1ea.
To: <sip:2...@10.10.0.177>;tag=27cccb20bc6792cai3.
Contact: <sip:1...@10.10.0.165:5060>.
Call-ID: 11e0dd3543d69a44...@10.10.0.165:5060.
CSeq: 103 NOTIFY.
User-Agent: Asterisk PBX 1.8.2.3.
Event: refer;id=102.
Subscription-state: terminated;reason=noresource.
Content-Type: message/sipfrag;version=2.0.
Supported: replaces, timer.
Content-Length: 16.
.
SIP/2.0 200 OK.
U 10.10.0.165:5060 -> 10.10.0.177:5063
BYE sip:2...@10.10.0.177:5063 SIP/2.0.
Via: SIP/2.0/UDP 10.10.0.165:5060;branch=z9hG4bK234066d9.
Max-Forwards: 70.
From: "300" <sip:3...@10.10.0.165>;tag=as60e8839a.
To: <sip:2...@10.10.0.165>;tag=b8ea2eaaec3178b6o3.
Call-ID: 9c5dccba...@10.10.0.177.
CSeq: 102 BYE.
User-Agent: Asterisk PBX 1.8.2.3.
Proxy-Authorization: Digest username="200", realm="asterisk",
algorithm=MD5, uri="10.10.0.165", nonce="",
response="eda523f9a8f4f7f8e747f003843b0fba".
X-Asterisk-HangupCause: Normal Clearing.
X-Asterisk-HangupCauseCode: 16.
Content-Length: 0.
.
U 10.10.0.165:5060 -> 10.10.0.142:5064
UPDATE sip:3...@10.10.0.142:5064 SIP/2.0.
Via: SIP/2.0/UDP 10.10.0.165:5060;branch=z9hG4bK54fc847d.
Max-Forwards: 70.
From: "200" <sip:2...@10.10.0.165>;tag=as4e16ecc6.
To: <sip:3...@10.10.0.142:5064>;tag=21a4719cbfa891bfi4.
Contact: <sip:2...@10.10.0.165:5060>.
Call-ID: 4cb9feb305510fee...@10.10.0.165:5060.
CSeq: 103 UPDATE.
User-Agent: Asterisk PBX 1.8.2.3.
Supported: replaces, timer.
Remote-Party-ID: "100" <sip:
1...@10.10.0.165>;party=calling;privacy=off;screen=no.
Content-Type: application/sdp.
Content-Length: 261.
.
v=0.
o=root 1194507612 1194507613 IN IP4 10.10.0.165.
s=Asterisk PBX 1.8.2.3.
c=IN IP4 10.10.0.165.
t=0 0.
m=audio 18294 RTP/AVP 8 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.
U 10.10.0.177:5063 -> 10.10.0.165:5060
SIP/2.0 200 OK.
To: <sip:2...@10.10.0.177>;tag=27cccb20bc6792cai3.
From: "100" <sip:1...@10.10.0.165>;tag=as5c51b1ea.
Call-ID: 11e0dd3543d69a44...@10.10.0.165:5060.
CSeq: 103 NOTIFY.
Via: SIP/2.0/UDP 10.10.0.165:5060;branch=z9hG4bK19772c6b.
Server: Cisco/SPA504G-7.4.3.
Content-Length: 0.
.
U 10.10.0.177:5063 -> 10.10.0.165:5060
SIP/2.0 200 OK.
To: <sip:2...@10.10.0.165>;tag=b8ea2eaaec3178b6o3.
From: "300" <sip:3...@10.10.0.165>;tag=as60e8839a.
Call-ID: 9c5dccba...@10.10.0.177.
CSeq: 102 BYE.
Via: SIP/2.0/UDP 10.10.0.165:5060;branch=z9hG4bK234066d9.
Server: Cisco/SPA504G-7.4.3.
Content-Length: 0.
.
U 10.10.0.142:5064 -> 10.10.0.165:5060
SIP/2.0 200 OK.
To: <sip:3...@10.10.0.142:5064>;tag=21a4719cbfa891bfi4.
From: "200" <sip:2...@10.10.0.165>;tag=as4e16ecc6.
Call-ID: 4cb9feb305510fee...@10.10.0.165:5060.
CSeq: 103 UPDATE.
Via: SIP/2.0/UDP 10.10.0.165:5060;branch=z9hG4bK54fc847d.
Contact: <sip:3...@10.10.0.142:5064>.
Server: Cisco/SPA509G-7.4.3.
Content-Length: 210.
Content-Type: application/sdp.
.
v=0.
o=- 114590764 114590765 IN IP4 10.10.0.142.
s=-.
c=IN IP4 10.10.0.142.
t=0 0.
m=audio 16028 RTP/AVP 8 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=ptime:30.
a=sendrecv.
En los casos en los que transfiere el que hace la primera llamada no
he conseguido hacer funcionar el updateo del CLID. Ni siquiera
haciendo transferencias semi-atendidas (confirmar xfer en el ringing).
Seguiré mirando...
Un saludo.
On 16 feb, 17:36, bauer <alberto.igles...@coit.es> wrote:
> Acabo de probar con sendrpid=pai y lo mismo, ni rastro de los updates.
> Este es el paquete que nos actualiza el callerid...
>
> U 2011/02/16 17:23:51.063001 192.168.19.20:37444 -> 192.168.19.96:5060
> INVITE sip:pruebas...@192.168.19.96:5060 SIP/2.0'
> To: <sip:pruebas...@192.168.19.96:5060>;tag=8b526c7cdb9b6bf4i0'
> Contact: <sip:pruebas...@192.168.19.20:37444>'
> Call-ID: 31caa1127c1f843a52d15d956d110...@192.168.19.20:37444'
En otra máquina de pruebas con Asterisk 1.8.2.3:
-Dialplan simple:
exten => _X.,1,NoOp(Llamada pra ${EXTEN})
exten => _X.,n,Dial(SIP/${EXTEN})
-Peers en sip.conf:
[usuario](!)
type=friend
secret=1234
host=dynamic
disallow=all
allow=alaw
context=remoteParty
;;Lo interesante:
;sendrpid=yes ;; => sendrpid=rpid
sendrpid=yes
directmedia=update
;directrtpsetup=yes
dtmfmode=rfc2833
[100](usuario)
[200](usuario)
[300](usuario)
-Llamada de 100 a 200 y después 100 transfiere a 300 -> No hay UPDATE
de CLID!!!! (No se como lo haces...) :P
-Llamada de 100 a 200 y después 200 transfiere a 300 -> UPDATE de CLID
correcto, con el correspondiente SIP UPDATE.
Te pego un trozo de la traza SIP (con Ngrep) del instante en el que se
confirma la Xfer.
U 10.10.0.177:5063 -> 10.10.0.165:5060
REFER sip:1...@10.10.0.165:5060 SIP/2.0.
Via: SIP/2.0/UDP 10.10.0.177:5063;branch=z9hG4bK-127877ab.
From: <sip:2...@10.10.0.177>;tag=27cccb20bc6792cai3.
To: "100" <sip:1...@10.10.0.165>;tag=as5c51b1ea.
Referred-By: <sip:2...@10.10.0.165>.
Call-ID: 11e0dd3543d69a44...@10.10.0.165:5060.
CSeq: 102 REFER.
Max-Forwards: 70.
Contact: <sip:2...@10.10.0.177:5063>.
Refer-To: <sip:3...@10.10.0.165?Replaces=9c5dccba-
c9dbf1e6%4010.10.0.177%3Bfrom-tag%3Db8ea2eaaec3178b6o3%3Bto-tag
%3Das60e8839a>.
User-Agent: Cisco/SPA504G-7.4.3.
Content-Length: 0.
.
U 10.10.0.165:5060 -> 10.10.0.177:5063
SIP/2.0 202 Accepted.
Via: SIP/2.0/UDP
10.10.0.177:5063;branch=z9hG4bK-127877ab;received=10.10.0.177.
From: <sip:2...@10.10.0.177>;tag=27cccb20bc6792cai3.
To: "100" <sip:1...@10.10.0.165>;tag=as5c51b1ea.
Call-ID: 11e0dd3543d69a44...@10.10.0.165:5060.
CSeq: 102 REFER.
Server: Asterisk PBX 1.8.2.3.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH.
Supported: replaces, timer.
Contact: <sip:1...@10.10.0.165:5060>.
Content-Length: 0.
.
U 10.10.0.165:5060 -> 10.10.0.177:5063
NOTIFY sip:2...@10.10.0.177:5063 SIP/2.0.
Via: SIP/2.0/UDP 10.10.0.165:5060;branch=z9hG4bK19772c6b.
Max-Forwards: 70.
From: "100" <sip:1...@10.10.0.165>;tag=as5c51b1ea.
To: <sip:2...@10.10.0.177>;tag=27cccb20bc6792cai3.
Contact: <sip:1...@10.10.0.165:5060>.
Call-ID: 11e0dd3543d69a44...@10.10.0.165:5060.
CSeq: 103 NOTIFY.
User-Agent: Asterisk PBX 1.8.2.3.
Event: refer;id=102.
Subscription-state: terminated;reason=noresource.
Content-Type: message/sipfrag;version=2.0.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH.
Supported: replaces, timer.
Content-Length: 16.
.
SIP/2.0 200 OK.
U 10.10.0.165:5060 -> 10.10.0.177:5063
BYE sip:2...@10.10.0.177:5063 SIP/2.0.
Via: SIP/2.0/UDP 10.10.0.165:5060;branch=z9hG4bK234066d9.
Max-Forwards: 70.
From: "300" <sip:3...@10.10.0.165>;tag=as60e8839a.
To: <sip:2...@10.10.0.165>;tag=b8ea2eaaec3178b6o3.
Call-ID: 9c5dccba...@10.10.0.177.
CSeq: 102 BYE.
User-Agent: Asterisk PBX 1.8.2.3.
Proxy-Authorization: Digest username="200", realm="asterisk",
algorithm=MD5, uri="10.10.0.165", nonce="",
response="eda523f9a8f4f7f8e747f003843b0fba".
X-Asterisk-HangupCause: Normal Clearing.
X-Asterisk-HangupCauseCode: 16.
Content-Length: 0.
.
U 10.10.0.165:5060 -> 10.10.0.142:5064
UPDATE sip:3...@10.10.0.142:5064 SIP/2.0.
Via: SIP/2.0/UDP 10.10.0.165:5060;branch=z9hG4bK54fc847d.
Max-Forwards: 70.
From: "200" <sip:2...@10.10.0.165>;tag=as4e16ecc6.
To: <sip:3...@10.10.0.142:5064>;tag=21a4719cbfa891bfi4.
Contact: <sip:2...@10.10.0.165:5060>.
Call-ID: 4cb9feb305510fee...@10.10.0.165:5060.
CSeq: 103 UPDATE.
User-Agent: Asterisk PBX 1.8.2.3.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH.
Supported: replaces, timer.
Remote-Party-ID: "100" <sip:
1...@10.10.0.165>;party=calling;privacy=off;screen=no.
Content-Type: application/sdp.
Content-Length: 261.
.
v=0.
o=root 1194507612 1194507613 IN IP4 10.10.0.165.
s=Asterisk PBX 1.8.2.3.
c=IN IP4 10.10.0.165.
t=0 0.
m=audio 18294 RTP/AVP 8 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.
U 10.10.0.177:5063 -> 10.10.0.165:5060
SIP/2.0 200 OK.
To: <sip:2...@10.10.0.177>;tag=27cccb20bc6792cai3.
From: "100" <sip:1...@10.10.0.165>;tag=as5c51b1ea.
Call-ID: 11e0dd3543d69a44...@10.10.0.165:5060.
CSeq: 103 NOTIFY.
Via: SIP/2.0/UDP 10.10.0.165:5060;branch=z9hG4bK19772c6b.
Server: Cisco/SPA504G-7.4.3.
Content-Length: 0.
.
U 10.10.0.177:5063 -> 10.10.0.165:5060
SIP/2.0 200 OK.
To: <sip:2...@10.10.0.165>;tag=b8ea2eaaec3178b6o3.
From: "300" <sip:3...@10.10.0.165>;tag=as60e8839a.
Call-ID: 9c5dccba...@10.10.0.177.
CSeq: 102 BYE.
Via: SIP/2.0/UDP 10.10.0.165:5060;branch=z9hG4bK234066d9.
Server: Cisco/SPA504G-7.4.3.
Content-Length: 0.
.
U 10.10.0.142:5064 -> 10.10.0.165:5060
SIP/2.0 200 OK.
To: <sip:3...@10.10.0.142:5064>;tag=21a4719cbfa891bfi4.
From: "200" <sip:2...@10.10.0.165>;tag=as4e16ecc6.
Call-ID: 4cb9feb305510fee...@10.10.0.165:5060.
CSeq: 103 UPDATE.
Via: SIP/2.0/UDP 10.10.0.165:5060;branch=z9hG4bK54fc847d.
Contact: <sip:3...@10.10.0.142:5064>.
Server: Cisco/SPA509G-7.4.3.
Content-Length: 210.
Content-Type: application/sdp.
.
v=0.
o=- 114590764 114590765 IN IP4 10.10.0.142.
s=-.
c=IN IP4 10.10.0.142.
t=0 0.
m=audio 16028 RTP/AVP 8 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=ptime:30.
a=sendrecv.
En los casos en los que transfiere el que hace la primera llamada no
he conseguido hacer funcionar el updateo del CLID. Ni siquiera
haciendo transferencias semi-atendidas (confirmar xfer en el ringing).
Seguiré mirando...
Un saludo.
On 16 feb, 17:36, bauer <alberto.igles...@coit.es> wrote:
> Acabo de probar con sendrpid=pai y lo mismo, ni rastro de los updates.
> Este es el paquete que nos actualiza el callerid...
>
> U 2011/02/16 17:23:51.063001 192.168.19.20:37444 -> 192.168.19.96:5060
> Via: SIP/2.0/UDP 192.168.19.20:37444;branch=z9hG4bK57f5e4ea'
> Max-Forwards: 70'
> From: "Alberto" <sip:pruebas...@192.168.19.20:37444>;tag=as2ae36194'
> Max-Forwards: 70'
> To: <sip:pruebas...@192.168.19.96:5060>;tag=8b526c7cdb9b6bf4i0'
> Contact: <sip:pruebas...@192.168.19.20:37444>'
> Call-ID: 31caa1127c1f843a52d15d956d110...@192.168.19.20:37444'
> CSeq: 103 INVITE'
> User-Agent: Asterisk PBX 1.8.2.2'
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
> INFO,
> PUBLIS
> H'
> Supported: replaces, timer'
> P-Asserted-Identity: "Manolo" <sip:699999...@192.168.19.20>'
> User-Agent: Asterisk PBX 1.8.2.2'
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
> INFO,
> PUBLIS
> H'
> Supported: replaces, timer'
bauer
Feb 16, 2011, 12:45:21 PM2/16/11
to asterisk-es
Lo único que veo a bote pronto es que yo los valores de sendrpid y
directmedia los pongo en la sección [general] del sip.conf en lugar de
en la definición de cada peer como tú (bueno, usas un template pero en
definitiva es lo mismo que ponerlo en cada peer).
¿puedes probar a ponerlo en [general] y quitarlo de los peer y ver lo
que pasa? Yo también puedo hacer lo contrario, pero al tener realtime
tengo que modificar la tabla de los peer. Si no te importa probarlo tú
con el archivo de texto, sólo para ver si influye...
O sea, que de momento te voy ganando :P, porque a nosotros sólo nos
falla cuando la llamada es al exterior, pero en internas nos
funciona... Aunque eso sí, tu tienes UPDATES y nosotros no (sniff!)
Bueno, lo dejamos en tablas... ;)
> Call-ID: 11e0dd3543d69a4434f7adac5359d...@10.10.0.165:5060.
> Call-ID: 11e0dd3543d69a4434f7adac5359d...@10.10.0.165:5060.
directmedia los pongo en la sección [general] del sip.conf en lugar de
en la definición de cada peer como tú (bueno, usas un template pero en
definitiva es lo mismo que ponerlo en cada peer).
¿puedes probar a ponerlo en [general] y quitarlo de los peer y ver lo
que pasa? Yo también puedo hacer lo contrario, pero al tener realtime
tengo que modificar la tabla de los peer. Si no te importa probarlo tú
con el archivo de texto, sólo para ver si influye...
O sea, que de momento te voy ganando :P, porque a nosotros sólo nos
falla cuando la llamada es al exterior, pero en internas nos
funciona... Aunque eso sí, tu tienes UPDATES y nosotros no (sniff!)
Bueno, lo dejamos en tablas... ;)
> CSeq: 102 REFER.
> Max-Forwards: 70.
> Contact: <sip:2...@10.10.0.177:5063>.
> Refer-To: <sip:3...@10.10.0.165?Replaces=9c5dccba-
> c9dbf1e6%4010.10.0.177%3Bfrom-tag%3Db8ea2eaaec3178b6o3%3Bto-tag
> %3Das60e8839a>.
> User-Agent: Cisco/SPA504G-7.4.3.
> Content-Length: 0.
> .
>
> U 10.10.0.165:5060 -> 10.10.0.177:5063
> SIP/2.0 202 Accepted.
> Via: SIP/2.0/UDP
> 10.10.0.177:5063;branch=z9hG4bK-127877ab;received=10.10.0.177.
> From: <sip:2...@10.10.0.177>;tag=27cccb20bc6792cai3.
> To: "100" <sip:1...@10.10.0.165>;tag=as5c51b1ea.
> Call-ID: 11e0dd3543d69a4434f7adac5359d...@10.10.0.165:5060.
> Max-Forwards: 70.
> Contact: <sip:2...@10.10.0.177:5063>.
> Refer-To: <sip:3...@10.10.0.165?Replaces=9c5dccba-
> c9dbf1e6%4010.10.0.177%3Bfrom-tag%3Db8ea2eaaec3178b6o3%3Bto-tag
> %3Das60e8839a>.
> User-Agent: Cisco/SPA504G-7.4.3.
> Content-Length: 0.
> .
>
> U 10.10.0.165:5060 -> 10.10.0.177:5063
> SIP/2.0 202 Accepted.
> Via: SIP/2.0/UDP
> 10.10.0.177:5063;branch=z9hG4bK-127877ab;received=10.10.0.177.
> From: <sip:2...@10.10.0.177>;tag=27cccb20bc6792cai3.
> To: "100" <sip:1...@10.10.0.165>;tag=as5c51b1ea.
> CSeq: 102 REFER.
> Server: Asterisk PBX 1.8.2.3.
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
> INFO, PUBLISH.
> Supported: replaces, timer.
> Contact: <sip:1...@10.10.0.165:5060>.
> Content-Length: 0.
> .
>
> U 10.10.0.165:5060 -> 10.10.0.177:5063
> NOTIFY sip:2...@10.10.0.177:5063 SIP/2.0.
> Via: SIP/2.0/UDP 10.10.0.165:5060;branch=z9hG4bK19772c6b.
> Max-Forwards: 70.
> From: "100" <sip:1...@10.10.0.165>;tag=as5c51b1ea.
> To: <sip:2...@10.10.0.177>;tag=27cccb20bc6792cai3.
> Contact: <sip:1...@10.10.0.165:5060>.
> Call-ID: 11e0dd3543d69a4434f7adac5359d...@10.10.0.165:5060.
> Server: Asterisk PBX 1.8.2.3.
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
> INFO, PUBLISH.
> Supported: replaces, timer.
> Contact: <sip:1...@10.10.0.165:5060>.
> Content-Length: 0.
> .
>
> U 10.10.0.165:5060 -> 10.10.0.177:5063
> NOTIFY sip:2...@10.10.0.177:5063 SIP/2.0.
> Via: SIP/2.0/UDP 10.10.0.165:5060;branch=z9hG4bK19772c6b.
> Max-Forwards: 70.
> From: "100" <sip:1...@10.10.0.165>;tag=as5c51b1ea.
> To: <sip:2...@10.10.0.177>;tag=27cccb20bc6792cai3.
> Contact: <sip:1...@10.10.0.165:5060>.
> CSeq: 103 NOTIFY.
> User-Agent: Asterisk PBX 1.8.2.3.
> Event: refer;id=102.
> Subscription-state: terminated;reason=noresource.
> Content-Type: message/sipfrag;version=2.0.
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
> INFO, PUBLISH.
> Supported: replaces, timer.
> Content-Length: 16.
> .
> SIP/2.0 200 OK.
>
> U 10.10.0.165:5060 -> 10.10.0.177:5063
> BYE sip:2...@10.10.0.177:5063 SIP/2.0.
> Via: SIP/2.0/UDP 10.10.0.165:5060;branch=z9hG4bK234066d9.
> Max-Forwards: 70.
> From: "300" <sip:3...@10.10.0.165>;tag=as60e8839a.
> To: <sip:2...@10.10.0.165>;tag=b8ea2eaaec3178b6o3.
> Call-ID: 9c5dccba-c9dbf...@10.10.0.177.
> User-Agent: Asterisk PBX 1.8.2.3.
> Event: refer;id=102.
> Subscription-state: terminated;reason=noresource.
> Content-Type: message/sipfrag;version=2.0.
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
> INFO, PUBLISH.
> Supported: replaces, timer.
> Content-Length: 16.
> .
> SIP/2.0 200 OK.
>
> U 10.10.0.165:5060 -> 10.10.0.177:5063
> BYE sip:2...@10.10.0.177:5063 SIP/2.0.
> Via: SIP/2.0/UDP 10.10.0.165:5060;branch=z9hG4bK234066d9.
> Max-Forwards: 70.
> From: "300" <sip:3...@10.10.0.165>;tag=as60e8839a.
> To: <sip:2...@10.10.0.165>;tag=b8ea2eaaec3178b6o3.
> CSeq: 102 BYE.
> User-Agent: Asterisk PBX 1.8.2.3.
> Proxy-Authorization: Digest username="200", realm="asterisk",
> algorithm=MD5, uri="10.10.0.165", nonce="",
> response="eda523f9a8f4f7f8e747f003843b0fba".
> X-Asterisk-HangupCause: Normal Clearing.
> X-Asterisk-HangupCauseCode: 16.
> Content-Length: 0.
> .
>
> U 10.10.0.165:5060 -> 10.10.0.142:5064
> UPDATE sip:3...@10.10.0.142:5064 SIP/2.0.
> Via: SIP/2.0/UDP 10.10.0.165:5060;branch=z9hG4bK54fc847d.
> Max-Forwards: 70.
> From: "200" <sip:2...@10.10.0.165>;tag=as4e16ecc6.
> To: <sip:3...@10.10.0.142:5064>;tag=21a4719cbfa891bfi4.
> Contact: <sip:2...@10.10.0.165:5060>.
> Call-ID: 4cb9feb305510fee7c88176c1b161...@10.10.0.165:5060.
> User-Agent: Asterisk PBX 1.8.2.3.
> Proxy-Authorization: Digest username="200", realm="asterisk",
> algorithm=MD5, uri="10.10.0.165", nonce="",
> response="eda523f9a8f4f7f8e747f003843b0fba".
> X-Asterisk-HangupCause: Normal Clearing.
> X-Asterisk-HangupCauseCode: 16.
> Content-Length: 0.
> .
>
> U 10.10.0.165:5060 -> 10.10.0.142:5064
> UPDATE sip:3...@10.10.0.142:5064 SIP/2.0.
> Via: SIP/2.0/UDP 10.10.0.165:5060;branch=z9hG4bK54fc847d.
> Max-Forwards: 70.
> From: "200" <sip:2...@10.10.0.165>;tag=as4e16ecc6.
> To: <sip:3...@10.10.0.142:5064>;tag=21a4719cbfa891bfi4.
> Contact: <sip:2...@10.10.0.165:5060>.
> CSeq: 103 NOTIFY.
> Via: SIP/2.0/UDP 10.10.0.165:5060;branch=z9hG4bK19772c6b.
> Server: Cisco/SPA504G-7.4.3.
> Content-Length: 0.
> .
>
> U 10.10.0.177:5063 -> 10.10.0.165:5060
> SIP/2.0 200 OK.
> To: <sip:2...@10.10.0.165>;tag=b8ea2eaaec3178b6o3.
> From: "300" <sip:3...@10.10.0.165>;tag=as60e8839a.
> Call-ID: 9c5dccba-c9dbf...@10.10.0.177.
> Via: SIP/2.0/UDP 10.10.0.165:5060;branch=z9hG4bK19772c6b.
> Server: Cisco/SPA504G-7.4.3.
> Content-Length: 0.
> .
>
> U 10.10.0.177:5063 -> 10.10.0.165:5060
> SIP/2.0 200 OK.
> To: <sip:2...@10.10.0.165>;tag=b8ea2eaaec3178b6o3.
> From: "300" <sip:3...@10.10.0.165>;tag=as60e8839a.
> CSeq: 102 BYE.
> Via: SIP/2.0/UDP 10.10.0.165:5060;branch=z9hG4bK234066d9.
> Server: Cisco/SPA504G-7.4.3.
> Content-Length: 0.
> .
>
> U 10.10.0.142:5064 -> 10.10.0.165:5060
> SIP/2.0 200 OK.
> To: <sip:3...@10.10.0.142:5064>;tag=21a4719cbfa891bfi4.
> From: "200" <sip:2...@10.10.0.165>;tag=as4e16ecc6.
> Call-ID: 4cb9feb305510fee7c88176c1b161...@10.10.0.165:5060.
> Via: SIP/2.0/UDP 10.10.0.165:5060;branch=z9hG4bK234066d9.
> Server: Cisco/SPA504G-7.4.3.
> Content-Length: 0.
> .
>
> U 10.10.0.142:5064 -> 10.10.0.165:5060
> SIP/2.0 200 OK.
> To: <sip:3...@10.10.0.142:5064>;tag=21a4719cbfa891bfi4.
> From: "200" <sip:2...@10.10.0.165>;tag=as4e16ecc6.
Andoni
Feb 17, 2011, 3:12:05 AM2/17/11
to asterisk-es
Buenos días,
Lo he probado a poner en la sección General y sigo igual... :(
He visto algo (no sé si ya lo has probado) que puede ser interesante
para tu gateway SIP:
;rpid_update = yes ; In certain cases, the only method
by which a connected line
; change may be immediately
transmitted is with a SIP UPDATE request.
; If communicating with another
Asterisk server, and you wish to be able
; transmit such UPDATE messages to it,
then you must enable this option.
; Otherwise, we will have to wait
until we can send a reinvite to
; transmit the information.
Lo he probado a poner en la sección General y sigo igual... :(
He visto algo (no sé si ya lo has probado) que puede ser interesante
para tu gateway SIP:
;rpid_update = yes ; In certain cases, the only method
by which a connected line
; change may be immediately
transmitted is with a SIP UPDATE request.
; If communicating with another
Asterisk server, and you wish to be able
; transmit such UPDATE messages to it,
then you must enable this option.
; Otherwise, we will have to wait
until we can send a reinvite to
; transmit the information.
Saúl Ibarra Corretgé
Feb 17, 2011, 3:20:19 AM2/17/11
to aster...@googlegroups.com
Personalmente no he probado esto del UPDATE, pero os habéis fijado si
en las 'cosas SIP' involucradas la cabecera Allow menciona el UPDATE?
en las 'cosas SIP' involucradas la cabecera Allow menciona el UPDATE?
Si Asterisk recibe un INVITE con una cabecera allow así:
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
No debería mandarle un UPDATE, ya que no lo soporta.
Solo una idea...
--
/Saúl
http://saghul.net | http://sipdoc.net
Andoni
Feb 17, 2011, 3:29:20 AM2/17/11
to asterisk-es
Buenas,
Yo he dado por supuesto que el terminal acepta UPDATEs (yo estoy
trabajando con Spa5xx).
Aquí un INVITE del terminal: (se ve claramente el UPDATE en el allow)
U 10.10.0.167:5063 -> 10.10.0.165:5060
INVITE sip:3...@10.10.0.165 SIP/2.0.
Via: SIP/2.0/UDP 10.10.0.167:5063;branch=z9hG4bK-b228a513.
From: <sip:1...@10.10.0.165>;tag=6ba0ff7845c376cbo3.
To: "300" <sip:3...@10.10.0.165>.
Call-ID: cac5aabc...@10.10.0.167.
CSeq: 101 INVITE.
Max-Forwards: 70.
Contact: <sip:1...@10.10.0.167:5063>.
Expires: 240.
User-Agent: Cisco/SPA504G-7.4.3.
Content-Length: 227.
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER, UPDATE.
Supported: replaces.
Content-Type: application/sdp.
.
v=0.
o=- 76807524 76807524 IN IP4 10.10.0.167.
s=-.
c=IN IP4 10.10.0.167.
t=0 0.
m=audio 16748 RTP/AVP 8 0 9 18.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:9 G722/8000.
a=rtpmap:18 G729a/8000.
a=ptime:30.
a=sendrecv.
Yo he dado por supuesto que el terminal acepta UPDATEs (yo estoy
trabajando con Spa5xx).
Aquí un INVITE del terminal: (se ve claramente el UPDATE en el allow)
U 10.10.0.167:5063 -> 10.10.0.165:5060
INVITE sip:3...@10.10.0.165 SIP/2.0.
Via: SIP/2.0/UDP 10.10.0.167:5063;branch=z9hG4bK-b228a513.
From: <sip:1...@10.10.0.165>;tag=6ba0ff7845c376cbo3.
To: "300" <sip:3...@10.10.0.165>.
Call-ID: cac5aabc...@10.10.0.167.
CSeq: 101 INVITE.
Max-Forwards: 70.
Contact: <sip:1...@10.10.0.167:5063>.
Expires: 240.
User-Agent: Cisco/SPA504G-7.4.3.
Content-Length: 227.
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER, UPDATE.
Supported: replaces.
Content-Type: application/sdp.
.
v=0.
o=- 76807524 76807524 IN IP4 10.10.0.167.
s=-.
c=IN IP4 10.10.0.167.
t=0 0.
m=audio 16748 RTP/AVP 8 0 9 18.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:9 G722/8000.
a=rtpmap:18 G729a/8000.
a=ptime:30.
a=sendrecv.
bauer
Feb 17, 2011, 4:24:54 AM2/17/11
to asterisk-es
Sí, lo del INVITE fue lo primero que miramos en las trazas cuando no
nos aparecían los UPDATES, y aparece como a Andoni.
Nosotros también estamos probando con el SPA504G.
Andoni, anoche me estuve leyendo el sip.conf.sample que viene con la
1.8 y ya me fijé en ese parámetro y en otro (no recuerdo cuál es,
porque me he dejado el documento en casa...).
Espera, un segundo que hago una prueba rápida.............. ¡Nada! con
(rpid_update = yes) el mismo resultado...
Me cagüen la leche!!!
On 17 feb, 09:29, Andoni <andoni.izu...@gmail.com> wrote:
> Buenas,
>
> Yo he dado por supuesto que el terminal acepta UPDATEs (yo estoy
> trabajando con Spa5xx).
>
> Aquí un INVITE del terminal: (se ve claramente el UPDATE en el allow)
>
> U 10.10.0.167:5063 -> 10.10.0.165:5060
> INVITE sip:3...@10.10.0.165 SIP/2.0.
> Via: SIP/2.0/UDP 10.10.0.167:5063;branch=z9hG4bK-b228a513.
> From: <sip:1...@10.10.0.165>;tag=6ba0ff7845c376cbo3.
> To: "300" <sip:3...@10.10.0.165>.
> Call-ID: cac5aabc-69032...@10.10.0.167.
nos aparecían los UPDATES, y aparece como a Andoni.
Nosotros también estamos probando con el SPA504G.
Andoni, anoche me estuve leyendo el sip.conf.sample que viene con la
1.8 y ya me fijé en ese parámetro y en otro (no recuerdo cuál es,
porque me he dejado el documento en casa...).
Espera, un segundo que hago una prueba rápida.............. ¡Nada! con
(rpid_update = yes) el mismo resultado...
Me cagüen la leche!!!
On 17 feb, 09:29, Andoni <andoni.izu...@gmail.com> wrote:
> Buenas,
>
> Yo he dado por supuesto que el terminal acepta UPDATEs (yo estoy
> trabajando con Spa5xx).
>
> Aquí un INVITE del terminal: (se ve claramente el UPDATE en el allow)
>
> U 10.10.0.167:5063 -> 10.10.0.165:5060
> INVITE sip:3...@10.10.0.165 SIP/2.0.
> Via: SIP/2.0/UDP 10.10.0.167:5063;branch=z9hG4bK-b228a513.
> From: <sip:1...@10.10.0.165>;tag=6ba0ff7845c376cbo3.
> To: "300" <sip:3...@10.10.0.165>.
Reply all
Reply to author
Forward
0 new messages