JP2009223533A - Session control device, session control method, and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To achieve higher level and highly convenient service development without making an application developer be conscious of medial classification between terminals. <P>SOLUTION: A gateway 200 is installed between an information network 300 and a communication undertaker network 100. In the gateway 200, connection API, disconnection API, switching API, division API, and binding API are set as control API 210 which can be called from an application 410. The gateway 200 establishes session on the basis of media negotiation by using the API calling from the application 410 or transmission from the terminal as a chance. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a session control device, a session control method, and a program for performing session control between terminals on a communication network (including server-to-terminal and server-to-server) in response to a request from an application.

  A technology (third-party call control) that allows session control between terminals on an IP phone or communication network to be controlled from a third-party application by providing an API (Application Program Interface) or the like has been partially standardized (for example, Non-Patent Document 1). However, in the conventional technique such as Non-Patent Document 1, since only a connection / disconnection means is provided and the number of types of control is small, control by an application is limited.

Therefore, in an IP-based communication network that can use various media types in a session between terminals, the Session Initiation Protocol (SIP) that is widely used as a session control signal can exchange a session by exchanging a Session Description Protocol (SDP). A method of selecting a media type (voice communication, video communication, data communication, etc.) according to the capability of a terminal by negotiation between terminals to be established has been standardized (for example, see Non-Patent Document 2).
`` Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP) '', 2004 "Practical SIP Detailed Text" Rick Telecom, 2005, p. 234-267

  However, in the above-described prior art (Non-Patent Document 2), the method shown by standardization is merely a session control method between terminals. In addition, RFC 3725, which defines the SDP exchange method in third-party call control, clarifies how SDP exchange should be performed when session control as in Non-Patent Document 1 is added. Not.

  Therefore, the number of types of control is increased (session switching, splitting, joining), and means for notifying applications of call control events such as incoming calls for specific phone numbers are provided, allowing application developers to develop more services. Is desired.

  However, if the media type used at the time of session connection between terminals is always specified from the application, the media type between the terminals to be connected must be conscious every time the application developer executes session control.

  As described above, in application development using the flexible session control API, it is inconvenient that the media type of the session must be designated from the application for each control. Also in flexible third-party call control, a mechanism that can leave the specification of the media type to media negotiation between terminals is necessary.

  The present invention has been made in consideration of such circumstances, and its purpose is to realize more advanced and highly convenient service development without making application developers aware of media types between terminals. It is an object to provide a session control apparatus, a session control method, and a program that can perform the above-described process.

  In order to solve the above-described problems, the present invention provides a command from the application server in a session control apparatus that receives a command from an application server and controls a session between communication nodes connected to a network of a communication carrier. In response, session establishment means for establishing a session between the communication nodes, session identifier notification means for transmitting a session identifier indicating a session established between the communication nodes to the application server, and established between the communication nodes Session control means for controlling a session according to a command from the application server; and management means for performing media negotiation between the communication nodes when a session is established with the communication node. It is.

  According to the present invention, in the above invention, the management means includes holding means for holding a media negotiation result for each communication node, and a codec associated with a media type change based on the media negotiation result for each communication node. It is characterized by determining a change.

  According to the present invention, in the above invention, the session control means switches one connection destination of the first and second communication nodes of the established session to the third communication node based on a command from the application server. It has a switching means.

  According to the present invention, in the above invention, the session control means determines the connection destinations of the first and second communication nodes of the established session based on a command from the application server, respectively. It has a dividing means for switching to a node.

  According to the present invention, in the above invention, the session control means, based on a command from the application server, one communication node of the first session being established and one communication node of the second session being established And recombination means for recombining with the session established.

  According to the present invention, in the above invention, the session control unit includes a disconnecting unit that disconnects the session being established based on a command from the application server.

  The present invention is characterized in that, in the above invention, when the session is established between the communication nodes, the session control means notifies the application server of a session identifier for specifying the established session.

  In order to solve the above-mentioned problem, the present invention provides a session control method for receiving a command from an application server and controlling a session between communication nodes connected to a network of a communication carrier. Establishing a session between the communication nodes in response to a command; transmitting a session identifier indicating a session established between the communication nodes to the application server; and a session established between the communication nodes. A session control method comprising: controlling according to a command from an application server; and performing media negotiation between the communication nodes when establishing a session with the communication node.

  In order to solve the above-described problem, the present invention receives a command from an application server, and sends a command from the application server to a computer that controls a session between communication nodes connected to a network of a communication carrier. Accordingly, establishing a session between the communication nodes, transmitting a session identifier indicating a session established between the communication nodes to the application server, and indicating the session established between the communication nodes to the application server. And a step of performing media negotiation between the communication nodes when establishing a session with the communication node.

  According to the present invention, by providing a session control API having a high degree of freedom for an application, the convenience of the application developer is improved, and more application developers are allowed to enter service development on a communication network. be able to. Furthermore, since the API is based on media negotiation between terminals in session control, service development using a multimedia compatible terminal is facilitated, and more advanced and highly convenient service development can be realized.

  Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

  FIG. 1 is a block diagram showing a configuration of an information communication system using a gateway (session control device) according to an embodiment of the present invention. This system uses SIP (Session Initiation Protocol) as a network control protocol and SOAP (Simple Object Access Protocol) as an API (Application Program Interface) providing protocol.

  In the figure, 400 is an application server managed by a server provider other than the carrier, 410 is an application set in the application server 400, 300 is an information network to which the application server 400 is connected, and 100 is a communication node. As a communication carrier network to which the terminal 500 is connected, 200 is a gateway connected between the information network 300 and the communication carrier network 100, and 210 is a session control API that is installed in the gateway 200 and published. It is.

  Here, the terminal 500 is a VoIP terminal compatible with SIP, and among the sessions controlled by these terminals 500 using SIP signals, the session linked with the application 410 always passes through the gateway 200. That is, when the session control API call request transmitted from the application 410 on the application server 400 is received by the gateway device 200, a call control signal is transmitted to and received from the terminal 500 via the communication carrier network 100, and the terminal Session control between 500 is performed.

  Further, when the terminal 500 makes a call, the call control event is notified to the application 410 by mediating the gateway 200 instead of directly transmitting to the partner terminal 500. At this time, the protocol between the gateway 200 and the terminal 500 is SIP, the protocol between the gateway 200 and the application server 400 is SOAP, and the session control API 210 of the application 410 running on the application server 400 is operated by SOAP. Calling is possible.

  FIG. 2 is a block diagram illustrating a configuration of the gateway 200 according to the present embodiment. As the control API 210 that can be called from the application 410, a connection API 211, a disconnect API 212, a switching API 213, a split API 214, and a combined API 215 are set as shown in FIG. An event notification API 216 for call control event notification is also provided. The terminal SDP management function 217 is a function for storing SDP information transmitted to the terminal 500 in order to realize inter-terminal media negotiation, which will be described later. The media termination function 218 is a function for transmitting an automatic voice, which will be described later, to the terminal 500, and accepting voice input from the terminal 500 and input via media such as a dial tone signal. In realizing the gateway 200, the media termination function 218 is not essential and may be the gateway 200 that does not include the media termination function 218.

  FIG. 3 is a sequence diagram showing an example of session control between terminals by SDP exchange standardized as a method for determining a media type at the time of terminal transmission according to the present embodiment. In session control between terminals, it is necessary to determine a media type used for communication between terminals. In FIG. 3, at the time of INVITE request, the terminal 500 (A) uses as the offer A information describing in its SDP format the media processing capability (corresponding codec, etc.) and the waiting state information (which port is waiting). 500 (B) is transmitted (S31). The terminal 500 (B) that has received this decrypts the content specified by offerA, determines the codec to be used in the session from its media processing capability, and describes it in the SDP format together with the standby state information, The response signal is transmitted as answerB (S32). Upon receiving the response signal, terminal 500 (A) transmits ACK to terminal 500 (B) (S33).

  FIG. 4 is a sequence diagram showing another example of session control between terminals by SDP exchange standardized as a method for determining a media type at the time of terminal transmission according to the present embodiment. As shown in FIG. 4, the calling terminal 500 (A) transmits INVITE (session connection signal) that does not set SDP (S41), and the receiving terminal 500 (B) that receives it transmits offerB from its media processing capability. Is set and transmitted on the response signal (S42), and the terminal 500 (A) receiving it transmits ACK with the answerA (S43).

  3 and FIG. 4, the media negotiation is performed between the terminals 500 (A) and (B), and the media according to the capabilities of the terminals 500 (A) and (B) is selected. The The above-described example is a procedure when the terminal 500 makes a call to the end, and is applied as it is to the session control method (third party call control) in which the gateway 200 that performs session control between the terminals 500 performs session control between the terminals 500. I can't do it.

  Here, FIGS. 5 to 7 are sequence diagrams illustrating an example of a method for determining the media type of the session controlled by the session control API 210 of the gateway 200 according to the present embodiment. The determination of the media type of the session controlled by the session control API 210 as shown in FIG. 2 is specified by the application 410 every time the control API is called by the connection request from the application 410 (S51), as shown in FIG. As shown in FIG. 6, the connection request from the application 410 is not specified (S61), and the negotiation (S62, S63) is performed based on the SDP information that the gateway 200 statically holds in the setting file or the like. As shown in FIG. 7, there is a method of determining by negotiation between terminals in the exchange of session control signals (S72, S73) without specifying in the connection request from the application 410 (S71) as shown in FIG. .

  However, the implementation method of the method shown in FIG. 7 is not clarified. Therefore, in the present invention, the terminal SDP management function 217 and the call control APIs 211 to 216 in the gateway 200 operate according to the sequences shown in FIGS. 8 to 16, thereby realizing the session control API as shown in FIG. .

