SIP消息有两种：客户机到服务器的请求(Request),服务器到客户机的响应(Response)。
SIP消息由一个起始行(start—line)、一个或多个字段(field)组成的消息头、一个标志 消息头结束的空行(CRLF)以及作为可选项的消息体(message body)组成。其中，描述消 息体(messagebody)的头称为实体头(entityheader),其格式如下：
generic-message = start-line
*message-header
CRLF
[message-body ]
起始行分请求行(Request-Line)和状态行(Status-Line)两种，其中请求行是请求消息 的起始行，状态行是响应消息的起始行。
消息头分通用头(general-header)、请求头(request-header)、响应头(response-header) 和实体头(entity-header) 4种。
1.SIP请求消息
请求消息的格式如下：
Request = Request-Line
*( general-header
I request-header
I entity-header)
CRLF
[message-body ]
请求行(Request-Line)以方法(method)标记开始，后面是Request-URI和协议版本 (SIP-Version),最后以回车键结束，各个元素间用空格键字符间隔。
Request-Line = Method SP Request-URI SP SIP-Version CRLF
SIP用术语“method”来对说明部分加以描述，Method标识是区分大小写的。
Method = "INVITE" I "ACK" I "OPTIONS" I "BYE"
I "CANCEL" I "REGISTER'T'INFO"
Slf定义了以下几种方法(methods)。
INVITE
INVITE方法用于邀请用户或服务参加一个会话。在INVITE请求的消息体中可对被叫方 被邀请参加的会话加以描述，如主叫方能接收的媒体类型、发出的媒体类型及其一些参数； 对INVITE请求的成功响应必须在响应的消息体中说明被叫方愿意接收哪种媒体，或者说明被 叫方发出的媒体。
服务器可以自动地用200 (OK)响应响应会议邀请。
ACK
ACK请求用于客户机向服务器证实它已经收到了对INVITE请求的最终响应。ACK只和 INVITE请求一起使用。对2xx最终响应的证实由客户机用户代理发出，对其他最终响应的证 实由收到响应的第一个代理或第一个客户机用户代理发出。ACK请求的To, From, CaU-ID, CSeq字段的值由对应的INVITE请求的相应字段的值复制而来。
OPTIONS
用于向服务器查询其能力。如果服务器认为它能与用户联系，则可用一个能力集响应 OPTIONS请求；对于代理和重定向服务器只要转发此请求，不用显示其能力。
OPTIONS的From、To分别包含主被叫的地址信息，对OPTIONS请求的响应中的From、 To (可能加上tag参数)、Call-ID字段的值由OPTIONS请求中相应的字段值复制得到。
BYE
用户代理客户机用BYE请求向服务器表明它想释放呼叫。
BYE请求可以像INVITE请求那样被转发，可由主叫方发出也可由被叫方发出。呼叫的 一方在释放(挂断)呼叫前必须发出BYE请求，收到BYE请求的这方必须停止发送媒体流 给发出BYE请求的一方。
CANCEL
CANCEL请求用于取消一个Call-ID, TO, From和Cseq字段值相同的正在进行的请求，但 取消不了已经完成的请求（如果服务器返回一个最终状态响应，则认为请求已完成）。
CANCEL请求中的Call-ID、To、Cseq的数字部分及From字段和原请求的对应字段值相 同，从而使CANCEL请求与它要取消的请求匹配。
REGISTER
REGISTER方法用于客户机向SIP服务器注册列在To字段中的地址信息。
REGISTER请求消息头中各个字段的含义定义如下：
• To:含有要创建或更新的注册的地址记录。
• From:含有提出注册的人的地址记录。
• Request-URI:注册请求的目的地址，地址的域部分的值即为主管注册者所在的域，而 主机部分必须为空。一般，Request-URI中的地址的域部分的值和To中的地址的域部 分的值相同。
• Call-ID:用于标识特定客户机的注册请求。来自同一个客户机的注册请求至少在相同 重启周期内Call-ID字段值应该相同；用户可用不同的Call-ID值注册不同的地址，后 面的注册请求将替换前面的所有请求。
• Cseq: Call-ID字段值相同的注册请求的CSeq字段值必须是递增的，但次序无关系， 服务器并不拒绝无序请求。
• Contact:此字段是可选项；用于把以后发送到TO字段中的URI的非注册请求转到 Contact字段给出的位置。如果请求中没有Contact字段，那么注册保持不变。
• Expires:表示注册的截止期。
INFO
INFO方法是对SIP协议的扩展，用于传递会话中产生的与会话相关的控制信息，如ISUP 和ISDN信令消息，有关此方法的使用还有待标准化，详细内容参见IETF RFC 2976。
其他扩展
其他扩展的含义如下：
• re-INVITE:用来改变参数；
• PRACK:与ACK作用相同，但是用于临时响应；
• SUBSCRIBE:该方法用来向远端端点预定其状态变化的通知；
• NOTIFY:该方法发送消息以通知预定者它所预定的状态的变化；
• UPDATE:允许客户更新一个会话的参数而不影响该会话的当前状态；
• MESSAGE:通过在其请求体中承载即时消息内容实现即时消息；
• REFER:其功能是指示接受方通过使用在请求中提供的联系地址信息联系第三方。
2. SIP响应消息
响应消息格式如下：
Response = Status-Line
*（ general-header
I response-header
I entity-header )
CRLF
[message-body ]
状态行(Status-Line)以协议版本开始，接下来是用数字表示的状态码(Status-Code)及 相关的文本说明，最后以回车键结束，各个元素间用空格字符(SP)间隔，除了在最后的CRLF 序列中，这一行别的地方不许使用回车或换行字符。
Status-Line = SIP-version SP Status-Code SP Reason-Phrase CRLF
SIP协议中用三位整数的状态码(Status Code)和原因码(Reason Code)来表示对请求做 出的回答。状态码用于机器识别操作，原因短语(Reason-Phrase)是对状态码的简单文字描述, 用于人工识别操作。其格式如下：
Status-Code = lxx (Informational)
I 2xx (Success)
I 3xx (Redirection)
I 4xx (Client-Error)
I 5xx (Server-Error)
I 6xx (Global-Failure)
I extension-code
状态码的第一个数字定义响应的类别，在SIP/2.0中第一个数字有6个值，定义如下：
• 1 xx(Informational):请求已经收到、继续处理请求。
• 2xx(Uccess):行动已经成功地收到，理解和接受。
• 3xx(Redirection):为完成呼叫请求，还须采取进一步的动作。
• 4xx(Client Error):请求有语法错误或不能被服务器执行。客户机需修改请求，然后再 重发请求。
• 5xx(ServerError):服务器出错，不能执行合法请求。
• 6xx(Global Failure):任何服务器都不能执行请求。
其中，lxx响应为暂时响应(Provisional response),其他响应为最终响应(Final Response)o
3. SIP消息头字段
SIP协议的消息头定义与HTTP在语法规则和定义上很相似。每个头字段都遵循以下格式: 首先是字段名(Field Name),字段名不分大小写，后面是冒号；然后是字段值，字段值与冒 号间可有多个前导空格(LWS)。其格式如下：
message-header = field-name ":" [ field-value ] CRLF field-name = token
field-value = *( field-content ILWS )
通用消息头(Generahheader)
通用头字段适用于请求消息和响应消息，包含的字段有：
general-header = Accept
I Accept-Encoding
I Accept-Language
I Call-ID
I Contact
I CSeq
I Date
I Encryption
I Expires
I From
I Organization
I Record-Route
I Timestamp
I To
I User-Agent
I Via
接下来，介绍通用头字段中各字段的含义：
• Accept, Accept-Encoding和Accept-Language字段用于客户机在请求消息中给出其可接 受的响应的媒体类型、编码方式以及描述语言。用于服务器在415响应(请确认)中 表明其可理解的请求消息的媒体类型、编码方式以及描述语言。
• Call-ID字段：用于惟一标识特定遨请或某个客户机的注册请求，一个多媒体会议可产 生多个Call-ID不同的呼叫。
• Contact字段：给出一个URL,用户可以与此URL建立进一步的通信。
• Cseq字段：用于标识服务器发出的不同请求，若Call-ID值相同，那么Cseq值必须各 不相同。
• Date字段：反映首次发出请求或响应消息的时间，重发的消息与原先的消息有相同的 Data字段值。
• Encryption字段：表明内容经过了加密处理，这种加密为端到端的加密。
• Expire字段：它给出消息内容截止的日期和时间。
• From字段：所有消息中都必须有From字段，此字段给出请求的发起者。
• Organization字段：它给出发出请求或响应消息的实体所属的组织的名称。
• Record-Route字段：它给出一个全局可到达的Request-URI,用于标识代理服务器。
• Time-Stamp字段：给出客户机向服务器发出请求的时间。
• To字段：所有消息中都必须有To字段，此字段给出请求的目的收方。
• User-Agent字段：含有与发起请求的用户代理客户机有关的信息。
• Via字段：它给出请求消息迄今为止经过的路径。
实体头(Entity-header)
实体头字段用于定义与消息体相关的信息。包含的字段有：
entity-header = Content-Encoding
I Content-Length
I Content-Type
接下来，介绍实体头字段中各个字段的含义：
• Content-Encoding字段：表明消息体上添加应用的内容编码方式。
• Content-Length字段：表明消息体的大小。
• Content-Type字段：表明消息体的媒体类型。
请求头(Request-header)
请求头字段用于客户机上传附加信息到服务器，其中包括有关请求和客户机本身的信息。 包含的字段有：
request-header = Authorization
I Contact
I Hide
I Max-Forwards
I Priority
I Proxy-Authorization
I Proxy-Require
I Route
I Require
I Response-Key
I Subject
接下来，介绍请求头字段中各个字段的含义：
• Authorization字段：用于用户代理向服务器鉴定自身身份。
• Hide字段：用于客户机表明其希望向后面的代理服务器或用户代理隐藏由Via字段构 成的路径。
• Max-Forwards字段：表明请求消息允许被转发的次数。
• Priority字段：用于客户机表明请求的紧急程度。
• Priority-Authorization字段：用于客户机向要求身份认证的代理服务器表明自身身份。
• Proxy-Require字段：用于标识出代理必须支持的代理敏感特征。
• Route字段：决定请求消息的路由。
• Require字段：用于客户机告诉代理服务器为了让服务器正确处理请求,客户机希望服 务器支持的选项。
• Response-Key 用于给出被叫方用户代理加密响应消息所采用的密钥需满足的要求。
• Su可ect字段：提供对呼叫的概述或表明呼叫的性质，可用于呼叫过滤。
响应头(Response-header)
响应头字段用于服务器向Request-URI指定的地址传送有关响应的附加信息。包含的字段 有：
response-header = Allow
I Proxy-Authenticate
I Retry-After
I Server
I Unsupported
I Warning
I WWW-Authenticate
接下来，介绍响应头字段中各个字段的含义：
• Proxy-Authenticate字段：必须为407响应的一部分：字段中的值给出适用于 Request-URI的代理的认证体制和参数。
• Retry-Afta•字段：可用于503响应中，向发出请求的客户机表明服务预计多久以后可 以启用，用于404、600、603响应中表明被叫方何时才有空。
• Server字段：含用户代理服务器处理请求所使用的软件信息。
• Unsuppoted字段：列出服务器不支持的特征。
• Warning字段：用于传递与响应状态有关的附加信息。
• WWW-Authenticate字段：含于401响应中，指出适用于Request-URI的认证体制和参数。.
各种头使用场合
每一种头都有相应的使用场合，具体如表2-1所示。
| Header field | where | proxy | ACK | BYE | CAN | INV | OPT | REG |
| Accept | R | o | o | m* | 0 | |||
| Accept | 2xx | 0 | m* | o | ||||
| Accept | 415 | c | c | c | c | |||
| Accept-Encoding | R | 0 | 0 | o | 0 | |||
| Accept-Encoding | 2xx | 0 | m* | .0 | ||||
| Accept-Encoding | 415 | c | c | c | c | |||
| Accept-Language | R | o | O | O | o | |||
| Accept-Language | 2xx | O | M* | 0 | ||||
| Accept-Language | 415 | c | C | C | c | |||
| Alert-Info | R | ar | O | |||||
| Alert-Info | 180 | ar | O | |||||
| Allow | R | 0 | O | O | o | |||
| Allow | 2xx | 0 | m* | m* | o | |||
| Allow | r | 0 | O | 0 | 0 | |||
| Allow | 405 | m | m | M | m | |||
| Authentication-Info | 2xx | 0 | O | O | o | |||
| Authorization | R | o | 0 | o | o | O | o | |
| CaU-ID | c | r | m | M | M | M | M | m |
| CaU-Info | ar | O | O | 0 | ||||
| Contact | R | O | M | 0 . | 0 | |||
| Contact | lxx | 0 | ||||||
| Contact | 2xx | M | o | o | ||||
| Contact | 3xx | d | - | 0 | 0 | o | 0 | |
| Contact | 485 | - | 0 | - | O | 0 | 0 |
| Header field | where | proxy | ACK | BYE | CAN | INV | OPT | REG |
| Content-Disposition | 0 | O | O | O | O | |||
| Content-Encoding | o | O | O | O | o | |||
| Content-Language | o | O | O | O | o | |||
| Content>Length | Ar | t | t | t | T | T | t | |
| Content-Type | * | * | * | * | * | |||
| CSeq | c | r | m | m | m | m | M | m |
| Date | a | 0 | O | o | 0 | O | o | |
| Error-Info | 300〜699 | a | 0 | O | O | O | o | |
| Expires | O | 0 | ||||||
| From | c | r | m | m | M | M | M | m |
| In-Reply-To | R | 0 | ||||||
| Max-Forwards | R | amr | m | m | m | M | M | m |
| Min>Expires | 423 | m | ||||||
| MIME-Wrsion | o | O | o | O | o | |||
| Organization | ar | o | O | 0 | ||||
| Priority | R | ar | - | O | - | - | ||
|
Proxy” Authenticate |
407 | ar | - | m | - | m | M | m |
|
Proxy- Aulhenticate |
401 | ar | - | 0 | 0 | o | O | 0 |
|
Proxy- Authorization |
R | Dr | 0 | 0 | - | O | O | 0 |
| Proxy-Require | R | ar | 0 | - | O | O | o | |
| Record-Route | R | ar | o | 0 | 0 | O | O | - |
| Record-Route |
2xx 18x |
mr | - | o | o | 0 | o | - |
| Reply-To | - | o | - | |||||
| Require | ar | - | c | c | c | c | ||
| Retiy-After |
404 413 480 486 |
o | o | 0 | o | 0 | ||
|
500 503 |
- | o | 0 | o | o | 0 | ||
|
600 603 |
- | 0 | 0 | O | o | 0 | ||
| Route | R | adr | C | c | c | c | c | c |
| Server | r | 0 | o | 0 | 0 | 0 | ||
| Subject | R | 0 | - | |||||
| Supported | R | - | 0 | 0 | m* | o | o |
| Header field | where | proxy | ACK | BYE | CAN | INV | OPT | REG |
| Supported | 2xx | 0 | 0 | m* | m* | 0 | ||
| Timestamp | o | o | o | 0 | 0 | o | ||
| To | c(l) | r | M | m | m | m | M | m |
| Unsupported | 420 | m | m | M | m | |||
| User-Agent | 0 | 0 | o | 0 | 0 | 0 | ||
| Via | R | amr | m | m | m | m | M | m |
| Via | rc | dr | m | m | m | m | M | m |
| Warning | r | o | o | o | O | 0 | ||
| WWW-Authenticate | 401 | ar | m | m | M | m | ||
| WWW-Authenticate | 407 | ar | - | o | - | o | o | 0 |
其中，Where栏表示头可使用的地方，当为R时，表示仅可用在请求中；为[时，表示仅可用 在响应中；为c时，表示将头从请求复制到响应中。
Proxy栏描述代理对头采取的操作，当为a时，表示如果没有头，代理可以增加头；为m 时，表示代理可以修改头；为d表示代理可以删除头；为I•表示代理必须能读此头，所以此头 不能加密。
接下来六栏中的c表示根据具体消息来决定是否需要头，m表示必须要头；ni*表示应该 发送头，但是在没有头的情况下，仍应能接收消息；o表示头可选；t表示应该发送头，但是 在没有头的情况下，仍应能接收消息，如果使用基于流的协议(如TCP)作为传输协议，则 必须发送头；*表示如果消息体非空，需要此头；■表示头不可用。
