Compare Plans

2021-09-10

会话启动协议( SIP)（二）

8.3.4    响应消息格式和意义
响应消息格式为：
响应消息＝状态行
       ＊（通用头部
         I响应头部
        I实体头部）
空行
［消息体］
其中，状态行的格式为：
      状态行＝SIP版本一状态码一理由短语心
其中，状态码是3位整数，指示请求执行的结果。理由短语给出状态码的简短的文字描述，便于使用者理解。
       状态码共分为6类，其第1位数字指示响应类别，后两位数字表示该类中的具体响应。
①lxx：信息响应，即呼叫进展响应。表示响应已收到、正在处理该请求等。已定义4个响应状态，其理由短语分别为：
100：试呼中
180：振铃
181：呼叫正在前转
182：排队
@2xx：成功响应，表示请求已成功接收，完全理解并被接受。只定义了一个响应状态：
200:0K
(3)3xx：重定向响应，表示需采取进一步动作，以完成该请求。已定义6个响应状态：
300：多重选择
301：永久迁移
302：临时迁移
303：见其它
305：使用代理
380：替换服务
④4xx：客户出错，表示请求语法出错或无法在此服务器完成该请求。已定义23个响应状态。
⑤ 5xx：服务器出错，表示服务器不能完成合法的请术。已定义6个响应状态。
⑥ 6xx：全局故障，表示任何服务器都无法完成此请求。已定义4个响应状态。
       SIP沿用许多HITP/1.1现成的响应码。SIP/2.0新增的状态码从X80开始，以免和新定义的HITP状态码冲突。另外，SIP新增加1类6xx状态码。
       SIP响应码是可扩展的。不要求SIP应用程序理解所有已注册响应码的含义，但是它必须理解所有响应码的类别。不能识别的响应码则作为x00处理，此时，用户代理应向用户显示该响应的消息体，该消息体一般含有能解释该异常状态的可读信息。
8.3.5   SDP的使用
       SDP用于构成请求消息和2xx响应消息的消息体，供主被叫用户交换关于呼叫媒体的信息。
       I.媒体流的配置
       主叫和被叫的媒体描述必须完全对应，也就是说主叫会话描述中的第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/AVP 0
       a=rtpmap:0PCMU/8000
       m=video51372R1P/AVP31
       a=rtpmap:31H261／9000
       m=video53000RTP/AVP32
       a=rtpmap:32MpV／9000
       被叫Bob不想接收或发送第1个视频流，因此，他回送如下的媒体描述：
       v=O
       o=bJb28908447302890844730INIp4host.example.com
       c=INIp4host.example.com
       m=audio47920RTP/AVPOI
       a=rtpmap:0PCMU/8000
       a=  rtpmap:I  1016/8000
       m=VideoORTP/AVP31
       m=Video53000RTPIAVP32
       a=rtpmap:32MPV／9000
       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:2REGISTER
        Contact:*Expires：。
 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<Sip:a.g.bell@bell-tel.com〉
       To:T.Watson<sip: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=IN Ip4 Kton.bell-tel.com
       m=audio 3456RTP/AVPO 3 4 5
邀请抵达被叫端后，被叫UAS返回呼叫进展响应：
S→C:SIP/2.0100Trying
        Via:SIP/2. 0/UDP Kton.bell-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.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,2callersahead
        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,1callersahead
       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.0200OK
       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'monmyway
       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<Sip:a.g.hell@hell-tel.com〉
       To:T.Watson <sip:watson @ bell-tel.com〉；tag=37462311
       Call-ID:3298420296@kton.bell-tel.com
       CSeq:1INVITE
        3.呼叫终结
主叫或被叫都能发送BYE请求，以终结呼叫：
C-->S:BYEsip:watson@boston.hell-tel.comSIP/2.0
       Via: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:2BYE
上例表示主叫发起呼叫释放。如果被叫发起呼叫释放，只需将To域和Fmm域对换一下即可。
 
8.3.7呼叫控制功能扩展
为了更有效地支持补充业务和会议呼叫，IETF又定义了一些新的SIP头部字段。主要有下述4个。
I.Also
       可置于请求和响应消息的头部，指示消息接收者对该字段所列地址发出INVITE请求，这些请求消息应包含Request-By(“应某人请求”)字段其中置人含Also字段消息的From字段。这样，收到IN­VITE消息的端系统就知道此邀请是应谁的请求而转发过来的，应用程序就可执行相应操作完成对呼叫分支的控制。
Also字段内可包含多个地址，例如：
       Also ：sip:jones @ foo.com,sip:mueller @ bar.edu设A、B、C均为端系统，A向B发出邀请，同时请B再向C发出邀请，则其SIP控制流为：
A→B:INVITEBSIP/2.0
      Call-ID:19971214T123503.33@A
      Also ：C
      From:A
B-->A:SIP/2.0200OK
      Call-ID:19971214T123503.33@A
      From:A
B→C:INVITECSIP/2.0
       Call-ID:19971214T123503.33@A
       From:B
       Requested-By:A
       C-B:SIP/2.0 200 OK
       Call-ID:19971214T123503.33@A
       From:B
       图8.4给出使用Also字段的一个应用实例。在电信营销中，可用自动拨号器拨打选定的客户群，一旦拨通一个用户，立即将其转给营销员处理。设自动拨号器、营销员和客户分别记为A、B和C,则其控制信息流为：
