WO2013048038A2 - 미디어 키 관리 및 상기 미디어 키를 이용한 피어-투-피어 메시지 송수신 시스템 및 방법 - Google Patents

미디어 키 관리 및 상기 미디어 키를 이용한 피어-투-피어 메시지 송수신 시스템 및 방법 Download PDF

Info

Publication number
WO2013048038A2
WO2013048038A2 PCT/KR2012/007340 KR2012007340W WO2013048038A2 WO 2013048038 A2 WO2013048038 A2 WO 2013048038A2 KR 2012007340 W KR2012007340 W KR 2012007340W WO 2013048038 A2 WO2013048038 A2 WO 2013048038A2
Authority
WO
WIPO (PCT)
Prior art keywords
client
relay server
message
media key
media
Prior art date
Application number
PCT/KR2012/007340
Other languages
English (en)
French (fr)
Other versions
WO2013048038A3 (ko
Inventor
윤희태
Original Assignee
삼성에스디에스 주식회사
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 삼성에스디에스 주식회사 filed Critical 삼성에스디에스 주식회사
Priority to CN201280046835.XA priority Critical patent/CN103843298B/zh
Priority to US14/347,577 priority patent/US20140237063A1/en
Publication of WO2013048038A2 publication Critical patent/WO2013048038A2/ko
Publication of WO2013048038A3 publication Critical patent/WO2013048038A3/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • 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/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]

Definitions

  • the present invention relates to techniques for efficiently performing peer-to-peer based message transmission and reception.
  • Peer-to-peer (P2P) technology refers to a technology for transmitting and receiving messages through direct communication between peers (clients) without passing through a server on a network.
  • P2P technology has been developed as a means of facilitating the exchange of information of individuals on the network.In the early days, P2P technology was widely used as an illegal data sharing means. It is actively used as a means for service.
  • a path (channel) for transmitting and receiving data between clients needs to be generated.
  • clients often exist inside of network address translation (NAT), and in order to send messages to these clients, there are many cases where a separate NAT traversal is required.
  • NAT network address translation
  • NAT evasion and port mapping are performed separately between relay server and client according to each client's target and data type.
  • this method since the number of necessary ports increases as the connection target increases, there is a problem that a smooth connection cannot be made when the number of access clients increases, such as a home router having a limit of the number of port mappings.
  • the second method is to perform only one NAT evasion and port mapping operation between the relay server and the client, and send and receive all messages using the same port.
  • This method has an advantage that it can be easily connected to multiple clients even when the number of connectable ports is limited.
  • additional identification information P2P header
  • adding a P2P header to each individual message dramatically increases the overall capacity of the message, thereby rapidly decreasing transmission efficiency.
  • an overhead according to message transmission and reception by effectively distributing a media key between each client and a relay server for message transmission and reception and transmitting and receiving the message using the same The goal is to minimize this.
  • a method for managing a media key the method for distributing a media key between a first client, a second client, a first relay server, and a second relay server.
  • the media key management system generates a first message and transmits the generated first message to the second client via the second relay server.
  • a first client receiving a second message transmitted from the second client and transmitted via the first relay server, and obtaining a media key of the second relay server included in the received second message;
  • a first relay server receiving the second message corresponding to the first message from the second client and obtaining a media key of the first client included in the received second message;
  • a second relay server receiving a third message from the first client and obtaining a media key of the second client included in the received third message;
  • a second client that receives the third message transmitted from the first client and transmitted via the second relay server, and obtains a media key of the first relay server included in the received third message.
  • the peer-to-peer message transmission and reception system for solving the above problems, the first media key issued from the receiving side relay server to the media data to transmit to the receiving side relay server; Sending client; Issue the first media key to the transmitting client, receive the media data from the transmitting client, and replace the first media key added to the received media data with a second media key issued from the receiving client to receive the media data.
  • a receiving relay server transmitting to a client; And a receiving client that issues the second media key to the receiving relay server and receives the media data from the receiving relay server.
  • the peer-to-peer message transmission and reception method for solving the above problem, in the transmitting client, the receiving side relay server by adding the first media key issued from the receiving relay server to the media data Transmitting to; Receiving, at the receiving relay server, the media data from the transmitting client, replacing the first media key added to the received media data with a second media key issued from the receiving client, and transmitting the received media data to the receiving client; And receiving, at the receiving client, the media data from the receiving relay server.
  • the network bandwidth for data transmission and reception can be effectively reduced by minimizing the overhead due to the P2P header when transmitting media data such as voice / video in a peer-to-peer message transmission system.
  • media data such as voice / video in a peer-to-peer message transmission system.
  • P2P peer-to-peer
  • FIG. 3 is a flowchart illustrating a process for deleting a media key distributed through the process of FIG. 2.
  • FIG. 4 is a flowchart illustrating a process of transmitting and receiving media data between clients when the media key distribution process is completed through the process shown in FIG. 2.
  • FIG. 1 is a block diagram of a peer-to-peer (P2P) message transmission and reception system 100 according to an embodiment of the present invention.
  • the message transmission / reception system 100 may operate the first client 102, the second client 104, the first relay server 106, and the second relay server 108. Include.
  • the first client 102 and the second client 104 are devices for transmitting and receiving messages to and from each other in the message transceiving system 100. That is, the message M1 transmitted from the first client 102 is delivered to the second client 104, and the message M2 transmitted from the second client 104 is delivered to the first client 102.
  • the first client 102 and the second client 104 may be, for example, VoIP terminals that send and receive voice messages using a VoIP service with each other, but this is an example to send and receive messages in a peer-to-peer manner.
  • the terminal may be the first client 102 and the second client 104 of the present invention without limitation.
  • the first relay server 106 and the second relay server 108 are servers for relaying message transmission and reception between the first client 102 and the second client 104.
  • the first client 102 or the second client 104 is located inside a separate NAT (Network Address Translation)
  • the first client unless the NAT traversal process is performed separately.
  • Messages sent by 102 cannot be delivered to the second client 104 by being blocked by the NAT, and messages sent by the second client 104 also cannot be delivered to the first client 102.
  • the first client 102 and the second client 104 by including the first relay server 106 and the second relay server 108 that exist outside the NAT. ) Can send and receive messages to each other without going through a separate NAT avoidance.
  • the first relay server 106 performs a NAT avoidance and port mapping operation with the first client 102 in advance to transmit a message between the first relay server 106 and the first client 102.
  • the second relay server 108 performs NAT avoidance and port mapping operations in advance with the second client 104 to transmit a message transmission path between the second relay server 108 and the second client 104.
  • the first client 102 sends a message to the second client 104
  • the first client 102 directly sends the message using the network address (IP / Port) of the second client 104.
  • the second relay server 108 Rather than transmitting the message to a second relay server 108 connected with a second client 104, the second relay server 108 secures a message received from the first client 102 in advance. To the second client 104 using. Similarly, when the second client 104 sends a message to the first client 102, the second client 104 sends the message to the first relay server 106 connected with the first client 102, The first relay server 106 transfers the message received from the second client 104 to the first client 102 using a transmission path secured in advance.
  • Caller Information Sender's network address (IP, port, etc.) and / or user identification number.
  • Recipient information Recipient's network address and / or user identification number
  • Channel Information Unique value for identifying the message between sender and receiver
  • a media key promised is exchanged between a client and a relay server in a communication channel generation step for transmitting a message between the clients, and after that, message transmission and reception are performed including only the media key previously exchanged in the message header.
  • the media key means a predetermined string used to distinguish the peer-to-peer message from another message between two clients who want to exchange a peer-to-peer message and a relay server that delivers the message to the client. .
  • the first client 102, the second client 104, and the first relay server issue four media keys of K1, K2, K3, and K4, respectively, and exchange them with each other.
  • the first client 102 sends a message to the second client 104
  • the first client 102 adds the media key K4 of the second relay server 108 to the header of the message.
  • the second relay server 108 recognizes the media key K4 of the second relay server 108 added to the received message so that the message is transmitted from the first client 102 so that the second client can receive the message.
  • the second relay server 108 replaces the K4 with the media key (K2) of the second client 104 that is the destination of the message, the second client 104 To send.
  • the second client 104 adds the media key K3 of the first relay server 106 to the header of the message to generate the message.
  • the first relay server 106 sends the media key K3 of the first relay server 106 added to the received message to the media key K1 of the first client 102.
  • FIG. 2 is a flowchart illustrating a media key distribution method 200 in a message transmission and reception system according to an embodiment of the present invention.
  • the first client 102 has a media key K1
  • the second client 104 has a media key K2
  • the first relay server 106 has a media key K3
  • the first client 102 needs to acquire K4, the second client 104 obtains K3, the first relay server 106 obtains K1, and the second relay server 108 obtains K2 to transmit and receive messages. do.
  • the process for transferring the media key between each illustrated component transmits a channel creation message (INVITE message and ACK message) for peer-to-peer communication and a message for media data transmission (PlaceCall message) as shown. This is done through the process.
  • the header added to the channel establishment message and the media data transfer message further includes a separate extension field for media key exchange in addition to the structure of the general peer-to-peer header described above.
  • the extended field consists of 9 bytes and may have a structure as follows.
  • MediaKeyCmd (1byte): A field in which a media key generation / destruction command is stored. This field is used for media key management in relay server. That is, when "A" is written in this field, the relay server issues a new media key. If “D” is written, the relay server deletes the previously issued media key.
  • the reason for having such a separate field is that the client explicitly creates a channel for communication with other clients, so that the generation and destruction cycle of the media key can be synchronized with the creation / destruction cycle of the channel. In this case, since it merely plays a role of relaying the message received from the client, it is impossible to know the creation / destruction of the channel and thus it is impossible to manage the lifecycle of the media key.
  • SenderMediaKeyNo (2byte): Stores the media key issued by the client sending the message.
  • SenderRelayMediaKeyNo (2byte): Stores the media key issued by the relay server connected to the client sending the message.
  • ReceiverMediaKeyNo (2byte): Stores the media key issued by the client receiving the message.
  • the first client 102 issues (202) its media key (K1), and transmits a channel creation message (INVITE) including the K1 to the second relay server 108 (204).
  • K1 media key
  • ISVITE channel creation message
  • the K1 is included in the extended field of the channel generation message, and the remaining fields are filled with zeros (K1, 0, 0, 0).
  • the second relay server 108 issues its own media key (K4) (206), adds it to the extension field (K1, 0, 0, K4) and the second client (104). (208).
  • the second client 104 receiving the channel generation message issues its own media key K2 (210), and generates the received K1, K4 and issued K2 corresponding to the channel generation message.
  • the data is transmitted to the first relay server 106 (212).
  • the first relay server 106 obtains the media key K1 of the first client 102 from the channel generation response message received from the second client 104 (214). At this time, the first relay server 106 obtains the network address of the first client 102 together with the K1 from the header of the channel generation response message, and maps and stores the network address of the first client 102. The reason is that after the key media key distribution process is completed, the subsequent media data header contains only the distributed media key and does not have the network address of the receiving client. That is, when the first relay server 106 receives a message from the second client 104, the first relay server 106 transmits the message to the first client 102 using the network address of the first client 102 mapped with the K1. do.
  • the first relay server 106 issues its own media key K3 (216) and adds it to the channel generation response message (K2, K4, K1, K3) to the first client 102. Transmit (218).
  • the first client 102 receives the channel generation response message to obtain a media key K4 of the second relay server 108 (220), the media key K1 of the first client 102,
  • the media data transmission message PlaceCall includes a media key K3 of the first relay server 106, a media key K2 of the second client 104, and a media key K4 of the second relay server 108.
  • K1, K3, K2, and K4) are generated and transmitted to the second relay server 108 (222).
  • the second relay server 108 obtains (224) the media key K2 of the second client 104 from the received media data transfer message.
  • the second relay server 108 obtains the network address of the second client 104 from the media data transmission message, maps it with the K2, and stores the mapped network address.
  • the second relay server 108 transmits the received media data transmission message to the second client 104 (226).
  • the media key distribution process is completed by obtaining the media key K3 of the first relay server 106 from the media data transmission message received at the second client 104 (228).
  • FIG. 3 is a flowchart 300 illustrating a process for deleting a media key distributed through the process of FIG. 2.
  • the first client 102 and the second client 104 generates a media key when generating a channel for transmitting and receiving a message, and deletes the media key when the channel is destroyed.
  • the first relay server 106 and the second relay server 108 simply relay messages received from the first client 102 and the second client 104 so that they know when the channel is created and destroyed. Because of this, media keys must be deleted through a separate procedure.
  • HangUpCallAsk and HangUpCallRep are used to stop the transmission of the media data.
  • the HangUpCallAsk and HangUpCallRep messages also use the same type of header as the message for the media key distribution, except that the media key deletion command “D” is written in MediaKeyCmd, which is the first field of the extended field.
  • the second relay server 108 that receives the media data is issued by the first client 102.
  • K4 is deleted (304), and the received media data transmission stop message is transmitted to the second client 104 (306).
  • the second client 104 transmits a media data transmission stop response message (HangUpCallRep) corresponding to the received media data transmission stop message to the first relay server 106 (308).
  • the first relay server 106 deletes the media key K3 issued by the first relay server according to the received media data transmission stop response message (310), and sends the received media data transmission stop response message to the first client (102).
  • the media key deletion procedure is terminated by sending 312.
  • the procedure for deleting a media key in the first relay server 106 and the second relay server 108 may be performed explicitly through the above method.
  • a new message may be received from the client for a certain period of time.
  • the relay server may separately manage and manage a flag to check whether a message is received along with the media key.
  • the relay server initializes the flags of all media keys to false at regular intervals using a preset timer, and then sets only the flags of the media keys from which the media data is received to true and is still false at the end of the cycle. It is possible to manage the life cycle of the media key by deleting the remaining media key. In this way, if the media key is periodically cleaned up, the media key of the relay server can be prevented from being maintained even if data transmission is abnormally terminated without sending or receiving an explicit data transmission stop message between clients, thereby effectively managing the media key. Will be.
  • FIG. 4 is a flowchart 400 illustrating a process of transmitting and receiving media data between clients when the media key distribution process is completed through the procedure of FIG. 2.
  • steps 402 to 406 represent a process of transmitting media data from the first client 102 to the second client 104
  • steps 408 to 412 are media from the second client 104 to the first client 102.
  • the process of transmitting data is shown.
  • each media data is transmitted including only a simple header including the media key.
  • the header consists of 4 bytes, and its structure may be configured as follows.
  • -Prefix Used to express that the message is media data, and has a fixed value of "M”.
  • -Media Key (2byte): Contains the media key value issued by the receiving party. For example, when the first client 102 transmits the media data to the second relay server 108, this field includes K4 issued by the second file server 108.
  • the first client 102 adds the media key K4 of the second relay server 108 to the header of the media data to be transmitted and transmits it to the second relay server 108 (402). Thereafter, the second relay server 108 replaces the media key K4 of the second relay server 108 included in the received media data with the media key K2 of the second client 104 (404). The media data is transmitted to the second client 104 using the network address of the second client 104 mapped with K2 (406).
  • the second client 104 adds the media key K3 of the first relay server 106 to the header of the media data to be transmitted and transmits it to the first relay server 106 (408). Thereafter, the first relay server 106 replaces the media key K3 of the first relay server 106 included in the received media data with the media key K1 of the first client 102 (410). The media data is transmitted to the first client 102 using the network address of the first client 102 mapped with K1 (412).
  • each media key issued and distributed by the first client 102, the second client 104, the first relay server 106, and the second relay server 108 is used for message transmission. Since they are used only within the relevant client and relay server, the keys need not be unique keys within the entire system, and it is sufficient to issue a locally unique key only within each client or relay server. Therefore, in the present invention, since it is not necessary to communicate with a separate key issuing server and the like for checking the uniqueness of the key in each media key issuing process, the media key can be issued and deleted at a high speed, and the issued key can be separately centralized. There is an advantage that does not need to be managed on the server.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)

