Hola,
El Jueves, 15 de Noviembre de 2007, Iñaki Baz Castillo
escribió:
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.
Pues lo he comprobado ahora enviando el OPTIONS a Twinkle (super RFC
compatible) y concluyo que el 481 es muy válido (es lo que devuelve
Twinkle
si no existe el diálogo).
No lo tengo claro... he leido por encima el punto 12.2.2 de la
rfc3261... de ahí me he ido al 8.2 y de este al 11.2 que dice:
11.2 Processing of OPTIONS Request
The response to an OPTIONS is constructed using the standard rules
for a SIP response as discussed in Section 8.2.6. The response code
chosen MUST be the same that would have been chosen had the request
been an INVITE. That is, a 200 (OK) would be returned if the UAS is
ready to accept a call, a 486 (Busy Here) would be returned if the
UAS is busy, etc. This allows an OPTIONS request to be used to
determine the basic state of a UAS, which can be an indication of
whether the UAS will accept an INVITE request.
Y de momento ahí me he quedado... a estas horas no doy más :)
Saludos
JesusR.
------------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr(a)voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------