JP2009284482A - Method for realizing voice call via content centric networks - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide real-time applications, such as, voice calls via content centric networks (CCNs). <P>SOLUTION: An interest in receiving voice calls directed to a CCN user is received from the CCN user (100). A packet, for voice call directed to the CCN user received (110) from a calling source device on another network is then forwarded to the user, with a CCN identifier corresponding to the interest received from the CCN destination user (120), and a voice call packet from the user is forwarded to the calling source (130), so that the voice call directed from the calling source to the CCN user is initiated and maintained, on the basis of the CCN identifier associated with the user, without the state information associated with the voice call (140). The voice call is terminated, when no interest corresponding to the voice call is received from the CCN user for a predetermined period or longer (150). <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a method for realizing a voice call via a data network, particularly a voice call via a CCN (content centric network).

  CCN is a network also called a content based network. The intra-CCN data transfer method is a novel method, and does not monitor the network traffic at the application level when sending and receiving content between call terminals, but requests / returns data, that is, content by its name, that is, content name. The network side is responsible for content routing to users.

  CCN has the advantage that content can be distributed very efficiently and very easily. Therefore, it is desired to be able to provide real-time applications such as voice calls via CCN.

  Here, in one embodiment of the present invention, the CCN is identified on a CCN in which data on the network is identified, searched and distributed according to the content identifier, and a self-authenticated data packet is used to transmit the data. In order to realize a voice call through a computer, a system or apparatus using a computer is constructed and a method and a program therefor are executed. In the present embodiment, first, an interest in receiving an incoming voice call addressed to the user is received from the OCN user, and a packet related to the voice call with the CCN user is received from a device that is on another network and is a calling source. The received packet is then forwarded to the CCN user along with the CCN identifier corresponding to the received interest from the destination CCN user. A packet related to the voice call is received from the CCN user and transferred to the caller device. As a result, the voice call from the calling device on the other network to the CCN user is started and sustained based on the CCN identifier related to the CCN user and without the state information related to the voice call. Then, the voice call is terminated after a predetermined time or more has elapsed since the interest in the voice call cannot be received from the CCN user.

  In a preferred embodiment of the present invention, further, an interest in receiving an outbound voice call request from a CCN user is expressed, and an outbound voice call request from the CCN user that is the originator of the outbound voice call, and the outbound voice call. Receive interest in receiving such packets. Furthermore, the outbound voice call request is transferred to another network, and a packet related to the outbound voice call is received from the other network as a response thereto. The received packet is then forwarded from the calling CCN user to the calling CCN user based on the CCN identifier associated with the received interest. Thereby, an outbound voice call by an outbound voice call requesting CCN user is started and sustained. The outbound voice call is terminated after elapse of a predetermined time after the interest in the outbound voice call cannot be received from the caller CCN user.

  In a preferred embodiment of the present invention, the format of the data packet is further converted between a format related to another network and a format related to CCN.

  In a preferred embodiment of the present invention, the voice call is further terminated when an interest to the voice call reception refusal is received from the CCN user.

  In a preferred embodiment of the present invention, the voice call load is further distributed among a plurality of proxy servers each capable of executing the above-described operations without using the state information related to the voice call by each proxy server. To do.

  In a preferred embodiment of the invention, each voice call data packet is also digitally signed so that the data packet can be authenticated by one or more nodes on the CCN.

  In a preferred embodiment of the present invention, it further receives information about public keys pertaining to CCN users, constructs a public directory of public keys so that terminals on other networks can find those keys, and sets the public key Secure the communication according to the existing method for securing communication between terminals.

  The preferred embodiment of the present invention further receives information about online users on CCN, users who have not yet voiced incoming calls, and users who have voiced calls forwarded, and provides that information outside the CCN.

  In a preferred embodiment of the present invention, the voice call transfer to the intra-CCN voice mail system is further executed based on the received information.

  In a preferred embodiment of the present invention, voice call transfer outside the CCN is further performed based on the received information.

It is a figure which shows operation | movement of the VoCCN proxy in one Embodiment of this invention. It is a flowchart which shows the execution example of the inbound (non-CCN network-> CCN) voice call connection procedure in one Embodiment of this invention. It is a flowchart which shows the execution example of the outbound (in CCN-> non-CCN network) voice call connection procedure in one Embodiment of this invention. It is a network diagram which shows an example of the content flow in CCN in one Embodiment of this invention. It is a figure which shows an example of a SIP message. It is a figure which shows the example of execution of the content transmission procedure after interest expression in one Embodiment of this invention, especially the transmission procedure when performing SIP signaling on CCN. It is a figure which shows the execution example of the pipeline transmission procedure at the time of media streaming on CCN by SIP by the content transmission procedure after interest expression in one Embodiment of this invention. It is a figure which shows the example of XML description of the message which propagates on CCN. It is a flowchart which shows an example of the public key management procedure in one Embodiment of this invention. Information transfer procedure according to an embodiment of the present invention, that is, receiving information about online users on CCN, users who have not yet waited to receive voice calls, and users who have expressed voice waiting to receive voice calls, and provides the information outside CCN It is a figure which shows an example of a procedure. It is a figure which shows an example of the computer system which supports the voice call via CCN.