Abstract

피어-투-피어 메시지 송수신 시스템 및 방법, 상기 시스템에서의 미디어 키 분배 방법이 개시된다. 본 발명의 일 실시예에 따른 피어-투-피어 메시지 송수신 시스템은, 미디어 데이터에 수신측 릴레이 서버로부터 발급된 제1 미디어 키를 부가하여 수신측 릴레이 서버로 송신하는 송신 클라이언트; 상기 송신 클라이언트로 상기 제1 미디어 키를 발급하며, 상기 송신 클라이언트로부터 상기 미디어 데이터를 수신하고, 수신된 상기 미디어 데이터에 부가된 상기 제1 미디어 키를 수신 클라이언트로부터 발급된 제2 미디어 키로 치환하여 수신 클라이언트로 송신하는 수신측 릴레이 서버; 및 상기 수신측 릴레이 서버로 상기 제2 미디어 키를 발급하며, 상기 수신측 릴레이 서버로부터 상기 미디어 데이터를 수신하는 수신 클라이언트를 포함한다.

Description

미디어 키 관리 및 상기 미디어 키를 이용한 피어-투-피어 메시지 송수신 시스템 및 방법
본 발명은 피어-투-피어 기반의 메시지 송수신을 효율적으로 수행하기 위한 기술과 관련된다.
피어-투-피어(P2P; peer-to-peer) 기술이란 네트워크상에서 서버를 경유하지 않고 피어(클라이언트)간 직접 통신을 통하여 메시지를 송수신하는 기술을 의미한다. P2P 기술은 네트워크상에 존재하는 개개인의 정보 교환을 용이하게 하기 위한 수단으로 발전해 왔으며, 초기에는 불법적인 자료 공유 수단으로 많이 이용되었으나 최근에는 대용량의 프로그램 및 미디어 전송을 위한 수단, 더 나아가 VoIP 등의 서비스를 위한 수단으로 적극적으로 활용되고 있다.
P2P 기반의 데이터 송수신 시스템에서 클라이언트간 메시지 송수신을 위해서는 클라이언트 사이에 데이터 송수신을 위한 경로(채널)를 생성할 필요가 있다. 그러나 요즘에는 클라이언트가 NAT(Network Address Translation)의 내부에 존재하는 경우가 많으며, 이러한 클라이언트로 메시지를 전송하기 위해서는 별도의 NAT 회피(NAT Traversal)가 필요한 경우가 많다. 그러나 동시에 다수의 클라이언트와 접속을 수행하는 P2P 시스템에서 접속시마다 NAT 회피를 수행하는 것은 비효율적이므로, NAT 내부에 존재하는 클라이언트는 NAT 외부의 릴레이 서버와 전송 경로를 생성한 뒤, 릴레이 서버를 통하여 메시지를 수신하는 것이 일반적이다. 즉, 특정 클라이언트로 메시지를 보내기 위해서, 다른 클라이언트는 먼저 해당 클라이언트로 직접 메시지 송신을 시도하고, 이러한 시도가 실패할 경우 해당 클라이언트와 연결된 릴레이 서버를 경유하여 메시지를 송신하게 된다.
이와 같은 릴레이 서버와 클라이언트 간의 NAT 회피를 위한 방법으로는 크게 다음의 두 가지를 들 수 있다. 첫 번째로, 각각의 클라이언트가 연결하려는 대상 및 데이터 종류에 따라 릴레이 서버와 클라이언트간에 개별적으로 NAT 회피 및 포트 매핑 작업을 수행하는 방법이다. 그러나 이 방법의 경우 연결 대상이 늘어날수록 필요한 포트의 개수가 늘어나므로, 포트 매핑 개수의 제한이 존재하는 가정용 공유기 등의 경우 접속 클라이언트의 개수가 증가하면 원활한 접속이 이루어지기 어려운 문제가 있다.
두 번째로는 릴레이 서버와 클라이언트 간에 한 번의 NAT 회피 및 포트 매핑 작업만을 수행하고, 모든 메시지를 동일한 포트를 사용하여 송수신하는 방법이다. 이 방법의 경우 연결 가능한 포트의 개수가 한정되어 있는 경우에도 다수의 클라이언트와 용이하게 접속할 수 있는 장점이 있으나, 각각의 메시지를 구별하기 위하여 메시지마다 추가적인 식별 정보(P2P 헤더)가 부가되어야 하는 문제가 있다. 특히 개별 메시지의 크기는 작으면서 메시지의 개수가 매우 많은 VoIP 등의 음성 통화 서비스의 경우, 개별 메시지마다 P2P 헤더를 부가하게 되면 메시지 전체의 용량이 비약적으로 증가하게 되어 전송 효율이 급격히 낮아지게 된다.
본 발명은 하나의 채널만을 이용하는 피어-투-피어 기반의 메시지 송수신 시스템에서, 메시지 송수신을 위하여 각 클라이언트 및 릴레이 서버 간에 미디어 키를 효과적으로 분배하고 이를 이용하여 메시지를 송수신함으로써, 메시지 송수신에 따른 오버헤드를 최소화하는 데 그 목적이 있다.
상기 과제를 해결하기 위한 본 발명의 일 실시예에 따른 미디어 키 관리 방법은, 제1 클라이언트, 제2 클라이언트, 제1 릴레이 서버 및 제2 릴레이 서버 간 미디어 키를 분배하기 위한 방법으로서, 상기 제1 클라이언트에서, 제1 메시지를 생성하고 생성된 상기 제1 메시지를 상기 제2 릴레이 서버를 경유하여 상기 제2 클라이언트로 송신하는 제1 단계; 상기 제2 클라이언트에서, 수신된 상기 제1 메시지에 대응하는 채널 생성 응답 메시지를 생성하는 제2 단계; 상기 제1 릴레이 서버에서, 상기 제2 클라이언트로부터 상기 제2 메시지를 수신하고, 수신된 상기 제2 메시지에 포함된 상기 제1 클라이언트의 미디어 키를 획득하는 제3 단계; 상기 제1 클라이언트에서, 상기 제1 릴레이 서버로부터 상기 제2 메시지를 수신하고, 수신한 상기 제2 메시지에 포함된 상기 제2 릴레이 서버의 미디어 키를 획득하는 제4 단계; 상기 제2 릴레이 서버에서, 상기 제1 클라이언트로부터 제3 메시지를 수신하고, 수신된 상기 제3 메시지에 포함된 상기 제2 클라이언트의 미디어 키를 획득하는 제5 단계; 및 상기 제2 클라이언트에서, 상기 제2 릴레이 서버로부터 상기 제3 메시지를 수신하고, 수신된 상기 제3 메시지에 포함된 상기 제1 릴레이 서버의 미디어 키를 획득하는 제6 단계를 포함한다.
한편, 상기 과제를 해결하기 위한 본 발명의 일 실시예에 미디어 키 관리 시스템은, 제1 메시지를 생성하고, 생성된 제1 메시지를 제2 릴레이 서버를 경유하여 제2 클라이언트로 송신하며, 상기 제2 클라이언트로부터 송신되어 제1 릴레이 서버를 경유하여 전송되는 제2 메시지를 수신하고, 수신한 상기 제2 메시지에 포함된 상기 제2 릴레이 서버의 미디어 키를 획득하는 제1 클라이언트; 상기 제2 클라이언트로부터 상기 제1 메시지에 대응하는 상기 제2 메시지를 수신하고, 수신된 상기 제2 메시지에 포함된 상기 제1 클라이언트의 미디어 키를 획득하는 제1 릴레이 서버; 상기 제1 클라이언트로부터 제3 메시지를 수신하고, 수신된 상기 제3 메시지에 포함된 상기 제2 클라이언트의 미디어 키를 획득하는 제2 릴레이 서버; 및 상기 제1 클라이언트로부터 송신되어 상기 제2 릴레이 서버를 경유하여 전송되는 상기 제3 메시지를 수신하고, 수신된 상기 제3 메시지에 포함된 상기 제1 릴레이 서버의 미디어 키를 획득하는 제2 클라이언트를 포함한다.
한편, 상기 과제를 해결하기 위한 본 발명의 일 실시예에 따른 피어-투-피어 메시지 송수신 시스템은, 미디어 데이터에 수신측 릴레이 서버로부터 발급된 제1 미디어 키를 부가하여 수신측 릴레이 서버로 송신하는 송신 클라이언트; 상기 송신 클라이언트로 상기 제1 미디어 키를 발급하며, 상기 송신 클라이언트로부터 상기 미디어 데이터를 수신하고, 수신된 상기 미디어 데이터에 부가된 상기 제1 미디어 키를 수신 클라이언트로부터 발급된 제2 미디어 키로 치환하여 수신 클라이언트로 송신하는 수신측 릴레이 서버; 및 상기 수신측 릴레이 서버로 상기 제2 미디어 키를 발급하며, 상기 수신측 릴레이 서버로부터 상기 미디어 데이터를 수신하는 수신 클라이언트를 포함한다.
한편, 상기 과제를 해결하기 위한 본 발명의 일 실시예에 따른 피어-투-피어 메시지 송수신 방법은, 송신 클라이언트에서, 미디어 데이터에 수신 릴레이 서버로부터 발급된 제1 미디어 키를 부가하여 수신측 릴레이 서버로 송신하는 단계; 상기 수신측 릴레이 서버에서, 상기 송신 클라이언트로부터 상기 미디어 데이터를 수신하고, 수신된 상기 미디어 데이터에 부가된 상기 제1 미디어 키를 수신 클라이언트로부터 발급된 제2 미디어 키로 치환하여 수신 클라이언트로 송신하는 단계; 및 상기 수신 클라이언트에서, 상기 수신측 릴레이 서버로부터 상기 미디어 데이터를 수신하는 단계를 포함한다.
본 발명의 실시예들에 따를 경우 피어-투-피어 메시지 송신 시스템에서 음성/영상 등의 미디어 데이터 전송 시 P2P 헤더로 인한 오버헤드를 최소화함으로써 데이터 송수신을 위한 네트워크 대역을 효과적으로 절감할 수 있으며, 저대역 환경에서도 원활한 통신이 가능한 장점이 있다.
도 1은 본 발명의 일 실시예에 따른 피어-투-피어(P2P) 메시지 송수신 시스템의 블록도이다.
도 2는 본 발명의 일 실시예에 따른 메시지 송수신 시스템에서의 미디어 키 분배 방법을 설명하기 위한 순서도이다.
도 3은 도 2와 같은 과정을 거쳐 분배된 미디어 키를 삭제하기 위한 과정을 설명하기 위한 순서도이다.
도 4는 도 2와 같은 과정를 거쳐 미디어 키 분배 과정이 완료된 경우 클라이언트간의 미디어 데이터의 송수신 과정을 설명하기 위한 순서도이다.
<부호의 설명>
100: 피어-투-피어 메시지 송수신 시스템
102: 제1 클라이언트
104: 제2 클라이언트
106: 제1 릴레이 서버
108: 제2 릴레이 서버
이하, 도면을 참조하여 본 발명의 구체적인 실시형태를 설명하기로 한다. 그러나 이는 예시에 불과하며 본 발명은 이에 제한되지 않는다.
본 발명을 설명함에 있어서, 본 발명과 관련된 공지기술에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략하기로 한다. 그리고, 후술되는 용어들은 본 발명에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다.
본 발명의 기술적 사상은 청구범위에 의해 결정되며, 이하의 실시예는 본 발명의 기술적 사상을 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 효율적으로 설명하기 위한 일 수단일 뿐이다.
도 1은 본 발명의 일 실시예에 따른 피어-투-피어(P2P) 메시지 송수신 시스템(100)의 블록도이다. 도시된 바와 같이, 본 발명의 일 실시예에 따른 메시지 송수신 시스템(100)은 제1 클라이언트(102), 제2 클라이언트(104), 제1 릴레이 서버(106) 및 제2 릴레이 서버(108)를 포함한다.
제1 클라이언트(102) 및 제2 클라이언트(104)는 메시지 송수신 시스템(100) 내에서 서로 메시지를 송수신하기 위한 장치이다. 즉, 제1 클라이언트(102)에서 송신한 메시지(M1)는 제2 클라이언트(104)로 전달되고, 제2 클라이언트(104)에서 송신한 메시지(M2)는 제1 클라이언트(102)로 전달된다. 제1 클라이언트(102) 및 제2 클라이언트(104)는 예를 들어 서로간에 VoIP 서비스를 이용하여 음성 메시지를 주고받는 VoIP 단말일 수 있으나, 이는 예시적인 것으로서 피어-투-피어 방식으로 메시지를 송수신하기 위한 단말이라면 제한 없이 본 발명의 제1 클라이언트(102) 및 제2 클라이언트(104)가 될 수 있다.
제1 릴레이 서버(106) 및 제2 릴레이 서버(108)는 제1 클라이언트(102) 및 제2 클라이언트(104) 간의 메시지 송수신을 중계(relay)하기 위한 서버이다. 예를 들어, 제1 클라이언트(102) 또는 제2 클라이언트(104)가 각각 별도의 NAT(Network Address Translation) 내부에 위치할 경우, 별도의 NAT 회피(NAT Traversal) 과정을 거치지 않는 한, 제1 클라이언트(102)가 송신한 메시지는 NAT에 막혀 제2 클라이언트(104)로 전달될 수 없고, 제2 클라이언트(104)가 송신한 메시지 또한 제1 클라이언트(102)로 전달되지 못하게 된다. 이와 같은 문제를 해결하기 위하여, 본 발명의 실시예에서는 NAT의 외부에 존재하는 제1 릴레이 서버(106) 및 제2 릴레이 서버(108)를 포함함으로써 제1 클라이언트(102) 및 제2 클라이언트(104)가 별도의 NAT 회피를 거치지 않고서도 상호간에 메시지를 송수신할 수 있도록 한다. 먼저, 제1 릴레이 서버(106)는 제1 클라이언트(102)와 사전에 NAT 회피 및 포트 매핑(Port mapping) 작업을 수행하여 제1 릴레이 서버(106)와 제1 클라이언트(102)간의 메시지 전송 경로를 확보한다. 마찬가지로, 제2 릴레이 서버(108)는 제2 클라이언트(104)와 사전에 NAT 회피 및 포트 매핑(Port mapping) 작업을 수행하여 제2 릴레이 서버(108)와 제2 클라이언트(104)간의 메시지 전송 경로를 확보한다. 이후, 제1 클라이언트(102)가 제2 클라이언트(104)로 메시지를 전송할 경우, 제1 클라이언트(102)는 제2 클라이언트(104)의 네트워크 주소(IP/Port)를 이용하여 상기 메시지를 직접 전송하는 것이 아니라, 제2 클라이언트(104)와 연결된 제2 릴레이 서버(108)로 상기 메시지를 송신하며, 제2 릴레이 서버(108)는 제1 클라이언트(102)로부터 수신한 메시지를 미리 확보된 전송 경로를 이용하여 제2 클라이언트(104)로 전달한다. 마찬가지로, 제2 클라이언트(104)가 제1 클라이언트(102)로 메시지를 전송할 경우, 제2 클라이언트(104)는 제1 클라이언트(102)와 연결된 제1 릴레이 서버(106)로 상기 메시지를 송신하며, 제1 릴레이 서버(106)는 제2 클라이언트(104)로부터 수신한 메시지를 미리 확보된 전송 경로를 이용하여 제1 클라이언트(102)로 전달한다.
한편, 전술한 바와 같이 일반적으로 클라이언트와 릴레이 서버 간에는 공유기의 포트 매핑 개수의 제한 등을 고려하여 하나의 전송 경로만이 설정되는 바, 상기 전송 경로로 송수신되는 메시지들을 용이하게 식별하기 위하여 각각의 메시지들은 P2P 헤더(P2P header)를 포함하도록 구성된다. 이와 같은 P2P 헤더에 포함되는 정보들은 다음과 같다.
- 발신자 정보: 발신자의 네트워크 주소(아이피, 포트 등) 및/또는 사용자 식별 번호
- 수신자 정보: 수신자의 네트워크 주소 및/또는 사용자 식별 번호
- 수신측 릴레이 서버 정보: 수신측 릴레이 서버의 네트워크 주소
- 채널 정보: 발신자와 수신자 간에 메시지를 식별하기 위한 고유값
만약 상대편 클라이언트에게 전송하려는 개별 메시지의 크기가 크고 메시지의 개수가 많지 않은 경우에는 상기와 같은 정보를 포함하는 헤더를 각 메시지마다 부가하더라도 전체적인 메시지 용량에 큰 영향을 미치지 않는다. 그러나 VoIP 음성 통화 등과 같이 개별 메시지의 크기는 작으면서 메시지의 개수가 매우 많은 경우에는 상기 헤더의 부가에 따른 메시지의 오버헤드(overhead)가 기하급수적으로 증가하게 된다. 이에 따라, 본 발명에서는 클라이언트간의 메시지 전송을 위한 통신 채널 생성 단계에서 클라이언트 및 릴레이 서버 간에 약속된 미디어 키(media key)를 교환하고, 이후에는 메시지 헤더에 기 교환된 미디어 키 만을 포함하여 메시지 송수신을 수행함으로써 메시지의 오버헤드를 최소화하도록 구성된다. 본 발명에서 미디어 키는 피어-투-피어 메시지를 교환하려는 두 클라이언트 및 상기 클라이언트로 메시지를 전달하는 릴레이 서버 간에 상기 피어-투-피어 메시지를 다른 메시지와 구별하기 위하여 사용하는 소정의 문자열을 의미한다.
예를 들어, 도 1에 도시된 실시예에서 제1 클라이언트(102)와 제2 클라이언트(104) 간의 메시지 교환을 위하여, 제1 클라이언트(102), 제2 클라이언트(104), 제1 릴레이 서버(106) 및 제2 릴레이 서버(108)는 각각 K1, K2, K3 및 K4의 4개의 미디어 키를 각각 발급하여 이를 서로 교환한다. 이후, 만약 제1 클라이언트(102)에서 제2 클라이언트(104)로 메시지를 전송할 경우, 제1 클라이언트(102)는 상기 메시지의 헤더에 제2 릴레이 서버(108)의 미디어 키(K4)를 부가하여 제2 릴레이 서버(108)로 전송한다. 상기 메시지를 수신한 제2 릴레이 서버(108)는 수신된 메시지에 부가된 제2 릴레이 서버(108)의 미디어 키(K4)를 인식함으로써 상기 메시지가 제1 클라이언트(102)로부터 송신되어 제2 클라이언트(104)로 전송되어야 할 것임을 알 수 있으며, 이에 따라 제2 릴레이 서버(108)는 상기 K4를 메시지의 수신처인 제2 클라이언트(104)의 미디어 키(K2)로 치환하여 제2 클라이언트(104)로 송신한다. 반대로, 제2 클라이언트(104)에서 제1 클라이언트(102)로 메시지를 전송할 경우, 제2 클라이언트(104)는 상기 메시지의 헤더에 제1 릴레이 서버(106)의 미디어 키(K3)를 부가하여 제1 릴레이 서버(106)로 전송하고, 제1 릴레이 서버(106)는 수신된 메시지에 부가된 제1 릴레이 서버(106)의 미디어 키(K3)를 제1 클라이언트(102)의 미디어 키(K1)로 치환하여 제1 클라이언트(102)로 송신한다. 즉, 본 발명에서 메시지를 송수신하는 클라이언트 및 릴레이 서버는 메시지 헤더에 포함된 미디어 키 만을 이용하여 해당 메시지의 송신처, 수신처 및 채널 정보 등 일반적인 P2P 헤더에 포함되어 있는 정보들을 인식할 수 있게 된다.
도 2는 본 발명의 일 실시예에 따른 메시지 송수신 시스템에서의 미디어 키 분배 방법(200)을 설명하기 위한 순서도이다.
도면에서 알 수 있는 바와 같이, 제1 클라이언트(102)는 미디어 키 K1을, 제2 클라이언트(104)는 미디어 키 K2를, 제1 릴레이 서버(106)는 미디어 키 K3를, 제2 릴레이 서버(108)는 미디어 키 K4를 각각 발급한다. 또한, 메시지 송수신을 위하여 제1 클라이언트(102)는 K4를, 제2 클라이언트(104)는 K3를, 제1 릴레이 서버(106)는 K1을, 제2 릴레이 서버(108)는 K2를 각각 획득하여야 한다.
도시된 각 구성요소간 미디어 키를 전달하기 위한 과정은, 도시된 바와 같이 피어-투-피어 통신을 위한 채널 생성 메시지(INVITE 메시지 및 ACK 메시지)와 미디어 데이터 전송을 위한 메시지(PlaceCall 메시지)를 전송하는 과정을 통하여 이루어진다. 미디어 키 교환을 위하여, 상기 채널 성성 메시지 및 미디어 데이터 전송 메시지에 부가되는 헤더는 전술한 일반적인 피어-투-피어 헤더의 구조 외에 미디어 키 교환을 위한 별도의 확장 필드를 더 포함한다. 상기 확장 필드는 9바이트로 구성되며, 다음과 같은 구조를 가질 수 있다.
- MediaKeyCmd(1byte): 미디어 키의 생성/소멸 명령이 저장되는 필드이다. 본 필드는 릴레이 서버에서 미디어 키의 관리를 위하여 사용한다. 즉, 본 필드에 "A"가 기재되어 있을 경우 릴레이 서버는 새로 미디어 키를 발급하며, "D"가 기재되어 있을 경우에는 기 발급된 미디어 키를 삭제한다. 이와 같은 별도의 필드를 두는 이유는, 클라이언트의 경우 명시적으로 다른 클라이언트와의 통신을 위해 채널을 생성하므로 미디어 키의 생성 및 소멸 주기를 상기 채널의 생성/소멸 주기와 동기화할 수 있으나, 릴레이 서버의 경우 단순히 클라이언트로부터 수신한 메시지를 중계하는 역할만을 하므로 채널의 생성/소멸을 알 수 없어 미디어 키의 라이프사이클(lifecycle) 관리가 불가능하기 때문이다.
- SenderMediaKeyNo(2byte): 메시지를 전송하는 클라이언트가 발급한 미디어 키가 저장된다.
- SenderRelayMediaKeyNo(2byte): 메시지를 전송하는 클라이언트와 연결된 릴레이 서버가 발급한 미디어 키가 저장된다.
- ReceiverMediaKeyNo(2byte): 메시지를 수신하는 클라이언트가 발급한 미디어 키가 저장된다.
- ReceiverRelayMediaKeyNo(2byte): 메시지를 수신하는 클라이언트와 연결된 릴레이 서버가 발급한 미디어 키가 저장된다.
이하의 설명 및 도면에서 예를 들어, (K1, 0, 0, K4)라고 표현된 경우에는 상기 확장 필드에 송신 클라이언트의 미디어 키(K1) 및 수신측 릴레이 서버의 미디어 키(K2)가 발급되어 저장된 상태를 나타낸다. 0은 아직 필드에 대응하는 해당 미디어 키가 발급되지 않았음을 나타낸다.
이하에서는, 도 2를 참조하여 구체적인 각 구성요소 간의 미디어 키 발급 및 교환 절차를 설명한다.
먼저, 제1 클라이언트(102)는 자신의 미디어 키(K1)를 발급하고(202), 상기 K1을 포함하는 채널 생성 메시지(INVITE)를 제2 릴레이 서버(108)로 송신한다(204). 이때, 상기 채널 생성 메시지의 확장 필드에는 상기 K1만이 포함되며, 나머지 필드는 0으로 채워진다(K1, 0, 0, 0).
상기 채널 생성 메시지를 수신한 제2 릴레이 서버(108)는 자신의 미디어 키(K4)를 발급하고(206), 이를 상기 확장 필드에 부가하여(K1, 0, 0, K4) 제2 클라이언트(104)로 송신한다(208).
이후, 상기 채널 생성 메시지를 수신한 제2 클라이언트(104)는 자신의 미디어 키(K2)를 발급하고(210), 수신된 K1, K4 및 발급된 K2를 상기 채널 생성 메시지에 대응하는 채널 생성 응답 메시지(ACK)의 헤더의 확장 필드에 부가하여(K2, K4, K1, 0) 제1 릴레이 서버(106)로 송신한다(212).
제1 릴레이 서버(106)는 상기 제2 클라이언트(104)로부터 수신된 상기 채널 생성 응답 메시지로부터 상기 제1 클라이언트(102)의 미디어 키(K1)를 획득한다(214). 이때, 제1 릴레이 서버(106)는 상기 채널 생성 응답 메시지의 헤더로부터 상기 K1과 함께 제1 클라이언트(102)의 네트워크 주소를 함께 획득하고 이를 상기 K1과 매핑하여 저장한다. 그 이유는 상기 키 미디어 키 분배 과정이 종료되면 이후의 미디어 데이터 헤더에는 분배된 미디어 키만을 포함할 뿐, 수신 클라이언트의 네트워크 주소를 가지고 있지 않기 때문이다. 즉, 제1 릴레이 서버(106)는 제2 클라이언트(104)로부터 메시지를 수신할 경우 상기 K1과 매핑된 제1 클라이언트(102)의 네트워크 주소를 이용하여 제1 클라이언트(102)로 해당 메시지를 전송한다.
이후, 제1 릴레이 서버(106)는 자신의 미디어 키(K3)를 발급한 뒤(216), 이를 상기 채널 생성 응답 메시지에 부가하여(K2, K4, K1, K3) 제1 클라이언트(102)로 송신한다(218).
제1 클라이언트(102)는 상기 채널 생성 응답 메시지를 수신하여 이로부터 제2 릴레이 서버(108)의 미디어 키(K4)를 획득하고(220), 제1 클라이언트(102)의 미디어 키(K1), 제1 릴레이 서버(106)의 미디어 키(K3), 제2 클라이언트(104)의 미디어 키(K2) 및 제2 릴레이 서버(108)의 미디어 키(K4)를 포함하는 미디어 데이터 전송 메시지(PlaceCall(K1, K3, K2, K4))를 생성하여 상기 제2 릴레이 서버(108)로 송신한다(222).
제2 릴레이 서버(108)는 수신된 상기 미디어 데이터 전송 메시지로부터 제2 클라이언트(104)의 미디어 키(K2)를 획득한다(224). 이때, 제2 릴레이 서버(108)는 제1 릴레이 서버(106)와 마찬가지로 상기 미디어 데이터 전송 메시지로부터 제2 클라이언트(104)의 네트워크 주소를 획득하고 이를 상기 K2와 매핑하여 저장한다.
이후, 제2 릴레이 서버(108)는 수신된 상기 미디어 데이터 전송 메시지를 제2 클라이언트(104)로 송신한다(226).
마지막으로, 제2 클라이언트(104)에서 수신된 상기 미디어 데이터 전송 메시지로부터 상기 제1 릴레이 서버(106)의 미디어 키(K3)를 획득함으로써 미디어 키 분배 과정이 완료된다(228).
도 3은 도 2와 같은 과정을 거쳐 분배된 미디어 키를 삭제하기 위한 과정을 설명하기 위한 순서도(300)이다. 전술한 바와 같이, 제1 클라이언트(102) 및 제2 클라이언트(104)는 메시지 송수신을 위한 채널 생성 시 미디어 키를 생성하고, 상기 채널이 소멸되는 경우 미디어 키를 삭제하므로 별도의 미디어 키 삭제 명령이 필요 없다. 그러나 제1 릴레이 서버(106) 및 제2 릴레이 서버(108)는 단순히 제1 클라이언트(102) 및 제2 클라이언트(104)로부터 수신되는 메시지를 중계하는 역할을 하므로 언제 채널이 생성되고 소멸되는지를 알 수 없기 때문에 별도의 절차를 통하여 미디어 키를 삭제하여야 한다.
릴레이 서버에서의 미디어 키를 삭제하기 위해서, 미디어 데이터의 전송을 중단하기 위한 메시지(HangUpCallAsk 및 HangUpCallRep)를 사용한다. 상기 HangUpCallAsk 및 HangUpCallRep 메시지 또한 상기 미디어 키 분배를 위한 메시지와 동일한 형태의 헤더를 사용하나, 확장 필드의 첫 번째 필드인 MediaKeyCmd에 미디어 키 삭제 명령인 "D"가 기재된다는 점이 다르다.
이하, 미디어 키 삭제 과정을 구체적으로 설명하면 다음과 같다.
먼저, 제1 클라이언트(102)에서, 제2 릴레이 서버(108)로 미디어 데이터 전송 중단 메시지(HangUpCallAsk)를 송신하면(302), 이를 수신한 제2 릴레이 서버(108)는 자신이 발급한 미디어 키(K4)를 삭제하고(304), 수신된 미디어 데이터 전송 중단 메시지를 제2 클라이언트(104)로 송신한다(306).
이후 제2 클라이언트(104)는 수신된 미디어 데이터 전송 중단 메시지에 대응하는 미디어 데이터 전송 중단 응답 메시지(HangUpCallRep)를 제1 릴레이 서버(106)로 송신한다(308). 제1 릴레이 서버(106)는 수신된 상기 미디어 데이터 전송 중단 응답 메시지에 따라 자신이 발급한 미디어 키(K3)를 삭제하고(310), 수신된 미디어 데이터 전송 중단 응답 메시지를 제1 클라이언트(102)로 송신함으로써(312) 미디어 키 삭제 절차가 마무리된다.
한편, 제1 릴레이 서버(106) 및 제2 릴레이 서버(108)에서의 미디어 키 삭제 절차는 상기와 같은 방법을 통하여 명시적으로 이루어질 수도 있으나, 이와 달리 릴레이 서버에서 클라이언트로부터 일정 기간 동안 새로운 메시지가 수신되지 않는 경우 해당 미디어 키를 삭제하도록 구성하는 것 또한 가능하다. 예를 들어, 릴레이 서버는 미디어 키와 함께 메시지의 수신 여부를 체크할 수 있는 플래그(flag)를 별도로 매핑하여 관리할 수 있다. 이 경우 릴레이 서버는 기 설정된 타이머 등을 이용하여 일정 주기마다 모든 미디어 키의 플래그를 false로 초기화한 뒤, 미디어 데이터가 수신된 미디어 키의 플래그만을 true로 설정하고 해당 주기가 종료된 시점에서 여전히 false로 남아있는 미디어 키를 삭제함으로써 미디어 키의 라이프사이클을 관리할 수 있다. 이와 같이 미디어 키를 주기적으로 정리할 경우, 클라이언트간에 명시적인 데이터 전송 중단 메시지의 송수신 없이 데이터 송수신이 비정상적으로 종료된 경우에도 릴레이 서버의 미디어 키가 계속 유지되는 것을 막을 수 있어 미디어 키를 효과적으로 관리할 수 있게 된다.
도 4는 도 2와 같은 절차를 거쳐 미디어 키 분배 과정이 완료된 경우 클라이언트간의 미디어 데이터의 송수신 과정을 설명하기 위한 순서도(400)이다. 도면에서 402 내지 406 단계는 제 클라이언트(102)에서 제2 클라이언트(104)로 미디어 데이터를 송신하는 과정을 나타낸 것이고, 408 내지 412 단계는 제2 클라이언트(104)에서 제1 클라이언트(102)로 미디어 데이터를 송신하는 과정을 나타낸 것이다.
전술한 바와 같이, 미디어 키가 분배된 이후, 각 미디어 데이터들은 미디어 키가 포함된 간단한 형태의 헤더만을 포함하여 전송된다. 상기 헤더는 4바이트로 구성되며, 그 구조는 다음과 같이 구성될 수 있다.
- Prefix(1byte): 해당 메시지가 미디어 데이터임을 표현하기 위한 용도로 사용하는 것으로서, "M" 으로 고정된 값을 가진다.
- Media Key(2byte): 해당 메시지를 수신한 측에서 발급한 미디어 키 값이 포함된다. 예를 들어, 제1 클라이언트(102)가 제2 릴레이 서버(108)로 미디어 데이터를 전송할 경우 본 필드에는 제2 필레이 서버(108)가 발급한 K4가 포함된다.
- Media Type(1byte): 해당 메시지를 송수신하는 송신 클라이언트 및 수신 클라이언트간에 생성된 세션의 채널값이 포함된다.
이와 같이, 본 발명의 경우 미디어 데이터 전송 시 송신 또는 수신 클라이언트의 네트워크 주소 등을 포함하는 복잡한 필드를 포함할 필요 없이 상기와 같은 4바이트의 경량화된 헤더만을 부가하여 전송되므로 특히 소용량의 데이터가 빈번하게 송수신되는 형태의 피어-투-피어 데이터 송수신 시스템에서의 데이터 전송 오버헤드를 현저히 감소시킬 수 있다.
상기와 같은 헤더 구조를 이용하여, 먼저 제1 클라이언트(102)에서 제2 클라이언트(104)로 미디어 데이터를 송신하는 과정을 설명하면 다음과 같다. 먼저, 제1 클라이언트(102)는 전송하려는 미디어 데이터의 헤더에 제2 릴레이 서버(108)의 미디어 키(K4)를 부가하여 제2 릴레이 서버(108)로 송신한다(402). 이후 제2 릴레이 서버(108)는 수신된 미디어 데이터에 포함된 제2 릴레이 서버(108)의 미디어 키(K4)를 제2 클라이언트(104)의 미디어 키(K2)로 치환하고(404), 상기 K2와 매핑된 제2 클라이언트(104)의 네트워크 주소를 이용하여 미디어 데이터를 제2 클라이언트(104)로 송신한다(406).
다음으로, 제2 클라이언트(104)에서 제1 클라이언트(102)로 미디어 데이터를 송신하는 과정을 설명하면 다음과 같다. 제2 클라이언트(104)는 전송하려는 미디어 데이터의 헤더에 제1 릴레이 서버(106)의 미디어 키(K3)를 부가하여 제1 릴레이 서버(106)로 송신한다(408). 이후 제1 릴레이 서버(106)는 수신된 미디어 데이터에 포함된 제1 릴레이 서버(106)의 미디어 키(K3)를 제1 클라이언트(102)의 미디어 키(K1)로 치환하고(410), 상기 K1과 매핑된 제1 클라이언트(102)의 네트워크 주소를 이용하여 미디어 데이터를 제1 클라이언트(102)로 송신한다(412).
한편, 본 발명의 실시예에서 제1 클라이언트(102), 제2 클라이언트(104), 제1 릴레이 서버(106) 및 제2 릴레이 서버(108)가 발급하여 분배하는 각각의 미디어 키는 메시지 전송에 관련된 클라이언트 및 릴레이 서버 내에서만 사용되므로, 해당 키들은 전체 시스템 내에서 유일한 키일 필요는 없으며, 각 클라이언트 또는 릴레이 서버 내부에서만 유일한 키(locally unique key)를 발급하는 것으로 충분하다. 따라서 본 발명의 경우, 각각의 미디어 키 발급 과정에서 키의 유일성 확인을 위해 별도의 키 발급 서버 등과 통신을 수행할 필요가 없으므로 빠른 속도로 미디어 키를 발급 및 삭제할 수 있으며, 발급된 키를 별도로 중앙 서버에서 관리할 필요가 없는 장점이 있다.
또한, 본 발명의 실시예에서는 모든 메시지가 릴레이 서버를 경유하는 것으로 기재하였으나, 실시예에 따라 채널 생성 과정에서만 홀 펀칭 등을 위하여 릴레이 서버를 경유하고 실제 메시지는 릴레이 서버를 거치지 않고 상대방 클라이언트로 바로 전송하는 경우가 있을 수 있다. 이 경우는 채널 생성을 위한 INVITE, ACK 메시지 전송 시 확장 필드를 비워놓지 않고 자신이 발급한 미디어 키를 릴레이 서버의 미디어 키 자리에 채워 넣음으로써 릴레이 서버에서 불필요하게 미디어 키를 발급하는 것을 막을 수 있다. 예를 들어, 204 단계에서 제1 클라이언트(102)에서 INVITE 메시지를 송신할 경우 확장 필드에 (K1, K1, 0, K1)과 같이 기재하면 제2 릴레이 서버(108)에서 이를 인식하고 별도의 K4를 발급하지 않게 된다. 마찬가지로, 212 단계에서 제2 클라이언트(104)가 ACK 메시지를 송신할 경우에도 확장 필드에 (K2, K2, K1, K2)와 같이 기재할 경우 제1 릴레이 서버(106)에서 이를 인식하고 별도의 K3를 발급하지 않게 된다.
한편, 본 발명의 실시예는 본 명세서에서 기술한 방법들을 컴퓨터상에서 수행하기 위한 프로그램을 포함하는 컴퓨터 판독 가능 기록매체를 포함할 수 있다. 상기 컴퓨터 판독 가능 기록매체는 프로그램 명령, 로컬 데이터 파일, 로컬 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 매체는 본 발명을 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 분야에서 통상의 지식을 가진 자에게 공지되어 사용 가능한 것일 수도 있다. 컴퓨터 판독 가능 기록매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체, CD-ROM, DVD와 같은 광 기록 매체, 플로피 디스크와 같은 자기-광 매체, 및 롬, 램, 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함할 수 있다.
이상에서 대표적인 실시예를 통하여 본 발명에 대하여 상세하게 설명하였으나, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자는 상술한 실시예에 대하여 본 발명의 범주에서 벗어나지 않는 한도 내에서 다양한 변형이 가능함을 이해할 것이다.
그러므로 본 발명의 권리범위는 설명된 실시예에 국한되어 정해져서는 안 되며, 후술하는 특허청구범위뿐만 아니라 이 특허청구범위와 균등한 것들에 의해 정해져야 한다.

