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

[Jesus Rodriguez]

Hola Iñaki,


> El Monday 19 November 2007 14:24:44 Jesus Rodriguez escribió:
>>> Lo leeré más, pero he leído que un OPTIONS in-dialog se puede
>>> comportar como
>>> un fuera de diálogo, lo que significaría que devuelve 200 salvo que
>>> esté
>>> ocupado (480 de DND y tal), de hecho he probado el Ekiga, WengoPhone
>>> y el
>>> XLite versión 2 (de Linux) y no hacen caso del OPTIONS in-dialog,
>>> devuelven
>>> 200  :(
>>>
>>> Vamos, que asumo que es una interpretación algo "ambigua" que
>>> algunos la ven
>>> así y otros no... ay estos del IEFT...
>>
>> Creo que, aunque diseminado a trozos por la rfc3261 queda más o menos
>> claro el comportamiento que debería tener.
>
>
> Jesús, te pido ayuda sobre este tema, ya que estoy en plena  
> discusión con Olle
> Johannson en un reporte sobre el in-dialog OPTIONS en Asterisk, y al  
> final me
> ha salido con esto:
>
>
> -----------------------------------
> Show me an IETF spec that says that we should answer on dialog  
> status and
> nothing else if the OPTION is sent in-dialog.
>
> From RFC3261:
>
> 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.
> An OPTIONS request received within a dialog generates a 200 (OK)  
> response that
> is identical to one constructed outside a dialog and does not have  
> any impact
> on the dialog.
>
>
> This says very clearly that OPTIONS outside and inside of a dialog  
> should be
> treated exactly the same way.
> -----------------------------------


Como bien pone Olle, el punto 11.2 dice que los OPTIONS se responderán  
como si el método fuese un INVITE. En ese caso, como el OPTIONS tiene  
un To tag, si el diálogo  al que hace referencia ese tag no existe, el  
UAS debería responder con un "481 Call/Transaction Does Not Exist" tal  
y como indica el punto 21.4.19 y como se haría para un INVITE:

21.4.19 481 Call/Transaction Does Not Exist
    This status indicates that the UAS received a request that does not
    match any existing dialog or transaction.


Además, el punto 12.2.2 UAS Behavior (requests within a dialog) dice  
que:

If the UAS wishes to reject the request because it does not wish to
    recreate the dialog, it MUST respond to the request with a 481
    (Call/Transaction Does Not Exist) status code and pass that to the
    server transaction.


El párrafo anterior a este es interesante ya que comenta la  
posibilidad de aceptar una request para un diálogo inexistente pero  
pone una serie de condiciones que estoy seguro que asterisk no tiene.

Espero que te sirva.

P.D. Al final me he decidido y he contestado más o menos lo mismo que  
te pongo aquí en el bug del mantis de Digium.


Saludos
JesusR.

------------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr at voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------