Method and arrangement for providing different services in a multimedia communication system

The present invention relates to methods and devices for providing different services in a multimedia communication system.

Currently, the telecommunications world, such as 3GPP and 3GPP2 (3rd Generation Partnership Project), is trying to determine the details of next-generation packet switch core networks for telecommunications services. The core network domain is called IMS (IP Multimedia Subsystem) in 3GPP and MMD (Multimedia Domain) in 3GPP2.

The similarity between the IMS domain and the MMD domain is that the call, or signaling to set up the session, is made using SIP (Session Initiation Protocol) (IETF RFC 3261). Multimedia services are set up using SIP messages that also include parts described by SDP (Session Description Protocol) (IETF RFC 2327). The multimedia client (terminal) that initiates the session or call must describe all media types (eg, image, audio, etc.) that the service uses in the SDP part of the message. The media type is negotiated in the SIP message exchange with the called multimedia client through the application server in the core network domain.

Media is typically sent over IP using RTP (Real Time Transport Protocol) (IETF RFC 3550), but other transmissions and applications can also be used.

IP-based networks allow you to make service changes. Service changes allow multimedia services to be populated with one or more media streams of the same or different types during active sessions, or multimedia during active sessions. You can remove one or several media streams of the same or different types from the service. Service changes are initiated, for example, by a user who wants to add an image stream to the current VoIP (Voice over IP) stream or remove the image stream from the current VoIP stream during an ongoing call. Will be done.

Service changes within VoIP are described as a negotiation procedure using SIP messages. By way of example, the client first sends a SIP message to initiate a VoIP call. This message is typically a SIP INVITE message. The SIP INVITE message contains an SDP containing a description of the voice codec (codec) to use. The user then attempts to attach an image stream to the session by sending another SIP INVITE message, also known as a re-INVITE message. In the re-INVITE message, both the description of the audio codec and the description of the image codec are described by SDP.

The concept within the IMS / MMD framework is Push-to-Talk (PoC) over cellular networks. This concept allows mobile phone users to communicate with other groups of mobile phone users in half-duplex mode, much like a walkie-talkie over IP. One advantage of using IP in a cellular network is that it allows you to use network resources more efficiently. Network resources talk for the duration of the call session, not for the entire call session. Used only during spurt). The call session described above is established using SIP, and the media channel that carries the voice uses RTP. PoC requires a specific call control function to realize a walkie-talkie style. For example, when a media channel is idle, users request access to this channel by pressing a button on their mobile phone (to start talking to other users in the group). it can. When the user releases the button, the media channel becomes free and other users in the group can request access to this channel. This mechanism is called "floor control" because it involves "controlling the floor". To provide PoC with a global, interoperable standard, the telecommunications community has provided a number of specifications in this area. One example is the PoC Release 1.0 specification, PoC User Plane; Transport Protocol. Protocols), which details the voice control mechanism in media channels that use the RTP Control Protocol (RTCP). However, the voice control mechanism does not explain service changes.

<p> The problem with using out-of-band signaling for service changes in multimedia conversations (eg SIP / SDP) is that each signaling message goes through a number of intermediate network nodes (SIP cores). The SIP / SDP protocol also uses many messages. This is because the content in these messages uses "human readable" ASCII syntax instead of the binary coded one. The SIP / SDP protocol also requires the reestablishment of an ongoing session for each service change. All of these factors cause unnecessary delays and increase the load on the processor.</p>