[Connection API]
First, the connection API 211 will be described.
FIG. 8 is a sequence diagram (Flow 3 shown in RFC 3725 (4.3. Page 6)) when the connection API 211 is called according to the present embodiment. In this sequence, when a connection request between the terminals 500 (A) and (B) is transmitted from the application 410 to the gateway 200 (S001), a session ID for identifying a session is returned (S002). The application 410 performs subsequent session control (disconnection, etc.) using the session ID.

  The gateway 200 performs call control between the terminals 500 (A) and (B) via the communication network 100 after receiving the connection request (S003 to S005). When this call control is performed, terminal 500 (A) enters a call-to-call state. However, since the SDP of the terminal 500 (B) is unknown at this time, bh-SDP is transmitted to the terminal 500 (A) to be in a silent state (S005). The bh-SDP is an SDP in which “0.0.0.0” is designated as the IP address, and the terminal 500 that has received such SDP stops transmission of the media. Thereafter, media negotiation is performed between the terminals 500 (A) and (B), and communication is started (S006 to S011).

  The feature of this method is that the terminal 500 (A) is in a silent state in S005 and that the SDP non-setting INVITE is transmitted to the terminal 500 (B) in S006, so that a response signal is received in S007. By transmitting the SDP (offerB) returned in step S <b> 008 to the terminal 500 (A) by re-INVITE in step S <b> 008, media negotiation between the terminals is realized. When the SDP transmitted from the terminal 500 is transferred to the other terminal (S006 to S007, S009 to S010), the gateway 200 may rewrite the SDP. This is performed when the media type is intentionally changed by session control using the gateway 200, or when the media transfer destination is operated at the gateway 200 (for example, when the gateway 200 mediates media communication). . Of course, there may be a sequence in which these conversion processes are not performed and the SDP is transferred as it is. Further, according to the standardization, there are the following restrictions on media update by re-INVITE.

