MXPA06008944A - Method and system for transmitting a multimedia message to multiple recipients - Google Patents

Abstract

A method of transmitting a message to multiple recipients comprising:receiving a message addressed to multiple recipients;determining an indication of a state of each recipient;and transmitting an acknowledgement, the acknowledgment including at least one message identifying at least one recipient and the associated state of said at least one recipient.

Description

METHOD AND SYSTEM TO TRANSMIT A MULTIMEDIA MESSAGE TO MULTIPLE RECIPIENTS FIELD OF THE INVENTION The invention relates to transmissions of message transfer to a plurality of recipients, and in particular, but not exclusively, to the transfer of multimedia messages between relays / multimedia messaging service servers in different multimedia messaging service environments. .

BACKGROUND OF THE INVENTION In 3GPP TS23.140 version 6.1.0 (or later), the inter and series of MM4 protocols support the sending of messages that have multiple recipients of a multimedia messaging service (MMS) relay / server in an environment from multimedia messaging service (MMSE) to another relay / MMS server in a different MMSE. In 3GPP TS23.140 version 6.1.0, a multimedia service reference (MMS) architecture is defined that identifies reference points within a multimedia service network architecture (MMSNA). The reference points represent inters in the MMS reference architecture. Eight reference points are defined and are called MMl to MM8. The reference points represent the inters, REF .: 174674 respectively, between an MMS user agent and an MMS relay / server; between an MMS relay and an MMS server; between an MMS relay / server and an external (legacy) messaging system; between one MMS relay server and another MMS relay server within another MMSE; between an MMS relay / server and a main location register; between an MMS relay / server and an MMS user database; between an MMS relay / server and a VAS application (value added service) MMS; and between an MMS relay / server and a registration system. The reference point between the relay / MMS server and another relay / MMS server that is inside another MMSE is designated MM4. 3GPP TS23.140 version 6.1.0 defines the inter and series of MM4 protocols to support the sending of messages between an MMS relay / server in a first MMSE and a relay / MMS server in a second MMSE. The inter and protocol allow the sending of messages between relays / respective MMS servers that have multiple recipients. Before 3GPP TS23.140 version 6.1.0 it was possible to send messages with multiple recipients in the inter provided by reference point MMl, which is the low bandwidth air inter. However, in the main network, where capacity has not usually been a problem, the messages have been transferred individually to each recipient.

In 3GPP TS23.140 version 6.1.0 messages are sent to multiple recipients in a message of protocol data units (pdu) MM4_remove .REQ from a relay / MMS server creator to a relay / MMS recipient. This message carries an information element of "message ID (identifier)", which uniquely identifies the message and is applicable to all recipients. The message includes MMS control information and multimedia content. The relay / MMS creator server can optionally request that the recipient MMS relay / server confirm the message transfer in the MM4 inter. Then, the relay / recipient MMS server responds with a message pdu MM4_togo. RES, which provides the status of the application. However, if multiple recipients are addressed in the request message, the recipient MMS relay / server can only respond with a limited response message. Response messages contain only the message ID, which is unique to the message but not from any original recipient. No indication of a recipient that causes a partial addressing failure is contained in the response message. An object of the invention is to provide an improved messaging inter. In particular, an object of the embodiments of the invention is to provide an inter of Improved MMS messaging between different MMS environments.

BRIEF DESCRIPTION OF THE INVENTION In one aspect of the invention, a method for transmitting a message to multiple recipients is provided, comprising: receiving a message addressed to multiple recipients; determine an indication of a state of each recipient; and transmitting a confirmation, the confirmation includes at least one message identifying at least one recipient and the associated state of the recipient or recipients. The state of each recipient can indicate a status of transmission of the message to that recipient. The step of receiving a message addressed to multiple recipients may include receiving a request to transmit the message to multiple recipients. The request to transmit the message to multiple recipients may be inherent in receiving a message addressed to multiple recipients.

