SIP请求通过在起始行带一个Request行和其他的method加以区别。一个请求行包含method名称，一个Request-URI，和由单空格字符分开的协议版本。
请求行以换行符CRLF结束。可以允许无回车或换行，除了在以换行符结束的序列中。不允许在任何要素中有任意数量的空白格（LWS）存在。
Request-Line = Method SP Request-URI SP SIP-Version CRLF
Method: 此规范定义了六个方法： REGISTER支持注册联系消息，INVITE，ACK， 和CANCEL支持会话创建，BYE支持结束会话，OPTIONS支持对服务器的能力查询。SIP扩展中定义了其他的方法。
- Request-URI: Request-URI是一个SIP或SIP URL在Section 19.1 介绍，它或者是一个标准的URL（RFC 2396 [5]）。它表示这个用户或这个服务被记录。Request-URI不能包含非转义符空格或控制字符，不能以"<>"方式出现。
- SIP 要素中可能支持Request-URIs，不一定是sip或者sips，也可能是其他的URL schemes形式，例如"tel"，这是RFC 2806 [9]的URL schemes。SIP要素可以在它们的处理过程中使用任何机制转译非SIP，最终生成SIP URI，或者其他的scheme。
- SIP-Version: 请求和响应都包括在使用的SIP版本，并且遵守 [H3.1]（HTTP替代了SIP，HTTP/1.1替代了SIP/2.0），这里涉及了版本顺序，遵守要求和版本更新数量。 为了遵从此规范，应用程序发送到SIP消息必须包括SIP版本 "SIP/2.0"。 此SIP版本字符串是大小写敏感，但是使用时必须发送大写字母。
- 不像HTTP/1.1，SIP把此版本号看作为一个一般字面字符串。在实际使用时，这应该没有什么不同。
7.2 Responses
SIP 响应消息和请求消息不同，响应消息包含一个Status-Line作为一个起始start-line。在每个要素中，一个Status-Line由响应版本，然后跟随一个数字类型的状态码以及其关联的文本短语，通过一个单空格字符分开。
除了在最后的CRLF顺序中，可以允许无CR（回车）或者LF（换行）转义字符。
Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
状态码是一个三位整数的结果代码，它表示一个测试输出的响应理解，满足请求的要求。原因短语的目的是对状态码给予一个短语解释。使用状态码的目的是为了系统的自动处理，而原因短语的目的是方便用户阅读理解状态原因，具有可阅读性。用户不要求检查或显示原因短语。
这里，此规范建议使用明确的用词来表示原因短语，部署使用时可使用其他的文本。例如，在请求中的Accept-Language头中的语言。
状态码的第一个数字定义了响应的级别。状态码后两位没有层级的设置。因为这个原因，任何状态码介于100和199之间的响应被看作是"1xx response"，任何状态码介于200和299的响应看作是一个"2xx response"响应，以此类推。以第一个数字为划分类别，SIP/2.0支持了六个级别的状态响应码：- 1xx: Provisional – 请求收到的响应码，表示是临时响应，会继续处理此请求；
- 2xx: Success – 成功收到处理流程，理解，接受了处理流程；
- 3xx: Redirection – 需要进一步的流程处理来完成此请求；
- 4xx: Client Error – 此请求中包含错误语法或不能满足服务器的要求；
- 5xx: Server Error – 服务器端不能满足一个明确有效请求；
- 6xx: Global Failure – 任何服务器都不能满足此请求流程。
7.3 Header Fields
在语法和语义方面，SIP头和HTTP头非常相似。在实际应用环境中，SIP header 遵从[H4.2] 对消息头的语法和对拓展头的规则。但是，后者通过HTTP定义，使用了隐藏的空格。此规范和RFC 2234[10]是一致的，仅使用了明确的空格，并且看作为语法的一个部分。
[H4.2] 也定义了同一域名称的多个头的语法，这些值都以逗号隔离的列表，这些列表可以合并成一个头值。这个应用方式也可以支持SIP，但是因为具体的规范有所不同。具体来说，任何SIP头都以下语法的形式表现
header = "header-name" HCOLON header-value *（COMMA header-value）
可以支持合并同一名称的头成为一个逗号隔离的列表。此 Contact header支持逗号隔离的列表，除非这个头的值是"*"。
7.3.1 Header Field Format
头域遵从标准的头格式标准，在Section 2.2 of RFC 2822 [3]定义。每个头由域名，然后冒号（":"） 和域值构成。
field-name: field-value
消息头顶标准语法在Section 25 定义，然后紧跟一个任意数量的空格。但是，在部署使用时应该避免基于头域和冒号之间的空格，在值域和冒号之间使用一个单空格。
- Subject: lunch
- Subject : lunch
- Subject :lunch
- Subject: lunch
因此，以上格式都是有效的，建议使用最后的格式。
Header 头域可以扩展为多行，实现方式是通过在每一行前添加至少一个SP或HT tab键来实现。在下一行开始前的换行符和空格被看作是一个单SP政府。因此，以下几种格式表达的意思是相同的：
- Subject: I know you're there, pick up the phone and talk to me!
- Subject: I know you're there,
- pick up the phone
- and talk to me!
带不同域值的头的相对顺序不是非常重要。但是，规范推荐，为了支持代理处理，这些头（Via, Route，Record-Route，Proxy-Require，Max-Forwards，和Proxy-Authorization，例如） 应该出现在消息体的顶部来支持代理的快速解析。头的相对顺序和其对应的名称是非常重要的。如果或只有如果那个头的域值定义为以逗号分割的列表时（Section 7.3的多头值域可能出现在消息中，但是，因为它们的语法没有遵从Section 7.3的标准格式，它们不允许合并为单头行域值。
使用时必须可以处理同样名称的多头值，无论是每行单值合并的头或是逗号分隔的方式。
以下各组头值是有效，相等的：
- Route: <sip:alice@atlanta.com>
- Subject: Lunch
- Route: <sip:bob@biloxi.com>
- Route: <sip:carol@chicago.com>
- Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>
- Route: <sip:carol@chicago.com>
- Subject: Lunch
- Subject: Lunch
- Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>, <sip:carol@chicago.com>
每个组的值是有效的但是又表达各自不同含义：
- Route: <sip:alice@atlanta.com>
- Route: <sip:bob@biloxi.com>
- Route: <sip:carol@chicago.com>
- Route: <sip:bob@biloxi.com>
- Route: <sip:alice@atlanta.com>
- Route: <sip:carol@chicago.com>
- Route: <sip:alice@atlanta.com>,<sip:carol@chicago.com>, <sip:bob@biloxi.com>
头的名称格式是通过每个头名称来定义的。它总是是UTF8文本八位字节不确定度顺序出现或空格，标志符，分隔符和带引号的字符出现。许多存在的头会附加到通过标准规范值，通过分号的方式，分隔参数名称，参数值，具体格式为：
field-name: field-value *（;parameter-name=parameter-value）
虽然任意数目的参数可以附加到头上，但是，任何已给定的参数名称不能出现第二次。
当对比头值时，头名称总是大小写不敏感的。要不然，这个头是一个指定的头，它已经声明了值域名称，参数名称和参数值是大小写不敏感的头。标记符总是大小写不敏感的字符。除非，这个标记符已经声明其属性，否则，被引号标注的字符值是大小写敏感的值。例如，
Contact: <sip:alice@atlanta.com>;expires=3600
等同于
CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600
和
Content-Disposition: session;handling=optional
等同于
content-disposition: Session;HANDLING=OPTIONAL
以下这两组是不相同的：
- Warning: 370 devnull "Choose a bigger pipe"
- Warning: 370 devnull "CHOOSE A BIGGER PIPE"
7.3.2 Header Field Classification
一些头值仅使用在请求和响应的处理中，并且具有一定的意义。它们被称之为request header fields 和 response header fields。如果一个头出现在消息体中，没有匹配任何头的层级（例如，请求的头出现在响应的消息体中），它则必须被忽略掉。Section 20定义了头的各种层级。
关注微信公众号：asterisk-cn，获得有价值的IP通信行业分享
Asterisk freepbx 中文官方论坛：http://bbs.freepbx.cn/forum.php
Asterisk freepbx技术文档： www.freepbx.org.cn
融合通信商业解决方案，协同解决方案首选产品：www.hiastar.com
Asterisk/FreePBX中国合作伙伴，官方qq技术分享群（3000千人）：589995817
