多媒体会话的媒体流增加方法和用户设备及应用服务器

摘要

本发明公开了多媒体会话的媒体流增加方法和用户设备及应用服务器。第一用户设备与第二用户设备在应用服务器的控制下建立多媒体会话；第一用户设备向应用服务器发送针对该多媒体会话媒体流增加请求；所述媒体流增加请求包括：第三用户设备的身份标识和请求增加的媒体流的媒体类型；所述第三用户设备与所述第二用户设备在所述应用服务器的控制下建立所述媒体类型的媒体流。实现了媒体流增加在第三方用户设备上，用户可以通过多个用户设备与对端进行多媒体会话，避免了现有技术中，媒体流只能在增加在会话双方，给用户带来的不便。满足用户对多样的多媒体业务的需求。

说明书

技术领域

本发明涉及通信技术领域，具体涉及多媒体会话的媒体流增加方法和用户设备及应用服务器。

背景技术

随着无线通信的发展，用户对服务质量和种类的需求越来越明显，出现了许多增值业务，为用户提供方便快捷的服务，满足用户的多样化需求。

目前，多媒体会话中，允许进行会话的双方增加会话使用的媒体流，如：在进行语音通话时，增加视频媒体流，实现可视电话。

现有的一种多媒体会话的媒体流增加方法，包括以下步骤：

第一用户设备(UE1)与第二用户设备(UE2)进行多媒体会话；

第一用户设备向所述第二用户设备请求增加新的媒体流；

所述第二用户设备接受所述增加请求；

所述第一用户设备与所述第二用户设备之间传输所述增加的媒体流。

可以理解的是，所述第一用户设备与所述第二用户设备交互消息需要经过通信网络中的呼叫控制设备。

在对现有技术的研究和实践过程中，发明人发现现有技术存在以下问题：

上述的多媒体会话的媒体流增加方法虽然可以实现多媒体会话过程中增加媒体流，但是上述的媒体流只能增加在会话的双方之间，无法增加第三方终端设备收发增加的媒体流，而实际情况，很可能用户同时持有多个用户设备，而各个用户设备的性能各有特长，例如：一个用户同时持有2个终端设备，一个终端设备通话质量较好，却不支持视频或支持视频但是显示效果不好，而另一个终端设备却拥有强大的视频功能，但却音质不好。而采用上述现有的方法进行媒体流的增加，则无法发挥这两个终端设备的特长，具有一定的局限性，给显然客户使用多媒体业务带来不便，客户话不足，不能满足用户对多样的多媒体业务的需求。

发明内容

本发明实施例解决的技术问题是提供多媒体会话的媒体流增加方法和用户设备及应用服务器，可以实现媒体流增加在第三方用户设备上，用户通过多个用户设备与对端进行多媒体会话。

本发明实施例提供一种多媒体会话的媒体流增加方法，包括：

第一用户设备与第二用户设备在应用服务器的控制下建立多媒体会话；

第一用户设备向应用服务器发送针对该多媒体会话媒体流增加请求；所述媒体流增加请求包括：第三用户设备的身份标识和请求增加的媒体流的媒体类型；

所述第三用户设备与所述第二用户设备在所述应用服务器的控制下建立所述媒体类型的媒体流。

本发明实施例提供的一种多媒体会话的媒体流增加方法，包括：

第一用户设备与第二用户设备在应用服务器的控制下建立多媒体会话；

第三用户设备向应用服务器发送和所述第二用户设备之间增加媒体流的媒体流增加请求；所述媒体流增加请求中包括：增加的媒体流的媒体类型；

所述第三用户设备和所述第二用户设备在所述应用服务器的控制下建立所述媒体类型的媒体流。

本发明实施例提供的一种用户设备，包括：

会话建立单元，用于与第二用户设备在应用服务器的控制下建立多媒体会话；

媒体增加请求发送单元，用于向所述应用服务器发送针对该多媒体会话的媒体增加请求；所述媒体增加请求包括：第三用户设备的身份标识和请求增加的媒体流的媒体类型。

本发明实施例提供的一种应用服务器，包括：

会话控制单元，用于控制第一用户设备和第二用户设备建立多媒体会话；

接收单元，用于接收所述第一用户设备的针对所述多媒体会话的媒体流增加请求；所述媒体流增加请求包括：第三用户设备的身份标识和请求增加的媒体流的媒体类型；