The request to transmit the message to multiple recipients may be included in the reception of a message addressed to multiple recipients. The confirmation may include a plurality of messages where each identifies at least one recipient, and each includes one of a plurality of corresponding states. The confirmation may include minus a message identifying a plurality of recipients' series and a corresponding plurality of states where each state is associated with a series of recipients. Each series can contain one or more recipients. The state may indicate one of the following: an invalid recipient address; an incomplete transmission; or a successful transmission. The status may indicate that the status is unknown. The method may further comprise the step of, in response to a receipt of a confirmation message indicating an incomplete transmission, retransmitting the message to the recipient or the recipients identified in the confirmation message. The message or messages identifying at least one recipient and a state of transmission to the recipient or recipients can identify a plurality of recipients, such a status is common to all identified recipients. The method may also comprise the step of receiving a request to transmit the message from a creator of the message and transmitting the confirmation to the creator of the message. The creator of the message can have a mailbox and the confirmation is transmitted to the mailbox.

The confirmation can provide the creator of the message with a delivery status for each recipient. At least one message can be transmitted through the use of the session initiation protocol. The message can be a multimedia services message. In another aspect the invention provides a method for transmitting a multimedia message to multiple recipients comprising: receiving in a creative multimedia services element a request to transmit the message to multiple recipients in a different multimedia services environment; transmitting the multimedia message from the creative multimedia services element to a multimedia services element addressed to the different multimedia services environment, including an identity of the recipients; determine the status of each recipient in the recipient multimedia services element; and transmitting a confirmation of the multimedia service element recipient to the creator multimedia services element, the confirmation includes at least one message identifying at least one recipient and a status of the recipient. The multiple recipients of the different multimedia services environment may be subscribers of the different multimedia services environment. The request to transmit the message to multiple Recipients in a different multimedia services environment may also include a request to transmit the message to one or more recipients in the creative multimedia services environment. The request to transmit the message to multiple recipients in a different multimedia services environment may also include a request to transmit the message to one or more recipients in a different multimedia services environment. In response to a confirmation message indicating an incomplete transmission status, the method may include retransmitting the multimedia message from the creative media services element to a multimedia services element addressed to the different multimedia services environment, the retransmitted message identifies the recipients associated with the status of incomplete transmission. In another aspect the invention may provide a message format of protocol data units MM4_remove .RES in accordance with 3GPP TS23.140, which includes an information element that identifies at least one recipient, the status in the message applies to recipient or recipients. The information element can identify a plurality of recipients, the status in the message applies to the plurality of recipients. In another aspect the invention provides a network element that includes means for receive a message addressed to multiple recipients; means for determining an indication of a state of each recipient; and means for transmitting a confirmation, the confirmation includes at least one message identifying at least one recipient and the associated state of the recipient or recipients. The means for transmitting a confirmation may be adapted to transmit a plurality of messages identifying at least one recipient, each of the plurality of messages including one of a plurality of corresponding states. In another aspect the invention provides a network element that includes means for receiving a message addressed to multiple recipients; means for forwarding such a message with an identity of multiple recipients; and means for receiving a confirmation message including at least one message identifying at least one recipient and the associated state of the recipient or recipients. The network element may also include means for resending such a message identifying those recipients associated with a state corresponding to a transmission failure. The invention also provides, in a multimedia messaging system, a multimedia services creator element having means to receive a request for transmit a message to multiple recipients in a different multimedia services environment; and means for transmitting the multimedia message from the creative multimedia services element to a multimedia services element addressed to the different multimedia services environment; and the recipient multimedia services element includes means for determining the status of each recipient; and means for transmitting a confirmation of the multimedia service element recipient to the creator multimedia services element, the confirmation includes at least one message identifying at least one recipient and a status of the recipient. The multimedia service elements may comprise relays, servers or relays / multimedia service servers.

BRIEF DESCRIPTION OF THE FIGURES The invention is described herein by way of example with reference to the attached figures, in which: Figure 1 illustrates the interworking of different multimedia service environments; "Fig. 2 illustrates a messaging flow in an embodiment of the invention that is applied to the environment of Fig. 1; Figure 3 illustrates the steps of the method associated with the message flow of Figure 2.

