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."
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...