[Outline]
First, in the conventional non-CCN network, a method is adopted in which content is exchanged between call terminals according to the location (destination) of the content, not the content name, and the traffic is monitored at the application level. On the other hand, CCN does not use information such as a file name that is merely a container name of content. Instead, the content name indicating the content itself is used as an identifier, and the content is identified, requested, and distributed.

  Unlike the IP (Internet Protocol) address, the location of the content cannot be determined from the content name. Therefore, in CCN, the network side is responsible for routing content. Further, a content name (OCN name) as an OCN identifier has persistence and content uniqueness. This is the property that when someone changes the content, the content name changes accordingly. As a mechanism for imparting this property, first, an explicit version management mechanism can be used. This is, for example, a mechanism in which version information (such as “version 4”) is added to a conventional name (name given by a human) of the content to form a content name. Second, an implicit association mechanism can also be used. For example, this is a mechanism in which authentication metadata is added to the conventional name of the content to obtain the content name. Authentication metadata refers to a digital signature or the like by a content issuer. In the implicit association mechanism, the content name changes when the content of the authentication metadata changes.

  One of the functions possessed by the CCN is a function of maintaining the correspondence between various contents and content names representing them. The content names are hierarchical and can be understood by many users. For example, if the content name is “/ abcd / bob / papers / ccn / VoIP”, the content is “article VoIP included in the paper collection ccn of Bob who is a user belonging to the organization ABCD”. Moreover, in the CCN, it is not necessary to define at the application level a method in which the content user searches for the organization ABCD and a method for searching on which host Bob's paper collection ccn as a user in the organization is located. On the CCN, when a device belonging to the CCN (CCN user; user terminal such as a telephone) requests content, the interest / interest in the content is registered on the CCN side with the content name. This is called an interest statement. If the interest content is locally available on the CCN, the content is routed to the requesting CCN user. The routing infrastructure (routing infrastructure) is controlled so that interest distribution is performed smartly, the interest reaches the device that can publish the content, and the required content travels back through the interest distribution route without omission. To do.

  CCN also has some other very attractive properties. First, since all contents are encrypted and authenticated in the CCN, authenticity can be confirmed for each content at a certain type of CCN node such as an authorized user of the content. Next, in the CCN, the content can be accessed with the content name regardless of the issuer, and the issuer can be specified when the content is requested. For example, “foo.txt” may be simply requested, or it may be further requested that “foo.txt” is issued by “Bob” and signed. Furthermore, in CCN, a self-authenticating content name can be used as the content name, and the naming method can be arbitrarily decided between the content provider and the content user. A hybrid type self-authenticating content name, that is, a content name consisting of a first half part used for efficient execution of routing on the network side and a second half part providing self-authentication can be used. And since content and credit are separated in CCN, each user who uses the content should set the credit method and reason for the same content or the same signer (same issuer) as liking Can do. For example, there may be a CCN user who gives credit to the content based on the honeymoon relationship with the signer, or the signer because the signer also subscribes to a PKI (public key infrastructure) that he can trust. Some CCN users will credit content from.

  In the embodiment described below, a stateless proxy server is arranged on the boundary between CCN and non-CCN networks. The proxy server is a server or a computer system that handles a voice call request to a client by transferring a request to another server (hereinafter simply referred to as “proxy”). A proxy placed on the boundary between a CCN and a non-CCN network, that is, a proxy shared by a CCN and a non-CCN network, uses the CCN and a non-CCN-like protocol (for example, VoIP (Voice over IP)) for voice. A voice call connection by a CCN, that is, a VOCCN (Voice over CCN) is mediated with a non-CCN network that allocates traffic. This VOCCN proposed in the present application is more elegant and robust than conventional VoIP, and is easy to maintain for network administrators.

  In general, a type of proxy that holds information indicating the state of the currently executed communication is called a stateful proxy, and a type that does not hold such state information is called a stateless proxy. The state information is a collection of stored state variables and their values, and the state is defined by the combination of the values. Therefore, when the state variable value changes, the state of the stateful proxy also changes. The stateless proxy responds only to a given command (received data) and does not depend on the state variable.

  For example, in VoIP, a stateful proxy must be placed on the network boundary. This is particularly necessary to ensure a safe call state. That is, in order to ensure the safety of a call with VoIP, when a SIP (Session Initiation Protocol) message for control information exchange (signaling) arrives, it passes it on a SSL (Secure Socket Layer) operating server. Status information must be retained. SIP is widely used as a signaling protocol for setting / disconnecting a multimedia communication session (voice call, video call, etc.) via the Internet. SIP is used to initiate, modify and terminate a two-party (unicast) or multi-party (multicast) session with one or more media streams. SIP is also used for changing addresses and ports, inviting more participants, adding and removing media streams, and so on. SSL is an encryption protocol that enables secure data transfer related to communication over the Internet, such as web browsing, electronic mail, and instant messaging. A session is a series of requests issued by individual users during individual transactions.

  On the other hand, in the present embodiment, for example, a stateless proxy is arranged on the boundary of the network in which the VoCCN is operating (this proxy is hereinafter referred to as “VoIP / VoIP CC proxy” or simply “VOCCN proxy”). The VOCCN proxy uses DNS (Domain Name System), for example, and announces to the outside world that “I am a standard SIP proxy and is seeking VoIP access into the CCN”. The VoCCN proxy wants to receive an incoming call whether or not an interest in the incoming voice call via the VoCCN has been expressed in the CCN (ie, an incoming call waiting interest). Check if there is a CCN user. In the VoCCN proxy, those identifiers are stored as needed, and when a SIP message for call request, that is, a call message comes in from the outside, a valid one is detected. However, as described above, it is not necessary to remember where the CCN user is on the CCN. This is because the CCN side routing infrastructure controls the entire data packet routing to the requesting device when a call message arrives. Further, the telephone number storage can be an optimization means such as presence detection alone. Thereby, incoming SIP messages that are related to a call to a telephone that is not currently expressing interest can be automatically rejected or routed. The automatic routing can be executed by borrowing the telephone number of a CCN user who has not expressed interest by himself and soliciting the interest by a so-called voice mail system.

  As will be described in detail, an important feature of the VoCCN proxy is its statelessness. The statelessness means that the information that should be known by the proxy in the case of a voice call is only the CCN name used for content transmission / reception by the proxy. As a result, the VoCCN proxy can run voice call sessions that can occur at the same time without being down due to overloading, and these sessions can be transparently mediated by any number of independent gateways. In other words, a series of packets that occur in an individual call do not have to pass through a specific and single gateway that exclusively uses some state information, but can be mediated by multiple and arbitrary gateways. . In addition, although it is less likely to occur than when a call is transferred by an SRTP (Secure Real-time Transport Protocol) portion that itself is a call, after a certain VoCCN proxy establishes a secure connection with an external SIP server by, for example, SSL During the setup operation by SIP, it may be necessary to transfer the call to another proxy. Even in that case, in order to transfer the SSL session from the proxy that leaves the SSL session to another proxy, it is not necessary to exchange state information about the SSL connection between the proxies. This is possible in CCN because the destination proxy can assert interest in the name of its SSL connection state. The interest is for example cast in the CCN (being accessible from anywhere on the CCN) and reaches one of the proxies under the state associated with the interest, making a round-trip contact with all proxies on the CCN There is no need to do. The new proxy can quickly get its status information and take over the SSL session.

  Also, VoIP is credited only to information that has only one passing server, the server name and address are both known, and a certificate relating to the address and name has been issued. The SSL server inevitably has to be the backbone of the network in the sense that the tunnel must be opened in the firewall of the network so that voice calls can be made after setup, and the tunnel must be closed when the call ends. Part. Therefore, the SSL server in VoIP must have sufficient state information to close the tunnel and remain online, not only at the time of initiating the call but throughout the call. In addition, since the condition that the SSL server must be single is imposed, it is difficult to realize voice communication on a scale of thousands of calls.

  On the other hand, in this embodiment, for example, since each individual packet within the CCN is signed, the voice call can be transferred between servers according to the traffic even if the server does not hold the state information related to the voice call. it can. In other words, in this embodiment, integrity and reliability are provided by data, so that the channel used for data transfer need not have such a property. Furthermore, in this embodiment, it is not necessary to keep the firewall. This is because the call is routed only to CCN users who have expressed interest in a series of packets following the call to the CCN user. The VoCCN proxy knows from each interest originated by a CCN user that the next voice packet corresponding to that interest must be forwarded across the network boundary to that CCN user. The call is terminated when the interest expression to the subsequent packet by the CCN user (for example, a telephone) is interrupted. In response to this, the VoCCN proxy automatically stops the packet transfer. There is no need to actively monitor call status. After all, the VoCCN proxy performs the following operations in response to an interest statement by a CCN user and on behalf of that CCN user.

  In VoCCN, a SIP message is embedded in a CCN format packet (CCN packet). That is, the VoCCN proxy can transfer a call request coming from a non-CCN network into the CCN, receives a response packet from a CCN user that is a call destination, and sends it as a normal VoIP packet to the non-CCN network. The packet format is converted between the IP format and the CCN format so that it can be transferred. The VoCCN proxy signs the packet prior to transmission into the CCN so that the called CCN user can receive pre-authenticated data. Therefore, unnecessary data is never transferred to the CCN user.

