NGN学习笔记3——软交换中的协议1--SIP、SIP-I\SIP-T\BICC

妖狐艹你老母 2024-04-19 13:38 2阅读 0赞

1.Overview：

[![image][]][image 1]

2.SIP协议：

**1）概述**

SIP: Session Initiation Protocol，由IETF制定，最早由MMUSIC工作组提出，现在主要由SIP工作组负责维护和后期扩展，是一种轻量级的应用层通用信令协议，用于多媒体通信控制，可建立、修改和终止IP网上的语音和多媒体会话。

典型的SIP梯形网络结构：

[![image][image 2]][image_image 2]

SIP的Offer/Answer模型：

也称为会话协商模型，以在对等功能实体之间进行会话协商通过在SIP消息的消息体中包含SDP描述完成。、

*  Offer:包括媒体类型、媒体格式、地址
 *  Answer:是否接收媒体类型、媒体格式、地址

在会话过程中，任何一方可以通过Offer/Answer模型修改会话属性。

**2）发展和应用情况：**

*  1999年，MMUSIC工作组推出SIP V1.0 (RFC2543)。
 *  2003年，SIP工作组推出SIP V2.0 (RFC3261)目前已进行了许多扩展，并被3GPP/3GPP2、OMA、ETSI、ITU-T等标准化组织广泛采纳。

**3）相关标准：**

a）SIP核心标准：

[![image][image 3]][image_image 3]

b）SIP扩展标准：

IETF针对SIP的不同应用需求制定了上百篇SIP扩展RFC，

SIP相关RFC：  
3261-32xx, 33xx, 34xx, 35xx, 36xx, 37xx, 38xx, 39xx, 40xx,  
41xx, 42xx, 43xx, 44xx, 45xx, 46xx, 47xx, 48xx, 49xx, 50xx,   
51xx, 52xx, 53xx, 54xx, before 3261

**4）SIP基本功能：**

*  用户定位：确定被叫用户通信所使用的终端系统的位置
 *  用户能力协商：确定所用媒体类型和媒体参数
 *  用户可用性判断：确定被叫用户是否空闲以及是否愿意加入会话
 *  邀请用户加入会话（呼叫建立）：邀请和提示被叫用户，在主被叫间传递控制参数是SIP的主要功能
 *  呼叫处理：对呼叫进行终结和转移等

**5）SIP的特点**

*  基于文本的协议：简单灵活，便于扩展，易于用Java、Perl等面向对象的语言实现，易于调测排错
 *  独立于底层传输协议：可工作在UDP、TCP、SCTP等协议之上，消息的格式及操作
 *  过程与传送协议无关：推荐首选UDP，可以减少呼叫建立时延，便于应用采用多播机制
 *  呼叫和媒体控制信息同时传送：在传送呼叫控制信令的同时，还可以在消息文本中通过SDP传送呼叫的媒体类型和格式等信息，以加快呼叫建立的速度便于增加新的应用或媒体
 *  支持用户移动性
 *  支持直接路由和代理路由

**6）网络中元素：**

SIP基本网络模型：客户-服务器协议，在语法和语义上与HTTP类似，SIP客户发出请求，SIP服务器接收请求并进行响应

[![image][image 4]][image_image 4]

a）SIP用户代理UA：

端系统中的SIP应用称作SIP用户代理(UA)，UA = UAC + UAS，UA最基本的功能是支持SIP请求和应答的正确发送和接收。

*  用户代理客户(UAC) - 发送SIP请求
 *  用户代理服务器(UAS)-侦听呼叫请求，提示用户或执行程序作出响应

B2BUA：在一次呼叫中既充当UAC又充当UAS角色，UAC根据UAS接收到的请求消息构造新的请求消息进行发送。

b）SIP代理服务器Proxy Server：

**负责将来自客户的请求转发** 到下一跳SIP代理服务器或重定向服务器或最终的UAS，也可能将请求分发到多个下一跳服务器。

主要功能：寻址、路由、转发，可以解释、翻译、改写SIP请求。

分类：

