17 Nov
2007
17 Nov
'07
9:26 p.m.
El Viernes, 16 de Noviembre de 2007, Jesus Rodriguez escribió:
Pero esa es la definición del OPTIONS fuera de diálogo, no la de in-dialog,
¿no? :)
PD: El otro día haciendo frikadas en Ruby para mandar un OPTIONS in-dialog y
resulta que el ****maravilloso**** Twinkle te permite enviar un OPTIONS
in-dialog:
- Estando en una conversación.
- Menú "Call" -> "Terminal capabilities"
y ya está ;)
Además gracias a él he descubierto que efectivamente Asterisk NOOOOOO responde
bien a los OPTIONS in-dialog:
Cuando yo lo probé con mi cosilla en Ruby enviaba como username la extensión
de Asterisk marcarda en el INVITE inicial, o sea, usaba esa extensión como
username en el OPTIONS in-dialog.
Pero claro, lo que tnego que poner es "asterisk@IP" que es el Contact que
devuelve Asterisk.
Twinkle lo hace bien. Entonces si le envías a Asterisk un OPTIONS in-dialog
con el username del Contact recibido (como debe ser) entonces devuelve 404
(ya que no existe una extensión llamada "asterisk").
En fin........ qué mal.
--
Iñaki Baz Castillo
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 :)