媒体流增加控制单元，用于控制所述第三用户设备和所述第二用户设备建立所述媒体类型的媒体流。

本发明实施例提供的一种用户设备，包括：

媒体增加请求发送单元，向应用服务器发送和所述第二用户设备之间增加媒体流的请求；所述请求中包括：增加的媒体流的媒体类型；

媒体流建立单元，用于与所述第二用户设备在所述应用服务器的控制下建立所述增加的媒体类型的媒体流。

本发明实施例提供的一种应用服务器，包括：

会话控制单元，用于控制第一用户设备和第二用户设备建立多媒体会话；

接收单元，用于接收第三用户设备发送的和所述第二用户设备之间增加媒体流的请求；所述请求中包括：增加的媒体流的媒体类型；

媒体流增加单元，用于控制所述第三用户设备和所述第二用户设备建立所述媒体类型的媒体流。

采用上述技术方案，本发明实施例有益的技术效果在于：

本发明实施例中，第一用户设备与第二用户设备在应用服务器的控制下建立多媒体会话；第一用户设备向应用服务器发送针对该多媒体会话媒体流增加请求；所述媒体流增加请求包括：第三用户设备的身份标识和请求增加的媒体流的媒体类型；所述第三用户设备与所述第二用户设备在所述应用服务器的控制下建立所述媒体类型的媒体流。实现了媒体流增加在第三方用户设备上，用户可以通过多个用户设备与对端进行多媒体会话，避免了现有技术中，媒体流只能在增加在会话双方，给用户带来的不便。满足用户对多样的多媒体业务的需求。

附图说明

图1为本发明实施例一多媒体会话的媒体流增加方法的流程图；

图2为本发明实施例一第一用户设备与第二用户设备在应用服务器的控制下建立多媒体会话的流程图；

图3为本发明实施例二多媒体会话的媒体流增加方法的流程图；

图4为采用SIP协议实现本发明实施例一方法应用例的信令流程图；

图5为采用SIP协议实现本发明实施例二方法应用例的信令流程图。

具体实施方式

本发明实施例提供了一种，多媒体会话的媒体流增加方法和用户设备及应用服务器，用于通信技术领域，下面对本发明的提供的媒体会话的媒体流增加方法和用户设备及应用服务器进行详细描述。

实施例一，一种多媒体会话的媒体流增加方法，流程图如图1所示，包括：

步骤a1，第一用户设备与第二用户设备在应用服务器的控制下建立多媒体会话；

本实施例中，所述第一用户设备与第二用户设备在应用服务器的控制下建立多媒体会话的过程如下，具体步骤参见图2，本例以所述第二用户设备为呼叫的发起方为例进行说明。

步骤b1，所述第二用户设备向呼叫会话控制设备(CSCF)发送请求所述第一用户设备加入会话的会话邀请(Invite)消息。

步骤b2，所述CSCF进行被叫初始过滤标准(iFC)检查，得知所述第一用户支持媒体流增加业务，则将将所述会话邀请消息发送给应用服务器；

步骤b3，所述应用服务器向所述第一用户设备发送会话邀请消息；所述会话邀请经过所述CSCF转发至所述第一用户设备。

步骤b4，所述第一用户设备应答确认消息(200 OK)到达所述第二用户设备，第一用户设备和所述第二用户设备建立多媒体会话。

可以理解的是，若所述第一用户设备为主叫方，与上述流程基本相同，区别在于，所述第一用户设备发送邀请第二用户设备进行会话的Invite消息到达CSCF后，CSCF进行主叫iFC检查，得知所述第一用户设备支持媒体流增加业务，则将所述会话邀请消息发送至应用服务器，应用服务器向所述第二用户设备发送会话邀请消息；所述会话邀请经过所述CSCF转发至所述第二用户设备。所述第二用户设备应答确认消息(200 OK)到达所述第一用户设备，第一用户设备和所述第二用户设备建立多媒体会话。

所述第一用户设备与第二用户设备在应用服务器的控制下建立多媒体会话，还可以采用现有其他的常规实现方式，具体的方式不构成对本发明的限制。

a2，第一用户设备向应用服务器发送针对该多媒体会话媒体流增加请求；所述媒体流增加请求包括：第三用户设备的身份标识和请求增加的媒体流的媒体类型；

a3，所述第三用户设备与所述第二用户设备在所述应用服务器的控制下建立所述媒体类型的媒体流。

