SIP借鉴了HTTP以及SMTP的消息格式，因此看起来是比较眼熟的。SIP消息格式为：
SIP request-line/response-line
other SIP fields
[CRLF]
SIP boby
其中每个头域都以换行分开。具体关于SIP消息格式请见SIP核心标准文档
RFC3261。
我从《Understanding the Session Initiation Protocol, Second Edition》一书的6.1摘出SIP几个重要的头域的介绍，不翻译，英文更纯正。
需要说明的是关于这些头域的更深层次的语义信息需要自己多多琢磨。
6.1.3 Call-ID
The Call-ID header field is mandatory in all SIP requests and responses. It is part of the dialog used to uniquely identify a call between two user agents. A Call-ID must be unique across calls, except in the case of a Call-ID in registration requests. All registrations for a user agent should use the same Call-ID. A Call-ID is always created by a user agent and is never modified by a server.
The Call-ID is usually made up of a local-id, which should be a cryptographically random identifier, or a local-id, the @ symbol, and a host name or IP address. Because a user agent can ensure that its local-id is unique within its domain, the addition of the globally unique host name makes the Call-ID globally unique. Some security is provided by the randomness of the Call-ID, because this prevents a third party from guessing a Call-ID and presenting false requests. The compact form of the Call-ID header field is i.
Examples of Call-ID are shown here:
6.1.4 Contact
The Contact header field is used to convey a URI that identifies the resource requested or the request originator, depending on whether it is present in a request or response. Once a Contact header field has been received, that URI can be cached and used for routing future requests within a dialog. For example, a Contact header field in a 200 OK response to an INVITE can allow the acknowledgment ACK message and all future requests during this call to bypass proxies and go directly to the called party. However, the presence of Record-Route header fields in an earlier request or default proxy routing configuration in a user agent may override that behavior. When a Contact URI is used in a Request-URI, all URI parameters are allowed with the exception of the method parameter, which is ignored.
Contact header fields must be present in INVITE requests and 200 OK responses to invitations. In some cases, the Contact URI may not resolve directly to the user agent. For example, a UA behind a firewall ALG will need to use a Contact URI that resolves to the firewall ALG address. Otherwise, the use of the user agent's URI will result in the call failing because of the firewall blocking any direct routed SIP requests. Contact header fields may also be present in 1xx, 2xx, 3xx, and 485 responses. Only in a REGISTER request, a special Contact:*, along with an Expires: 0, header field is used to remove all existing registrations. Examples of Contact header fields in registrations are shown in Table 4.3. Otherwise, wild carding is not allowed. A Contact header field may contain a display name that can be in quotes. If a display name is present, the URI will be enclosed in < >. If any header field parameters are present, the URI will also be enclosed in < > along with any URI parameters, with the header field parameters outside the < >, even if no display name is present.
There are three additional parameters defined for use in Contact header fields: q, action, and expires. They are placed at the end of the URI and separated by semicolons. The q value parameter is used to indicate relative preference, which is represented by a decimal number in the range 0 to 1. The q value is not a probability, and there is no requirement that the q values for a given list of Contacts add up to 1. (The action parameter defined in RFC 2543 has been deprecated and is not used in RFC 3261. It was only used in registration Contact header fields, and is used to specify proxy or redirect operation by the server.) The expires parameter indicates how long the URI is valid and is also only used in registrations. The parameter either contains an integer number of seconds or a date in SIP form .
The Contact header field may contain a feature tag [4], which can be used to indicate the capabilities of the device identified by the Contact URI. For example, the feature tag isfocus is used to indicate that the URI in the Contact header field is a Conference URI, and that the dialog is associates with a focus. A focus is a SIP user agent that hosts a particular instance of a conference, called a "bridge" or MCU in other protocols. The presence of the isfocus feature tag can be used by a SIP user agent that supports advanced conferencing features to invoke certain call control operations [5] or subscribe to the conference package [6].
6.1.5 CSeq
The command sequence CSeq header field is a required header field in every request. The CSeq header field contains a decimal number that increases for each request. Usually, it increases by 1 for each new request, with the exception of CANCEL and ACK requests, which use the CSeq number of the INVITE request to which it refers.
The CSeq count is used by UASs to determine out-of-sequence requests or to differentiate between a new request (different CSeq) or a retransmission (same CSeq). The CSeq header field is used by UACs to match a response to the request it references. For example, a UAC that sends an INVITE request then a CANCEL request can tell by the method in the CSeq of a 200 OK response if it is a response to the invitation or cancellation request.
Each user agent maintains its own command sequence number space. For example, consider the case where user agent 1 establishes a session to user agent 2 and initializes its CSeq count to 1. When user agent 2 initiates a request (such as a INVITE or INFO, or even BYE) it will initialize its own CSeq space, totally independent of the CSeq count used by user agent 1.
6.1.8 From
The From header field is a required header field that indicates the originator of the request. It is one of two addresses used to identify the dialog. The From header field contains a URI, but it may not contain the transport, maddr, or ttl URI parameters. A From header field may contain a tag, used to identify a particular call. A From header field may contain a display name, in which case the URI is enclosed in < >. If there is both a URI parameter and a tag, then the URI including any parameters must be enclosed in < >.
A From tag was optional in RFC 2543 but is mandatory to include in RFC 3261.
6.1.10 Record-Route
The Record-Route header field is used to force routing through a proxy for all subsequent requests in a session between two user agents. Normally, the presence of a Contact header field allows user agents to send messages directly bypassing the proxy chain used in the initial request (which probably involved database lookups to locate the called party). A proxy inserting its address into a Record-Route header field overrides this and forces future requests to include a Route header field containing the address of the proxy that forces this proxy to be included.
A proxy, such as a firewall control proxy, wishing to implement this inserts the header field containing its own URI, or adds its URI to an already present Record-Route header field. The URI is constructed so that the URI resolves back to the proxy server. The UAS copies the Record-Route header field into the 200 OK response to the request. The header field is forwarded unchanged by proxies back to the UAC. The UAC then stores the Record-Route proxy list plus a Contact header field if present in the 200 OK for use in a Route header field in all subsequent requests. Because Record-Route is bidirectional, messages in the reverse direction will also traverse the same set of proxies. Chapter 10 contains an example of the use of the Record-Route and Route header fields. The lr parameter is new to RFC 3261 and indicates that the proxy server supports "loose routing". Older RFC 2543 compliant proxy servers create Record-Route URIs that instead of the lr parameter often contain the maddr parameter with an address or host that resolves to that proxy server.
Examples are:
Record-Route: <sip:proxy1.carrier.com;lr>,
<sip:firewall33.corporation.com;lr>
Record-Route:<sip:139.23.1.44;lr>
6.1.15 To
The To header field is a required header field in every SIP message used to indicate the recipient of the request. Any responses generated by a user agent will contain this header field with the addition of a tag. (Note that an RFC 2543 client will typically only generate a tag if more than one Via header field is present in the request.) Any response generated by a proxy must have a tag added to the To header field. A tag added to the header field in a 200 OK response is used throughout the call and incorporated into the dialog. The To header field is never used for routing-the Request-URI is used for this purpose. An optional display name can be present in the header field, in which case the SIP URI is enclosed in < >. If the URI contains any parameters or username parameters, the URI must be enclosed in < > even if no display name is present. The compact form of the header field is t.
6.1.17 Via
The required Via header field is used to record the SIP route taken by a request and is used to route a response back to the originator. A user agent generating a request records its own address in a Via header field in the request. While the ordering of most SIP header fields is not significant, the Via header fields order is significant because it is used to route responses. A proxy forwarding the request adds a Via header field containing its own address to the top of the list of Via header fields. A proxy adding a Via header field always includes a branch tag containing a cryptographic hash of the To, From, Call-ID header fields and the Request-URI. A proxy or user agent generating a response to a request copies all the Via header fields from the request in order into the response, then sends the response to the address specified in the top Via header field. A proxy receiving a response checks the top Via header field to ensure that it matches its own address. If it does not, the response has been misrouted and should be discarded. The top Via header field is then removed, and the response forwarded to the address specified in the next Via header field. A simplified Via decision tree is shown in Figure 6.1. Figure 6.1: Via forwarding decision tree.
Via header fields contain protocol name and version number and transport (SIP/2.0/UDP, SIP/2.0/TCP, etc.) and may contain port numbers and parameters such as received, branch, maddr, and ttl.A received tag is added to a Via header field if a user agent or proxy receives the request from a different address than that specified in the top Via header field. This indicates that a NAT or firewall proxy is in the message path. If present, the received tag is used in response routing. (The hidden parameter, deprecated in RFC 3261, was used to indicate the Via header field has been encrypted.) A branch parameter is added to Via header fields by UAs and proxies, which is computed as a hash function of the Request-URI, and the To, From, Call-ID and CSeq number. A second part is added to the branch parameter if the request is being forked as shown in Figure 3.4. The maddr and ttl parameters are used for multicast transport and have a similar meaning as the equivalent SIP URI parameters.
5292
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
