[OpenSER-Users-ES] Comprobación de diálogo con "OPTIONS - 200 OK"

[Jesus Rodriguez]

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 at voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------