[basic action]
FIG. 1A shows the operation of the VoCCN proxy in this embodiment. As shown in the figure, the VoCCN proxy 168 is arranged on the boundary of the CCN 160 and is communicating with the user terminal 170. The proxy 168 also belongs to the IP network 162, and a conventionally known SIP proxy 166 is arranged in the IP network 162. The proxy 166 is communicating with the user terminal 164.

  When the user terminal 170 in the CCN 160 is ready to receive an inbound call, the user terminal 170 expresses a voice call call waiting interest to wait for data traffic of the voice call addressed to itself. When the user terminal 164 makes a call to the terminal 170 in this state, the SIP proxy 166 transfers a packet related to the call to the VoCCN proxy 168. Proxy 168 first transmits the first content name for the call into CCN 160 and then forwards the first packet for the call into CCN 160. The transmission of the first content name by the proxy 168 is an interest expression on behalf of the terminal 164, specifically, a voice call transfer waiting interest expression indicating that any packet addressed to the first content name is received. The terminal 170 identifies the first content name based on the content of the first packet transferred subsequently (for example, the one set in the terminal 164). In other words, the first content name that can be derived from the information in the first packet becomes the identifier of the terminal 164 in this voice call session.

  The called user terminal 170 then responds with a data packet addressed to the first content name, and further sets the second content name. The VoCCN proxy 168 identifies that the packet is a response to the terminal 164 based on the second content name. Before and after that, the terminal 170 asserts interest (voice call transfer waiting interest) for all data addressed to the second content name.

  In an outbound call, i.e., a call that is started within CCN 160 and connected outside CCN 160, the VoCCN proxy 168 first starts with the content name corresponding to the voice call or a part thereof (a prefix, etc.), for example, a VoIP destination address. Or an interest in a telephone number of a public switched telephone network (PSTN) (voice call call waiting interest). In response to this interest expression, the user terminal 170 requests a voice call with the user terminal 164, for example. At that time, the terminal 170 first transmits an SIP message for connection request embedded in a CCN packet, and then asserts a voice call transfer waiting interest for one of the terminals, for example, 164. At that time, the terminal 170 can specify a content name that can be used when the proxy 168 forwards the message from the terminal 164.

  The CCN packet containing the SIP message for connection request from the user terminal 170 is received by the VoCCN proxy 168. The proxy 168 extracts the SIP message by converting the format of the packet, and transfers the packet related to the message, that is, the SIP packet to the SIP proxy 166. Proxy 166 forwards the packet to user terminal 164. When receiving the packet, the terminal 164 returns an SIP message for completing the voice call session start procedure. When those SIP messages reach the boundary between the CCN 160 and the IP network 162, the proxy 168 embeds the SIP messages in the CCN packet together with the content name. As the content name, a content name previously specified by the terminal 170, for example, a content name that can be derived from the SIP message itself, that is, a content name that can maintain the statelessness of the proxy 168 is used. Since the terminal 170 has already announced the voice call transfer waiting interest for waiting for the content related to the content name, the terminal 170 can successfully receive those SIP messages. An initial handshake between the terminals 170 and 164 can be established by executing the above-described CCN / SIP conversion procedure in this manner, and a voice call session can be established by subsequently executing a SIP session start procedure and the like. Can be started.

  FIG. 1B is a flowchart showing an execution example of an inbound (non-CCN network → inside CCN) voice call connection procedure in the present embodiment. In this example, first, when a CCN user asserts an incoming voice call waiting interest, the VoCCN proxy receives the interest (operation 100). The CCN user informs all entities residing on the same CCN, ie routers, gateways, proxies, and any other peers, that they are ready to receive the call by asserting the voice call incoming interest.

  Thereafter, when receiving a voice call connection request addressed to a CCN user from another network (operation 110), the VoCCN proxy transfers the request into the CCN (operation 120). Since the content name used in the call is set in this type of request, the CCN user who can be a call destination is a voice call transfer that waits for the content corresponding to the content name before executing the voice call. Waiting interests can be asserted and subsequent voice call connection requests can be answered. The VoCCN proxy forwards the response over the other network (operation 130). As a naming method for voice calls, that is, an identifier assigning method, for example, a structured naming method in which the left prefix is “parent” is used. In this method, for example, “/ parc / home / smetters” becomes the parent of “/parc/home/smeters/test.txt”.

  Thereafter, the VoCCN proxy is interposed between the caller on the other network and the callee on the CCN to start and continue the voice call (operation 140). This operation is performed based on the identifier associated with the called party and the identifier associated with the voice call. It is not necessary to keep the status information related to the voice call. The call continues while the called party continues to make periodic interest assertions, but the call is automatically terminated if the interest cannot be received for a predetermined time or longer (operation 150). The predetermined time can be changed according to the type of call.

  FIG. 1C is a flowchart showing an execution example of an outbound (in CCN → non-CCN network) voice call connection procedure in the present embodiment. In this example, the VoCCN proxy first asserts a voice call call waiting interest to wait for an outbound call connection request (operation 180). A CCN user who desires an outbound voice call makes a call by transmitting a CCN packet containing an outbound connection request SIP message in accordance with the interest. The VoCCN proxy receives the packet (operation 182). The CCN user who is the call originator sends a voice call transfer waiting interest with a designated name to wait for an inbound SIP message as a response. The VoCCN proxy receives the interest and specified name. That is, the caller can specify a content name that can be used by the VoCCN proxy when transferring the SIP message from the callee.

  The VoCCN proxy then forwards the connection request SIP packet to the SIP proxy server (operation 184). The VoCCN proxy receives a SIP message as a response thereto from the called party (operation 186). The VoCCN proxy further embeds the SIP message in the CCN packet together with the content name specified by the caller (operation 188), and forwards the packet to the caller (operation 190). Thereafter, the VoCCN proxy causes the caller to start and continue a voice call (operation 192). When the caller stops the interest statement to receive the content related to the call, the call is automatically terminated.

  Thus, on the CCN, information is specified, searched, and distributed according to the content name, that is, the content identifier, and the routing method is determined on the CCN side based on the content identifier. Data packets are self-authenticating and every data packet contains authentication information about itself. That is, since every data packet is digitally signed by someone whom the user trusts, the data packet can be cached, copied and obtained from anyone, and its integrity and authenticity can be confirmed. can do. Specifically, authentication in CCN is based on content name / data pairs. That is, when bringing the content onto the CCN, the publisher declares that “I will give this content C a content name of N” and digitally signs the correspondence between the content name N and the content C. The full name of each content on the CCN is obtained by adding a signature about the correspondence between the content name and the content to the content name assigned by the publisher. In addition, an appropriate amount of authentication metadata such as an issuer identifier (for example, an encryption digest of the public key of the issuer), a time stamp, and a content type notation can be added.

  FIG. 2 is a network diagram showing an example of a content flow within CCN in the present embodiment. In this example, content flows from the issuer 200 to the subscriber 250 via the CCN nodes 210 and 220. Reference numerals 270, 280, and 290 denote the flow, that is, the content flow. In the CCN, content flowing on the CCN can be locally cached and a copy thereof can be held at any number of intermediate nodes (210, 220, and 230) interposed between the issuer 200 and the subscriber 250. Thus, after a subscriber accesses a content, if another subscriber in the vicinity of that subscriber requests access to the same content, the other subscriber implicitly copies a copy on the CCN node. It can be used at home and the network load is reduced. For example, if subscriber 240 in the figure requests content that subscriber 250 may have previously requested, it can be provided to subscriber 240 because there is a copy on node 220. Similarly, if subscriber 260 asserts interest in content that subscriber 250 may have previously requested, a copy on node 210 or 230 can be provided to subscriber 260. In either case, the entire data transmission path reaching the issuer 200 need not be traced back. Since the voice call goes through the same content flow and local caching, a multicast voice session such as a conference call can be smoothly carried out, and the moved subscriber, for example, 250 can be reconsidered by the node 230 or the like. Can be suitably dealt with. In addition, even if a failure or fault occurs in communication with a certain CCN node, for example, if communication with another CCN node can be performed, communication can be continued without any problem, so that fail / fault tolerance can be improved.

