KR100259821B1 - Method for operating rtcp of a rtp header in a video server - Google Patents
Method for operating rtcp of a rtp header in a video server Download PDFInfo
- Publication number
- KR100259821B1 KR100259821B1 KR1019970078893A KR19970078893A KR100259821B1 KR 100259821 B1 KR100259821 B1 KR 100259821B1 KR 1019970078893 A KR1019970078893 A KR 1019970078893A KR 19970078893 A KR19970078893 A KR 19970078893A KR 100259821 B1 KR100259821 B1 KR 100259821B1
- Authority
- KR
- South Korea
- Prior art keywords
- rtp
- packet
- ssrc
- session
- binding
- 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.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/643—Communication protocols
- H04N21/6437—Real-time Transport Protocol [RTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
- H04N21/23605—Creation or processing of packetized elementary streams [PES]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
- H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
- H04N21/25808—Management of client data
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Computer Graphics (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
본 발명은 비디오 서버에서 알티피 헤더의 알티씨피의 운영방법에 관한 것으로, 종래에는 RTP세션과 SSRC의 바인딩 과정에서 알티씨피 패킷이 도착할 때 까지 기다리고 있다가 바인딩하는 방법을 사용하는 경우에는 상기 알티씨피 패킷이 도착하기 전에 도착한 알티피 패킷은 모두 손실되는 문제점이 있고, 알티피 데이터 패킷이 순차적으로 2개가 도착하면 바인딩하는 방법을 사용하는 경우에는 2개가 순차적으로 도착하지 않을 때 도착하는 알티피 데이터 패킷이 모두 손실되는 문제점이 있다. 따라서 본 발명은 서버의 초기상태에서 클라이언트로 부터 서비스 요구가 있으면 임의의 세션이 오픈상태가 되는 제1단계와, 상기 오픈상태에서 SSRC 바인딩을 위한 RTCP-APP 패킷을 클라이언트로 보내 클라이언트의 RTP 세션과 바인딩하도록 하는 제2단계와, 상기 제2단계에서 바인딩이 이루어진 상태에서 오픈된 세션에 대한 플레이 요구가 있으면 플레이상태가 되고 상기 제2단계에서 바인딩된 SSRC를 갖는 RTP 패킷에 미디어 데이터를 실어 보내는 제3단계로 동작하여, 초기에 손실되는 미디어 데이터의 손실을 막기 위해 플레이전의 오픈상태에서 RTCP 패킷을 RTP 패킷보다 먼저 보내 미디어 데이터가 전송되기 전에 클라이언트의 RTP 세션과 바인딩하게 한 후, 플레이 상태에서 그 바인딩된 RTP 패킷에 미디어 데이터를 실어보내 데이터의 손실을 방지하도록 한 것이다.The present invention relates to a method of operating an RTP of an ALTP header in a video server. In the related art, in the binding process of an RTP session and an SSRC, the RTP session waits until an RTP packet arrives and then binds the RTP. There is a problem in that all Altippi packets that arrive before the packet arrives are lost, and when the Altipi data packets are bound in sequence when two arrive, the Altipi data packets arrive when the two do not arrive sequentially. There is a problem that all of them are lost. Accordingly, the present invention provides a first step in which an arbitrary session is opened when a service request is received from a client in an initial state of the server, and sends an RTCP-APP packet for SSRC binding to the client in the open state. A second step of binding and a play request for a session opened in the second step in which the binding is made, and the media data is loaded into an RTP packet having the SSRC bound in the second step. In order to prevent the loss of media data that is initially lost, the RTCP packet is sent before the RTP packet in the open state before play so that it can be bound to the client's RTP session before the media data is transmitted. Load media data into bound RTP packets to prevent data loss Will.
Description
본 발명은 알티피(RTP)/알티씨피(RTCP) 버전 2.0을 사용하는 비디오 서버를 위한 알티피 헤더의 정당성 검사(VALIDITY CHECK)를 위한 알티씨피의 운영방법에 관한 것으로, 특히 비디어 서버의 스트림 데이터인 엠펙과 같은 멀티미디어 데이터를 손실없이 전송하여 고품질의 실시간 서비스를 제공할 수 있도록 한 비디오 서버에서 알티피 헤더의 알티씨피의 운영방법에 관한 것이다.The present invention relates to a method of operating ALTPIP for validity check of ALTIPP header for video server using RTP / RTC version 2.0, in particular stream of video server. The present invention relates to a method of operating an ALTIFI header of an ALTIFI header in a video server to provide multimedia data such as MPEG, which is data, without loss.
미디어 데이터의 경우 인토딩되는 앞부분의 내용은 미디어 데이터를 사용자에게 플레이(play)할 때 필요한 중요한 정보들을 포함하고 있으므로, 초기에 보내지는 데이터가 손실될 경우 원활한 서비스 제공이 어렵거나 복구하는데 많은 시간이 소요되므로 실시간 서비스에 치명적인 영향을 줄 수 있다.In the case of media data, the inbound content includes important information needed to play the media data to the user. Therefore, if the data to be sent is lost, it is difficult to provide a smooth service or to recover a lot of time. This can have a fatal effect on real-time services.
알티피(RTP: Real Time Protocol)는 멀티미디어 응용에서 실시간 성질을 갖는 멀티미디어 데이터를 전송하기 위한 일종의 응용 프로토콜이다.Real Time Protocol (RTP) is an application protocol for transmitting multimedia data having real-time properties in multimedia applications.
그리고, 알티피(RTP)는 하부 프로토콜로서 다른 네트워크 전송 프로토콜을 사용할 수 있다. 즉 하부 프로토콜이 멀티캐스트 디스트리부션(multicast distribution)을 제공하는 경우, 다수의 목적지에 데이터를 전송할 수 있게 된다.In addition, RTP may use another network transport protocol as a lower protocol. That is, when the underlying protocol provides a multicast distribution, it is possible to transmit data to multiple destinations.
알티씨피(RTCP: Real Time Control Protocol)는 상기 알티피(RTP)를 제어하는 제어 프로토콜이다.Real Time Control Protocol (RTCP) is a control protocol for controlling the RTP.
알티피(RTP)/알티씨피(RTCP) 버전 2.0에서는 데이터의 근원지를 구분하기 위한 식별자로서, SSRC(Synchronization source)값을 가지며, 이 값은 알티피 헤더에 실어져 알티피 패킷이 전송될 때 마다 함께 전송되며, 네트워크 주소와는 관계없는 값이다.In RTP / RTCP version 2.0, an identifier for identifying the source of data, which has a Synchronization source (SSRC) value, which is carried in an Altipee header and transmitted every time an Altippi packet is transmitted. Sent together, this value is independent of network address.
즉, 상기 Synchronization source(SSRC)는 알티피 패킷 스트림(STREAM)의 소오스로서 네트워크 어드레스와 구분하기 위해 알티피 헤더에서 SSRC 식별자로서 32비트의 숫자를 사용한다.That is, the synchronization source (SSRC) uses a 32-bit number as the SSRC identifier in the ALTP header to distinguish it from the network address as a source of the ALTP packet stream (STREAM).
Synchronization source(SSRC)로 부터 발생되는 모든 패킷은 같은 시간과 연 속의 숫자 공간을 형성하므로 수신자는 플래이백(PLAYBACK)을 위해 상기 SSRC가 보낸 패킷들을 분류할 수 있게 된다.Since all packets generated from the synchronization source (SSRC) form the same time and consecutive number spaces, the receiver can classify the packets sent by the SSRC for PLAYBACK.
그리고, SSRC 식별자는 랜덤하게 선택되는 값으로 유일할 값을 갖는다.The SSRC identifier is a randomly selected value having a unique value.
임의의 멀티미디어 세션 내의 모든 알티피 세션에 대해 참여자는 같은 SSRC 식별자를 사용하지 않으며, 이에 대한 바인딩은 알티씨피(RTCP)를 통해 이루어진다.Participants do not use the same SSRC identifier for all ALTP sessions in any multimedia session, and binding to this is done through RTCP.
즉 알티피 패킷의 정당성 검사(Validity Check)를 위해서는 전송되는 알티피 데이터 헤더의 SSRC와 받아들이는 쪽의 SSRC가 일치해야 한다.That is, for the validity check of the ALTP packet, the SSRC of the ALTP data header to be transmitted must match the SSRC of the receiver.
종래의 알티피 세션과 SSRC의 바인딩 과정은 크게 2가지가 있다.There are two types of binding processes between the conventional ALTP session and the SSRC.
첫째는, 첫 번째 알티씨피 패킷이 도착할 때 까지 바인딩 되지 않고 있다가 상기 알티씨피 패킷이 도착하면 바인딩된다.First, it is not bound until the first RTP packet arrives, and then bound when the RTP packet arrives.
둘째는, 알티피 데이터 패킷이 순차적으로 2개가 도착하면 바인딩된다.Secondly, when two ALTP data packets arrive in sequence, they are bound.
상기에서와 바인딩 과정을 통하여 얻은 패킷이 받아들이는 쪽의 SSRC와 일치하면 전송한다.If the packet obtained through the binding process is identical to that of the receiving SSRC, the packet is transmitted.
그러나, 상기에서와 같은 종래기술에서, RTP세션과 SSRC의 바인딩 과정에서 알티씨피 패킷이 도착할 때 까지 기다리고 있다가 바인딩하는 방법을 사용하는 경우에는 상기 알티씨피 패킷이 도착하기 전에 도착한 알티피 패킷은 모두 손실되는 문제점이 있고, 알티피 데이터 패킷이 순차적으로 2개가 도착하면 바인딩하는 방법을 사용하는 경우에는 2개가 순차적으로 도착하지 않을 때 도착하는 알티피 데이터 패킷이 모두 손실되는 문제점이 있다.However, in the prior art as described above, when the RTP session and the SSRC binding process waits for the arrival of the RTP packet and then binds, the RTP packet arrives before the RTP session arrives. There is a problem that is lost, when using the binding method when two arrival of two ALTIPI data packets in sequence, there is a problem that all the ALTIPI data packets arriving when the two do not arrive sequentially.
따라서 상기에서와 같은 종래의 문제점을 해결하기 위한 본 발명의 목적은 초기에 보내지는 멀티미디어 데이터를 손실없이 전송할 수 있도록 한 비디오 서버에서 알티피 헤더의 알티씨피의 운영방법을 제공함에 있다.Accordingly, an object of the present invention to solve the conventional problems as described above is to provide a method for operating the Altipi header of the Altipi header in the video server to be able to transmit the multimedia data initially sent without loss.
본 발명의 다른 목적은 멀티미디어 데이터를 손실없이 전송하여 고품질의 실시간 서비스를 제공할 수 있도록 한 비디오 서버에서 알티피 헤더의 알티씨피의 운영방법을 제공함에 있다.Another object of the present invention is to provide a method of operating an AltiPi header of an Altipi header in a video server that can transmit multimedia data without loss to provide a high quality real-time service.
도 1은 본 발명 비디오 서버에서 알티피 헤더의 알티씨피의 운영방법에 대한 동작 과정도.1 is a flowchart illustrating a method of operating an RTP of an ALTI header in a video server of the present invention.
도 2는 서버측에서 클라이언트로 전송되는 미디어 데이터의 천이 과정을 보여주는 설명도.2 is an explanatory diagram showing a transition process of media data transmitted from a server side to a client.
도 3은 도 1에서, RTCP-APP 패킷의 구조를 보여주는 구조도.3 is a structural diagram showing the structure of an RTCP-APP packet in FIG.
상기 목적을 달성하기 위한 본 발명은 초기상태에서 클라이언트로 부터 서비스 요구시 서비스 제공을 위한 준비단계인 오픈상태로 들어가는 제1단계와, 상기 오픈상태에서 SSRC 바인딩을 위한 RTCP-APP 패킷을 클라이언트로 보내 클라이언트의 RTP 세션과 바인딩하도록 하는 제2단계와, 상기 제2단계에서 바인딩이 이루어진 상태에서 오픈된 세션에 대한 플레이 요구시 상기 제2단계에서 바인딩된 SSRC를 갖는 RTP 패킷에 미디어 데이터를 실어 보내는 제3단계와, 상기에서 미디어 데이터로 모두 전송되면 종료하는 제4단계로 이루어진 것을 특징으로 한다.In order to achieve the above object, the present invention provides a first step of entering an open state, which is a preparation step for providing a service when a service request is made from a client in an initial state, and sends an RTCP-APP packet for SSRC binding to the client in the open state. A second step of binding to the RTP session of the client, and a media sending of the media data to the RTP packet having the SSRC bound in the second step when a play request for the opened session is performed in the second step; And a fourth step of terminating when all of the media data has been transmitted.
이하, 첨부한 도면에 의거하여 상세히 살펴보면 다음과 같다.Hereinafter, the present invention will be described in detail with reference to the accompanying drawings.
도 1은 본 발명 비디오 서버에서 알티피 헤더의 알티씨피의 운영방법에 대한 동작 과정도로서, 이에 도시한 바와같이, 초기상태에서 클라이언트로 부터 서비스 요구시 서비스 제공을 위한 준비단계인 오픈상태로 들어가는 제1단계와, 상기 오픈상태에서 SSRC 바인딩을 위한 RTCP-APP 패킷을 클라이언트로 보내 클라이언트의 RTP 세션과 바인딩하도록 하는 제2단계와, 상기 제2단계에서 바인딩이 이루어진 상태에서 오픈된 세션에 대한 플레이 요구시 상기 제2단계에서 바인딩된 SSRC를 갖는 RTP 패킷에 미디어 데이터를 실어 보내는 제3단계와, 상기에서 미디어 데이터로 모두 전송되면 종료하는 제4단계로 이루어진다.FIG. 1 is a flowchart illustrating a method of operating an RTP of an ALTP header in a video server according to an embodiment of the present invention. As shown in FIG. A first step, a second step of sending an RTCP-APP packet for SSRC binding to the client in the open state to bind to the RTP session of the client, and a play for the session opened in the second step; A third step of loading the media data in the RTP packet having the SSRC bound in the second step when requested, and a fourth step of terminating when all of the media data is transmitted.
이와같이 각 단계로 이루어진 본 발명의 동작 및 작용 효과에 대하여 상세히 설명하면 다음과 같다.When described in detail with respect to the operation and effect of the present invention made of each step as follows.
알티피 패킷으로 전송되는 미디어 데이터는 알티피 헤더의 정당성 검사를 SSRC의 바인딩이 이루어진 다음에 유효해지므로 바인딩되는 시기는 매우 중요하다.Since the media data transmitted in the ALTP packet is valid after the SSRC binding is performed, the binding time is very important.
종래의 알티씨피 운영의 경우, 일정량의 알티피 패킷이 전송된 다음에 알티씨피 패킷을 전송된 후, 보내진다.In a conventional RTP operation, a certain amount of RTP packets are transmitted, and then RCT packets are transmitted and then sent.
즉, SSRC의 바인딩이 이루어지기 위해서는 첫 번째 알티씨피가 도착할 때까지 도착한 미디어 데이터를 버리거나, 적어도 2개의 데이터를 버려야 한다.In other words, in order for SSRC to be bound, media data that has arrived must be discarded or at least two data must be discarded until the first RTP arrives.
따라서 종래에서와 같이 초기에 손실되는 미디어 데이터의 손실을 막기 위해, 도 2에서와 같이, 플레이(PLAY)하기 전 상태인 오픈(OPEN) 상태에서 알티씨피 패킷을 알티피 패킷 보다 먼저 보냄으로써 미디어 데이터가 전송이 시작되기 전에 클라이언트의 알티피 세션(session)과 바인딩되게 하여, 처음 보내지는 미디어 데이터 부터 유효 데이터로 처리할 수 있게 한다.Therefore, in order to prevent the loss of media data that is initially lost as in the prior art, as shown in FIG. 2, by sending the RCT packet before the ALTP packet in the OPEN state before the PLAY state, as shown in FIG. Is bound to the client's Altipi session before the transfer begins, allowing it to process valid data from the first media data sent.
이때 이용되는 알티씨피 패킷은 RTCP-APP(Application-defined RTCP packet Byte)를 이용한다.The RTP packet used here uses an RTCP-APP (Application-defined RTCP packet byte).
이 과정에 대하여 도 1에 의거하여 살펴보면, 멀티미디어 데이터가 전송되어 플레이되기 이전에 비디오 서버측은 초기상태로 있게 된다.(S11)Referring to FIG. 1, the video server side is in an initial state before multimedia data is transmitted and played.
이와같이 초기상태에서 클라이언트측으로 부터 멀티미디어 데이터에 대한 요구가 있으면 비디오 서버측의 임의의 세션이 오픈상태가 된다.(S12)In this way, if there is a request for multimedia data from the client side in the initial state, an arbitrary session on the video server side is opened (S12).
오픈상태에서 비디오 서버측은 SSRC 바인딩을 위한 RTCP-APP 패킷을 클라이언트측으로 전송한다.(S13)In the open state, the video server side transmits an RTCP-APP packet for SSRC binding to the client side (S13).
여기서, RTCP-APP의 구조를 살펴보면, 도 3에서와 같이, 버전을 나타내기 위한 2비트와, 패딩추가 여부를 나타내기 위한 1비트와, 오픈시 바인딩을 위해 정의된 값을 나타내기 위한 5비트와, 패킷 타입을 나타내기 위한 8비트와, 길이를 나타내기 위한 16비트와, 바인딘을 위한 SSRC값을 나타내기 위한 32비트와, 문자열을 나타내기 위한 32비트의 구조로 이루어진다.Here, looking at the structure of the RTCP-APP, as shown in Figure 3, 2 bits to indicate the version, 1 bit to indicate whether to add the padding, and 5 bits to indicate the value defined for the binding on open And 8 bits for indicating the packet type, 16 bits for indicating the length, 32 bits for indicating the SSRC value for the bindin, and 32 bits for indicating the character string.
따라서 클라이언트의 RTP 세션과 서버측의 SSRC 바인딩을 행한다.(S14)Therefore, the client performs the RTP session and the server-side SSRC binding (S14).
이렇게 바인딩이 이루어진 상태에서 오픈된 세션에 대한 플레이 요구가 입력되면, 플레이 상태로 진행(S15)하게 되고, 앞에서 바인딩된 SSRC를 갖는 RTP패킷에 미디어 데이터를 실어보낸다.(S16)When the play request for the opened session is input while the binding is made, the process proceeds to the play state (S15), and the media data is loaded on the RTP packet having the SSRC bound before (S16).
결국 초기의 멀티미디어 데이터가 손실되지 않고 RTP 패킷에 실려 클라이언트측으로 보내진다.As a result, the initial multimedia data is not lost and sent to the client side in an RTP packet.
따라서, 본 발명은 초기에 손실되는 미디어 데이터의 손실을 막기 위해 플레이전의 오픈상태에서 RTCP 패킷을 RTP 패킷보다 먼저 보내 미디어 데이터가 전송되기 전에 클라이언트의 RTP 세션과 바인딩하게 한 후, 플레이 상태에서 그 바인딩된 RTP 패킷에 미디어 데이터를 실어보내 데이터의 손실을 방지하도록 한 효과가 있다.Therefore, in order to prevent the loss of media data that is initially lost, the present invention sends an RTCP packet before the RTP packet in the open state before play to bind the RTP session of the client before the media data is transmitted. The media data is loaded on the RTP packet to prevent the loss of data.
Claims (2)
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1019970078893A KR100259821B1 (en) | 1997-12-30 | 1997-12-30 | Method for operating rtcp of a rtp header in a video server |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1019970078893A KR100259821B1 (en) | 1997-12-30 | 1997-12-30 | Method for operating rtcp of a rtp header in a video server |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| KR19990058739A KR19990058739A (en) | 1999-07-15 |
| KR100259821B1 true KR100259821B1 (en) | 2000-06-15 |
Family
ID=19529953
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1019970078893A Expired - Fee Related KR100259821B1 (en) | 1997-12-30 | 1997-12-30 | Method for operating rtcp of a rtp header in a video server |
Country Status (1)
| Country | Link |
|---|---|
| KR (1) | KR100259821B1 (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9883361B2 (en) | 2012-07-27 | 2018-01-30 | Qualcomm Incorporated | Delivering time synchronized arbitrary data in an RTP session |
-
1997
- 1997-12-30 KR KR1019970078893A patent/KR100259821B1/en not_active Expired - Fee Related
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9883361B2 (en) | 2012-07-27 | 2018-01-30 | Qualcomm Incorporated | Delivering time synchronized arbitrary data in an RTP session |
Also Published As
| Publication number | Publication date |
|---|---|
| KR19990058739A (en) | 1999-07-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6263371B1 (en) | Method and apparatus for seaming of streaming content | |
| US7447242B2 (en) | Method for real time protocol media recording | |
| US20030206549A1 (en) | Method and apparatus for multicast delivery of information | |
| US6205140B1 (en) | Communication of dynamic dependencies along media streams | |
| EP1678909B1 (en) | Method, system and article for dynamic real-time stream aggregation in a network | |
| US7865599B2 (en) | Methods and apparatus for supporting transmission of streaming data | |
| JP2009512280A (en) | RTP egress streaming apparatus and method using complementary instruction file | |
| CN101352013A (en) | Method and apparatus for rtp egress streaming using complementary directing file | |
| US7764708B2 (en) | Data transmission system, header-information adding device, data-format converting device, and data transmission method | |
| US20080082674A1 (en) | Method, Network and Network Proxy for Transmitting Information | |
| AU2007344308A2 (en) | Method of real-time transmission/reception of data in packets between a server and a client terminal, corresponding server and terminal | |
| CN101039325B (en) | Method for configuring real-time transmission protocol packet based on mixer | |
| CN109257620B (en) | Network live broadcast method and system based on multipath transmission | |
| US8639279B2 (en) | Method of requesting a communication session using segmented signaling messages | |
| US20090268730A1 (en) | Data transmitting apparatus and method and program for controlling transmission rate | |
| KR20010035779A (en) | Packet loss compensating method in user datagram protocol | |
| KR100259821B1 (en) | Method for operating rtcp of a rtp header in a video server | |
| US8068515B2 (en) | Faster multimedia synchronization of broadcast streams using router caching of RTCP packets | |
| Ver Steeg et al. | Unicast-based rapid acquisition of multicast RTP sessions | |
| WO2000077999A2 (en) | Method and apparatus for dynamic proxy reflecting of streaming content | |
| Halepoto et al. | Evaluation of multimedia streams in internet applications | |
| Yetgi et al. | Efficient progressive downloading over multimedia broadcast multicast service | |
| KR100234757B1 (en) | Binding method of rtp session and ssrc | |
| Ver Steeg et al. | RFC 6285: Unicast-Based Rapid Acquisition of Multicast RTP Sessions | |
| Kasamis | Network Steganography |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A201 | Request for examination | ||
| PA0109 | Patent application |
St.27 status event code: A-0-1-A10-A12-nap-PA0109 |
|
| PA0201 | Request for examination |
St.27 status event code: A-1-2-D10-D11-exm-PA0201 |
|
| R17-X000 | Change to representative recorded |
St.27 status event code: A-3-3-R10-R17-oth-X000 |
|
| PN2301 | Change of applicant |
St.27 status event code: A-3-3-R10-R13-asn-PN2301 St.27 status event code: A-3-3-R10-R11-asn-PN2301 |
|
| PG1501 | Laying open of application |
St.27 status event code: A-1-1-Q10-Q12-nap-PG1501 |
|
| E701 | Decision to grant or registration of patent right | ||
| PE0701 | Decision of registration |
St.27 status event code: A-1-2-D10-D22-exm-PE0701 |
|
| PN2301 | Change of applicant |
St.27 status event code: A-3-3-R10-R13-asn-PN2301 St.27 status event code: A-3-3-R10-R11-asn-PN2301 |
|
| GRNT | Written decision to grant | ||
| PR0701 | Registration of establishment |
St.27 status event code: A-2-4-F10-F11-exm-PR0701 |
|
| PR1002 | Payment of registration fee |
St.27 status event code: A-2-2-U10-U11-oth-PR1002 Fee payment year number: 1 |
|
| PG1601 | Publication of registration |
St.27 status event code: A-4-4-Q10-Q13-nap-PG1601 |
|
| PN2301 | Change of applicant |
St.27 status event code: A-5-5-R10-R13-asn-PN2301 St.27 status event code: A-5-5-R10-R11-asn-PN2301 |
|
| PN2301 | Change of applicant |
St.27 status event code: A-5-5-R10-R13-asn-PN2301 St.27 status event code: A-5-5-R10-R11-asn-PN2301 |
|
| LAPS | Lapse due to unpaid annual fee | ||
| PC1903 | Unpaid annual fee |
St.27 status event code: A-4-4-U10-U13-oth-PC1903 Not in force date: 20030329 Payment event data comment text: Termination Category : DEFAULT_OF_REGISTRATION_FEE |
|
| PC1903 | Unpaid annual fee |
St.27 status event code: N-4-6-H10-H13-oth-PC1903 Ip right cessation event data comment text: Termination Category : DEFAULT_OF_REGISTRATION_FEE Not in force date: 20030329 |
|
| P22-X000 | Classification modified |
St.27 status event code: A-4-4-P10-P22-nap-X000 |
|
| P22-X000 | Classification modified |
St.27 status event code: A-4-4-P10-P22-nap-X000 |