[Restrictions when updating media]
(A) When updating the SDP, it is necessary to include m = rows (rows specifying the media type) equal to or more than the previous SDP.
(B) Do not delete the payload type (a line in which the media encoding information is specified). In the case of deletion, media negotiation (re-INVITE) is performed with SDP in which the port number of m line is overwritten with 0, so that the media transmission from the terminal is stopped [1], and then SDP with updated m line is used. It is necessary to perform [2] media negotiation (re-INVITE) again.

  Due to the above restrictions, when changing the connection destination / media type for a connected terminal 500, only the address information of the destination is updated, or the payload type representing video / audio is changed. In the case of adding only the SDP, as shown in FIG. 9, the SDP with the updated address information may be transmitted once in the INVITE / re-INVITE process (S84). When it is desired to change the payload type used by the terminal 500 after the update (when deleting the payload type), as shown in FIG. 10, two re-INVITE transmissions ([1] and [2] above) May be necessary (S94, S95). Each API sequence shown in the present invention is shown only when it is completed by one re-INVITE. However, depending on the updated media type, the procedure shown in FIG. 10 may be used. At this time, whether or not the codec is changed by the re-INVITE process (S84, S94) cannot be determined unless the SDP information (S82, S92) transmitted to the terminal 500 is held. As shown in FIG. 5, a terminal SDP management function 217 that holds SDP information for each terminal is provided in the gateway 200, and the result of media negotiation is held.

  Further, when the sequence shown in FIG. 8 is applied to the IP telephone network, the terminal 500 (A) from when the user of the terminal 500 (A) lifts the handset in S004 until the communication between the two starts in S011. There is a problem that the user of the user must continue to wait in a silent state. Further, when there is a terminal 500 that does not support bh-SDP, the sequence cannot be applied.

  FIG. 11 is a sequence diagram for explaining an operation for avoiding the above problem. In FIG. 11, the basic sequence is not different from the sequence of FIG. 8, but the provisional SDP is returned in S 105, and automatic sound is sent to the terminal 500 (A) by the media termination function 21. In the provisional SDP, an arbitrary address such as an address of the gateway 200 and an arbitrary media type are set. Terminal 500 (A) has an illusion that session control with a normal terminal is performed. Thereby, session control is possible even if there is a terminal 500 that does not support bh-SDP. As for the automatic voice, the automatic voice is played using the media termination function 218 to the SDP (offerA) of the terminal 500 (A) designated in S104. As automatic voice, there is a case in which silence is intentionally designated in addition to calling sound or voice guidance.