本发明实施例中，所述第三用户设备与所述第二用户设备在所述应用服务器的控制下建立所述媒体类型的媒体流的过程可以为：

(1)所述应用服务器向所述第三用户设备发送会话邀请；

所述会话邀请中，主叫方的地址为所述应用服务器的地址或所述第二用户设备的身份标识。

本发明实施例中，所述用户设备的身份标识可以是该用户设备的地址、用户名、昵称等，可以理解的是，只要是可以在通信系统中标识该用户设备，并且可以通过该标识找到该用户设备的标识，都可以理解为该用户设备的身份标识。

若所述第一用户设备与所述第二用户设备建立的多媒体会话中主叫方为所述第一用户设备，则所述主叫方的地址添入所述应用服务器的身份标识，；若所述多媒体会话的主叫方为第二用户设备，则需要将所述主叫方的地址添所述第二用户设备的身份标识。

(2)所述第三用户设备和所述第二用户设备在所述应用服务器的控制下针对所述媒体类型进行媒体信息协商；

所述媒体协商是针对所述媒体类型，协商双方支持的编码格式，接收所述媒体流和发送媒体流的端口地址等信息。协商的过程可能有多次消息的交互，进行媒体协商为现有的常规技术手段，具体的协商过程不再赘述。

(3)协商成功后，所述第三用户设备与所述第二用户设备传输所述媒体类型的媒体流。

可以理解的是，所述第三用户设备与所述第二用户设备在所述应用服务器的控制下建立所述媒体类型的媒体流的过程还可以采用其他的常规流程实现，具体的建立方式不构成对本发明的限制。并且，在进行媒体协商时，对于应用服务器与所述第二用户设备之间的呼叫关系可以重用，无需重新建立新的呼叫关系。

可以理解的是，所述步骤a2第一用户设备向应用服务器发送媒体流增加请求可以是用户操作所述第一用户设备触发，也可能是所述第一用户设备收到所述第二用户设备发送的媒体流增加请求进行触发，所述媒体流增加请求包括：增加的媒体流的媒体类型。

本发明实施例一，第一用户设备与第二用户设备在应用服务器的控制下建立多媒体会话；第一用户设备向应用服务器发送针对该多媒体会话媒体流增加请求；所述媒体流增加请求包括：第三用户设备的身份标识和请求增加的媒体流的媒体类型；所述第三用户设备与所述第二用户设备在所述应用服务器的控制下建立所述媒体类型的媒体流。实现了媒体流增加在第三方用户设备上，用户可以通过多个用户设备与对端进行多媒体会话，避免了现有技术中，媒体流只能在增加在会话双方，给用户带来的不便。满足用户对多样的多媒体业务的需求。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括如下步骤：

第一用户设备与第二用户设备在应用服务器的控制下建立多媒体会话；

第一用户设备向应用服务器发送针对该多媒体会话媒体流增加请求；所述媒体流增加请求包括：第三用户设备的身份标识和请求增加的媒体流的媒体类型；

所述第三用户设备与所述第二用户设备在所述应用服务器的控制下建立所述媒体类型的媒体流。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括如下步骤：

第一用户设备与第二用户设备在应用服务器的控制下建立多媒体会话；

第一用户设备向应用服务器发送针对该多媒体会话媒体流增加请求；所述媒体流增加请求包括：第三用户设备的身份标识和请求增加的媒体流的媒体类型；

所述第三用户设备与所述第二用户设备在所述应用服务器的控制下建立所述媒体类型的媒体流。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。

实施例二，一种多媒体会话的媒体流增加方法，流程图如图3所示，包括：

步骤c1，第一用户设备与第二用户设备在应用服务器的控制下建立多媒体会话。

具体的建立多媒体会话的过程参见实施例一步骤a1。

步骤c2，第三用户设备向应用服务器发送和所述第二用户设备之间增加媒体流的请求；所述请求中包括：增加的媒体流的媒体类型；

本发明实施例中，所述媒体流增加请求还包含所述第一用户设备的身份标识。用于向应用服务器指明是要增加哪个用户设备会话中的媒体流。

可以理解的是，所述应用服务器还可以通过所述第三用户设备的身份标识来识别要增加哪个用户设备的媒体流。

所述第三用户的身份标识为所述用户设备的全局可路由地址，若所述第一用户设备和所述第二用户设备为采用一个多媒体公共身份(IM Public useridentity，IMPU)注册的多个用户终端，则根据所述第三用户设备的IMPU查找得到与其关联的第一用户设备。

