一种视频彩铃的信令连接方法、装置、终端及存储介质与流程

1.本技术涉及通信技术领域，尤其是一种视频彩铃的信令连接方法、装置、终端及存储介 质。


背景技术：

2.在移动通信网络中，不通过的用户终端之间传输媒体流需要建立媒体pdp上下文，这一 过程称为资源预留。进行资源预留有一定可能失败，而终端在双方资源预留成功之前不会有 任何通知指示产生(比如振铃提示、回铃提示等)。针对这一问题，相关技术对sip信令上新 增precondition扩展标识，表示支持资源预留功能，在初始invite携带require:precondition头 域或call waiting，同时对sdp属性进行扩展，增加了qos一种前提类型。通过这种方法，被 叫终端收到请求后，得知主叫终端支持资源预留功能，同时被叫终端也支持资源预留功能， 则提供183响应，在sdp中包括被叫终端支持的所有编码，并针对qos描述进行补充。但是， 在电信ims网络sip协议的技术规范中不建议初始invite携带require:precondition头域，原 因是主要资源预留功能在没有为现有业务或网络带来增值的前提下，增加了信令交互的复杂 性。
3.因此，相关技术存在的上述技术问题亟待解决。


技术实现要素：

4.本技术旨在解决相关技术中的技术问题之一。为此，本技术实施例提供一种视频彩铃的 信令连接方法、装置、终端及存储介质，能够排除了彩铃接续信令流程复杂化问题。
5.根据本技术实施例一方面，提供一种视频彩铃的信令连接方法，所述方法包括：
6.向被叫终端发送invite请求；
7.接收所述被叫终端的回复消息，所述回复消息包括183响应；
8.判断所述183响应中是否携带reason头域或call waiting指示，若所述183响应中携带 reason头域或call waiting指示，则向所述被叫终端透传后向消息和后向音；
9.向所述被叫终端发出update信令，确定所述信令连接的资源预留成功。
10.在其中一个实施例中，所述方法还包括：
11.判断所述回复消息是否包括180响应，若所述回复消息包括180响应，则停止进行彩铃 通信。
12.在其中一个实施例中，若所述回复消息包括180响应，所述方法还包括：
13.彩铃平台判断180响应是否携带reason头域或call waiting指示，若所述180响应携带 reason头域或call waiting指示，则透传后向消息和后向音，则停止进行彩铃媒体协商。
14.在其中一个实施例中，所述方法还包括：
15.判断所述invite请求中的contact头域是否包含video标签或sdp携带视频媒体行，如 果所述invite请求中的contact头域包含video标签或sdp携带视频媒体行，则发起
视频彩 铃媒体更新请求；若所述invite请求中的contact头域不包含video标签或sdp携带视频媒 体行，则发起音频彩铃媒体更新请求。
16.在其中一个实施例中，所述方法还包括：
17.判断所述彩铃的类型，若所述彩铃类型为视频通话，则视频媒体行下需要携带a＝sendrecv， 音频媒体行audio下需要携带a＝sendrecv；若所述彩铃类型为音频通话，则视频媒体行下需要 携带a＝sendonly，音频媒体行audio下需要携带a＝sendrecv。
18.在其中一个实施例中，所述方法还包括：
19.若所述被叫终端在预设时间内未收到信令，则放弃播放被叫彩铃产品，向主叫终端发送 180响应，所述携180响应带pem:inactive。
20.根据本技术实施例一方面，提供一种视频彩铃的信令连接装置，所述装置包括：
21.请求模块，用于向被叫终端发送invite请求；
22.接收模块，用于接收所述被叫终端的回复消息，所述回复消息包括183响应；
23.判断模块，用于判断所述183响应中是否携带reason头域或call waiting指示，若所述 183响应中携带reason头域或call waiting指示，则向所述被叫终端透传后向消息和后向音；
24.发送模块，用于向所述被叫终端发出update信令，确定所述信令连接的资源预留成功。
25.根据本技术实施例一方面，提供一种终端，包括如前面实施例所述的一种视频彩铃的信 令连接装置。
26.根据本技术实施例一方面，提供一种视频彩铃的信令连接装置，所述装置包括：
27.至少一个处理器；
28.至少一个存储器，所述存储器用于存储至少一个程序；
29.当至少一个所述程序被至少一个所述处理器执行时实现如权利要求1-6中任一项所述的 一种视频彩铃的信令连接方法。
30.根据本技术实施例一方面，提供一种存储介质，其特征在于，所述存储介质存储有处理 器可执行的程序，所述处理器可执行的程序被处理器执行时实现如前面实施例所述的一种视 频彩铃的信令连接方法。
31.本技术实施例提供的一种视频彩铃的信令连接方法的有益效果为：本技术技术方案相对 现有技术，在彩铃接续信令流程增加了对183响应是否携带reason头域或call waiting指示的 判断，若183响应中携带了reason头域或call waiting指示，则彩铃as将透传后向消息和后 向音，若收到180响应后不再进行彩铃媒体。通过这个判断，在precondition模式进行初始媒 体协商的场景下排除了彩铃接续信令流程复杂化问题。
32.本技术的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显， 或通过本技术的实践了解到。
附图说明
33.为了更清楚地说明本技术实施例中的技术方案，下面将对实施例描述中所需要使用的附 图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域 普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其
他的附图。
34.图1为本技术实施例提供的一种视频彩铃的信令连接方法的流程图；
35.图2为本技术实施例提供的一种视频彩铃的信令连接方法的另一流程图；
36.图3为本技术实施例提供的一种视频彩铃的信令连接方法的另一流程图；
37.图4为本技术运行原理示意图；
38.图5为本技术另一运行原理示意图；图6为一种视频彩铃的信令连接装置的结构图；图7为一种视频彩铃的信令连接装置的另一结构图。
具体实施方式
39.为了使本技术领域的人员更好地理解本技术方案，下面将结合本技术实施例中的附图， 对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术 一部分的实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没 有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本技术保护的范围。
40.本技术的说明书和权利要求书及附图中的术语“第一”、“第二”、“第三”和“第四”等 是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们 任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、 产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或 可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。
41.在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在 本技术的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施 例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理 解的是，本文所描述的实施例可以与其它实施例相结合。
42.在移动通信网络中，不通过的用户终端之间传输媒体流需要建立媒体pdp上下文，这一 过程称为资源预留。进行资源预留有一定可能失败，而终端在双方资源预留成功之前不会有 任何通知指示产生(比如振铃提示、回铃提示等)。针对这一问题，相关技术对sip信令上新 增precondition扩展标识，表示支持资源预留功能，在初始invite携带require:precondition头 域或call waiting，同时对sdp属性进行扩展，增加了qos一种前提类型。通过这种方法，被 叫终端收到请求后，得知主叫终端支持资源预留功能，同时被叫终端也支持资源预留功能， 则提供183响应，在sdp中包括被叫终端支持的所有编码，并针对qos描述进行补充。但是， 在电信ims网络sip协议的技术规范中不建议初始invite携带require:precondition头域，原 因是主要资源预留功能在没有为现有业务或网络带来增值的前提下，增加了信令交互的复杂 性。
43.针对上述问题，本技术提出了一种视频彩铃的信令连接方法，
44.图1为本技术实施例提供的一种视频彩铃的信令连接方法的流程图。参考图1，本技术 提供的一种视频彩铃的信令连接方法包括：
45.s101、向被叫终端发送invite请求。
46.步骤s101中，向被叫终端发送invite请求的主体是主叫终端，当需要启动彩铃功
能时 主叫终端将会发送invite请求给被叫终端，代表主叫终端开始请求与被叫终端之间建立彩 铃信令连接。
47.需要说明的是，视频彩铃业务流程通过主叫初始invite请求中的contact头域是否包含 video标签或sdp携带视频媒体行的初始判断，contact头域出现在invite、ack和register 的请求，1**，2**，3**或4**响应中。通常它提供了一个url，invite 1**响应：发送一个 临时的响应(1**)可以插入一个contact响应域。将contact url中的“user”、“password”、
ꢀ“
host”、“port”、“user-param”复制至重定位请求的“request-url”中，同时使用tranport 参数中传输协议，将此请求传到“maddr”和“port”参数所说明的地址处。如果“maddr
”ꢀ
是一个多点地址，“ttl”值表明time-to-live值contact头域可能指示一个不同于原始呼叫实体 的实体。contact头域可以包含任何合适的url来指示被叫方的位置，而不只限于sip url。
48.s102、接收所述被叫终端的回复消息，所述回复消息包括183响应。
49.步骤s102中，183(session progress)响应(或应答)用于提示建立对话的进度信息， rrason-phrase(表达原因的句子)、头域或消息体可以用于提示呼叫进度的更新消息。
50.s103、判断所述183响应中是否携带reason头域或call waiting指示。
51.步骤s103主要判断183响应中是否携带reason头域或call waiting指示，如果183响应 中携带reason头域或call waiting指示，说明主叫终端和被叫终端的彩铃信令通道能够建立成 功。
52.s104、若所述183响应中携带reason头域或call waiting指示，则向所述被叫终端透传 后向消息和后向音。
53.s104、向所述被叫终端发出update信令，确定所述信令连接的资源预留成功。
54.其中，步骤s104中的资源预留具体为：ue之间传输媒体流基于pdp上下文，建立媒体 pdp上下文的过程称为资源预留。媒体pdp上下文建立会花费一些时间甚至失败，这意味着 在资源被成功预留之前，无法保证协商的媒体会话是否可以建立起来。因此终端在双方资源 预留成功之前不会有任何通知指示产生，比如振铃提示、回铃提示等。资源预留功能在sip 信令上体现为两个阶段，第一阶段的所有媒体协商仅仅是为了双方进行资源预留准备(比如 媒体协商如果承载在183响应中，终端不能将183做为回铃指示，因为资源预留还没有建立 成功)。在资源预留建立成功之后，使用update信令来表明资源预留建立完成。进入第二 个阶段，之后的18*信令就可以像普通sip流程一样，做为放回铃音的指示信息。
55.可选地，本实施例提出的一种视频彩铃的信令连接方法还包括：判断所述彩铃的类型， 若所述彩铃类型为视频通话，则视频媒体行下需要携带a＝sendrecv，音频媒体行audio下需要 携带a＝sendrecv；若所述彩铃类型为音频通话，则视频媒体行下需要携带a＝sendonly，音频 媒体行audio下需要携带a＝sendrecv。本实施例通过根据不同的彩铃类型赋予音视频媒体行携 带不同的参数，能够使被叫终端快速辨认彩铃呼叫的类型，以便被叫终端及时调用不同的参 数进行信令连接。
56.可选地，本实施例提出的一种视频彩铃的信令连接方法还包括：若所述被叫终端在预设 时间内未收到信令，则放弃播放被叫彩铃产品，向主叫终端发送180响应，所述携180响应 带pem:inactive。具体地，本实施例的实现方式为设置定时器，当定时器超时还未收到主被 叫终端的资源确认消息时，放弃播放被叫彩铃产品，直接发送180消息，携带pem:
inactive， 终端播放普通回铃音。其中，本实施例中的定时器的时间可配置，缺省可以设置为3秒，本 领域技术人员可以根据需要灵活设置，本说明书不作限定。
57.通过上述步骤，本技术实施例提出的一种视频彩铃的信令连接方法在彩铃接续信令流程 增加了对183响应是否携带reason头域或call waiting指示的判断，若183响应中携带了 reason头域或call waiting指示，则彩铃as将透传后向消息和后向音，若收到180响应后不 再进行彩铃媒体。通过这个判断，在precondition模式进行初始媒体协商的场景下排除了彩铃 接续信令流程复杂化问题。
58.优选地，本技术还提供了其他实施例，用于取得更优的技术效果，具体如下。
59.图2为本技术实施例提供的一种视频彩铃的信令连接方法的另一流程图。参考图2，本 申请实施例提供的一种视频彩铃的信令连接方法还包括：
60.s201、向被叫终端发送invite请求。
61.s202、180响应中是否携带reason头域或call waiting指示。
62.需要说明的是，在彩铃通信中，所有1开头的响应称为临时响应，例如180和183。这 些响应一般是对invite请求的响应。使用场景为：主叫用户(a)在发起一个呼叫时，会向 被叫用户(b)发起一个invite请求，被叫用户在收到这个请求后，会给主叫用户一个响应， 一般的响应流程是回100，紧接着回180，或(和)183。其中，上述实施例中的180响应代 表振铃，接收这一响应的终端将进行振铃操作。
63.s203、若180响应中携带reason头域或call waiting指示，则透传后向消息和后向音。
64.s204、停止进行彩铃媒体协商。
65.本实施例在收到180响应后及时停止进行彩铃媒体协商，能够有效节约彩铃通信资源， 简化彩铃通信流程的复杂程度。
66.此外，本技术还提出了另一种优选的实施例，具体如下。
67.图3为本技术实施例提供的一种视频彩铃的信令连接方法的另一流程图。参考图3，本 申请提出的一种视频彩铃的信令连接方法还包括：
68.s301、判断所述invite请求中的contact头域是否包含video标签或sdp携带视频媒体 行。
69.s302、若所述invite请求中的contact头域包含video标签或sdp携带视频媒体行，则 发起视频彩铃媒体更新请求。
70.s303、若所述invite请求中的contact头域不包含video标签或sdp携带视频媒体行， 则发起音频彩铃媒体更新请求。
71.在本实施例完成对音频和视频彩铃媒体更新请求后，主叫终端还能够根据自身能力及状 态回复200update，若主叫不支持precondition，将忽略彩铃asupdate消息中的precondition 参数。这一步骤的作用在于当主叫不支持precondition时，通过忽略precondition参数来实现 对update参数的回复，提高了本方法的系统兼容性。
72.接下来对本技术的运行原理和数据交换机制作进一步说明，具体如下。
73.图4为本技术运行原理示意图。参考图4，本技术的执行主体分为主叫域和被叫域，其 中，主叫域是指多个主叫终端构成的集合，被叫域是指多个被叫终端构成的集合，具体步骤 如下：
74.主叫发出初始invite时，被叫ims域的彩铃as收到invite请求，彩铃as透传主叫 消息至被叫，被叫回复183，开始主被叫双方资源预留。判断183响应中是否携带了reason 头域或call waiting指示，若183响应中携带了reason头域或call waiting指示，则彩铃as 将透传后向消息和后向音，若收到180响应后不再进行彩铃媒体。主被叫分别发出update信 令，以确认双方资源预留成功。被叫终端返回180响应(振铃)通过被叫i/s-cscf到达被叫 归属域彩铃as，资源预留。
75.图5为本技术运行原理示意图。参考图5，相比于上述实施例增加了多个判断过程，具 体如下：
76.判断180响应携带了reason头域或call waiting指示，彩铃平台将透传后向消息和后向音， 不做彩铃媒体协商。
77.1)彩铃as向主叫ims域update主叫彩铃的sdp，
78.判断3具体为：主叫初始invite请求中的contact头域是否包含video标签或sdp携带 视频媒体行，如果携带，则发起视频彩铃媒体更新请求(后续协商成功后为主叫播放被叫用 户视频铃音库中的铃音)；若未携带，则发起音频彩铃媒体更新请求(后续协商成功后为主叫 播放被叫用户音频铃音库中的铃音)。对于判断(2)，平台设置开关(视频彩铃协商判断开关)， 开关默认开启，当开关关闭时，无论主叫起呼时是否contact头域携带video标签或为视频起 呼，平台均发起视频彩铃媒体更新请求。
79.判断4具体为：若主被叫初始媒体协商为视频通话(以第6步媒体协商结果为准)，则视 频媒体行下需要携带a＝sendrecv，音频媒体行audio下需要携带a＝sendrecv；若主被叫初始媒 体协商为音频通话(以第6步媒体协商结果为准)，则视频媒体行下需要携带a＝sendonly，音频 媒体行audio下需要携带a＝sendrecv。媒体更新消息需携带support：precondition、conf要求， 及precondition协商所需相关参数，不可携带require：precondition。
80.2)主叫终端根据自身能力及状态回复200update，若主叫不支持precondition，将忽略彩 铃asupdate消息中的precondition参数。
81.此外，本实施还有可选步骤，具体为：如果上述步骤中主叫终端视频资源未预留成功， 待其完成资源预留后发送资源确认消息，彩铃as进行应答。
82.3)彩铃as根据主叫应答的媒体能力播放音频或视频彩铃(若主叫在第10步或第11步的 消息中视频媒体行属性为sendrecv，则彩铃as播放视频彩铃；若主叫在第10步或第11步的 消息中视频媒体行属性为inactive或被置0，则彩铃as播放音频彩铃)，并转发180消息， 携带pem:sendrecv。
83.4)被叫ue摘机回复200ok，彩铃as停止彩铃播放，并回复ack。
84.5)彩铃as向被叫ue发送re-invite请求，不携带sdp信息。
85.6)被叫ue对re-invite请求进行应答。此处，终端判断本地没有发生过网络切换或视频 电话音频摘机，终端回复与主叫初始协商时相同的媒体能力或直接回复全媒体能力。
86.另外，此处终端也可能使用200ok进行应答，也可能使用183进行应答，彩铃as应根 据sip协议，进行相应的处理。
87.7)彩铃as将被叫对re-invite请求应答的媒体能力作为sdp offer向主叫进行媒体更新。 此处，彩铃as应将被叫sdp的媒体行类型与主叫侧当前通话类型进行匹配处理，再
发给主 叫侧。即，若被叫返回的sdp媒体行若同时包含音频和视频，而此时主叫侧通话类型为音频， 则彩铃as需要将被叫sdp中的视频媒体行置0后，再将被叫sdp发送给主叫。若被叫sdp 包含的媒体行类型与主叫在初始媒体协商过程中与被叫最终协商好的媒体能力匹配，则无需 任何修改，直接向主叫透传请求媒体更新。
88.8)主叫对媒体更新进行应答，返回200ok。
89.9)彩铃as向主叫转发被叫摘机200ok。
90.10)彩铃as向被叫返回re-invite ack，携带主叫对第22步媒体更新消息应答的sdp 信息。
91.参照图6，本发明实施例还提供了一种视频彩铃的信令连接装置，包括：
92.请求模块601，用于向被叫终端发送invite请求。
93.接收模块602，用于接收所述被叫终端的回复消息，所述回复消息包括183响应。
94.判断模块603，用于判断所述183响应中是否携带reason头域或call waiting指示，若所 述183响应中携带reason头域或call waiting指示，则向所述被叫终端透传后向消息和后向音。
95.发送模块604，用于向所述被叫终端发出update信令，确定所述信令连接的资源预留成 功。
96.可见，上述方法实施例中的内容均适用于本装置实施例中，本装置实施例所具体实现的 功能与上述方法实施例相同，并且达到的有益效果与上述方法实施例所达到的有益效果也相 同。
97.参照图7，本技术实施例提供了一种视频彩铃的信令连接装置，包括：
98.至少一个处理器701；
99.至少一个存储器702，用于存储至少一个程序；
100.当至少一个程序被至少一个处理器701执行时，使得至少一个处理器701实现的前述实 施例的视频彩铃的信令连接方法。
101.同理，上述方法实施例中的内容均适用于本装置实施例中，本装置实施例所具体实现的 功能与上述方法实施例相同，并且达到的有益效果与上述方法实施例所达到的有益效果也相 同。
102.本发明实施例还提供了一种终端，包括上述实施例的视频彩铃的信令连接方法。
103.同理，上述方法实施例中的内容均适用于本实施例中，本实施例所具体实现的功能与上 述方法实施例相同，并且达到的有益效果与上述方法实施例所达到的有益效果也相同。
104.本发明实施例还提供了一种存储介质，存储介质存储有程序，程序在被处理器执行时用 于实现前述实施例的视频彩铃的信令连接方法。
105.上述的方法实施例中的内容均适用于本存储介质实施例中，本存储介质实施例所具体实 现的功能与上述的方法实施例相同。
106.同理，上述方法实施例中的内容均适用于本存储介质实施例中，本存储介质实施例所具 体实现的功能与上述方法实施例相同，并且达到的有益效果与上述方法实施例所达到的有益 效果也相同。
107.在一些可选择的实施例中，在方框图中提到的功能/操作可以不按照操作示图提
到的顺序 发生。例如，取决于所涉及的功能/操作，连续示出的两个方框实际上可以被大体上同时地执 行或方框有时能以相反顺序被执行。此外，在本技术的流程图中所呈现和描述的实施例以示 例的方式被提供，目的在于提供对技术更全面的理解。所公开的方法不限于本文所呈现的操 作和逻辑流程。可选择的实施例是可预期的，其中各种操作的顺序被改变以及其中被描述为 较大操作的一部分的子操作被独立地执行。
108.此外，虽然在功能性模块的背景下描述了本技术，但应当理解的是，除非另有相反说明， 功能和/或特征中的一个或多个可以被集成在单个物理装置和/或软件模块中，或者一个或多个 功能和/或特征可以在单独的物理装置或软件模块中被实现。还可以理解的是，有关每个模块 的实际实现的详细讨论对于理解本技术是不必要的。更确切地说，考虑到在本文中公开的装 置中各种功能模块的属性、功能和内部关系的情况下，在工程师的常规技术内将会了解该模 块的实际实现。因此，本领域技术人员运用普通技术就能够在无需过度试验的情况下实现在 权利要求书中所阐明的本技术。还可以理解的是，所公开的特定概念仅仅是说明性的，并不 意在限制本技术的范围，本技术的范围由所附权利要求书及其等同方案的全部范围来决定。
109.功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个 计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做 出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存 储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器， 或者网络设备等)执行本技术各个实施例方法的全部或部分步骤。而前述的存储介质包括： u盘、移动硬盘、只读存储器(rom，read-only memory)、随机存取存储器(ram，randomaccess memory)、磁碟或者光盘等各种可以存储程序代码的介质。
110.在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现 逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行 系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、 装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。 就本说明书而言，“计算机可读介质”可以是任何可以包含、存储、通信、传播或传输程序以 供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。
111.计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电 连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(ram)，只读存储器 (rom)，可擦除可编辑只读存储器(eprom或闪速存储器)，光纤装置，以及便携式光盘 只读存储器(cdrom)。另外，计算机可读介质甚至可以是可在其上打印程序的纸或其他合 适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时 以其他合适方式进行处理来以电子方式获得程序，然后将其存储在计算机存储器中。
112.应当理解，本技术的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施 方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件 来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术 中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻 辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(pga)，
现场可编程门 阵列(fpga)等。
113.在本说明书的上述描述中，参考术语“一个实施方式/实施例”、“另一实施方式/实施例
”ꢀ
或“某些实施方式/实施例”等的描述意指结合实施方式或示例描述的具体特征、结构、材料 或者特点包含于本技术的至少一个实施方式或示例中。在本说明书中，对上述术语的示意性 表述不一定指的是相同的实施方式或示例。而且，描述的具体特征、结构、材料或者特点可 以在任何的一个或多个实施方式或示例中以合适的方式结合。
114.尽管已经示出和描述了本技术的实施方式，本领域的普通技术人员可以理解：在不脱离 本技术的原理和宗旨的情况下可以对这些实施方式进行多种变化、修改、替换和变型，本申 请的范围由权利要求及其等同物限定。
115.以上，以上实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述实施例 对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例 所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换， 并不使相应技术方案的本质脱离本技术各实施例技术方案的精神和范围。