本文通过一个完整的SIP呼叫实例解释SIP头部的一些常见字段,在对这些字段的解释的同时也阐述了SIP消息的路由过程。下图是呼叫的消息流示意图和所有的消息头部(因为SDP和消息路由无关,故在此省略):
atlanta.com . . . biloxi.com
. proxy proxy .
. .
Alice's . . . . . . . . . . . . . . . . . . . . Bob's
softphone SIP Phone
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| 100 Trying F3 |--------------->| INVITE F4 |
|<---------------| 100 Trying F5 |--------------->|
| |<-------------- | 180 Ringing F6 |
| | 180 Ringing F7 |<---------------|
| 180 Ringing F8 |<---------------| 200 OK F9 |
|<---------------| 200 OK F10 |<---------------|
| 200 OK F11 |<---------------| |
|<---------------| | |
| ACK F12 |
|------------------------------------------------->|
| Media Session |
|<================================================>|
| BYE F13 |
|<-------------------------------------------------|
| 200 OK F14 |
|------------------------------------------------->|
| |
F1 INVITE Alice -> atlanta.com proxy
INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 Max-Forwards: 70 To: Bob From: Alice Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 142 |
F2 100 Trying atlanta.com proxy -> Alice
SIP/2.0 100 Trying Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob From: Alice Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Content-Length: 0 |
F3 INVITE atlanta.com proxy -> biloxi.com proxy
INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 Max-Forwards: 69 To: Bob From: Alice Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 142 |
F4 100 Trying biloxi.com proxy -> atlanta.com proxy
SIP/2.0 100 Trying Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob From: Alice Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Content-Length: 0 |
F5 INVITE biloxi.com proxy -> Bob
INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 Max-Forwards: 68 To: Bob From: Alice Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 142 |
F6 180 Ringing Bob -> biloxi.com proxy
SIP/2.0 180 Ringing Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 ;received=192.0.2.3 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob From: Alice Call-ID: a84b4c76e66710 Contact: CSeq: 314159 INVITE Content-Length: 0 |
F7 180 Ringing biloxi.com proxy -> atlanta.com proxy
SIP/2.0 180 Ringing Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob From: Alice Call-ID: a84b4c76e66710 Contact: CSeq: 314159 INVITE Content-Length: 0 |
F8 180 Ringing atlanta.com proxy -> Alice
SIP/2.0 180 Ringing Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob From: Alice Call-ID: a84b4c76e66710 Contact: CSeq: 314159 INVITE Content-Length: 0 |
F9 200 OK Bob -> biloxi.com proxy
SIP/2.0 200 OK Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 ;received=192.0.2.3 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob From: Alice Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 131 |
F10 200 OK biloxi.com proxy -> atlanta.com proxy
SIP/2.0 200 OK Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob From: Alice Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 131 |
F11 200 OK atlanta.com proxy -> Alice
SIP/2.0 200 OK Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob From: Alice Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 131 |
F12 ACK Alice -> Bob
ACK sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9 Max-Forwards: 70 To: Bob From: Alice Call-ID: a84b4c76e66710 CSeq: 314159 ACK Content-Length: 0 |
F13 BYE Bob -> Alice
BYE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10 Max-Forwards: 70 From: Bob To: Alice Call-ID: a84b4c76e66710 CSeq: 231 BYE Content-Length: 0 |
F14 200 OK Alice -> Bob
SIP/2.0 200 OK Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10 From: Bob To: Alice Call-ID: a84b4c76e66710 CSeq: 231 BYE Content-Length: 0 |
1. SIP消息头部主要字段:
· Request-URI:Request消息的第一行中method后面紧跟的部分就是Request-URI(本例中的sip:[email protected])。该值在消息经过Proxy之后就有可能发生变化,变成消息路径中Next Hop的URI。
· To:包含的是最终用户的Public address,消息无论被Proxy多少次该值都不会改变。当最终用户开始回应第一个Response消息时(比如本例中的180 Ring)会在To中加上本地唯一的一个tag值。
· From:包含Request消息发起者的URI,也不会被Proxy改变;在生成Reqeust消息时就会在后面加上一个本地唯一的tag值。
· Call-Id:用来标识一个唯一的Session,整个Session期间的所有消息的Session-Id都是相同的。
· Max-Forwards:消息可被转发的最大次数,每经过一个Proxy,该值就会被减一。
· CSeq:该属性由一个整数和一个method名字两部分组成;整数部分的作用是用来对同一个Session中的Request消息进行排序的;从第一个Invite消息发出后,随后的所有Request消息(ACK和Cancel除外)中的CSeq值都依次加一。比如Alice与Bob的通话过程中Alice想修改会话的一些属性,于是她便发起第二个Invite消息,这个Invite消息中的CSeq就需要加一;在比如Alice给Bob发送了一个Invite消息,而Bob发回的200 OK发生延时,于是Alice又发送第二个Invite消息,此时对第一个Invite消息的200 OK到达,Alice根据200 OK中的CSeq便可以知道这是对第一个Invite消息的应答。Request消息Cancel和Ack中的CSeq和与之对应的Invite消息中的CSeq值是一致的。
· Via:该属性记录了消息的路由。Request消息被生成的时候只有一个Via,那就是本地的URI,此后消息每经过一个Proxy,Proxy都会在消息中插入一个Via记录下自己的URI。当最终用户发挥Response消息时,会从Request消息中拷贝所有的Via,然后按照反序进行路由,每经过一个Proxy,该Proxy就会将包含自己URI的Via删除,这样当Response消息最终到达Request发起端的时候就只剩下一个Via了。
· Contact:该属性包含了用户可以被直接找到的一个URI,Request发起方会在Request消息中加入该值,接收方会在第一个Response(该例中的180 Ring)中加入该值。利用这个URI,此后再发起Request消息时就直接发送到对方了,而无需经过Proxy,比如本例中的F12 ACK消息,由于之前通过交换Contact值,Alice知道如何能直接找到Bob,于是在第一行的SIP-URI中填上Bob所提供的Contact值,将ACK消息直接发送给Bob而无需经过Proxy,注意To中仍然是原先的值。
· Route and Record-Route:这两个属性都是有Proxy加入的;上面提到Contact属性可以让随后的Reqeust消息绕过Proxy而直接发给最终用户。有时候处于安全或者其他方面的原因,Proxy希望所有的消息都必须经过Proxy,那么这时候Proxy就需要在经过它的第一个Request消息中插入该属性记录自己的URI,这样此后的Request消息就必须按照该属性中指定的路径路由。
2. 对以上几个头部属性简单概括一下:
· SIP-URI是一个Hop-to-Hop的属性,所以有可能被Proxy改变;
· From和To属性在消息的路由过程中一直保持不变;它们在Request消息中确定,此后对端发来的所有Response消息的From和To都是原样拷贝Request消息中的From和To;
· Via是用来帮助Response消息进行路由的,Contact是用来供随后的Request消息进行路由的。
参考资料:
1. “RFC 3261”- Section 4,Section 12,Section 17,Section 24;
2. “SIP Demystified”- Chapter 4, Chapter 5;