关于声纹验证

在前面的讲座中，我们介绍了MRCP媒体资源的几个主要类型，它们分别是语音合成资源，语音识别资源和录音资源的所有请求，事件和headers的细节。今天的讲座中，我们介绍MRCP媒体资源的最后一个资源类型-说话人验证资源（speaker verification resource-speakverify）。

　　1、说话人验证资源对MRCP客户端提供说话人的验证和确认功能。说话人验证主要关心的是说话人应该是谁。通常情况下，说话人验证是通过他们自己声明的身份数据来验证。说话人通过一系列的验证方式来关联身份验证。这一系列的验证方式包括输入密码，客户ID，或者呼叫号码绑定的方式来加以验证。说话人的语句可以和其保存的声纹语句进行对比来确认其身份，然后执行通过或者拒绝的流程。而说话人确认功能则处理的是通过从多人的说话语句中识别出其身份，它通过已录制的语句对比一组存储的说话人声纹来确认说话人身份。简单来说，说话人确认就是一个已录制的语音和一组或者多组存储的声纹进行对比，识别出其身份。事实上，如果从MRCP说话人验证资源的角度来讨论的话，说话人确认可以看作为多组声纹的说话人验证方式。因此，为了讨论方便，我们通常使用说话人验证来表示验证和确认步骤。另外，MRCP验证资源的处理方式和基于文本方式的处理方式是相似的，它也借用了自然语言语义标识语音的语法格式来封装说话人验证和确认的结果。

　　2、MRCP验证资源可以在两种工作模式下执行，它可以配合语音识别资源或录音资源来工作，也可以独立工作。当独立工作时，它在媒体会话中通过实时传输的方式获得的语音数据，然后对语音数据进行分析。当结合其他媒体资源工作时，验证资源会通过验证资源的缓冲和语音识别资源或录音资源共享缓冲数据。通过设定Ver-Buffer-Utterance header，语音识别资源和录音资源可以对缓冲进行数据写入的操作。在语音识别或录音过程中，这个缓冲中的语音数据可以后续支持说话人验证或者确认的分析任务。

　　MRCP验证资源支持十一个请求消息，两个事件消息，二十个headers和一个状态机。状态机可支持两种工作模式：训练模式和验证模式。状态机的状态改变是通过VERIFY或VERIFY-FROM-BUFFER method来实现。验证资源的状态机的工作流程图如下：

　　3、START-SESSION method 是用来启动一个训练或验证会话。Verification-Mode header可以用来表示其启动的会话模式。这个会话类型值包括：train和verify。如果设置为验证会话的话，它会绑定声纹的数据仓库，其路径通过Repository-URI来表示。每个会话可以绑定一个或多个声纹，他们通过各自的声纹ID Voiceprint-Identifier header表示。这里需要读者注意，结合本章节前面谈到的关于验证资源和确认资源的区别，他们的使用方式在在这里得到了体现。如果是验证资源的话，指定的是一个声纹资源URL。如果是说话人确认的话，可以支持多个声纹路径，通过分号分开多个声纹资源。在训练期间的话，如果声纹不存在的话，系统会自动创建。其请求的图例如下：

　　现在，我们看一下此请求的消息流程：

　　F1 （client → speakverify）:

• MRCP/2.0 194 START-SESSION 00001
• Channel-Identifier: 1cd3ee59@speakverify
• Verification-Mode: train
• Repository-URI: http://example.com/voiceprintdatabase
• Voiceprint-Identifier: dave.burke

　　F2 （speakverify → client）:

• MRCP/2.0 76 00001 200 COMPLETE
• Channel-Identifier: 1cd3ee59@speakverify

　　END-SESSION请求支持结束训练或验证会话。在Abort-Model header创建声纹，这个声纹则反映更新状态。如果声纹更新，则可能是训练会话被激活，或者验证会话被激活，同时声纹状态信息也会更新。声纹更新是通过START-SESSION会话中设置 header Adapt-Model 为true来实现。如果Abort-Model设置为false，则会导致声纹的任何修改都最终保存到数据库中。如果此header设置为true，则会丢弃任何对声纹的修改。以下是结束会话的图例：

　　其具体的消息流程如下：

　　F1 （client → speakverify）:

• MRCP/2.0 95 END-SESSION 10000
• Channel-Identifier: 1cd3ee59@speakverify
• Abort-Model: false

