IMS users shall be able to exchange immediate messages with each other by using the procedure described in this clause. This procedure shall allow the exchange of any type of multimedia content (subject to possible restrictions based on operator policy and user preferences/intent), for example but not limited to:
-
Pictures, video clips, sound clips with a format defined in the respective access specific annex.
If the message size exceeds the size limit for MESSAGE requests, the UE shall use alternative means to deliver the content of the Immediate Message. Session based messaging specified in
clause 5.16.2 provides such means.
RFC 3428 presents guidelines for the selection of transport mechanism for an Immediate Message. The message size limitations described above are meant to be applicable for Immediate Messages sent over end-to-end congestion safe transport, i.e. are not necessarily equal to the limitations specified for MESSAGE over congestion-unsafe transport by
RFC 3428.
If the size limit for a terminating MESSAGE request is exceeded, the network may refuse the request or respond to the sender with an indication that the size of the message is too large.
The sender UE can include an indication in the message regarding the length of time the message will be considered valid.
Step 1.
UE#1 generates the multimedia content intended to be sent to UE#2.
Step 2.
UE#1 sends the MESSAGE request to P-CSCF#1 that includes the multimedia content in the message body.
Step 3.
P-CSCF#1 forwards the MESSAGE request to S-CSCF#1 along the path determined upon UE#1's most recent registration procedure. Before forwarding, if P-CSCF#1 has received the MPS for Messaging indication for the UE as set (enabled), P-CSCF#1 sets the Resource-Priority information in the MESSAGE to a value appropriate for MPS.
Step 4.
Based on operator policy S-CSCF#1 may reject the MESSAGE request with an appropriate response, e.g. if content length or content type of the MESSAGE are not acceptable. S-CSCF#1 invokes whatever service control logic is appropriate for this MESSAGE request. This may include routing the MESSAGE request to an Application Server, which processes the request further on.
Step 5.
S-CSC#1 forwards the MESSAGE request to I-CSCF#2.
Step 6.
I-CSCF#2 performs Location Query procedure with the HSS to acquire the S-CSCF address of the destination user (S-CSCF#2).
Step 7.
I-CSCF#2 forwards the MESSAGE request to S-CSCF#2.
Step 8.
Based on operator policy S-CSCF#2 may reject the MESSAGE request with an appropriate response, e.g. if content length or content type of the MESSAGE are not acceptable. S-CSCF#2 invokes whatever service control logic is appropriate for this MESSAGE request. This may include routing the MESSAGE request to an Application Server, which processes the request further on.
For example, the UE#2 may have a service activated that blocks the delivery of incoming messages that fulfil criteria set by the user. The AS may then respond to the MESSAGE request with an appropriate error response.
Step 9.
S-CSCF#2 forwards the MESSAGE request to P-CSCF#2 along the path determined upon UE#2's most recent registration procedure.
Step 10.
P-CSCF#2 forwards the MESSAGE request to UE#2. After receiving the MESSAGE UE#2 renders the multimedia content to the user.
Step 11-16.
UE#2 acknowledges the MESSAGE request with a response that indicates that the destination entity has received the MESSAGE request. The response traverses the transaction path back to UE#1.
Step 1-5.
The same actions apply as for when the Public User Identity is registered, see step 1-5 in
clause 5.16.1.1.1.
Step 6.
I-CSCF#2 interacts with the HSS as per the terminating procedures defined for unregistered Public User Identities in
clause 5.12.1. If the Public User Identity has no services related to unregistered state activated the interaction with HSS would be as per the procedure defined in
clause 5.12.2.
Step 7.
I-CSCF#2 forwards the MESSAGE request to S-CSCF#2.
Step 8.
Based on operator policy S-CSCF#2 may reject the MESSAGE request with an appropriate response, e.g. if content length or content type of the MESSAGE are not acceptable or the UE#2 does not have a service activated that temporarily hold the MESSAGE request in the network.
S-CSCF#2 invokes whatever service control logic appropriate for this MESSAGE request. This may include routing the MESSAGE request to an Application Server, which processes the request further on.
For example, the UE#2 may have a service activated that allows delivery of any pending MESSAGE request. The AS may then hold the MESSAGE request and deliver the MESSAGE request when the UE#2 becomes reachable. In this case, depending on user settings UE#2 controls the delivery of the pending MESSAGEs.
Step 9-12.
The MESSAGE request is acknowledged with an appropriate acknowledgement response. The acknowledgement response traverses the transaction path back to UE#1.