Mobile messaging technologies and services sms ems and mms phần 9 doc

The following sections presenttransaction flows for message forward, delivery report forward and read-reply report forward.6.33.2 Routing Forward a Message The request for forwarding a me

two distinct MMS environments is provided in Section 6.33.5 The following sections presenttransaction flows for message forward, delivery report forward and read-reply report forward.

6.33.2 Routing Forward a Message

The request for forwarding a message (MM4_forward.REQ request) over the MM4 face allows a multimedia message to be transferred between two MMS environments Ifrequested by the originator MMSC, the recipient MMSC acknowledges the forward requestwith a forward response (MM4_forward.RES response) The transaction flow for thetransfer of a message over the MM4 interface is shown in Figure 6.49

inter-The MM4_forward.REQ request is composed of the information elements/parameterslisted in Table 6.40 If requested by the originator MMSC, the recipient MMSC acknowl-edges the forward request with a forward response (MM4_forward.RES response) Theresponse is composed of the information elements/parameters listed in Table 6.41

Unlike forward requests, the addressing of forward responses is related to neither themessage originator nor the message recipient Instead, the addressing of a forward response

is related to special system addresses The value to be assigned to the To parameter is thevalue assigned to the X-MMS-Originator-System parameter of the correspondingforward request (usually a special system address identifying the originator MMSC) Thevalue to be assigned to the Sender parameter is a special address identifying the recipientMMSC It is suggested that special system addresses should be formatted in the form:

system-user@mms-relay-host.operatorX.net

If the forward request has been processed without error by the recipient MMSC, thefollowing value is assigned to the request status code information element (X-Mms-Request-Status-Codeparameter)

† Ok: this status code indicates that the corresponding request has been processed withouterrors

If errors occurred during the processing of the forward request, the codes listed in Table 6.42can be assigned to the request status code information element

6.33.3 Routing Forward a Delivery Report

The request for forwarding a delivery report (MM4_delivery_report.REQ request)over the MM4 interface allows the transfer of a delivery report between two MMS environ-ments If requested by the recipient MMSC, the originator MMSC acknowledges the forwardrequest with a forward response (MM4_delivery_report.RES response) The transac-tion flow for the transfer of a delivery report over the MM4 interface is shown in Figure 6.50.The MM4_delivery_report.REQ request is composed of the information elements/parameters listed in Table 6.43 The MM4_delivery_report.RES response iscomposed of the information elements/parameters listed in Table 6.44

For the forward response, the value to be assigned to the To parameter is the value assigned

to the Sender parameter of the corresponding forward request The value to be assigned tothe Sender parameter is the system address of the recipient MMSC

6.33.4 Routing Forward a Read-reply Report

The request for forwarding a read-reply report (MM4_read_reply_report.REQrequest) over the MM4 interface allows a read-reply report to be transferred between twodistinct MMS environments If requested by the recipient MMSC, the originator MMSCacknowledges the forward request with a forward response (MM4_read_reply_report.RES response) The transaction flow for the transfer of a read-reply report over the MM4interface is shown in Figure 6.51 The MM4_read_reply_report.REQ request iscomposed of the information elements/parameters listed in Table 6.45 The MM4_read_reply_report.RESresponse is composed of the information elements/parameters listed

in Table 6.46

For the response, the value to be assigned to the To parameter is the value assigned to the

the request

authentication or authorizationError-message-format-

due to capacity overloadError-content-not-

accepted

The request was not accepted because of issues with theassociated message size or format, or because ofcopyright issues

Figure 6.50 MM4 delivery report

Sender parameter of the corresponding forward request The value to be assigned to theSenderparameter is the system address of the recipient MMSC.

6.33.5 Example for Message Transfer with SMTP

Figure 6.52 shows the sequence of SMTP instructions required to open an SMTP session,transferring a message and tearing down the session Note that values assigned to From, Toand Cc fields are not used for routing purpose over SMTP These values are transferredtransparently over SMTP Consequently, these values may be formatted as RFC 822addresses or as MSISDN addresses Values, used for routing purpose in SMTP, are thoseassigned to MAIL and RCPT fields

6.33.6 Availability Matrix of PDU Parameters

Table 6.47 indicates the set of parameters composing each request/response for operationsthat can be invoked over the MM4 interface (3GPP releases 4 and 5)

6.34 MM5 Interface MMSC–HLR

The MM5 interface enables interactions between an MMSC and other network entities such

