Aupa, Vale, entendido, digamos que cada cliente SIP rechaza una llamada como le 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". 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. No creo que sea tan trivial, yono he conseguido entenderlo del todo, asi que no me parece tan facil. Yo he preferido añadir algo mas de oscuridad a la situacion.un saludo. -- SALUD. David ( a.k.a. Highwayman)

On Monday 10 September 2007 12:04:37 David Santamaria wrote: 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. -- Raúl Alexis Betancor Santana Dimensión Virtual S.L.