现有的IMS中支持多个用户设备采用一个IP多媒体公有用户身份(IMPublic user identity，IMPU)进行注册，即一个用户有多个终端。而IMS应用需要能够区分消息来源并把消息发送到注册为相同IMPU的某个特定的用户设备。而通过全局可路由地址(Globally Routable User Agent(UA)URIs，GRUU)可以解决这个问题。例如：

用户设备在进行IP多媒体子系统(IMS)注册时，用户设备发出GRUU分配请求，所述分配请求包括：sip:bob@3gpp.org；gruu；opaque＝＂urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6＂，其中bob@3gpp.org；gruu是用户的IMPU，而opaque在用户的多个用户设备中唯一标识该用户设备，S-CSCF将返回bob@3gpp.org；gr＝kjh29x97us97d，其中gr参数是CSCF选择的，用来标识该用户设备。

由上述可知，在同一个用户两个终端的情况下，为该用户注册的用户设备具有相同的IMPU，而在进行IMS注册的过程中，会分配GRUU标识对各个用户设备进行区别。而本发明实施例中，所述第三用户设备和所述第二用户设备是属于前述的同一用户多终端的情况，有相同的IMPU，因此所述应用服务器在收到所述媒体流增加请求时，则可以根据所述第三用户设备的IMPU查找到所述第一用户设备。

可以理解的是，所述媒体流增加请求还可以包含所述多媒体会话的标识，用户标识进行媒体流增加的会话。因为在IMS多媒体子系统中，用户设备可以同时存在与多个会话中，通过上述的方式识别要增加用户设备哪个会话中的媒体流。

步骤c3，所述第三用户设备与所述第二用户设备在所述应用服务器的控制下建立所述媒体类型的媒体流。

建立所述媒体类型的媒体流的步骤参见实施例一步骤a3。

可以理解的是，所述步骤c3之前可以包括：

所述应用服务器向所述第一用户设备请示是否允许所述第三用户设备增加所述媒体类型的媒体流；

若允许，则所述第一用户设备向所述应用服务器确认，并继续步骤c3。

本发明实施例二与实施例一的区别在于，由第三用户设备发起媒体流的增加，适应更多的场景，为进行媒体流的转移提供更丰富的可能的方式，方便用户使用。

下面提供采用会话初始协议(SIP)协议实现本发明实施例一方法的应用例，本应用例中，假设用户Bob拥有两个终端，第一用户设备和第三用户设备，第一用户设备和所述第三用户设备都进行了IMS注册，并注册了同一个公共用户身份(Bob@sipo.com)，GRUU分别为Bob@sipo.com；gr＝erwiopue1和Bob@sipo.com；gr＝dfweyuiue3。采用了gr的值为：erwiopue1和dfweyuiue3对第一用户设备的和第二用户设备的身份进行区分。

信令流程如图4所示，包括：

d1，第二用户设备发送邀请第一用户设备加入多媒体会话的Invite消息到服务CSCF(S-CSCF)，所述Invite消息中包含Bob@sipo.com；gr＝erwiopue1，Call-ID:3456df0u，其中Call-ID是呼叫标识，用于标识当前呼叫。还包括请求建立的媒体类型，本应用例中是：音频、视频和实时文本消息。

d2，S-CSCF对所述第一用户设备进行被叫iFC检查，得知所述第一用户设备支持媒体流转移业务，则将所述Invite消息发送至应用服务器，发送的Invite消息中包括：所述S-CSCF增加的自己的地址一个对话标识符参数dia-id，增加所述S-CSCF的地址可以便于所述应用服务器操作完成后将请求返回所述S-CSCF；增加所述dia-id，用于所述S-CSCF后续收到该请求后识别与刚才的请求的关系。

d3，应用服务器生成一个新的Invite消息发送到所述第一用户设备，所述Invite消息包括所述S-CSCF的地址和所述dia-id，该Invite消息首先被发送到S-CSCF，S-CSCF通过该消息中的dia-id识别该呼叫请求，继续进行iFC检查，若完毕，则发送呼叫请求到所述第一用户设备。

d4，第一用户设备应答确认消息(200 OK)并到达第二用户设备，第一用户设备和第二用户设备建立呼叫，进行包含媒体流1、媒体流2和媒体流3的多媒体通话。