<p> The present invention first solves the above problem by separating signaling into two planes, namely a session signaling plane and a media control signaling plane.</p><p> The session signaling plain includes signaling for session control (eg, using SIP signaling messages known as prior art). Session signaling is transmitted over the session signaling channel. The media control signaling plane includes media control signaling as a service change, a voice control, and the like. Media control signaling is transmitted on a media control channel that is separate from the session signaling channel. The media control channel is implemented within the bandwidth within the media channel or using a separate channel that is closely related to the media channel.</p><p> The present invention also provides a novel media type negotiation procedure involving an intermediate application server. This application server collects information about the media types that each multimedia client involved in the session can support. From the information collected, the application server can determine which media type each multimedia client is allowed to use in order to achieve maximum interoperability.</p><p> A multimedia client (session initiating client) that wants to establish a session that contains two or more multimedia clients invites each multimedia client (Invite). A session is established by sending an invitation message over an out-of-band signaling channel to an intermediate application server with an address to the multimedia client to invite. The invitation message also contains a set of media types that the session initiation client can support.</p><p> The application server forwards the session invitation message to the invited multimedia client. When the invited multimedia client accepts the invitation, it responds by notifying in the session response message a set of media types that the multimedia client can support. The application server responds to the session start client with a session response message stating that the session establishment was successful.</p><p> For each invitation procedure to other multimedia clients, the application server collects information about the media types supported for these other multimedia clients.</p><p> One of the multimedia clients involved in the session (hereinafter referred to as the requesting or sending multimedia client) is a multimedia stream with one or more media types (eg, audio, image, etc.). When it wants to send, the multimedia client sends a first media request containing a set of "requested" media types. A set of "request" media types is equal to or a subset of the set of media types supported for request multimedia clients. From the collected information about the media types that all multimedia clients involved in the session can support, the application server is "allowed" in the first media grant to the request multimedia client. Allow a set of media types.</p><p> The first media request and first media authorization are transmitted in the session invitation and session response messages, or in a separate media control message on a different media control channel than the session signaling channel. This media control channel can be implemented as a separate channel or within the bandwidth within the media channel. Media control messages can use short binary syntax instead of the ASCII syntax used in traditional session control messages.</p><p> This allows the request multimedia client to send the media stream (according to a set of "allowed" media types) over the media channel through the application server to the receiving multimedia client. It can be performed. The application server copies the media stream (if necessary) and resends it to the receiving multimedia client.</p><p> At some point during the session, the user of the request multimedia client, for example, changes from sending only audio to sending audio and images to the receiving multimedia client. On the other hand, suppose that you want to change the service.</p><p> The request multimedia client sends a new media request to the application server, including a new set of "request" media types. The application server allows the request multimedia client a new set of "allowed" media types in the new media allowance.</p><p> This allows the request multimedia client to now send the receiving multimedia client a media stream (according to a new set of "allowed" media types) over the media channel through the application server. Can be sent.</p><p> New media requests and new media permits are transmitted in media control messages.</p><p> Even if not all receiving multimedia clients support a particular media type, the application server allows the request multimedia client to send this particular media type. In this case, the application server terminates the media flow associated with this particular media type instead of resending it to the receiving multimedia client.</p><p> The application server also allows different sets of "allowed" media types for request multimedia clients, depending on additional parameters such as local policies and subscriber information enforced by the application server etc. it can.</p><p> The present invention can reduce signaling delays in the network by using a media control protocol that is separate from the session control protocol and does not pass through the SIP core. Also, according to the present invention, signaling can be significantly reduced because it is not necessary to reestablish the ongoing session for each service change. The user can recognize the reduction of signaling and delay, and the speeding up of the service change procedure.</p><p> Hereinafter, the present invention will be described in more detail with reference to the accompanying drawings, along with preferred embodiments.</p>

FIG. 1 shows the functional architecture of a multimedia communication system in which at least one embodiment of the present invention is implemented. This architecture includes a plurality of multimedia clients 110, an application server 120, and a network 130, which are illustrated as mobile video phones in FIG. Application server 120 includes a plurality of functional entities such as session signaling unit 121 and media resource unit 122. The session signaling unit 121 has a signaling interface 123 that receives a SIP signaling message from the multimedia client 110 and sends a SIP signaling message to the multimedia client 110. The SIP signaling protocol is transmitted over session signaling channel 141. The media resource unit 122 has a media control interface 124 that transmits media control signaling to the multimedia client 110 and receives media control signaling from the multimedia client 110. Media control signaling is transmitted through media control channel 142. The media stream (media flow) is transmitted through media channel 143. The media resource unit 122 has a media interface 125 that transmits a media stream to the multimedia client 110 and receives the media stream from the multimedia client 110. If necessary, the media resource unit 122 uses the copying unit 126 to copy the media stream received from the multimedia client 110 to other multimedia clients involved in the multimedia conversation. The media resource unit 122 also has media in the media stream received from the multimedia client 110. The media type can be terminated when the assignment is not supported by a particular other multimedia client. The application server 120 also has processor logic 128 that handles session signaling and media control signaling, and storage area 127 that stores a set of media types supported for each multimedia client 110.

Session signaling channel 141 can pass through a number of different intermediate nodes in network 130, where session signaling messages are processed. The intermediate node that processes SIP signaling is collectively called SIP core 131. Both media control channel 142 and media channel 143 are clearly separated from session signaling channel 141. However, the media control channel 142 and the media channel 143 may be integrated into the same channel.

