CN101917409B - 一种多媒体流的传输方法及系统 - Google Patents

一种多媒体流的传输方法及系统 Download PDF

Info

Publication number
CN101917409B
CN101917409B CN 201010235845 CN201010235845A CN101917409B CN 101917409 B CN101917409 B CN 101917409B CN 201010235845 CN201010235845 CN 201010235845 CN 201010235845 A CN201010235845 A CN 201010235845A CN 101917409 B CN101917409 B CN 101917409B
Authority
CN
China
Prior art keywords
port
server
calling terminal
called end
media stream
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
Application number
CN 201010235845
Other languages
English (en)
Other versions
CN101917409A (zh
Inventor
邝翠珊
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shenzhen black hole Optical Technology Co., Ltd
Original Assignee
SHENZHEN YUEHETONG TECHNOLOGY Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by SHENZHEN YUEHETONG TECHNOLOGY Co Ltd filed Critical SHENZHEN YUEHETONG TECHNOLOGY Co Ltd
Priority to CN 201010235845 priority Critical patent/CN101917409B/zh
Publication of CN101917409A publication Critical patent/CN101917409A/zh
Application granted granted Critical
Publication of CN101917409B publication Critical patent/CN101917409B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Abstract

本发明涉及一种多媒体流传输方法,包括如下步骤:通过所述主叫端发来的信令、被叫端接收到经所述服务器转发的信令后发出的回应、设置在所述服务器上的端口匹配表得到主叫端传送多媒体流端口号、被叫端传送多媒体流端口号以及位于所述服务器上的分别与所述主叫端传送多媒体流端口对应的第一端口号和与所述被叫端传送多媒体流端口对应的第二端口号;在所述第一端口和第二端口之间转发接收到的多媒体流。本发明还涉及一种多媒体流传输系统。实施本发明所述的一种多媒体流传输方法及系统,具有以下有益效果:其占用内核资源较少,转发速度较快。

Description

一种多媒体流的传输方法及系统
技术领域
本发明涉及数据传输领域,更为具体地说,涉及一种多媒体流的传输方法及系统。
背景技术
SIP(Session Initiation Protocol,会话启动协议)是一个应用层的信令控制协议,用于创建、修改和释放一个或多个参与者的会话。这些会话可以是Internet多媒体会议、IP电话或多媒体分发。SIP中包括UAS、UAC以及转发上述UAC和UAS之间的数据流的代理服务器(Proxy server),SIP代理服务器是处理与多个呼叫相关联信令的网络设备;UAS和UAC允许点到点的呼叫通过客户机-服务器协议来完成。当一用户希望呼叫另一用户,呼叫者用INVITE请求初始呼叫,该请求包含足够的信息用以被呼叫方参与会话。该服务器回复上述呼叫者并将请求转发被叫者,在最简单的情况下,被叫者回复上述服务器,在上述信令交互的过程中,服务器确认呼叫者(UAC、主叫端)、被叫者(UAS、被叫端)以及上述服务器本身的用于传输多媒体流的地址及端口,然后在上述UAS、UAC及服务器之间开始传输多媒体流。在上述传输中,上述服务器使用套接字(Socket)从UAC的地址及指定端口取得多媒体流并转发到UAS的地址及指定端口中。但是这种转发方式设计较多的服务器操作系统内核资源,在多个会话并发时,会降低服务器的处理效率,使得传输速度下降。
发明内容
本发明要解决的技术问题在于,针对现有技术的上述占用系统内核资源多、在多个会话并发时传输速度慢的缺陷,提供一种占用系统内核资源少、在多个会话并发时传输速度较快的一种多媒体流的传输方法及系统。
本发明解决其技术问题所采用的技术方案是:构造一种多媒体流传输方法,包括如下步骤:
A)主叫端通过默认的SIP信令端口发送请求到服务器;
B)通过所述主叫端发来的信令及被叫端接收到经所述服务器转发的信令后发出的回应或通过所述主叫端发来的信令、被叫端接收到经所述服务器转发的信令后发出的回应以及设置在所述服务器上的端口匹配表得到主叫端传送多媒体流端口号、被叫端传送多媒体流端口号以及位于所述服务器上的分别与所述主叫端传送多媒体流端口对应的第一端口号和与所述被叫端传送多媒体流端口对应的第二端口号;
C)在所述第一端口和第二端口之间转发接收到的多媒体流。在本发明所述的多媒体流传输方法中,所述步骤B)进一步包括如下步骤:
B1)服务器通过默认的SIP信令端口接收所述主叫端发出的请求,得到所述主叫端地址及主叫端多媒体流传输端口号,并查找所述请求中包含的被叫端对应的第二端口号;
B2)所述服务器通过默认的SIP端口转发请求到所述被叫端,并接收所述被叫端通过默认的SIP信令端口的回应;
B3)由所述回应取得所述被叫端的地址及所述被叫端传输多媒体流的端口号,并查找得到与所述主叫端对应的第一端口号。
在本发明所述的多媒体流传输方法中,所述步骤B1)进一步包括如下步骤:
B11)通过所述请求中的SDP信息取得所述主叫端的IP地址和主叫端多媒体流传输端口号;
B12)通过查找可用端口得到所述第二端口号。
在本发明所述的多媒体流传输方法中,所述步骤B3)进一步包括如下步骤:
B31)通过所述被叫端回应中的SDP信息取得所述被叫端的IP地址和被叫端多媒体流传输端口号;
B32)通过查找可用端口得到所述第一端口号。
在本发明所述的多媒体流传输方法中,所述步骤B11)中的请求为SIP会话中的INVITE请求;所述步骤B31)中的回应为SIP会话中的200OK信令。
在本发明所述的多媒体流传输方法中,所述步骤B)进一步包括如下步骤:
B1′)服务器通过默认的SIP信令端口接收所述主叫端发出的请求,得到所述主叫端地址及主叫端多媒体流传输端口号,并查找所述请求中包含的被叫端对应的第二端口号;并通过所述端口匹配表得到与所述第二端口匹配的第二端口号;
B2′)所述服务器通过默认的SIP端口转发请求到所述被叫端,并接收所述被叫端通过默认的SIP信令端口的回应;
B3′)由所述回应取得所述被叫端的地址及所述被叫端传输多媒体流的端口号。
在本发明所述的多媒体流传输方法中,所述步骤C)进一步包括:
C1)通过所述第二端口转发所述第一端口接收到的多媒体流到所述被叫端;
C2)通过所述第一端口转发所述第二端口接收到的多媒体流到所述主叫端。
在本发明所述的多媒体流传输方法中,所述步骤C1)和步骤C2)中均通过配置NETFILTER转发路径转发所述多媒体流。
在本发明所述的多媒体流传输方法中,所述步骤C1)和步骤C2)中配置的转发路径在本次会话中维持有效;所述服务器在接收到所述主叫端或被叫端任意一方发出的CANCEL/BYE信令并将其转发所述被叫端或主叫端后,清除所述转发路径将所述端口重新写入所述端口匹配表中。
本发明还涉及一种多媒体流传输系统,在本发明所述的多媒体流传输系统中,包括主叫端、被叫端以及连接所述主叫端和所述被叫端、并在所述主叫端和被叫端之间转发其各自发出的多媒体流的服务器,所述服务器还包括在传输多媒体流时分别与所述主叫端连接的第一端口和与所述被叫端连接的第二端口、取得所述主叫端和被叫端地址及传输多媒体流端口号的地址取得装置以及确定所述服务器第一端口号及第二端口号的端口取得装置。
实施本发明所述的一种多媒体流的传输方法及系统,具有以下有益效果:由于在转发多媒体流时,将在服务器中将主叫端发出的多媒体流的目的地址和源地址分别转换为被叫端的地址和服务器地址,而且该过程使用内核中的NETFILTER架构而不是使用套接字(SOCKET)实现转发,所以其占用内核资源较少,在会话并发时转发速度较快。
附图说明
图1是本发明一种多媒体流的传输方法及系统第一实施例中系统结构示意图;
图2是所述实施例中多媒体流传输方法的流程图;
图3是所述实施例中系统服务器的结构示意图。
具体实施方式
下面将结合附图对本发明实施例作进一步说明。
如图1所示,在本发明一种多媒体流的传输方法及系统第一实施例中,该系统包括主叫端11、服务器12、被叫端13;其中,主叫端11包括主叫端多媒体流传输端口14,服务器12包括第一端口15、第二端口16,被叫端13包括被叫端口多媒体流传输端17;在上述主叫端11和被叫端13通过服务器12建立连接并传输多媒体流时,上述主叫端11通过其多媒体流传输端口14与服务器12的第一端口15与服务器12连接;被叫端13通过被叫多媒体流传输端口17和服务器12的第二端口16与服务器12连接。在主叫端11和被叫端13没有传输多媒体流时,上述端口之间并没有连接。而主叫端11在建立连接时,通过主叫端11的默认SIP端口与服务器12之间传送SIP信令,服务器12通过其默认的SIP端口与被叫端13传送SIP信令,而被叫端13同样通过其默认的SIP端口向服务器12传送SIP信令,一般来讲,上述默认端口通常是其设备本身的5060端口(当然,也可以是别的指定端口)。在本实施例中,上述系统是SIP。一般而言,SIP(Session Initiation Protocol,会话启动协议)中包括了两个要素,SIP用户代理和SIP网络服务器;SIP用户代理包括UAC(User Agent Client,用户代理客户端,即本实施例中所述的主叫端11)和UAS(User Agent Server,用户代理服务器,即本实施例中所述的被叫端13),上述UAC和UAS都是网络终端;而SIP服务器是处理与多个呼叫相关联信令的网络设备,在本实施例中,上述SIP服务器用于转发数据流的代理服务器(Proxy Server);一般来讲,UAC发起初始呼叫而UAS应答呼叫,而SIP服务器(即本实施例中所述的服务器12)转发上述呼叫与回应。一般而言,在一个呼叫(或会话)中,上述的UAC和UAS是不会转变的,即一个终端发起呼叫,那它在这次呼叫中就是UAC,被其呼叫的终端是UAS;而在不同的呼叫中,上述UAC、UAS的角色是可以转换的,例如,一个终端在上次呼叫时为UAC,在本次呼叫时可以是UAS;在请求连接时是UAC,在挂断时可能是UAS。也就是说,一个终端可以是UAS,也可以是UAC,要视具体的情况而定。在本实施例中,发起呼叫的主叫端11(即UAC)通过服务器12(在本实施例中,该服务器为SIP服务器,Proxy Server)与被叫端13(即UAS)建立连接并传送多媒体流,其过程在稍后有详细描述。
通常,UAC与UAS建立连接的过程中会出现多次UAC、代理服务器以及UAS之间的信息交互(即信令传送及应答,稍后有描述),而在该过程中,涉及SDP(会话描述协议)的信息中携带有UAS、UAC的信息,这些信息包括IP地址、端口号以及所要传输的多媒体类型等等,在上述建立连接的过程中,SIP代理服务器可以通过提取上述信息交换的内容取得上述信息。在本实施例中,上述信息交互是通过UAC、UAS以及服务器上的默认的SIP信令端口进行的,通常该端口的端口号是5060,在UAC、UAS以及服务器上系统开始工作时,其自身的5060端口就被配置为SIP信令传输使用。
在本实施例中,在上述的呼叫与多媒体流传输过程中,上述UAC不知道UAS的地址,UAC也不需要知道UAS的网络地址,UAC只需要知道与其连接的SIP服务器(在本实施例中,是SIP代理服务器,即Proxy Server)地址即可;同样,UAS在应答及传输多媒体流的过程中,也不需要知道UAC的网络地址,只要其知道与其连接的SIP服务器(即Proxy Server)的网络地址即可。
在本实施例中,如图2所示,上述UAC通过代理服务器与UAS建立连接并传输多媒体流的具体步骤如下:
步骤S201UAC发送INVITE请求到服务器:在本实施例中,UAC希望与UAS建立连接,但是,UAC不知道UAS的IP地址,只知道SIP服务器的IP地址,于是,UAC产生一个INVITE请求,并通过其上述默认端口(即UAC的5060端口)发送该请求到服务器(即服务器的5060端口)。在该请求的文件头中,包括了UAS的SIP链接;在该请求中,包括了一个SDP(Session DescriptionProtocol)信息,该信息包括了一些需要被填充的、关于被叫端UAS的参数(包括代码、IP地址、端口等)。
步骤S202服务器回复上述UAC:服务器通过上述默认端口5060收到上述INVITE请求后,同样通过默认端口5060发送信令“100Trying”到上述UAC;在接收到上述INVITE请求的时候,上述服务器取出在该请求中的SDP信息,也就是说,在本步骤中,服务器取得UAC(主叫端11)的IP地址及其传输多媒体流的端口号(该端口并非上述SIP信令默认端口),以及在这个INVITE包的SDP有相关的media地址,codec,port信息等。此外,在本实施例中上述默认端口时5060,在其他实施例中,也可以是其他的SIP指定(或默认)端口。
步骤S203服务器转发INVITE请求到UAS:在上述服务器通过SIP信令默认端口5060回复UAC的同时,服务器还将上述INVITE请求同样通过SIP信令默认端口5060转发到目的地,同时,服务器在本步骤中需要执行一个查找可用端口操作,查找本地数据,找到可以与上述目的地(即UAS)的多媒体流传输端口连接的第二端口,并得到上述第二端口的端口号;在本步骤中,还将上述取得的第二端口的端口号作为SIP中的SDP信息的一部分加入INVITE请求,一起通过上述SIP默认端口5060转发到UAS,使UAS得知自己的多媒体流将传输到上述服务器的那个端口。
步骤S204UAS回复振铃信令到上述服务器:当被叫端UAS接收到上述INVITE请求后,通过SIP信令默认端口5060发送信令“180Ringing”到上述服务器;同样地,UAS也是由上述INVITE请求中的SDP信息取得服务器IP地址及上述第二端口的端口号。
步骤S205服务器转发收到的振铃信令到UAC:服务器通过SIP信令默认端口5060转发上述由UAS发出的信令“180Ringing”到UAC。
步骤S206UAS回复接受信令到上述服务器:如果UAS接收呼叫,同意建立会话,则通过SIP信令默认端口5060发送信令“200OK”到上述服务器,在上述信令“200OK”中,包括了SDP信息,于是,在本步骤中,服务器取得上述SDP信息中包含的UAS的IP地址以及UAS(被叫端)传输多媒体流端口的端口号。
步骤S207服务器转发收到的接受信令到UAC:服务器通过SIP信令默认端口5060转发上述信令“200OK”到主叫端UAC;在本步骤中,服务器同样要执行查找可用端口的动作,找出与上述的UAC连接的第一端口的端口号。
步骤S208UAC回复确认信令到服务器:当UAC接收到上述信令“200OK”,后通过SIP信令默认端口5060发送确认信令,即信令“ACK”到上述服务器。
步骤S209服务器转发确认信令到UAS,建立UAC与UAS之间的连接。
通过上述步骤,实现了UAC和UAS通过服务器的连接。同时,由于上述过程中的INVITE及200OK中都携带有SDP,而SDP信息则包括了多媒体数据流的收发地址、端口以及媒体格式等等,所以,上述通过SIP默认信令端口的信息交互过程中实现了参数的取得;这些参数包括:UAS主叫端的IP地址及其多媒体流传输端口号、UAC被叫端的IP地址及其多媒体流传输端口号、服务器上与上述主叫端多媒体流传输端口对应的第一端口号以及服务器上与上述被叫端多媒体流传输端口对应的第一端口号。在进行上述步骤之后,对于服务器而言,已经完全取得在上述UAC和UAS之间传送多媒体流时所需要的路径参数。因此,在上述步骤实施后,服务器配置上述第一端口和第二端口之间的NETFILTER架构的转发路径。当上述第一端口或第二端口接收到多媒体流数据时,通过上述NETFILTER架构的转发机制分别将多媒体流转发到上述第二端口或第一端口,实现多媒体流的转发。也就是说,当第一端口接收到多媒体流时,将其通过NETFILTER架构中配置好的转发机制转发到第二端口;而当第二端口接收到多媒体流时,同样通过配置好的NETFILTER架构的转发机制转发到第二端口。值得一提的是,在本实施例中,UAC通过SIP信令默认端口在SIP信令中的SDP部分将自己的传输多媒体流的端口和地址通知服务器;当服务器转发信令到UAS的时候,服务器通知UAS,服务器发送媒体流到UAS的地址和传输多媒体流的端口(即第二端口),UAS返回其地址和传输多媒体流的端口给服务器;服务器在转发UAS回复信令给UAC时,通知UAC服务器地址及服务器与上述UAC传输多媒体流的端口对应的第一端口。于是,服务器依据上述得到的各端口和地址配置多媒体流通道(即转发路径),将一边端口接收到的多媒体流传送到另一端口(相当于在服务器的两个传输多媒体流的端口之间提供一个虚拟的连接,即在上述第一端口和第二端口之间建立连接)。此外,在本实施例中,上述对NETFILTER的转发路径的配置是使用上述各步骤中取得的参数,通过对NETFILTER架构中的NAT转发机制来实现的,一旦上述转发路径配置,在本次会话传输多媒体流中都维持有效。即在本次会话中,通过上述端口接收到的多媒体流将直接转发到对应端口,进而达到其目的地。在上述主叫端或被叫端中的任意一个通过上述SIP默认信令端口发出cancel/Bye信令,且被服务器转发到对端时,上述转发路径被清除,服务器的第一端口和第二端口被释放。
在本实施例中,还揭示了一种实现多媒体流传输的系统,该系统的结构参见图1和图3。在本实施中,该多媒体传输系统包括主叫端11、被叫端13以及连接主叫端11和被叫端13、并在主叫端11和被叫端13之间转发其各自发出的多媒体流的服务器12,服务器12还包括在传输多媒体流时分别与主叫端11连接的第一端口15和与被叫端13连接的第二端口16,同时,服务器12还分别通过SIP默认的信令传输端口(在本实施例中,是端口5060)与上述主叫端11和被叫端13传输SIP信令;此外,服务器12还包括地址取得装置32,该地址取得装置32用于取得主叫端11和被叫端13的IP地址及其传输多媒体流的端口号;端口取得装置31,该端口取得装置用于确定上述服务器12的第一端口15的端口号及第二端口16的端口号。由于在本实施例中上述第一端口号和第二端口号是通过在上述服务器12上查找可用端口的动作来实现的,因此,上述端口取得装置31还包括通过在服务器12上查找可用端口来取得上述第一端口号和第二端口号的可用端口查找单元311。在本实施例中,多媒体流是通过NETFILTER架构中的转发机制来实现的,一般而言,NETFILTER中的转发机制是存在的,但是,还是需要将正确的参数设置好才能将数据转发到需要的位置,在本实施例中,上述服务器12还包括用于配置上述服务器12操作系统内核中NETFILTER架构转发路径的转发路径配置装置33,该转发路径配置装置33使用在上述步骤中取得的UAC、UAS以及服务器的参数,通过对NETFILTER架构中的NAT转发机制的配置,使得多媒体流不管由UAC发出,还是由UAS发出,都能正确、快捷地被转发到设定的位置。
在本发明的第二实施例中,除了取得上述第一端口15和第二端口16的端口号的过程与上述第一实施不同之外,其余步骤基本上与上述第一实施例相同。在第二实施例中,当使用与第一实施例中基本相同的方法取得上述第二端口16的端口号时,通过遍历事先存储在服务器上的端口匹配表找到与上述第二端口16匹配的端口,将其直接设置为第一端口15,之后的步骤中,不再通过查找可用端口来确定第一端口15。这样的端口查找使得只需要查找一次即可确定两个端口,节省了端口查找的时间。当然,在第二实施例中,要求事先将服务器上的可用端口两两设置为匹配端口存储在服务器上的表中,当需要查找可用端口时,只需查找一次,即可得到两个事先配对的可用端口。这种端口匹配的端口号可以是随意的,也可以是用户设定的。当上述多媒体流传输完成后,上述端口被释放,这两个端口被由上述端口匹配表的一端(与端口开始遍历的一端相反)加入到该表中,在多数情况下,上述两个端口依然是一对。
具体而言,在第二实施例中,首先,服务器会配置了一个端口对应表,这个对应表预先将服务器中的端口分为第一端口15和第二端口16并预先配好对,例如:端口1000为第一端口15与端口1001为第二端口16为一对,端口1002为第一端口15与端口1003为第二端口16为一对,端口1004为第一端口15与端口1005为第二端口16为一对,等等;这里的对应可以是随机的,只要端口不重复就可以了。在服务器里面,会实现一个队列(表),将上述所有“可以用的端口对”保存。上述队列或表在使用时遵循先进后出的规则,要用的时候,从其一端取的端口对,用完之后放回到上述队列的另外一端。这样服务器就可以快速查找端口。当主叫端通过默认的SIP信令端口发送请求到上述服务器时,服务器从收到主叫发来的请求中得到主叫将会用在做媒体流交互的地址和端口;服务器从上述“可用端口队列”一端取出一对可以用的端口;在服务器把上述信令转发给被叫端的时候,会把上述取出的“端口对”中的“对应被叫端口”之信息放到发给被叫的INVITE的SDP里。当被叫端回复上述服务器发来的信令时,被叫端回复给服务器的200OK信令里面的SDP会附带上被叫端将会用来收发媒体流的地址及端口。这样,被叫与服务器之间互相都知道对方的媒体流端口,在他们之间就可以进行媒体流通信。当服务器再把上述200OK信令转发给主叫端时,该信令中的SDP里的端口则是之前取出的“端口对”中的“对应主叫端口”即上述第一端口15的信息。主叫端收到后,主叫端和服务器之间就知道大家互相的对应端口,可以做媒体流交互。于是上述过程之后得到整个多媒体流传输路径的参数,服务器就可以把一边收到的媒体流转到另外一边。
在上述通话(或多媒体流传输)结束时,或任何一方发送BYE或CANCEL信令来结束通话后,服务器就会把上述取出的“端口对”放回取“可用端口队列”之中。
以上所述实施例仅表达了本发明的几种实施方式,其描述较为具体和详细,但并不能因此而理解为对本发明专利范围的限制。应当指出的是,对于本领域的普通技术人员来说,在不脱离本发明构思的前提下,还可以做出若干变形和改进,这些都属于本发明的保护范围。因此,本发明专利的保护范围应以所附权利要求为准。