[Cut API]
Next, the cutting API 212 will be described.
The cutting API 212 can be realized by the procedure of RFC3725 (7. Page 10). According to this, when the gateway 200 receives a disconnection request with a session ID assigned when calling a connection API, BYE is transmitted to the terminal 500 connected to the session, and the session is disconnected.

[Switching API]
Next, the switching API 213 will be described.
FIG. 12 is a sequence diagram when the switching API 213 is called according to the present embodiment. First, in the sequence of FIG. 12, when the gateway 200 receives a switching request from the application 410 (S201), a response is returned to the application 410 (S202), and then the terminal of the session [1] specified by the session ID [1]. Call control is performed to switch the connection destination of 500 (A) from terminal 500 (B) to terminal 500 (C).

  In the call control, first, BYE is transmitted to the terminal 500 (B) to be disconnected after switching, and disconnected (S203, S204). Next, in order to prevent the terminal 500 (A) from entering a silent state during the switching process, re-INVITE transmission (S205 to S207) to the terminal 500 (A) is connected to automatic voice. However, in the sequence, connection to automatic voice (S205 to S207) is not essential. Thereafter, INVITE transmission without SDP setting is transmitted to the terminal 500 (C) (S208), and the offerC received in response is transmitted to the terminal 500 (A) by re-INVITE, whereby the terminals 500 (A) and (C) Is exchanged (S208 to S213), and a session in which media is negotiated between terminals is established.

  However, as a restriction of the sequence, when the terminal 500 (C) returns a busy response or an error response to the INVITE (S208), the terminal 500 (A) has no connection destination and is disconnected. Become. Since it is not known what kind of response the terminal 500 (C) will return unless it tries to send INVITE, switching is attempted, but if connection to the terminal 500 (C) fails, The API specification that the switching process is not performed cannot be realized.

  FIG. 13 is a sequence diagram in which processing at the time of terminal switching failure, which is a limitation of the sequence of FIG. 12, is improved. In this sequence, before the terminal 500 (B) is disconnected, INVITE transmission to the terminal 500 (C) is first performed (S303). When a normal response (200 OK) is returned from the terminal 500 (C) (S304), the terminal 500 (B) is then disconnected (S305, S306), and the terminals 500 (A), (C ) Is negotiated (S307 to S310). In this sequence, when an error response such as a busy response is returned in response to INVITE to the terminal 500 (C), the subsequent switching process can be stopped.

