This section describes the steps to end the session established by SIP's. STATUS conversation and dialogue are closely related. When after a session is established by the INVITE, each of a different UAS 1xx or 2xx response will create a dialogue, and when completed the session description request / response (offer / answer) interaction, it creates a session. In other words, every single conversation and dialogue are "related" - a dialogue session is created. If the Initial INVITE had a non-2xx final response, which is also the end of any session (if any) created by this request, and the end of all the dialogue created with this request (if any). Since completing the transaction, a non-2xx final response also prevents further sessions of this INVITE may be created later. BYE request is used to terminate a specific session or attempted session. Here, a particular session is UA other end corresponding to the conversation. When receiving a BYE in conversation, any conversation associated with that dialogue should be terminated. UA NOT send a BYE outside of a dialog. UA requesting party may send a BYE in the established dialogue or early dialogue; the called party can send a BYE in establishing a good dialogue, you can not send a BYE on early dialogs.
However, in a well-established session, the called party UA can not send a BYE request before receiving the corresponding ACK request 2xx response, or can not send a BYE request to the server before the transaction timeout. If no SIP extensions have defined other application layer states associated with the dialog, the BYE also ended the conversation.
In dialogue and conversation, to the non-2xx INVITE final response, makes the use of CANCEL attractive. CANCEL attempts to force a non-INVITE request 2xx response (e.g., 487). Therefore, if UAC want to give up the entire call, it can send a CANCEL. If there 2xx INVITE final response, this means that a UAS received an invitation when CANCEL being processed. UAC can continue to answer establish a session with the 2xx, it can also be used BYE end of this session. (This means that, under normal circumstances, if UAC want to cancel the INVITE, it will issue the CANCEL request, if received the non-2xx final responses, it means CANCEL off, but if received or 2xx response, it shows no CANCEL away, no CANCEL out of it, you can choose to continue to establish a session, or send a BYE to end the session)
In SIP, and not a very good "hangin up" (hook) is defined. It belongs to a common user interface, common details. Typically, when the user hangs up, it means the end of an attempt to establish a session and terminate all sessions have been established. UA for the caller, if the final response is not received initial INVITE request, this may generate a CANCEL request for the initial INVITE request, receive and give each a well-established dialogue after issuing a BYE final response. For the callee's UA, it is very common BYE; Roughly speaking, when the user (since the response ring) hook, will produce a 2xx response, so hanging sends a BYE request after receiving the ACK. This does not mean you can not hang up before receiving the ACK, this is only the expression of a user's phone software need to maintain state for a little while to correct released state. If a UI (User Interface) allowing the user rejects the call without going off-hook, may be 403 (Forbidden) response as INVITE, in this case, we can not send the BYE.
15.1 BYE request to terminate a session
15.1.1 UAC Behavior
BYE request just like any other request within a dialog, as the structure, as described in section 12.
When the BYE request to create a good, UAC core processing section to create a new non--INVITE client transaction, and use it to deal BYE request. UAC must be considered that when a BYE request is sent to the client transaction, session terminated (and therefore stop sending or receiving media streams). If the response is the BYE request 481 (Call / Transaction Does Not Exists) or a 408 (Request Timeout) or BYE they not answer (that is client transaction returns a timeout), UAC must think and dialogue sessions have ended.
15.1.2 UAS behavior
First, the UAS according to the general UAS processing request to be processed BYE request (8.2). UAS core after receiving the BYE request, it first checks for an existing dialog. If a BYE does not match any existing dialog, the UAS should generate a 481 (Call / Transaction Does Not Exists) response, and transmitted to the server transaction.
This rule means that if UAC sends a BYE request is not marked with a tag will be rejected. This is a change of RFC2543, RFC2543 allowed BYE without a tag flag.
UAS core receiving a BYE request, and it was found to match an existing dialog, it must follow the steps 12.2.2 to process the request. Once the processing is completed, UAS should terminate the session (and therefore stop sending and receiving media streams). Only one can choose not to terminate the case is multi-session, multi-party session in allowing other participants to participate in the conversation terminated its session. Whether terminating party session, UAS core MUST generate a 2xx response to the BYE, and must be transmitted by the communication layer server.
UAS must still respond to pending requests received in this conversation. We recommend that a 487 (Request Terminated) to those pending requests to answer.
Reproduced in: https: //www.cnblogs.com/share-everything-i-do/archive/2012/11/06/2757765.html