Claims (25)

  1. 제1 클라이언트, 제2 클라이언트, 제1 릴레이 서버 및 제2 릴레이 서버 간 미디어 키를 분배하기 위한 방법으로서,
    상기 제1 클라이언트에서, 제1 메시지를 생성하고, 생성된 상기 제1 메시지를 상기 제2 릴레이 서버를 경유하여 상기 제2 클라이언트로 송신하는 제1 단계;
    상기 제2 클라이언트에서, 수신된 상기 제1 메시지에 대응하는 제2 메시지를 생성하는 제2 단계;
    상기 제1 릴레이 서버에서, 상기 제2 클라이언트로부터 상기 제2 메시지를 수신하고, 수신된 상기 제2 메시지에 포함된 상기 제1 클라이언트의 미디어 키를 획득하는 제3 단계;
    상기 제1 클라이언트에서, 상기 제1 릴레이 서버로부터 상기 제2 메시지를 수신하고, 수신한 상기 제2 메시지에 포함된 상기 제2 릴레이 서버의 미디어 키를 획득하는 제4 단계;
    상기 제2 릴레이 서버에서, 상기 제1 클라이언트로부터 제3 메시지를 수신하고, 수신된 상기 제3 메시지에 포함된 상기 제2 클라이언트의 미디어 키를 획득하는 제5 단계; 및
    상기 제2 클라이언트에서, 상기 제2 릴레이 서버로부터 상기 제3 메시지를 수신하고, 수신된 상기 제3 메시지에 포함된 상기 제1 릴레이 서버의 미디어 키를 획득하는 제6 단계를 포함하는 미디어 키 관리 방법.
  2. 청구항 1에 있어서,
    상기 제1 메시지는 채널 생성 메시지(INVITE)이고, 상기 제2 메시지는 상기 채널 생성 메시지에 대응하는 채널 생성 응답 메시지(ACK)이며, 상기 제3 메시지는 미디어 데이터 전송 메시지(PlaceCall)인, 미디어 키 관리 방법.
  3. 청구항 2에 있어서,
    상기 제1단계는,
    상기 제1 클라이언트에서, 상기 제1 클라이언트의 미디어 키를 생성하고, 생성된 상기 제1 클라이언트의 미디어 키를 포함하는 채널 생성 메시지를 제2 릴레이 서버로 송신하는 단계; 및
    상기 제2 릴레이 서버에서, 상기 제2 릴레이 서버의 미디어 키를 생성하고, 상기 제1 클라이언트로부터 수신한 상기 채널 생성 메시지에 상기 제2 릴레이 서버의 미디어 키를 부가하여 제2 클라이언트로 송신하는 단계를 더 포함하고,
    상기 제3 단계는, 상기 제2 클라이언트에서, 상기 제2 릴레이 서버로부터 상기 채널 생성 메시지를 수신하는 단계;
    상기 제2 클라이언트에서, 상기 제2 클라이언트의 미디어 키를 생성하고, 상기 제1 클라이언트의 미디어 키, 상기 제2 릴레이 서버의 미디어 키 및 상기 제2 클라이언트의 미디어 키를 포함하는 채널 생성 응답 메시지를 제1 릴레이 서버로 송신하는 단계; 및
    상기 제1 릴레이 서버에서, 상기 제2 클라이언트로부터 수신된 상기 채널 생성 응답 메시지로부터 상기 제1 클라이언트의 미디어 키를 획득하여 저장하는 단계를 더 포함하며,
    상기 제4 단계는, 상기 제1 릴레이 서버에서, 상기 제1 릴레이 서버의 미디어 키를 생성하고, 상기 제2 클라이언트로부터 수신한 상기 채널 생성 응답 메시지에 생성된 상기 제1 릴레이 서버의 미디어 키를 부가하여 제1 클라이언트로 송신하는 단계; 및
    상기 제1 클라이언트에서, 상기 제1 릴레이 서버로부터 수신된 상기 채널 생성 응답 메시지로부터 상기 제2 릴레이 서버의 미디어 키를 획득하여 저장하는 단계를 더 포함하고,
    상기 제5 단계는, 상기 제1 클라이언트에서, 상기 제1 클라이언트의 미디어 키, 상기 제1 릴레이 서버의 미디어 키, 상기 제2 클라이언트의 미디어 키 및 상기 제2 릴레이 서버의 미디어 키를 포함하는 미디어 데이터 전송 메시지 생성하고, 생성된 상기 미디어 데이터 전송 메시지를 상기 제2 릴레이 서버로 송신하는 단계; 및
    상기 제2 릴레이 서버에서, 수신된 상기 미디어 데이터 전송 메시지로부터 상기 제2 클라이언트의 미디어 키를 획득하여 저장하는 단계를 더 포함하며,
    상기 제6 단계는, 상기 제2 릴레이 서버에서, 수신된 상기 미디어 데이터 전송 메시지를 상기 제2 클라이언트로 송신하는 단계; 및
    상기 제2 클라이언트에서, 수신된 상기 미디어 데이터 전송 메시지로부터 상기 제1 릴레이 서버의 미디어 키를 획득하여 저장하는 단계를 더 포함하는 미디어 키 관리 방법.
  4. 청구항 3에 있어서,
    상기 제1 릴레이 서버에서 상기 제1 클라이언트의 미디어 키를 획득하여 저장하는 단계는,
    상기 제1 릴레이 서버에서, 수신된 상기 채널 응답 메시지로부터 상기 제1 클라이언트의 네트워크 주소를 획득하는 단계; 및
    상기 제1 릴레이 서버에서, 획득된 상기 제1 클라이언트의 네트워크 주소를 상기 제1 클라이언트의 미디어 키와 매핑하여 저장하는 단계를 더 포함하는 미디어 키 관리 방법.
  5. 청구항 3에 있어서,
    상기 제2 릴레이 서버에서 상기 제2 클라이언트의 미디어 키를 획득하여 저장하는 단계는,
    상기 제2 릴레이 서버에서, 상기 미디어 데이터 전송 메시지로부터 상기 제2 클라이언트의 네트워크 주소를 획득하는 단계; 및
    상기 제2 릴레이 서버에서, 획득된 상기 제2 클라이언트의 네트워크 주소를 상기 제2 클라이언트의 미디어 키와 매핑하여 저장하는 단계를 더 포함하는 미디어 키 관리 방법.
  6. 청구항 2에 있어서,
    상기 제6 단계의 수행 이후,
    상기 제1 클라이언트에서, 상기 제2 릴레이 서버로 미디어 데이터 전송 중단 메시지를 송신하는 단계;
    상기 제2 릴레이 서버에서, 수신된 상기 미디어 데이터 전송 중단 메시지에 따라 상기 제2 릴레이 서버의 미디어 키를 삭제하고, 수신된 상기 미디어 데이터 전송 중단 메시지를 상기 제2 클라이언트로 송신하는 단계;
    상기 제2 클라이언트에서, 수신된 상기 미디어 데이터 전송 중단 메시지에 대응하는 미디어 데이터 전송 중단 응답 메시지를 상기 제1 릴레이 서버로 송신하는 단계; 및
    상기 제1 릴레이 서버에서, 수신된 상기 미디어 데이터 전송 중단 응답 메시지에 따라 상기 제1 릴레이 서버의 미디어 키를 삭제하고, 수신된 상기 미디어 데이터 전송 중단 응답 메시지를 상기 제1 클라이언트로 송신하는 단계를 더 포함하는 미디어 키 관리 방법.
  7. 제1 메시지를 생성하고, 생성된 제1 메시지를 제2 릴레이 서버를 경유하여 제2 클라이언트로 송신하며, 상기 제2 클라이언트로부터 송신되어 제1 릴레이 서버를 경유하여 전송되는 제2 메시지를 수신하고, 수신한 상기 제2 메시지에 포함된 상기 제2 릴레이 서버의 미디어 키를 획득하는 제1 클라이언트;
    상기 제2 클라이언트로부터 상기 제1 메시지에 대응하는 상기 제2 메시지를 수신하고, 수신된 상기 제2 메시지에 포함된 상기 제1 클라이언트의 미디어 키를 획득하는 제1 릴레이 서버;
    상기 제1 클라이언트로부터 제3 메시지를 수신하고, 수신된 상기 제3 메시지에 포함된 상기 제2 클라이언트의 미디어 키를 획득하는 제2 릴레이 서버; 및
    상기 제1 클라이언트로부터 송신되어 상기 제2 릴레이 서버를 경유하여 전송되는 상기 제3 메시지를 수신하고, 수신된 상기 제3 메시지에 포함된 상기 제1 릴레이 서버의 미디어 키를 획득하는 제2 클라이언트를 포함하는 미디어 키 관리 시스템.
  8. 청구항 7에 있어서,
    상기 제1 메시지는 채널 생성 메시지(INVITE)이고, 상기 제2 메시지는 상기 채널 생성 메시지에 대응하는 채널 생성 응답 메시지(ACK)이며, 상기 제3 메시지는 미디어 데이터 전송 메시지(PlaceCall)인, 미디어 키 관리 시스템.
  9. 청구항 8에 있어서,
    상기 제1 클라이언트는, 상기 제1 클라이언트의 미디어 키를 생성하고, 생성된 상기 제1 클라이언트의 미디어 키를 포함하는 채널 생성 메시지를 제2 릴레이 서버로 송신하며,
    상기 제2 릴레이 서버는, 상기 제2 릴레이 서버의 미디어 키를 생성하고, 상기 제1 클라이언트로부터 수신한 상기 채널 생성 메시지에 상기 제2 릴레이 서버의 미디어 키를 부가하여 제2 클라이언트로 송신하는, 미디어 키 관리 시스템.
  10. 청구항 9에 있어서,
    상기 제2 클라이언트는, 상기 제2 릴레이 서버로부터 상기 채널 생성 메시지를 수신하고, 상기 제2 클라이언트의 미디어 키를 생성하며, 상기 제1 클라이언트의 미디어 키, 상기 제2 릴레이 서버의 미디어 키 및 상기 제2 클라이언트의 미디어 키를 포함하는 채널 생성 응답 메시지를 제1 릴레이 서버로 송신하고,
    상기 제1 릴레이 서버는, 상기 제2 클라이언트로부터 수신된 상기 채널 생성 응답 메시지로부터 상기 제1 클라이언트의 미디어 키를 획득하여 저장하는, 미디어 키 관리 시스템.
  11. 청구항 10에 있어서,
    상기 제1 릴레이 서버는, 상기 제2 클라이언트로부터 수신된 상기 채널 응답 메시지로부터 상기 제1 클라이언트의 네트워크 주소를 획득하고, 획득된 상기 제1 클라이언트의 네트워크 주소를 상기 제1 클라이언트의 미디어 키와 매핑하여 저장하는, 미디어 키 관리 시스템.
  12. 청구항 10에 있어서,
    상기 제1 릴레이 서버는, 상기 제1 릴레이 서버의 미디어 키를 생성하고, 상기 제2 클라이언트로부터 수신한 상기 채널 생성 응답 메시지에 생성된 상기 제1 릴레이 서버의 미디어 키를 부가하여 제1 클라이언트로 송신하며,
    상기 제1 클라이언트는, 상기 제1 릴레이 서버로부터 수신된 상기 채널 생성 응답 메시지로부터 상기 제2 릴레이 서버의 미디어 키를 획득하여 저장하는, 미디어 키 관리 시스템.
  13. 청구항 12에 있어서,
    상기 제1 클라이언트는, 상기 제1 클라이언트의 미디어 키, 상기 제1 릴레이 서버의 미디어 키, 상기 제2 클라이언트의 미디어 키 및 상기 제2 릴레이 서버의 미디어 키를 포함하는 미디어 데이터 전송 메시지를 상기 제2 릴레이 서버로 송신하며,
    상기 제2 릴레이 서버는, 수신된 상기 미디어 데이터 전송 메시지로부터 상기 제2 클라이언트의 미디어 키를 획득하여 저장하는, 미디어 키 관리 시스템.
  14. 청구항 13에 있어서,
    상기 제2 릴레이 서버는, 상기 미디어 데이터 전송 메시지로부터 상기 제2 클라이언트의 네트워크 주소를 획득하고, 획득된 상기 제2 클라이언트의 네트워크 주소를 상기 제2 클라이언트의 미디어 키와 매핑하여 저장하는, 미디어 키 관리 시스템.
  15. 청구항 13에 있어서,
    상기 제2 릴레이 서버는, 수신된 상기 미디어 데이터 전송 메시지를 상기 제2 클라이언트로 송신하고,
    상기 제2 클라이언트는, 수신된 상기 미디어 데이터 전송 메시지로부터 상기 제1 릴레이 서버의 미디어 키를 획득하여 저장하는, 미디어 키 관리 시스템.
  16. 청구항 8에 있어서,
    상기 제1 클라이언트는, 상기 제2 릴레이 서버로 미디어 데이터 전송 중단 메시지를 송신하고,
    상기 제2 릴레이 서버는, 수신된 상기 미디어 데이터 전송 중단 메시지에 따라 상기 제2 릴레이 서버의 미디어 키를 삭제하고, 수신된 상기 미디어 데이터 전송 중단 메시지를 상기 제2 클라이언트로 송신하며,
    상기 제2 클라이언트는, 수신된 상기 미디어 데이터 전송 중단 메시지에 대응하는 미디어 데이터 전송 중단 응답 메시지를 상기 제1 릴레이 서버로 송신하고,
    상기 제1 릴레이 서버는, 수신된 상기 미디어 데이터 전송 중단 응답 메시지에 따라 상기 제1 릴레이 서버의 미디어 키를 삭제하고, 수신된 상기 미디어 데이터 전송 중단 응답 메시지를 상기 제1 클라이언트로 송신하는, 미디어 키 관리 시스템.
  17. 미디어 데이터에 수신측 릴레이 서버로부터 발급된 제1 미디어 키를 부가하여 수신측 릴레이 서버로 송신하는 송신 클라이언트;
    상기 송신 클라이언트로 상기 제1 미디어 키를 발급하며, 상기 송신 클라이언트로부터 상기 미디어 데이터를 수신하고, 수신된 상기 미디어 데이터에 부가된 상기 제1 미디어 키를 수신 클라이언트로부터 발급된 제2 미디어 키로 치환하여 수신 클라이언트로 송신하는 수신측 릴레이 서버; 및
    상기 수신측 릴레이 서버로 상기 제2 미디어 키를 발급하며, 상기 수신측 릴레이 서버로부터 상기 미디어 데이터를 수신하는 수신 클라이언트를 포함하는 피어-투-피어 메시지 송수신 시스템.
  18. 청구항 17에 있어서,
    상기 수신측 릴레이 서버는 상기 제2 미디어 키와 대응되는 상기 수신 클라이언트의 네트워크 주소를 저장 및 관리하며, 상기 수신 클라이언트의 네트워크 주소를 이용하여 상기 미디어 데이터를 상기 수신 클라이언트로 송신하는 메시지 송수신 시스템.
  19. 청구항 17에 있어서,
    상기 수신측 릴레이 서버는 상기 송신 클라이언트로부터 미디어 키 삭제 메시지가 수신되는 경우 상기 제1 미디어 키를 삭제하고, 수신된 상기 미디어 키 삭제 메시지를 상기 수신 클라이언트로 송신하는, 메시지 송수신 시스템.
  20. 청구항 17에 있어서,
    상기 수신측 릴레이 서버는 기 설정된 시간 동안 상기 송신 클라이언트로부터 새로운 미디어 데이터가 수신되지 않는 경우, 상기 제1 미디어 키를 삭제하는, 메시지 송수신 시스템.
  21. 송신 클라이언트에서, 미디어 데이터에 수신 릴레이 서버로부터 발급된 제1 미디어 키를 부가하여 수신측 릴레이 서버로 송신하는 단계;
    상기 수신측 릴레이 서버에서, 상기 송신 클라이언트로부터 상기 미디어 데이터를 수신하고, 수신된 상기 미디어 데이터에 부가된 상기 제1 미디어 키를 수신 클라이언트로부터 발급된 제2 미디어 키로 치환하여 수신 클라이언트로 송신하는 단계; 및
    상기 수신 클라이언트에서, 상기 수신측 릴레이 서버로부터 상기 미디어 데이터를 수신하는 단계를 포함하는 피어-투-피어 메시지 송수신 방법.
  22. 청구항 21에 있어서,
    상기 수신측 릴레이 서버는 상기 제2 미디어 키와 대응되어 기 저장된 상기 수신 클라이언트의 네트워크 주소를 이용하여 상기 미디어 데이터를 상기 수신 클라이언트로 송신하는, 메시지 송수신 방법.
  23. 청구항 21에 있어서,
    상기 미디어 데이터 수신 단계의 수행 이후,
    상기 송신 클라이언트에서 상기 수신측 릴레이 서버로 미디어 키 삭제 메시지를 송신하는 단계;
    상기 수신측 릴레이 서버에서, 수신된 상기 미디어 키 삭제 메시지에 따라 기 저장된 상기 제1 미디어 키를 삭제하는 단계; 및
    상기 수신측 릴레이 서버에서, 수신된 상기 미디어 키 삭제 메시지를 상기 수신 클라이언트로 송신하는 단계를 더 포함하는 메시지 송수신 방법.
  24. 청구항 21에 있어서,
    상기 미디어 데이터 수신 단계의 수행 이후,
    상기 수신측 릴레이 서버에서, 기 설정된 시간 동안 상기 송신 클라이언트로부터 새로운 미디어 데이터가 수신되지 않는 경우 상기 제1 미디어 키를 삭제하는 단계를 더 포함하는 메시지 송수신 방법.
  25. 청구항 1 내지 청구항 6, 또는 청구항 21 내지 청구항 24 중 어느 한 항에 기재된 방법을 컴퓨터상에서 수행하기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체.