DESCRIPTION OF THE PREFERRED MODALITIES The invention is described herein by way of reference to applications of particular examples. However, the invention is not limited to such applications. In particular, the invention is described in an exemplary implementation of the exchange of multimedia service messages between different multimedia service environments. Reference is made to Figure 1, which illustrates an overview of the interworking of two different multimedia service environments (MMSE), as defined by 3GPP TS23.140 version 6.4.0. With reference to Figure 1, a first multimedia service user (UA) A (MMS) A, denoted by the reference numeral 104a, is connected to a first MMS A relay / server, denoted by the reference numeral 106a, of a first MMSE service provider A, denoted by reference numeral 102a. A second MMS user agent B, denoted by the reference numeral 104b, is connected to a second MMS B relay / server, denoted by the reference numeral 106b, of a second MMSE B service provider, denoted by the reference numeral. 102b. Each of the user agents 104a and 104b is connected to the respective MMS relay / server via an interface connection 108a and 108b respectively. The first and second relays / MMS servers 106a and 106b are interconnected via an interface 110. - - Each of the MMS user agents 104a and 104b constitutes an application that resides in a user equipment., a mobile station or an external device that performs specific MMS operations on behalf of a user. The MMS user agent is not considered part of an MMSE. Each of the MMS relays / servers 106a and 106b is a network / application entity or MMS-specific element and operates under the control of an MMS service provider. Each MMS relay / server transfers messages, provides MMS operations that are specific to or required by the mobile environment, and provides temporary and / or permanent storage services to the MMS. The MMS reference architecture, as defined by 3GPP TS23.140 version 6.4.0, defines an MMS reference architecture and eight interfaces within the reference architecture denoted MMl to MM8. Figure 1 shows two of these reference points. The interfaces 108a and 108b between the MMS user agents and the MMS relays / servers represent the reference point MMl, which is the reference point between the MMS user agent and the MMS relay / server. The MMl reference point is used to send messages multimedia from an MMS user agent to an MMS relay / server, to let the MMS user agent extract multimedia messages from the relay / MMS server, to let the relay / MMS server enter information about multimedia messages to the MMS user agent as part of a multimedia message notification, and to exchange delivery ports between the MMS relay / server and MMS user agents. The interface 110 between the relays / MMS servers of the respective service environments represents the interface MM4, which is the reference point between the relay server MMS and another relay / MMS server that is inside another MMSE. The interface provided by reference point MM4 is used to transfer messages between the respective relays / MMS servers. The interworking between relays / MMS servers is based on the simple mail transfer protocol (SMTP). Each relay / MMS server is adapted for peer discovery, to locate relays / MMS servers in other MMSEs. In a multimedia message transmission, an MMS relay / server that transmits a message is called a creator, and an MMS relay / server that receives a message is called a recipient or destination. After successful discovery of a homologous entity, a MMS relay / server creator routes a multimedia request message to the relay / server MMS recipient. This request message contains MMS control information and multimedia message content. The recipient MMS relay / server must respond with a response message if the MMS relay / server creator has a "confirmation request" information element field set in message MM4_remove .REQ. The response message provides, for example, the status of the request. The request message is a MM4_reenviar.REQ message, and the response message is a message MM4_remove .RES. These messages are from protocol data units (PDUs) defined by 3GPP TS23.140. The invention, in this embodiment, provides an adaptation of the response message, as discussed more fully below. No adaptation of the request message is necessary. In accordance with this embodiment of the invention, an additional information element is included in message MM4_remove .RES. This information element is called "recipients". However, the name of the information element is not limiting. The information element includes a list of recipients. If the message MM4_realviar .RES contains a collective status indication in response to a message MM4_remove .RES, with multiple recipients, the list of recipients contained in the message MM4__remove .RES identifies the recipients to who applies the collective status. A message MM4_submit.RES includes a value of request status, and this value of application status applies to all recipients identified in that message. The information elements in the MM4_reenviar protocol data unit message .RES, adapted according to this embodiment of the invention, are illustrated below in table 1.