　　F2 （speakverify → client）:

• MRCP/2.0 76 10000 200 COMPLETE
• Channel-Identifier: 1cd3ee59@speakverify

　　4、VERIFY method是验证资源对实时语音通过媒体会话进行传输，启动声纹训练，或启动验证，并且对比多组声纹数据。具体的操作模式是在START-SESSION的header Verification-Mode中设置。当VERIFY 请求完成后，验证资源会生成一个VERIFICATION-COMPLETE事件消息。NLSML数据会包含在这个事件消息中，包括训练状态和验证状态数据。以下图例是一个训练模式下的流程图：

　　具体的训练流程消息如下：

　　F1 （client → speakverify）:

• MRCP/2.0 194 START-SESSION 20000
• Channel-Identifier: 1cd3ee59@speakverify
• Verification-Mode: train
• Repository-URI: http://example.com/voiceprintdatabase
• Voiceprint-Identifier: dave.burke

　　F2 （speakverify → client）:

• MRCP/2.0 76 20000 200 COMPLETE
• Channel-Identifier: 1cd3ee59@speakverify

　　F3 （client → speakverify）:

• MRCP/2.0 70 VERIFY 20001
• Channel-Identifier: 1cd3ee59@speakverify

　　F4 （speakverify → client）:

• MRCP/2.0 79 20001 200 IN-PROGRESS
• Channel-Identifier: 1cd3ee59@speakverify

　　F5 （speakverify → client）:

• MRCP/2.0 90 START-OF-INPUT 20001 IN-PROGRESS
• Channel-Identifier: 1cd3ee59@speakverify

　　F6 （speakverify → client）:

• MRCP/2.0 921 VERIFICATION-COMPLETE 20001 COMPLETE
• Channel-Identifier: 1cd3ee59@speakverify
• Completion-Cause: 000 success
• Content-Type: application/nlsml+xml
• Content-Length: 737
• <?xml version="1.0" encoding="UTF-8"?>
• <result xmlns="http://www.ietf.org/xml/ns/mrcpv2">
• <verification-result>
• <voiceprint id="dave.burke">
• <incremental>
• <device>cellular-phone</device>
• <gender>male</gender>
• <utterance-length>751</utterance-length>
• </incremental>
• <cumulative>
• <verification-score>0.93</verification-score>
• <device>cellular-phone</device>
• <gender>male</gender>
• <utterance-length>1522</utterance-length>
• <need-more-data>false</need-more-data>
• </cumulative>
• </voiceprint>
• </verification-result>
• </result>

　　F7 （client → speakverify）:

• MRCP/2.0 95 END-SESSION 20002
• Channel-Identifier: 1cd3ee59@speakverify
• Abort-Model: false

　　F8 （speakverify → client）:

• MRCP/2.0 76 20002 200 COMPLETE
• Channel-Identifier: 1cd3ee59@speakverify

　　5、VERIFY-FROM-BUFFER 请求的和VERIFY的工作方式相同，但是VERIFY-FROM-BUFFER的语音流源来自于验证缓冲而不是来自于实时的语音数据。验证缓冲数据写入的方式支持通过说话人验证资源写入数据，通过VERIFY请求的头中设置Ver-Buffer-Utterance为true来获得支持，也可以通过语音识别资源分配同样的SIP dialog，通过RECOGNIZE请求中设置Ver-Buffer-Utterance为true的方式写入，还可以通过录音资源分配同样的SIP dialog，通过RECORD请求中设置Ver-Buffer-Utterance为true来获得支持。这里，需要读者注意，系统不会为VERIFY-FROM-BUFFER 请求生成START-OF-INPUT事件消息。

　　使用从验证缓冲中验证说话人有几个方面的理由。语音识别资源可以用来验证其用户身份（例如通过识别客户账户），然后，紧接着此语音数据可以和其相应的声纹进行匹配。另外，如果VERIFY请求验证用户失败的话，但是MRCP客户端希望使用同样的语音数据匹配其他不同的声纹资源，这个资源可以被重复使用。这里我们假设，初始的VERIFY已传输了Ver-Buffer-Utterance为true的header，验证缓冲将被写入，START-SESSION 创建了一个新的会话支持了不同的声纹，VERIFY-FROM-BUFFER请求也已经启动。以下是一个VERIFY-FROM-BUFFER图例：