as the HLR Operations that can be invoked over the MM5 interface include:

† Interrogating the HLR to obtain routing information for the purpose of forwarding amessage from one MMSC to another one over the MM4 interface

† Determination of the recipient handset’s location (e.g if the subscriber is roaming)

† etc

If the MM5 interface is present in the MMSE, then it is usually implemented on the basis ofexisting MAP operations At the time of writing, no technical realization of the MM5 inter-face has been specified by standardization organizations

Figure 6.51 MM4 read-reply report

6.35 MM6 Interface MMSC–User Databases

The MM6 interface allows interactions between the MMSC and user databases nately, the MM6 interface has yet to be standardized Consequently, this interface is notcovered in this book

Unfortu-6.36 MM7 Interface MMSC–VAS Applications

The MM7 interface enables interactions between Value Added Service (VAS) applicationsand an MMSC Table 6.48 lists the operations that are available on the MM7 interface At thetime of writing, the only standardized technical realization for the MM7 interface is the onepublished by the 3GPP in [3GPP-23.140] release 5 (stages 2 and 3) This technical realization

is based on the Simple Object Access Protocol (SOAP) with HTTP at the transport layer.Figure 6.53 shows a typical network configuration allowing a VAS application to interactwith several MMS user agents In this configuration, the VAS application and the MMSCplay dual roles of sender and receiver of SOAP messages

Figure 6.52 Example of message transfer over SMTP

As for other interfaces, each operation invoked over the MM7 interface is composed of arequest and a corresponding response HTTP-level mechanisms5 can be used in order toauthenticate parties communicating over the MM7 interface Additionally, messages overthe MM7 interface can be transported over TLS to ensure confidentiality between commu-nicating parties.

Figure 6.53 Network architecture with a VAS application

message

B

VAS application

B

5

For instance, the access authentication mechanism described in [RFC-2617] can be used for authenticating parties communicating over the MM7 interface.

The support of the MM7 interface is optional for the MMSC However, if such an interface

is supported, then message submission, message delivery, operations related to the provision

of delivery reports and the management of errors are mandatory operations to be supported bythe MMSC The support of other operations such as message cancellation, replacement andoperations related to the management of read-reply reports is optional for the MMSC.The two addressing modes, MSISDN [ITU-E.164] and Email address [RFC-2822], can beused to identify entities communicating over the MM7 interface Communicating entitiesinclude MMS user agents, VAS applications and the MMSC

SOAP messages are structured according to SOAP technical specifications published bythe W3C in [W3C-SOAP] and [W3C-SOAP-ATT] In addition, the XML schema for format-ting MMS-specific SOAP messages is published by the 3GPP at the following location: http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0

6.36.1 Introduction to SOAP

SOAP is a lightweight protocol for the exchange of information in distributed environmentssuch as the MMS environment All SOAP messages are represented using XML SOAPspecifications consist of three distinct parts:

† Envelope: this part defines a framework for describing the content of a SOAP message andhow to process it

† Set of encoding rules: encoding rules are used for expressing instances of defined data types

application-† Convention for representing remote procedure calls: this convention helps entities in adistributed environment to request services from each other in an interoperable manner

Figure 6.54 Structure of a SOAP message

SOAP may be used over a variety of transport protocols In the MMS environment, for therealization of the MM7 interface, SOAP is used over the HTTP transport protocol With thisconfiguration, MM7 request messages are transferred in HTTP POST requests whereascorresponding MM7 response messages are transferred as part of HTTP Response messages.

A SOAP message, represented using XML, consists of a SOAP envelope, a SOAP header,

a SOAP body and an optional SOAP attachment as shown in Figure 6.54 For messagescontaining a SOAP envelope only, then the media type text/xml is used If the SOAPmessage also contains an attachment, then the media type multipart/related is usedand the SOAP envelope is identified with the Start field of the content type Each part ofthe SOAP message has, at least, the two fields Content-Type and Content-ID.The SOAP envelope is the first element to appear in HTTP POST requests and correspond-ing responses The SOAPAction parameter is set to the ‘Null string’ The MMSC or theVAS server is identified uniquely with a URI placed in the host header field of the HTTPPOST method

A request status is provided as part of the corresponding response The status can be ofthree types:

† Success or partial success: this status indicates the successful or partial treatment of arequest This status is composed of three information elements identified by parametersStatusCode (numerical code), StatusText (human readable textual description)and Details (optional human readable detailed textual description) The classification