FIG. 2 shows a typical information flow for service changes as seen from the application server 120. The application server 120 receives the session invitation message 201 from the first multimedia client. The session invitation message contains a set of media types supported by the first multimedia client. This set is stored in application server 120 (204). The application server 120 sends the session invitation message 202 to the second multimedia client. When the second multimedia client accepts the invitation, it sends session response message 203. This session response message 203 contains a set of media types supported by the second multimedia client. This set is also stored in application server 120 (204). The application server 120 sends a session response message 205 indicating that the session invitation was successful to the first multimedia client. The session invitation procedure is repeated for each of the other multimedia clients invited to the session by the first multimedia client.

When one of the multimedia clients involved in the session, the request multimedia client, wants to send a multimedia stream (eg, audio) to the other multimedia client, the request multimedia client , Send the first media request 206. The first media request 206 includes a set of first "requested" media types. The application server 120 is supported by the first set of "request" media types and other multimedia clients because the application server 120 has knowledge of the supported media types for other multimedia clients. Allow the request by comparing it with the entire set of media types (207) and responding with media allowance 208 with the first "allowable" set of media types. A request multimedia client is a media type with a set of "first tolerated" media types that can carry a media stream (media flow) through a media channel. The media stream (media flow) is received by the application server 120 (209), copied (if necessary), and retransmitted to other multimedia clients (210). During the conversation, when the request multimedia client wants to change the media stream (media flow) (for example, by adding video to the ongoing audio conversation), the request multimedia client has a second " Request A second media request 211 containing a set of media types is sent to the application server 120. The application server 120 compares the set of "second request" media types with all sets of media types supported by other multimedia clients (212) and requests with second media permission 213. Allow Est (213). This second media allowance 213 includes a set of second "allowable" media types. This allows the request multimedia client to transmit a modified media stream (media flow) through the media channel with a media type with a set of second "allowable" media types. This media stream (media flow) is received by the application server 120 (214), copied (if necessary), and retransmitted to other multimedia clients (215).

The first and second media requests 206 and 211 and the first and second media permits 208 and 213 are typically transmitted in a media control message.

Figure 2 shows a typical information flow and can be modified in various ways. When the request multimedia client is the same as the first multimedia client and the first multimedia client wants to start sending data directly after the invitation procedure, the first media request 206 and the first media Authorization 208 can be included in session invitation message 202 and session response message 205. Instead, the first media request 206 can be sent in the session invitation message and the first media authorization 208 can be sent in a separate media control message.

The first media request 206 and the first media permit 208 can be "implicit" media permits. For example, when application server 120 learns that a VoIP service has been requested (from stored multimedia client subscription data or by looking at other parameters in session invitation message 201), the first Media permission 208 can be incorporated into session invitation message 202 destined for the second multimedia client and session response message 205 destined for the first multimedia client. In this example, the first media permission 208 includes the media type "voice" because the VoIP conversation usually starts with voice.

In addition to the media type comparison (207, 212), the application server 120 is a request multimedia client, depending on other parameters such as local policies and subscriber information enforced by the application server 120. Can allow different sets of "acceptable" media types (208, 213).

The service change procedure shown in Figure 2 and described above is, of course, not limited to just one or two service change events. Service changes can be requested and repeated using the media control messages described above at any time during the session at the convenience of any of the involved multimedia clients.

For multimedia clients that do not support certain media types in the retransmitted media stream (media flow), this particular media type ends in application server 120 before reaching these clients. Can be made.

Figures 3 and 4 show examples of session establishment and service modification for VoIP (Voice over IP) conversations enriched with images (eg, video clips). The network entities involved in this information flow are the two user terminals: the multimedia clients first client 310 and second client 350, the SIP core 131, and the application server 120.

The multimedia clients 310 and 350 use SIP signaling and media control signaling to communicate with the application server 120. SIP signaling messages are typically transmitted over session signaling channel 141 and processed by a number of intermediate nodes or SIP cores 131 in the signaling network. Media control signaling is separated from the SIP core and transmitted over media control channel 142. The application server 120 receives and retransmits the media stream sent from the multimedia clients 310 and 350 through the media channel 143.

Figure 3 shows the information flow that establishes a session between the first client 310 and the second client 350. Figure 4 shows the information flow for the service change procedure.