[Split API]
Next, the divided API 214 will be described.
FIG. 14 is a sequence diagram when the split API 214 is called according to the present embodiment. In the sequence of FIG. 14, when the gateway 200 receives a split request for the session ID [1] from the application 410 (S401), a response including the session ID [2] generated after the split is returned to the application 410 (S402). The connection destination of the session terminal 500 (A) specified by the session ID [1] is switched from the terminal 500 (B) to the terminal 500 (C), and the connection destination of the terminal 500 (B) is switched to the terminal 500 (D). Then, call control for establishing session ID [2] is performed.

  In the call control, first, INVITE without SDP setting is transmitted to the terminal 500 (C) (S403), a response (200 OK) is received (S404), and then the terminal 500 (B) automatically performs the split processing. A re-INVITE for sending audio is transmitted (S405 to S407). Thereafter, the SDP (offerC) on the response from the terminal 500 (C) is transmitted to the terminal 500 (A) by re-INVITE, thereby performing media negotiation between the terminals 500 (A) and (C). Session [1] is established (S408 to S411). Next, INVITE without SDP setting is transmitted to terminal 500 (D) (S412), a response (200 OK) is received (S413), and then SDP (offerD ′) on the response signal is transmitted to terminal 500 ( By transmitting to B), media negotiation between the terminals 500 (B) and (D) is performed, and the session [2] is established (S414 to S417).

[Binding API 215]
Next, the binding API 215 will be described.
FIG. 15 is a sequence diagram when the binding API 215 is called according to the present embodiment. In the sequence of FIG. 15, when the gateway 200 receives a join request (S601) from the application 410, it returns a response to the application 410 (S602), and then the terminal 500 (A) of the session [1] designated by the application 410 Then, call control for newly connecting the terminal 500 (C) of the other designated session [2] is performed.

  In the call control, first, BYE is transmitted to the terminal 500 (B) and the terminal (D) that are not to be combined and disconnected (S603 to S606). Thereafter, media negotiation is performed between the terminals 500 (A) and (C) (S607 to S612). When the terminal 500 (C) transmits re-INVITE (S609), “offerA ′” is set as the SDP, which is generated using the value held by the “offerA” and the terminal SDP management function 217. More specifically, first, when re-INVITE is transmitted from terminal 500 (A) (S607), re-INVITE without SDP is transmitted, and offerA of terminal 500 (A) is received as a response. After that, when re-INVITE is generated for the terminal 500 (C), using the SDP value for the terminal 500 (C) held by the offer A and the terminal SDP management function 217, the above [Restrictions at the time of media update] Exchange media according to In this way, by performing the media negotiation processing of S607 to S612 using the terminal SDP management function 217, session establishment by SDP exchange between the terminals 500 (A) and (C) can be realized. However, as a restriction of the sequence, in S607 to S612, when an error such as failure of media negotiation between the terminals 500 (A) and (C) occurs, the API specification that the division process is not performed cannot be realized. .

  FIG. 16 is a sequence diagram for explaining an operation in which the process at the time of the unsuccessful combination, which is a limitation of the sequence in FIG. 15, is improved. In the sequence, first, before the terminals 500 (B) and (D) are disconnected, media negotiation of the terminals 500 (A) and (C) is performed (S703 to S706). Then, after media negotiation ends normally, disconnection processing to terminals 500 (B) and (D) is performed (S707 to S710). In this sequence, even if the media negotiation between the terminals (A) and (C) ends in error, the subsequent combining process can be stopped.