[SIP signaling]
In this embodiment, signaling is executed according to SIP. SIP is the basic transfer mechanism except that it defines the difference in behavior depending on whether it is a stream type reliable connection such as TCP (Transmission Protocol) or a datagram connection such as UDP (User Datagram Protocol). It is stipulated in a non-conforming form. In addition, SIP RFC (Request For Comment) explains the hop-by-hop accounting maintenance method for the route that SIP messages follow from the caller to the final callee via various proxy servers. is doing. Therefore, signaling by SIP (SIP signaling) can also be executed on the CCN, and the datagram method is suitable as the connection form. In this method, SIP signaling can be executed without difficulty by decomposing PDUs (Protocol Data Units) for request and response and mapping them into corresponding contents.

  However, in the classic SIP system, a calling user terminal establishes a connection with a SIP proxy having a corresponding configuration, and delegates a distribution task to the proxy. On the other hand, in the present embodiment, the VoCCN proxy names the content of the SIP message according to the CCN type nomenclature. Thus, any recipient on the CCN who has already expressed interest in the invitation can receive the SIP message. For example, the invitation SIP message shown in FIG. 3 would be named “/abcd.com/bob/sip/invite”. The content represented by the content name invites Bob who is a user belonging to the organization ABCD. SIP messages forwarded on CCN reach all devices that have expressed interest in the content, so by deriving content names instead of SIP addresses according to such consistent CCN nomenclature, The place restrictions that were were eliminated. In the example shown in FIG. 3, based on the method name “INVITE”, the protocol identifier “sip”, and the called party entity (called party name “bob” and the organization to which it belongs “abcd.com”) in the invitation SIP message. Since the content name is derived, the calling party does not need to know where the called party is on the CCN and where to ask to find it. In CCN, the network side is responsible for content distribution.

  In this embodiment, instead of a device on a non-CCN network, the VoCCN proxy expresses interest in content related to the voice call. The called party on the CCN derives the content name for the content related to the current exchange by SIP from the content of the invitation SIP message transferred by the VoCCN proxy. In addition to the callee entity, protocol identifier, and method name, a call identifier can be added (to the content name) by the VoCCN proxy. As a result, a plurality of signaling instances that can occur can be clearly distinguished from each other, that is, only the instances that are actively participating in the current signaling can receive the content. The CCN user who has received the invitation SIP message shown in FIG. 3, for example, the user terminal 170 in FIG. 1A, has a voice having a content name of “/efgh.com/alice/sip/response/12345600@efgh.com”, for example. Send call content.

  In this embodiment, in order to maintain the statelessness of the VoCCN proxy, inbound and outbound messages are used to carry state information necessary for reaching the other party. Specifically, a method of embedding status information in the CCN name is used, but a method of adding status information to payload data can also be used. In general, there are at least three types of methods for conveying status information in a message: (1) a method for embedding status information in a CCN content name, (2) a method for embedding in a SIP message itself, and (3) a CCN data message. The method (1) is used because it is advantageous in various other points although it is somewhat overhead in many cases. For example, if the invitation SIP message shown in FIG. 3 is named by the VoCCN proxy, “/abcd.com/bob/sip/invite/13.1” is used instead of the above “/abcd.com/bob/sip/invite”. Just name it as .14.5 / 2303 ”to embed status information in the content name. The called party on the CCN can derive the response message content name “/efgh.com/alice/sip/response/12345600@efgh.com/13.1.14.5/2303” from the SIP message. The VOCCN proxy can derive the status information “/13.1.14.5/2303” from the content name of the response message, and thus the forwarding VoIP address of the response message. The VoCCN proxy does not require state information related to the call. Further, when there is a difference in SSL handling or the like, more state information can be embedded in the content name or data configuration part.

  Further, when a response message to the content is desired when transmitting the content, in the present embodiment, the transmission side expresses a voice call transfer waiting interest. Since the content name given to the content of the response message is implicitly determined by the content of the message used for content transmission, the content name of the response message that should be sent or its prefix is transmitted. It is possible to derive earlier. This lockstep transaction leads to flow control of CCN traffic. That is, if a content is transmitted even if the voice call transfer waiting interest is not asserted, it may be ignored. Such a procedure is referred to as content transmission after an interest expression for short. FIG. 4 shows an example of a content transmission procedure after interest assertion in the present embodiment, particularly a procedure in SIP signaling. In the figure, an arrow line between the caller 400 and the callee 405 indicates the flow of content and interest and the direction thereof. Messages with the subscript (I) are for interest expression, and messages with the subscript (C) are for content transmission. Specifically, first, an incoming call waiting “Invite” interest indicating that the device 405 desired to receive the call waits for an invitation is expressed (410). In response to this, the caller 400 asserts the call call waiting “Call1 / SIP” interest to wait for a response from the callee 405 (415), and then makes the callee 405 the current call “Call1”. The “Invite [Call1]” content for invitation is transmitted (420). The called party 405 expresses a voice call transfer waiting “Call1 / SIP” interest to wait for a response from the calling source 400 (425), and then “Call1 / SIP” to accept the invitation from the calling source 400. [OK] ”The content is transmitted (430). In response to this, the calling source 400 continuously announces a call call waiting “Call1 / SIP” interest to wait for a response from the called party 405 (435), and then “Call1 /” confirms that the invitation has been established. SIP [ACK] ”content is transmitted (440). The called party 405 also continuously announces (issue) “Call1 / SIP445” interest. This procedure is continued while the caller 400 and the callee 405 want to continue the call. Thus, it is not necessary for the VoCCN proxy to maintain state information about the call. Note that the communication procedure described here is a general pattern of a one-to-one call via CCN.

  The CCN can support various functions for this embodiment. First, the interest that the final callee expressed about the invitation by SIP message can be flooded in the CCN. At least to the extent that the content related to the interest can be routed to the terminal that satisfies the interest, the interest is distributed. Second, CCN can preserve the interest that potential callees express about invitations via SIP messages. A potential callee can continue to wait for an incoming call indefinitely, so that as long as the device expresses interest in joining the call, it can keep the interest on the network or the device itself. it can. In the preferred embodiment of the present invention, the voice call can be continued as long as interest from the CCN to the continuation of the voice call is asserted. In addition, by disabling interest assertion after the occurrence of a certain non-listening period (several seconds), a device that has stopped its operation or a device that has been disconnected from the network can be basically disconnected from the CCN with respect to that interest. .

