Re: [OpenSER-Users-ES] Re: ¿Por qué algunos clientes SIP cancelan TODAS las branchs al hacer "Decline"? [ACLARADO]

David Santamaria d.highwayman at gmail.com
Mon Sep 10 13:04:37 CEST 2007


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.

-- 
SALUD.

David ( a.k.a. Highwayman)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kamailio.org/pipermail/sr-users-es/attachments/20070910/e334672c/attachment-0002.htm 


More information about the Users-es mailing list