d5，在用户Bob操作下，第一用户设备向应用服务器发送媒体流增加请求，所述媒体流增加请求通过SIP的通知消息(Notify)消息实现，所述Subscribe消息中包括希望增加的类型m＝4即：媒体流4，和媒体增加目标第三用户设备的身份标识即GRUU:Bob@sipo.com；gr＝dfweyuiue3对应的会话。

d6，应用服务器发送媒体增加确认到第一用户设备，采用SIP协议的Notify消息应答所述第一用户设备。

可以理解的是，因为所述应用服务器和所述第一用户设备之间已经存在一个呼叫关系，所以发送的媒体转移请求可以采用re-Invite或Update消息；返回相应的应答可以采用200OK进行应答。

d7，应用服务器生成另一新的Invite消息(Call-ID:2876oj68，Route:scscf1；dia-id＝8736yuhs)到所述第三用户设备，所述Invite消息首先被发送到S-CSCF，S-CSCF通过dia-id识别该呼叫请求，则发送呼叫请求到第三用户设备。应用服务器也通过呼叫请求发送第三用户设备关于媒体流4的媒体信息如：IP地址，端口，编码格式等。

在步骤d1～d4的多媒体会话建立过程中，若会话的发起方是第一用户设备，则应用服务器将Invite消息中主叫地址设置为所述应用服务器的地址并将呼叫请求发送到第三用户设备。这里，应用服务器将主叫地址设置为第二方用户设备的身份标识是不被现有的网络支持的。另外，若应用服务器将主叫地址设置为第一方用户设备的身份标识，则相当于代替第一方用户设备向第三方用户设备发起新的呼叫，会导致应用服务器侧逻辑处理混乱，增加网络侧处理的复杂度。

d8，第三用户设备以200 OK应答。

d9，应用服务器收到200 OK后，生成re-Invite或Update消息发送到第三用户设备的媒体信息到第二用户设备，使得第三用户设备和第二用户设备建立媒体流2。

re-Invite或Update消息用来进行会话的重新协商，如增加/删除媒体/变更媒体流的IP地址等，可以理解的是，媒体协商的过程可能有多次，具体的协商次数不构成对本发明的限制。

d10，第二用户设备返回确认消息(200OK)接受会话协商请求，所述确认消息包括所述第二用户设备的媒体信息。

至此，用户Bob通过第一用户设备和第三用户设备与第二用户设备的用户Tom进行多媒体通话。

d11，所述应用服务器通过ACK消息发送所述第二用户所设备的媒体信息到第三用户设备。

至此，用户Bob通过第一用户设备和第三用户设备与第二用户设备的用户Tom进行多媒体通话。

图4中，虚线部分代表进行媒体流转移前的媒体流传输状况，和媒体流转移后的媒体流传输状况。

下面提供采用会话初始协议(SIP)协议实现本发明实施例二方法的应用例，本应用例中，假设用户Bob拥有两个终端，第一用户设备和第三用户设备，第一用户设备和所述第三用户设备都进行了IMS注册，并注册了同一个公共用户身份(Bob@sipo.com)，GRUU分别为Bob@sipo.com；gr＝erwiopue和Bob@sipo.com；gr＝dfweyuiue3。采用了gr的值为：erwiopue和dfweyuiue3对第一用户设备的和第二用户设备的身份进行区分。

信令流程如图5所示，包括：

e1，第二用户设备发送邀请第一用户设备加入多媒体会话的Invite消息到服务CSCF(S-CSCF)，所述Invite消息中包含Bob@sipo.com；gr＝erwiopue，Call-ID:3456df0u，其中Call-ID是呼叫标识，用于标识当前呼叫。还包括请求建立的媒体类型，本应用例中是：音频、视频和实时文本消息。

e2，S-CSCF对所述第一用户设备进行被叫iFC检查，得知所述第一用户设备支持媒体流转移业务，则将所述Invite消息发送至应用服务器，发送的Invite消息中包括：所述S-CSCF增加的自己的地址一个对话标识符参数dia-id，增加所述S-CSCF的地址可以便于所述应用服务器操作完成后将请求返回所述S-CSCF；增加所述dia-id，用于所述S-CSCF后续收到该请求后识别与刚才的请求的关系。