TABLE 1 All the information elements shown in Table 1 are defined in 3GPP TS23.140 version 6.4.0, with the exception of the new information element according to this embodiment of the invention, ie the information element "recipients". The other information elements shown will be familiar to the expert the technique, and the function of such information elements is described in the column "description" day table 1. The column "presence" day table 1 identifies whether the presence of such information element is optional, mandatory or conditional. As shown in Table 1, the presence of the information element "recipients" is conditional. By example, if the message was addressed to a single recipient, it is not essential to include the information element "recipients" in the response, since it is effectively redundant. Also, if the request status is the same for all recipients, the recipient information element is not necessary in the response. However, in both cases the recipient information element may still be present. The operation of an embodiment of the invention to ensure the reliable transfer of multimedia services between multimedia service environments is now further described with reference to the flow of messages of figure 2 and the flow process of figure 3. With reference to figure 2, there is shown an example in which a multimedia message is transmitted by relay / server MMS A 106a to relay / server MMS B 106b. Accordingly, the MMS relay / server A 106a is the creator multimedia messaging service controller (MMSC), and the MMS relay / server B 106b is the target MMSC or recipient. In a step 302, an MMS request is received on a line 202 in the MMS relay / server 106a. In the example, the MMS will be sent to five recipients, called a, b, c, d, e. As is known in the art, the MMS relay / server 106a performs a discovery process to identify the relay / MMS server counterpart appropriate. In this way the relay / destination MMS server or recipient 106b is identified. In this example, the five recipients are located for simplicity within the same MMSE 102b, that is, controlled by the relay / MMS server 106b; however, this may not necessarily be the case in practical implementations. The creator MMS relay / server 106a receives the MMS at the air interface, which is denoted by reference point MMl in the MMS reference architecture. "As denoted by step 304, the interface provided by reference point MM4, denoted by the reference numeral 204, is then used by the MMS relay / server 106a to transmit an MMS request message (denoted by MM4_reenviar.REQ by 3GPP TS23.140), which includes the identity of the five recipients, to the relay / destination MMS server 106b.According to 3GPP TS23.140 version 6.1.0, the request for a confirmation is an optional feature.However, the invention described in this application also applies even if the provision of a confirmation is mandatory. discussed above, the message sent in the interface MM4 204 is an SMTP message, and is a request message from pdu MM4_remove REQ.The message also includes a unique identifier, which identifies Only the message. As denoted by step 306, the relay / MMS server recipient 106b receives the MMS request message from the MMS relay / server 106a at the interface MM4 204. An MMS relay / recipient server, upon receiving an MMS request message, and specifically a MM4_reenviar.REQ pdu, has to determine the status code of request for each recipient before attempting to forward the pdu to the recipients. This is known in the art, and is necessary due to the latency involved in communicating with the recipients (for example, the recipient can itself determine when he is ready to retrieve the pdu). It is worth mentioning that the recipients are user agents. In order to determine the request status code for each recipient, the recipient MMS relay / server additionally retrieves a user agent profile for each recipient. This is also denoted by step 306. The user agent profiles are retrieved from a database denoted as the MM6 reference point by 3GPP TS23.140 version 6.1.0. In a step 308 the receiving MMS relay / server examines both the MM4_reenviar pdu it has received and a user agent profile it retrieves from the database. The user agent profile contains a description of the capabilities of the user agent and possibly other user agent specific data, for example, if the User agent is blocked. The recipient MMS relay / server then determines for each user agent (or recipient) whether the actual message (which is the format MMl_recover .RES generated from MM4_realire .REQ) can be forwarded to the user agent in question. After such determination, a status code is determined for each recipient as denoted by step 310. The possible application status codes defined by 3GPP TS23.140 version 6.4.0, and their meanings, are set forth in Table 2 then.

