Summary of SIP common head domain Header-field

From

The From header field contains the logical flags of the requesting initiator, which may be the user's Address-of-record. Just like the To header field, the From header field also contains a URI and can contain a displayed name (SIP display info).

To

The To Header field is the first and also the "logical" receiving place that specifies the request first ("First" is because it may refer to another receiving place),

Or the Address-of-record of the requested user or resource (for example, the from of register and SUBSCRIBE method, the URI of the to is the same).

Call-id

Call-id is a unique flag that distinguishes a set of messages in a series of messages. All requests for any UA in the dialog (Dialog/callleg) and all responses Call-id must be consistent. In each of the UA registrations, it should be the same.

Note that if it is a retry of the request (Re-invite, for example, Hold,unhold,session-timer, and the Register mechanism), the retry request is not treated as a new request, So there is no need for new Call-id (retry requests such as authentication conflicts, etc.).

CSeq

Consists of a sequential number and a method. Method must be consistent with the requested method. The order used to differentiate and act as a transaction (Transaction).

Max-forwards

The Max-forwards header field is used to restrict the jump to the middle of the request to his destination. It contains a number that automatically minus one every other jump. If Max-forwards is reduced to 0 before the destination, he will report a 483 (too many routes) error response. The default value for this field should be 70. This header field ensures that the resource of proxy is consumed as little as possible when there is a loop.

Via

The Via header domain is a transport device that flags the transport for the transaction (Transaction), and also flags the address that the answer is sent back to. You need to include the Via domain in the header domain only if you need to reach the next node (hop) by selecting a transport device.

Record-route

Contact

The Contact header field provides a method of contacting a specific UA instance that accesses subsequent requests.

The scope of the contact is global. This means that the URI contained in the Contact header field is the UA that can receive the request.

Supported and Require,proxy-require

If UAC supports the SIP extension that the service side responds to the corresponding request, UAC should include a supported header domain description in the request when the options tags describe those sip extensions.

The extension instructions that appear in option tags must follow the standard extension instructions for RFCs. This prevents the server from supporting non-standard client-side extension implementations.

If UAC requires UAS to be able to support extensions so that UAS can handle specific requests for UAC, it must add a require header field to the request header to illustrate what kind of extension option tags are required to handle this particular request.

If UAC needs to request that all proxies pass through the extended portion of a request it makes, it must add a Proxy-require header field to indicate what option tag extension is required for proxy support. As indicated in the Supported header field, the Option field in the Require and Proxy-require header fields must be limited to the standard extension of RFCs.

Todo