*  有状态代理服务器：作为虚拟的UAC/UAS，维持事务/对话状态机，需要记忆入请求和出请求
 *  无状态代理服务器：接收请求，进行必要的翻译，发出请求，不需要记忆任何请求信息
 *  分叉代理服务器：必须有状态记忆能力，以便将请求和应答进行匹配
 *  非分叉代理服务器：可以无状态记忆能力

c）SIP重定向服务器Redirect Server：

通过响应告诉请求的发起方下一跳服务器的地址，然后**由请求发起方根据此地址向下一跳服务器重新发送请求** 。

[![image][image 5]][image_image 5]

与Proxy Server的区别

*  重定向服务器的目的是提供可供选择的地址列表供用户定位SIP UA，代理服务器则是代替用户继续后面的定位尝试
 *  重定向服务器只提供地址解析服务，类似于DNS
 *  重定向服务器不主动发送SIP请求
 *  重定向服务器需要维持事务状态

d）SIP注册服务器Register Server

通过注册过程接收客户当前的位置信息，并对位置服务器进行添加、修改、查询等操作。通常与代理服务器或重定向服务器放在一起。

[![image][image 6]][image_image 6]

功能：

*  接收用户的注册请求
 *  记录用户的SIP地址和IP地址的绑定关系
 *  提供注册认证功能，是实现用户移动性的基础

e）位置服务器

存储并向用户返回可能的位置信息，在SIP网络架构中起到重要作用的Internet公共服务器。位置服务器的信息可能来自SIP注册服务器，也可能通过其他渠道获取。位置服务器与SIP服务器之间通过使用**LDAP协议** 进行通信，位置服务器可能返回多个位置信息，重定向服务器和代理服务器可以采用不同的方式来处理这多个位置信息。

我们看一个呼叫的过程体会一下各个功能实体的作用：

[![image][image 7]][image_image 7]

**7）SIP协议的结构及其位置**

[![image][image 8]][image_image 8]

各层功能相对独立。层与层之间松散耦合，SIP独立于网络传输协议。

事务用户层

*  负责处理请求或响应、产生请求或响应
 *  负责客户事务(CT)和服务器事务(ST)的创建和销毁
 *  通过事务层完成消息的发送和接收
 *  除无状态Proxy外，所有SIP实体都包含事务用户层

事务层

*  接收来自事务用户层的请求或响应，并向下传给传输层进行传送，同时完成重传、响应与请求之间的匹配以及应用层超时处理等
 *  用户代理、有状态Proxy都包含事务层，无状态Proxy不包含事务层

传输层

*  定义了客户如何发送请求和接收响应以及服务器如何接收请求和发送响应
 *  该层从事务层接收消息，或将网络中收到的消息传给对应的事务
 *  所有的SIP实体（包括客户和服务器）都包含传输层

语法和编码层

*  定义SIP操作的语法和编码表示，使用BNF范式描述

**8）SIP消息：**

a）简述：SIP消息用于建立或终结会话，采用纯文本形式，用于Internet多媒体会议，Internet电话呼叫或多媒体信息流分配。SIP中最重要的消息是邀请“INVITE”请求消息

b) 类型：

*  请求消息：请求行=方法 +空格 +请求地址 +SIP版本号 +空行。通过一个请求行作为起始行，请求行包括了方法名、请求的URL、协议版本号、中间用空格分开。
 *  应答消息:状态行=SIP版本+空格+状态码+空格+相关文本短语+空行，SIP应答消息状态码与功能

c）消息体通用结构：

> SIP消息＝起始行（请求行/状态行）  
> 一个或多个消息头域行  
> CRLF（空行）  
> \[消息体\]
> 
>  *  start-line（起始行）：在请求消息中称为请求行，在响应消息中称为状态行，给出版本号、调用的请求操作、被邀请用户的当前地址、响应类型等信息。
>  *  headers 域：携带呼叫属性和业务信息，用于指示客户机/服务器如何处理消息，许多头域来自HTTP（From, To, …）。有些是SIP特有的（Call-ID, Cseq, Via, …）。
>  *  body 域：携带呼叫或会话描述，可以使用SDP格式，描述会话的音频/视频编解码方法、参数、地址以及会话的时间等信息。在响应消息中还可能是原因和进展指示文本。

