1.SIP1.1.1.SIP格式每条SIP消息由以下三部分组成：（1）起始行（Start Line）：每个SIP消息由起始行开始。
起始行传达消息类型（在请求中是方法类型，在响应中是响应代码）与协议版本。
起始行可以是一请求行（请求）或状态行（响应）。
（2）SIP头：用来传递消息属性和修改消息意义。
它们在语法和语义上与HTTP头域相同（实际上有些头就是借自HTTP），并且总是保持格式：<名字>:<值>。
（3）消息体：用于描述被初始的会话（例如，在多媒体会话中包括音频和视频编码类型，采样率等）。
消息体能够显示在请求与响应中。
SIP清晰区别了在SIP起始行和头中传递的信令信息与在SIP 范围之外的会话描述信息。
可能的体类型就包括本文将要描述的SDP会话描述协议。
1.1.2.消息头Header field where proxy ACK BYE CAN INV OPT REG Accept R - o - o m* o Accept 2xx - - - o m* o Accept 415 - c - c c c Accept-Encoding R - o - o o o Accept-Encoding 2xx - - - o m* o Accept-Encoding 415 - c - c c c Accept-Language R - o - o o o“where”列描述了在头域中能够使用的请求和应答的类型。
这列的值是：R:头域只能在请求中出现；r:头域只能在应答中出现；2xx，4xx，等等：一个数字的值区间表示头域能够使用的应答代码。
c：头域是从请求拷贝到应答的。
如果”where”栏目是空白，表示头域可以在所有的请求和应答中出现。
“proxy”列描述了proxy在头域上的操作a：如果头域不存在，proxy可以增加或者连接头域m：proxy可以修改现存的头域值d：proxy可以删除头域值r：proxy必须能读取这个头域，因此这个头域不能加密。
接下来6个栏目与在某一个方法中出现的头域有关：c：条件；对头域的要求依赖于消息的内容m：头域是强制要有的。
m*：头域应当被发送，但是客户端/服务端都需要准备接收没有这个头域的消息。
o：头域是可选的。
t：头域应当被发送，但是客户端/服务端都需要准备接收没有这个头域的消息。
客户端/服务端都需要准备接收没有这个头域的消息。
如果通讯的协议是基于面向流的协议（比如TCP），那么头域值必须被发送。
*：如果消息体不为空，那么头域值就绪要的。
（细节请参见20.14,20.15和7.4节）-:这个头域是不适用的。
1.1.3.请求格式1.1.4.响应格式1.2.字段Request-URI :呼叫请求发送地址。
UA生成初始请求消息时，该域中的信息一般与TO中的地址相同，经过网络服务器后，由于实际路由问题，该值可能发生变化以，另外一个比较特殊的是REGISTER消息，在REGISTER消息中，在REQUEST-URI中将会填充注册服务器的地址（表示消息发往注册服务器），而此时TO域中的地址将会填充客户端实际的地址。
From 发起请求方的地址。
一般采用USERINFO@HOSTPORT形式。
该域同时带有一个TAG参数，是随机产生的整数。
To接受方地址。
同FROM域相同，也采用USERINFO@HOSTPORT的地址形式，当该域存在于最终响应消息中时，将会事有TAG参数。
Call－ID用于识别呼叫参数，在同一个DIALOG中，该参数不发生变化。
该参数与FROM 中的TAG参数、TO域中的TAG参数相结合用以保证呼叫的惟一性。
Cseq表征TRANSACEION的参数，由于同一个呼叫中会存在多个TRANSACTION,因此通过该能数来保证同一个USERAGENT发送的不同请求消息间的顺序。
Via该参数表征呼叫经过的路径，UA生成SIP消息时，会在该域中填写自己的地址：PROXY在转发请求消息时，将会增加一个填有自己地址的VIA域，表示才叫经过本PROXY。
VIA域的存在可以保证响应消息按照原路径返回到主叫方.代理服务器用它检查其内容，如果新端点已出现在via列表中，则表示有环路了。
Contact告知对端自己的地址。
当对端发送下一个请求消息时，可直接向该地址发送，不需要关心前一个路由信息（除非有特定原则，例如PROXY可以通过RECORD-ROUTE域来保证下一个请求消息必须经过本PROXY,即使CONTACT域中填写对端客户的地址。
Expires limits search time,给出消息内容超期的时间Record-Route 由于CONTACT域的存在使得两个用户后续的请求消息可能不经过PROXY,为了运营需要，PROXY在初始INVITE消息中增加了RECORD-ROUTE域，这样可以保证后续请求（例如BYE消息）经过PROXY.通过RECORD-ROUTE与CONTACT的结合，既可避免后续请求旁路网络服务器的行为，又可减少后续请求路径上的环节。
CONTENT-TYPE表征消息格式的参数，例如，呼叫采用了SDP进行会话描述，还是采用其他类型的会话描述协议。
Examples of SIP URIssip:*********************sip:*********************;transport=sip:******************.ch:5678sip:**********.200.27:3456sip:+41-76-456-9786@sipgate.sip:*****************.ch;user=sip:zhwin.ch;method=REGISTERDefaults:5060 (destination port)transport=udp (transport parameter)user=ip (user parameter)method=INVITE (SIP method)1.2.1.Via格式Via = ( "Via" | "v") ":" 1#( sent-protocol sent-by *( ";" via-params ) [ comment ] )via-params = via-hidden | via-ttl | via-maddr| via-received | via-branch | via-extensionvia-hidden = "hidden"via-ttl = "ttl" "=" ttlvia-maddr = "maddr" "=" maddrvia-received = "received" "=" hostvia-branch = "branch" "=" tokenvia-extension = generic-paramVia 处理流程received/rport处理001 INVITEsip:*******************.66.222SIP/2.0002 Via: SIP/2.0/UDP 211.123.66.223:5060;branch=a71b6d57-507c77f2003 Via: SIP/2.0/UDP 10.0.0.1:5060;received=202.123.211.25;rport=12345004 From:<sip:******************.66.223>;tag=108bcd14005 To:sip:*******************.66.222006 Contact:sip:***************.0.1007 Call-ID:*****************************************.19.6008 CSeq: 703141 INVITE009 Content-Length: 138010 Content-Type: application/sdp011 User-Agent: HearMe SoftPHONE012…………In the above trace, the IP address in line 003 of the SIP header is the IP address that the client thinks it is – i.e. the internal IP address (10.0.0.1). But the proxy knows from which IP address it actually received the packet, so it adds the “received” and “rport”tags with the IP address and port after the NAT mapping. These tags allow the proxy to forward SIP messages back to the client via the NAT.Branch处理used to distinguish between multiple responses to the same request.Forking Proxy: Issue a single request to multiple destinations.1.2.2.Route/Record-Route•Record-Route can be used:–ensures Firewall proxy stays in path• A Firewall proxy adds Record-Route header–Clients and Servers copy Record-Route and put in Route header for all messagesRequest routing例Only Proxy 3 remains in route1. UA1 is instructed to INVITE “sip:UA2@proxy1”2. The message should be sent to Proxy 13. The message should be sent to Proxy 24. The message should be sent to Proxy 35. The message should be sent to UA2.6. UA2 sends a “200 OK”, which should be sent back to UA1, through all three proxies.7. UA1 sends an ACK to Proxy 3.8. Proxy 3 sends the ACK to UA2.9. UA2 sends a BYE to proxy 3.10. Proxy 3 sends the BYE to UA1.11. UA1 sends a 200 OK through proxy 3 to UA2.1.2.3.ExpiresThe RFC is referring to a REGISTER request that includes an expires parameter on the Contact and one is a separate header field like this:Contact:<sip:***************>;expires=1000Contact:<sip:***************>Expires: 2000for the above, the foo contact should expire after 1000 seconds, and the bar contact after 2000 seconds.The test used the Contact header:Contact:<sip:*************************.com;Expires=1800>;EXPIRES=2970which means something else entirely. The ';expires=1800' inside the angle brackets is a part of the URI, not a field parameter of the Contact field. The ';expires=2970' outside is the field parameter, so it is correct to use it as the expiration time of the contact.The inner one is used by the proxy to control forking timeouts when this Contact is used, and has nothing to do with the registration expiration.Broad Band。