[OpenSER-Users-ES] ¿Por qué algunos clientes SIP cancelan TODAS las branchs al hacer "Decline"?
Hola, llevo tiempo mosqueado con este tema.
Supongamos dos casos:
A) Una misma cuenta SIP se registra desde varios softphones.
B) Para una cuenta SIP existe en Openser un forwarding paralelo a otra cuenta.
Pues bien, en ambos casos, y dependiendo siempre del cliente SIP, cuando suenan los distintos teléfonos si se rechaza la llamada desde uno de ellos se cancelan TODAS las branchs restantes. ¿¿¿POR QUE???
Insisto en que sólo ocurre con algunos (incluído Twinkle, snif...).
Me explico mejor:
- Una cuenta SIP está registrada desde un Twinkle, un X-Lite y un SJphone (y un Asterisk también).
- Alguien llama a esa cuenta SIP y empiezan a sonar todos los tfnos anteriores.
- Si se cancela la llamada desde X-Lite o SJphone entonces el resto siguen sonando (como entiendo debe ser).
- Si se cancela la llamada desde Twinkle o Asterisk entonces se cancelan el resto de branchs. ?¿?¿?¿?¿?
Estoy peleándome ahora con las capturas SIP pero parece complejo en este caso...
Gracias por cualquier aclaración.
El Domingo, 9 de Septiembre de 2007, Iñaki Baz Castillo escribió:
- Una cuenta SIP está registrada desde un Twinkle, un X-Lite y un SJphone
(y un Asterisk también).
- Alguien llama a esa cuenta SIP y empiezan a sonar todos los tfnos
anteriores.
- Si se cancela la llamada desde X-Lite o SJphone entonces el resto siguen
sonando (como entiendo debe ser).
- Si se cancela la llamada desde Twinkle o Asterisk entonces se cancelan el
resto de branchs. ?¿?¿?¿?¿?
Vale, entendido, digamos que cada cliente SIP rechaza una llamada como le sale de los c******:
- X-Lite envía "486 Busy Here". - SJphoneenvía "480 Temporarily Unavailable". - Twinkle y Asterisk envía "603 Decline".
En los 2 primeros casos OpenSerno genera un CANCEL al resto de branchs. Parece que tiene sentido, lo que no tiene sentido es la ensalada de anarquía en el comportamiento de cada cliente SIP para algo tan sencillo como rechazar una llamada :(
Estoy peleándome ahora con las capturas SIP pero parece complejo en este caso...
Gracias por cualquier aclaración.
Aupa,
Vale, entendido, digamos que cada cliente SIP rechaza una llamada como le
sale de los c******:
Vale, segun el rfc la cosa seria asi:
"
13.3.1.3 The INVITE is Rejected
A common scenario occurs when the callee is currently not willing or
able to take additional calls at this end system. A 486 (Busy Here) SHOULD be returned in such a scenario. If the UAS knows that no other end system will be able to accept this call, a 600 (Busy Everywhere) response SHOULD be sent instead. However, it is unlikely
that a UAS will be able to know this in general, and thus this response will not usually be used. The response is passed to the INVITE server transaction, which will deal with its retransmissions.
A UAS rejecting an offer contained in an INVITE SHOULD return a 488 (Not Acceptable Here) response. Such a response SHOULD include a Warning header field value explaining why the offer was rejected."
- X-Lite envía "486 Busy Here".
- SJphoneenvía "480 Temporarily Unavailable".
- Twinkle y Asterisk envía "603 Decline".
Con lo que ninguno se comporta correctamente, ya que deberian de comprobar si hay algun otro terminal SIP en las cabeceras del mensaje y mandar un 488 Not Acceptable Here, no? Pero mis dudas llegan en este punto:
21.4.26 488 Not Acceptable Here
The response has the same meaning as 606 (Not Acceptable), but only applies to the specific resource addressed by the Request-URI and the request may succeed elsewhere.
A message body containing a description of media capabilities MAY be present in the response, which is formatted according to the Accept header field in the INVITE (or application/sdp if not present), the same as a message body in a 200 (OK) response to an OPTIONS request.
Es decir, segun esto es como mandar un 606, solo que en este caso sabes que otro puede contestar, no?
21.6.4 606 Not Acceptable
The user's agent was contacted successfully but some aspects of the session description such as the requested media, bandwidth, or addressing style were not acceptable.
A 606 (Not Acceptable) response means that the user wishes to communicate, but cannot adequately support the session described. The 606 (Not Acceptable) response MAY contain a list of reasons in a Warning header field describing why the session described cannot be supported. Warning reason codes are listed in Section 20.43.
A message body containing a description of media capabilities MAY be present in the response, which is formatted according to the Accept header field in the INVITE (or application/sdp if not present), the same as a message body in a 200 (OK) response to an OPTIONS request.
It is hoped that negotiation will not frequently be needed, and when a new user is being invited to join an already existing conference, negotiation may not be possible. It is up to the invitation initiator to decide whether or not to act on a 606 (Not Acceptable) response.
This status response is returned only if the client knows that no other end point will answer the request.
Pero en esta no se da a entender como que hay algo que no va bien, y no que ha sido el usuario quien no ha queirod comunicarse, no? Creo que hay algo que se me esta escapando...
En los 2 primeros casos OpenSerno genera un CANCEL al resto de branchs.
Parece que tiene sentido, lo que no tiene sentido es la ensalada de anarquía en el comportamiento de cada cliente SIP para algo tan sencillo como rechazar una llamada :(
No creo que sea tan trivial, yono he conseguido entenderlo del todo, asi que no me parece tan facil.
Gracias por cualquier aclaración.
Yo he preferido añadir algo mas de oscuridad a la situacion.un saludo.
El Monday 10 September 2007 13:04:37 David Santamaria escribió:
Aupa,
Vale, entendido, digamos que cada cliente SIP rechaza una llamada como le
sale de los c******:
Vale, segun el rfc la cosa seria asi:
"
13.3.1.3 The INVITE is Rejected
A common scenario occurs when the callee is currently not willing or
able to take additional calls at this end system. A 486 (Busy Here) SHOULD be returned in such a scenario. If the UAS knows that no other end system will be able to accept this call, a 600 (Busy Everywhere) response SHOULD be sent instead. However, it is unlikely
Con lo que ninguno se comporta correctamente,
ya que deberian de comprobar si hay algun otro terminal SIP en las cabeceras del mensaje
Ops, eso no es posible. En las cabeceras nunca figuran las otras branches que haya podido crear el proxy. Es decir, si un usuario SIP está registrado en varios teléfonos y se le llama, cada teléfono NO sabe que están sonando otros.
y mandar un 488 Not Acceptable Here, no? Pero mis dudas llegan en este punto:
Un 488 Not Acceptable es maś bien relacionado con el contenido de la invitación, por ejemplo si le envías un SDP con un único códec posible que el receptor no soporta, o un "content-type" inexistente o no soportado... Es decir, es más tema de negociación previa a que el teléfono llegue a sonar.
21.6.4 606 Not Acceptable
Pero en esta no se da a entender como que hay algo que no va bien, y no que ha sido el usuario quien no ha queirod comunicarse, no? Creo que hay algo que se me esta escapando...
Sí, eso es. 606 y 488 indican fallos de negociación, por lo que el usuario ni se entera de esa llamada.
También he leído en otra lista (la de Twinkle) una realidad curiosa: ¿Qué sentido tiene que un teléfono después de sonar indique que está ocupado (486 Busy Here)?
Por eso me pregunto si no podría tener más sentido responder con un:
-- Respuestas de error de cliente (no paran otros branches): * 410 Gone (ni idea de para qué es) * 480 Temporarily not available
-- Respuestas de error general (hacen que el proxy SIP cancele el resto de branches): * 600 Busy Everywhere (pero estamos en las mismas) * 603 Decline
En fin, el mundo feliz de SIP... XD
On Monday 10 September 2007 12:04:37 David Santamaria wrote:
Aupa,
Vale, entendido, digamos que cada cliente SIP rechaza una llamada como le
sale de los c******:
Vale, segun el rfc la cosa seria asi:
"
13.3.1.3 The INVITE is Rejected
A common scenario occurs when the callee is currently not willing or
able to take additional calls at this end system. A 486 (Busy Here) SHOULD be returned in such a scenario. If the UAS knows that no other end system will be able to accept this call, a 600 (Busy Everywhere) response SHOULD be sent instead. However, it is unlikely
that a UAS will be able to know this in general, and thus this response will not usually be used. The response is passed to the INVITE server transaction, which will deal with its retransmissions.
A UAS rejecting an offer contained in an INVITE SHOULD return a 488 (Not Acceptable Here) response. Such a response SHOULD include a Warning header field value explaining why the offer was rejected."
- X-Lite envía "486 Busy Here".
- SJphoneenvía "480 Temporarily Unavailable".
- Twinkle y Asterisk envía "603 Decline".
Con lo que ninguno se comporta correctamente, ya que deberian de comprobar si hay algun otro terminal SIP en las cabeceras del mensaje y mandar un 488 Not Acceptable Here, no? Pero mis dudas llegan en este punto:
Te confundes, un UAC no tiene ni zorra idea de "quienes más" han recibido el INVITE, es el UAS quien lo sabe.
La cosa iría:
UAS (OpenSer) --- Branch 1 -> UAC1 --- Branch 2 -> UAC2 .... --- Branch n -> UACn
Si OpenSer envía el INVITE a los diferentes UACn y uno de ellos responde con un 48x, el comportamiento debería ser de cerrar ese branch y seguir con los demás. SOLO cuando todos los branch hayan devuelto 48x, se le puede enviar al "originador" un 600.
Lo que pasa es que eso no ocurre, se suele optar por un comportamiento parecido a un ring-group, en el que si uno rechaza, se corta en todos.
El Monday 10 September 2007 13:54:41 Raúl Alexis Betancor Santana escribió:
UAS (OpenSer) --- Branch 1 -> UAC1 --- Branch 2 -> UAC2 .... --- Branch n -> UACn
Si OpenSer envía el INVITE a los diferentes UACn y uno de ellos responde con un 48x, el comportamiento debería ser de cerrar ese branch y seguir con los demás. SOLO cuando todos los branch hayan devuelto 48x, se le puede enviar al "originador" un 600.
Lo que pasa es que eso no ocurre, se suele optar por un comportamiento parecido a un ring-group, en el que si uno rechaza, se corta en todos.
Por añadir una cosa: la decisión de cortar todos los branches la realiza el Proxy SIP en dos casos:
- Recibe un 4XX de cada UAC llamado. - Recibe un 6XX de algún UAC llamado.
sr-users-es@lists.kamailio.org
-
David Santamaria -
Iñaki Baz Castillo -
Iñaki Baz Castillo -
Raúl Alexis Betancor Santana