d）SIP消息起始行：

*  请求消息：客户机->服务器，“请求行（Method  Request-URI  SIP-Ver）”
    
     *  INVITE：邀请一个用户加入一电话呼叫或会议
     *  ACK：证实客户已收到对INVITE请求的最终响应，仅和INVITE方法配套使用
     *  BYE：终止用户之间的会话
     *  OPTIONS：请求用户能力信息，但不建立呼叫
     *  CANCEL：终止未决的请求
     *  REGISTER：将用户的位置信息送往SIP注册服务器

RFC3261中定义的基本方法Method：

注：SIP方法可以进行扩展

Request-URI 请求去往的服务器的地址

SIP-VerSIP版本号目前设为SIP/2.0

响应消息：服务器->客户机，“SIP响应消息＝状态行（Status-code Reason-phase   SIP-Ver）”

*  中间响应：报告呼叫进展情况，1xx，即呼叫进展响应，指示请求已被服务器接收并正在处理，但尚未产生明确的响应，目的是防止UAC重传请求，一 般不需要证实。100 trying、180 ringing、181 call is being forwarded、182 queued、183 call progress
 *  最终响应：报告呼叫成功或失败，2xx，3xx，4xx, 5xx, 6xx。

2xx，成功响应。表示请求已成功接收、完全理解并被接受，如200 OK

3xx，重定向响应。需要采取进一步动作来完成该请求，如301、302、305

4xx，客户出错。请求语法出错或无法在此服务器完成该请求，如401、403、407，……

5xx，服务器出错。服务器不能完成合法的请求，如503、504，……

6xx，全局故障。任何服务器都无法完成该请求

注：SIP响应码可以进行扩展

e）SIP消息头域：

用于携带呼叫属性和业务信息，用于指示客户或服务器如何处理消息，语法和语义类似HTTP。同一头域名的多个头域值可以位于同一头域行，头域值之间 用逗号隔开。头域存在多个参数时，头域值与参数之间用逗号隔开。RFC3261定义了44个头域，头域的顺序没有严格限制，但建议将需要Proxy处理的 头域放在前面。From、To、Call-ID、CSeq、Via和Max-Forwards这六个头域在所有的请求消息中都必须出现。Contact头 域在INVITE请求消息的头域中必须出现。

通用格式：field-name: field-value \*(;parameter-name=parameter-value)

*  Call-ID：标识一个特定的邀请，或来自一个UAC的所有注册请求；标识一个特定的邀请和与这个邀请相关的所有后续事务；Call-ID代表了一个或多个用户之间共享的信令关系。
 *  CSeq：在同一对话中标识不同事务的顺序，保证了同一用户发送的不同请求消息间的顺序，包括一个十进制的序列号和一个请求方法名；CSeq: 4711 INVITE。
 *  Max-Forwards：请求可被代理转发的最大跳数（0-255），建议值70，Max-Forwards: 70。
 *  From：标识请求的发送方，可以包含一个“display-name”参数和“tag”参数，From: "A. G. Bell" ;tag=a48s。
 *  To：指示请求的逻辑接收者，**在整个对话的建立及持续过程中不变，也不能被代理改变** 。它通常包含目的方的公开地址（AOR），可以包含一个“display-name”参数和“tag”参数，To: “The Operator”;tag=287447。
 *  Contact：UAC或UAS的直接联系地址，可以使SIP服务器在路由第一个消息后，不再需要存在于信令通道中。Contact: "Mr. Watson" [watson@worcester.bell-elephone.com][watson_worcester.bell-elephone.com] >; q=0.7; expires=3600 。
 *  Content-Type：指示消息体的媒体类型，Content-Type: application/sdp。
 *  Content-Length：以十进制表示消息体的字节数，Content-Length: 349。
 *  Via：存储所有处理请求的代理的地址，表示到目前为止经过的路径，可以使响应消息沿请求消息的原路径返回，还可用于检测环路，由传输层协议、客 户名和地址，及接收响应的端口号组成。Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7
 *  Record-Route：由始终位于信令路径的Proxy使用，由Proxy在请求消息中插入，以强制要求该对话中的后续请求通过该Proxy路由。
 *  Route：表示需要按照头域中列出的Proxy对请求进行路由 Route: ,