A user using the first client 310 requests the start of a multimedia session with another user using the second client 350 (301). The first client 310 sends SIP INVITE message 311 to SIP core 131. SIP INVITE message 311 contains a set of all media types (voice and image in this example) that the first client 310 can support. SIP INVITE message 311 also includes a set of first request media types (voice only in this example). SIP core 131 responds with SIP100 attempt message 312. SIP100 trial message 312 indicates that SIP INVITE message 311 was received by SIP core 131 and that some unspecified action has been taken for this session. SIP core 131 is a SIP containing the set of media types received from the first client 310. Send INVITE message 321 to application server 120. Application server 120 responds with SIP100 attempt message 322 to SIP core 131. The application server 120 stores the set of media types received from the first client 310 and sends the SIP INVITE message 331 to the SIP core 131. SIP core 131 responds to application server 120 with SIP100 attempt message 332 and SIPs Send INVITE message 341 to the second client 350. The second client 350 issues an incoming call instruction 351 to the user of the second client 350. When the user accepts the session invitation (352), the second client 350 sends the SIP200OK message 342 to the SIP core 131, and the SIP core 131 sends the SIP200OK message 333 to the application server 120. The two SIP200OK messages 342 and 333 carry a set of all media types (audio and image in this example) that the second client 350 can support, and this set is stored in the application server 120. The application server 120 compares two sets of all media types supported by the first client 310 and the second client 350, respectively. The application server 120 includes a set of first acceptable media types (voice only in this example) because the first client 310 requests to start with voice only and the second client 350 supports voice. Send SIP200OK message 323. The SIP core 131 transfers this information to the first client 310 in the SIP200OK message 323. The first client 310 sends a SIP ACK message 314 to the SIP core 131, and the SIP core 131 sends a SIP ACK message 324 to the application server 120.

This allows the first client 310 to now initiate voice transmission to the second client 350 through media channel 143 via application server 120 using RTP protocols 325 and 343.

A service change is required if the user of the first client 310 wants to send a live video clip to the second client 350 in addition to the audio during the audio conversation. The information flow for service changes is shown in Figure 4. When the user of the first client 310 requests this service change (401), the first client 310 sends a media control message 411 containing a request to send audio and images to the application server 120. Since both the first client 310 and the second client 350 support images, application server 120 permits this request in media control message 412. The application server 120 also sends a media control message 431 indicating a service change to the second client 350. This allows the first client 310 to send both audio and image media streams 421 and 441 to the second client 350.

When the user of the first client 310 requests to end the image stream and continue only the audio stream (403), the first client 310 issues a media control message 413 requesting to abandon the video stream to the application server 120. Send to. The application server 120 sends a media control message 432 indicating a new service change to the second client 350.

As a result, the first client 310 now sends only audio to the second client 350 (422, 442). The media control message 413 relates to abandoning one media type, so the application server 120 does not need to send a response message.

5 and 6 show another preferred embodiment of the invention. Figures 5 and 6 show the procedure for establishing a session and changing services for PoC (Push to Talk on Cellular), which is rich in images. The principle is the same as VoIP (Figures 3 and 4), but media control signaling is carried in the same message used for the voice control procedure known in PoC and conference applications. To. Voice control in the PoC context basically gives mobile phone users half-duplex access to a communication channel common to other groups of mobile phone users by simply pressing a button on the mobile phone. You can request it.

First, suppose that the first PoC user presses a button on the mobile phone, referring to FIG. 5 (501). If no session with another mobile phone already exists, this event 501 initiates the session initiation process by the first PoC client 510, which sends a SIP INVITE message 511 to SIP core 131. SIP INVITE message 511 is considered an implied "speaking request". SIP INVITE message 511 includes a set of all media types (voice and image in this example) that the first PoC client 510 can support. SIP INVITE message 511 also includes a set of first request media types (voice only in this example). SIP core 131 responds to first PoC client 510 with SIP100 attempt message 512. SIP core 131 sends SIP INVITE message 521 to application server 120. SIP INVITE message 521 contains a set of media types received from the first PoC client 510. Application server 120 responds with SIP100 attempt message 522 to SIP core 131. Application server 120 stores a set of all media types that the first PoC client 510 can support and sends SIP INVITE message 531 to SIP core 131. SIP core 131 responds to application server 120 with SIP100 trial message 532 and sends SIP INVITE message 541 to second PoC client 550.

