Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.333  Word version:  17.1.0

Top   Top   Up   Prev   Next
1…   4   5…   5.8…   5.12…   5.14…   5.20…   5.24…   6…   6.1.8…   6.2…   6.2.3…   6.2.4…   6.2.5   6.2.6…   6.2.7…   6.2.8…   6.2.9…   6.2.10…   6.2.10.2.7   6.2.10.3…   6.2.11…   6.2.13…   6.2.13.2.6…   6.2.14…   6.2.15…   6.2.16…   6.2.18…   6.2.19…   6.2.19.3…   6.2.20…   6.2.21…   6.2.22…   6.2.23   6.2.24…   7   8…   8.11…   8.20   8.21   8.22   8.23…   8.30…   8.39…   8.45…   8.56…

 

6.2.10.3  Message Conferencing |R8|p. 101

The procedures specified in clauses 6.2.10.1 - 6.2.10.6 for "General Multimedia Conferencing" shall be followed. The following clauses describe the additional requirements for the message conferencing.
6.2.10.3.1  Generalp. 101
For message conferencing, the Message Session Relay Protocol (MSRP) (see RFC 4975) shall be used to transport messages. The message content may carry different media including text, image, video and audio. The Media types shall be MIME encoded. The TCP connection that the MSRP runs over shall be established when adding a new participant into the conference according to clause 6.2.20.
In order to manage the message conferencing, the following features may be supported:
  • Message statistics.
  • Message filtering.
An MRFC and an MRFP that support a session based messaging, as defined in RFC 4975, shall support the following procedures.
When receiving an SDP offer for a MSRP media, the MRFC:
  • shall provide the value of the received "a=path" SDP attribute (defined in RFC 4975) to the MRFP in the "MSRP URI Path" information element, as part of a remote descriptor;
  • shall indicate "TCP/MSRP" or "TCP/TLS/MSRP" (if e2e media security is applied) as transport protocol to the MRFP;
  • if the "a=msrp-cema" SDP attribute, as defined in RFC 6714, is not contained in the SDP offer, should use the IP address and port within the first entry of the "a=path" SDP attribute from the received SDP offer to configure the remote IP address and port at the MRFP;
  • shall request the MRFP to allocate the IP address, TCP port and MSRP session-id and provide this information in the "MSRP URI Path" information element;
  • shall include the "a=path" SDP attribute received from the MRFP in an SDP answer it sends; and
  • if the SDP offer included the "a=msrp-cema" SDP attribute, shall include the "a=msrp-cema" SDP attribute in the SDP answer.
When sending an SDP offer for MSRP media, the MRFC:
  • shall request the MRFP to allocate an IP address, TCP port and MSRP session-id and provide this information in the "MSRP URI Path" information element;
  • shall indicate "TCP/MSRP" or "TCP/TLS/MSRP" (if e2e media security is applied) as transport protocol to the MRFP;
  • shall include the value of the "MSRP URI Path" information element received from the MRFP in the "a=path" SDP attribute of the SDP offer it sends; and
  • should include the "a=msrp-cema" SDP attribute in the SDP offer.
When receiving a corresponding SDP answer for MSRP media, the MRFC:
  • shall provide the value of the received "a=path" SDP attribute to the MRFP in the "MSRP URI Path" information element; and
  • if the "a=msrp-cema" SDP attribute is not contained in the SDP answer, should use the IP address and TCP port within the first entry of the "a=path" SDP attribute from the received SDP answer to configure the remote IP address and port at the MRFP.
When the MRFP is configured to handle MSRP media and is requested to allocate an IP address, TCP port and MSRP session-id, it shall provide this information in the "a=path" SDP attribute and shall store this information. When the MRFP then receives MSRP packets, it shall compare the session-id part of the received MSRP packets with the stored session-id.
The MRFP shall include MSRP URI(s) received in the "MSRP URI Path" information element from the MRFC in the "To-Path" header field of MSRP packets it sends.
Up
6.2.10.3.2  Messages Statisticsp. 102
The MRFP may report the statistics for the number of messages sent and/or received in two ways described as following.
1)
The MRFC indicates quotas granted to the MRFP. The granted quotas indicate the units specifying the number of messages or volume of messages allowed to be received or sent by users. The MRFC may also indicate to the MRFP a valid time together with the granted quotas. The valid time indicates the time until the specific unit may be measured, after which the quota shall be reported, whether or not it has reached its granted quota. The MRFC initiates this via the "Configure Granted Quota" procedure as specified in clause 8.50. The quotas granted by MRFC may include any of the following:
  • Quota for number of messages sent
  • Quota for number of messages received
  • Quota for volume (size) of messages sent
  • Quota for volume (size) of messages received
When the quota granted is reached or the valid time elapses the MRFP shall report statistics information of messages according to the indication by the MRFC. The MRFP uses the "Report Message Statistics" procedure as specified in clause 8.51 to report the statistics of messages. The statstistics of messages sent and/or received may include any of the following:
  • number of messages sent
  • number of messages received
  • volume (size) of messages sent
  • volume (size) of messages received
  • reason for report i.e. quota reached or granted time elapsed
2)
The MRFC requests the MRFP to report the statistics information of messages sent and/or received at the end of the session or during the session. In this case, the quotas or the valid time is not required, and the MRFP should report the statistics of message as requested by the MRFC. The statstistics of messages are the same as described above.
Figure 6.2.10.3.2.1 shows the message sequence chart example for reporting message statistics.
Copy of original 3GPP image for 3GPP TS 23.333, Fig. 6.2.10.3.2.1: Message statistics according to the granted quota
Up
6.2.10.3.3  Message Filteringp. 104
When the MRFC receives the trigger to config the filtering rules, the MRFC may initiate the "Configure Filtering Rules" procedure as specified in clause 8.52 to set filtering rules in the MRFP. The filtering rule is composed of two parts: the criteria and the treatment of the filtered message. The MRFP should handle messages according to the filtering rules.
The MRFC may indicate to the MRFP the following criterias:
  • Sender address
  • Message size
  • Message content type (e.g. video, audio)
  • Message content format(e.g. mpeg, jpeg)
  • Message subject
The MRFC may indicate to the MRFP the following message treatments:
  • Block the delivery of the message content
  • Store the message content
  • Redirect the message to another address
The MRFC may indicate to the MRFP the "store url" when messages storage is needed, or the MRFC may indicate the MRFP to allocate the "store url" and return the generated "store url" to the MRFC.
The MRFC may indicate to the MRFP the "redirect url" when messages redirection is needed.
Figure 6.2.10.3.3.1 shows the message sequence chart example to config the filtering rules.
Copy of original 3GPP image for 3GPP TS 23.333, Fig. 6.2.10.3.3.1: Configure the filtering rules
Figure 6.2.10.3.3.1: Configure the filtering rules
(⇒ copy of original 3GPP image)
Up

Up   Top   ToC