TABLE 2 Not all status codes are possible as a result of the examination of step 308. Those status codes that may possibly be determined for each recipient in accordance with the embodiments of the invention are discussed in more depth hereinafter. The status code "Ok" indicates that the message can be delivered to the recipient 'as is', or after adaptation of content made by the recipient relay / MMS server. The status code "Error - unspecified shipping address" indicates that the particular recipient (agent user) is not a subscriber of the relay / recipient MMS server. The code of "Error - content not accepted" status indicates that the particular recipient (user agent) is unable to accept the content of the message. The status code "Error - network problem" indicates that the recipient MMS relay / server is not able to accept the corresponding request due to a capacity overload. This status could be given in a way imaginable by recipient (user agent) from relays / MMS servers that can set a limit on the maximum number of recipients allowed for a single message. This status could also occur in an imaginable way if some of the recipients are really applications (instead of headphones) that are overloaded or temporarily unavailable. The other codes listed in table 2 and not mentioned above apply to the pd MM4-resend .REQ as an entity, and not to the individual recipients (user agents), and therefore are not relevant to the embodiments of the invention. However, new status codes can be introduced in modified versions of 3GPP TS23.140 and some of them may be specific to recipients. After the step of determining status, in a step 312 the message can be forwarded by the recipient MMS relay / server to those recipients for whom transmission is possible according to standardized techniques. The relay / destination MMS server or recipient 106b processes the transmission of the MMS message to each of the recipients a, b, c, d, e individually. This is represented graphically in Figure 2 by the respective signals 206a to 206e. These signals 206a to 206e illustrate the processing of the MMSs individually in the relay / recipient MMS server 106b. However, as shown in Figure 2 the messages are not necessarily delivered successfully to all recipients. It is worth mentioning that the transmission of these messages to the individual recipients according to a given status is known in the art. The invention does not propose any adaptation to the messages transmitted at the interface provided by the reference point MMl. However, it is contemplated that the invention will support any modifications to the interface provided by the MMl reference point, and the creation of any new messages in the future. It is worth mentioning that step 312 can occur to transmit the messages at any time after the status of the recipients is determined, and it is not it is necessary to adhere to the order of appearance of step 312 in figure 3. After determination of the status code for each recipient in step 310, in step 314 the recipient MMS relay / server groups the recipients according to the status codes shared. Therefore, the destination MMS relay / server 106b intersperses the status codes for the various recipients. Then all the recipients are grouped according to particular categories. Therefore, for example, each recipient that has an "Ok" status code is grouped together, etc. Then, as represented by step 316, the relay / destination MMS server or recipient 106b transmits multiple confirmation messages back to the creator MMS relay / server, the number of confirmation messages corresponds to the number of status code types identified as associated with the individual recipients. Therefore, if all recipients have an "Ok" status code, for example, a single confirmation can be transmitted back to the relay / MMS server 106a. In the described example, a first confirmation message is transmitted back as signal 210, which identifies the recipients a and d, and indicates that the status it's OK". A second confirmation message is transmitted back, as signal 212, which identifies recipients b and e, and identifies that the transmission status is a transient fault. A third confirmation message is transmitted as the signal 214, which identifies the recipient c and indicates that an invalid address was provided. Each of the confirmation messages is transmitted as a pd message MM4_reenviar.RES at the interface provided by the reference point MM4. The reception of these messages by the relay / server MMS creator is denoted by step 318. The relay / MMS server 106a, in step 320, then determines any other action that is to be taken in response to the confirmation message (s) received from the relay. / MMS recipient server. The creator MMS relay / server analyzes these confirmation messages in this way. For example, when a confirmation message indicates that the transmission has failed due to a fault or transient error, the MMS relay / server 106a preferably forwards the MMS to the destination MMS relay / server 106b, and identifies the recipients associated with the failure. transient With reference to table 2 above, in the case of a status code "Error - unspecified delivery address", it is useless to attempt retransmission. In the case of a status code "Error - content not accepted", the MMS relay / server Creator can perform content adaptation to reduce the PDU content so that it complies with the OMA Conformance Specification which defines the message content that all user agents must support and then attempt to retransmit. In the case of an "Error - network problem" status code, a retransmission without PDP adaptation can be attempted after an appropriate interval (the interval is typically an attribute that can be configured from the relay / MMS server creator). In the example shown in FIG. 2, a signal 216 is transmitted to the relay / destination MMS server 106b, which identifies the recipients b and e. With reference to the flow chart of Figure 3, after analyzing the received confirmations of the relay / recipient MMS server, the creator MMS relay / server determines in a step 322 whether any retransmission is appropriate. If not, the activity in the reference point interface MM4 ends in step 324. If the retransmissions are appropriate, then in step 326 the creator MMS relay / server creates and sends a new MMS request message to the recipients associated with it. the relay to the MMS relay / server recipient. Steps 306 to 320 are then repeated. The destination MMS relay / server 106b processes the transmission of the message to each of the recipients again b and e. This is represented graphically in Figure 2 by means of the signals 218b and 218e. On this occasion, the destination MMS relay / server 106b determines an "Ok" status code for the recipients b and e. This is denoted, graphically, by the transmission of signals 220b and 22Oe. Another confirmation message as denoted by the signal 222 is returned to the relay / MMS server 106a which identifies the recipients b and e and indicates that the status is "ok". It is worth mentioning that in a system architecture MMS there is a known separate delivery report concept that is controlled by the creator MMS user agent. The creator MMS user agent can request in a MMS message a delivery report which is delivered to the MMS user agent after a successful delivery of the MMS. This MMS delivery report feature does not use the confirmation mechanism described above and is outside the scope of the invention. However, the principles described above can be used in other communication systems to provide a message creator with a status indication (confirmation) of a message addressed to multiple recipients. The relay / MMS server, when functioning as the creator MMS, requires a bit of adaptation in order to handle relaying messages to recipients individual However, retransmission of messages after a transient failure is a typical feature of relays / MMS servers. The only additional functionality needed to support the described invention is to determine which recipients of a MM4_web. REQ have a transient fault associated with them, and retransmit only to this series of recipients. The invention favorably allows the creator MMS relay / server to identify the specific recipients to which a message is delivered or not. "delivered As the creator MMS controller is responsible for registering a user who sent a message, it is favorable for the creator MMS controller to know the status of a transmitted message, and to have control over making a decision as to whether the messages should The invention has been described in the context of an MMS environment, however, the invention is not limited to such an environment and can be applied more generally The invention applies to any architecture or network in which an The message is sent to a plurality of recipients and in which a confirmation can be returned which identifies at least one of said recipients and a status associated with a delivery of the message to that recipient In the MMS mode described above, a plurality of response messages it can be sent to the creator MMS relay / server, which corresponds to a plurality of status codes. However, alternative techniques can be provided to provide associated status codes and recipients. For example, as an alternative solution to minimize the amount of messages transferred between two relays / MMS servers, a reply message (eg, message from MMU_Perfect .RES) can identify various status codes and an information element of separate recipient for each status indication. In another alternative it may be possible to list the .de codes. status (errors) and recipients in message MM4_realviar .RES, so that the status of the same number in the list applies to the recipient with the same number in the corresponding list. However, this approach is not ideal, since it can cause a compatibility problem with previous versions. In addition, it may be possible to provide two new headers (do not use the existing "request status" header): one for the recipient list and the other for the list of status values. In some communication systems the delivery of messages or the determination of whether the message can be delivered to all recipients may take a relatively long time due to some reasons in the network or on the side of the recipients (for example, problems of communication). network, terminal out of coverage, the recipient's mailbox is full). In this case a partial response can be sent with the corresponding status indication to those recipients with whom the message delivery was successful or an error occurred immediately. A final answer for the rest of the recipients can be sent later when the final status of each individual delivery is known. In addition, in some communication systems a message or confirmation messages may be delivered, not only between main network elements, but also to the actual end user who created the message to the multiple recipients. In particular, if the creating terminal is a mobile device, it is more efficient to transfer only a collective confirmation at the low bandwidth air interface. The confirmation message may be shown to a user as a normal received message or alternatively it may be used as a delivery report to provide a user with an indication of the status of the message sent by indicating the status of the delivery by each recipient or by several recipients. Another exemplary implementation of the technique of the present invention is in the context of session initiation protocol (SIP) messaging or instant messaging (IM). In SIP there is an active work element in the IETF (Internet Engineering Special Group, www.ietf.org) regarding the so-called SIP Deployer concept. An example of a SIP deployer message is a request sent from a single user .-. A, for example, a server. The message is then transmitted in, immediately or at the given time, from the server to a plurality of other users. In accordance with the principles of the invention as described above, each of the messages sent to the plurality of users can return., U. confirmation message to the server and in this way the server can return to the creator user a message transmission status for each user or users. It is also possible to derive a status indication for a recipient of other signals or error messages received from the network. In addition, in case no response of any kind from the network or the user is received, the delivery status for that recipient can be set as unknown, for example, after a certain time. The invention has been described in the context of a particular and non-limiting example, as specifically in the context of an MMS environment and communication between MMS environments. The person skilled in the art will understand that the invention is not limited to such an environment and may have a use that can be applied more in general. The scope of the invention is defined by the appended claims.

