CN101098513A - 一种建立群组会话的方法 - Google Patents
一种建立群组会话的方法 Download PDFInfo
- Publication number
- CN101098513A CN101098513A CNA2006100613951A CN200610061395A CN101098513A CN 101098513 A CN101098513 A CN 101098513A CN A2006100613951 A CNA2006100613951 A CN A2006100613951A CN 200610061395 A CN200610061395 A CN 200610061395A CN 101098513 A CN101098513 A CN 101098513A
- Authority
- CN
- China
- Prior art keywords
- session
- client
- medium type
- server
- setting
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/40—Support for services or applications
- H04L65/4061—Push-to services, e.g. push-to-talk or push-to-video
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/1016—IP multimedia subsystem [IMS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1069—Session establishment or de-establishment
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1083—In-session procedures
- H04L65/1093—In-session procedures by adding participants; by removing participants
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1104—Session initiation protocol [SIP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
- H04W4/08—User group management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
- H04W4/10—Push-to-Talk [PTT] or Push-On-Call services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/40—Support for services or applications
- H04L65/403—Arrangements for multi-party communication, e.g. for conferences
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Telephonic Communication Services (AREA)
Abstract
本发明提供了一种建立群组会话的方法,该方法包括服务器在和客户端建立会话前,判断待建立会话的媒体类型是否采用预建立会话的媒体类型,如是则用预建立会话的媒体类型建立会话,否则通过重协商建立会话或判定无法与所述客户端建立会话。利用本发明,解决了建立会话的媒体类型和客户端预建立会话的媒体类型集之间没有相同的媒体类型时,服务器通过重协商来建立群组会话保证群组会话的效果,或者通过不连接,节约通信资源。
Description
技术领域:
本发明涉及通讯领域,尤其涉及一种建立群组会话的方法。
背景技术:
PTT(Push to Talk)一种通过按功能键进行通信的半双工语音业务,目前包括很多实现方式,比如Motorola的iDEN以及Nokia的Tetra。PoC(PTT overCellular)是OMA(Open Mobile Alliance开放移动联盟组织)定义的在分组网络上实现的PTT业务,采用VoIP(分组语音)以及半双工的方式,低成本、高效率的满足PoC客户端(以下简称客户端)的实时通信需求。通过这种业务,客户端可以向单个客户端或群组发起PoC会话,实现一对一或一对多的会话方式。
在PoC会话中,服务器根据逻辑功能划分为控制功能和参与功能服务器。控制功能服务器提供对PoC会话集中控制,包括RTP媒体分发、发言权控制、对参与会话的成员执行会话策略以及处理参与成员信息;参与功能服务器提供会话控制,包括对呼入会话的策略控制、对控制功能服务器与客户端之间的发言权信令中继等,也可以根据需要提供媒体流的中继。
OMA中的PoC业务通过SIP信令建立会话的交互过程。建立会话的主要作用是协商通信双方的多媒体信息流的编码格式及实时传输协议(Real-timeTransport Protocol,以下简称RTP)传输地址等。因此,无论在请求消息还是响应消息中都应该包含描述有关将要交换的多媒体信息流的一些信息,如RTP净荷类型、RTP传输地址等,这些信息不是在SIP消息头给出的,而是通过消息所携带的消息体提供的。在PoC中,用会话描述协议(SDP)描述这些信息。SDP的提供(offer)/应答(answer)模型被两个实体用来对会话描述达成协议,例如会话中包含哪些媒体流、编码方案等。提供者在提供中表明所希望的会话描述,应答者则在应答中指明所希望的会话描述。一旦经过一次交换,双方在确立SIP对话的同时,就可以采用Offer/Answer中的信息来进行媒体流交互了。提供/应答模型可用来创建会话或修改已有的会话。
由于PoC业务中为了计费、管理和安全的需要,媒体流需要经过第二客户端方参与功能服务器(以下简称参与功能服务器)和第一客户端方控制功能服务器(以下简称控制功能服务器)的转发或分发,因此PoC业务种的媒体协商采用分段协商的机制。也就是说,Offer/Answer机制的双方为直接进行媒体交互的双方。
PoC业务支持两种协商方法:一种是随选会话。所谓随选会话(On-demandsession),就是一种在会话建立过程中进行媒体类型协商的PoC会话建立机制。另一种是预建立会话,所谓预建立会话是PoC业务中为了加快会话建立速度而采用的一种技术。预建立会话是一个会话建立过程,是在客户端和本地网络之间建立的一个会话,在系统和客户端之间进行媒体协商参数、传输参数及发言权控制的协议参数协商,使得客户端在邀请其它的客户端加入会话或接受一个会话时不用再进行上述参数的协商。
如图1所示,在OMA PoC中,假定有PoC第二客户端(以下简称第二客户端)预建立一个PoC v1.0的会话,一个预建立的会话过程如下:
步骤1:第二客户端向SIP/IP核心网A发送邀请(INVITE)消息,该消息中携带下列信息:
a:参与功能的统一资源标识(Uniform Resource Identifier以下简称URI)(具体实现中可以是本地SERVER URI);
b:第二客户端非激活媒体流的媒体协商参数,包括RTP会话的IP地址和端口号、支持的编码格式、建议的发言权控制协议及端口号等;
c:POC业务指示
d:第二客户端的POC地址
e:发言权控制协议参数
步骤2:第二SIP/IP核心网将INVITE消息发给参与功能服务器。
步骤3:参与功能服务器收到INVITE后,分别执行以下步骤:3’:检查消息中是否有PoC业务指示和INVITE消息中的参与功能URI是否能在控制功能服务器中找到,如果没有PoC业务指示或者不能找到参与功能URI,则向第二SIP/IP核心网发送404(即:NOTFOUND)消息,即没有PoC业务指示或参与功能URI;3”:对第二客户端进行认证鉴权,不通过则向第二SIP/IP核心网发送403(即:FORBIDEN)消息,即第二客户端未通过鉴权;3:检查媒体类型是否能接受,若不能,则向第二SIP/IP核心网发送488(即:NotAcceptable Here)响应消息即不能接受媒体类型。3:若以上均能满足,则控制功能服务器向第二SIP/IP核心网发送200 OK响应。该响应包含下列信息:
a:参与功能服务器的媒体协商参数,包括参与功能服务器的RTP会话的IP地址和端口号,选择的媒体编码格式等;
b:一个用来标示预建立会话的会议URI;
c:选择的发言权控制协议参数;
步骤4:第二SIP/IP核心网将所收到的响应消息发送给第一客户端。
如果第二客户端预建立一个PoC v1.0的会话并被邀请加入会话时,根据PoC第二客户端(以下简称第二客户端)的使用偏好和使用环境等,第二客户端支持两种应答模式:自动应答和手动应答。自动应答即被邀请时自动进入会话;手动应答即弹出确认窗口,由客户端确定后进入会话。
这两种应答模式可以在客户端进行设置,一般默认为自动应答。如果被邀请的客户端已激活了自动应答设置,他将能收听到来自其它PoC会话参与者的语音,而无需进行任何操作,这样方便了客户端的使用,尤其是在某些场合如开车、紧急呼叫等情况下。
发言权控制协议(Talk Burst Control Protocol以下简称TBCP)连接消息(TBCP connect),其作用参与功能服务器发送给使用预建立会话的客户端,通知他(们)已经被连接到PoC会话。利用预建立会话过程,TBCP连接消息通知一个或多个客户端(第二客户端):他已经被邀请参加PoC会话并提供PoC会话的识别码(会话标识),或者通知一个发起(第一客户端)客户端:他已经成功建立一个PoC会话。
在第二客户端预建立会话并且是自动应答的情况下,在PoC V1.0规范中,第二客户端方的参与功能服务器收到第一客户端的呼叫请求后,会直接根据预建立的参数去向第二客户端发起连接消息。如图2所示:假定第一客户端发起群组会话邀请第二客户端加入,对于临时群组会话或者1对1会话时,第二客户端如果采用预建立的自动应答模式,则流程如下:
步骤201-203:控制功能服务器发送邀请(INVITE)消息,根据消息中第二客户端的PoC地址和PoC业务指示,经过第一SIP/IP核心网和第二SIP/IP核心网将该INVITE请求路由到参与功能服务器,该INVITE消息中携带如下信息:第二客户端的PoC地址、控制功能服务器的媒体协商参数、PoC业务指示、第一客户端的PoC地址、控制功能服务器的控制功能已分配指示、选择发言权控制协议、选择的发言权控制实体、本次临时群组PoC会话分配的PoC会话标识。
步骤204-到206:如果第二客户端设置了PoC会话自动应答,并且和参与功能服务器已预建立了会话,参与功能服务器发送OK响应消息到第二SIP/IP核心网后,由第二SIP/IP核心网发送到第一SIP/IP核心网,再由第一SIP/IP核心网将所述OK消息发送到PoC控制功能服务器。其中OK响应包含如下信息:参与功能服务器的媒体协商参数、选择发言权控制协议、发言权控制实体响应。
步骤207:参与功能服务器发送连接(Connect)消息到第二客户端。该消息包括如下信息:第一客户端的客户端地址、第一客户端的昵称、本次临时群组PoC会话标识。
步骤208:第二客户端向参与功能服务器发送确认消息(Talk BurstAcknowledge),从而建立会话。
当采用预定义群组时,第二客户端采用预建立的自动应答,建立群组会话的流程与建立临时会话群组的流程一致,其区别点在:在INVITE消息中临时群组没有群组标识而预定义群组有群组标识,以及connect消息中携带群组相关信息。
然而,从以上方案可以看出,在建立临时群组会话和预定义群组会话时,第二客户端采用预建立会话且自动应答时,参与功能服务器和第二客户端之间不再进行媒体协商,而利用已经协商好的媒体通道直接通过连接消息。
参与功能服务器向第二客户端发起的connect消息为TBCP消息,由于PoC业务媒体协商采用分段协商机制(即第一客户端方的客户端与参与功能服务器,参与功能服务器与控制功能服务器进行能力协商),在媒体类型只有语音的情况下,参与功能服务器向第二客户端发起连接消息不会有什么问题,原因是:第一客户端发出会话请求媒体类型集中的媒体类型和第二客户端预建立会话媒体类型集中的媒体类型肯定一致,因为只有一种语音媒体类型,即使编码方案不一样,也不影响会话的建立,参与功能服务器可以对编码格式做转换。但是,在有多种媒体类型(语音,音频,视频,文本,图片,文件)的情况下,就会产生问题。现假定第二客户端方预建立了一个语音会话类型并采用自动应答,此后第一客户端发出一个视频会话请求,按照现有技术如果去直连(connect)客户端,同时参与功能服务器用自己所支持的媒体类型(视频类型)给第一客户端回了OK应答,那么即使会话建立起来,因为协商媒体类型不一致,导致第二客户端方无法和第一客户端视频,浪费通信资源,以及第一客户端和第二客户端将无法产生可靠的会话连接,导致主第二客户端无法正常通信。
发明内容:
为了解决现有技术中当要建立会话的媒体类型与客户端在会话前预先协商好的媒体类型之间没有相同的媒体类型而无法建立会话,本发明提供一种建立群组会话的方法。
为实现上述目的,本发明提供一种建立群组会话的方法,该方法包括如下步骤:服务器在和客户端建立会话前,判断待建立会话的媒体类型是否采用预建立会话的媒体类型,如是则用预建立会话的媒体类型建立会话,否则通过重协商建立会话或判定无法与所述客户端建立会话。
优选的,执行权利要求1的步骤之前,还应执行:所述客户端在建立会话之前与服务器预建立会话。
优选的,服务器判断待建立会话的媒体类型集和客户端预建立会话的媒体类型集没有相同的媒体类型时,服务器根据所述服务器的设置决定通过重协商建立会话或判定无法与所述客户端建立会话。
优选的,判断待建立会话的媒体类型集是否为所述客户端预建立会话的媒体类型集的子集或超集,或两者的媒体类型集是否存在交集,如是则待建立会话和预建立会话的媒体类型集有相同的媒体类型;否则,待建立会话和预建立会话的媒体类型集没有相同的媒体类型。
优选的,判断待建立会话的媒体类型集是预建立会话媒体类型集的超集时,服务器通过重协商与客户端建立会话。
优选的,所述服务器通过重协商建立会话具体包括以下步骤:服务器向客户端发起包括待建立会话的媒体类型的邀请消息;客户端返回成功响应消息;服务器采用待建立会话的媒体类型与客户端建立会话。
优选的,当客户端预建立会话的应答模式为自动应答模式时,服务器判断是否采用预建立会话的媒体类型。
优选的,服务器采用预建立会话的媒体类型建立会话时,通知所述客户端所述待建立会话包含的媒体类型集。
优选的,所述服务器指参与功能服务器。
优选的,参与功能服务器向控制功能服务发送与所述客户端建立会话失败的消息或发送携带所述客户端预建立会话的媒体类型集的建立会话失败的消息。
由以上方案可以看出,本发明的有益效果如下:
(1)本发明通过服务器提取待建立会话的媒体类型集和客户端预建立会话的媒体类型集进行比较,判断是否有相同的媒体类型,如有则直接连接客户建建立群组会话,否则向客户端发起重邀请消息再联接会话或不连接客户端,从而解决了现有技术中当要建立会话的媒体类型和客户端预建立会话的媒体类型之间没有相同的媒体类型时,服务器仍连接从而浪费通信资源以及不能使群组会话可靠的进行的问题。
(2)此外,当两者没有相同的媒体类型时,本发明通过向邀请建立群组会话的客户端回复不能建立群组会话的原因以及被邀请客户端预建立会话的媒体类型,可以使邀请者重新以被邀请客户端预建立会话的媒体类型发起群组会话,方便邀请者再次发起群组会话的请求。
附图说明:
1.图1为现有技术PoC业务中第二客户端预建立会话流程图;
2.图2为现有技术PoC业务中建立临时群组会话的流程图;
3.图3为本发明所提供的PoC业务中建立群组会话的流程图;
4.图4为图3中一种实施方式的流程图;
5.图5为图3中一种实施方式的流程图;
6.图6为图3中一种实施方式的流程图;
7.图7为图4具体应用实施例的流程图;
8.图8为图5具体应用实施例的流程图;
9.图9为图6具体应用实施例的流程图;
10.图10为图3中一种实施方式的流程图。
具体实施方式:
下面结合附图和具体实施例对本发明再作进一步详细的说明。
如图3所示,当第二客户端和参与功能服务器之间预建立了会话并采用自动应答时,本发明所提供的实施例中建立群组会话的流程如下:
步骤301:当要建立群组会话时,如收到第一客户端发出的邀请加入会话的消息或第一客户端设置的建立会话的条件满足从而服务器触发建立会话时,服务器提取待建立会话的媒体类型集即待建立会话中所有媒体类型的集合,(该参数包括:媒体类型、端口号、传输方式等)同时提取第二客户端预建立会话的媒体类型集。
步骤302:判断待建立会话的媒体类型集与第二客户端预建立会话的媒体类型集中是否包括有相同的媒体类型,即比较待建立会庆的媒体类型集和客户端预建立会话的媒体类型集是否为所述客户端预建立会话的媒体类型集的子集或超集或两者的媒体类型集存在交集,如是,表明有相同的媒体类型,则执行步骤303,如果交集为空时,表明没有相同的媒体类型,则执行步骤304。
其中,媒体类型集是媒体类型的集合,待建立会话的媒体类型集是客户端预建立会话的媒体类型集的子集指:客户端预建立会话的媒体类型集完全包括待建立会话的媒体类型集。反之,待建立会话的媒体类型集是客户端预建立会话的媒体类型集的超集。而如果两者之间没有包含关系,只有某些相同的媒体类型时,表明两者存在交集。
步骤303:服务器按第二客户端预建立会话的媒体类型向第二客户端发起连接并结束流程。
步骤304:服务器不向第二客户端发任何消息,判定无法与所述客户端建立会话。如果服务器收到了第一客户端建立会话的邀请消息,可以直接给第一客户端方返回不能接受该呼叫的消息,消息中可以指明不能接受该呼叫的原因或第二客户端预建立会话的媒体类型集,并结束流程。
其中,如果待建立会话的媒体类型集与第二客户端预建立会话的媒体类型集不存在交集(交集为空)时,即两者之间没有相同的媒体类型时,根据服务器设置或能力,可以用如下步骤替代:
步骤305:第二客户端参与功能服务器向第二客户端发起INVITE或re-INVITE请求,要求第二客户端手动应答,重新协商媒体类型。
步骤306:第二客户端向参与功能服务器发送确认响应消息;
步骤307:控制功能服务器发送接收发言权(Receiving Talk Burst)指示给第二客户端,并建立第一、第二客户端之间的连接。如图4所示,当第一客户端发出的INVITE消息中媒体类型是第二客户端预建立会话的媒体类型集的子集或超集或交集不为空时,直接建立主、第二客户端双方的连接的流程如下:
步骤401:控制功能服务器发送邀请(INVITE)消息到第一SIP/IP核心网;该INVITE消息中携带如下信息:
a:第二客户端的PoC地址;
b:控制功能服务器的媒体协商参数;
c:PoC业务指示;
d:第一客户端的PoC地址;
e:控制功能服务器已分配指示;
f:选择的发言权控制协议;
g:选择发言权控制实体;
h:本次临时群组PoC会话分配的PoC会话标识。
步骤402:第一SIP/IP核心网将该邀请(INVITE)消息发送至第二SIP/IP核心网;
步骤403:第二SIP/IP核心网将收到的该INVITE消息发送到参与功能服务器
步骤404:由于第二客户端设置了PoC会话自动应答,并且和参与功能服务器已预建立了会话,参与功能服务器发送OK响应消息到第二SIP/IP核心网,该OK响应中包含如下信息:参与功能服务器的媒体协商参数、选择发言权控制协议、发言权控制实体响应。
步骤405:第二SIP/IP核心网将收到的OK响应消息发送到第一SIP/IP核心网。
步骤406:第一SIP/IP核心网将收到的OK响应消息发送到控制功能服务器。
步骤407:参与功能服务器提取邀请加入会话的消息中媒体类型和第二客户端预建立会话的媒体类型,并判断两参数中所包括的媒体类型有子集或超集关系或两者交集不为空时,即两参数中包括有相同的媒体类型,执行如下步骤。
步骤408:参与功能服务器发送连接(Connect)消息到第二客户端。该连接消息包括如下信息:第一客户端的PoC地址、第一客户端的昵称、本次临时群组PoC会话的PoC会话标识。
步骤409:第二客户端产生响应connect消息的发言权确认消息,发送到参与功能服务器,并建立第一客户端与第二客户端的连接。
如图5所示,当第一客户端发出的INVITE消息中媒体类型是第二客户端预建立会话的媒体类型没有相同的媒体类型,即两者交集为空时,或第一客户端发出的INVITE消息中媒体类型是第二客户端预建立会话的媒体类型的超集时,参与功能服务器向第二客户端发起重新协商并建立连接的流程如下:
步骤501:控制功能服务器发送INVITE消息到第一SIP/IP核心网;该INVITE消息中携带如下信息:
a:第二客户端的PoC地址;
b:控制功能服务器的媒体协商参数即第一媒体协商参数;
c:PoC业务指示;
d:第一客户端的PoC地址;
e:控制功能服务器已分配指示;
f:选择的发言权控制协议;
g:选择发言权控制实体;
h:本次临时群组PoC会话分配的PoC会话标识。
步骤502:第一SIP/IP核心网根据消息中第二客户端的PoC地址和PoC业务指示,将该INVITE消息发送到第二SIP/IP核心网;
步骤503:第二SIP/IP核心网将收到的该INVITE消息发送到参与功能服务器;
步骤504:由于第二客户端设置了PoC会话自动应答,并且和参与功能服务器已预建立了会话,参与功能服务器发送自动应答响应(AUTO-ANSWER)到第二SIP/IP核心网,指示第二客户端已自动应答;
步骤505:第二SIP/IP核心网将收到的AUTO-ANSWER消息发送到第一SIP/IP核心网;
步骤506:第一SIP/IP核心网将收到的AUTO-ANSWER消息发送到控制功能服务器,指示第二客户端已自动应答。
步骤507:参与功能服务器提取邀请加入会话的消息中媒体类型集和第二客户端预建立会话的媒体类型集,并判断比较两媒体类型集中的媒体类型没有相同的媒体类型,即邀请加入会话消息的媒体类型和第二客户端预建立会话的媒体类型的超集或交集为空,执行如下步骤;
步骤508:参与功能服务器根据第一客户端发出的邀请加入会话的消息中媒体类型集中的媒体类型,向第二SIP/IP核心网发送INVITE或re-INVITE消息。该INVITE或re-INVITE消息包括如下信息:
a:第二客户端的PoC地址;
b:参与功能服务器的媒体协商参数(其中,媒体类型包括第一客户端请求媒体类型);
c:PoC业务指示;
d:第一客户端的PoC地址;
e:选择的发言权控制协议;
f:选择发言权控制实体;
g:本次临时群组PoC会话分配的PoC会话标识;
h:手动应答请求;
步骤509:第二SIP/IP核心网向第二客户端发送该INVITE或re-INVITE消息。
步骤510:第二客户端向第二SIP/IP核心网发送OK响应消息。该消息中携带如下信息:第二客户端的媒体协商参数、所选的发言权控制协议、发言权实体响应。
步骤511:第二SIP/IP核心网将收到的OK响应消息发送至参与功能服务器;
步骤512:参与功能服务器收到第二SIP/IP核心网发送OK响应消息后,再将OK响应消息发送给第二SIP/IP核心网。该OK响应消息包括如下参数:参与功能服务器的媒体协商参数、所选的发言权控制协议、发言权实体响应。
步骤513:第二SIP/IP核心网将收到的OK响应消息发送至第一SIP/IP核心网;
步骤514第一SIP/IP核心网将收到的OK响应消息发送至控制功能服务器。
步骤515:控制功能服务器发送接收发言(Receiving Talk Burst)指示消息给第二客户端,并建立第一客户端与第二客户端之间的连接。该指示消息中携带如下信息:发送该会话参与者客户端的PoC地址、发送该会话参与者的昵称。
如图6所示,当第一客户端发出的INVITE消息的媒体类型和第二客户端预建立会话的媒体类型集之间没有相同的媒体类型,即两者的交集为空时,参与功能服务器直接向控制功能服务器回复呼叫失败的消息的流程如下:
步骤601:控制功能服务器发送INVITE消息到第一SIP/IP核心网;该INVITE消息中携带如下信息:
a:第二客户端的PoC地址;
b:控制功能服务器的媒体协商参数;
c:PoC业务指示;
d:第一客户端的PoC地址;
e:控制功能服务器已分配指示;
f:选择的发言权控制协议;
g:选择发言权控制实体;
h:本次临时群组PoC会话分配的PoC会话标识。
步骤602:第一SIP/IP核心网根据消息中第二客户端的PoC地址和PoC业务指示,将该INVITE消息发送过第二SIP/IP核心网。
步骤603:第二SIP/IP核心网将收到的该INVITE消息发送到参与功能服务器。
步骤604:参与功能服务器提取邀请加入会话的消息中媒体类型集和第二客户端预建立会话的媒体类型集,并判断比较两媒体类型集中没有相同的媒体类型,即交集为空。
步骤605:参与功能服务器向第二SIP/IP核心网发送488(Not AcceptableHere)消息,指示第二客户端预建立媒体类型不支持第一客户端请求媒体类型,此时,488(Not Acceptable Here)消息还可以携带第二客户端支持的预建立会话媒体类型集指示。
步骤606:第二SIP/IP核心网将收到的488(Not Acceptable Here)消息发送给第一SIP/IP核心网。
步骤607:第一SIP/IP核心网将收到的488(Not Acceptable Here)消息发送给控制功能服务器。
如果采用预定义群组会话,第二客户端采用预建立的自动应答会话流程与上述采用临时群组会话中第二客户端采用预建立的自动应答会话流程基本相同,只是在INVITE消息、Connect消息以及INVITE消息中携带的是预定义群组标识而非临时群组标识。
第一实施例
如果第一客户端向包括用户在内的群组人员发起一个临时群组会话,第一客户端希望和大家视频通话,第二客户端采用的是预建立的语音和视频通话并采用自动应答。第二客户端的预建立媒体协商参数(SDP PARAMETERS):
Content-Type | application/sdp | |
SDP参数部分 | ||
c= | IN IP6 5536::aaa:bbb:ccc:ddd | |
m= | video 4456 RTP/AVP 99 | |
a= | rtpmap:99 H.261 | |
m= | audio 5600 RTP/AVP 97 | |
a= | rtpmap:97 AMR | |
a= | rtcp:5566 |
参数说明:
C:连接信息
m:媒体信息
a:属性
如图7所示,实现上述情况的流程如下:
步骤701:第一客户端向第一SIP/IP核心网发送INVITE消息以向第二客户端发起临时群组会话,该邀请(INVITE)消息中携带如下信息:
a.第二客户端的PoC地址
b.第一客户端的媒体协商参数(SDP PARAMETERS),该参数见下表:
Content-Type | application/sdp | |
SDP参数部分 |
c= | IN IP6 5555::aaa:bbb:ccc:ddd | |
m= | Video 3456 RTP/AVP 99 | |
a= | rtpmap:99 H.261 | |
a= | rtcp:5560 |
c.PoC业务指示
d.第一客户端的PoC地址
e.选择发言权控制协议
f.选择的发言权控制实体建议
步骤702:第一SIP/IP核心网将该INVITE消息发送给控制功能服务器。
步骤703:控制功能服务器收到第一SIP/IP核心网发送INVITE消息后,将该消息转发给参与功能服务器。该INVITE请求中包含如下信息:
a.第二客户端的PoC地址;
b.控制功能服务器的媒体协商参数(SDP PARAMETERS,其中该参数中的媒体类型和第一客户端要协商的媒体类型相同,如下表:
Content-Type | application/sdp | |
SDP参数部分 | ||
c= | IN IP6 50555::aaa:bbb:ccc:ddd | |
m= | Video 53456 RTP/AVP 98 99 | |
a= | rtpmap:99 H.261 | |
a= | rtcp:5561 |
c.PoC业务指示;
d.第一客户端的PoC地址;
e.控制功能服务器已分配指示;
f.选择发言权控制协议;
g.选择的发言权控制实体建议;
h.本次临时群组PoC会话分配的PoC会话标识;
步骤704:第一SIP/IP核心网将该INVITE消息发送给第二SIP/IP核心网。
步骤705:第二SIP/IP核心网将收到的由第一SIP/IP核心网发出的INVITE消息发送给参与功能服务器。
步骤706:由于第二客户端设置了PoC会话自动应答,并且和参与功能服务器预建立了会话,PoC业务B发送OK响应消息到第二SIP/IP核心网,OK响应中包含如下信息:
a.参与功能服务器的媒体协商参数(SDP PARAMETERS),见下表:
Content-Type | application/sdp | |
SDP参数部分 | ||
c= | IN IP6 50558::aaa:bbb:ccc:ddd | |
m= | Video 53458 RTP/AVP 98 99 | |
a= | rtpmap:99 H.261 | |
a= | rtcp:5562 |
b.选择发言权控制协议;
c.发言权控制实体响应;
步骤707:第二SIP/IP核心网将OK响应消息发送给第一SIP/IP核心网;
步骤708:第一SIP/IP核心网将收到的OK响应消息发送给控制功能服务器;
步骤709:控制功能服务器将OK响应消息发送给第一SIP/IP核心网。该OK消息中携带如下信息:
a.控制功能服务器的媒体协商参数(SDP PARAMETERS),见下表:
Content-Type | application/sdp | |
SDP参数部分 | ||
c= | IN IP6 50555::aaa:bbb:ccc:ddd | |
m= | Video 53456 RTP/AVP 99 |
a= | rtpmap:99 H.261 | |
a= | rtcp:5561 |
b.选择发言权控制协议;
c.发言权控制实体响应;
步骤710:第一SIP/IP核心网将收到的由控制功能服务器发送的经控制功能服务器修改后的OK响应消息发送给第一客户端。
步骤711:控制功能服务器发送发言权确认(Talk Burst Confirm)指示消息给第一客户端。
步骤712:参与功能服务器提取邀请加入会话的消息中媒体类型集和第二客户端预建立会话的媒体类型集,并判断比较两媒体类型集中有相同的媒体类型。由于第二客户端预建立的为video和audio类型,第一客户端发起的为video类型,{video}∩{video,audio}={video},因此两媒体类型集中有相同的媒体类型
步骤713:参与功能服务器发送Connect消息到第二客户端。该连接消息包括如下信息:
a.第一客户端的PoC地址;
b.第一客户端的昵称;
c.本次临时群组PoC会话的PoC会话标识;
步骤714:第二客户端产生响应connect消息的发言权确认消息,发送到参与功能服务器,建立第一客户端与第二客户端的连接。
第二实施例:
第一客户端向包括第二客户端在内的临时群组人员发起一个群组会话,第一客户端希望和大家视频通话,第一个应答第一客户端的第二客户端采用的是预建立的语音通话并采用自动应答。第二客户端的预建立媒体协商参数SDPPARAMETERS如下表所示:
Content-Type | application/sdp | |
SDP参数部分 | ||
c= | IN IP6 5536::aaa:bbb:ccc:ddd | |
m= | audio 5600 RTP/AVP 97 | |
a= | rtp:97 AMR | |
a= | rtcp:5560 |
如图8所示,如果参与功能服务器不发起重新协商,直接给控制功能会会话建立失败的消息,其流如下:
步骤801:第一客户端向第一SIP/IP核心网发送INVITE消息以向第二客户端发起临时群组会话,该邀请(INVITE)消息中携带如下信息:
a.第二客户端的PoC地址
b.第一客户端的媒体协商参数(SDP PARAMETERS),见下表:
Content-Type | application/sdp | |
SDP参数部分 | ||
c= | IN IP6 5555::aaa:bbb:ccc:ddd | |
m= | Video 3456 RTP/AVP 99 | |
a= | rtpmap:99 H.261 | |
a= | rtcp:5561 |
c.PoC业务指示
d.第一客户端的PoC地址
e.选择发言权控制协议
f.选择的发言权控制实体建议
步骤802:第一SIP/IP核心网将该INVITE消息发送给控制功能服务器。
步骤803:控制功能服务器收到第一SIP/IP核心网发送INVITE消息后,转发该INVITE消息给第一SIP/IP核心网。该INVITE消息包括如下信息:
a.第二客户端的PoC地址;
b.控制功能服务器的媒体协商参数SDP PARAMETERS见下表:
Content-Type | application/sdp | |
SDP参数部分 | ||
c= | IN IP6 50555::aaa:bbb:ccc:ddd | |
m= | Video 53456 RTP/AVP 98 99 | |
a= | rtpmap:99 H.261 | |
a= | rtcp:5562 |
c.PoC业务指示;
d.第一客户端的PoC地址;
e.控制功能服务器已分配指示;
f.选择发言权控制协议;
g.选择的发言权控制实体建议;
h.本次临时群组PoC会话分配的PoC会话标识。
步骤804:第一SIP/IP核心网转发INVITE消息给第二SIP/IP核心网。
步骤805:第二SIP/IP核心网将收到的由第一SIP/IP核心网发出的INVITE消息发送给参与功能服务器。
步骤806:参与功能服务器提取邀请加入会话的消息中媒体类型集和第二客户端预建立会话的媒体类型集,由于第二客户端预建立的为audio类型,第一客户端发起的为video类型,{video}∩{audio}=Φ,因此两媒体类型集中没有相同的媒体类型。
步骤807:参与功能服务器向第二SIP/IP核心网发送488(Not AcceptableHere)消息,指示第二客户端预建立媒体类型不支持第一客户端请求媒体类型,此时,488消息还可以给第一客户端携带第二客户端支持的预建立会话媒体类型集指示。
步骤808:第二SIP/IP核心网将收到的488(Not Acceptable Here)消息发送给第一SIP/IP核心网。
步骤809:第一SIP/IP核心网将收到的488(Not Acceptable Here)消息发送给控制功能服务器。如果所有的第二客户端都回488(Not Acceptable Here)失败响应,则有如下步骤:
步骤810’:控制功能服务器将收到的488(即:Not Acceptable Here)消息返还给第一SIP/IP核心网;
步骤811’:第一SIP/IP核心网将收到的由控制功能服务器发送的488(NotAcceptable Here)消息发送给第一客户端。
否则,当收到第一个最终成功OK应答时,有如下步骤:
步骤810”:控制功能服务器向第一SIP/IP核心网发送OK响应消息;该OK消息中携带如下信息:
a.控制功能服务器的媒体协商参数;
b.选择发言权控制协议;
c.发言权控制实体响应;
d.第一OK应答者所包含的媒体类型(可选)
步骤811”:第一SIP/IP核心网将收到的由控制功能服务器发送的OK响应消息发送给第一客户端。
如图9所示,参与功能服务器要向第二客户端发起重新协商,并使第一客户端与第二客户端建立连接,其流程如下:
步骤901:第一客户端向第一SIP/IP核心网发送INVITE消息以向第二客户端发起临时群组会话,该邀请(INVITE)消息中携带如下信息:
a)第二客户端的PoC地址;
b)第一客户端的媒体协商参数(SDP PARAMETERS)见下表:
Content-Type | application/sdp | |
SDP参数部分 |
c= | IN IP6 5555::aaa:bbb:ccc:ddd | |
m= | Video 3456 RTP/AVP 99 | |
a= | rtpmap:99 H.261 | |
a= | rtcp:5561 |
c) PoC业务指示;
d)第一客户端的PoC地址;
e)选择发言权控制协议;
f)选择的发言权控制实体建议;
步骤902:第一SIP/IP核心网将该INVITE消息发送给控制功能服务器。
步骤903:控制功能服务器收到该消息后,转发该INVITE消息发送给第一SIP/IP核心网(可能修改其中的端口号和编码方案)。该INVITE消息包括如下信息:
a)第二客户端的PoC地址;
b)控制功能服务器的媒体协商参数SDP PARAMETERS见下表:
Content-Type | application/sdp | |
SDP参数部分 | ||
c= | IN IP6 50555::aaa:bbb:ccc:ddd | |
m= | Video 53456 RTP/AVP 98 99 | |
a= | rtpmap:99 H.261 | |
a= | rtcp:5562 |
c)PoC业务指示;
d)第一客户端的PoC地址;
e)控制功能服务器已分配指示;
f)选择发言权控制协议;
g)选择的发言权控制实体建议;
h)本次临时群组PoC会话分配的PoC会话标识。
步骤904:第一SIP/IP核心网根据收到的经控制功能服务器发送的INVITE消息中的第二客户端的PoC地址和PoC业务指示,将该经控制功能服务器修改后的INVITE消息发送给第二SIP/IP核心网。
步骤905:第二SIP/IP核心网将收到的由第一SIP/IP核心网发出的INVITE消息发送给参与功能服务器。
步骤906:由于第二客户端设置了PoC会话自动应答,并且和参与功能服务器已预建立了会话,参与功能服务器发送自动应答响应(AUTO-ANSWER)到第二SIP/IP核心网,指示第二客户端已自动应答;
步骤907:第二SIP/IP核心网将收到的AUTO-ANSWER消息发送到第一SIP/IP核心网;
步骤908:第一SIP/IP核心网将收到的AUTO-ANSWER消息发送到控制功能服务器,指示第二客户端已自动应答。
步骤909:控制功能服务器收到AUTO-ANSWER消息后,发送不带确认指示的OK响应消息(UNCONFIRMED OK)到第一SIP/IP核心网。该消息中携带如下信息:
a.控制功能服务器的媒体协商参数(SDP PARAMETERS),见下表:
Content-Type | application/sdp | |
SDP参数部分 | ||
c= | IN IP6 50555::aaa:bbb:ccc:ddd | |
m= | Video 53456 RTP/AVP 99 | |
a= | rtpmap:99 H.261 | |
a= | rtcp:5562 |
b.选择发言权控制协议;
c.发言权控制实体响应。
步骤910:第一SIP/IP核心网将收到的UNCONFIRMED OK消息发送给第一客户端。
步骤911:控制功能服务器发送发言权确认(Talk Burst Confirm)指示给第一客户端。
步骤912:参与功能服务器提取邀请加入会话的消息中媒体类型集和第二客户端预建立会话的媒体类型集,由于第二客户端预建立的为audio类型,第一客户端发起的为video类型,{video}∩{audio}=Φ,因此两媒体类型集中没有相同的媒体类型。
步骤913:参与功能服务器根据第一客户端网络的请求媒体类型构造re-INVITE消息,发送INVITE消息到第二SIP/IP核心网。该re-INVITE消息包括如下信息:
a.第二客户端的PoC地址
b.参与功能服务器的媒体协商参数(SDP PARAMETERS)见下表:
Content-Type | application/sdp | |
SDP参数部分 | ||
c= | IN IP6 50558::aaa:bbb:ccc:ddd | |
m= | Video 53458 RTP/AVP 98 99 | |
a= | rtpmap:99 H.261 | |
a= | rtcp:5563 |
c.PoC业务指示;
d.第一客户端的PoC地址;
e.选择发言权控制协议;
f.选择发言权控制实体;
g.手动应答请求;
h.本次临时群组PoC会话分配的PoC会话标识;
步骤914:第二SIP/IP核心网将收到的参与功能服务器发送的re-INVITE消息发送给第一客户端。
步骤915:第二客户端向第二SIP/IP核心网发送OK响应消息。该消息中携带如下信息:
a.第二客户端的媒体协商参数(SDP PARAMETERS),见下表:
Content-Type | application/sdp | |
SDP参数部分 |
c= | IN IP6 5536::aaa:bbb:ccc:ddd | |
m= | video 5600 RTP/AVP 99 | |
a= | rtpmap:99 H.261 | |
a= | rtcp:5564 |
b.所选的发言权控制协议
c.发言权实体响应
步骤916:第二SIP/IP核心网将收到的第二客户端发送的OK响应消息发送给参与功能服务器。
步骤917:参与功能服务器收到第二SIP/IP核心网发送OK响应消息后,根据OK响应消息中携带的参数与第二客户端进行能力协商,并将协商结果写入所述OK响应消息体中从而修改所述OK,再将经修改后的OK响应消息发送给第二SIP/IP核心网。经参与功能服务器修改后的OK响应消息中携带如下信息:
a.参与功能服务器的媒体协商参数(SDP PARAMETERS)见下表:
Content-Type | application/sdp | |
SDP参数部分 | ||
c= | IN IP6 50558::aaa:bbb:ccc:ddd | |
m= | Video 53458 RTP/AVP 99 | |
a= | rtpmap:99 H.261 | |
a= | rtcp:5563 |
b.选择发言权控制协议
c.发言权控制实体响应
步骤918:第二SIP/IP核心网将收到的由参与功能服务器发送的并经参与功能服务器修改后的OK响应消息发送给第一SIP/IP核心网;
步骤919:SIP/IP核心网将收到的由第二SIP/IP核心网发送的OK响应消息发送给控制功能服务器。
步骤920:控制功能服务器收到第一SIP/IP核心网发送OK响应消息后,依据该OK响应消息中的参数,并将修改OK响应消息中的消息体媒体类型及编码格式端口等参数并将该消息发送给第一SIP/IP核心网。经控制功能服务器修改后的OK响应消息中携带如下信息:
a.控制功能服务器的媒体协商参数,SDP PARAMETERS见下表:
Content-Type | application/sdp | |
SDP参数部分 | ||
c= | IN IP6 50555::aaa:bbb:ccc:ddd | |
m= | Video 53456 RTP/AVP 99 | |
a= | rtpmap:99 H.261 | |
a= | rtcp:5562 |
b.选择发言权控制协议
c.发言权控制实体响应
步骤921:第一SIP/IP核心网将收到的由控制功能服务器发送的并经控制功能服务器修改后的OK响应消息发送给第一客户端。
步骤922:控制功能服务器在收到第一SIP/IP核心网发送的OK响应消息后,向参与功能服务器发送接收会话(Receiving Talk Burst)消息。该消息中携带如下信息:
a.发送该会话参与者客户端的PoC地址
b.发送该会话参与者的昵称
步骤922:参与功能服务器将收到的Receiving Talk Burst消息发送给第二客户端。
第三实施例
第三方在服务器上设置了触发条件,并设置了要发起会话的媒体参数,假定要发起的会话媒体类型为视频类型。触发条件满足后,服务器向客户端发起一个临时群组会话,建立视频通话,客户端在服务器上预建立了包含语音和视频两种媒体类型的会话并采用自动应答。客户端的预建立媒体协商参数(SDPPARAMETERS)如下表:
Content-Type | application/sdp | |
SDP参数部分 | ||
c= | IN IP6 5536::aaa:bbb:ccc:ddd | |
m= | video 4456 RTP/AVP 99 | |
a= | rtpmap:99 H.261 | |
m= | audio 5600 RTP/AVP 97 | |
a= | rtpmap:97 AMR | |
a= | rtcp:5566 |
如图10所示,实现上述情况的流程如下:
步骤1001:触发条件满足,服务器发起会话。
步骤1002:服务器提取要发起会话的媒体类型集和客户端预建立会话的媒体类型集,并判断比较两媒体类型集中的媒体类型。由于客户端预建立的为video和audio类型,发起的为video类型,{video}∩{video,audio}={video},即两者有相同的媒体类型,执行如下步骤:
步骤1003:参与功能服务器发送Connect消息到客户端。该连接消息包括如下信息:本次临时群组PoC会话的PoC会话标识;
步骤1004:客户端产生响应connect消息的发言权确认消息,发送到服务器,建立服务器与客户端之间的连接。
由以上方案可以看出,本发明通过服务器提取要建立会话的媒体类型和客户端预建立会话的媒体类型进行比较,判断是否有相同的媒体类型,如有则直接连接客户建建立群组会话,否则向客户端发起重邀请消息再联接会话或不连接客户端,从而解决了现有技术中当要建立会话的媒体类型和客户端预建立会话的媒体类型之间没有相同的媒体类型时,服务器仍连接从而浪费通信资源以及不能使群组会话可靠的进行的问题。
当然,以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (10)
1.一种建立群组会话的方法,其特征在于该方法包括如下步骤:服务器在和客户端建立会话前,判断待建立会话的媒体类型是否采用预建立会话的媒体类型,如是则用预建立会话的媒体类型建立会话,否则通过重协商建立会话或判定无法与所述客户端建立会话。
2.如权利要求1所述的建立群组会话的方法,其特征在于执行权利要求1的步骤之前,还应执行:所述客户端在建立会话之前与服务器预建立会话。
3.如权利要求1所述的建立群组会话的方法,其特征在于,服务器判断待建立会话的媒体类型集和客户端预建立会话的媒体类型集没有相同的媒体类型时,服务器根据所述服务器的设置决定通过重协商建立会话或判定无法与所述客户端建立会话。
4.如权利要求1或3所述的建立群组会话的方法,其特征在于所述判断包括:判断待建立会话的媒体类型集是否为所述客户端预建立会话的媒体类型集的子集或超集,或两者的媒体类型集是否存在交集,如是则待建立会话和预建立会话的媒体类型集有相同的媒体类型;否则,待建立会话和预建立会话的媒体类型集没有相同的媒体类型。
5.如权利要求4所述的建立群组会话的方法,其特征在于判断待建立会话的媒体类型集是预建立会话媒体类型集的超集时,服务器通过重协商与客户端建立会话。
6.如权利要求1所述的建立群组会话的方法,其特征在于,所述服务器通过重协商建立会话具体包括以下步骤:
服务器向客户端发起包括待建立会话的媒体类型的邀请消息;
客户端返回成功响应消息;
服务器采用待建立会话的媒体类型与客户端建立会话。
7、如权利要求5所述的建立群组会话的方法,其特征在于,当客户端预建立会话的应答模式为自动应答模式时,服务器判断是否采用预建立会话的媒体类型。
8、如权利要求1所述的建立群组会话的方法,其特征在于,服务器采用预建立会话的媒体类型建立会话时,通知所述客户端所述待建立会话包含的媒体类型集。
9、如权利要求1、2、3、6、7或8所述的建立群组会话的方法,其特征在于,所述服务器指参与功能服务器。
10、如权利要求9所述的建立群组会话的方法,其特征在于,参与功能服务器向控制功能服务发送与所述客户端建立会话失败的消息或发送携带所述客户端预建立会话的媒体类型集的建立会话失败的消息。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2006100613951A CN101098513B (zh) | 2006-06-28 | 2006-06-28 | 一种建立群组会话的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2006100613951A CN101098513B (zh) | 2006-06-28 | 2006-06-28 | 一种建立群组会话的方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101098513A true CN101098513A (zh) | 2008-01-02 |
CN101098513B CN101098513B (zh) | 2011-11-02 |
Family
ID=39011964
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2006100613951A Expired - Fee Related CN101098513B (zh) | 2006-06-28 | 2006-06-28 | 一种建立群组会话的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101098513B (zh) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101854372A (zh) * | 2009-04-03 | 2010-10-06 | 华为技术有限公司 | 一种点击拨号中控制会话媒体类型的方法和装置 |
WO2015096686A1 (zh) * | 2013-12-23 | 2015-07-02 | 广州华多网络科技有限公司 | 一种建立语音通信的方法及系统 |
CN105872833A (zh) * | 2015-12-15 | 2016-08-17 | 乐视致新电子科技(天津)有限公司 | 视频通信方法及装置、智能电视 |
CN109257318A (zh) * | 2017-07-12 | 2019-01-22 | 中国移动通信集团广东有限公司 | 一种群组通话建立方法及平台 |
CN110381039A (zh) * | 2019-06-27 | 2019-10-25 | 杭州叙简科技股份有限公司 | 一种融合快速云眼查看的手机PoC对讲业务实现方法 |
CN111555964A (zh) * | 2020-04-30 | 2020-08-18 | 网易(杭州)网络有限公司 | 一种群组成员的管理方法、电子设备和存储介质 |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1619854A1 (en) * | 2004-07-21 | 2006-01-25 | Siemens Mobile Communications S.p.A. | SIP message extension for push to watch service |
CN1303793C (zh) * | 2004-09-21 | 2007-03-07 | 华为技术有限公司 | 一种实现应用服务器通信的方法 |
-
2006
- 2006-06-28 CN CN2006100613951A patent/CN101098513B/zh not_active Expired - Fee Related
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101854372A (zh) * | 2009-04-03 | 2010-10-06 | 华为技术有限公司 | 一种点击拨号中控制会话媒体类型的方法和装置 |
CN101854372B (zh) * | 2009-04-03 | 2014-07-30 | 华为技术有限公司 | 一种点击拨号中控制会话媒体类型的方法和装置 |
WO2015096686A1 (zh) * | 2013-12-23 | 2015-07-02 | 广州华多网络科技有限公司 | 一种建立语音通信的方法及系统 |
CN105872833A (zh) * | 2015-12-15 | 2016-08-17 | 乐视致新电子科技(天津)有限公司 | 视频通信方法及装置、智能电视 |
CN109257318A (zh) * | 2017-07-12 | 2019-01-22 | 中国移动通信集团广东有限公司 | 一种群组通话建立方法及平台 |
CN109257318B (zh) * | 2017-07-12 | 2021-06-11 | 中国移动通信集团广东有限公司 | 一种群组通话建立方法及平台 |
CN110381039A (zh) * | 2019-06-27 | 2019-10-25 | 杭州叙简科技股份有限公司 | 一种融合快速云眼查看的手机PoC对讲业务实现方法 |
CN111555964A (zh) * | 2020-04-30 | 2020-08-18 | 网易(杭州)网络有限公司 | 一种群组成员的管理方法、电子设备和存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN101098513B (zh) | 2011-11-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101138201B (zh) | 在无线一键通网络中识别响应客户机的方法和系统 | |
CN101682409B (zh) | 管理预建立的会话的方法、实现该方法的无线一键通话系统和无线一键通话用户设备 | |
CN101061687B (zh) | 处理PoC呼叫的方法和系统 | |
CN101106536B (zh) | 一种建立群组会话的方法 | |
CN101491124B (zh) | 用于使用实时控制协议连接消息来处理无线一键通自组织群组会话信息的方法和系统 | |
CN102438009B (zh) | 在无线一键通网络中执行媒体存储服务的方法和系统 | |
CN102348167B (zh) | 在服务器中支持多种多媒体类型的通信服务的方法 | |
CN101548556B (zh) | 建立和管理用于执行多媒体呼叫业务的多媒体基于蜂窝网络的即按即说会话的系统及其方法和用户设备 | |
US20060223563A1 (en) | Method and system for transmitting information of respondent participating in push-to-talk over cellular network session | |
CN101313493A (zh) | 用于在poc系统中开启ad-hoc poc会话的方法、用户设备和系统 | |
CN1328917C (zh) | 架构即按即说通信连结及即按即说客户单元的方法及通信装置 | |
US20060211438A1 (en) | Method and system for granting floor in push-to-talk over cellular network | |
CN102355631A (zh) | 传输和施加发言权控制方案的用户设备、服务器及方法 | |
CN101098513B (zh) | 一种建立群组会话的方法 | |
CN100433857C (zh) | 普通多媒体终端实现集群呼叫的方法 | |
CN101188815B (zh) | 媒体流数据的传送方法、系统、服务器及客户端 | |
CN100409701C (zh) | 控制集群系统无线一键通方式讲话权的方法 | |
CN101820589A (zh) | 用于划分单个PoC组会话的方法和系统 | |
CN101682395B (zh) | 管理无线一键通话会话中支持的一个或多个媒体类型的方法、实现该方法的无线一键通话系统和无线一键通话用户设备 | |
CN101578850A (zh) | 标识会议中的参与者 | |
CN101026871A (zh) | 在会话初始化协议多媒体通信系统中处理媒体类型的方法 | |
CN100366038C (zh) | 基于蜂窝网的即按即说会话控制方法 | |
CN101400022B (zh) | 标识业务类型及根据标识建立业务的方法、装置及系统 | |
KR101277860B1 (ko) | PoC 시스템에서의 멀티 미디어 통화 서비스를 수행하기위한 발언권 관리 시스템과 그 방법 및 단말장치 | |
KR20070075649A (ko) | PoC 시스템에서 멀티미디어 PoC 세션 참가자 정보제공 방법과 단말 장치 및 그 시스템 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20111102 Termination date: 20170628 |