The second PoC client 550 sends the SIP200OK message 542 to the SIP core 131, and the SIP core 131 sends the SIP200OK message 533 to the application server 120. The two SIP200OK messages 542 and 533 carry a set of all media types (audio and image in this example) that the second PoC client 550 can support, and this set is stored in application server 120. The application server 120 compares two sets of all media types supported by the first PoC client 510 and the second PoC client 550, respectively. Since the first PoC client 510 requests to start with voice only and the second PoC client 550 supports voice, application server 120 sends SIP202 Accepted message 524. SIP core 131 transfers this information to the first PoC client 510 in SIP200 authorization message 513. In connection with sending SIP202 Grant Message 524, Application Server 120 also contains a combination of media request messages and voice control messages, along with a set of first allowed media types (voice only in this example) Message 523. To send.

The first PoC client 510 sends the SIP ACK message 514 to the SIP core 131, and the SIP core 131 sends the SIP ACK message 525 to the application server 120. The user of the first PoC client 510 receives a talk instruction that allows the talk to begin (502). The application server 120 sends a floor taken voice message 534 to the second PoC client 550, and the user of the second PoC client 550 receives a listening instruction.

As a result, as shown in FIG. 6, the first PoC client 510 is now directed to the second PoC client 550 through media channel 143 via application server 120 using RTP protocols 621 and 641. You can start transmitting the half-duplex audio stream.

The user of the first PoC client 510 can "waive his voice" at any time and release the PoC button to make the channel available to other PoC clients (602). In this case, the voice message 611 for giving up the right to speak is sent to the application server 120. The application server 120 sends a free voice message 631 to the second PoC client 550 to indicate that it is idle. The user of the second PoC client 550 receives the voice free instruction 651 in the second PoC client 550.

At some point during the session, the user of the first PoC client 510 makes a request to send a multimedia burst that involves both audio and image (603). As a result, the first PoC client 510 transmits the voice request voice and the image message 612 to the application server 120. When granting this request, the application server 120 sends a Floor Taken voice and image message 632 to the second PoC client 550 and sends the Floor Granted voice and image message 613 to the first PoC client 510. Send. The user of the second PoC client 550 receives the incoming image and voice call instruction 652 on the second PoC client 550, and the user of the first PoC client 510 receives the talk and show instruction 604 on the first PoC client 510.

This allows the first PoC client 510 to now send half-duplex audio and image streams to the second PoC client 550 over media channel 143 via application server 120 using RTP protocols 622 and 642. Can be started.

When the user of the first PoC client 510 requests the abandonment of the audio and video stream (605), the first PoC client 510 sends a floor release audio and image message 614 to the application server 120. The application server 120 sends a floor Idle message 633 to the second PoC client 550. The user of the second PoC client 550 receives the voice free instruction 653 in the second PoC client 550. The media channel between the 1st PoC client 510 and the 2nd PoC client 550 is now idle. This allows "speaking rights" to be requested by any client involved in the session.

Although the embodiment of the present invention illustrated and described above relates to a service change between two multimedia clients, the present invention is not limited to the above embodiment, and any number of multimedia can be used. -Allows service changes involving clients. A SIP VITE message is sent via the application server 120 to the invited new multimedia client. Each SIP 200 that application server 120 receives from each invited client Supported by each invited client in response to OK messages, the set of media types contained in these messages is stored in application server 120. Every time any multimedia client involved in a session (request multimedia client) sends a request to send a media stream (or a "speak" request), the application server 120 has everything else involved. Allow this request based on the media types supported by the multimedia client and the availability of media channel 143 at that time. The application server can allow a request multimedia client to send a particular media type even if the particular multimedia client involved in the session does not support that particular media type. In this case, the application server terminates this media stream (media flow) by this media type in the application server instead of resending this particular media type to a particular multimedia client.

The term "media type" does not simply mean audio, images, images, etc., but also, for example, different types of codecs that use different algorithms to encode / decode audio, images, etc. To do.

<figref num="1">Figure 1 is a block diagram showing a functional architecture that includes network elements as well as separate signaling and media interfaces.</figref><figref num="2">FIG. 2 is a flow chart showing a typical information flow for service change.</figref><figref num="3">FIG. 3 is a flow diagram showing an information flow for establishing a voice session in an embodiment including VoIP and images.</figref><figref num="4">FIG. 4 is a continuation of FIG. 3 showing an information flow requesting a service change during a voice session established in an embodiment involving VoIP and images.</figref><figref num="5">FIG. 5 is a flow diagram showing an information flow for establishing a session in an embodiment including PoC and images.</figref><figref num="6">FIG. 6 is a continuation of FIG. 5 showing an information flow requesting a service change during a session established in an embodiment including PoC and images.</figref>