El Viernes, 16 de Noviembre de 2007, Jesus Rodriguez escribió:
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 :)
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.