[Voice call session]
When SIP signaling is successfully completed, the streaming target is specified by exchanging various parameters, and a corresponding media stream is generated using the payloads of the various SIP packets. If it is a voice call session by SIP, an SDP (Session Description Protocol) type payload is specified as a streaming target, and data in the payload is actually transmitted in real time according to a procedure related to RTP (Real-time Transport Protocol). It is common to implement an audio-visual call session.

  On the other hand, in this embodiment, VoCCN is realized by mapping data transmitted according to RTP to CCN by a server or the like. At that time, the information pieces (sequence numbers) for mutual distinction of RTP frames in the same media stream are used for naming the contents. This is because the RTP media stream (RTP stream) can be reproduced on the receiving side by naming the content using such a sequence number in addition to the called entity and call identifier used during SIP signaling. is there. For example, if the content name of a frame is in the format of “/ abcd / bob / rtp / 12345600@efgh.com/5678”, the RTP stream is based on the sequence number (“5678” in this example) at the end. Can be reproduced. In addition, since the nomenclature is such a method, the latency between the transmission side and the reception side can be absorbed by temporarily storing a plurality of frames on the CCN.

In the CCN node or the like, a copy of the frame transmitted in this way is cached. When a frame having the same content name as that already cached arrives, the latter is cached instead of the former, so that one cached copy per sequence number. Since the sequence number is a 16-bit binary number, it is not a globally unique value in the RTP stream, but it should be used without any problem on the receiving side until the number of frames in the stream reaches 2 ^16. Can do. Further, when older frames are required on the receiving side, an extended sequence number may be calculated and used according to the RFC of RTP so that more frames can be distributed on the CCN. However, if the interest expression and content transmission are executed in a lockstep manner following the signaling, that is, if the content transmission is executed after the interest is asserted, the round trip latency is long in the RTP stream due to the dispersibility and latency of the network. There is a possibility. There is a possibility that the reception of the packet is awaited so that the stream cannot be normally reproduced.

  In the present embodiment, since a plurality of interests can be transmitted by pipeline using the same channel, such a problem can be eliminated. FIG. 5 shows an example of a content transmission procedure after interest assertion in this embodiment, particularly a pipeline procedure when media streaming is performed on the CCN by SIP. In this procedure, the receiving side 500 continuously expresses interest in receiving a call a plurality of times, and the transmitting side 510 makes a call accordingly. Therefore, the data distribution speed on the CCN is determined not by the interest arrival frequency from the receiving side 500 but by the content transmission speed from the encoding device 520 such as a media codec.

  In this embodiment, the CCN user on the stream receiving side simultaneously engages a predetermined number of interests in the media stream. That is, the reception side asserts a predetermined number of interests in the stream when the stream is generated or when the network state changes. Every time a frame (content) belonging to the stream is received, the receiving side asserts a new interest, thereby returning the number of interest to the initial number, so that the interest in the same stream is necessary for pipeline reception. Keep in number. On the system side, these interests are integrated into one interest, and the number before integration is stored. Unlike interests, content with the same name is not held at the same time, so the stored number value is decremented each time the content is forwarded to the corresponding interest assertion source. Therefore, the frequency at which the content arrives at the CCN user is determined by the rate at which the content is transmitted from the issuer, for example, the data transmission rate by the encoding device 520. However, the upper limit is limited by the number of interests simultaneously expressed by the CCN user on the receiving side.

