专利名称：一种在VoIP网络中传输SIP请求历史信息的方法
技术领域：
本发明涉及通信领域，具体的说是一种在VoIP网络中传输SIP 请求历史信息的方法。
背景技术：
会话初始协议(Session Initiation Protocol, SIP协议)是 IETF (Internet工程任务组)提出的一个支持多媒体会话的信令控 制协议，主要用于实现IP网上的信令控制，包括建立、管理和终止 由多方参与的语音会话进程。SIP协议借鉴了 HTTP、 SMTP等协议， 支持代理、重定向及登记定位用户等功能，支持用户移动。通过与 RTP/RTCP、 SDP、 RTSP等协议及DNS配合，SIP协议支持语音、视频、 数据、E-mail、状态、IM、聊天、游戏等。
SIP协议是一个基于文本的应用层控制协议，独立于底层传输协 议TCP/UDP/SCTP。 SIP协议分为请求和响应两种类型，而请求又包括 REGISTER、 INVITE、 ACK、 BYE和OPTION等类型。SIP协议的基本网 络元素包括UA (User Agent,用户代理)、Proxy (代理服务器)、 Registrar (注册服务器)和Redirect Server (重定向服务器)等。
VoIP (Voice over Internet Protocol)是指将模拟的声音讯号 经过压缩与封包之后，以数据封包的形式在IP网络的环境进行语音 讯号的传输，通俗来说也就是互联网电话、网络电话或者简称IP电 话的意思。VoIP的基本原理是通过语音的压縮算法对语音数据编 码进行压縮处理，然后把这些语音数据按TCP/IP标准进行打包，经 过IP网络把数据包送至接收地，再把这些语音数据包串起来，经过 解压处理后，恢复成原来的语音信号，从而达到由互联网传送语音的 目的。TLS (传输层安全，Transport Layer Security)是基于SSL (安 全端口层，Secure Socket Layer)的一种协议。SSL是设计用来保 护网页通信，并且现在应用于绝大多数浏览器中。TLS是比SSL更通 用，它可以用于保护任何类型的可靠连接。TLS为可靠连接(如一个 TCP连接)提供数据的完整性和保密性。TLS包括两层TLS握手层 (TLS handshake layer)禾口 TLS记录层(TLS record layer)。 TLS 握手层处理对等用户的认证，在这一层使用了公共密钥和证书，并协 商算法和加密实际数据传输的密钥。TLS记录层处理数据的加密，通 常它使用一个对称的算法，这个算法的密钥由握手层提供的值产生。 TLS是一个逐跳(h叩by hop)的安全措施，在SIP的应用中，TLS 保护一个SIP实体与和它相距一跳远的另一实体之间的信息交换。
现有SIP网络中提供历史请求记录的方式如下图1所示。主要工 作过程如下
1. 用户代理1发送一个INVITE请求到代理服务器1;
2. 代理服务器1转发这个INVITE请求到代理服务器2，代理 服务器2在转发前在INVITE请求中的History-Info头域中增加代理 服务器1以及代理服务器2的信息；以图1为例，在INVITE请求中 的History-Info头域中增加下述信息
〈sip:Bob@Pl. example, com〉； index二l， 〈sip:Bob@P2. example, com〉；index二l.l5
3. 代理服务器2在给代理服务器1回响应之前，尝试把这个 INVITE请求通过SIP具有的Forking机制并行转发到用户代理2、用 户代理3、用户代理4，所说的Forking机制是指 一个用户注册了 多个用户代理(一号多机)，到该用户的呼叫会同时转发到上述的多 个用户代理去。以图1为例，用户代理2、用户代理3和用户代理4 是属于同一个用户的用户代理，在代理服务器2转发INVITE请求前 添加用户代理的信息。具体地说，是在转发的各个INVITE请求的 History-Info头域中分别增加各个用户代理的信息；以图1为例， 图1中代理服务器2尝试把这个INVITE请求并行转发到用户代理2、用户代理3、用户代理4，在转发的各个INVITE请求的History-Info
头域中增加的信息如下
在转发到用户代理2的INVITE请求的History-Info头域中增加 〈sip:User2@UA2. example. com>;index=l. 1. 1，
在转发到用户代理3的INVITE请求的History-Info头域中增加 〈sip:User3@UA3. example, com〉 ； index=l. 1. 2，
在转发到用户代理4的INVITE请求的History-Info头域中增加 <sip:User4@UA4. example. com>:index=l. 1. 3;
4. 当用户代理2、用户代理3、用户代理4对上述INVITE请 求的响应都是不成功或不可用时，代理服务器2发送一个480响应给 代理服务器1，在480响应的History-Info头域中增加第3步中尝 试的各个用户代理的信息以及失败原因等；以图1为例，用户代理2、 用户代理3、用户代理4对INVITE请求的响应都是不成功或不可用， 此时，代理服务器2发送一个480响应给代理服务器1，在480响应 的History-Info头域中增加信息如下
〈sip:User2@UA2. example. com" Reason二SIP; \ cause=408;text=〃RequestTimeout〃〉；index=l.1.1， 〈sip:User3@UA3. example. com7Reason二SIP;\ cause=487;text=〃Request Terminated〃〉；index=l. 1. 2， 〈sip:User4@UA4. example. com" Reasoiv^SIP; \ cause=603;text=〃Decline〃>;index=l. 1.3;
5. 当代理服务器1接收到这个480响应时，代理服务器1检 测到INVITE的另一个路由途径——用户代理5，于是代理服务器1 把这个INVITE请求转发给用户代理5。在该INVITE请求的 History-Info头域中增加用户代理5的信息；以图1为例，代理服 务器1把这个INVITE请求转发给用户代理5，在转发到用户代理5 的INVITE请求的History-Info头域中增加信息如下
<sip:User2@UA2. example. com7Reason二SIP;cause=408;\ text="RequestTimeout">;index二l. 1. 1，<sip:User3@UA3. example. com* Reason=SIP; cause=487; \
text="Request Terminated"; index=l. 1.2，
〈sip:User4@UA4. example. com7Reason二SIP;cause=603;\
text="Decline"〉；index二l. 1. 3
〈sip:User5@UA5. example. com>;index=l. 2;
6. 用户代理5发送200 OK响应给代理服务器1，代理服务器 1把这个200 OK响应转发给用户代理1,用户代理1向用户代理5发 送ACK响应，在用户代理1和用户代理5之间建立这个呼叫会话。
虽然History-Info头域提供了请求历史信息的记录，但是由于 SIP协议是基于文本的协议，以文本形式表示消息的词法和语法分析 比较简单，非常容易被攻击者模仿、篡改，加以非法利用。 History-Info头域也有如下几个缺陷
* 一个不可信的应用程序可能插入一个伪造的请求历史信息 条目。
* 一个不可信的应用程序可能重排了请求历史信息。
* 一个不可信的应用程序可能删除某些请求历史信息条目。 因此在RFC4244中，提出了 History-Info头域必须在TLS这类
安全网络中传输。如果没有使用TLS，则必须在转发之前删除 History-Info头域；或者对重定向该请求消息，要求客户端用户代 理通过安全的途径发起这个包含History-Info头域的请求。
但由于TLS网络建设成本高，并没有大规模应用，也就导致了 History-Info头域的机制并不能在普通IP网络中大量应用。
发明内容
针对现有技术中存在的缺陷，本发明的目的在于提供一种在VoIP 网络中传输SIP请求历史信息的方法，通过为SIP消息的请求历史信 息计算摘要的方式，可以有效的规避请求历史信息被伪造、篡改、删 除和重新排列等问题，而且可以摆脱对TLS这类安全网络的依赖，使该功能可以在普通的IP网络中被应用。
为达到以上目的，本发明采取的技术方案是
一种在VoIP网络中传输SIP请求历史信息的方法，其特征在于: 其具体步骤为
步骤1，为History-Info头域定义扩展参数digest;
步骤2，当一个SIP应用收到SIP请求时，把请求历史信息加入 History-Info头域后，用摘要算法计算出History-Info头域包含的 全部内容的摘要信息，然后在History-Info头域中增加digest参数， 把所述摘要信息放入到digest参数中；转发该SIP请求到下一跳的 SIP应用；
步骤3，下一跳的SIP应用接收到转发来的SIP请求时，首先从 History-Info头域中提取出digest参数携带的摘要信息，然后从 History-Info头域中删除digest参数，然后用与步骤2相同的摘要 算法重新计算一遍当前History-Info头域包含的全部内容的摘要信 息，把重新计算出的摘要信息和digest参数携带的摘要信息进行比 较，如果比较结果一致，则认为该History-Info头域是可信的，此 时当前SIP应用把自己的信息加入到History-Info头域后，用摘要 算法计算出新的History-Info头域包含的全部内容的新摘要信息， 然后在新的History-Info头域中增加digest参数，把所述新摘要信 息放入到digest参数中；转发当前SIP请求到下一跳的SIP应用； 如果比较结果不一致，则认为该History-Info头域是不可信的，转 发当前SIP请求到下一跳的SIP应用前删除不可信的History-Info 头域，或者请求上一跳的SIP应用重新发起请求而不进行转发。
本发明所述的在VoIP网络中传输SIP请求历史信息的方法，通 过为SIP消息的请求历史信息计算摘要的方式，可以有效的规避请求 历史信息被伪造、篡改、删除和重新排列等问题，而且可以摆脱对 TLS这类安全网络的依赖，使该功能可以在普通的IP网络中被应用。
本发明有如下附图
图1现有IP网络中记录请求历史记录的流程； 图2本发明方案示意图3实施例l:经过重定向服务器和代理服务器的会话流程； 图4实施例2:串行分岔会话流程。
具体实施例方式
以下结合附图对本发明作进一步详细说明。
图2为本发明所述的在VoIP网络中传输SIP请求历史信息的方 法，本发明通过对现有的SIP头域进行扩展，提供了一种在普通IP 网络中对History-Info头域进行保护的方法，使得History-Info头 域可以在普通IP网络中进行传递;本发明提供的扩展方式和目前SIP 网络的消息流程并不冲突，可以同时存在，并作为现有流程的很好补 充，为SIP应用提供了一种更为灵活的记录请求历史信息的方法，使 其摆脱了 TLS网络的限制，大大扩展了 SIP消息的请求历史信息功能 的应用场景。本发明所述的方法在RFC4244 (An Extension to the Session Initiation Protocol ( SIP ) for Request History Information)定义的基础上进行运用，并且实际运用到SIP网络的 消息流程中，History-Info头域是在RFC4244中定义，但本专利并 不限定于RFC4244。在RFC4244中定义了 History-Info头域的可选 扩展参数，这个扩展参数满足generic-param格式，其具体定义如下
History-Info = "History-Info" HC0L0N
hi-entry氺(CO麗A hi-entry)
hi-entry = hi-targeted-to-uri氺(SEMI hi-param )
hi-targeted-to-uri= name-addr
hi-param = hi-index / hi-extension
hi—index = 〃index〃 EQUAL 1*DIGIT * (DOT 1*DIGIT)hi—extension = generic-param
本发明就是利用了这个扩展参数，为History-Info头域定义了 一个新的扩展参数digest。具体地说，其具体步骤为
步骤1，为History-Info头域定义扩展参数digest;
步骤2，当一个SIP应用收到SIP请求时，把请求历史信息加入 History-Info头域后，用摘要算法计算出History-Info头域包含的 全部内容的摘要信息，然后在History-Info头域中增加digest参数， 把所述摘要信息放入到digest参数中；转发该SIP请求到下一跳的 SIP应用；
步骤3，下一跳的SIP应用接收到转发来的SIP请求时，首先从 History-Info头域中提取出digest参数携带的摘要信息，然后从 History-Info头域中删除digest参数，然后用与步骤2相同的摘要 算法重新计算一遍当前History-Info头域包含的全部内容的摘要信 息，把重新计算出的摘要信息和digest参数携带的摘要信息进行比 较，如果比较结果一致，则认为该History-Info头域是可信的，此 时当前SIP应用把自己的信息加入到History-Info头域后，用摘要 算法计算出新的History-Info头域包含的全部内容的新摘要信息， 然后在新的History-Info头域中增加digest参数，把所述新摘要信 息放入到digest参数中；转发当前SIP请求到下一跳的SIP应用； 如果比较结果不一致，则认为该History-Info头域是不可信的，转 发当前SIP请求到下一跳的SIP应用前删除不可信的History-Info 头域，或者请求上一跳的SIP应用重新发起请求而不进行转发。
所述的计算摘要的方法可以采用MD5或者SHA-1算法。
图2为图1使用本发明所述方法后的各个步骤，具体地说 步骤1，用户代理1发送一个INVITE请求到代理服务器1; 步骤2，代理服务器1转发这个INVITE请求到代理服务器2，代 理服务器2在转发前在INVITE请求中的History-Info头域中增加代 理服务器1以及代理服务器2的信息，然后计算摘要信息并通过扩展参数digest添加到History-Info头域中；以图2为例，在INVITE 请求中的History-Info头域中增加下述信息
〈sip:Bob@Pl. example, com〉 ； index=l，
<sip:Bob@P2. example, com〉 ； index二l. l.'
digest=d41d8cd98f00b204e9800998ecf8427e
步骤3，代理服务器2在给代理服务器1回响应之前，尝试把这 个INVITE请求通过SIP具有的Forking机制并行转发到用户代理2、 用户代理3、用户代理4，，在代理服务器2转发INVITE请求前添加 用户代理的信息。具体地说，是在转发的各个INVITE请求的 History-Info头域中分别增加各个用户代理的信息，然后计算各摘 要信息并通过扩展参数digest添加到History-Info头域中；以图2 为例，图2中代理服务器2尝试把这个INVITE请求并行转发到用户 代理2、用户代理3、用户代理4，在转发的各个INVITE请求的 History-Info头域中增加的信息如下
在转发到用户代理2的INVITE请求的History-Info头域中增加 <sip:User2@UA2. example, com〉；index二l. 1. 1，
digest=0ccl75b9c0flb6a831c399e269772661
在转发到用户代理3的INVITE请求的History-Info头域中增加 〈sip:User3@UA3. example, com〉； index=l. 1.2,
digest=900150983cd24fb0d6963f7d28el7f72
在转发到用户代理4的INVITE请求的History-Info头域中增加 <sip:User4@UA4. example. com>;index=L 1. 3;
digest=f96b697d7cb7938d525a2f31aafl61d0
步骤4，当用户代理2、用户代理3、用户代理4对上述INVITE 请求的响应都是不成功或不可用时，代理服务器2发送一个480响应 给代理服务器1，在480响应的History-Info头域中增加第3步中 尝试的各个用户代理的信息以及失败原因等；以图2为例，用户代理 2、用户代理3、用户代理4对INVITE请求的响应都是不成功或不可 用，此时，代理服务器2发送一个480响应给代理服务器1，在480响应的History-Info头域中增加信息如下
<sip:User2@UA2. example. com" Reason二SIP; \
cause二408;text二〃RequestTimeout〃〉；index二l.1.1，
〈sip:User3@UA3. example. com" Reason二SIP; \
cause=487; text=〃Request Terminated"; index=l. 1. 2，
〈sip:User4@UA4. example. com7Reason二SIP;\
cause=603;text二"Decline〃〉；index二l. 1.3;
digest=c3fcd3d76192e4007dfb496cca67el3b
步骤5，当代理服务器1接收到这个480响应时，代理服务器l 检测到INVITE的另一个路由途径——用户代理5,于是代理服务器1 把这个INVITE请求转发给用户代理5。在该INVITE请求的 History-Info头域中增加用户代理5的信息；以图2为例，代理服 务器1把这个INVITE请求转发给用户代理5，在转发到用户代理5 的INVITE请求的History-Info头域中增加信息如下
〈sip:User2@UA2. example. com Reason=SIP;cause=408;\
text=〃RequestTimeout〃〉；index=l. 1. 1，
<sip:User3@UA3. example. com7Reason二SIP;cause二487;\
text=〃Request Terminated"; index=l. 1.2，
〈sip:User4@UA4. example. com" Reason二SIP; cause=603; \
text="Decline〃>; index=l. 1.3
<sip:User5@UA5. example. com>;index=l. 2;
digest=dl74ab98d277d9f5a5611c2c9f419d9f
步骤6.用户代理5发送200 OK响应给代理服务器1，代理服 务器1把这个200 OK响应转发给用户代理1，用户代理1向用户代 理5发送ACK响应，在用户代理1和用户代理5之间建立这个呼叫会 话。
由此可见，扩展参数digest携带的摘要信息随着History-Info 头域内容不同而不同，通过摘要信息可以方便、准确、快捷的判断该 History-Info头域是否可信。通过为SIP消息的请求历史信息计算摘要的方式，可以有效的规避请求历史信息被伪造、篡改、删除和重
新排列等问题，而且可以摆脱对TLS这类安全网络的依赖，使该功能 可以在普通的IP网络中被应用。
图3给出的实施例主要描述根据本发明方法，SIP会话经过重定 向服务器和代理服务器时对请求历史信息的处理过程。具体的处理过 程如图3所示
1. 用户A发起一个到用户B的INVITE请求，该请求首先被发 送到重定向服务器。在该请求中包含了请求历史记录，并为该请求历 史记录计算了一个摘要。
History-Info: <sip:bob@biloxi. example, com〉； index=l;\ digest=6c652063616c6c7320746f2062652072
2. 重定向服务器返回302响应，该响应的Contact头域中包 含了用户B当前的SIP地址。在该响应中会包含INVITE请求中所携 带的History-Info头域。
History-Info: <sip:bob@biloxi. example, com〉； index=l;\ digest=6c652063616c6c7320746f2062652072
3. 用户A生成一个ACK请求发送给重定向服务器，结束重定 向的过程。
4. 用户A使用用户B当前的SIP地址生成一个新的INVITE请 求，并把该请求发送到代理服务器。代理服务器接收到INVITE请求 后，从History-Info头域中提取digest参数所携带的摘要，重新计 算原History-Info头域中的请求历史记录的摘要，并把新计算出的 摘要和携带过来的摘要进行比较。比较合格后，在这个INVITE请求 的History-Info头域中，增加了代理服务器的信息条目，并为该请 求历史记录计算了一个新的摘要放入digest参数中。
History-Info:<sip:bob@biloxi. example. com" Reason二SIP;cau se=302〉\
text=〃Moved Temporarily"; index=l，<sip:bob@chicago. example, com〉； index=2;\
digest=43b8fcb8c4d2bbb8f6c7ebc7f3b5c455
5. 代理服务器把该INVITE请求转发给用户B。用户B接收到 INVITE请求后，从History-Info头域中提取digest参数所携带的 摘要，重新计算原History-Info头域中的请求历史记录的摘要，并 把新计算出的摘要和携带过来的摘要进行比较。比较合格后，在该 INVITE请求中，增加了用户B的信息条目，并为该请求历史记录计 算了一个新的摘要放入digest参数中。
History-Info:<sip:bob@biloxi. example. com7Reason二SIP;cau se=302〉\
text=〃Moved Temporarily"; index=l， 〈sip:bob@chicago. example, com〉； index=2， 〈sip:bob@client.Chicago, example, com〉； index=2.1;\ digest=c4bfbleab5d8d6b7ala3d5e2b8f6caf5
图4给出的实施例主要描述根据本发明方法，SIP串行分岔会话 中对请求历史信息的处理过程，具体的处理过程如图4所示
1. 位于用户代理1的用户A发起一个到用户B的INVITE请求。 该请求首先被发送到代理服务器1。
2. 代理服务器1接收到INVITE请求后，把用户A和代理服务 器1的信息条目加入到History-Info头域中，并为该请求历史记录 计算了一个摘要放入digest参数中。然后把该请求转发给用户B的 其中一个用户代理(用户代理2)。
History-Info: <sip:UserA@example. com〉； index二l, <sip:UserA@ims. example, com》'index二l. 1;\ digest=accbfcccelb9a9d2bbb8f6cfecd3a6bb
3. 转发INVITE请求后，代理服务器1为该INVITE请求产生 一个100响应发送给用户代理1。
4. 用户代理2接收到INVITE请求后产生一个302响应给代理服务器l，告知用户B当前的SIP地址。
5. 代理服务器1接收到302响应后，使用用户B当前的SIP 地址，把该INVITE请求转发给用户B的用户代理(用户代理3)。在 该INVITE请求的History-Info头域中，增加了用户代理3的信息条 目，删除原摘要，并为该请求历史信息重新计算一个新的摘要。
History—Info: 〈sip:UserA@example. com〉； index=l, <sip:UserA@ims. example. com Reason二SIP;\ cause=302: text=〃Moved Temporarily"); index=l. 1， 〈sip:UserB@example. com>; index=l. 2;\ digest=205468652072756c657320666f722064
6. 用户代理3接收到INVITE请求后，为该INVITE请求产生 一个180响应。
7. 代理服务器1接收到用户代理3产生的180响应后，把该 180响应转发给用户代理1。
8. 假设用户代理3不可用，重发请求发送多次后超时，代理 服务器1继续把INVITE请求转发给用户B的另一个用户代理(用户 代理4)。在该INVITE请求的History-Info头域中，增加了用户代 理4的信息条目，删除原摘要，并为该请求历史信息重新计算一个新 的摘要。
History-Info: <sip:UserA@example. com〉； index=l， 〈sip:UserA@ims. example. com7Reason二SIP;\ cause=302; text二〃Moved Temporarily"; index=l. 1， <sip:UserB@example. com7ReasorFSIP;cause-480;\ text=〃Tempomrily Unatvailable〃 〉； index=l. 2， <sip:UserC@example. com〉；index=l. 3;\ digest=d5d5b9e6b6a8c2b7d3c9b5bdccd8b6a8
9. 用户代理4忙，为该INVITE请求产生一个486响应。
10. 代理服务器1接收到用户代理4的486响应后，产生一个 ACK请求给用户代理4。11. 代理服务器1把用户代理4的486响应转发给用户代理1。 在该486响应中，包含了 INVITE请求中的History-Info头域。
History—Info: <sip:UserA@example. com>; index=l， <sip:UserA@ims. example. com7Reason二SIP;\ cause=302; text=〃Moved Temporarily"; index二l. 1， <sip:UserB@example. com" Reason二SIP; cause=480; \ text=〃Temporarily Unavailable" >; index=l. 2， <sip:UserC@example. com〉； index=l. 3;\ digest=d5d5b9e6b6a8c2b7d3c9b5bdccd8b6a8
12. 用户代理1接收到486响应后，产生一个ACK请求，结束 该INVITE请求流程。
上述实施例中，是以各digest参数所携带的摘要信息可信为基 础描述的。如果各digest参数所携带的摘要信息不可信，SIP代理 服务器直接丢弃该SIP消息，不再继续处理。SIP代理服务器接收到 此类不可信消息时，可以产生错误日志并生成告警信息，具体错误处 理流程不在本专利中描述。
权利要求
1. 一种在VoIP网络中传输SIP请求历史信息的方法，其特征在于其具体步骤为步骤1，为History-Info头域定义扩展参数digest；步骤2，当一个SIP应用收到SIP请求时，把请求历史信息加入History-Info头域后，用摘要算法计算出History-Info头域包含的全部内容的摘要信息，然后在History-Info头域中增加digest参数，把所述摘要信息放入到digest参数中；转发该SIP请求到下一跳的SIP应用；步骤3，下一跳的SIP应用接收到转发来的SIP请求时，首先从History-Info头域中提取出digest参数携带的摘要信息，然后从History-Info头域中删除digest参数，然后用与步骤2相同的摘要算法重新计算一遍当前History-Info头域包含的全部内容的摘要信息，把重新计算出的摘要信息和digest参数携带的摘要信息进行比较，如果比较结果一致，则认为该History-Info头域是可信的，此时当前SIP应用把自己的信息加入到History-Info头域后，用摘要算法计算出新的History-Info头域包含的全部内容的新摘要信息，然后在新的History-Info头域中增加digest参数，把所述新摘要信息放入到digest参数中；转发当前SIP请求到下一跳的SIP应用；如果比较结果不一致，则认为该History-Info头域是不可信的，转发当前SIP请求到下一跳的SIP应用前删除不可信的History-Info头域，或者请求上一跳的SIP应用重新发起请求而不进行转发。
全文摘要
一种在VoIP网络中传输SIP请求历史信息的方法，具体步骤为1.为History-Info头域定义扩展参数digest；2.当一个SIP应用收到SIP请求时，把请求历史信息加入头域后，计算头域的摘要信息并放入到digest参数中，转发该SIP请求到下一跳；3.下一跳的SIP应用从头域中提取出digest参数携带的摘要信息，然后重新计算头域的摘要信息，根据摘要信息的对比确定该History-Info头域是否可信。本发明所述方法，通过为SIP消息的请求历史信息计算摘要的方式，可以有效的规避请求历史信息被伪造、篡改、删除和重新排列等问题，而且可以摆脱对TLS这类安全网络的依赖，使该功能可以在普通的IP网络中被应用。
文档编号H04L12/56GK101547222SQ20091013669
公开日2009年9月30日 申请日期2009年5月14日 优先权日2009年5月14日
发明者刚 卢, 辉 李 申请人:烽火通信科技股份有限公司