16 Nov
2007
16 Nov
'07
7 a.m.
El Jueves, 15 de Noviembre de 2007, Iñaki Baz Castillo escribió:
El Jueves, 15 de Noviembre de 2007, Jesus Rodriguez
escribió:
Vale, he hecho unas cuantas pruebas con un mini-cliente-megabeta SIP en Ruby
que pretendo hacer y que de momento sólo envía OPTIONS y MESSAGE y muestra la
respuesta.
He llamado desde Twinkle a Asterisk, apunto los tags y call-id de la llamada y
durante el diálogo envío un OPTIONS a Asterisk. Los resultados son divertidos
(una autentica ensalada de despropósitos, pero creo que de chiripa pueden
ser "válidos").
Asterisk 1.4.13
1º caso: pedantic=no (Asterisk sólo comprueba el call-id pero no los tags)
------------
a) OPTIONS -> 200 OK (bien!)
b) OPTIONS cambiando RURI username:
c.1) la extensión existe -> 200 OK (ainsss)
c.2) la extensión no existe -> 404
c) OPTIONS cambiando from/to tag -> 200 OK (bueno...)
d) OPTIONS cambiando call-id -> 404 (bien!)
2º caso: pedantic=yes (Asterisk comprueba el call-id y tags)
------------
a) OPTIONS -> 200 OK (bien!)
b) OPTIONS cambiando RURI username:
c.1) la extensión existe -> 200 OK (ainsss)
c.2) la extensión no existe -> 404
c) OPTIONS cambiando from/to tag -> 481 Transaction Does Not Exist (opss...)
d) OPTIONS cambiando call-id -> 481 Transaction Does Not Exist (la cagamos...)
Bueno, yo ya sabía que el modo pedantic funciona muy mal, trata de ser más RFC
pero la lía gorda pues siempre da por hecho que habla con un UAS y si hay un
OpenSer por medio no da una.
Pero el caso es que si ponemos modo pedantic=no entonces sí que podría
funcionar (a tenor de los resultados) el tema del OPTIONS in-dialog, ¿no?
(casi de casualidad, pues no comprueba el RURI, sólo el call-id, pero
bueno...).
¿Qué opinas?
Voy a reportar ahora mismo a Digium que Asterisk se comporta mal en modo
pedantic en cuanto a que devuelve 481 en vez de 404 para un OPTIONS
in-dialog. ¿Podrías por favor confirmarme que sólo es válido el 404 y no el
481? Mil gracias.
--
Iñaki Baz Castillo
Hola,
Vaya por dios.
Estoy pensando que voy a testearlo en todo lo SIP que pille. Le haré una
llamada desde un tfno y posteriormente le enviaré con SIPp u otra cosa un
OPTIONS in-dialog con los parámetros de dicho diálogo. Hola, para controlar el estado de un diálogo se
supone se debe usar
los
Session Timers (RFC 4028) con re-INVITE o UPDATE y tiempos de
expiración y
tal.
Pero en breves me tendré que comunicar con una Nortel SIP_2_PSTN que
comprueba
el estado de una llamada con OPTIONS. Mi pregunta es si los
dispositivos SIP
comunes responden con un 200 OK si reciben un OPTIONS in-dialog, ya
que no
planeo meter un B2BUA entre OpenSer y el NORTEL.
Toda la familia de Linksys sí responde bien. Asterisk no.