CN103024681B - 一种高效的按键通话方法 - Google Patents
一种高效的按键通话方法 Download PDFInfo
- Publication number
- CN103024681B CN103024681B CN201110282500.5A CN201110282500A CN103024681B CN 103024681 B CN103024681 B CN 103024681B CN 201110282500 A CN201110282500 A CN 201110282500A CN 103024681 B CN103024681 B CN 103024681B
- Authority
- CN
- China
- Prior art keywords
- poc
- message
- territory
- rtcp
- tbcptalkburst
- 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.)
- Active
Links
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
本发明公开了一种按键通话中呼叫建立的时间太长的问题的解决方案。针对现有OMA的PoC(push?to?talk?over?celluler)规范中首次呼叫建立延时、通话延时时间比较长的问题,对会话控制协议进行修改后传输的呼叫控制协议数据量减少,并对音频数据进行打包传输,达到减少延时的目的。
Description
技术领域
本发明涉及通讯领域,特别是涉及一种基于的移动通信网络分组域的会话协商和音频媒体数据传输的领域。
背景技术
SIP是一个应用层的信令控制协议。用于创建、修改和释放一个或多个参与者的会话。这些会话可以好似Internet多媒体会议、IP电话或多媒体分发。会话的参与者可以通过组播(multicast)、网状单播(unicast)或两者的混合体进行通信。SIP它既不是会话描述协议,也不提供会议控制功能。为了描述消息内容的负载情况和特点,SIP使用Internet的会话描述协议(SDP)来描述终端设备的特点。SIP自身也不提供服务质量(QoS),它与负责语音质量的资源保留设置协议(RSVP)互操作。
在进行实时传输媒体数据时,使用RTP协议与SIP合作使用。RTCP控制协议需要与RTP数据协议一起配合使用,RTP本身并不能为按序传输数据包提供可靠的保证,也不提供流量控制和拥塞控制,这些都由RTCP来负责完成。通常RTCP会采用与RTP相同的分发机制,向会话中的所有成员周期性地发送控制信息,应用程序通过接收这些数据,从中获取会话参与者的相关资料,以及网络状况、分组丢失概率等反馈信息,从而能够对服务质量进行控制或者对网络状况进行诊断。
在现在的OMA规范中PoC业务就是使用的SIP加RTP/RTCP的方案,SIP用于会话的协商,RTP/RTCP用于流媒体数据的传输。
对于PoC业务的使用场景主要在通话比较频繁的地方或者偏僻的郊外,如行业用户中的电力、物流、水利等,这些地方偏僻、流动性大,不可能有专用网络,接入方式使用最多的就是现在覆盖比较好的移动通信网络,所以3G分组域接入成了最常用的接入方式。
在现有的产品中,受限于带宽、PDP激活时长等的限制导致会话建立时间太长、语音延时明显的问题,分析其原因主要是由几个方面引起,一个是PDP激活的时长,这个由移动网络决定不在此讨论。一个是通过SIP协议做会话协商的时间太长,由于SIP协议数据量太大,做会话协商需要的时间比较长。另外一个是做媒体流传输的包太小,导致传输中有大量的包头数据和建立连接次数太多消耗时间,本发明就是针对后两个问题做优化来减少按键通话的会话建立延时和传输效率地下。
发明内容
本发明所要解决的技术问题是在原有RTCP协议的基础上作了如下改进,使用RTP协议进行媒体数据传输,RTCP协议在实现本身功能的同时进行扩展,使其同时能够完成会话协商的功能来替代SIP会话协商;并对传输的媒体包进行打包处理使相同时间发送的包的数量最少。
为实现上述发明目的,本发明提供一个重新封装的RTP/RTCP协议库,及对应的PoC服务器,包括PoC客户端和PoC服务器:
所述PoC客户端,用于最终用户使用,手机终端中的PoC软件通过移动通讯网络的分组域连接,注册使用SIP消息在服务器中注册,移动通讯网络分组域连接为了节约资源,防止没有数据的空连接太多都设置了连接时长限制,在一段时间内如果没有数据传输就会断开连接,所以客户端软件在注册成功后为了维持连接需要发送心跳消息,心跳消息的间隔时长根据不同地方的网络设置有区别,心跳消息是通过RTP和RTCP消息发送,发送IDLE消息,不作其他功能,只是维持连接使用。根据用户的操作发起对PoC联系人的按键通话操作,发起呼叫的主叫方通过RTCP的格式和通道,把RTCP包的APP字段特殊定义成204,subtype字段定义成不同的会话控制请求类型,把NAME定义成“PoC1”,这样整个会话协商功能的包就完成了,通过RTCP通道发送,并通过接受RTCP通道的消息来完成会话协商,这样在;
所述PoC服务器,用于对PoC客户端服务,支撑PoC业务的使用。
本发明还提供一套打包和解包的方法,包括:
1.本系统使用AMR编码格式5.15kbps的比特率,这个比特率对于人说话的声音清晰度是够用的,音频数据采集是20ms一组数据,在编码后一组数据是13字节,在对音频数据打包处理时不是一组数据一发,而是采用8组数据编码完成后组合在一起发送,这样处理主要考虑两方便,一个是数据不能太短,太短发送频率太大,这样建立连接和包头数据冗余太多,影响发送效率;数据不能太长,太长后延时就长,另外要一个分组域的包能发送完成,如果分包处理就会有延时。
2.解包时,服务器或客户端会先根据收到包的长度,来判断该包构成,然后再解包恢复媒体数据。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1为本发明实施中消息控制图;
图2为本发明实施中的媒体数据组包发送格式。
具体实施方式
为使本发明的上述目的、特征和优点能够更加明显易懂,下面结合附图和具体实施方式对本发明作进一步详细的说明。显然,所描述的实施例仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
本发明提供一个重新封装的RTP/RTCP协议库,其中改进点包括:
RTCP是发言权控制协议,是基于RTCP应用包的(RTCP:APP),与其他的RTCP包发送到相同的UDP端口。
RTCP定义的控制TBCP消息包括:
·TBCPTalkBurstRequest——客户端向服务器端请求发言权允许
表1“TBCPTalkBurst请求消息”说明了消息的内容。
在Subtype域中的下列比特格式应该被用来作为TBCPTalkBurst请求信息:00000。SSRC域应该携带申请发言权的PoC用户的SSRC值。在TBCPTalkBurst请求消息中,可以包含一个或多个可选域。每个TBCPTalkBurst请求消息可选域应该包含三个子域。
第一个子域是可选ID子域。这个可选ID子域应该标识选来作为8-bit可选ID的选项。
第二个子域是可选长度子域。可选长度子域应该由一个字节组成,说明整个可选域的长度。可选长度子域的值应该等于可选ID子域、可选长度子域和可选值子域字节数的总和。
注意:这个长度没有必要乘以4。
第三个子域是可选值子域。这个值子域应该包含一个字节数的整数值。这个子域的格式和值是依赖于应用选项的。
下面的定义了TBCPTalkBurst请求信息选项
如果PoC服务器收到重复的TBCPTalkBurstrequest,PoC服务器按照正常的处理方法处理请求。
·TBCPTalkBurstGranted——服务器端通知客户端允许其讲话
表2“TBCPTalkBurst允许消息”显示了消息的内容。
在Subtype域中的下列比特格式应该被用来作为TBCPTalkBurst允许信息:00001。TBCPTalkBurst允许消息应该只包含12字节的包头信息,长度域应该被设为2。SSRC域应该携带完成控制功能的PoC服务器的SSRC信息。
·TBCPTalkBurstDeny——服务器端通知客户端请求被拒绝
表3“TBCPTalkBurst拒绝消息”显示了消息的内容。
在Subtype域中的下列比特格式应该被用来作为TBCPTalkBurst拒绝信息:00011。这个TBCPTalkBurst拒绝消息中的应用相关的数据包含了用原因代码表示拒绝的原因,并且可能在原因短语域紧跟一个文本,描述请求为什么被拒绝。因此包的长度将根据应用相域的大小而改变。SSRC域应该携带完成控制功能的PoC服务器的SSRC信息。在应用相关的数据中的最先8比特是用来作为原因代码域。
长度子域给出了原因短语的字节长度,如果长度子域的值被设为0,表示在原因短语中没有原因。原因短语域中可以包含具有附加短语的字符串,这个字符串应该使用象在SDES条款CNAME中一样的编码。
·TBCPTalkBurstRelease——客户端通知服务器端讲话结束
表4“TBCPTalkBurst释放消息”显示了这个消息的内容。
在Subtype域中的下列比特格式应该被用来作为TBCPTalkBurst释放信息:00100。与应用相关的数据域由4个字节组成。
前16(0-15)个比特表示了在TalkBurst序列中最后一个RTP媒体包的序列号。
比特16是忽略序列号域,该值为0是序列号有效,为1时序列号无效。
在应用相关数据中的最后15个比特是填充比特,建议全部设为0。PoC服务器应该忽略填充比特的值。
·TBCPTalkBurstIdle——服务器端通知客户端现在空闲,可以发送发言权请求
表5“TBCPTalkBurst空闲消息”显示了消息的内容。
在Subtype域中的下列比特格式应该被用来作为TBCPTalkBurst空闲信息:00101。TBCPTalkBurst空闲消息应该只包含12字节的包头信息,长度域应该被设为2。SSRC域应该携带完成控制功能的PoC服务器的SSRC信息。
·TBCPTalkBurstTaken——服务器端通知所有客户端(被分配发言权的除外)发言权被分配
表6“TBCPTalkBurst占用消息”显示了消息的内容。
在Subtype域中的下列比特格式应该被用来作为TBCPTalkBurst占用信息:
-00010,当不期望得到确认消息,和:
-10010,当发送TalkBurst占用消息的发送方期望得到一个确认消息。
在应用相关的数据中,TBCPTalkBurst占用消息应该携带两个SDES条款,条款的名字为CNAME和NAME,用来指明被允许发送TalkBurst客户的身份,因此包的长度将随着SDES条款的大小而改变。
CNAME标识应该是允许发送TalkBurst的PoC用户的URI,而NAME因该是该用户的昵称。
SDES条款和正确的URI和昵称的编码在[RFC3550]中规定。
SSRC域应该携带完成控制功能的PoC服务器的SSRC信息。
·TBCPTalkBurstRevoke——服务器撤销客户端的发言权
表7“TBCPTalkBurst撤销消息”显示了消息的内容。
在Subtype域中的下列比特格式应该被用来作为TBCPTalkBurst占用信息:00110。
应用相关的数据域应该携带在原因代码域表明的原因,表示因为什么完成控制功能的PoC服务器想要这个PoC客户停止发送TalkBurst。在附加消息域可以携带附加的信息,因此包的长度可以随着原因代码域的值而改变。
SSRC域应该携带完成控制功能的PoC服务器的SSRC信息。
·TBCPTalkBurstAcknowledgement——客户端给服务器端的确认消息
表8“TBCPTalkBurst确认”显示了消息的内容。
在Subtype域中的下列比特格式应该被用来作为TBCPTalkBurst占用信息:00111。
应用相关数据包含一或二个定义的子域:subtype和紧随其后的11比特原因代码域,最后是16比特的填充位。如果原因代码域没有使用,相应的域应该按照6.4.1’RTCP:APP消息格式’节中的规定,用填充比特填充。几个环节的消息控制流程如下:
1.连接
客户端A向服务器发送连接请求CONNECT;服务器向目标客户端B转发CONNECT请求;客户端B向服务器回复ACK;服务器向客户端A回复ACK;服务器分别向客户端A发送GRANT分配媒体数据通道,向客户端B发送TAKEN通知媒体数据通道被占用。
2.断开连接
客户端A向服务器发送连接请求DISCONNECT;服务器向目标客户端B转发DISCONNECT请求;客户端B向服务器回复ACK;服务器向客户端A回复ACK。
3.请求发言
在已经连接的状态下,客户端A向服务器发送连接请求REQUEST;服务器分别向客户端A发送GRANT分配媒体数据通道,向客户端B发送TAKEN通知媒体数据通道被占用。
4.结束发言
客户端A向服务器发送连接请求RELEASE;服务器向客户端A和B发送IDLE释放通道占用。
PoC客户端和控制功能的服务器都应支持RTCP。
还包括了媒体传输格式,将每20ms产生的一个音频包进行组合,把每8个包内的数据组成一个新的RTP包发送出去,这样在不影响用户体验的情况下最大程度减少数据冗余,减小延时。
由上可见,本发明提供的一种新的按键通话(PoC)实现方式,有以下优点。
(1)会话协商建立时间短
这里使用的经过修改的RTCP协议进行会话协商,交互数据量少,协议简洁明了,对所需的消息都有完整的定义,因此使用清晰便于控制,避免了使用SIP协议信令数据太长,会话协商延时的问题。
(2)提高带宽利用率
通过降低发送音频流的频率,加大每次发送包的大小来达到最佳的网络带宽使用率。
通过以上的方法实施例的描述,所属领域的技术人员可以清楚地了解到本发明可借助软件的方式来实现,按照上文具体实施方式中的定义数据格式和消息流程可以很容易实现,。
另外,所描述系统和方法以及不同实施例的示意图,在不超出本申请的范围内,可以与其它系统,模块,技术或方法结合或集成。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
以上所述仅是本发明的具体实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。
Claims (8)
1.一种基于RTCP的使用RTP协议作为媒体流传输的协议的系统,其特征在于,包括:
两个PoC客户端和PoC服务器;
两个所述PoC客户端和所述PoC服务器为使用封装好的RTCP协议进行扩展来代替SIP协议控制会话状态,使用RTCP协议作为控制信号传输的协议,使用RTP协议作为媒体流传输的协议,RTCP是发言权控制协议,是基于RTCP应用包(RTCP:APP),与其他的RTCP包发送到相同的UDP端口;
定义的RTCP信号包括CONNECT,DISCONNECT,ACK(Acknowledgement),GRANTED,REQUEST,RELEASE,IDLE;
所述PoC客户端,用于最终用户使用,手机终端中的PoC软件通过移动通讯网络的分组域连接,注册使用SIP消息在服务器中注册,移动通讯网络分组域连接为了节约资源,防止没有数据的空连接太多都设置了连接时长限制,在预置时间内,如果没有数据传输就会断开连接,所以PoC客户端的所述PoC软件在注册成功后为了维持连接需要发送心跳消息,心跳消息是通过RTP和RTCP消息发送,发送IDLE消息,根据用户的操作发起对PoC联系人的按键通话操作,发起呼叫的主叫方通过RTCP的格式和通道,把RTCP包的APP字段特殊定义成204,subtype字段定义成不同的会话控制请求类型,把NAME定义成PoC1,使得整个会话协商功能的包就完成了,通过RTCP通道发送,并通过接受RTCP通道的消息来完成会话协商;
所述PoC服务器,用于对两个PoC客户端服务,支撑PoC业务的使用;
其中,所述RTCP协议定义的控制TBCP消息包括:
TBCPTalkBurstRequest(TBCPTalkBurst请求消息),用于PoC客户端向PoC服务器请求发言权允许;
TBCPTalkBurstGranted(TBCPTalkBurst允许消息),用于PoC服务器通知PoC客户端允许其讲话;
TBCPTalkBurstRelease(TBCPTalkBurst释放消息),用于PoC客户端通知PoC服务器讲话结束;
TBCPTalkBurstIdle(TBCPTalkBurst空闲消息),用于PoC服务器通知PoC客户端现在空闲,并发送发言权请求;
TBCPTalkBurstTaken(TBCPTalkBurst占用消息),用于PoC服务器通知所有PoC客户端,使得被分配发言权的除外的所有PoC客户端的发言权被分配;
TBCPTalkBurstRevoke(TBCPTalkBurst撤销消息),用于PoC服务器撤销PoC客户端的发言权;
TBCPTalkBurstAcknowledgement(TBCPTalkBurst确认消息),用于PoC客户端给PoC服务器的确认消息。
2.根据权利要求1所述的基于RTCP的使用RTP协议作为媒体流传输的协议的系统,其特征在于,在Subtype域中的下列比特格式被用来作为TBCPTalkBurst请求信息:00000;
SSRC域携带申请发言权的用户的SSRC值,在TBCPTalkBurst请求消息中包含一个或多个可选域,每个TBCPTalkBurst请求消息可选域至少包含三个子域;
第一个子域是可选ID子域,第一个子域用于标识选来作为8-bit可选ID的选项;
第二个子域是可选长度子域,第二个子域由一个字节组成,说明整个可选域的长度,第二个子域的值等于可选ID子域、可选长度子域和可选值子域字节数的总和;
第三个子域是可选值子域,第三个子域包含一个字节数的整数值。
3.根据权利要求1所述的基于RTCP的使用RTP协议作为媒体流传输的协议的系统,其特征在于,在Subtype域中的下列比特格式被用来作为TBCPTalkBurst拒绝信息:00011,TBCPTalkBurst拒绝消息中的应用相关的数据包含了用原因代码表示拒绝的原因,并且在原因短语域紧跟一个文本,描述请求被拒绝的原因;
SSRC域携带完成控制功能的PoC服务器的SSRC信息,在应用相关的数据中的最先8比特是用来作为原因代码域;
长度子域给出了原因短语的字节长度,如果长度子域的值被设为0,表示在原因短语中没有原因,原因短语域中包含具有附加短语的字符串,这个字符串为在SDES条款CNAME中一样的编码。
4.根据权利要求1所述的基于RTCP的使用RTP协议作为媒体流传输的协议的系统,其特征在于,
在Subtype域中的下列比特格式被用来作为TBCPTalkBurst释放信息:00100,与应用相关的数据域由4个字节组成;
前16个比特表示了在TalkBurst序列中最后一个RTP媒体包的序列号;
比特16是忽略序列号域,值为0是序列号有效,为1时序列号无效;
在应用相关数据中的最后15个比特是填充比特,全部设为0。
5.根据权利要求1所述的基于RTCP的使用RTP协议作为媒体流传输的协议的系统,其特征在于,在Subtype域中的下列比特格式被用来作为TBCPTalkBurst空闲信息:00101;
TBCPTalkBurst空闲消息包含12字节的包头信息,长度域设为2;
SSRC域携带完成控制功能的PoC服务器的SSRC信息。
6.根据权利要求1所述的基于RTCP的使用RTP协议作为媒体流传输的协议的系统,其特征在于,
在Subtype域中的下列比特格式被用来作为TBCPTalkBurst占用信息:-00010,当不期望得到确认消息,和-10010,当发送TalkBurst占用消息的发送方期望得到一个确认消息;
在应用相关的数据中,TBCPTalkBurst占用消息携带两个SDES条款,条款的名字分别为CNAME和NAME,用来指明被允许发送TalkBurst客户的身份,包的长度将随着SDES条款的大小而改变;
CNAME标识是允许发送TalkBurst的PoC用户的URI,而NAME是该用户的昵称;
SDES条款和正确的URI和昵称的编码在RFC3550中规定;
SSRC域携带完成控制功能的PoC服务器的SSRC信息。
7.根据权利要求1所述的基于RTCP的使用RTP协议作为媒体流传输的协议的系统,其特征在于,
在Subtype域中的下列比特格式被用来作为TBCPTalkBurst占用信息:00110;
应用相关的数据域携带在原因代码域表明的原因,表示完成控制功能的PoC服务器想要这个PoC客户停止发送TalkBurst的原因;
SSRC域携带完成控制功能的PoC服务器的SSRC信息。
8.根据权利要求1所述的基于RTCP的使用RTP协议作为媒体流传输的协议的系统,其特征在于,
在Subtype域中的下列比特格式被用来作为TBCPTalkBurst占用信息:00111;
应用相关数据包含一或二个定义的子域,为subtype域和紧随其后的11比特原因代码域,最后是16比特的填充位,如果原因代码域没有使用,则用填充比特填充。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201110282500.5A CN103024681B (zh) | 2011-09-20 | 2011-09-20 | 一种高效的按键通话方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201110282500.5A CN103024681B (zh) | 2011-09-20 | 2011-09-20 | 一种高效的按键通话方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN103024681A CN103024681A (zh) | 2013-04-03 |
CN103024681B true CN103024681B (zh) | 2016-05-11 |
Family
ID=47972721
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201110282500.5A Active CN103024681B (zh) | 2011-09-20 | 2011-09-20 | 一种高效的按键通话方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN103024681B (zh) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103634746B (zh) * | 2013-12-13 | 2017-05-17 | 中国人民解放军重庆通信学院 | 一种保持PoC持续连接处理能力的方法和装置 |
CN109889997B (zh) * | 2019-04-26 | 2021-08-20 | 福建科立讯通信有限公司 | 一种实现dmr或pdt对讲机个呼的功率自动控制方法 |
RU2755529C1 (ru) * | 2021-02-01 | 2021-09-17 | Даурен Муратович Айдарханов | Способ установления сеанса групповой пакетной голосовой связи по сетям передачи данных |
CN116631456A (zh) * | 2023-07-21 | 2023-08-22 | 江西红声技术有限公司 | 一种声控通讯处理方法、耳机、存储介质及计算机 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1863340A (zh) * | 2005-12-01 | 2006-11-15 | 华为技术有限公司 | 一种PoC会话中的发言权控制方法 |
CN101394363A (zh) * | 2008-11-10 | 2009-03-25 | 北京佳讯飞鸿电气股份有限公司 | 一种rtcp通信的实现方法 |
CN101562898A (zh) * | 2008-04-16 | 2009-10-21 | 北京信威通信技术股份有限公司 | 一种高效的无线接入系统rtp代理技术 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR100667000B1 (ko) * | 2006-02-17 | 2007-01-10 | 삼성전자주식회사 | 데이터의 전송 대상을 선택적으로 지정하는 pta 서비스시스템 및 그 방법 |
-
2011
- 2011-09-20 CN CN201110282500.5A patent/CN103024681B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1863340A (zh) * | 2005-12-01 | 2006-11-15 | 华为技术有限公司 | 一种PoC会话中的发言权控制方法 |
CN101562898A (zh) * | 2008-04-16 | 2009-10-21 | 北京信威通信技术股份有限公司 | 一种高效的无线接入系统rtp代理技术 |
CN101394363A (zh) * | 2008-11-10 | 2009-03-25 | 北京佳讯飞鸿电气股份有限公司 | 一种rtcp通信的实现方法 |
Also Published As
Publication number | Publication date |
---|---|
CN103024681A (zh) | 2013-04-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7359725B2 (en) | Push-to-talk apparatus and method for communication between an application server and media resource function processor | |
KR101008698B1 (ko) | 멀티미디어 세션을 위한 서비스 품질 파라미터의 시그널링 | |
CN101473616B (zh) | 用于可靠地传递多播数据的方法和装置 | |
US9088909B2 (en) | System for transmitting streaming media content to wireless subscriber stations | |
US20060034260A1 (en) | Interoperability for wireless user devices with different speech processing formats | |
EP1708392B1 (en) | Apparatus and method for delivering a stream in a mobile broadcast system | |
MX2010012735A (es) | Metodo y sistema para proporcionar una interfase de satelite para soporte de servicios de comunicaciones moviles. | |
CN101212316A (zh) | 一种多方会话中基于媒体流计费的方法及系统 | |
CN103024681B (zh) | 一种高效的按键通话方法 | |
CN101364998A (zh) | 一种ims实现方法、装置和系统 | |
US20070133527A1 (en) | Communication of data to communication devices | |
EP2765736B1 (en) | Methods and devices for processing media data packets and corresponding conference system | |
CN100417245C (zh) | 基于VoIP技术的“一键通”业务实现系统及方法 | |
CN102801725B (zh) | Sip音视频会议中进行音视频媒体传输的方法 | |
CN1917672A (zh) | 数字集群系统的讲话权控制方法及通信方法 | |
CN105262744B (zh) | 一种多媒体调度系统中实现媒体端口复用的方法 | |
WO2018076376A1 (zh) | 一种语音数据传输方法、用户设备以及存储介质 | |
CN101594623B (zh) | 一种互联网协议语音呼叫的监听方法及设备 | |
CN101150538A (zh) | 一种收发即时多媒体信息的方法和装置 | |
CN100446602C (zh) | 一种传输手机按键信息的方法 | |
CN102244841A (zh) | 语音交互处理方法、装置和系统 | |
CN101119212B (zh) | 通过信令适配实体传输isdn用户-用户应用信息的方法 | |
CN101258717B (zh) | 媒体网关系统与实现媒体网关内部呼叫的方法 | |
CN102185828B (zh) | 一种pc软件与sip ua绑定及控制的方法 | |
CN101132392A (zh) | 一种单独载频广播架构及其实现业务传送的方法 |
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 | ||
CP03 | Change of name, title or address | ||
CP03 | Change of name, title or address |
Address after: Room 306, area 2, building 1, Fanshan Venture Center, Panyu energy saving science and Technology Park, 832 Yingbin Road, Donghuan street, Panyu District, Guangzhou, Guangdong 510000 Patentee after: Jiadu Technology Group Co.,Ltd. Address before: No.4, Jiangong Road, Tianhe Software Park, Guangzhou, Guangdong 510665 Patentee before: PCI-SUNTEKTECH Co.,Ltd. |