[Secure calls]
First, MIKEY (Multimedia Internet KEYing) is known as a standard method for securing communication between terminals. In a network that transmits voice traffic using standard VoIP packets according to SRTP, this MIKEY can be used for encryption of a transmission path that accommodates the voice traffic and key exchange. However, MIKEY must be able to authenticate the public key of the communication partner. This issue needs to be cleared in order to secure voice calls on CCN using MIKEY. Further, a condition is imposed on the communication on the CCN that every packet must be publicly authenticable. In order to satisfy this condition, the information embedded in the CCN packet must be publicly authenticated. However, in SRTP, a shared key-based encryption and authentication method is used to protect individual packets in the media stream. Therefore, except for the terminal (calling party) to which the key is distributed, SRTP packets Cannot be authenticated / modified.

  Therefore, in this embodiment, a single point configuration is performed to solve the above-mentioned key distribution problem in VoIP, although there is a slight risk of security leakage. This is because the VoCCN proxy looks for the public key of every device belonging to the CCN (eg every phone in the organization) and the public key is found outside the CCN according to a standard directory protocol such as LDAP (Light Weight Directory Access Protocol). It is a method of providing to etc. A telephone belonging to this CCN asserts a voice call waiting interest by accessing its own secret key and sends it to the CCN. While the gateway belonging to the VoIP section receives such interest, it requests the public key for the target node from the CCN side. The VoCCN proxy receives a request by the LDAP message and returns a public key for a required node (for example, an in-house telephone that is a calling party). At that time, it is not necessary to make the VoCCN proxy remember the public key in advance. The gateway belonging to the VoIP section can confirm the authenticity of the signature attached to the interest if the voice call data spreading control is necessary.

  In this embodiment, the VoCCN proxy is also functioned as an authentication proxy. This is so that authentic VoIP packets can be authenticated for the CCN infrastructure. As described above, in order to secure a call using VoIP, it is required to secure the channel itself and to enable the VoIP packet on the channel to be authenticated only by the calling party. Data packets must also be publicly authenticated with a digital signature or the like. Therefore, in this embodiment, the VoCCN proxy receives a credit from another node on the CCN, and attaches a signature to the VoIP packet that is embedded in the CCN packet and transmitted on the CCN. A standard digital signature method may be used for the signature, or a stream signature that can be publicly authenticated may be used in some other form. Stream signature is a method in which the cost of an individual digital signature is amortized by a plurality of packets on a media stream, and normally only packets within a predetermined period after the generation can be authenticated. For example, when a VoCCN proxy that collects voice communication data for 100 packets subsequently sends one digital signature, all 100 packets are authenticated. However, if this is done, the statelessness of the VoCCN proxy may be infringed, so that the main state information is also required to be held on the authentication side. As a technique for realizing such a mechanism, a technique described in existing or future cryptography documents can be used at will, and a mechanism capable of efficiently digitally signing with various media streams is realized thereby. Can do.

  FIG. 7 is a flowchart showing a public key management procedure in the present embodiment. In this procedure, the VoCCN proxy first receives information about the public key associated with the CCN user (operation 700) and then builds a public directory for the public key (operation 710). The VoCCN proxy secures communication in accordance with an existing terminal-to-terminal communication security method using a public key after enabling terminals on other networks to find these keys (operation 720).

  One of the advantages of this embodiment is that the TCO (Total Cost of Ownership) in the VOCCN method is lower than that in the VoIP method because the single site type construction is executed. As already explained in relation to the presence detection and public key directory automatic construction, it is only necessary to provide identity information such as “this phone is Bob's” to each phone in the VoCCN method. Configuration settings are automatically executed later. The identity information “Bob's” is used as a public key / private key pair or as a generation material thereof, and the generated key is transmitted on the CCN to be authenticated by the organization to which it belongs. This operation can be performed as part of the configuration settings for the phone, but if you want to easily do it even if it is somewhat lacking in security, for example, authenticate the first key declaring that it is "Bob's" After that, you can just wait for a while. The phone owner, Bob, will complain if he can't receive a call to him. If there is such a complaint, it can be dealt with assuming that the identity information of the phone has been stolen.

  Once the key has been authenticated, the CCN infrastructure initiates automatic routing of calls to the phone. That is, the phone starts expressing voice call waiting interest wherever it is, so the infrastructure routes the call request to the phone if there is a call destined for that type of interest. . At this time, it is not necessary to configure the CCN infrastructure so that the port to which the telephone is connected can be known. The presence / absence of a telephone can be determined by the presence / absence of interest expressed by the telephone. If the telephone is a desk phone, a voice mail addressed to the user of the telephone can be recorded on the telephone by using the fact that the telephone can always be called. If the phone is a mobile phone and works with software installed and configured, the infrastructure can redirect calls to the phone to others when the user is unable to answer the phone, When the user is notified that the call cannot be made, the voice mail addressed to the user can be recorded on the infrastructure side.

  In the present embodiment, these functions can be executed simply by performing configuration setting at a single site. That is, if identity information is given to a telephone, it is possible to make a secure call with that telephone. Any policy for the phone and configuration settings for additional services useful for all phones can be performed on the devices that provide those services. Configuration mistakes (configuration errors) are remarkably reduced by such a single site type construction, and the implementation cost of the VoCCN method is considerably suppressed by the effect of the single site type construction.

  FIG. 8 shows information transfer procedures in this embodiment, that is, information on online users on the CCN, users who have not yet voiced incoming calls, and users whose voice calls have been forwarded (process 800). An example of a procedure provided outside the CCN (process 810) is shown. The information is used, for example, to route the caller to voice mail or a non-CCN telephone.

