SIP控制流示例

8.3.4响应消息格式和意义

响应消息格式为：响应消息＝状态行

＊（通用头部

I响应头部

I实体头部）

空行

［消息体］

其中，状态行的格式为：

状态行＝SIP版本一状态码一理由短语↘

其中，状态码是3位整数，指示请求执行的结果。理由短语给出状态码的简短的文字描述，便于使用者理解。

状态码共分为6类，其第1位数字指示响应类别，后两位数字表示该类中的具体响应。

①lxx：信息响应，即呼叫进展响应。表示响应已收到、正在处理该请求等。已定义4个响应状态，其理由短语分别为：

100：试呼中

180：振铃

181：呼叫正在前转

182：排队

②2xx：成功响应，表示请求已成功接收，完全理解并被接受。只定义了一个响应状态：

200:0K

③3xx：重定向响应，表示需采取进一步动作，以完成该请求。已定义6个响应状态：

300：多重选择

301：永久迁移

302：临时迁移

303：见其它

305：使用代理

380：替换服务

④4xx：客户出错，表示请求语法出错或无法在此服务器完成该请求。已定义23个响应状态。

⑤5xx：服务器出错，表示服务器不能完成合法的请术。已定义6个响应状态。

⑥6xx：全局故障，表示任何服务器都无法完成此请求。已定义4个响应状态。

SIP沿用许多HTTP/1.1现成的响应码。SIP/2.0新增的状态码从X80开始，以免和新定义的HTTP状态码冲突。另外，SIP新增加1类6xx状态码。

SIP响应码是可扩展的。不要求SIP应用程序理解所有已注册响应码的含义，但是它必须理解所有响应码的类别。不能识别的响应码则作为x00处理，此时，用户代理应向用户显示该响应的消息体，该消息体一般含有能解释该异常状态的可读信息。

8.3.5   SDP的使用

SDP用于构成请求消息和2xx响应消息的消息体，供主被叫用户交换关于呼叫媒体的信息。

1.媒体流的配置

主叫和被叫的媒体描述必须完全对应，也就是说主叫会话描述中的第n个媒体流（第n个“m=“行）对应于被叫会话描述中的第n个媒体流。所有媒体描述都应包含“a=rtpmap"描述行，指明从RTP净荷类型至编码的映射，其目的是易于适应静态净荷类型至动态类型的转换。

如果被叫既不想发送也不想接收主叫提出的某个媒体流，则可在其会话描述中将该媒体流的端口号置成零。

例如，主叫Alice在其INVITE请求中包含如下会话描述，它包括一个音频流和两个双向视频流，分别采用H.261（净荷类型31)和MPEG（净荷类型32):

v=0

o=alice28908445262890844526INIP4host.anywhere.com

c=INIP4host.anywhere.com

m=audio49170RTP/AVP0

a=rtpmap:0PCMU/8000

m=video51372R1P/AVP31a=rtpmap:31H261／叩

m=video53000RTP/AVP32a=rtpmap:32MpV／叩

被叫Bob不想接收或发送第1个视频流，因此，他回送如下的媒体描述：

v=O

o=bJb28908447302890844730INIp4host.example.com

c=INIp4host.example.com

m=audio47920RTP/AVPOIa=rtpmap:0PCMU/8000

a=rtpmap:I1016/8000m=VideoORTP/AVP31

m=Video53000RTPIAVP32

a=rtpmap:32MPV／90000

2.单播SDP值的设定

如果主叫的会话描述包含一个媒体流，列为只发或只收，则表示主叫只想发送或接收该媒体流。对于被叫亦然如此。

对于只收和发／收媒体流，会话描述中的端口号和地址指示会话描述的接收者应将该媒体流送往何处。对于只发媒体流，地址和端口号没有意义，应置零。

每个媒体流的净荷类型列表传送两个信息，即主叫或被叫能够发送或接收的编译码以及用以标识这些编译码的RTP净荷类型号。对于只收或发／收媒体流，主叫应在INVITE或ACK的会话描述中列出它能支持的所有编译码。对于只发媒体流，主叫应只指示它想发送的编译码。同样，对于只收媒体流，净荷类型号指示主叫期望接收该类编译码的RTP数据包中的净荷类型字段值。对于只发媒体流，净荷类型号指示主叫计划发送该类编译码的R怍数据包中的净荷类型字段值。对于发／收媒体流，净荷类型号则表示主叫期望收发的净荷类型字段值。

如果某媒体流被主叫列为只收，则被叫在响应中列出它从请求消息中选取的想要使用的编译码。如果某媒体流被主叫列为只发，则被叫在响应中列出它从请求消息中选取的愿意接收的编译码。如果某媒体流为收／发数据流，则被叫列出它从INVITE中选取的能够发送和接收的编译码。对应于某一编译码实际使用的净荷类型号，被叫会话描述必须和主叫会话描述完全一致。

