This article is transferred from: https://blog.csdn.net/yunlianglinfeng/article/details/81477069
From:
If there is no Contact or Record-Route header field in a SIP message, the callee will generate subsequent Requests based on the From header field. For example: If Alice makes a call to Bob, the content of the From header field is From:Alice<sip:[email protected]>. Then Bob will use sip:[email protected] as the content of the To header field and Request-URI header field when calling Alice.
Contact: The
subsequent Request will determine the destination address based on the content of the Contact header field, and put the content of the Contact header field in the Request-URI. It can also be used to indicate the addresses of Proxies that are not recorded in the Record-Route header field. At the same time it can also be used in Redirect servers and REGISTER requests and responses.
Record-Route/Route: The
Record-Route header field is generally inserted into the request by proxies, so that subsequent Requests with the same call-id as before will be routed to these proxies. It will also be used by the User Agent as the basis for sending subsequent requests. This mechanism is very similar to source-route. The information in the Record-Route header field is copied to the Route header field. And the Request-URI header field will be set to the content of the first Route header field.
Via: The
Via header field is inserted into the request by the server to check the routing loop and enable the response to find the way back based on via. It will not affect future requests or responses.
In general, if there is a Route, the request should be sent according to the Route, if not, it should be sent according to the Contact header field, if there is no Contact, it should be sent according to the From header field.
Dialog, transaction, session The
three important concepts in SIP are dialog, session and transaction.
The following is my experience on these three concepts in my study, and I will post it to discuss with you. The establishment of
dialog is started when the response from UAS (To tag) is received. The
dialog created when the 180 response is received is called an early dialog, and the real dialog is established when the 2XX response is received.
The session is established after the media exchange. Specifically, it is to exchange sdp media through offer/answer.
The establishment of session can be INVITE-200 or 200-ACK. It depends on when the media exchange takes place.
Specifically, the message body in INVITE uses the sdp language to describe the media types that it can handle, and the 200 OK
brings back the media types that can be handled by the UAS. At this time, the media exchange is complete. Session is established
here.
Dialog is the relationship between end-point and end-point. And transaction is the relationship of hop by hop. Dialog uses
From tag, To tag (it should be said that local tag, remote tag-these two tags are different with UAC and UAS.) and
Call-ID to distinguish. The transaction is the request and response relationship between a SIP entity and the next SIP entity. (Stateless proxy servers are no longer listed here). It
is determined by the branch in Via.
Transaction:
Maintain the hop to hop state, including a request and all responses triggered by it, including several temporary responses and a final response. The life cycle is from the request to the final response.
Dialog:
Maintain the peer to peer status. Currently, only invite and subscribe requests will trigger the dialog. Its life cycle runs through an end-to-end conversation