Hola, para controlar el estado de un diálogo se supone se debe usar los Session Timers (RFC 4028) con re-INVITE o UPDATE y tiempos de expiración y tal.
Pero en breves me tendré que comunicar con una Nortel SIP_2_PSTN que comprueba el estado de una llamada con OPTIONS. Mi pregunta es si los dispositivos SIP comunes responden con un 200 OK si reciben un OPTIONS in-dialog, ya que no planeo meter un B2BUA entre OpenSer y el NORTEL.
Gracias.
Hola,
Hola, para controlar el estado de un diálogo se supone se debe usar los Session Timers (RFC 4028) con re-INVITE o UPDATE y tiempos de expiración y tal.
Pero en breves me tendré que comunicar con una Nortel SIP_2_PSTN que comprueba el estado de una llamada con OPTIONS. Mi pregunta es si los dispositivos SIP comunes responden con un 200 OK si reciben un OPTIONS in-dialog, ya que no planeo meter un B2BUA entre OpenSer y el NORTEL.
Toda la familia de Linksys sí responde bien. Asterisk no.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Jueves, 15 de Noviembre de 2007, Jesus Rodriguez escribió:
Hola,
Hola, para controlar el estado de un diálogo se supone se debe usar los Session Timers (RFC 4028) con re-INVITE o UPDATE y tiempos de expiración y tal.
Pero en breves me tendré que comunicar con una Nortel SIP_2_PSTN que comprueba el estado de una llamada con OPTIONS. Mi pregunta es si los dispositivos SIP comunes responden con un 200 OK si reciben un OPTIONS in-dialog, ya que no planeo meter un B2BUA entre OpenSer y el NORTEL.
Toda la familia de Linksys sí responde bien. Asterisk no.
Vaya por dios.
Estoy pensando que voy a testearlo en todo lo SIP que pille. Le haré una llamada desde un tfno y posteriormente le enviaré con SIPp u otra cosa un OPTIONS in-dialog con los parámetros de dicho diálogo.
¿Debe cumplir algo más este OPTIONS referente al Cseq y tal? ¿alguna relación del Cseq respecto del resto de mensajes (por ejemplo el INVITE y ACK inicial?
O mejor, ¿en qué RFC figura esto del OPTIONS in-dialog para monitorizar un diálogo? no recuerdo haberlo visto en el 3261.
Mil gracias.
El Jueves, 15 de Noviembre de 2007, Iñaki Baz Castillo escribió:
El Jueves, 15 de Noviembre de 2007, Jesus Rodriguez escribió:
Hola,
Hola, para controlar el estado de un diálogo se supone se debe usar los Session Timers (RFC 4028) con re-INVITE o UPDATE y tiempos de expiración y tal.
Pero en breves me tendré que comunicar con una Nortel SIP_2_PSTN que comprueba el estado de una llamada con OPTIONS. Mi pregunta es si los dispositivos SIP comunes responden con un 200 OK si reciben un OPTIONS in-dialog, ya que no planeo meter un B2BUA entre OpenSer y el NORTEL.
Toda la familia de Linksys sí responde bien. Asterisk no.
Vaya por dios.
Estoy pensando que voy a testearlo en todo lo SIP que pille. Le haré una llamada desde un tfno y posteriormente le enviaré con SIPp u otra cosa un OPTIONS in-dialog con los parámetros de dicho diálogo.
Vale, he hecho unas cuantas pruebas con un mini-cliente-megabeta SIP en Ruby que pretendo hacer y que de momento sólo envía OPTIONS y MESSAGE y muestra la respuesta.
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.
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).
Conclusión: Asterisk lo hace bien (sobre todo en pedantic mode).
Y también concluyo que no se comprueba el username, sólo el From/To tag y call-id.
Bueno, mejor ¿no? XD
PD: Si que me gustaría saber dónde se explica el uso de OPTIONS in-dialog para monitorización de sesiones.
Saludos.
El Jueves, 15 de Noviembre de 2007, Iñaki Baz Castillo 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).
Conclusión: Asterisk lo hace bien (sobre todo en pedantic mode).
Y también concluyo que no se comprueba el username, sólo el From/To tag y call-id.
Horror, el tan aclamado Ekiga (que me parece una ****) responde siempre 200 OK a un OPTIONS in-dialog, exista o no dicho diálogo. Ya empezamos...
Entonces... si mi esquema es:
Ekiga -> OpenSer -> OpenSer+MediaProxy -> SIP_PSTN
y el gateway SIP_PSTN controla los diálogos con un OPTIONS entonces ya la hemos liado, ¿no?
Bueno, queda la esperanza de que el MediaProxy envíe un BYE cuando detecta que el audio se ha cortado... espero... (al menos esto es lo que se comenta en la escueta doc de CDRTool (OpenSer con siptrace + MediaProxy).
Ay ay... que algo me dice que voy a necesitar un B2BUA en medio, y no sabría qué poner :(
El Jueves, 15 de Noviembre de 2007, Iñaki Baz Castillo escribió:
Horror, el tan aclamado Ekiga (que me parece una ****) responde siempre 200 OK a un OPTIONS in-dialog, exista o no dicho diálogo. Ya empezamos...
Más horror: el WengoPhone también, lo mismo, responde siempre 200 OK aunque no exista el diálogo.
Y encima te manda un Trying a un OPTIONS cuando resulta que el RFC dice claramente que sólo se debe enviar Trying en el INVITE.
En fin...
¿Qué hay de los teléfonos comerciales? Los Linksys ya me ha comentado Jesús que soportan OPTIONS in-dialog para monitorizar sesiones, ¿y los Thomson, Snom...? buff...
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@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
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.
El Sábado, 17 de Noviembre de 2007, Iñaki Baz Castillo escribió:
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.
Bueno, por si os interesa he reportado un bug en Asterisk: http://bugs.digium.com/view.php?id=11264
Al final de todo me he tirado un farol para darle un poco más de "alarma", a ver si no me eh equivocado:
"Nortel and Cisco gateways use those in-dialog OPTIONS to monitorize the status of a dialog, so if Asterisk generates the INVITE but replies with 404 when receiving an in-dialog OPTIONS then the gateway would end the call."
XD
vaya triple que te has tirado!! jeje.
Y lo de los options con twinkle, como no te acordaste? si a mi me lo contaste tu!? jejeje
El 17/11/07, Iñaki Baz Castillo ibc@aliax.net escribió:
El Sábado, 17 de Noviembre de 2007, Iñaki Baz Castillo escribió:
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.
Bueno, por si os interesa he reportado un bug en Asterisk: http://bugs.digium.com/view.php?id=11264
Al final de todo me he tirado un farol para darle un poco más de "alarma", a ver si no me eh equivocado:
"Nortel and Cisco gateways use those in-dialog OPTIONS to monitorize the status of a dialog, so if Asterisk generates the INVITE but replies with 404 when receiving an in-dialog OPTIONS then the gateway would end the call."
XD
-- Iñaki Baz Castillo
Users-es mailing list Users-es@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
El Domingo, 18 de Noviembre de 2007, Saúl Ibarra escribió:
vaya triple que te has tirado!! jeje.
Y lo de los options con twinkle, como no te acordaste? si a mi me lo contaste tu!? jejeje
Sí, sí, pero es distinto:
Con Twinkle si selecionas una línea (una de las dos) sin llamada en curso entonces la opción "Call" -> "Terminal capabilities" envía un OPTIONS al destino que tú elijas, pero un OPTIONS initial request.
Pero lo que descubrí ayer es que si estás en una línea con una llamada en curso, entonces "Call" -> "Terminal capabilities" envía un OPTIONS in-dialog al destino de la conversación. Y lo que justamente yo necesitaba para estas pruebitas era un OPTIONS in-dialog.
;)
El 18/11/07, Iñaki Baz Castillo ibc@aliax.net escribió:
El Domingo, 18 de Noviembre de 2007, Saúl Ibarra escribió:
vaya triple que te has tirado!! jeje.
Y lo de los options con twinkle, como no te acordaste? si a mi me lo contaste tu!? jejeje
Sí, sí, pero es distinto:
Con Twinkle si selecionas una línea (una de las dos) sin llamada en curso entonces la opción "Call" -> "Terminal capabilities" envía un OPTIONS al destino que tú elijas, pero un OPTIONS initial request.
Pero lo que descubrí ayer es que si estás en una línea con una llamada en curso, entonces "Call" -> "Terminal capabilities" envía un OPTIONS in-dialog al destino de la conversación. Y lo que justamente yo necesitaba para estas pruebitas era un OPTIONS in-dialog.
Ups, no rcuerdo como lo hice... pero creo que probé de las 2 maneras, aunque no me dí cuenta de lo que implicaba jejeje.
;)
-- Iñaki Baz Castillo
Users-es mailing list Users-es@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
Hola,
El Jueves, 15 de Noviembre de 2007, Jesus Rodriguez escribió:
Hola,
Hola, para controlar el estado de un diálogo se supone se debe usar los Session Timers (RFC 4028) con re-INVITE o UPDATE y tiempos de expiración y tal.
Pero en breves me tendré que comunicar con una Nortel SIP_2_PSTN que comprueba el estado de una llamada con OPTIONS. Mi pregunta es si los dispositivos SIP comunes responden con un 200 OK si reciben un OPTIONS in-dialog, ya que no planeo meter un B2BUA entre OpenSer y el NORTEL.
Toda la familia de Linksys sí responde bien. Asterisk no.
Vaya por dios.
Estoy pensando que voy a testearlo en todo lo SIP que pille. Le haré una llamada desde un tfno y posteriormente le enviaré con SIPp u otra cosa un OPTIONS in-dialog con los parámetros de dicho diálogo.
¿Debe cumplir algo más este OPTIONS referente al Cseq y tal? ¿alguna relación del Cseq respecto del resto de mensajes (por ejemplo el INVITE y ACK inicial?
rfc://3261/12.2.1.1 :-)
O mejor, ¿en qué RFC figura esto del OPTIONS in-dialog para monitorizar un diálogo? no recuerdo haberlo visto en el 3261.
Que yo sepa no hay ninguna... digamos que se debe a una interpretación (con cumplimiento estricto) de lo que deja hacer la rfc3261.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Jueves, 15 de Noviembre de 2007, Jesus Rodriguez escribió:
¿Debe cumplir algo más este OPTIONS referente al Cseq y tal? ¿alguna relación del Cseq respecto del resto de mensajes (por ejemplo el INVITE y ACK inicial?
rfc://3261/12.2.1.1 :-)
"Requests within a dialog MUST contain strictly monotonically increasing and contiguous CSeq sequence numbers (increasing-by-one) in each direction"
OK :)
O mejor, ¿en qué RFC figura esto del OPTIONS in-dialog para monitorizar un diálogo? no recuerdo haberlo visto en el 3261.
Que yo sepa no hay ninguna... digamos que se debe a una interpretación (con cumplimiento estricto) de lo que deja hacer la rfc3261.
¿Y este "estándar de facto" es tal como para que gateways SIP_PSTN de prestigiosas marcas lo implementen como único mecanismo para monitorizar estado de diálogos? miedo tengo.
Gracias.
Hola,
El Jueves, 15 de Noviembre de 2007, Jesus Rodriguez escribió:
¿Debe cumplir algo más este OPTIONS referente al Cseq y tal? ¿alguna relación del Cseq respecto del resto de mensajes (por ejemplo el INVITE y ACK inicial?
rfc://3261/12.2.1.1 :-)
"Requests within a dialog MUST contain strictly monotonically increasing and contiguous CSeq sequence numbers (increasing-by-one) in each direction"
OK :)
O mejor, ¿en qué RFC figura esto del OPTIONS in-dialog para monitorizar un diálogo? no recuerdo haberlo visto en el 3261.
Que yo sepa no hay ninguna... digamos que se debe a una interpretación (con cumplimiento estricto) de lo que deja hacer la rfc3261.
¿Y este "estándar de facto" es tal como para que gateways SIP_PSTN de prestigiosas marcas lo implementen como único mecanismo para monitorizar estado de diálogos? miedo tengo.
La rfc3261 hace varias referencias al OPTIONS in-dialog para saber si existe un diálogo o no así que supongo que alguien decidió implementarlo y los demás han ido detrás.
Por cierto, los gateways/routers Cisco también lo soportan.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Viernes, 16 de Noviembre de 2007, Jesus Rodriguez escribió:
O mejor, ¿en qué RFC figura esto del OPTIONS in-dialog para monitorizar un diálogo? no recuerdo haberlo visto en el 3261.
Que yo sepa no hay ninguna... digamos que se debe a una interpretación (con cumplimiento estricto) de lo que deja hacer la rfc3261.
¿Y este "estándar de facto" es tal como para que gateways SIP_PSTN de prestigiosas marcas lo implementen como único mecanismo para monitorizar estado de diálogos? miedo tengo.
La rfc3261 hace varias referencias al OPTIONS in-dialog para saber si existe un diálogo o no así que supongo que alguien decidió implementarlo y los demás han ido detrás.
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...
Por cierto, los gateways/routers Cisco también lo soportan.
Con "soportar" entiendo que son ellos (los Cisco) los que envían el OPTIONS in-dialog para monitorizar diálogos, ¿no?
Gracias.
Hola Iñaki,
El Viernes, 16 de Noviembre de 2007, Jesus Rodriguez escribió:
O mejor, ¿en qué RFC figura esto del OPTIONS in-dialog para monitorizar un diálogo? no recuerdo haberlo visto en el 3261.
Que yo sepa no hay ninguna... digamos que se debe a una interpretación (con cumplimiento estricto) de lo que deja hacer la rfc3261.
¿Y este "estándar de facto" es tal como para que gateways SIP_PSTN de prestigiosas marcas lo implementen como único mecanismo para monitorizar estado de diálogos? miedo tengo.
La rfc3261 hace varias referencias al OPTIONS in-dialog para saber si existe un diálogo o no así que supongo que alguien decidió implementarlo y los demás han ido detrás.
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.
Por cierto, los gateways/routers Cisco también lo soportan.
Con "soportar" entiendo que son ellos (los Cisco) los que envían el OPTIONS in-dialog para monitorizar diálogos, ¿no?
Soporta los dos, tanto enviarlos como recibirlos.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
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. -----------------------------------
Voy a tratar de revisar el RFC3261 donde habla del comportamiento "alternativo" del in-dialog OPTION, pero si pudieses ayudarme un poco indicándome dónde se especifica (tengo un peso muy pesado delante XD).
Por cierto, el reporte es éste: http://bugs.digium.com/view.php?id=11264
Muchas gracias por adelantado.
El Monday 19 November 2007 16:58:13 Iñaki Baz Castillo escribió:
Voy a tratar de revisar el RFC3261 donde habla del comportamiento "alternativo" del in-dialog OPTION, pero si pudieses ayudarme un poco indicándome dónde se especifica (tengo un peso muy pesado delante XD).
Yo no lo veo nada claro:
¿Se debe responder a un OPTIONS in-dialog con 200 OK ó 404/481 dependiendo de si el diálogo existe o no en vez de tratarlo como un OPTIONS initial request en el que se responde 200 OK si el usuario existe y acepta llamadas o 404/486 si no existe o no acepta llamadas?
**** A favor (y con pinzas):
11 Querying for Capabilities
[...] An OPTIONS request MAY be sent as part of an established dialog to query the peer on capabilities that may be utilized later in the dialog.
11.1 Construction of OPTIONS Request
[...] The response to an OPTIONS request is assumed to be scoped to the Request-URI in the original request. However, only when an OPTIONS is sent as part of an established dialog is it guaranteed that future requests will be received by the server that generated the OPTIONS response.
**** En contra:
11 Querying for Capabilities
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.
12 Dialogs
12.2.2 UAS Behavior
[...] Requests that do not change in any way the state of a dialog may be received within a dialog (for example, an OPTIONS request). They are processed as if they had been received outside the dialog.
Me parece que voy a tener que agachar la cabeza delante de Ollew...
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@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Martes, 20 de Noviembre de 2007, Jesus Rodriguez escribió:
Como bien pone Olle, el punto 11.2 dice que los OPTIONS se responderán como si el método fuese un INVITE.
Mil gracias por tu aporte, era demasiado para mí "discutir" con alguien como Ollew en un hilo tan largo ;)
Además tu comparación con el re-INVITE me ha inspirado una cosa que era evidente y en la que no había caído antes:
Durante el re-INVITE el username del RURI **NO** es comprobado por Asterisk (en cuanto a que aunque B no pueda llamar a A, B sí que puede enviarle un re-INVITE).
En cambio eso mismo no ocurre para un OPTIONS in-dialog (se mira primero si B puede llamar a A y como no puede entonces devuelve 404 sin mirar siquiera si el diálogo existe).
Creo que esto es inconsistente y así lo he planteado en mi último comentario (tras el tuyo).
Lo dicho, mil gracias Jesús por tu inestimable ayuda.
El Tuesday 20 November 2007 00:52:21 Iñaki Baz Castillo escribió:
El Martes, 20 de Noviembre de 2007, Jesus Rodriguez escribió:
Como bien pone Olle, el punto 11.2 dice que los OPTIONS se responderán como si el método fuese un INVITE.
Mil gracias por tu aporte, era demasiado para mí "discutir" con alguien como Ollew en un hilo tan largo ;)
Vaya, parece que el señor Olle se ha relajado un poquito en el hilo y dice que va a comprobar la implementación del OPTIONS in-dialog en otros sistemas. :)
Ahora estoy en otro reporte hablando con él sugiriendo que Asterisk se digne a mostrar el From original en llamadas con entre dos canales SIP (ahora sólo respeta el username, pero se inventa el dominio, así que si recibe una llamada de 215@dominio_externo_A y otra de 215@dominio_externo_B, el llamado sólo ve 215@IP_Asterisk. Toma ya!
Bueno, volvamos a OpenSer ;)
Hola Iñaki,
El Tuesday 20 November 2007 00:52:21 Iñaki Baz Castillo escribió:
El Martes, 20 de Noviembre de 2007, Jesus Rodriguez escribió:
Como bien pone Olle, el punto 11.2 dice que los OPTIONS se responderán como si el método fuese un INVITE.
Mil gracias por tu aporte, era demasiado para mí "discutir" con alguien como Ollew en un hilo tan largo ;)
Vaya, parece que el señor Olle se ha relajado un poquito en el hilo y dice que va a comprobar la implementación del OPTIONS in-dialog en otros sistemas. :)
Pués puede encontrarse cualquier cosa!! :)
Ahora estoy en otro reporte hablando con él sugiriendo que Asterisk se digne a mostrar el From original en llamadas con entre dos canales SIP (ahora sólo respeta el username, pero se inventa el dominio, así que si recibe una llamada de 215@dominio_externo_A y otra de 215@dominio_externo_B, el llamado sólo ve 215@IP_Asterisk. Toma ya!
Sí, ya he visto el thread en la lista de asterisk... teniendo en cuenta que asterisk hace de b2bua no es extraño que no respete el domino original... y no sigo más :)
P.D. Creo que sigues enviando los mails a users-es@openser.org y deberías usar users-es@lists.openser.org
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Jueves, 22 de Noviembre de 2007, Jesus Rodriguez escribió:
P.D. Creo que sigues enviando los mails a users-es@openser.org y deberías usar users-es@lists.openser.org
Cierto, y eso que sí lo he corregido hace tiempo en la otra lista.
Gracias por avisarme.
El Martes, 20 de Noviembre de 2007, Jesus Rodriguez escribió:
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.
"UAs wishing to support this capability must take into consideration some issues such as choosing monotonically increasing CSeq sequence numbers even across reboots"
Asterisk no hace eso pero ni de coña. De hecho creo que ya me conozco hasta los 4ó 5 valores CSeq que usa Asterisk XD
sr-users-es@lists.kamailio.org
-
Iñaki Baz Castillo -
Iñaki Baz Castillo -
Jesus Rodriguez -
Saúl Ibarra