20 Nov
2007
20 Nov
'07
1:21 a.m.
Hola Iñaki,
El Monday 19 November 2007 14:24:44 Jesus Rodriguez
escribió:
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(a)voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------
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.