　　具体的消息流程如下：

　　F1 （client → speakverify）:

• MRCP/2.0 82 VERIFY-FROM-BUFFER 30000
• Channel-Identifier: 1cd3ee59@speakverify

　　F2 （speakverify → client）:

• MRCP/2.0 79 30000 200 IN-PROGRESS
• Channel-Identifier: 1cd3ee59@speakverify

　　F3 （speakverify → client）:

• MRCP/2.0 986 VERIFICATION-COMPLETE 30000 COMPLETE
• Channel-Identifier: 1cd3ee59@speakverify
• Completion-Cause: 000 success
• Content-Type: application/nlsml+xml
• Content-Length: 802
• <?xml version="1.0" encoding="UTF-8"?>
• <result xmlns="http://www.ietf.org/xml/ns/mrcpv2">
• <verification-result>
• <voiceprint id="dave.burke">
• <incremental>
• <verification-score>0.85</verification-score>
• <device>carbon-button-phone</device>
• <gender>male</gender>
• <utterance-length>751</utterance-length>
• </incremental>
• <cumulative>
• <verification-score>0.81</verification-score>
• <device>carbon-button-phone</device>
• <gender>male</gender>
• <decision>accepted</decision>
• <utterance-length>801</utterance-length>
• </cumulative>
• </voiceprint>
• </verification-result>
• </result>

　　6、VERIFY-ROLLBACK 请求时回滚到前面VERIFY或VERIFY-FROM-BUFFER的请求，因此，前面已处理的语音数据不再用于声纹训练（训练会话中）和声纹的调整环境中（验证会话）。如果多次发起VERIFY-ROLLBACK请求，则会导致无效回滚。以下是一个回滚请求的图例：

　　VERIFY-ROLLBACK 的消息流程：

　　F1（client→speakverify）:

• MRCP/2.0 79 VERIFY-ROLLBACK 40000
• Channel-Identifier:1cd3ee59@speakverify

　　F2（speakverify→client）:

• MRCP/2.0 76 40000 200 COMPLETE
• Channel-Identifier:1cd3ee59@speakverify

　　START-INPUT-TIMERS请求用来支持对验证资源启动定时器。启动默认环境下，当发起一个VERIFY请求时，系统会自动启动No-Input-Timeout的定时器。如果在定时器时间范围内，验证资源没有检测到任何输入的话，VERIFY请求会结束这个请求，并且生成VERIFICATION-COMPLETE消息，消息中说明了Completion-Cause，其值为002 no-input-timeout。通常情况下，如果用户完成输入的话，MRCP 客户端会马上发起VERIFY请求。但是，在有一些应用场景中，我们需要用户输入的同时在同一时间内启动训练或验证流程。因此，它可以支持熟悉的用户可以打断输入，并且尽早启动训练或验证资源。有时，在提示回放的同时，训练/验证资源也同时启动，如果用户不想启动No-Input-Timeout 定时器，他/她需要让系统完成提示回放以后，才开始启动定时器。用户可以VERIFY消息中设置Start-Input-Timers header为false来实现以上要求。如果在稍后的处理过程中，MRCP客户端知道提示回放已经完成的话，客户端可以对验证资源发起START-INPUT-TIMERS启动No-Input-Timeout定时器。 以下是一个START-INPUT-TIMERS图例：

　　START-INPUT-TIMERS 的消息流程：

　　F1（client→speakverify）:

• MRCP/2.0 70 VERIFY 50000
• Channel-Identifier:1cd3ee59@speakverify

　　F2（speakverify→client）:

• MRCP/2.0 79 50000 200 IN-PROGRESS
• Channel-Identifier:1cd3ee59@speakverify

　　F3（client→speakverify）:

• MRCP/2.0 82 START-INPUT-TIMERS 50001
• Channel-Identifier:1cd3ee59@speakverify

　　F4（speakverify→client）:

• MRCP/2.0 76 5000 1200 COMPLETE
• Channel-Identifier:1cd3ee59@speakverify

　　F5（speakverify→client）:

• MRCP/2.0 90 START-OF-INPUT 50000 IN-PROGRESS
• Channel-Identifier:1cd3ee59@speakverify

　　F6（speakverify→client）:

• MRCP/2.0 920 VERIFICATION-COMPLETE 50000 COMPLETE
• Channel-Identifier:1cd3ee59@speakverify
• Completion-Cause: 000 success
• Content-Type:application/nlsml+xmlContent-Length:736<?xmlversion="1.0"encoding="UTF-8"?>
• <result xmlns="http://www.ietf.org/xml/ns/mrcpv2">
• <verification-result>
• <voiceprintid="dave.burke">
• <incremental>
• <device>cellular-phone</device>
• <gender>male</gender>
• <utterance-length>751</utterance-length>
• </incremental>
• <cumulative>
• <verification-score>0.53</verification-score>
• <device>cellular-phone</device>
• <gender>male</gender>
• <utterance-length>1522</utterance-length>
• <need-more-data>true</need-more-data>
• </cumulative>
• </voiceprint>
• </verification-result>
• </result>

　　当VERIFY或VERIFY-FROM-BUFFER请求正在处理中时，MRCP客户端可以发出GET-INTERMEDIATE-RESULT请求要求获得更多累计的验证资源。这里读者要注意，GET-INTERMEDIATE-RESULT的响应消息中包含NLSML数据，因为请求仍然进行中，还没有完成，所以响应消息中没有Completion-Cause header。当验证资源在空闲状态时，MRCP客户端发送GET-INTERMEDIATE-RESULT请求时，它会收到402 Method not valid in this state 响应码。以下是GET-INTERMEDIATE-RESULT图例：

　　消息流程如下：

　　F1 （client → speakverify）:

• MRCP/2.0 87 GET-INTERMEDIATE-RESULT 60000
• Channel-Identifier: 1cd3ee59@speakverify

　　F2 （speakverify → client）:

• MRCP/2.0 934 60000 200 COMPLETE
• Channel-Identifier: 1cd3ee59@speakverify
• Content-Type: application/nlsml+xml
• Content-Length: 799
• <?xml version="1.0" encoding="UTF-8"?>
• <result xmlns="http://www.ietf.org/xml/ns/mrcpv2">
• <verification-result>
• <voiceprint id="dave.burke">
• <incremental>
• <verification-score>0.53</verification-score>
• <device>cellular-phone</device>
• <gender>male</gender>
• <utterance-length>751</utterance-length>
• </incremental>
• <cumulative>
• <verification-score>0.67</verification-score>
• <device>cellular-phone</device>
• <gender>male</gender>
• <utterance-length>1522</utterance-length>
• <need-more-data>true</need-more-data>
• </cumulative>
• </voiceprint>
• </verification-result>
• </result>

　　STOP method用来支持正在进行的训练验证资源，资源状态返回到空闲状态。STOP 的响应消息中会包含Active-Request-Id-List 列表，表示结束的ID。在STOP请求method中可以包含一个Abort-Verification 头，此header可以用来表示训练验证结果是否丢弃（true）或者保持（false）。 如果是false的话，STOP请求的响应消息中包含验证结果。以下是STOP 请求的图例：

　　具体的消息流程图：

　　F1 （client → speakverify）:

• MRCP/2.0 70 VERIFY 70000
• Channel-Identifier: 1cd3ee59@speakverify

　　F2 （speakverify → client）:

• MRCP/2.0 79 70000 200 IN-PROGRESS
• Channel-Identifier: 1cd3ee59@speakverify

　　F3 （client → speakverify）:

• MRCP/2.0 95 STOP 70001
• Channel-Identifier: 1cd3ee59@speakverify
• Abort-Verification: true

　　F4 （speakverify → client）:

• MRCP/2.0 108 70001 200 COMPLETE
• Channel-Identifier: 1cd3ee59@speakverify
• Active-Request-Id-List: 70000

　　CLEAR-BUFFER method用来清除验证缓冲数据。在前面的讨论中，我们已经介绍了如何实现缓冲数据写入。这里，使用CLEAR-BUFFER来清除缓冲数据。具体的缓冲清除图例如下：

　　清除验证缓冲数据的消息流程如下：

　　F1 （client → speakverify）:

• MRCP/2.0 76 CLEAR-BUFFER 80000
• Channel-Identifier: 1cd3ee59@speakverify

　　F2 （speakverify → client）:

• MRCP/2.0 76 80000 200 COMPLETE
• Channel-Identifier: 1cd3ee59@speakverify