e3，应用服务器生成一个新的Invite消息发送到所述第一用户设备，所述Invite消息包括所述S-CSCF的地址和所述dia-id，该Invite消息首先被发送到S-CSCF，S-CSCF通过该消息中的dia-id识别该呼叫请求，继续进行iFC检查，若完毕，则发送呼叫请求到所述第一用户设备。

e4，第一用户设备应答确认消息(200 OK)并到达第二用户设备，第一用户设备和第二用户设备建立呼叫，进行包含媒体流1、媒体流2和媒体流3的多媒体通话。

e5，用户Bob操作第三用户设备向应用服务器发起媒体流2的切换请求，切换请求可以由VDI/VDN标识。应用服务器通过第三用户设备的身份标识Bob@sipo.com；gr＝dfweyuiue3找到待转移媒体的会话。

e6，应用服务器通过INFO消息通知第一用户设备，第三用户设备请求增加媒体流4。

e7，若所述第一用户设备接收所述媒体流的切换，则以INFO消息应答接受所述请求。

e8，应用服务器生成re-Invite或Update消息发送到第三用户设备的媒体信息到第二用户设备。

e9，所述第二用户设备接收所述第三用户设备的媒体信息，返回200OK消息确认。

e10.应用服务器发送200 OK到第三用户设备，将第二用户设备的媒体信息发送给第三用户设备。这样第三用户设备和第二用户设备建立媒体流4的连接。

re-Invite或Update消息用来进行会话的重新协商，如增加/删除媒体/变更媒体流的IP地址等，可以理解的是，媒体协商的过程可能有多次，具体的协商次数不构成对本发明的限制。

至此，用户Bob通过UE-1和第三用户设备与UE-2的用户Tom进行多媒体通话。

本发明实施例三，一种用户设备，包括：会话建立单元和媒体增加请求发送单元；

会话建立单元，用于与第二用户设备在应用服务器的控制下建立多媒体会话；

媒体增加请求发送单元，用于向所述应用服务器发送针对该多媒体会话的媒体增加请求；所述媒体增加请求包括：第三用户设备的身份标识和请求增加的媒体流的媒体类型。

本发明实施例四，一种应用服务器，包括：会话控制单元、接收单元和媒体流增加控制单元；

会话控制单元，用于控制第一用户设备和第二用户设备建立多媒体会话；

接收单元，用于接收所述第一用户设备的针对所述多媒体会话的媒体流增加请求；所述媒体流增加请求包括：第三用户设备的身份标识和请求增加的媒体流的媒体类型；

媒体流增加控制单元，用于控制所述第三用户设备和所述第二用户设备建立所述媒体类型的媒体流。

本发明实施例五，一种用户设备，包括：媒体增加请求发送单元和媒体流建立单元；

媒体增加请求发送单元，向应用服务器发送和所述第二用户设备之间增加媒体流的请求；所述请求中包括：增加的媒体流的媒体类型；

媒体流建立单元，用于与所述第二用户设备在所述应用服务器的控制下建立所述增加的媒体类型的媒体流。

实施例六，一种应用服务器，包括：会话控制单元、接收单元和媒体流增加单元；

会话控制单元，用于控制第一用户设备和第二用户设备建立多媒体会话；

接收单元，用于接收第三用户设备发送的和所述第二用户设备之间增加媒体流的请求；所述请求中包括：增加的媒体流的媒体类型；

媒体流增加单元，用于控制所述第三用户设备和所述第二用户设备建立所述媒体类型的媒体流。

以上对本发明所提供的一种多媒体会话的媒体流增加方法和用户设备及应用服务器进行了详细介绍，其中：

本发明一个的实施例，第一用户设备与第二用户设备在应用服务器的控制下建立多媒体会话；第一用户设备向应用服务器发送针对该多媒体会话媒体流增加请求；所述媒体流增加请求包括：第三用户设备的身份标识和请求增加的媒体流的媒体类型；所述第三用户设备与所述第二用户设备在所述应用服务器的控制下建立所述媒体类型的媒体流。实现了媒体流增加在第三方用户设备上，用户可以通过多个用户设备与对端进行多媒体会话，避免了现有技术中，媒体流只能在增加在会话双方，给用户带来的不便。满足用户对多样的多媒体业务的需求。

本发明另一实施例，与上述实施例的区别在于，由第三用户设备发起媒体流的增加，适应更多的场景，为进行媒体流的转移提供更丰富的可能的方式，方便用户使用。

对于本领域的一般技术人员，依据本发明实施例的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。