f）SIP消息体：

SIP消息头只涉及会话建立、终结和修改，并不涉及媒体控制。SIP会话的媒体类型、编码格式、收发地址等信息由SIP的消息体（SDP）来描述。SIP请求和响应消息都可以包含消息体  
SIP消息体通常在UA之间进行端到端的传送，对中间代理透明。SDP是用于描述多媒体会话信息的协议，目的为告知某会话的存在给出参与会话所必需的信息，包括会话的地址、时  
间、媒体类型等信息。SDP定义了会话描述的统一格式，但不定义SDP消息的传送，也不支持媒体编码方案的协商。SDP描述的信息封装在传送协议中传送。 典型的会话传送协议包括：SAP、SIP、RTSP、HTTP、使用MIME的E-mail。采用SAP、SIP或RTSP传送SDP信息的数据报格式。

[![image][image 9]][image_image 9]

SDP会话描述作为消息体放在SIP消息中，只有请求消息和2xx响应消息包含SDP消息体，其它响应消息包含的消息体为文本描述，给出呼叫进展信息和异常原因的说明。

SIP消息体头部中用于说明消息体类型和大小的部分：

*  内容类型(content-type)：指明消息体的类型。共有两种类型。application/sdp表示是SDP会话描述；text/html表示是普通文本或html格式描述
 *  内容编码(content-encoding)：补充说明消息体类型，使用户可以采用压缩编码编辑消息体
 *  内容长度(content-length)：给出消息体的字节数

SDP内容：

*  会话名和目的
 *  会话激活的时间区段
 *  构成会话的媒体
 *  媒体类型（如音频、视频、数据）
    
     *  传送协议（如UDP、H.320）
     *  媒体格式（如H.261视频）
     *  媒体地址和端口
 *  接收媒体所需的信息（地址、端口、格式等）
 *  会话所用的带宽信息（任选）
 *  会话负责人的联系方式（任选）

SDP格式：

[![image][image 10]][image_image 10]

SDP描述由多个文本行构成 =，纯文本描述——具有可携带性，紧凑型编码——各字段有严格的顺序和格式。

SDP描述包括两部分

*  会话级描述：给出适用于整个会话和所有媒体流的描述信息，以“v=”文本行开始，一个会话描述可能包含一个（SAP中）或多个会话级描述（SIP、RTSP等）。
 *  媒体级描述：给出只适用于该媒体流的信息，以“m=”文本行开始，一个会话描述可以包含零个或多个媒体级描述。

g）SIP举例：

SIP请求消息举例——INVITE

[![image][image 11]][image_image 11]

SIP响应消息举例——200 OK

[![image][image 12]][image_image 12]

h）SIP寻址和路由

寻址：在SIP中，用户通过SIP/SIPS URI进行寻址，SIP URI有以下几种形式。

*  sip:user@domain--sip:wei.wang@alcatel.com
 *  sip:user@host--sip:manu5@bellsip.alcatel.be
 *  sip:user@IP\_address--sip:manu@198.137.241.30
 *  sip:phone\_number@gateway--sip:+86-1-62409735@beijing.net2phone.com

[![image][image 13]][image_image 13]

路由：

UAC的路由机制--

相关头域：

*  Request-URI：位于请求行，一般与To头域的值一致
 *  Route：可选头域，只出现在预设路由的情况

路由策略：

*  存在Route头域时，按照Route头域的第一个URI路由请求消息。
 *  不存在Route头域时，按照Request-URI对应的IP地址发送请求消息

UAS的路由机制--应答消息根据Via头域的值与沿着请求消息相反的路径返回，在不要求代理转发请求时，应答消息直接发送给请求消息的Contact头域指示的UAC。

