您当前的位置是:  首页 > 新闻 > 国内 >
 首页 > 新闻 > 国内 >

MRCP学习笔记-通过SIP协议实现会话管理

2018-05-16 14:20:48   作者:james.zhu   来源:Asterisk开源派   评论:0  点击:


  在前面的分享中,我们讨论了MRCP的整体介绍,包括客户端和服务器端的相互通信的流程。在这些流程中,它涉及了SIP和RTP的传输问题。我们在很多历史文档中已经对SIP协议和RTP协议做过很多介绍,这里我们不再做更多讨论,读者可以查阅历史文章对SIP协议和RTP协议做一个补充了解。在本分享中,我们会专门针对SIP协议在MRCP中实现会话控制管理做一个比较完整的介绍,帮助读者进一步了解SIP需要在MRCP协议中的作用。在下面的分享中,我们将介绍初始化会话,初始化示例,单媒体源,分布式的媒体源。
  1、在前面的章节中,我们已经介绍了MRCP的架构。在MRCP的架构中,通过SIP来创建和管理会话,以保证MRCP客户端和服务器端的正常工作。这里,系统都使用标准的三方通信机制INVITE-200 OK-ACK的方式来创建媒体和会话控制,使用BYE-200 OK来结束会话,其中,系统使用SDP的Offer/Answer模式来进行媒体和会话支持能力,属性等的协商。在接下来的分享中,我们将通过具体的示例,并且结合握手机制,SDP协商等流程来进一步讨论关于SIP在MRCP中的角色和其作用。
  2、大家知道,SDP是MRCP客户端提供的终端侧的支持能力的描述。首先让我们看一下关于控制话的初始化过程中的SDP协商能力的支持消息。每个通道都会创建一个唯一的通道ID号,通过通道ID号和其他的通道来加以区别。以下是一段关于SDP的描述消息。
  c=IN IP4 10.0.0.1
  m=application 9 TCP/MRCPv2 // 客户端端口是9
  a=setup:active // 表示是客户端发起的,媒体服务器端则回复passive
  a=connection:new
  a=resource:speechsynth
  a=cmid:1
  通过以上的消息体,我们可以看到SDP的所描述的支持能力。这里,c=中表示一个客户端的IP地址。消息体中可能包含多个m=来媒体类型。每个m=表示单个的控制通道,并且支持一个或多个媒体资源的映射。这里的是TCP  TCP/MRCPv2,也可能支持实现TLS支持:TCP/TLS/MRCPv2。m= 中的9表示MRCP客户端的端口号。注意,MRCP客户端的端口号只能是9或0。9 表示将被丢弃的端口;0 表示一个特殊含义,此通道将被关闭。客户端也可以提供一个0端口来指示关闭MRCP的控制通道。
  MRCP客户端必须总是需要通过a=来发起一个初始化的连接。客户端的a=是active,而服务器端则会返回passive。如果是一个新的连接,则使用a=connection:new;如果是一个已存在的连接,则使用existing来表示。
  客户端通过a=resource:来指定媒体服务的类型,这里的是speechsynth。
  a=cmid则和媒体流的控制通道相关联。这里的cmid值必须匹配属于媒体流的cmid值。有一些情况下(例如,在同一个SIPdialog中,同时语音合成和语音识别同时启用,使用了单个sendrecv 媒体资源),多个媒体通道使用同一cmid值,这表示一个或多个媒体控制通道正在使用同一个媒体流资源。
  上面我们介绍了MRCP客户端初始化中INVITE的SDP消息,现在让我们看一下从服务器端返回的消息体(200 OK)包含了那些内容:
  c=IN IP4 10.0.0.22
  m=application 43251 TCP/MRCPv2
  a=setup:passive
  a=connection:new
  a=channel:43b9ae17@speechsynth
  a=cmid:1
  这里在m=中表示了服务器端口是4325,通过此支持客户端创建连接。c=包含了服务器的IP地址。a=说明了passive,通过服务器端返回的值。增加了另外一行a=,它来表示创建的通道ID。cmid和上面的客户端消息中的一致。
  3、现在,我们介绍两个会话初始化的思路,让读者能够更加清楚了解MRCP的初始化过程。以下是一个示例流程(INVITE-200 OK-ACK):
  MRCP客户端的INVITE信息示例:
  INVITE sip:mrcpv2@example.com SIP/2.0
  Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bKabc
  Max-Forwards: 70
  To:
  From: ;tag=12425
  Call-ID: 43fb8aec@host1.example.com
  CSeq: 1 INVITE
  Contact:
  Content-Type: application/sdp
  Content-Length: 264
  v=0
  o=client 2890844527 2890844527 IN IP4
  host1.example.com
  s=-
  c=IN IP4 host1.example.com
  t=0 0
  m=audio 5324 RTP/AVP 0
  a=rtpmap:0 PCMU/8000
  a=recvonly
  a=mid:1
  m=application 9 TCP/MRCPv2
  a=setup:active
  a=connection:new
  a=resource:speechsynth
  a=cmid:
  读者需要注意,这里的SDP消息体中包含了两个m=值。第一个m= 用来创建媒体流数据连接。第二个m=用来表示对媒体资源的会话控制。资源类型是speechsynth。a=recvonly表示来自MRCP客户端方向接收。
  MRCP发出INVITE请求后,MRCP服务器端返回200 OK响应消息和SDP消息体:
  SIP/2.0 200 OK
  Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bKabc
  ;received=192.168.1.11
  Max-Forwards: 70
  To: ;tag=98452
  From: ;tag=12425
  Call-ID: 43fb8aec@host1.example.com
  CSeq: 1 INVITE
  Contact:
  Content-Type: application/sdp
  Content-Length: 274
  v=0
  o=server 31412312 31412312 IN IP4 host100.example.com
  s=-
  c=IN IP4 host100.example.com
  t=0 0
  m=audio 4620 RTP/AVP 0
  a=rtpmap:0 PCMU/8000
  a=sendonly  // 发送
  a=mid:1
  m=application 9001 TCP/MRCPv2 // 通过TCP发送
  a=setup:passive // 从服务器端发出。
  a=connection:new
  a=channel:153af6@speechsynth // 通道ID
  a=cmid:1
  这里,服务器 200 OK消息中表示了服务器端的必要信息,包括了服务器端的发送端口(4620)。
  最后,MRCP客户端发送一个确认信息(ACK):
  ACK sip:mrcpv2@host100.example.com SIP/2.0
  Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bK214
  Max-Forwards: 70
  To: ;tag=98452
  From: ;tag=12425
  Call-ID: 43fb8aec@host1.example.com
  CSeq: 1 ACK
  Contact:
  Content-Length: 0
  4、在上面的介绍中,我们给出了一个创建请求的示例。但是很多情况下,MRCP客户端不可能仅实现一个请求回复的流程,在使用过程中,可能会发生很多的变化,通过发送一个re-INVITE来控制目前存在的SIPdialog会话属性,例如需要临时添加一些媒体资源或使用媒体资源后删除此媒体资源。关于SIP re-INVITE
  的详细说明读者可以查阅我们的历史文档,也可以参考其他的SIP学习资源来获取关于re-INVITE的说明。对会话的控制需要MRCP客户端重新发起一个re-INVITE消息来实现。首先,让我们看一下简单的流程示例:
  这是MRCP客户端发起的re-INVITE消息:
  INVITE sip:mrcpv2@host100.example.com SIP/2.0
  Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bK452
  Max-Forwards: 70
  To: ;tag=98452
  From: ;tag=12425
  Call-ID: 43fb8aec@host1.example.com
  CSeq: 2 INVITE
  Contact:
  Content-Type: application/sdp
  Content-Length: 367
  v=0
  o=client 2890844527 2890844528 IN IP4
  host1.example.com
  s=-
  c=IN IP4 host1.example.com
  t=0 0
  m=audio 5324 RTP/AVP 0
  a=rtpmap:0 PCMU/8000
  a=sendrecv
  a=mid:1
  m=application 9 TCP/MRCPv2
  a=setup:active
  a=connection:existing
  a=resource:speechsynth
  a=cmid:1
  m=application 9 TCP/MRCPv2 // 第三个m 增加了对recording 的控制
  a=setup:active
  a=connection:existing
  a=resource:recorder
  a=cmid:1
  从以上的re-INVITE消息中我们可以看出,事实上,INVITE消息和re-INVITE消息几乎相似,但是在存在的SIPdialog中增加了To和From。另外,因为SDP模式中的offer/answer中需要更新完整的会话属性参数,因此,MRCP客户端会修改一些参数来支持SDP协商。
  这里,读者可能注意到,o= 的数值增加了1表示会话被修改。a= 在INVITE消息中是reconly, 但是现在修改为a=sendrecv。m=也修改为existing, 而不是new。第三个m= 增加了对新recorder的会话控制。这是re-INVITE在此dialog中的真正作用。这里的recorder 和speechsynth共享同样的媒体流,因为这里的cmid仍然是1。
  接下来,服务器端接受这个re-INVITE的会话属性,然后返回一个200 OK消息:
  SIP/2.0 200 OK
  Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bK452
  ;received=192.168.1.1
  To: ;tag=98452
  From: ;tag=12425
  Call-ID: 43fb8aec@host1.example.com
  CSeq: 2 INVITE
  Contact:
  Content-Type: application/sdp
  Content-Length: 387
  v=0
  o=client 31412312 31412313 IN IP4 host100.example.com
  s=-
  c=IN IP4 host100.example.com
  t=0 0
  m=audio 4620 RTP/AVP 0
  a=rtpmap:0 PCMU/8000
  a=sendrecv
  a=mid:1
  m=application 9001 TCP/MRCPv2
  a=setup:passive
  a=connection:existing
  a=channel:153af6@speechsynth
  a=cmid:1
  m=application 9001 TCP/MRCPv2
  a=setup:passive
  a=connection:existing
  a=channel: 153af6@recorder
  a=cmid:1
  服务器端的响应消息中,其他的属性没有特别的变化,但是增加了对recorder的新的通道ID:a=channel: 153af6@recorder。
  MRCP 客户端继续发送一个ACK确认消息:
  ACK sip:mrcpv2@host100.example.com SIP/2.0
  Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bK554
  Max-Forwards: 70
  To: ;tag=98452
  From: ;tag=12425
  Call-ID: 43fb8aec@host1.example.com
  CSeq: 2 ACK
  Contact:
  Content-Length: 0
  至此,增加recorder的流程完成。
  当完成录音以后,如果MRCP需要删除recorder 资源时,则需要再对服务器端发送一个re-INVITE消息来更新其会话管理。
  INVITE sip:mrcpv2@host100.example.com SIP/2.0
  Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bK763
  Max-Forwards: 70
  To: ;tag=98452
  From: ;tag=12425
  Call-ID: 43fb8aec@host1.example.com
  CSeq: 3 INVITE
  Contact:
  Content-Type: application/sdp
  Content-Length: 367
  v=0
  o=client 2890844527 2890844529 IN IP4
  host1.example.com
  s=-
  c=IN IP4 host1.example.com
  t=0 0
  m=audio 5324 RTP/AVP 0
  a=rtpmap:0 PCMU/8000
  a=recvonly
  a=mid:1
  m=application 9 TCP/MRCPv2
  a=setup:active
  a=connection:existing
  a=resource:speechsynth
  a=cmid:1
  m=application 0 TCP/MRCPv2 // 针对相应的媒体资源更新为0-删除资源
  a=setup:active
  a=connection:existing
  a=resource:recorder
  a=cmid:1
  在以上的re-INVITE中,媒体会话已经更新为reconly 表示只能接收此会话的媒体流,以前是sendrecv 方式。同时,如果删除某一项媒体资源的话,需要在相应的m= 增加端口0表示对其媒体资源进行删除或释放。
  媒体服务器端则会回复一个200 OK消息:
  SIP/2.0 200 OK
  Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bK763
  ;received=192.168.1.1
  To: ;tag=98452
  From: ;tag=12425
  Call-ID: 43fb8aec@host1.example.com
  CSeq: 3 INVITE
  Contact:
  Content-Type: application/sdp
  Content-Length: 384
  v=0
  o=client 31412312 31412314 IN IP4 host100.example.com
  s=-
  c=IN IP4 host100.example.com
  t=0 0
  m=audio 4620 RTP/AVP 0
  a=rtpmap:0 PCMU/8000
  a=sendonly
  a=mid:1
  m=application 9001 TCP/MRCPv2
  a=setup:passive
  a=connection:existing
  a=channel:153af6@speechsynth
  a=cmid:1
  m=application 0 TCP/MRCPv2
  a=setup:passive
  a=connection:existing
  a=channel: 153af6@recorder
  a=cmid:1
  在以上的媒体资源服务器的回复中,媒体资源服务器确认会关闭recorder 端口,增加了端口0,并且对此MRCP客户端会话中的媒体发送方式修改为sendonly。
  最后,MRCP客户端会发送一个ACK确认消息表示此re-INVITE确认,删除recorder 媒体资源,然后对服务器端发送BYE消息:
  ACK sip:mrcpv2@host100.example.com SIP/2.0
  Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bK432
  Max-Forwards: 70
  To: ;tag=98452
  From: ;tag=12425
  Call-ID: 43fb8aec@host1.example.com
  CSeq: 3 ACK
  Contact:
  Content-Length: 0
  至此,整个删除recorder 媒体资源的流程结束。
  5、在上面的示例中,我们介绍了一个单媒体源的流程处理方式。现在让我们进一步讨论如何实现分布式媒体源的处理流程和SIP在处理流程中所扮演的角色。在分布式的媒体源处理流程中,媒体源可以是一个SIP终端,媒体网关或者其他的SIP应用。MRCP 客户端则作为一个背靠背代理(B2BUA)的方式工作,简单来说,媒体源来说,MRCP 客户端作为一个SIP 用户代理的方式来工作,同时,MRCP客户端也作为一种SIP 代理的模式来配合媒体资源服务器。所以,如以下示例所示,在整个会话控制流程中,MRCP 客户端会生成两个SDP描述消息。一个是针对媒体源的SDP消息,另外一个是针对媒体资源服务器的SDP消息。
  现在让我们根据以上图例所示,一步步讨论B2BUA中INVITE消息,200 OK消息中SDP消息所发生的变化。
  首先是媒体源在INVITE中提供的SDP消息(SDPo1):
  v=0
  o=Bob 31245351 31245352 IN IP4 pc02.newton.com
  s=-
  c=IN IP4 pc02.newton.com
  t=0 0
  m=audio 5632 RTP/AVP 8
  a=rtpmap:8 PCMA/8000
  a=sendrecv
  MRCP客户端接受了INVITE消息,它根据应用客户端的请求在会话中生成了媒体资源类型消息,并且根据SDPo1的描述重新生成了一个SDPo2的消息内容,这些内容会包含到MRCP客户端对媒体资源服务器发起的INVITE消息中:
  v=0
  o=Client 43523532 43523532 IN IP4 host01.example.com
  s=-
  t=0 0
  m=audio 5632 RTP/AVP 8
  c=IP IP4 pc02.newton.com
  a=rtpmap:8 PCMA/8000
  a=sendrecv
  a=mid:1
  m=application 9 TCP/MRCPv2
  c=IN IP4 host01.example.com
  a=setup:active
  a=connection:existing
  a=resource:speechsynth
  a=cmid:1
  m=application 9 TCP/MRCPv2
  c=IN IP4 host01.example.com
  a=setup:active
  a=connection:existing
  a=resource:speechrecog
  a=cmid:
  注意,这里的每个m= 都和一个c=相关联。c= 则携带了m=指定的媒体源地址
  。m=的媒体端口和媒体源的端口是一致的。
  媒体资源服务器端则回复200 OK消息,并且返回SDPa2 的消息内容:
  v=0
  o=Server 15454326 15454326 IN IP4 host99.example.com
  s=-
  t=0 0
  m=audio 87242 RTP/AVP 8 // 定义了媒体端口
  c=IP IP4 host99.example.com
  a=rtpmap:8 PCMA/8000
  a=sendrecv
  a=mid:1
  m=application 56723 TCP/MRCPv2 // 定义了媒体资源服务类型
  c=IN IP4 host99.example.com
  a=setup:passive
  a=connection:existing
  a=channel:42a6f3e9@speechsynth
  a=cmid:1
  m=application 56723 TCP/MRCPv2 // 定义了媒体资源服务类型
  c=IN IP4 host99.example.com
  a=setup:passive
  a=connection:existing
  a=channel: 42a6f3e9@speechrecog
  a=cmid:1
  在SDPa2 中,媒体资源服务器通知MRCP客户端使用的端口和其使用的媒体资源服务类型,通道ID等消息。
  MRCP客户端收到媒体资源服务器端返回的200 OK消息,然后基于SDPa2的描述内容,再次生成新的SDPa1 描述内容发送到媒体源::
  v=0
  o=Client 24356331 24356331 IN IP4 host01.example.com
  s=-
  c=IP IP4 host99.example.com // 这里定义了媒体资源服务器的地址
  t=0 0
  m=audio 87242 RTP/AVP 8
  a=rtpmap:8 PCMA/8000
  a=sendrecv
  这里定义了媒体资源服务器的地址。媒体源对MRCP客户端发送ACK消息确认,MRCP客户端继续对媒体资源服务器发送ACK消息确认。至此,媒体源,MRCP客户端和媒体资源服务器之间的协商流程完成,媒体流数据可以正式发送。
  6、通过以上多个示例的介绍,我们把整个SIP协议在进行握手处理中SDP消息的内容变化都进行了介绍,并且通过完整的示例流程介绍了MRCP客户端,媒体资源服务器端的SDP消息说明,另外也介绍了分布式媒体源和MRCP协议的通过B2BUA的方式进行媒体资源服务器的协商处理,和在其消息生成过程中各自SDP的描述变化。笔者希望通过此章节的介绍笔者用户基本了解了SIP协议在MRCP协商过程中所扮演的控制角色,对MRCP流程有一个非常清晰的概念。在接下来的章节中,我们会针对媒体资源服务器的分布式部署查询定位的处理进行讨论介绍。
  

  unimrcp-MRCP协议学习分享,QQ群号:208136295
  关注微信公众号:asterisk-cn,获得有价值的行业分享
  freepbx 技术论坛:www.ippbx.org.cn
  Asterisk, freepbx技术文档: www.freepbx.org.cn
  欧米(Omni)智能客服解决方案
  融合通信商业解决方案,协同解决方案首选产品:www.hiastar.com
 
【免责声明】本文仅代表作者本人观点,与CTI论坛无关。CTI论坛对文中陈述、观点判断保持中立,不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。请读者仅作参考,并请自行承担全部责任。

相关阅读:

专题

博评网