Aupa,<br><br><div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Vale, entendido, digamos que cada cliente SIP rechaza una llamada como le sale
<br>de los c******:</blockquote><div><br>Vale, segun el rfc la cosa seria asi:<br><br>"<br><pre><a href="http://13.3.1.3" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">13.3.1.3</a> The INVITE is Rejected
<br><br> A common scenario occurs when the callee is currently not willing or<br><br> able to take additional calls at this end system. A 486 (Busy Here)<br> SHOULD be returned in such a scenario. If the UAS knows that no
<br> other end system will be able to accept this call, a 600 (Busy<br> Everywhere) response SHOULD be sent instead. However, it is unlikely<br><br> that a UAS will be able to know this in general, and thus this<br>
response will not usually be used. The response is passed to the<br> INVITE server transaction, which will deal with its retransmissions.<br><br>
A UAS rejecting an offer contained in an INVITE SHOULD return a 488<br> (Not Acceptable Here) response. Such a response SHOULD include a<br> Warning header field value explaining why the offer was rejected."
<br>
</pre></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">- X-Lite envía "486 Busy Here".<br>- SJphoneenvía "480 Temporarily Unavailable".
<br>- Twinkle y Asterisk envía "603 Decline".</blockquote><div><br>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:
<br><br><pre>21.4.26 488 Not Acceptable Here<br><br> The response has the same meaning as 606 (Not Acceptable), but only<br> applies to the specific resource addressed by the Request-URI and the<br> request may succeed elsewhere.
<br><br> A message body containing a description of media capabilities MAY be<br> present in the response, which is formatted according to the Accept<br> header field in the INVITE (or application/sdp if not present), the
<br> same as a message body in a 200 (OK) response to an OPTIONS request.</pre>Es decir, segun esto es como mandar un 606, solo que en este caso sabes que otro puede contestar, no?<br><br><pre>21.6.4 606 Not Acceptable<br>
<br> The user's agent was contacted successfully but some aspects of the<br> session description such as the requested media, bandwidth, or<br> addressing style were not acceptable.<br><br> A 606 (Not Acceptable) response means that the user wishes to
<br> communicate, but cannot adequately support the session described.<br> The 606 (Not Acceptable) response MAY contain a list of reasons in a<br> Warning header field describing why the session described cannot be
<br> supported. Warning reason codes are listed in Section 20.43.<br><br> A message body containing a description of media capabilities MAY be<br> present in the response, which is formatted according to the Accept
<br> header field in the INVITE (or application/sdp if not present), the<br> same as a message body in a 200 (OK) response to an OPTIONS request.<br><br> It is hoped that negotiation will not frequently be needed, and when
<br> a new user is being invited to join an already existing conference,<br> negotiation may not be possible. It is up to the invitation<br> initiator to decide whether or not to act on a 606 (Not Acceptable)<br> response.
<br><br> This status response is returned only if the client knows that no<br> other end point will answer the request.<br></pre><br>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...
<br><br></div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">En los 2 primeros casos OpenSerno genera un CANCEL al resto de branchs. Parece<br>que tiene sentido, lo que no tiene sentido es la ensalada de anarquía en el
<br>comportamiento de cada cliente SIP para algo tan sencillo como rechazar una<br>llamada :(</blockquote><div><br>No creo que sea tan trivial, yono he conseguido entenderlo del todo, asi que no me parece tan facil.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Gracias por cualquier aclaración.</blockquote><div><br>Yo he preferido añadir algo mas de oscuridad a la
situacion.un saludo.<br clear="all"></div></div><br>-- <br>SALUD.<br><br>David (
a.k.a. Highwayman)