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.
--
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.