　　QUERY-VOICEPRINT method用来支持MRCP客户端对验证资源进行声纹数据查询。声纹数据是通过Repository-URI和Voiceprint-Identifier 来确定。在给定的URL资源中，每个Voiceprint-Identifier 设定了一个唯一的ID。QUERY-VOICEPRINT 响应消息中会包含一个布尔值Voiceprint-Exists来表示此声纹是否存在。如果Repository-URI 不存在，则返回响应消息，并且相当Completion-Cause: 007 repository-uri-failure header。 以下是一个查询声纹资源的图例：

　　查询声纹消息流程：

　　F1 （client → speakverify）:

• MRCP/2.0 171 QUERY-VOICEPRINT 90000
• Channel-Identifier: 1cd3ee59@speakverify
• Repository-URI: http://example.com/voiceprintdatabase
• Voiceprint-Identifier: dave.burke

　　F2 （speakverify → client）:

• MRCP/2.0 102 90000 200 COMPLETE
• Channel-Identifier: 1cd3ee59@speakverify
• Voiceprint-Exists: true

　　DELETE-VOICEPRINT method用来支持MRCP客户端删除声纹，具体的声纹身份确认由Repository-URI 和Voiceprint-Identifier构成。 这里，读者要注意，如果指定的需要删除的声纹不存在的话，不会会任何返回错误。图例是删除声纹的流程：

　　具体的删除声纹的消息流程如下：

　　F1 （client → speakverify）:

• MRCP/2.0 173 DELETE-VOICEPRINT 100000
• Channel-Identifier: 1cd3ee59@speakverify
• Repository-URI: http://example.com/voiceprintdatabase
• Voiceprint-Identifier: dave.burke

　　F2 （speakverify → client）:

• MRCP/2.077100000200COMPLETE
• Channel-Identifier:1cd3ee59@speakverify

　　7、验证资源包括两个消息事件，两个事件分别是START-OF-INPUT和VERIFICATION-COMPLETE。这两个事件在前面的章节中都有完整的消息示例，读者可以参考那些示例来进一步了解这两个事件。

　　START-OF-INPUT事件是由说话人验证资源生成，通知MRCP客户端已经收到输入数据。MRCP客户端使用此事件来进行语音打断检测或者停止语音回放。

　　VERIFICATION-COMPLETE是由说话人验证资源生成来对MRCP客户端说明训练/验证流程已经完成，正在消息体中传输训练或验证结果。Completion-Cause和可选Completion-Reason header来表示训练或验证的完成状态。

　　8、MRCP协议的验证资源支持了二十个headers。现在，我们逐一介绍这些headers的使用方式。