PCT/KR2012/007340 2011-09-26 2012-09-13 미디어 키 관리 및 상기 미디어 키를 이용한 피어-투-피어 메시지 송수신 시스템 및 방법 WO2013048038A2 (ko)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201280046835.XA CN103843298B (zh) 2011-09-26 2012-09-13 媒体密钥管理及利用该媒体密钥的p2p消息收发系统和方法
US14/347,577 US20140237063A1 (en) 2011-09-26 2012-09-13 System and method for transmitting and receiving peer-to-peer messages using a media key, and managing the media key

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020110097027A KR101240552B1 (ko) 2011-09-26 2011-09-26 미디어 키 관리 및 상기 미디어 키를 이용한 피어-투-피어 메시지 송수신 시스템 및 방법
KR10-2011-0097027 2011-09-26

Publications (2)

Publication Number Publication Date
WO2013048038A2 true WO2013048038A2 (ko) 2013-04-04
WO2013048038A3 WO2013048038A3 (ko) 2013-07-04

Family

ID=47996578

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2012/007340 WO2013048038A2 (ko) 2011-09-26 2012-09-13 미디어 키 관리 및 상기 미디어 키를 이용한 피어-투-피어 메시지 송수신 시스템 및 방법

Country Status (4)

Country Link
US (1) US20140237063A1 (ko)
KR (1) KR101240552B1 (ko)
CN (1) CN103843298B (ko)
WO (1) WO2013048038A2 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017003215A1 (ko) * 2015-06-30 2017-01-05 투이이피 주식회사 라우팅 방법 및 이를 수행하는 네트워크 엔티티
US10681755B2 (en) 2015-06-30 2020-06-09 2Ip Co., Ltd. Routing method and network entity performing same

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9185021B1 (en) * 2012-10-15 2015-11-10 Wal-Mart Stores, Inc. Content based routing architecture system and method
KR101508859B1 (ko) 2013-12-30 2015-04-07 삼성에스디에스 주식회사 클라이언트와 서버 간 보안 세션을 수립하기 위한 방법 및 장치
KR102144509B1 (ko) * 2014-03-06 2020-08-14 삼성전자주식회사 근접 통신 방법 및 장치
CN104284237A (zh) * 2014-10-13 2015-01-14 中安消技术有限公司 视频传输方法及系统
KR101785385B1 (ko) * 2015-07-10 2017-10-16 주식회사 투아이피 네트워크 경로를 관리하는 방법 및 이를 수행하는 네트워크 엔티티
CN108270523B (zh) * 2017-12-27 2021-04-02 成都卫士通信息产业股份有限公司 带内密钥协商传输方法及传输系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060069800A1 (en) * 2004-09-03 2006-03-30 Microsoft Corporation System and method for erasure coding of streaming media
US20090116430A1 (en) * 2007-11-07 2009-05-07 Motorola, Inc. System for enabling mobile coverage extension and peer-to-peer communications in an ad hoc network and method of operation therefor
KR20100136533A (ko) * 2003-06-05 2010-12-28 인터트러스트 테크놀로지즈 코포레이션 Ｐ2ｐ 서비스 편성을 위한 상호운용 시스템 및 방법
US20110010768A1 (en) * 2007-11-29 2011-01-13 Telefonaktiebolaget Lm Ericsson (Publ) Method and Apparatuses for End-to-Edge Media Protection in ANIMS System