如果对于某一媒体流，主叫和被叫没有公共的媒体格式，被叫仍然必须返回该媒体流的“m=“行，但是置其端口号为零，且不列净荷类型。

如果所有媒体流均尤公共的媒体格式，则被叫回送400响应（“坏请求”)，并加入304警告头部字段（“无媒体类型”)。

3.多播操作

多播媒体会话中只发和只收的含义和单播会话不一样。在多播中，只发表示会话描述的接收方（主叫或被叫）应只向指示的地址和端口发送媒体流。只收表示会话描述接收方应只在指示的地址和端口上接收媒体流。

对于多播来说，接收和发送多播地址是相同的，所有通信方都使用相同的端口号接收媒体数据。如果被叫接受主叫提供的会话描述，则被叫可以选择不包含会话描述或者在响应中将主叫的会话描述返送回去。

被叫在返回会话描述时，可以去除某些净荷类型，或置某些端口号为零，藉此向主叫表明被叫不支持去除的媒体流或媒体类型。被叫不允许改变媒体流的只发、只收或收／发特性。

如果被叫根本不支持多播，应回送400状态响应和330警告（“多播不可用”)。

4.延时媒体流

在某些情况下，例如主叫实际上是一个和其它协议互通的网关，该协议要求在呼叫建立之后进行媒体格式协商，这样，主叫在发送INVITE时还不知道它能支持哪些媒体格式。此时，主叫发出的IN­VITE请求中的会话描述可以不含媒体描述行。被叫应解释为：主叫想参加会话描述说明的多媒体会话，但是媒体流还未知，被叫应回送会话描述，指明它愿意支持的媒体流和格式。一旦网关协商完成后，主叫可通过ACK请求或重新发送一个INVITE请求修改被叫的会话描述。

5.媒体流保持

如果一方要使另一方进入保持状态，即暂时停止发送一个或多个媒体流，则它可以向对方重新发送一个INVITE请求，其会话描述和原来邀请（或响应）中的描述相同，只是“c=”行中保持媒体流的地址置于全零(0.0.0.0)。重发INVITE请求的Cseq序号需递增，以区别于原来的邀请。最后说明一点，SDP会话描述是作为消息体置入SIP消息中的，它用于请求消息和2xx响应消息。其它响应消息包含的消息体则为文本描述，给出呼叫进展信息和异常原因的说明。为此，SIP定义了实体头部字段，说明消息体的类型和大小。计有如下3个实体字段：

．内容类型(Content-Type)：指明消息体的类型。计有两种类型。application,1sdp：表示是SDP会话描述；text/html：表示是普通文本或html格式描述。

．内容编码(Content-Encoding)：补充说明消息体类型，使用户可以采用压缩编码编辑消息体。

．内容长度(Content-Length)：给出消息体的字节数。

8.3.6   SIP控制流示例

本小节给出几种典型应用情况下的SIP控制流示例。为简明计，未列出消息体和相应的实体头部字段。

1.登记

设用户在主机saturn.bell-tel.com开机后经由多播方式在本地SIP服务器bell-tell.com上登记。例中，saturn主机上的用户代理期望在UDP端口3890接收SIP请求。则登记请求消息为：

C→S:REGISTERsip:bell-tel.comSIP/2.0

Via:SIP/2.0/UDPsatum.bell-tel.com

From:sip:watson@bell-tel.com

To:sip:watson@bell-tel.com

Call-ID:70710@satum.bell-tel.com

CSeq:1REGISTER