Proxy的路由机制--对请求消息的路由策略，根据Request-URI头域的值进行路由，根据Route头域的值进行路由；对应答消息的路由策略，根据Via头域的内容进行转发。

i）SIP的呼叫/对话/会话/事务：

Call——呼叫：在对等SIP UA之间建立的联系，由Call-ID唯一标识

Dialog——对话：在两个UA之间保持一定时间的对等SIP关系，由SIP消息（如对INVITE的2xx响应）建立，由Call-ID（呼叫标识）、local tag（本地标签）和 remote tag（远端标签）共同标识。

Session——会话：在对等参与者之间建立的媒体流连接。在使用SDP进行会话描述时，会话由SDP用户名、session id、网络类型、地址类型以及源域的地址元素共同定义。

[![image][image 14]][image_image 14]

SIP Transaction——SIP事务：发生在一个客户和一个服务器之间，包括从客户发出一个请求到服务器回送终结响应之间的所有消息。

事务是一个垂直的概念，描述了SIP实体在事务层应完成的功能（对话则描述了对等UA之间的交互关系，一个对话往往需要通过多个事务来完成）事务只存在于UA和有状态的Proxy中。事务通过维护有限状态机来提供相应的功能，SIP定义了四个事务状态机。

*  INVITE CT
 *  Non-INVITE CT
 *  INVITE ST
 *  Non-INVITE-ST

每个事务状态机有自身的定时器、重传规则、过滤规则和终止规则。

[![image][image 15]][image_image 15]

g）SIP典型流程

[![image][image 16]][image_image 16]

用户注册流程：

[![image][image 17]][image_image 17]    
直接呼叫控制流程：

[![image][image 18]][image_image 18]

代理呼叫控制流程：

[![image][image 19]][image_image 19]

重定向呼叫控制流程：

[![image][image 20]][image_image 20]

第三方呼叫控制模型：

[![image][image 21]][image_image 21]

k）SIP在软交换网络中的应用

[![image][image 22]][image_image 22] [![image][image 23]][image_image 23]

l）SIP的扩展

**SIP方法扩展**  
INFO  
UPDATE、MESSAGE  
SUBSCRIBE/NOTIFY  
REFER  
PRACK  
PUBLISH  
……  
**SIP消息头域和参数扩展**  
refered-by  
Refer-to  
……  
**SIP消息体扩展**  
XML消息体  
Multipart消息体  
ISUP消息体

**3.SIP-T/SIP-I/BICC协议**

**1）简介：**

SIP-T--Session Initiation Protocol for Telephones，SIP协议针对电信业务的扩展，RFC3372、RFC3398。

SIP-I--SIP with Encapsulated ISUP，由ITU-T制定，是SS7 ISUP与SIP的互通协议，Q.1912。

**2）目的：**

使基于SIP的软交换网络能够与传统电信网络互通，使SIP网络桥接PSTN网络时能够透明传递ISUP消息。

**3）内容：**

制定了详细的SIP消息与ISUP消息的映射，保证ISUP信令的透明传递，通过 “封装” 的方法实现。

**4）二者区别：**

SIP-T协议：制定了基本的SIP-ISUP映射规则与映射方法，描述简单，易于理解，但可实现性差，不易操作。

SIP-I协议：继承了SIP-T协议的规则与方法，进一步严格规范了消息与参数的映射，描述复杂，可操作性好，可实现性强，扩展了对补充业务的描述已经考虑了3GPP的相关内容。

**5）SIP 网络与PSTN网络互通：**

[![image][image 24]][image_image 24]

SIP-T/SIP-I协议用于指导软交换完成SIP-ISUP的映射。

[![image][image 25]][image_image 25]

参考点A：ISUP over SIGTRAN  
参考点B：Megaco/H.248  
参考点D：SIP-T/SIP-T

SIP-T/SIP-I用于指导软交换之间的交互，以透明传递ISUP消息。

[![image][image 26]][image_image 26] [![image][image 27]][image_image 27]

**6）BICC协议**

BICC协议由ITU-T SG11定义提供承载无关的呼叫控制功能，**与IETF的SIP协议相对应。**