[Wire protocol in CCN]
In the present embodiment, an XML (eXtensible Markup Language) -based wire protocol such as FastInfoset is used. However, various other compression formats can also be used. For example, the XML “end” tag does not need to be explicitly encoded, but in that case, it takes into account the XML document structure such that all fields are tagged with the length, and its binary content. It is not necessary to re-sort the content to Base64 after encoding.

  FIG. 6 shows XML notation of a message propagating on the CCN, taking as an example the case of transmitting the SIP message (INVITE method) shown in FIG. A PDU mapped to content in the CCN includes at least a pair of “ccn” tags as shown. An arbitrary number of “interest” tags and “content” tags can be described in a portion of the PDU enclosed by “ccn” tags. In addition, since the “interest” tag and “content” tag can be added to or removed from that part at any time, PDUs can be integrated at any device on the network and the PDU can be divided into a plurality of PDUs. Furthermore, from a network point of view, it is not necessary to change the handling of individual “interest” tags or “content” tags depending on whether or not they exist in the same frame. In any case, the part enclosed by the “interest” tag and the part enclosed by the “content” tag are listed in the same order as the order of the routing information used elsewhere in this application. Therefore, it is possible to extract information important for routing content to the network layer on the CCN. In order to gain an understanding of the present embodiment, the wire protocol has been described here using XML terms. However, in actual use, it is necessary to convert data encoded in a compression format such as FastInfoset into XML notation. There is no.

  In this embodiment, an application PDU is held. That is, since signaling and data (SIP and RTP content) are embedded together in the same frame, only a small amount of information hidden in the content of the frame is necessary for routing the frame on the CCN. .

[CCN Agent]
In this embodiment, the CCN agent is responsible for flow control by CCN. That is, any application or network interface must execute the CCN agent process once when communicating with an individual CCN node. The CCN agent used in this embodiment is an independent process for communicating with various applications through a UNIX (registered trademark) domain socket. The CCN agent is of a single thread type, and is configured to execute a selection loop and wait until data arrives from any one of the connection destination sockets. It is another process that is responsible for the network connection to those sockets. These processes connect to the CCN agent in the same way as applications do, and are responsible for bidirectional transmission of packets. It is also possible to incorporate this function into the CCN agent body, but the resulting efficiency improvement is negligible.

  The CCN agent uses a content cache and a pending interest table. The pending interest table is a table that manages the currently asserted interests (pending interests) and the number of the interests for each interface. When a packet arrives, the CCN agent disassembles the packet to retrieve individual interests and content and processes the incoming interest and incoming content separately from each other. For incoming content, the CCN agent first confirms that content having the same name as the incoming content is not stored there by referring to the content cache. Since the content name is assigned so that the content can be uniquely identified, if the content with the same name is already stored in the content cache, the incoming content is regarded as duplicate and ignored.

  The CCN agent then looks for a pending interest that matches its incoming content by referring to the pending interest table. “Match” means that the prefix of the content name of the incoming content matches the name of the pending interest on the pending interest table. If a pending interest that matches the incoming content is found, the CCN agent consumes the pending interest (ie decrements its interface count) and sets a schedule for sending the incoming content to the corresponding interface. In any case, the CCN agent stores the new content on the content cache.

  For the incoming interest, a procedure that is more intrusive than the procedure for the incoming content is performed. That is, the CCN agent looks for unsent content that matches its incoming interest by referring to the content cache. “Match” means that the content can be satisfied with the content, specifically, the same prefix matching condition as described above is satisfied. “Unsent” means that the content has not yet been transmitted, that is, the interest issuing interface has not yet received it. If the relevant content is found, the CCN agent schedules the transmission of the content and consumes its incoming interest.

  Further, when there are a plurality of contents matching the incoming interest on the content cache, only one of them is set as a transmission target. In terms of accuracy, there is no problem in transmitting any message, but the CCN agent in the present embodiment targets the transmission with the earliest arrival time. Conversely, if no content matching the incoming interest is found in the content cache, the CCN agent registers the incoming interest in the pending interest table in association with the issuing interface and adds the new pending interest to the other Distribute to the interface.

  When distributing the interest, the CCN agent in the present embodiment uses a fluid system. That is, the CCN agent assigns randomly generated interest identifiers to interests that do not have an interest identifier among the interests to be distributed and distributes them. By ignoring anything with an identifier, loop transmission is prevented. At that time, by setting a time window of an appropriate length, the size of the table for storing the interest identifier reception history can be suppressed. In addition, since the CCN agent distributes interests slightly and randomly shifts the transmission timings of individual interests, new content that matches (some) interests targeted for distribution while waiting for the transmission. (Some) may arrive. When such a situation occurs, the distribution of the interest is canceled and the interest is consumed. Conversely, the CCN agent does not deliberately cancel the interest that has been distributed due to the arrival of the matching content. Interests that have not been consumed after a certain amount of time have timed out.