of four-digit error identifiers to be assigned to the StatusCode is provided in Figure6.55

† Processing error: this status indicates that a fault occurred while parsing SOAP elements.Possible errors include faultcode, faultstring and detail elements as defined

Figure 6.55 Classification of MM7 error codes

MMSC accepts the submission request, then the MMSC sends back a positive response Thisindicates that the submission request is accepted but does not indicate that the message hasbeen successfully delivered to the message recipients The transaction flow in Figure 6.56shows interactions between the VAS application and the MMSC for the submission of amultimedia message over the MM7 interface.

In tables describing the content of requests and responses for the MM7 interface, thecolumn named ‘location’ indicates whether the corresponding information element is placed

in the SOAP header (‘H’), SOAP body (‘B’) or SOAP attachment (‘A’)

The submission request MM7_submit.REQ is composed of the information elements/parameters listed in Table 6.49 The MMSC acknowledges the submission request with theMM7_submit.RESresponse This response is composed of the information elements/para-meters listed in Table 6.50

Figure 6.57 shows an example of submission request embedded in an HTTP POST request,whereas Figure 6.58 shows the corresponding response

6.36.3 Message Delivery

In the context of value added services, message delivery refers to the delivery of a multimediamessage from the MMSC to a VAS application The MMSC may deliver the message to theVAS application along with a linked identification This identification can be conveyed aspart of a subsequent message submission from the VAS application to indicate that thesubmitted message is related to a previously delivered message The transaction flow inFigure 6.59 shows interactions between the MMSC and the VAS application for the delivery

of a multimedia message over the MM7 interface

The submission request MM7_deliver.REQ is composed of the information elements/parameters listed in Table 6.51

The VAS application acknowledges the delivery request with the MM7_deliver.RESresponse This response is composed of the information elements/parameters listed in Table6.52

6.36.4 Message Cancellation

In the context of value added services, message cancellation refers to the possibility for a

Figure 6.56 MM7 message submission

VAS application to cancel a previously submitted multimedia message prior to its delivery.Upon receipt of such a cancellation request, the MMSC cancels the delivery of the associatedmessage to all message recipients to which the associated notification has not yet been sentout The transaction flow in Figure 6.60 shows interactions between the MMSC and the VASapplication for the cancellation of a previously submitted multimedia message over the MM7interface.

The cancellation request MM7_cancel.REQ is composed of the information elements/parameters shown in Table 6.53 The MMSC acknowledges the cancellation request with theMM7_cancel.RESresponse This response is composed of the information elements/para-meters listed in Table 6.54

6.36.5 Message Replacement

In the context of value added services, message replacement refers to the possibility for aVAS application to replace a previously submitted multimedia message prior to its delivery.Upon receipt of such a replacement request, the MMSC replaces the previously submittedmessage with the new message specified as part of the replacement request Only messagesthat have not yet been retrieved or forwarded can be replaced The replacement requestcontains a number of information elements that overwrite the ones associated with thepreviously submitted message If an information element was associated with the previouslysubmitted message but is not provided as part of the replacement request, then this informa-tion element is retained for the new message The transaction flow in Figure 6.61 shows

messageTransaction

identification

submission transaction

TransactionIDMessage

type

(message submission

MessageTypeValue: SubmitRsp

identification

MessageIDRequest

status

completion

StatusCodeRequest

status text

status of the requestcompletion

StatusText

Request

status details

textual description of thecorresponding request status

Details

a

Condition: available only if the MMSC accepts the corresponding forward request

Figure 6.57 Example of message submission request over the MM7 interface

interactions between the MMSC and the VAS application for the replacement of a previouslysubmitted multimedia message over the MM7 interface.

The replacement request MM7_replace.REQ is composed of the information elements/parameters listed in Table 6.55 The MMSC acknowledges the replacement request with theMM7_replace.RES response This response is composed of the information elements/parameters listed in Table 6.56

6.36.6 Delivery Report

In the context of value added services, a VAS application has the ability to request, as part of

a message submission request, the generation of a delivery report If allowed by the messagerecipient, the MMSC generates a delivery report upon message retrieval, forwarding, dele-tion, rejection, etc Note that if the message was submitted to multiple recipients, then severaldelivery reports may be received by the originator VAS application The transaction flow in

Figure 6.58 Example of message submission response over the MM7 interface

Figure 6.59 MM7 message delivery