BICC协议基于ISUP标准（Q.761-765），并对其进行了增强，以支持分组网承载信息的传送。承载信息采用BICC的APM机制

BICC CS1支持基于ATM承载上的窄带业务的提供。BICC CS2进行了进一步的增强，可以支持基于IP的承载信息的传送。

BICC呼叫控制流程举例：

[![image][image 28]][image_image 28][ ][image_image 28]

转载于:https://my.oschina.net/alphajay/blog/4946

[image]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/7fe3f68d982a4095a589084bf79251da.png
[image 1]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_2_633975947898332500.png
[image 2]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_14_633975948033332500.png
[image_image 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/3d77b043957b4b4a977041626f6a6f03.png
[image 3]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_1_633975948061301250.png
[image_image 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/d2184afd688c4f9aa1c5c8ffcdb158d1.png
[image 4]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_2_633975948071613750.png
[image_image 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/06a717d4eb3b480f9ec1d71ff0f3d178.png
[image 5]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_3_633975948085363750.png
[image_image 5]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/f47b1bb537ac466da6cd45966183ea0e.png
[image 6]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_4_633975948095207500.png
[image_image 6]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/2cb3cf0003af42aca6bb67bfbdde6418.png
[image 7]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_5_633975948166457500.png
[image_image 7]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/27836fde674e42768a8781e5e4528b80.png
[image 8]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_6_633975948283801250.png
[image_image 8]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/f7f0fe290c6241b4b227449f3219b049.png
[watson_worcester.bell-elephone.com]: mailto:watson@worcester.bell-elephone.com
[image 9]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_7_633975948303645000.png
[image_image 9]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/fa66169117bc42f28287a16c40a2a2a7.png
[image 10]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_8_633975948336301250.png
[image_image 10]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/965bb75396874c20a82f3c03daf9598d.png
[image 11]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_9_633975948354270000.png
[image_image 11]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/8ddeee568bdf43f9b15eafdc369a432f.png
[image 12]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_10_633975948382707500.png
[image_image 12]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/9cb2086815c447319c46b61dbfd08b05.png
[image 13]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_11_633975948637395000.png
[image_image 13]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/e20bce2da4fd4d4bb12f395766e321e6.png
[image 14]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_12_633975948695363750.png
[image_image 14]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/dd209e4c1bc64aa9a716f60035c33238.png
[image 15]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_13_633975948735520000.png
[image_image 15]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/26b9e2e9873842dfaaaf09fec641ffb7.png
[image 16]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_15_633975948821926250.png
[image_image 16]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/a1153347d75b48889aba9dca58d2c0d7.png
[image 17]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_16_633975948831457500.png
[image_image 17]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/65451d2acb86471ca35238743e0af789.png
[image 18]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_17_633975948845207500.png
[image_image 18]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/28f6e6c6be434adc93d5983ebcef956d.png
[image 19]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_19_633975948860988750.png
[image_image 19]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/25706b6d97a045a28139c70c9612b992.png
[image 20]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_20_633975948888645000.png
[image_image 20]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/adf89161d3a441aba43ee5bb3f44ebe9.png
[image 21]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_21_633975949029426250.png
[image_image 21]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/2a0c8128cbc24e2c9e3ce3aeb036e0d6.png
[image 22]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_22_633975949061145000.png
[image_image 22]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_46_633975949041145000.png
[image 23]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_23_633975949206926250.png
[image_image 23]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/46444ed37042442497acdc4c419ca0cd.png
[image 24]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_24_633975949233020000.png
[image_image 24]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/1ba0fce68b52403c94bf7e4286e2613a.png
[image 25]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_25_633975949262395000.png
[image_image 25]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/adf40f33e83a4140a4523e045057f186.png
[image 26]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_26_633975949364270000.png
[image_image 26]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_54_633975949268020000.png
[image 27]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_27_633975949375676250.png
[image_image 27]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/b3f91163bf4d40dfb6ddc70e0405a946.png
[image 28]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_thumb_28.png
[image_image 28]: https://p-blog.csdn.net/images/p_blog_csdn_net/gnuhpc/598384/o_image_58.png