Family Cites Families (56)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB9503738D0 (en) * 1995-02-24 1995-04-19 Int Computers Ltd Cryptographic key management
US5602918A (en) * 1995-12-22 1997-02-11 Virtual Open Network Environment Corp. Application level security system and method
US5956404A (en) * 1996-09-30 1999-09-21 Schneier; Bruce Digital signature with auditing bits
US20020087862A1 (en) * 2000-01-07 2002-07-04 Sandeep Jain Trusted intermediary
JP3386117B2 (ja) * 2000-01-11 2003-03-17 日本電気株式会社 マルチレイヤクラス識別通信装置と通信装置
US20020161848A1 (en) * 2000-03-03 2002-10-31 Willman Charles A. Systems and methods for facilitating memory access in information management environments
US7016847B1 (en) * 2000-12-08 2006-03-21 Ben Franklin Patent Holdings L.L.C. Open architecture for a voice user interface
JP2002247047A (ja) * 2000-12-14 2002-08-30 Furukawa Electric Co Ltd:The セッション共有鍵共有方法、無線端末認証方法、無線端末および基地局装置
US6879690B2 (en) * 2001-02-21 2005-04-12 Nokia Corporation Method and system for delegation of security procedures to a visited domain
US7181017B1 (en) * 2001-03-23 2007-02-20 David Felsher System and method for secure three-party communications
JP3963690B2 (ja) * 2001-03-27 2007-08-22 富士通株式会社 パケット中継処理装置
US7995603B2 (en) * 2001-05-22 2011-08-09 Nds Limited Secure digital content delivery system and method over a broadcast network
US7089298B2 (en) * 2001-08-20 2006-08-08 Nokia Corporation Naming distribution method for ad hoc networks
RU2298824C2 (ru) * 2001-09-28 2007-05-10 Хай Денсити Дивайсез Ас Способ и устройство для шифрования/дешифрования данных в запоминающем устройстве большой емкости
US7234063B1 (en) * 2002-08-27 2007-06-19 Cisco Technology, Inc. Method and apparatus for generating pairwise cryptographic transforms based on group keys
US7580980B2 (en) * 2002-12-20 2009-08-25 Nippon Telegraph And Telephone Corporation Email system restoring recipient identifier based on identifier-for-disclosure for establishing communication between sender and recipient
US8483105B2 (en) * 2003-10-15 2013-07-09 Qualcomm Incorporated High speed media access control
WO2005046126A1 (en) * 2003-10-31 2005-05-19 Juniper Networks, Inc. Secure transport of multicast traffic
KR100651716B1 (ko) * 2004-10-11 2006-12-01 한국전자통신연구원 Ｄｉａｍｅｔｅｒ 기반 프로토콜에서 모바일 네트워크의부트스트랩핑 방법 및 그 시스템
JP4707992B2 (ja) * 2004-10-22 2011-06-22 富士通株式会社 暗号化通信システム
US20070198837A1 (en) * 2005-04-29 2007-08-23 Nokia Corporation Establishment of a secure communication
US20060248337A1 (en) * 2005-04-29 2006-11-02 Nokia Corporation Establishment of a secure communication
JP4887682B2 (ja) * 2005-08-05 2012-02-29 日本電気株式会社 通信システム、鍵管理・配信サーバ、端末装置及びそれらに用いるデータ通信方法並びにそのプログラム
US20090119504A1 (en) * 2005-08-10 2009-05-07 Riverbed Technology, Inc. Intercepting and split-terminating authenticated communication connections
US20090083537A1 (en) * 2005-08-10 2009-03-26 Riverbed Technology, Inc. Server configuration selection for ssl interception
FI20051320A0 (fi) * 2005-12-22 2005-12-22 Nokia Corp Menetelmä pakettivirtojen kohdentamiseksi siirtoteille viestintäjärjestelmässä
US7822209B2 (en) * 2006-06-06 2010-10-26 Red Hat, Inc. Methods and systems for key recovery for a token
US7804806B2 (en) * 2006-06-30 2010-09-28 Symbol Technologies, Inc. Techniques for peer wireless switch discovery within a mobility domain
US7916682B2 (en) * 2006-07-14 2011-03-29 Symbol Technologies, Inc. Wireless switch network architecture implementing layer 3 mobility domains
JP2008058944A (ja) * 2006-07-31 2008-03-13 Hitachi Ltd 暗号通信方法、受信者側装置、鍵管理センタ側装置及びプログラム
WO2008030549A2 (en) * 2006-09-06 2008-03-13 Sslnext Inc. Method and system for providing authentication service for internet users
US20080065729A1 (en) * 2006-09-08 2008-03-13 Pitney Bowes Incorporated Method and system for service provider to be compensated for delivering e-mail messages while reducing amount of unsolicited e-mail messages
JP2008104040A (ja) * 2006-10-20 2008-05-01 Fujitsu Ltd 共通鍵生成装置および共通鍵生成方法
US8161543B2 (en) * 2006-12-22 2012-04-17 Aruba Networks, Inc. VLAN tunneling
US8078688B2 (en) * 2006-12-29 2011-12-13 Prodea Systems, Inc. File sharing through multi-services gateway device at user premises
CN101637004B (zh) * 2007-03-16 2015-04-01 艾利森电话股份有限公司 用于通信系统中的前缀可达性的方法
US8190875B2 (en) * 2007-03-22 2012-05-29 Cisco Technology, Inc. Reducing processing load in proxies for secure communications
WO2008128212A1 (en) * 2007-04-12 2008-10-23 Ncipher Corporation Ltd. Method and system for identifying and managing encryption keys
CN101682656B (zh) * 2007-05-09 2013-07-24 艾利森电话股份有限公司 用于保护数据分组的路由选择的方法和设备
EP1990975B1 (en) * 2007-05-09 2013-02-20 Murata Machinery, Ltd. Relay server and relay communication system
US8374086B2 (en) * 2007-06-06 2013-02-12 Sony Computer Entertainment Inc. Adaptive DHT node relay policies
JP5073385B2 (ja) * 2007-07-03 2012-11-14 パナソニック株式会社 情報通信装置
US8699711B2 (en) * 2007-07-18 2014-04-15 Interdigital Technology Corporation Method and apparatus to implement security in a long term evolution wireless device
EP2177997A4 (en) * 2007-08-09 2010-11-03 Nippon Telegraph & Telephone COMMUNICATION METHOD, RELAY SERVER DEVICE, PROGRAM, AND RECORDING MEDIUM
US7930732B2 (en) * 2008-02-22 2011-04-19 Novell, Inc. Techniques for secure transparent switching between modes of a virtual private network (VPN)
WO2009113921A1 (en) * 2008-03-12 2009-09-17 Telefonaktiebolaget Lm Ericsson (Publ) Re-establishment of a security association
JP4715937B2 (ja) * 2009-03-06 2011-07-06 ブラザー工業株式会社 端末装置とコンピュータプログラム
US9112875B2 (en) * 2009-08-04 2015-08-18 Sam Zaid System and method for anonymous addressing of content on network peers and for private peer-to-peer file sharing
US8850203B2 (en) * 2009-08-28 2014-09-30 Alcatel Lucent Secure key management in multimedia communication system
US8566590B2 (en) * 2009-11-26 2013-10-22 Kabushiki Kaisha Toshiba Encryption information transmitting terminal
US8725880B2 (en) * 2010-04-07 2014-05-13 Apple, Inc. Establishing online communication sessions between client computing devices
US9350708B2 (en) * 2010-06-01 2016-05-24 Good Technology Corporation System and method for providing secured access to services
US9015281B2 (en) * 2010-10-08 2015-04-21 Brian Lee Moffat Private data sharing system
DE102011003919A1 (de) * 2011-02-10 2012-08-16 Siemens Aktiengesellschaft Mobilfunkgerätbetriebenes Authentifizierugssystem unter Verwendung einer asymmetrischen Verschlüsselung
JP5741150B2 (ja) * 2011-04-04 2015-07-01 富士通株式会社 中継装置、中継プログラム、及び中継方法
US10135613B2 (en) * 2012-01-13 2018-11-20 Qualcomm Incorporated Method and apparatus for generating a privilege-based key

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20100136533A (ko) * 2003-06-05 2010-12-28 인터트러스트 테크놀로지즈 코포레이션 Ｐ2ｐ 서비스 편성을 위한 상호운용 시스템 및 방법
US20060069800A1 (en) * 2004-09-03 2006-03-30 Microsoft Corporation System and method for erasure coding of streaming media
US20090116430A1 (en) * 2007-11-07 2009-05-07 Motorola, Inc. System for enabling mobile coverage extension and peer-to-peer communications in an ad hoc network and method of operation therefor
US20110010768A1 (en) * 2007-11-29 2011-01-13 Telefonaktiebolaget Lm Ericsson (Publ) Method and Apparatuses for End-to-Edge Media Protection in ANIMS System

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017003215A1 (ko) * 2015-06-30 2017-01-05 투이이피 주식회사 라우팅 방법 및 이를 수행하는 네트워크 엔티티
US10681755B2 (en) 2015-06-30 2020-06-09 2Ip Co., Ltd. Routing method and network entity performing same

