LIN LING (CN)
LIANG WEI (CN)
LIN LING (CN)
| CN102082675A | 2011-06-01 | |||
| CN101046736A | 2007-10-03 | |||
| CN101123702A | 2008-02-13 |
北京同立钧成知识产权代理有限公司 (CN)
| 权 利 要 求 书 1、 一种远程呈现会议业务处理方法， 其特征在于， 包括： 获取包含至少两个屏的远程呈现会议终端的主辅屏绑定关系； 根据所述主辅屏绑定关系 ,向媒体资源服务器 MRS发送用于申请资源的 消息， 所述用于申请资源的消息中携带每个屏的信息， 以便对应每个屏分别 建立一个用于加入远程呈现会议的会话。 2、 根据权利要求 1所述的方法， 其特征在于， 所述向 MRS发送用于申 请资源的消息之后， 所述方法还包括： 应答消息转发给所述远程呈现会议终端的主屏； 接收所述主屏返回的确认消息， 将所述确认消息转发给所述 MRS, 以实 现主屏的成功入会。 3、 根据权利要求 2所述的方法， 其特征在于， 所述主屏在成功入会后， 所述方法还包括： 根据所述主辅屏绑定关系， 向与所述主屏绑定的辅屏发送用于邀请加入 会议的请求消息； 在接收到所述辅屏返回的成功应答消息后，向 MRS发送用于加入会议的 请求消息， 所述用于加入会议的请求消息中携带辅屏的信息， 以实现辅屏的 成功入会。 4、 根据权利要求 1-3任一项所述的方法， 其特征在于， 所述获取包含至 少两个屏的远程呈现会议终端的主辅屏绑定关系， 包括： 接收主屏发送的用于加入会议的请求消息， 在接收所述用于加入会议的 请求消息后， 获取预设的主辅屏绑定关系； 或者， 接收主屏发送的用于加入会议的请求消息， 所述用于加入会议的请求消 息中携带主辅屏绑定关系。 5、 根据权利要求 4所述的方法， 其特征在于， 所述接收主屏发送的用于 加入会议的请求消息， 包括： 接收主屏主动发送的用于加入会议的请求消息； 或者， 向主屏发送用于邀请加入会议的请求消息， 接收所述主屏在接收到所述 用于邀请加入会议的请求消息后发送的用于加入会议的请求消息。 6、 根据权利要求 1所述的方法， 其特征在于， 所述会话为会话建立协议 SIP会话， 所述方法还包括： 通过与每个屏对应的 SIP会话， 向 MRS发送用于控制的消息， 所述用于 控制的消息中携带待控制的屏的标识， 所述待控制的屏的标识携带在 SIP会 话的 toTag参数中， 以便所述 MRS根据所述用于控制的消息， 对所述待控制 的屏进行控制。 7、 一种远程呈现会议业务处理设备， 其特征在于， 包括： 关系； 申请资源模块， 用于根据所述主辅屏绑定关系， 向媒体资源服务器 MRS 发送用于申请资源的消息， 所述用于申请资源的消息中携带每个屏的信息， 以便对应每个屏分别建立一个用于加入远程呈现会议的会话。 8、 根据权利要求 7所述的设备， 其特征在于， 还包括： 答消息， 将所述成功应答消息转发给所述远程呈现会议终端的主屏； 接收所 述主屏返回的确认消息， 将所述确认消息转发给所述 MRS, 以实现主屏的成 功入会。 9、 根据权利要求 8所述的设备， 其特征在于， 还包括： 辅屏加入模块， 用于根据所述主辅屏绑定关系， 向与所述主屏绑定的辅 屏发送用于邀请加入会议的请求消息； 在接收到所述辅屏返回的成功应答消 息后， 向 MRS发送用于加入会议的请求消息， 所述用于加入会议的请求消息 中携带辅屏的信息， 以实现辅屏的成功入会。 10、 根据权利要求 7-9任一项所述的设备， 其特征在于， 所述获取模块 具体用于接收主屏发送的用于加入会议的请求消息， 在接收所述用于加入会 议的请求消息后， 获取预设的主辅屏绑定关系； 或者， 接收主屏发送的用于 加入会议的请求消息，所述用于加入会议的请求消息中携带主辅屏绑定关系。 11、 根据权利要求 10所述的设备， 其特征在于， 所述获取模块具体用于 接收主屏主动发送的用于加入会议的请求消息； 或者， 向主屏发送用于邀请 加入会议的请求消息， 接收所述主屏在接收到所述用于邀请加入会议的请求 消息后发送的用于加入会议的请求消息。 12、 根据权利要求 7所述的设备， 其特征在于， 还包括： 控制模块， 用于通过与每个屏对应的会话建立协议 SIP会话， 向 MRS发 送用于控制的消息， 所述用于控制的消息中携带待控制的屏的标识， 所述待 控制的屏的标识携带在 SIP会话的 toTag参数中， 以便所述 MRS根据所述用 于控制的消息， 对所述待控制的屏进行控制。 |
本发明涉及网络通信技术， 尤其涉及一种远程呈现会议业务处理方法及 设备。 背景技术
一个远程呈现终端包括多个屏， 每个屏至少包括一到多路视频流、 0 到多路语音流， 甚至还有数据流、 控制流， 因此需要给出终端入会流程， 实现终端与视讯交换平台 （ Multipoint Control Unit , MCU )建立多个媒体 流的功能。 现有技术中， 包括多个屏的远程呈现终端加入会议时只建立 一 个会话， 然后通过实时传输协议 ( Real-time Transfer Protocol, RTP ) I RTP 控制协议 ( RTP Control Protocol, RTCP ) 协商出多个子会话。 在协商多 个子会话的过程中是采用私有协议。
现有技术中， 采用私有协议会限制使用范围。 另外， 只建立一个会话 时每个终端只对应一个终端标识， 这样， 在会议控制过程中， 无法标识具 体为主屏还是辅屏， 难以对一个终端包括的多个屏准确控制。 发明内容
本发明实施例是提供一种远程呈现会议业务处 理方法及设备， 用以解决 现有技术中存在的适用范围受限以及难以对每 个屏进行控制的问题。
本发明实施例提供了一种远程呈现会议业务处 理方法， 包括：
获取包含至少两个屏的远程呈现会议终端的主 辅屏绑定关系； 根据所述主辅屏绑定关系， 向 MRS发送用于申请资源的消息， 所述用 于申请资源的消息中携带每个屏的信息， 以便对应每个屏分别建立一个用 于加入远程呈现会议的会话。
本发明实施例提供一种远程呈现会议业务处理 设备， 包括： 关系；
申请资源模块， 用于根据所述主辅屏绑定关系， 向 MRS发送用于申请 资源的消息， 所述用于申请资源的消息中携带每个屏的信息 ， 以便对应每 个屏分别建立一个用于加入远程呈现会议的会 话。
由上述技术方案可知， 本发明实施例通过为每个屏分别建立一个会话 ， 不需要采用私有协议在建立的一个会话中再协 商出多个子会话， 可以提高适 用范围； 并且， 本发明实施例通过为每个屏分别建立会话， 可以根据会话中 的参数区分不同的屏， 实现对每个屏进行控制， 解决不能区分各个屏的问题。 附图说明
为了更清楚地说明本发明实施例中的技术方案 ， 下面将对实施例描述中 所需要使用的附图作一简单地介绍， 显而易见地， 下面描述中的附图是本发 明的一些实施例， 对于本领域普通技术人员来讲， 在不付出创造性劳动性的 前提下， 还可以根据这些附图获得其他的附图。
图 1为本发明第一实施例的方法流程示意图；
图 2为本发明第二实施例的方法流程示意图；
图 3为本发明第三实施例的方法流程示意图；
图 4为本发明第四实施例的方法流程示意图；
图 5为本发明第五实施例的方法流程示意图；
图 6为本发明第六实施例的方法流程示意图；
图 7为本发明第七实施例的设备结构示意图。 具体实施方式
为使本发明实施例的目的、 技术方案和优点更加清楚， 下面将结合本发 明实施例中的附图， 对本发明实施例中的技术方案进行清楚、 完整地描述， 显然， 所描述的实施例是本发明一部分实施例， 而不是全部的实施例。 基于 本发明中的实施例， 本领域普通技术人员在没有做出创造性劳动前 提下所获 得的所有其他实施例， 都属于本发明保护的范围。
图 1为本发明第一实施例的方法流程示意图， 包括：
步骤 11 : 获取包含至少两个屏的远程呈现会议终端的主 辅屏绑定关系； 步骤 12: 根据所述主辅屏绑定关系， 向媒体资源服务器（Media resource server, MRS )发送用于申请资源的消息， 所述用于申请资源的消息中携带每 个屏的信息， 以便对应每个屏分别建立一个用于加入远程呈 现会议的会话。
本实施例通过为每个屏分别建立一个会话， 不需要采用私有协议在建立 的一个会话中再协商出多个子会话， 可以提高适用范围； 并且， 本实施例通 过为每个屏分别建立会话， 可以根据会话中的参数区分不同的屏， 实现对每 个屏进行控制， 解决不能区分各个屏的问题。
远程呈现终端可以包括多个屏， 在下面的实施例中将以每个远程呈现终 端包含 3个屏为例， 该 3个屏分别为： 主屏（main ) 、 左辅屏（left )和右辅 屏（right )。另夕卜，下面实施例中以 MRS为媒体资源功能控制器（ Media resource function controller, MRFC )和媒体资源功能处理器（ Media Resource Function Processor, MRFP ) (简写为 MRFC/MRFP ) 为例。 其中， MRFC和 MRFP 可以是分离的两个网元， 也可以是一个网元。
图 2为本发明第二实施例的方法流程示意图， 本实施例以远程呈现终端 拨打会议接入号参加会议， 且会议服务器中预设主辅屏绑定关系为例。 参见 图 2, 本实施例包括：
步骤 21： 主屏向会议服务器发送用于加入会议的请求消 息， 该用于加入 会议的请求消息中包含会议接入号和主屏号码 。
例如， 该用于加入会议的请求消息中为会话建立协议 ( Session Initiation Protocol, SIP ) 消息， 具体如：
SIP INVITE ( SDP offer 1 )
Request-URI=会议接入号， From=主屏号码。
步骤 22: 会议服务器根据预设的主辅屏绑定关系， 向 MRFC/MRFP发送 用于申请资源的消息， 该用于申请资源的消息中携带每个屏的信息。
例如， 会议服务器向 MRFC/MRFP发送如下消息：
SIP INVITE ( SDP offer 1 )
Request-URI: sip: msml-video-conf=<会议 ID>@<MRFC IP addr>:<port>
From: <Conference Server>
TelePresence-URI:<主屏号码〉； osition=main
TelePresence-URI:<左屏号码〉； osition=left; index=l
TelePresence-URI:<右屏号码〉； osition=right; index=l
步骤 23: MRFC/MRFP向会议服务器返回应答消息。
例如， 返回 200 INVITE ( SDP answer 1 ) 消息。
步骤 24: 会议服务器向主屏返回应答消息。
例如， 返回 200 INVITE ( SDP answer 1 ) 消息。
步骤 25: 主屏向会议服务器发送确认消息， 例如 ACK消息。
步骤 26: 会议服务器向 MRFC/MRFP发送确认消息， 例如 ACK消息。 至此， 主屏与 MRFC/MRFP 之间完成初步的会话描述协议 （Session Description Protocol, SDP )媒体协商， 实现主屏的成功入会。
另外， 本实施例是以主屏主动申请加入会议为例， 也可以是会议服务器 要求主屏加入会议， 会议服务器要求主屏加入会议的流程可以参见 下面其他 的实施例。
本实施例通过为每个屏分别建立一个会话， 不需要采用私有协议在建立 的一个会话中再协商出多个子会话， 可以提高适用范围； 并且， 本实施例通 过为每个屏分别建立会话， 可以根据会话中的参数区分不同的屏， 实现对每 个屏进行控制， 解决不能区分各个屏的问题。 另外， 本实施例在会议服务器 中预设主辅屏绑定关系， 可以减少主屏与会议服务器交互的消息的开销 。
主屏入会成功后， 会议服务器可以自动邀请远程呈现终端登记的 辅屏号 码。 参见下一实施例。
图 3为本发明第三实施例的方法流程示意图， 本实施例以会议服务器邀 请辅屏加入会议为例。 参见图 3 , 本实施例包括：
步骤 31 : 会议服务器向左辅屏发送用于邀请加入会议的 消息。
例如， 该用于邀请加入会议的消息为 SIP INVITE (无 SDP ) 。
步骤 32: 左辅屏向会议服务器返回临时应答消息。
例如， 该临时应答消息为 100 Trying或者 180 Ringing。
步骤 33: 左辅屏自动或手动应答。
步骤 34: 左辅屏向会议服务器发送应答消息。 步骤 35: 会议服务器向 MRFC/MRFP发送用于加入会议的请求消息， 该 消息中携带左辅屏的信息。
例如， 该用于加入会议的请求消息为：
SIP INVITE ( SDP offer2 )
TelePresense-URI=<左屏号码>; osition=left; index=l。
步骤 36: MRFC/MRFP向会议服务器发送应答消息。
例如， 该消息为 200 OK ( SDP answer2 ) 。
步骤 37: 会议服务器向 MRFC/MRFP发送确认消息， 例如 ACK消息。 步骤 38:会议服务器向左辅屏发送确认消息，例如 ACK( SDP answer 2 )。 至此， 左辅屏与 MRFC/MRFP之间完成了初步的 SDP媒体协商。
另外， 在上述邀请左辅屏的同时也可以再邀请右辅屏 ， 邀请右辅屏的流 程可以参照执行。 并且， 邀请左辅屏和流程和邀请右辅屏的流程无时序 限制 关系， 例如， 可以先邀请左辅屏再邀请右辅屏， 或者， 先邀请右辅屏再邀请 左辅屏， 或者， 同时邀请左辅屏和右辅屏。
本实施例通过在辅屏加入时携带辅屏的信息， 可以使得 MRFP/MRFC根 据主屏入会时携带的主辅屏绑定关系确定该辅 屏对应的主屏及会话， 实现辅 屏的成功入会。
上述实施例以会议服务器中预设主辅屏绑定关 系为例， 该绑定关系也可 以是主屏发送给会议服务器的消息中携带的。 如下一实施例。
图 4为本发明第四实施例的方法流程示意图， 本实施例以远程呈现终端 拨打会议接入号参加会议， 且主屏发送给会议服务器的消息中携带主辅屏 绑 定关系为例。 参见图 4, 本实施例包括：
步骤 41： 主屏向会议服务器发送用于加入会议的请求消 息， 该用于加入 会议的请求消息中包含会议接入号、 主屏号码以及主辅屏的绑定关系。
例如， 该用于加入会议的请求消息为：
SIP INVITE ( SDP offer 1 )
Request-URI=会议接入号， From=主屏号码
TelePresence-URI:<主屏号码〉； osition=main
TelePresence-URI:<左屏号码〉； osition=left; index=l
TelePresence-URI:<右屏号码〉； osition=right; index=l
步骤 42: 会议服务器从该用于加入会议的请求消息中获 取主辅屏绑定关 系， 根据该主辅屏绑定关系， 向 MRFC/MRFP发送用于申请资源的消息， 该 用于申请资源的消息中携带每个屏的信息。
例如， 会议服务器向 MRFC/MRFP发送如下消息：
SIP INVITE ( SDP offer 1 )
Request-URI: sip: msml-video-conf=<会议 ID>@<MRFC IP addr>:<port>
From: <Conference Server> TelePresence-URI:<主屏号码〉； osition=main
TelePresence-URI:<左屏号码〉； osition=left; index=l
TelePresence-URI:<右屏号码〉； osition=right; index=l
步骤 43: MRFC/MRFP向会议服务器返回应答消息。
步骤 44: 会议服务器向主屏返回应答消息。
例如， 返回 200 INVITE ( SDP answer 1 ) 消息。
步骤 45: 主屏向会议服务器发送确认消息， 例如 ACK消息。
步骤 46： 会议服务器向 MRFC/MRFP发送确认消息， 例如 ACK消息。 步骤 43-46的具体内容可以参见步骤 23-26。
至此， 完成了主屏的成功入会， 之后， 辅屏入会的流程可以参见图 3所 示。
本实施例通过为每个屏分别建立一个会话， 不需要采用私有协议在建立 的一个会话中再协商出多个子会话， 可以提高适用范围； 并且， 本实施例通 过为每个屏分别建立会话， 可以根据会话中的参数区分不同的屏， 实现对每 个屏进行控制， 解决不能区分各个屏的问题。 另外， 本实施例不需要在会议 服务器中预设主辅屏绑定关系， 可以降低会议服务器的负担。
远程呈现会议召开过程中， 会议主席可以通过终端会议控制、 Web Portal 会议控制、 或者 IVR Portal会议控制、 Video Portal会议控制， 邀请远程呈现 终端参加会议。
图 5为本发明第五实施例的方法流程示意图， 本实施例以会议服务器邀 请主屏加入会议为例。 参见图 5 , 本实施例包括：
步骤 51 : 会议服务器向主屏发送用于邀请加入会议的消 息。
例如， 该用于邀请加入会议的消息为：
SIP INVITE (无 SDP )
Request-URI=主屏号码
From=<会议接入号 > 步骤 52: 主屏向会议服务器返回临时应答消息。
例如， 该临时应答消息为 100 Trying或者 180 Ringing。
步骤 53: 主屏自动或手动应答。 步骤 54: 主屏向会议服务器发送应答消 息， 该应答消息中携带主辅屏的绑定关系。
例如， 该应答消息为：
200 INVITE ( SDP offer 1 )
TelePresence-URI:<主屏号码〉； osition=main
TelePresence-URI:<左屏号码〉； osition=left; index=l
TelePresence-URI:<右屏号码〉； osition=right; index=l
步骤 55 : 会议服务器从该应答消息中获取主辅屏绑定关 系， 根据该主辅 屏绑定关系， 向 MRFC/MRFP发送用于申请资源的消息， 该用于申请资源的 消息中携带每个屏的信息。
例如， 会议服务器向 MRFC/MRFP发送如下消息：
SIP INVITE ( SDP offer 1 )
Request-URI: sip: msml-video-conf=<会议 ID>@<MRFC IP addr>:<port>
From: <Conference Server>
TelePresence-URI:<主屏号码〉； osition=main
TelePresence-URI:<左屏号码〉； osition=left; index=l
TelePresence-URI:<右屏号码〉； osition=right; index=l
可以理解的是， 步骤 54-55是主屏将主辅屏绑定关系发送给会议服务 ， 也可以类似于第二实施例， 在会议服务器中预设主辅屏绑定关系， 这样主屏 在向会议服务器发送的消息中不需要再携带该 主辅屏绑定关系。
步骤 56: MRFC/MRFP向会议服务器发送应答消息。
例如， 该消息为 200 OK ( SDP answer 1 ) 。
步骤 57： 会议服务器向 MRFC/MRFP发送确认消息， 例如 ACK消息。 步骤 58: 会议服务器向主屏发送确认消息， 例如 ACK ( SDP answer l ) 。 至此， 主屏与 MRFC/MRFP之间完成了初步的 SDP媒体协商。
后续邀请左辅屏、 右辅屏的流程可以参见图 3所示。
本实施例通过为每个屏分别建立一个会话， 不需要采用私有协议在建立 的一个会话中再协商出多个子会话， 可以提高适用范围； 并且， 本实施例通 过为每个屏分别建立会话， 可以根据会话中的参数区分不同的屏， 实现对每 个屏进行控制， 解决不能区分各个屏的问题。 另外， 本实施例通过会议服务 器主动要求主屏参与会议， 可以提高针对性。
上述实施例以 3屏为例， 当然， 本发明实施例并不限于 3屏， 远程呈现 终端屏幕数大于等于 2都可以。 例如， 远程呈现终端屏幕数为 2N+1 ( N > 1 ) 时， SIP头域 TelePresence-URI及其参数是对标准 SIP头域的扩展定义， 具体 为：
TelePresence-URI:<-^码〉； osition=<main/left/right>； index=<0~N> 其中， <号码 >可以是主屏号码、 左辅屏号码、 右辅屏号码。 当有一个或 多个左辅屏时， 参数 position填写 left, 参数 index填写表明是哪个左辅屏的 参数， 例如包括 3个左辅屏， 其中与主屏相邻的左辅屏对应的 Index为 1 , 中 间的左辅屏对应的 Index为 2, 另一个最左侧的左辅屏对应的 index为 3。 类 似地， 当有一个或多个右辅屏时， 参数 osition填写 right, 参数 index填写表 明是哪个右辅屏的参数， 例如包括 3个右辅屏， 其中与主屏相邻的右辅屏对 应的 Index为 1 , 中间的右辅屏对应的 Index为 2, 另一个最右侧的右辅屏对 应的 index为 3。 当然， 本发明也不限于奇数的屏， 对于偶数的屏， 可以指定 其中一个为主屏， 对于其他的辅屏可以用不同的 "index" 进行区分。
对于包含多个屏的远程呈现终端加入会议的其 他流程可以参照对 3屏的 流程执行。
另外， 在上述实施例中， 当远程呈现终端的每个屏均成功加入会议后， MRS可以根据与会议服务器之间的 SIP会话， 对每个屏进行控制。
图 6为本发明第六实施例的方法流程示意图， 本实施例以控制远程呈现 终端的单屏为例。 参见图 6, 本实施例包括：
步骤 61 : 会议服务器与 MRFC/MRFP建立 SIP会话。
具体建立流程可以参见上述实施例， 在上述实施例中， 会议服务器与 MRFC/MRFP之间交互的 SIP信令， 例如 SIP INVITE, 200 OK等可以构成 SIP会话 ( SIP dialog ) 。 因此， 通过上述流程可以对应每个屏建立一个 SIP 会话。
步骤 62: 当需要对某个屏进行控制时， 会议服务器向 MRFC/MRFP发送 用于控制的消息， 该用于控制的消息中携带待控制的屏的标识， 所述待控制 的屏的标识携带在 SIP会话的 toTag参数中。
例如， 远程呈现终端 TP— 1含有 3个屏， 对应的标识分别为： TP— 1— M、
TP— 1— L、 TP— 1— R, 远程呈现终端 TP— 2含有 3 个屏， 对应的标识分别为： TP— 2— M、 TP— 2— L、 TP— 2— R, 需要控制 TP— 1— M选看 TP— 2— L 。 则可以是 MRFC/MRFP向会议服务器发送 SIP INFO消息， 该 SIP INFO消息的 toTag 参数中携带 TP— 1— M和 TP— 2— L。
具体地 , SIP INFO携带的 MSML body样例如下：
<modifyconference name="myconf >
<videolayout type="text/msml-basic-layout" id="vidmixl" optmode ="assign">
<assignscreen sourcescreen="conn:TP_2_L_toTag" destinationscreen= "conn:TP_l_M_toTag" />
</videolayout>
</modifycconference>
步骤 63: MRFC/MRFP根据该用于控制的消息，对待控制的屏 进行控制。 例如， 将 TP— 2— L屏对应的输入媒体流输出给 TP— 1— M屏进行播放。 本实施例通过对应每个屏分别建立一个 SIP会话， 可以采用 SIP会话中 的参数携带屏的标识， 实现对远程呈现终端每个屏的控制。 图 7为本发明第七实施例的设备结构示意图， 包括获取模块 71和申请资 辅屏绑定关系； 申请资源模块 72用于根据所述主辅屏绑定关系， 向 MRS发 送用于申请资源的消息， 所述用于申请资源的消息中携带每个屏的信息 ， 以 便对应每个屏分别建立一个用于加入远程呈现 会议的会话。
本实施例还可以包括： 主屏加入模块 73 , 用于接收所述 MRS在为每个 屏分配资源后返回的成功应答消息， 将所述成功应答消息转发给所述远程呈 现会议终端的主屏； 接收所述主屏返回的确认消息， 将所述确认消息转发给 所述 MRS, 以实现主屏的成功入会。
本实施例还可以包括辅屏加入模块 74 , 用于根据所述主辅屏绑定关系， 向与所述主屏绑定的辅屏发送用于邀请加入会 议的请求消息； 在接收到所述 辅屏返回的成功应答消息后， 向 MRS发送用于加入会议的请求消息， 所述用 于加入会议的请求消息中携带辅屏的信息， 以实现辅屏的成功入会。
所述获取模块 71 可以具体用于接收主屏发送的用于加入会议的 请求消 息， 在接收所述用于加入会议的请求消息后， 获取预设的主辅屏绑定关系； 或者， 接收主屏发送的用于加入会议的请求消息， 所述用于加入会议的请求 消息中携带主辅屏绑定关系。
具体地，所述获取模块 71具体用于接收主屏主动发送的用于加入会议 请求消息； 或者， 向主屏发送用于邀请加入会议的请求消息， 接收所述主屏 在接收到所述用于邀请加入会议的请求消息后 发送的用于加入会议的请求消 自
本实施例还可以包括：控制模块 75,用于通过与每个屏对应的 SIP会话， 向 MRS 发送用于控制的消息， 所述用于控制的消息中携带待控制的屏的标 识， 所述待控制的屏的标识携带在 SIP会话的 toTag参数中， 以便所述 MRS 根据所述用于控制的消息， 对所述待控制的屏进行控制。
本实施例通过为每个屏分别建立一个会话， 不需要采用私有协议在建立 的一个会话中再协商出多个子会话， 可以提高适用范围； 并且， 本发明实施 例通过为每个屏分别建立会话， 可以根据会话中的参数区分不同的屏， 实现 对每个屏进行控制， 解决不能区分各个屏的问题。
可以理解的是， 上述方法及设备中的相关特征可以相互参考。 另外， 上 述实施例中的 "第一" 、 "第二" 等是用于区分各实施例， 而并不代表各实 施例的优劣。
本领域普通技术人员可以理解： 实现上述方法实施例的全部或部分步骤 可以通过程序指令相关的硬件来完成， 前述的程序可以存储于计算机可读取 存储介质中， 该程序在执行时， 执行包括上述方法实施例的步骤； 而前述的 存储介质包括： ROM, RAM,磁碟或者光盘等各种可以存储程序代码的 质。
最后应说明的是： 以上实施例仅用以说明本发明的技术方案， 而非对其 限制； 尽管参照前述实施例对本发明进行了详细的说 明， 本领域的普通技术 人员应当理解： 其依然可以对前述各实施例所记载的技术方案 进行修改， 或 者对其中部分技术特征进行等同替换； 而这些修改或者替换， 并不使相应技 术方案的本质脱离本发明各实施例技术方案的 精神和范围。