[Call control event notification API]
Next, the call control event notification API 216 will be described.
FIG. 17 is a sequence diagram when the call control event notification API 216 is called according to the present embodiment. FIG. 17 shows a sequence when terminal 500 (A) transmits to terminal 500 (B ′). Here, a URI (Uniform Resource Identifier) for identifying the terminal of the terminal 500 (B ′) may be the same as that of the terminal 500 (B).

  When terminal 500 (A) sends (B ′) (S801), INVITE is not directly routed to terminal 500 (B), and gateway 200 receives INVITE first. Upon receiving the INVITE from the terminal, the gate 200 notifies the application 410 that an incoming call has arrived from A to B 'as an incoming call notification API (S802). At that time, by notifying the application 410 of the session ID [1], the application 410 can control the session using the call control API thereafter. The application 410 returns a response to the event notification (S803). The response can include control information for the session (forcibly disconnecting the session, changing the connection destination, etc.). Thereby, the session control operation designation at the time of incoming call by the application 410 is made possible.

  After a response is returned from the application 410, the gateway 200 transfers INVITE to the terminal 500 (B), and session [1] is established (S804 to S808). Thereafter, a notification of communication establishment is transmitted to the application 410 (S809). The application 410 can specify the received notification (S802, S809) to the gateway 200 in advance. However, as a problem of the sequence, if the response process (S803) of the application 410 is delayed, there is a possibility that the response to the terminal 500 (A) that made the transmission will be delayed and the silent state will continue. .

  FIG. 18 is a sequence diagram for explaining an operation in which the above problem is improved. In FIG. 18, in this sequence, before notification of an event (incoming call) to the application 410 in S <b> 904, connection to automatic voice or the like is made (S <b> 901 to S <b> 903). Then, after a response is returned from the application 410 (S905), media negotiation is performed by re-INVITE processing between the terminals (A) and (B), and the session [1] is established. Thereby, even when the response from the application 410 is delayed, the silent time of the terminal 500 (A) can be shortened.

According to the embodiment described above, the following effects can be obtained.
(1) A session control unit that is convenient for the developer of the application 410 is provided, and an advanced service using session control between the terminals 500 on the communication network 100 can be developed.
(2) By realizing the session control API based on the inter-terminal media negotiation, service development for multimedia compatible terminals such as voice, video, and data can be easily performed.
(3) By realizing the incoming event notification API, it is possible to develop a service application that uses media negotiation between terminals 500 in combination with the session control API even in the case of a session generated by terminal transmission.
(4) For the terminal 500, session control including only session control signals supported by many terminals is performed, so that the corresponding terminals are not limited while realizing various session controls.

  Note that the terminal 500, the gateway 200, the application server 400, and the like described above may have a computer system therein. The operation processes of the terminal 500, the session control API 210 of the gateway 200, and the application 410 of the application server 400 described above are recorded on a computer-readable recording medium in the form of a program, and recorded on this recording medium. The above processing may be performed by the computer system reading and executing the program. Here, the “computer system” may include an OS and hardware such as peripheral devices. Further, the “computer system” includes a homepage providing environment (or display environment) if a WWW system is used. The “computer-readable recording medium” means a flexible disk, a magneto-optical disk, a ROM, a writable nonvolatile memory such as a flash memory, a portable medium such as a CD-ROM, a hard disk built in a computer system, etc. This is a storage device.

  Further, the “computer-readable recording medium” means a volatile memory (for example, DRAM (Dynamic DRAM) in a computer system that becomes a server or a client when a program is transmitted through a network such as the Internet or a communication line such as a telephone line. Random Access Memory)), etc., which hold programs for a certain period of time. The program may be transmitted from a computer system storing the program in a storage device or the like to another computer system via a transmission medium or by a transmission wave in the transmission medium. Here, the “transmission medium” for transmitting the program refers to a medium having a function of transmitting information, such as a network (communication network) such as the Internet or a communication line (communication line) such as a telephone line. The program may be for realizing a part of the functions described above. Furthermore, what can implement | achieve the function mentioned above in combination with the program already recorded on the computer system, and what is called a difference file (difference program) may be sufficient.