It is noted that in relation to this date, the best method known to the applicant to carry out the aforementioned invention, is that which is clear from the present description of the invention.

Claims (26)

1. CLAIMS Having described the invention as above, the content of the following claims is claimed as property: 1. A method for transmitting a message to multiple recipients, characterized in that it comprises: receiving a message addressed to multiple "recipients; determining an indication of a status of each recipient, and transmit a confirmation, the confirmation includes at least one message identifying at least one recipient and the associated state of the recipient or recipients 2. The method according to claim 1, characterized in that the determination of a indication of a state of each recipient comprises determining whether the message can be transmitted to each addressee 3. The method according to claim 1, characterized in that the determination of an indication of a state of each recipient comprises examining user profile data. of the recipients 4. The method of conformity with the claim 1, characterized in that the state of each recipient indicates a status of transmission of the message to that recipient. 5. The method according to any of the preceding claims, characterized in that the step of receiving a message addressed to multiple recipients includes receive a request to transmit the message to multiple recipients. 6. The method according to any of the preceding claims, characterized in that the confirmation includes a plurality of messages where each identifies at least one recipient, and each includes one of a plurality of corresponding states. The method according to any of the preceding claims, characterized in that the confirmation includes at least one message identifying a plurality of recipients' series and a corresponding plurality of states where each state is associated with a series of recipients. 8. The method according to claim 7, characterized in that each series contains one or more recipients. The method according to any of the preceding claims, characterized in that the state indicates one of the following: an invalid recipient address; an incomplete transmission; content of the message not accepted; or a successful transmission. The method according to claim 7, characterized in that it further comprises the step of, in response to a reception of a confirmation message indicating an incomplete transmission, retransmitting the message to the recipient or recipients identified in the confirmation message. The method according to any of the preceding claims, characterized in that the message or messages identifying at least one recipient and a state of the transmission to the recipient or recipients identify a plurality of recipients, such status is common to all recipients identified. The method according to any of the preceding claims, characterized in that it further comprises the step of receiving a request to transmit the message from a creator of the message and transmitting the confirmation to the creator of the message. The method according to claim 12, characterized in that the creator of the message has a mailbox and the confirmation is transmitted to the mailbox. The method according to claim 12, characterized in that the confirmation provides the creator of the message with a delivery status for a plurality of recipients. The method according to any of the preceding claims, characterized in that at least one message is transmitted through the use of the session initiation protocol. 16. The method according to any of the preceding claims, characterized in that the message is a multimedia services message. 17. A method for transmitting a multimedia message to multiple recipients, characterized in that it comprises: receiving in a creative media services element a request to transmit the message to multiple recipients in a different multimedia services environment; transmitting the multimedia message from the creative multimedia services element to a multimedia services element addressed to the different multimedia services environment, including an identity of the recipients; determine the status of each recipient in the recipient multimedia services element; and transmitting a confirmation of the multimedia service element recipient to the creator multimedia services element, the confirmation includes at least one message identifying at least one recipient and a status of the recipient. 18. The method of compliance with the claim 17, characterized in that it further comprises, in response to a confirmation message indicating an incomplete transmission status, retransmitting the multimedia message of the creative media services element to a multimedia services element addressed to the multimedia services environment differently, the retransmitted message identifies the recipients associated with the incomplete transmission status. 19. A message format of protocol data units MM4_realviar .RES in accordance with 3GPP TS23.140, characterized in that it includes an information element that identifies at least one recipient, the status in the message applies to the recipient or recipients. 20. The message format of MM4 protocol data units. RES according to claim 19, characterized in that the information element identifies a plurality of recipients, the status in the message applies to the plurality of recipients. 21. A network element characterized in that it includes means for receiving a message addressed to multiple recipients; means for determining an indication of a state of each recipient; and means for transmitting a confirmation, the confirmation includes at least one message identifying at least one recipient and the associated state of the recipient or recipients. 22. The network element according to claim 21, characterized in that the means for transmitting a confirmation are adapted to transmit a plurality of messages identifying at least one recipient, each of the plurality of messages includes one of a plurality of corresponding states. 23. A network element characterized in that it includes means for receiving a message addressed to multiple recipients; means for forwarding such a message with an identity of multiple recipients; and means for receiving a confirmation message including at least one message identifying at least one recipient and the associated state of the recipient or recipients. 24. The network element according to claim 23, characterized in that it further includes means for resending such a message identifying those recipients associated with a state corresponding to a transmission failure. 25. In a multimedia messaging system, a creative multimedia services element characterized in that it has means for receiving a request to transmit a message to multiple recipients in a different multimedia services environment; and means for transmitting the multimedia message from the creative multimedia services element to a multimedia services element addressed to the different multimedia services environment; and the recipient multimedia services element includes means for determining the status of each recipient; and means for transmitting a confirmation of the multimedia service element recipient to the creator multimedia services element, the confirmation includes at least one message identifying at least one recipient and a status of the recipient. 26. The multimedia messaging system according to claim 23, characterized in that the multimedia service elements comprise relays, servers or relays / multimedia service servers.