Invite transaction:
When using the UDP transmission protocol to transmit INVITE messages, you must use the hop-by-hop retransmission mechanism to ensure the final transmission of invite. That is, both the user agent UA and the SIP proxy must ensure that invite reach the next hop, when the next hop is received, a temporary response is returned (proxy returns 100 trying, UA returns 100trying and 180 ringing). If the proxy fails to receive the response within the specified time, it will re-Send the invite.
Temporary response (100 ~ 199) it is used to prevent hop-by-hop invite retransmission without end-to-end reliable transmission. That is to say, when the callee returns a 180 response, it will not be re-transmitted if it is lost halfway through the path.
Final response (200 ~ 699) can be ensured to reach the destination they want to go.
Successful response (200 ~ 299) It is reliably transmitted to the caller UA, but it does not use the hop-by-hop retransmission mechanism. Only the caller ua can send an ACK (directly sent to the called UA) for the final successful response. If the successful response is lost midway through the path or the ACK sent by the UA is lost, then, the called party will resend the final response when Ack is not received within the specified time until Ack is confirmed.
Unsuccessful final response (300 ~ 699) uses the same hop-by-hop mechanism as invite. The called party's user agent will continuously re-send an unsuccessful response (to the first hop) until the Ack is received (the proxy can also send an ACK for a non-successful response ).
Cancel transaction:
The cancel transaction and the invite transaction are both Skip-by-Skip transactions, but the processing method is different. When each agent on the path receives the cancel request, it will send a final response to respond (instead of issuing a temporary response ), and send a cancel request in the next hop.