Session-based IMS messaging communications shall as much as possible use the same basic IMS session delivery mechanisms (e.g. routing, security, service control) as defined in clause 4 and 5 of this document. For session based messaging the session shall include a messaging media component, other media components may also be included.
As the messaging media component usually does not require QoS beyond best-effort, use of the preconditions mechanism as defined in RFC 3312 is not required for session based messaging establishment that only includes a messaging media component.
Once the session containing a messaging media component is established, messages in the session are transported between the session participants as per the parameters defined in the messaging media component part of the session description (SDP).
The invited UE shall host the message session (accept a connection for the message session from the other endpoint). In order to host the message session the UE needs an appropriate IP-CAN bearer, on which it can accept the connection for the message media component. This IP-CAN bearer may be e.g. a general purpose bearer available prior to starting the session initiation or a dedicated bearer that is established during session establishment. Messages within a message session should be transported over a connection-oriented reliable transport protocol. Message sessions may be either established end to end between two UEs or may involve one or more intermediate nodes (e.g. a chat server for multi party chat or an Application Server to perform per message charging).
For addressing chat-group-type session based messaging the concept of Public Service Identities is used.
Session based messaging is available for users that are registered in the IMS.
The session based messaging shall be able to provide the following functionality:
Per-message-based charging, as well as content- and size-based charging.
Operator-controlled policy to be set on the size and content of the messages.
Support for indication of maximum message content size that a UA will accept to be received.
Support for a messaging media component as part of a session where other media components are also included.
Support for messaging-only sessions.
If charging mechanisms like charging based on the message content, message type or number of sent and/or received messages (see TS 22.340) are required, then an intermediate node (messaging AS) shall be involved, which is able to inspect the SIP signalling as well as the exchanged messages and their content. Such an intermediate node may also provide support for time- and/or volume based charging.
IMS users shall be able to exchange session-based messages with each other by using the procedures described in this clause. These procedures 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 documents.
The following procedure shows the establishment of a message session between two registered UEs where the UEs are able to exchange messages end-to-end. The signalling flow is based on the general flow shown in clause 5.7a of this specification.
These steps are identical to the steps 1 to 30 in the flow of clause 5.7a. After that the message session is established. For session based messaging the SDP offer in the first INVITE request may indicate the maximum message size UE#1 accepts to receive and the 200 OK (Offer response) to the INVITE request may indicate the maximum message size UE#2 accepts to receive.
UE#2 acknowledges the message with a response that indicates that UE#2 has received the message. The response traverses back to UE#1. After receiving the message UE#2 renders the multimedia content to the user.
Further messages may be exchanged in either direction between UE#1 and UE#2 using the established connection. The size of the messages exchanged within the session shall be within the size limits indicated by UE#1 and UE#2 respectively.
Session based messaging between more than two UEs require the establishment of a session based messaging conference.
Within session based messaging conferences including multiple UEs (e.g. multiparty chat conferences) an MRFC/MRFP or an IMS AS shall be used to control the media resources.
When MRFC/MRFP are used, then conferencing principles are used to provide the chat service:
MRFP must be able to establish message connections with all involved parties.
MRFC/MRFP must be able to receive messages from conference participants and to distribute messages to all or some of the participants.
In order to enable the UE managing information related to the session based messaging conference the MRFC may be co-located with an IMS AS.
The interface for session based messaging between MRFC and MRFP is not standardised in this release. When an AS is used, then the IMS service control architecture is used to provide the chat service. Both signalling and user plane are then supported by the AS. For more details, see clause 4.2.
The following flow shows the originating session based messaging set up using an intermediate server for a chat service. In this case the intermediate chat server is addressed by the UE#1 using a PSI. It is assumed that UE#1 is the first UE entering the chat session.
UE #1 sends the SIP INVITE request addressed to a conferencing or chat PSI to the P-CSCF. The SDP offer indicates that UE#1 wants to establish a message session and contains all necessary information to do that. The SDP offer may indicate the maximum message size UE#1 accepts to receive.
Another UE (UE#2) sends an INVITE request addressed to the same conferencing or chat PSI. The initial SDP indicates that the UE wants to establish a message session and contains all necessary information to do that.
Further INVITE requests from new possible participants may arrive at any time.
Further messages may be exchanged in either direction between the participating UEs using the established connection via the MRFC/MRFP or AS. The size of the messages exchanged within the session shall be within the size limits indicated by UE#1 and the host of the PSI respectively.
The following procedure shows the originating session based messaging involving an intermediate node. An optional ringing response from AS to the UE or vice versa is not shown in the following procedure.
Based on operator policy the S-CSCF may reject the INVITE request with an appropriate response. S-CSCF may invoke whatever service control logic is appropriate for this INVITE request. In this case the Filter Criteria trigger the INVITE request to be routed to an Application Server that acts as an intermediate node for the message session.
The S-CSCF forwards the INVITE request to the AS. The AS may modify the content of the SDP (such as IP address/port numbers). Based on operator policy the AS may either reject the session set-up or decrease the maximum message size indication.
UE#2 or AS in the terminating network accepts the INVITE request with a 200 OK response. The 200 OK response is forwarded by the S-CSCF to the AS. The 200 OK (Offer response) may indicate the maximum message size UE#2 accepts to receive, possibly decreased by the AS.
The AS forwards the message response back to UE#1.
Further messages may be exchanged in either direction between UE#1 and the terminating network using the established message connection via the AS. The size of the messages exchanged within the session shall be within the size limits indicated by UE#1 and UE#2 respectively, possibly decreased by the AS.
UE#1 indicates its intent to terminate the message session by sending a BYE request to UE#2. UE#1 stops sending messages and tears down the message connection on the transport level and destroy local state for the message session. The UE#1 may use the IP-CAN bearer for some other services; hence it keeps the bearer activated.
UE#2 agrees to end the session and tear down the message connection on the transport level and destroy local state for the message session. The UE#2 may use the IP-CAN bearer for some other services; hence it keeps the bearer activated.
UE#1 indicates its intent to terminate the message session by sending a BYE request to UE#2, via the AS. UE#1 stops sending messages and tears down the message connection on the transport level and destroy local state for the message session. The UE#1 may use the IP-CAN bearer for some other services; hence it keeps the bearer activated.
The AS tears down the message connection on the transport level and destroys local state for the message session. The AS acknowledges the BYE request by sending a 200 OK to UE#1, which traverses back the signalling path
The active sessions in stateful network elements (e.g. CSCFs, ASs) may need to be refreshed periodically. This allows these stateful elements to detect and free resources that are being used by hanging sessions.
This SIP-level session refreshing mechanism is to be used to allow removing session state from the stateful elements of the session path upon unexpected error situations (e.g. loss of radio coverage, crash of application in the UE, etc…). The refreshing period is typically in the range of several tens of minutes / hours. The mechanism is intended as a complementary mechanism for the "Network initiated session release" described in clause 5.10.3. Whether the session refresh mechanism is used for a particular session is negotiated between the endpoints of the session upon session initiation.
IMS entities acting as User Agents as defined in RFC 3261 should support the refresh mechanism of SIP sessions. This includes support for the negotiation of the session refresh details upon session initiation, and the initiation of session refresh requests.