电信营销实例
图8.4电信营销实例
①A---->C：发送INVITE;C---->A：回送200响应
②A---->B：发送INVITE,Also：B---->A:200
③B---->C：发送INVITE,Requested-By:A;C---->AB:200
④B---->A:BYE
⑤A---->C:BYE
       ALSO字段还可用于处理群地址。例如，G为群地址，它有三个成员：X、Y、z，则群邀请的SIP流为：
A---->G:INVITEGSIP/2.0
        From:A
        Call-ID:19971214T124523.00@A
G---->A:SIP/2.0200OK
        From:A
       Call-ID:19971214T124523.00 @A
       Also:X,Y,Z
A--->X:INVITEXSIP/2.0
        From:A
        Call-ID:19971214T124523.00@A
        Requested-By:G
A--->y: 的 ITE Y SIP/2.0
         From:A
        Call-ID:19971214T124523.00@A
         Requested-By:G
A--->Z:INVITEZSIP/2.0
        From:A
        Call-ID:19971214T124523.00@A
        Requested-By:G
2.Replaces
       该字段可用于请求和响应消息的头部，用法和Also相同，不同之处是它指示消息接收者向所列地址发送BYE消息，Call-ID应和含Replaces的消息相同。Replaces字段中也可以包含特殊的地址表示符”*"，指示消息接收者以新的连接代替呼叫标识为Call-ID的所有原有的呼叫分支。
设A、B为端系统，M为MCU。在A-B建立呼叫后，MCU要将此连接转成和它相连的集中式会议方式，则SIP 流可为：
A--->B:INVITEBSIP/2.0
          Call-ID:19971214T123503.33@A
          From:A
B---->A:SIP/2.0200OK
         Call-ID:19971214T123503.33@A
         From:A
M--->B:INVITEBSIP/2.0
Call-ID:19971214T123503.33@A
From:M
Replaces:*
B--->M:SIP/2.0200 OK
Call-lD:19971214T123503.33@  A
From:M
B--->A:BYEASIP/2.0
        Call-ID:19971214T123503.33@ A
         From:BRequested-By:M
A--->B:SIP/2.0200OK
         Call-ID:19971214T123503.33@A
         From:B
图8.5示出使用Replaces和Also字段的一个应用实例。例中，A、B、C、D4个用户原来是全网状会议连接，今要转成至MCU的集中式会议连接。为简明计，图中只给出A、B、C三用户连接的转换，其SIP控制过程为：
网状连接至MCU连接转换实例
图8.5   网状连接至MCU连接转换实例
①A--->MCU：发送INVTTE Also:B,C
②MCU--->B：发送INVITE;Replaces:A
③)MCU--->C：发送INVITE,Replaces:A,B
④B--->A：发送BYE,Requested-By:MCU
⑤C--->B：发送BYE,Requested-By:MCU
⑥c---> A: 发送BYE,Requested-By:MCU
       如果消息中既含Also字段又含Replaces字段，则必须先完成Al­so字段指定的邀请，才能终结Replaces字段指定的呼叫分支，即先建立新的呼叫，后拆除老的呼叫。
3.Requested-By
该字段和Also及Replaces字段配用，已如上所述。
4.Call-Disposition
       该“呼叫处理”字段仅用千请求消息的头部，供客户向服务器指示如何处理呼叫。定义了如下4种处理方式，可以指示使用1种处理方式或组合使用多种处理方式：
•   all：如果SIP请求地址的用户名部分是群用户，则该方式指示代理服务器或重定位服务器将此地址解析为一组成员地址，返回300（ 多重选择）响应，成员地址含于Also头部字段中。
•  do-not-forward：＂不要前转”。禁止代理服务器将呼叫转给另一个人。例如，该呼叫是指定受话人的呼叫，或被叫不希望占线时转给秘书等。
•  queue:＂排队＂。若被叫暂时不可达，如正在进行另一个呼叫，主叫可以指示呼叫排队，而不是立即拒绝。
•  do-not-respond:”不要响应＂。指示被叫不要回发响应（包括进展响应和最终响应），可用于向多播组发送的邀请。

联系我们

028-83110277

IP电话机、视频电话机供应商

手机：

成都世讯电科信息技术有限公司

成都世讯电科信息技术有限公司是一家多媒体融合通信解决方案及运营服务提供商，公司专注于为广大用户提供简单高效的通信产品和真正符合行业用户需求的行业应用解决方案，让用户享受到个性化、私密性强又具开放性、兼容性强又易于管理的高科技服务，帮助用户实现办公及运营通信的现代化与网络信息化。

公司拥专注于IP多媒体解决方案的应用与实施,有IP多媒体通信系统(IPBX)、IP多媒体通信平台定制与搭建（运营、对讲广播、门禁、调度、音视频会议及与视频监控交互式应用等）、IP电话机、视频电话机、项目租赁、云通信及系统集成等服务。

电话：028-83110277

Q Q：86313858

客服 电话