Claims (7)

1.一种多媒体流的传输方法,其特征在于,包括如下步骤:
A)  主叫端通过默认的SIP信令端口发送请求到服务器;
B)  通过所述主叫端发来的信令及被叫端接收到经所述服务器转发的信令后发出的回应或通过所述主叫端发来的信令、被叫端接收到经所述服务器转发的信令后发出的回应以及设置在所述服务器上的端口匹配表得到主叫端传送多媒体流端口号、被叫端传送多媒体流端口号以及位于所述服务器上的分别与所述主叫端传送多媒体流端口对应的第一端口号和与所述被叫端传送多媒体流端口对应的第二端口号;
C)  在所述第一端口和第二端口之间转发接收到的多媒体流,依据上述步骤中取得的参数,通过配置所述第一端口和第二端口之间的NETFILTER转发路径,实现通过所述第二端口转发所述第一端口接收到的多媒体流到所述被叫端,通过所述第一端口转发所述第二端口接收到的多媒体流到所述主叫端;所述参数包括主叫端的IP地址及其多媒体流传输端口号、被叫端的IP地址及其多媒体流传输端口号、服务器上与上述主叫端多媒体流传输端口对应的第一端口号以及服务器上与上述被叫端多媒体流传输端口对应的第二端口号。
2.根据权利要求1所述的多媒体流的传输方法,其特征在于,所述步骤B)进一步包括:
B1)服务器通过默认的SIP信令端口接收所述主叫端发出的请求,得到所述主叫端地址及主叫端多媒体流传输端口号,并查找所述请求中包含的被叫端对应的第二端口号;
B2)所述服务器通过默认的SIP端口转发请求到所述被叫端,并接收所述被叫端通过默认的SIP信令端口的回应;
B3)由所述回应取得所述被叫端的地址及所述被叫端传输多媒体流的端口号,并查找得到与所述主叫端对应的第一端口号。
3.根据权利要求2所述的多媒体流的传输方法,其特征在于,所述步骤B1)进一步包括如下步骤:
B11)通过所述请求中的SDP信息取得所述主叫端的IP地址和主叫端多媒体流传输端口号;
B12)通过查找可用端口得到所述第二端口号。
4.根据权利要求3所述的多媒体流的传输方法,其特征在于,所述步骤B3)进一步包括如下步骤:
B31)通过所述被叫端回应中的SDP信息取得所述被叫端的IP地址和被叫端多媒体流传输端口号;
B32)通过查找可用端口得到所述第一端口号。
5.根据权利要求4所述的多媒体流的传输方法,其特征在于,所述步骤B11)中的请求为SIP会话中的INVITE请求;所述步骤B31)中的回应为SIP会话中的200 OK信令。
6.根据权利要求1所述的多媒体流的传输方法,其特征在于,所述步骤B)进一步包括如下步骤:
B1′)服务器通过默认的SIP信令端口接收所述主叫端发出的请求,得到所述主叫端地址及主叫端多媒体流传输端口号,并查找所述请求中包含的被叫端对应的第二端口号;并通过所述端口匹配表得到与所述第二端口匹配的第一端口号;
B2′)所述服务器通过默认的SIP端口转发请求到所述被叫端,并接收所述被叫端通过默认的SIP信令端口的回应;
B3′)由所述回应取得所述被叫端的地址及所述被叫端传输多媒体流的端口号。
7.根据权利要求1所述的多媒体流的传输方法,其特征在于,所述步骤C)中配置的转发路径在本次会话中维持有效;所述服务器在接收到所述主叫端或被叫端任意一方发出的CANCEL/BYE信令并将其转发所述被叫端或主叫端后,清除所述转发路径或将所述端口重新写入所述端口匹配表中。
CN 201010235845 2010-07-23 2010-07-23 一种多媒体流的传输方法及系统 Active CN101917409B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN 201010235845 CN101917409B (zh) 2010-07-23 2010-07-23 一种多媒体流的传输方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN 201010235845 CN101917409B (zh) 2010-07-23 2010-07-23 一种多媒体流的传输方法及系统