Also Published As

Publication number Publication date
US20140237063A1 (en) 2014-08-21
WO2013048038A3 (ko) 2013-07-04
KR101240552B1 (ko) 2013-03-11
CN103843298A (zh) 2014-06-04
CN103843298B (zh) 2016-07-20

Similar Documents

Publication Publication Date Title
WO2013048038A2 (ko) 미디어 키 관리 및 상기 미디어 키를 이용한 피어-투-피어 메시지 송수신 시스템 및 방법
US8055771B2 (en) Network traversal method for establishing connection between two endpoints and network communication system
WO2021135471A1 (zh) 数据传输方法、装置、网卡及存储介质
US20160142302A1 (en) Network system, machine allocation device and machine allocation method
CN101834783B (zh) 一种报文转发方法、装置及网络设备
WO2012050293A1 (en) Method and apparatus for sharing contents using information of group change in content oriented network environment
KR20110071453A (ko) 지그비 게이트웨이 및 이의 메시지 동일화 방법
WO2016180020A1 (zh) 一种报文处理方法、设备和系统
WO2011136526A2 (en) Method for providing message and device therefor
KR20070078347A (ko) Ｐｐｐ 멀티링크를 지원하는 시스템에서의 멀티캐스트트래픽 포워딩 장치 및 제어방법
WO2012120474A1 (en) Sctp association endpoint relocation in a load balancing system
WO2013069979A1 (ko) Ｈｔｔｐ를 이용한 파일 전송 시스템, 그의 메시지 서버, 단말 및 방법
WO2013176431A1 (ko) 단말을 서버에 할당하고 단말로의 효율적인 메시징을 위한 시스템 및 방법
WO2014148865A1 (ko) 통합 sns 게이트웨이
CN101552745A (zh) 一种实现nat的方法及装置
CN110012107B (zh) 一种数据通信方法、设备、装置、系统及存储介质
EP2394396A2 (en) Supplementary service provision method and system for ims-based network
CN105915662B (zh) 一种数据传输方法及装置
EP3662719A1 (en) Method for establishing peer to peer service session over infrastructure link
WO2010095882A2 (en) Method and system for managing connection payload information in medium access control protocol data unit
JP3970857B2 (ja) 通信システム、ゲートウェイ装置
WO2024005565A1 (ko) 메신저 서비스를 제공하기 위한 방법, 시스템 및 비일시성의 컴퓨터 판독 가능한 기록 매체
WO2017052210A1 (ko) 사용자 계정 동기화를 이용한 디지털 상품 제공 방법 및 장치
WO2012121514A2 (ko) 에스아이피 메시지 송수신 시스템 및 방법
WO2015037911A1 (ko) 오픈플로우를 이용하여 사용자 단말 장치와 로컬 호스트 사이의 통신을 지원하기 위한 방법, 장치, 시스템 및 컴퓨터 판독 가능한 기록 매체

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 14347577

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 12835027

Country of ref document: EP

Kind code of ref document: A2