• Completion-Cause，此header总是出现在VERIFICATION-COMPLETE的响应事件中，用来表示VERIFY或VERIFY-FROM-BUFFER请求完成的原因。注意，它也可能出现在VERIFY，VERIFY-FROM-BUFFER或QUERY-VOICEPRINT请求中，包含失败状态码。名称等消息。示例：Completion-Cause:005 buffer-empty。
• Completion-Reason，此header是可选的header，通常伴随着Completion-Cause header一起出现，为MRCP客户端排查提供更多log消息。示例：Completion-Reason:Out of memory。
• Verification-Mode，此header用来表示在START-SESSION的验证类型，是训练模式（train）还是验证模式（verify）。示例：Verification-Mode:train。
• Repository-URI，此header用来表示在START-SESSION，QUERY-VOICEPRINT或DELETE-VOICEPRINT中的声纹，此声纹所存储的数据库中的URL地址。示例：Repository-URI:file://host/voiceprintdb/。
• Voiceprint-Identifier，此header在说话人验证资源中已声明的确认身份。对于说话人确认来说，此header可以包含单个声纹或者一组说话人声纹。此header在START-SESSION，QUERY-VOICEPRINT或DELETE-VOICEPRINT请求中设定。此header的值的格式必须是两组字符串，通过句号分开。示例：Voiceprint-Identifier:joe.bloggs。
• Adapt-Model, 此header使用在START-SESSION请求中，表示当验证资源成功执行后，是否可以对声纹进行调整，通过调整可以提高验证的准确率。默认为false。示例：Adapt-Model:true。
• Abort-Model，此header可以在END-SESSION请求中设定，它用来表示任何声纹的修改结果可以被丢弃或保存在数据库。如果在header中设置为true，表示丢弃修改结果；false则表示保存修改结果。示例为：Abort-Model:true。
• Min-Verification-Score，此header表示验证评分最小值，验证资源决定可接受范围。其取值范围在-1.0-1.0之间。示例为：Min-Verification-Score:0.75。
• Num-Min-Verification-Phrases, 此header设定的最小语句，此最小语句值是认证资源要求的可接受的最小数值。默认值为1，示例为：Num-Min-Verification-Phrases：2。
• Num-Max-Verification-Phrases，此header设定的最大语句数量，在验证结果决定之前所接受的最大语句数量。示例：Num-Max-Verification-Phrases: 3。
• No-Input-Timeout，此header用来设定的检测输入超时的时长。此取值以毫秒为单位。无默认值设置。示例：No-Input-Timeout: 3000。
• Save-Waveform，此header为一个布尔值，用来表示说话让验证资源是否在验证过程中保存捕捉到语音。如果设置为true，生成的事件VERIFICATION-COMPLETE中包含Waveform-URI来提示保存文件的路径，MRCP客户端可以通过此URL获取到捕捉到语音数据。默认值为false，示例为：Save-Waveform: true。
• Media-Type，此header表示捕捉到的语音数据的格式。示例为：Media-Type: audio/x-wav。MRCP不会强制使用某种特定的语音格式。
• Waveform-URI，此header表示在实时验证中捕捉到语音数据URL地址，用来和MRCP客户端进行通信。如果Save-Waveform设定为true，此header会出现在VERIFICATION-COMPLETE事件中。此取值会追加数据大小（bytes）和时长（毫秒）参数设置。在存活的会话过程中，此URL必须是可访问的。如果录音时产生错误的话，Waveform-URI为空。示例：Waveform-URI: <http://10.0.0.1/utt01.wav>;size=8000;duration=1000。
• Input-Waveform-URI，此header是为VERIFY请求method提供语音数据，而不是使用媒体会话的方式。此header在某些环境下非常有用，当需要前面的资源提供识别时，语音识别资源和语音验证资源都是独立分离的状态，可能各自在不同的会话。示例：Input-Waveform-URI: http://10.0.0.1/utt01.wav。
• Voiceprint-Exists，此header是一个布尔值，表示声纹URL是否存在。它存在于QUERY-VOICEPRINT 和 DELETE-VOICEPRINT响应消息中。示例：Voiceprint-Exists: false。
• Ver-Buffer-Utterance, 此header可以通过VERIFY请求中设定。如果此值设定为true, 则表示验证资源可以支持对捕捉到录音作为缓冲，以支持会话的后期使用。这里，读者要注意，在同一SIP dialog中的语音识别资源或录音资源可以通过其各自的请求方式对缓冲进行写入操作。默认值为false。示例是：Ver-Buffer-Utterance: true。
• New-Audio-Channel，此header可以通过VERIFY请求来设定。如果此header设置为true，则对验证资源表示，从此刻起，新通道会接收语音数据。说话人验证资源通常会以请求的方式打断现在的通道，重新对终端设置新的算法，丢弃前面通道中的历史数据。默认值为false，示例：New-Audio-Channel: true。
• Abort-Verification，此header在STOP请求中出现，表示是否丢弃或保留已训练或验证的结果。如果设置为true，则表示丢弃训练结果。示例：Abort-Verification: true。
• Start-Input-Timers，此header可能出现在VERIFY请求中，通知说话人验证资源是否启动No-Input-Timeout 定时器。默认为true。示例：Start-Input-Timers: false。

　　9、在本讲座中，我们首先介绍了说话人验证资源的背景知识，验证资源和确认资源的区别，然后分别介绍了验证资源的请求方式，事件和所有验证资源的headers。在每个请求方式的介绍过程中，笔者结合具体的流程图和消息流程做了非常详细的解释，以及需要读者特别注意到对方。另外，对headers也做了非常详细的解释，这样可以帮助读者能够完全掌握MRCP协议中说话人验证资源的所有相关细节。

　　到目前为止，我们已经基本上介绍了整个MRCP协议的主体部分。在后续的章节中，笔者会根据时间安排等实际情况，更多讨论MRCP相关的安全方面的话题和其应用实践。

 

转载自：

http://ec.ctiforum.com/jishu/qiye/qiyetongxinjishu/kaiyuantongxin/jishudongtai/540755.html

版权归原作者所有