It is a block diagram which shows the structure of the information communication system using the gateway (session control apparatus) by one embodiment of this invention. It is a block diagram which shows the structure of the gateway 200 by this embodiment. It is a sequence diagram which shows an example of the session control between the terminals by SDP exchange standardized as a media type determination method at the time of terminal transmission by this embodiment. It is a sequence diagram which shows the other example of the session control between the terminals by SDP exchange standardized as the determination method of the media type at the time of terminal transmission by this embodiment. It is a sequence diagram which shows the example of the method of determining the media type of the session controlled in the session control API210 of the gateway 200 by this embodiment. It is a sequence diagram which shows the example of the method of determining the media type of the session controlled in the session control API210 of the gateway 200 by this embodiment. It is a sequence diagram which shows the example of the method of determining the media type of the session controlled in the session control API210 of the gateway 200 by this embodiment. It is a sequence diagram when connection API211 is called by this embodiment. It is a sequence diagram at the time of implementing change of a connection destination and change of a media type for a certain terminal 500 being connected. It is a sequence diagram at the time of implementing change of the terminal 500 payload type in connection. It is a sequence diagram for demonstrating the operation | movement for avoiding the restriction | limiting matter at the time of the connection API211 being called by this embodiment. It is a sequence diagram when switching API213 is called by this embodiment. It is a sequence diagram for demonstrating the operation | movement for avoiding the restriction | limiting matter at the time of the switching API213 being called by this embodiment. FIG. 10 is a sequence diagram when a divided API 214 is called according to the present embodiment. It is a sequence diagram when combined API215 is called by this embodiment. It is a sequence diagram for demonstrating the operation | movement for avoiding the restriction | limiting matter when combined API215 is called by this embodiment. It is a sequence diagram when the call control event notification API 216 is called according to the present embodiment. It is a sequence diagram for demonstrating the operation | movement for improving the problem at the time of the call control event notification API216 being called by this embodiment.

Explanation of symbols

100 carrier network 200 gateway 210 session control API
211 Connection API
212 Cutting API
213 switching API
214 Split API
215 Binding API
216 Event Notification API
217 Terminal SDP management function 218 Media termination function 300 Information network 400 Application server 410 Application 500 Terminal

Claims (9)

In a session control device that receives a command from an application server and controls a session between communication nodes connected to a network of a communication carrier,
Session establishment means for establishing a session between the communication nodes in response to a command from the application server;
Session identifier notification means for transmitting a session identifier indicating a session established between the communication nodes to the application server;
Session control means for controlling a session established between the communication nodes according to a command from the application server;
A management means for performing media negotiation between the communication nodes when establishing a session with the communication node;
A session control apparatus comprising:   The management means includes holding means for holding a media negotiation result for each communication node, and determines a codec change accompanying a change in media type based on the media negotiation result for each communication node. The session control apparatus according to claim 1.   The session control means has switching means for switching one connection destination of the first and second communication nodes of the session being established to a third communication node based on a command from the application server. The session control apparatus according to claim 1.   The session control means has a dividing means for switching the connection destinations of the first and second communication nodes of the established session to the third and fourth communication nodes, respectively, based on a command from the application server. The session control apparatus according to claim 1, wherein:   The session control means re-establishes one communication node of the first session being established and one communication node of the second session being established with the session established, based on a command from the application server. 2. The session control apparatus according to claim 1, further comprising recombining means for combining.   The session control device according to claim 1, wherein the session control unit includes a disconnecting unit that disconnects an established session based on a command from the application server.   7. The session control means, when a session is established between communication nodes, notifies the application server of a session identifier that identifies the established session. Session controller. In a session control method for receiving a command from an application server and controlling a session between communication nodes connected to a network of a communication carrier,
Establishing a session between the communication nodes in response to a command from the application server;
Transmitting a session identifier indicating a session established between the communication nodes to the application server;
Controlling a session established between the communication nodes according to a command from the application server;
Performing media negotiation between the communication nodes when establishing a session with the communication node;
A session control method characterized by comprising: A computer that receives a command from the application server and controls a session between communication nodes connected to the network of the carrier.
Establishing a session between the communication nodes in response to a command from the application server;
Transmitting a session identifier indicating a session established between the communication nodes to the application server;
Controlling a session established between the communication nodes according to a command from the application server;
Performing media negotiation between the communication nodes when establishing a session with the communication node;
A program for running

Images