Contact:(sip:watson@saturn.bell-tel.com:3890;

transport=udp〉Expires:7200

该登记生存期为2个小时。登记后到达sip:bell-tel.com的关于wat­son@bell-tel.com的邀请都重定向送至watson@saturn.bell-tel.com,

UDP端口号为3890。

如果Watson在旅行时又想将邀请转至某在线服务点，则应首先删除原先的位置，然后更新其登记。其登记请求消息格式为：

C→S:REGISTERsip:bell-tel.comSIP/2.0

Via:SIP/2.0/UDPsaturn.bell-tel.com

From:Sip:watson@bell-tel.com

To:Sip:watson@bell-tel.com

Call-ID:70710@satum.bell-tel.com

CSeq:2 REGISTER

Contact:*

Expires：0

C→S:REGISTERsip:bell-tel.comSIP/2.0

Via:SIP/2.0/UDPsaturn.bell-tel.com

From:Sip:watson@bell-tel.com

To:Sip:watson@bell-tel.com

Call-lD:70710@satum.bell-tel.com

CSeq:3REGISTER

Contact:Sip:tawatson@example.com

此时，服务器将把至Watson的所有请求前转至位于example.com的服务器，目的地址为tawatson@example.com。为了使example.com处的服务器能够找到Watson，他必须向该服务器发送一个REGISTER,或者用其它方法告之其当前位置。

2.两方呼叫

设Bell呼叫Watson,Bell表示他能够接收RTP音频编码O(PC­MU)、3(GSM)、4(G.723)和5(DVI4)。首先，Bell发出邀请：

c→s:INVITEsip:watson@boston.bell-td.comSIP/2.0

Via:SIP/2.0/UDPKton.bell-tel.com

From:A.Bell@bell-tel.com〉

To:T.Watson@bell-tel.com〉

Call-lD:3298420296@kton.bell-tel.com

CSeq:1INVITE

Subject:Mr.Watson,Comehere

Content-Type:application/sdpContent-Length：…

v=O

0=bell536557652353687637INIP4128.3.4.5

s=Mr.Watson,comehere

c=INIp4Kton.bell-tel.com

m=audio3456RTP/AVPO345

邀请抵达被叫端后，被叫UAS返回呼叫进展响应：

S→C:SIP/2.0 100 Trying

Via:SIP/2.0/UDPKton.bell-tel.com

From:A.Bell@bell-tel.com〉

To:T.Watson@bell-tel.com〉;tag=37462311

Call-ID:3298420296@kton.bell-tel.com

CSeq:1INVITE

Content-Length:0

S→C:SIP/2.0 180 Ringing

Via:SIP/2.0/UDPKton.hell-tel.com

From:A.Bell(Sip:a.g.bell@bell-tel.com〉

To:T.Watson(Sip:watson@bell-tel.com〉;tag=37462311

Call-ID:3298420296@kton.bell-tel.com

CSeq:1INVITE

Content-Length:0

S→C:SIP/2.0182Queued,2callers ahead

Via:SIP/2.0/UDPKton.hell-tel.com

From:A.Bell(Sip:a.g.bell@bell-tel.com〉

To:T.Watson(Sip:watson@bell-tel.com〉;tag=37462311

Call-ID:3298420296@kton.bell-tel.com

CSeq:1INVITE

Content-Length:0

S→C:SIP/2.0182 Queued,1callers ahead

Via:SIP/2.0/UDPKton.bell-tel.com

From:A.Bell(Sip:a.g.bell@hell-tel.com〉

To:T.Watson(Sip:watson@hell-tel.com〉;tag=37462311

Call-ID:3298420296@kton.bell-tel.com

CSeq:1INVITE

Content-Length:O

呼叫建立成功后，返回200响应，同时用SDP告之选定的媒体格式：

S→C:SIP/2.0200 OK

Via:SIP/2.0/UDPKton.bell-tel.com

From:A.Bell(Sip:a.g.bell@bell-tel.com〉

To:T.Watson(Sip:watson@hell-tel.com〉;tag=37462311

Call-ID:3298420296@kton.bell-tel.com

CSeq:1INVITE

Contact:Sip:watson@boston.bell-tel.com

Content-Type:application/sdp

Content-Length：…

V=O

0=watson48589494858949INIP4192.1.2.3

s=I'm on my way

c=INIP4boston.hell-tel.com

m=audio5004RTP/AVPO3

上例表示，被叫UAS收到呼叫邀请后，首先立即证实(100响应），然后经数据库检查后振铃(180响应），接着呼叫排队，周期性状态更新。

Watson告之Bell，他只能接收PCMU和GSM编码的音频。Wat­son将把音频数据发往地址kton.hell-tel.com的端口3456,Bell则发往boston.bell-tel.com的端口5004。

媒体会话为一个RTP会话。Watson将在端口5005接收RTCP包，Bell则在端口3457接收RTCP数据包。

由于双方己就媒体达成一致意见，Bell就发送证实请求，请求中无需再带SDP描述：

C-->S:ACKsip:watson@boston.hell-tel.comSIP/2.0

Via:SIP/2.0/UDPKton.bell-tel.com

From:A.Bell@hell-tel.com〉

To:T.Watson@bell-tel.com〉；tag＝37462311

Call-ID:3298420296@kton.bell-tel.com

CSeq:1INVITE

3.呼叫终结

主叫或被叫都能发送BYE请求，以终结呼叫：

C-->S:BYEsip:watson@boston.hell-tel.com

SIP/2.0Via:SIP/2.0/VDPKton.hell-tel.com

From:A.Bell(Sip:a.g.bell@bell-tel.com〉

To:T.A.Watson(Sip:watson@bell-tel.com〉;tag=37462311

Call-ID:3298420296@kton.bell-tel.com

CSeq:2 BYE

上例表示主叫发起呼叫释放。如果被叫发起呼叫释放，只需将To域和Fmm域对换一下即可。