Publications (2)

Publication Number Publication Date
CN101917409A CN101917409A (zh) 2010-12-15
CN101917409B true CN101917409B (zh) 2013-04-24

Family

ID=43324795

Family Applications (1)

Application Number Title Priority Date Filing Date
CN 201010235845 Active CN101917409B (zh) 2010-07-23 2010-07-23 一种多媒体流的传输方法及系统

Country Status (1)

Country Link
CN (1) CN101917409B (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104519302B (zh) * 2014-12-25 2018-03-20 漳州顶竹通讯技术有限公司 一种视频信息实时共享与管控的系统及方法
WO2018000355A1 (zh) * 2016-06-30 2018-01-04 周肇梅 一种在系统内转发数据流的方法及系统
CN109510838B (zh) * 2018-12-20 2020-08-28 北京明朝万达科技股份有限公司 端口启动方法和装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1551569A (zh) * 2003-04-08 2004-12-01 Adv通讯公司 网络传输多媒体数据的方法
EP1515515A1 (en) * 2000-07-28 2005-03-16 Ridgeway Systems and Software Audio-video telephony with firewalls and network address translation
CN101212405A (zh) * 2006-12-29 2008-07-02 中国移动通信集团公司 媒体路由控制系统及控制方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1515515A1 (en) * 2000-07-28 2005-03-16 Ridgeway Systems and Software Audio-video telephony with firewalls and network address translation
CN1551569A (zh) * 2003-04-08 2004-12-01 Adv通讯公司 网络传输多媒体数据的方法
CN101212405A (zh) * 2006-12-29 2008-07-02 中国移动通信集团公司 媒体路由控制系统及控制方法

Also Published As

Publication number Publication date
CN101917409A (zh) 2010-12-15

Similar Documents

Publication Publication Date Title
US6992974B1 (en) System and method for providing fault tolerance in a network telephony system
JP5363461B2 (ja) グループ呼機能の問い合わせ
US8767590B2 (en) Multimedia conference system and method which enables communication between private network and internet
US9113030B2 (en) Multimedia-enhanced emergency call systems
EP2472984A1 (en) Method for realizing end-to-end call, end-to-end call terminal and system
JP2017510116A (ja) 第1のユーザが第2のユーザのソーシャル・ネットワーク識別子およびそれらのソーシャル・ネットワークにおけるこの第2のユーザのそれぞれのステータスを自動的に検出できるようにする方法およびサーバ
CN102571722A (zh) 融合通信系统及适用于该融合通信系统的多协议适配方法
RU2332804C2 (ru) Обработка начальных мультимедийных данных ii
EP1889416B1 (en) Shared IP multimedia resource reservation
JP2005129980A (ja) ネットワーク、構内交換機、無線lan端末及びそれに用いるマルチプロトコル通信端末制御方法
WO2016040624A1 (en) Teleconferencing system using synthetic identifiers
KR20090058610A (ko) 아이엠에스 기반 인스턴트 메시지 서비스 제공 시스템 및방법
RU2374777C2 (ru) Обработка начальных мультимедийных данных i
CN101917409B (zh) 一种多媒体流的传输方法及系统
KR100514196B1 (ko) 네트웍 어드레스 변환 및 세션 관리 시스템 및 그 방법
WO2011029335A1 (zh) 一种sip会话的路由系统及方法
EP3228057B1 (en) Ims application control protocol
CN101674297B (zh) 分布式业务网络、核心服务设备及协议报文处理方法
US8495225B2 (en) Methods and arrangements for a telecommunications system
KR20120100376A (ko) 에스아이피 메시지 송수신 시스템 및 방법
KR101080383B1 (ko) 브이오아이피 호설정 방법 및 이를 수행하는 브이오아이피 통신 시스템
CN101594623B (zh) 一种互联网协议语音呼叫的监听方法及设备
US20080137647A1 (en) VoIP terminal and method for providing multi-call service
KR100785792B1 (ko) 접속 설정 프로토콜을 사용하는 인터넷 전화 시스템에서의서비스 제공 방법 및 그 시스템
KR100666945B1 (ko) Sip 프로토콜을 이용한 단말간의 미디어 정보 교환 방법

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
TR01 Transfer of patent right

Effective date of registration: 20180816

Address after: 518000 Room 201, building A, No. 1, Qian Wan Road, Qianhai Shenzhen Hong Kong cooperation zone, Shenzhen, Guangdong (Shenzhen Qianhai business secretary Co., Ltd.)

Patentee after: SHENZHEN SHUZIXINGHE TECHNOLOGY CO., LTD.

Address before: 518000 room 701, international business building, Nanshan District Science Park, Shenzhen, Guangdong

Patentee before: Shenzhen Yuehetong Technology Co., Ltd.

TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20200810

Address after: Room 905-909, building 6, Shenzhen Bay science and technology ecological park, No. 6, Gaoxin South ninth Road, high tech Zone community, Yuehai street, Nanshan District, Shenzhen City, Guangdong Province

Patentee after: Shenzhen black hole Optical Technology Co., Ltd

Address before: 518000 Guangdong city of Shenzhen province Qianhai Shenzhen Hong Kong cooperation zone before Bay Road No. 1 building 201 room A (located in Shenzhen Qianhai business secretary Co. Ltd.)

Patentee before: SHENZHEN DIGITAL GALAXY TECHNOLOGY Co.,Ltd.

TR01 Transfer of patent right