MirrorLink（五 RTP client--整合RTP库到项目中）

本文主要是介绍MirrorLink（五 RTP client--整合RTP库到项目中），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

一、整合RTP库（example1.cpp）到项目中进行编译

提示错误：

/mnt/hgfs/ubuntu/MAKE/example1/src/anw_rtp.cpp:40: undefined reference to `jrtplib::RTPGetErrorString[abi:cxx11](int)'

修改方法：

增加：-D_GLIBCXX_USE_CXX11_ABI=0
修改前：C++FLAGS = $(CFLAGS_DEBUG) -c -g

修改后：C++FLAGS = $(CFLAGS_DEBUG) -c -g -D_GLIBCXX_USE_CXX11_ABI=0

二、文档说明:

1、启动手机端的RTP Server:

通过UPNP发送LaunchApplication() action（UPnP Application Server Service文档中有描述）启动RTP Server application，

（1）MirrorLink UPnP Control Point（MirrorLink Client端）调用GetApplicationList()获取applist

（2）MirrorLink UPnP Server（MirrorLink Server端）返回A_ARG_TYPE_AppList

（3）MirrorLink Client通过protocolID and direction elements来确定具体启动那个RTP app

例如：

<app><appID>0x5</appID><name>RTP Server 99</name><description>RTP Audio Server</description><allowedProfileIDs>0</allowedProfileIDs><remotingInfo><protocolID>RTP</protocolID><format>99</format><direction>out</direction><audioIPL>4800</audioIPL><audioMPL>9600</audioMPL></remotingInfo><appInfo><appCategory>0xf0000001</appCategory><trustLevel>0x80</trustLevel></appInfo><audioInfo><audioType>application</audioType><contentCategory>0x2</contentCategory><contentRules>0x0</contentRules><trustLevel>0x80</trustLevel></audioInfo><resourceStatus>free</resourceStatus>
</app>

上面是获取到的applist中其中一个RTP Server app的配置，我们根据

remotingInfo.protocolID:RTP

audioInfo.contentCategory:0x2（如果是voice command，应该判断这个值是0x10）

注意：audioInfo.contentCategory在audio文档中说是0x1

但是按照upnp application server文档应该是bit 1即0x2

确定这就是我们要选择的app

（4）MirrorLink UPnP Control Point（MirrorLink Client端）调用LaunchApplication() action启动对应的RTP server app

（5）MirrorLink Server会启动对应的RTP Server

（6）MirrorLink UPnP Server返回一个 A_ARG_TYPE_URI

<?xml version="1.0"?>
<u:LaunchApplicationResponse xmlns:u="urn:schemas-upnp-org:service:TmApplicationServer:1">
<AppURI>RTP://192.168.42.129:10600</AppURI>
</u:LaunchApplicationResponse>

（7）MirrorLink Client根据URL启动RTP Client

2、RTP AUDIO STREAMING
MirrorLink server必须能够发送单向RTP audio streaming给MirrorLink client
MirrorLink Client必须能够接收来自MirrorLink Server的单向RTP audio streaming
MirrorLink server可能支持发送双向RTP audio streaming，注意：如果MirrorLink server不支持双向RTP streaming，那么电话通话只能使用BT HFP。

RTP packet包含：RTP header和payload

（1）RTP header的结构：

第一部分：

上面的12个字符是每个RTP包都包含的。

Version (V 2 bits) : The RTP version defined by this specification is two (2).这个不用关注，jrtplib中默认就是2

Padding (P 1bit) : If the padding bit is set, the packet contains one or more additional padding octets at the end which are not part of the payload. 这个不用关注，jrtplib中默认是0

Extension (X 1 bit) : If the extension bit is set, the fixed header MUST be followed by exactly one header extension. If the RTP header carries information about the audio category and application id, then this bit MUST be one (1).
CSRC count (CC 4bits) : The CSRC count contains the number of CSRC identifiers that follow the fixed header.这个不用关注，暂时没有用到
Marker (M 1bit) : The interpretation of the marker is defined ;
0: More packets will follow.
1: Current package carries the end of stream
Payload type (PT 7 bits) :This field identifies the format of the RTP payload and determines its interpretation by the application.
Sequence number （16 bits）: The sequence number increments by one for each RTP data packet sent, and MAY be used by the receiver to detect packet loss and to restore packet sequence.这个不用关注，jrtplib中自己维护

Timestamp（32 bits） :The timestamp reflects the sampling instant of the first octet in the RTP data packet. The initial value of the timestamp is random.这个不用关注，jrtplib中自己维护
SSRC Synchronization source（32 bits） : This field identifies the synchronization source. 这个不用关注，暂时没有用到
CSRC Contributing Source （32 bits）: An array of 0 to 15 CSRC elements identifying the contributing sources for the payload contained in this packet. The number of identifiers is given by the CC field.这个不用关注，暂时没有用到

第二部分：如果第一部分RTP Header中的Extension (X 1 bit) 为1，则RTP包中需要添加第二部分

Profile Identifier（16bits）: Profile identifier for the extension header; MUST be 0x388C
Length（16bits）: Number of 32-bit words for the extension, excluding the extension header (therefore 0 is a valid length).Length MUST be an even number.
Header Extension（Array of 64 bits，所以上面的Length必须是偶数）:
The first 32 bits give the unique application id. For an application being advertised via UPnP, the unique application id MUST match the advertised appID. This field MAY be left empty (i.e. zero value).
The second 32 bits give the application category

（2）RTP Audio Payload Definition

RTP payload type是MirrorLink Server和MirrorLink Client通过UPNP进行提前协商的。

（MirrorLink Client先调用SetClientProfile通知自己支持的payload type，然后通过GetApplicationList获取到某个app支持的payload type）

MirrorLink主要关注3个payload type：0,98,99

其中RTP Server应该支持payload type 0，必须支持payload type 99；RTP Client必须支持payload type 99

type 0：8bit，8khz，单声道

type 98：signed 16bit（大端），48khz，单声道

type 99：signed 32bit（大端，每个声道16bit），48khz，双声道

3、Establishing the RTP Connection

RTP streaming是基于UDP传输的。

（1）RTP Server within MirrorLink Server

MirrorLink Client此时需要建立一个RTP Client，ip和port根据LaunchApplication() action（启动MirrorLink Server端的RTP server）获取的URL确定

具体流程如下：

1）. RTP server: 等待UDP包（1byte的udp包，注意：不是RTP payload长度是1byte，是整个udp包只有1byte，这个byte是任意值）
2）. RTP client: 向RTP server发送1 byte UDP packet
3）. RTP client: 然后等待接收数据
4）. RTP server: 确定client的IP和port
5）. RTP server: 开始发送 RTP streaming; 如果没有数据，应该发送一个没有payload的空的RTP packet
6）. RTP client：开始接收RTP packets.
7）. RTP client: 如果RTP client没有接收到任何的RTP packets，那么RTP client必须每隔一段时间发送1 byte的 UDP packets

（2）RTP Server within MirrorLink Client

MirrorLink Client此时需要建立一个RTP Server，目标ip和port根据LaunchApplication() action（启动MirrorLink Server端的RTP client）获取的URL确定

1）. UPnP Control Point: Invoke UPnP LaunchApplication action for the respective RTP Client on the MirrorLink Server.
2）. UPnP Server: Return IP address and port number for the RTP client as a reply for the LaunchApplicationRequest action.
3）. RTP Client: Get ready for getting RTP streaming
4）. RTP Server: Starts RTP streaming; if no audio data available, RTP Server SHOULD send a single RTP packet, without data payload.

4、VOICE COMMAND HANDLING

Voice Command中用到了VNC Device Status message中的Voice Command and Microphone flags

注意：Device Status Voice Command flag 用来表示VC session的开始和结束，Device Status Microphone flag表示一条Voice Commands的开始和结束，如果一个vc session只包含一条voice command，则可以用下图来表示：

1）MirrorLink Client发送VNC Device Status Request （测试发现Voice Command和Microphone都要设置成enable，如果只设置Voice Command华为手机异常）请求建立vc session

2）MirrorLink Server 决定是否建立vc session，并且发送VNC Device Status（Voice Command enabled or disabled），建立vc session则Voice Command为enabled，否则是disabled

3）MirrorLink Server 发送VNC Device Status（Microphone enabled ）请求MirrorLink Client打开microphone

4）MirrorLink Client 打开microphone,然后立即发送RTP streaming（注意：rtp包的RTP header extension等于0xF0000010 或者0xF0000020）

5）如果mic被占用，则MirrorLink Client接收到VNC Device Status Microphone enabled message以后必须回复VNC Device Status Request Microphone disabled message
6）MirrorLink Server 停止microphone输入时必须发送VNC Device Status Voice Mic disabled message. MirrorLink Server or Client 停止VC session时必须VNC Device Status Request message （Voice Command flag disabled）
7）the MirrorLink Server 如果请求继续VC回话, 需要发送一个新的VNC Device Status message（Microphone flag enabled），具体流程如下（但是测试发现，手机根本不按照这个流程来，开启和关闭语音识别的时候，我们收不到任何消息）：

The MirrorLink Server SHOULD send VNC Device Status with the Voice Command flag enabled together with or before Microphone flag enabled (Δt_vr-mic ≥ 0)
The MirrorLink Server SHOULD send VNC Device Status with the Voice Command flag disabled together with or after Microphone disabled (Δt_mic-vr ≥ 0)

VC session发生在Phone Call过程中，流程图如下（目前测试发现三星和华为手机都不支持双向（bi）的RTP，所以这个不用管）：