In this embodiment, an exponential decay method, that is, a method of deleting the interest from the pending interest table at a rate proportional to the number of interests to the table is used as a mechanism for timing out the interest. In this method, in principle, half of the pending interests are deleted after a certain period of time (half-life), except when the number of interests is one, and the last one interest follows. Be maintained over a half-life. Specifically, using a scale factor of 5 and updating the interest count x 4 times per half-life, the following formula:
(Equation 1)
if x ≦ 5 then x = x−1;
else x = floor ((x * 5 + 3) / 6);
The interest pending number x may be updated according to (5/6 is a suitable rational number approximation of 2 to ^1/4 ). On the application side, in order to fulfill the role of refreshing the deleted interest, the time required for the refresh is determined using the same exponential decay method. Also, here, interest distribution and pending interest deletion have been described as the most important of them, but there are several other situations where a similar time-based operation is required. For example, it is an operation of deleting outdated information from the content cache, or an operation of retreating an interest data structure that has not been used for a long time. The CCN agent refers to its own operation schedule list and executes such operations in a form similar to the callout function by the operating system kernel. The timeout value used by the CCN agent in such a selection loop is calculated according to the execution time of the next operation on the schedule list.

[Computer and communication system]
FIG. 9 shows an example of a computer system used for realizing a voice call via CCN in this embodiment. As illustrated, the computer / communication system 900 includes a processor 910, a memory 920, and a storage device 330, and various programs executed by the processor 910 are stored in the storage device 330. Among them, the program 940 is a stateless VoCCN proxy application for providing a VoCCN proxy function, and a voice call via the CCN 950 is realized by the proxy function. This figure also shows the environment in which the system 900 is placed. That is, the system 900 is located between the CCN 950 and the other network 970, and is connected to them via the network connection means 980 and 990 (in the same order in the same order). The connection means 980 and 990 may be broadband, wireless, telephone, or satellite. That is, it is only necessary to connect to the target network. In addition, there are a plurality of nodes (for example, other computer systems) 960 to 964 on the CCN 950. These nodes 960-964 form a network or CCN 950 together with various user terminals or devices. System 900 can also be a member of CCN 950, other network 970, or both. In operation, the application 940 on the storage device 930 is loaded onto the memory 920 and further executed by the processor 910, thereby causing the system 900 to function as a VoCCN proxy. That is, the above functions are executed between the CCN 950 and the other network 970.

  100-150, 180-192, 700-720 operation, 160,950 CCN, 162 IP network, 164,170 user terminal, 166 SIP proxy, 168 VoCCN proxy, 200 issuer, 210-230, 960-964 CCN node, 240-260 subscribers, 270-290 content flow, 400 calling party, 405 called party, 410, 415, 425, 435, 445 interest, 420, 430, 440 content, 500 receiving side, 510 transmitting side, 520 code Device, 800, 810 processing, 900 computer / communication system, 910 processor, 920 memory, 930 storage device, 940 stateless VoCCN proxy application, 970 other network, 980, 990 network Over click connection means.

Claims (4)

On a content-centric network (CCN) where data on the network is identified, searched and distributed according to its content identifier, and self-authenticated data packets are used to transmit the data,
While receiving an interest in receiving a voice call from the OCN user, a packet related to the voice call with the CCN user is received from a device that is on another network and is a calling source.
Forwards the received packet to the CCN user with the CCN identifier corresponding to the received interest from the destination CCN user;
Furthermore, by receiving a packet related to the voice call from the CCN user and transferring it to the calling device,
Initiating and sustaining a voice call from a calling device on another network to a CCN user based on the CCN identifier associated with the CCN user and without state information pertaining to the voice call;
Then, the voice call is terminated after elapse of a predetermined time after the interest related to the voice call cannot be received from the CCN user.
A method for realizing a voice call via CCN, which executes the above operation on an arbitrary computer. The method for realizing a voice call via CCN according to claim 1, further comprising:
Announcing interest in outbound voice call requests by CCN users,
Receiving an outbound voice call request and an interest in receiving a packet related to the outbound voice call from the CCN user who is the originator of the outbound voice call;
Forward the outbound voice call request to another network,
In response to this, the packet related to the outbound voice call is received from the other network,
By forwarding the received packet to the calling CCN user based on the CCN identifier for the interest received from the calling CCN user,
Initiating and maintaining an outbound voice call for an outbound voice call requesting CCN user;
A method for realizing a voice call via CCN that ends the outbound voice call after elapse of a predetermined time or more after the interest in the outbound voice call cannot be received from the caller CCN user.   The method for realizing voice call via CCN according to claim 1, further comprising: converting a data packet format between a format related to the other network and a format related to CCN.   The method for realizing a voice call via CCN according to claim 1, further comprising: ending the voice call when receiving an interest in refusing to receive a voice call from the CCN user.

Images