11 Quality of Experience

26.2343GPPProtocols and codecsRelease 17Transparent end-to-end Packet-switched Streaming Service (PSS)TS

11.1 General

The PSS Quality of Experience (QoE) metrics feature is optional for both PSS servers and clients, and shall not disturb the PSS service. A PSS server that supports the QoE metrics feature shall signal the activation and gathering of client QoE metrics when desired. QoE metrics can also be activated by a default setting via OMA-DM. A 3GPP PSS client supporting the feature shall perform the quality measurements in accordance to the measurement definitions, aggregate them into client QoE metrics and report the metrics to a server, which may or may not be the PSS server. The way the QoE metrics are processed and made available is out of the scope of this specification.

11.2 QoE metrics

11.2.0 General

The following metrics shall be derived by the PSS client implementing QoE. All the metrics defined below are only applicable to at least one of audio, video, speech and timed text media types, and are not applicable to other media types such as synthetic audio, still images, bitmap graphics, vector graphics, and text. Any unknown metrics shall be ignored by the client and not included in any QoE report. Among the QoE metrics, corruption duration, successive loss of RTP packets, frame-rate deviation and jitter duration are of media level, whereas content switch time, initial buffering duration and rebuffering duration are of session level.

The measurement period for the metrics is the period over which a set of metrics is calculated. The maximum value of the measurement period is negotiated via the QoE protocol as in clause 11.3. The measurement period shall not include any voluntary event that impacts the actual play, such as pause or rewind, or any buffering or freezes/gaps caused by them.

In the case of guaranteed delivery transports, such as HTTP as used in progressive download or HTTP-based streaming, metrics relating to loss or corruption (such as "Corruption duration", "Successive loss of RTP packets" and "Jitter duration") are not relevant and should be omitted from the report or report that no corruption has occurred.

11.2.1 Corruption duration metric

11.2.1.1 Default reporting format

Corruption duration, M, is the time period from the NPT time of the last good frame before the corruption (since the NPT time for the first corrupted frame cannot always be determined) or the start of the measurement period (whichever is later), to the NPT time of the first subsequent good frame or the end of the measurement period (whichever is sooner). A corrupted frame is either an entirely lost frame, or a media frame that has quality degradation and the decoded frame is not the same as in error-free decoding. A good frame is a "completely received" frame X that

– either is a refresh frame (does not reference any previously decoded frames and where none of the subsequently decoded frames reference any frames decoded prior to X);

– or only references previously decoded "good frames".

"Completely received" means that all the bits are received and no bit error has occurred.

Corruption duration, M, in milliseconds can be calculated according to the derivation of good frames as below:

a) A good frame can be derived by the client using the codec layer, in which case the codec layer signals the decoding of a good frame to the client. A good frame could also be derived by error tracking methods, but decoding quality evaluation methods shall not be used. An error tracking method may derive that a frame is a good frame even when it references previously decoded corrupted frames, as long as all the referenced pixels for generating the prediction signal were correctly reconstructed when decoding the reference frames. A decoding quality evaluation method may derive that a frame is a good frame even one or more pixels of the frame have not been correctly reconstructed, as long as the decoding quality is considered by the method as acceptable. Such a frame is not a good frame according to the definition above, which shall be strictly followed.

b) In the absence of information from the codec layer, a good frame is derived according to N, where N is optionally signalled from server to client and represents the maximum duration, in presentation time, between two subsequent refresh frames in milliseconds. After a corrupted frame, if all subsequent frames within N milliseconds in presentation time have been completely received, then the next frame is a good frame. If N is not signalled, then it defaults to infinity (for video) or to one frame duration (for audio).

The optional parameter D is defined to indicate which of options a) and b) is in use. D is signalled from the client to the server. When D is equal to "a", option a) shall be in use, and the optional parameter T shall be present. When D is equal to "b", option b) shall be in use and the optional parameter T shall not be present.

The optional parameter N as defined in point b is used with the "Corruption_Duration" parameter in the "3GPP-QoE-Metrics" header. The optional parameter T is defined to indicate whether the client uses error tracking (when T is equal to "On") or not (when T is equal to "Off"). T is signalled from the client to the server.

The syntax for D, N and T to be included in the "Measure-Spec" (clause 5.3.2.3.1) is as follows:

D = "D" "=" "a" / "b"

N = "N" "=" 1*DIGIT

T = "T" "=" "On" / "Off"

The syntax for the "Metrics-Name Corruption_Duration" for the QoE-Feedback header is as defined in clause 5.3.2.3.2

The absence of an event is reported using the space (SP).

For the "Metrics-Name Corruption_Duration", the "Value" field in 5.3.2.3.2 indicates the corruption duration. The unit of this metric is expressed in milliseconds. There is the possibility that corruption occurs more than once during a measurement period. In that case the value can occur more than once indicating the number of corruption events.

The value of "Timestamp" is equal to the NPT time of the last good frame inside the measurement period, in playback order, before the occurrence of the corruption, relative to the starting time of the measurement period. If there is no good frame inside the measurement period and before the corruption, the timestamp is set to the starting time of the measurement period.

11.2.1.2 XML reporting format

The semantics for calculating corruption duration and corresponding parameters are specified in section 11.2.1.1.

All the occurred corruption durations within each resolution period are summed and stored in the vector TotalCorruptionDuration. The unit of this metric is expressed in milliseconds. Within each resolution period the number of individual corruption events are summed up and stored in the vector NumberOfCorruptionEvents. These two vectors are then reported by the PSS client as Metric-Name "TotalCorruptionDuration" and "NumberOfCorruptionEvents" respectively. The use of error tracking is reported by setting the parameter t to "True" or "False". The method of corruption duration calculation, a or b, is signalled in the parameter d with the values "a" and "b" respectively.

11.2.2 Rebuffering duration metric

11.2.2.1 Default reporting format

Rebuffering is defined as any stall in playback time due to any involuntary event at the client side.

The syntax for the "Metrics-Name Rebuffering_Duration" for the QoE-Feedback header is as defined in clause 5.3.2.3.2.

The absence of an event is reported using the space (SP).

For the "Metrics-Name Rebuffering_Duration", the "Value" field in 5.3.2.3.2 indicates the rebuffering duration. The unit of this metrics is expressed in seconds, and can be a fractional value. There is the possibility that rebuffering occurs more than once during a measurement period. In that case the metrics value can occur more than once indicating the number of rebuffering events.

The optional "Timestamp" indicates the time when the rebuffering has occurred since the beginning of the measurement period. The value of the "Timestamp" is equal to the NPT time of the last played frame inside the measurement period and before the occurrence of the rebuffering. If there is no played frame inside the measurement period, the timestamp is set to the starting time of the measurement period.

11.2.2.2 XML reporting format

The semantics for calculating rebuffering duration are specified in section 11.2.2.1.

All the occurred rebuffering durations are summed up over each resolution period of the stream and stored in the vector TotalRebufferingDuration. The unit of this metrics is expressed in seconds, and can be a fractional value. The number of individual rebuffering events for each resolution period are summed up and stored in the vector NumberOfRebufferingEvents. These two vectors are then reported by the PSS client as Metric-Name "TotalRebufferingDuration" and "NumberOfRebufferingEvents" respectively.

11.2.3 Initial buffering duration metric

11.2.3.1 Default reporting format

Initial buffering duration is the time from receiving the first media packet until playing starts.

The syntax for the "Metrics-Name Initial_Buffering_Duration" for the QoE-Feedback header is as defined in clause 5.3.2.3.2 with the exception that "Timestamp" in "Measure" is undefined for this metric. If the measurement period is shorter than the "Initial_Buffering_Duration" then the client should send this parameter for each measurement period as long as it observes it. The "Value" field indicates the initial buffering duration occurring during the current measurement period, where the unit of this metrics is expressed in seconds, and can be a fractional value. There can be only one "Measure" and it can only take one "Value". The absence of an event can be reported using the space (SP). "Initial_Buffering_Duration" is a session level parameter.

For instance, if the measurement period is set to one second, and the total initial buffering duration is 2.4 seconds, then the three first initial buffering duration values reported will be 1 second, 1 second and 0.4 seconds.

11.2.3.2 XML reporting format

The XML reporting format is identical to the default reporting format.

11.2.4 Successive loss of RTP packets

11.2.4.1 Default reporting format

This parameter indicates the number of RTP packets lost in succession per media channel.

The syntax for the "Metrics-Name Successive_Loss" for the QoE-Feedback header is as defined in clause 5.3.2.3.2.

The absence of an event can be reported using the space (SP).

For the "Metrics-Name Successive_Loss", the "Value" field indicates the number of RTP packets lost in succession. The unit of this metric is expressed as an integer equal to or larger than 1. There is the possibility that successive loss occurs more than once during a measurement period. In that case the metrics value can occur more than once indicating the number of successive losses.

The optional "Timestamp" indicates the time when the succession of lost packets has occurred. The value of the "Timestamp" is equal to the NPT time of the last received RTP packet inside the measurement period, in playback order, before the occurrence of the succession of lost packets, relative to the starting time of the measurement period. If there is no received RTP packet inside the measurement period and before the succession of loss, the timestamp is set to the starting time of the measurement period.

If a full run length encoding of RTP losses with sequence number information is desired, RTCP XR [RFC 3611] Loss RLE Reporting Blocks should be used instead of the successive loss metric.

11.2.4.2 XML reporting format

The semantics for calculating successively lost RTP packets is specified in section 11.2.4.1.

All the number of successively lost RTP packets are summed up over each resolution period of the stream and stored in the vector TotalNumberofSuccessivePacketLoss. The unit of this metric is expressed as an integer equal to or larger than 0. The number of individual successive packet loss events over each resolution period are summed up and stored in the vector NumberOfSuccessiveLossEvents. The number of received packets is also summed up over each resolution period and stored in the vector NumberOfReceivedPackets. These three vectors are reported by the PSS client as as Metric-Name "TotalNumberofSuccessivePacketLoss", "NumberOfSuccessiveLossEvents" and "NumberOfReceivedPackets" respectively.

11.2.5 Frame rate deviation

11.2.5.1 Default reporting format

Frame rate deviation indicates the playback frame rate information. Frame rate deviation happens when the actual playback frame rate during a measurement period is deviated from a pre-defined value.

The actual playback frame rate is equal to the number of frames played during the measurement period divided by the time duration, in seconds, of the measurement period.

The parameter FR that denotes the pre-defined frame rate value is used with the "Framerate_Deviation" parameter in the "3GPP-QoE-Metrics" header. The value of FR shall be set by the server. The syntax for FR to be included in the "Measure-Spec" (clause 5.3.2.3.1) is as follows:

FR = "FR" "=" 1*DIGIT "." 1*DIGIT

The syntax for the Metrics-Name "Framerate_Deviation" for the QoE-Feedback header is as defined in clause 5.3.2.3.2 with the exception that "Timestamp" in "Measure" is undefined for this metric. The absence of an event can be reported using the space (SP).

For the Metrics-Name "Framerate_Deviation", "Value" field indicates the frame rate deviation value that is equal to the pre-defined frame rate minus the actual playback frame rate. This metric is expressed in frames per second, and can be a fractional value, and can be negative. The metric value can occur only once for this metric.

11.2.5.2 XML reporting format

In the XML reporting format the frame rate is reported instead of the frame rate deviation. The metric "Framerate" indicates the average actual playback frame rate used during each resolution period. It is expressed in frames per second, and can be a fractional value. The average frame rate for each resolution period is stored in the vector Framerate and the vector is reported by the PSS client as Metric-Name "FrameRate".

11.2.6 Jitter duration

11.2.6.1 Default reporting format

Jitter happens when the absolute difference between the actual playback time and the expected playback time is larger than a pre-defined value, which is 100 milliseconds. The expected time of a frame is equal to the actual playback time of the last played frame plus the difference between the NPT time of the frame and the NPT time of the last played frame.

The syntax for the Metrics-Name "Jitter_Duration" for the QoE-Feedback header is as defined in clause 5.3.2.3.2.

The absence of an event can be reported using the space (SP).

For the Metrics-Name "Jitter_Duration", the "Value" field in 5.3.2.3.2 indicates the time duration of the playback jitter. The unit of this metrics is expressed in seconds, and can be a fractional value. There is the possibility that jitter occurs more than once during a measurement period. In that case the metric value can occur more than once indicating the number of jitter events.

The optional "Timestamp" field indicates the time when the jitter has occurred since the beginning of the measurement period. The value of the "Timestamp" is equal to the NPT time of the first played frame in the playback jitter, relative to the starting time of the measurement period.

11.2.6.2 XML reporting format

The semantics for calculating jitter duration is specified in section 11.2.6.1.

All the Jitter_Durations are summed up over each resolution period and stored in the vector TotalJitterDuration. The number of individual events over the resolution duration are summed up and stored in the vector NumberOfJitterEvents. These two vectors are then reported by the PSS client as Metric-Name "TotalJitterDuration" and "NumberOfJitterEvents" respectively.

11.2.7 Content Switch Time

11.2.7.1 Default reporting format

Fast content switching is defined in section 5.5 and allows for improving the switch time between different content accessible via the same RTSP server. Content switch time has a significant impact on the quality of experience for the user.

The content switch time is the time that elapses between the initiation of the content switch by the user and up to the time of reception of the first media packet from the new content or media stream.

The syntax for the metric "Content_Switch_Time" for the QoE Feedback header is defined in clause 5.3.2.3.2.

The absence of a content switch event or the impossibility to determine the duration of a content switch can be reported using the space (SP).

For the metric name "Content_Switch_Time", the "Value" field in 5.3.2.3.2 indicates the content switch time as defined above. The unit of this metric is expressed in milliseconds.

In case several content switch events have occurred during the measurement period, a list of values is reported each relating to the corresponding old content or media URL.

The optional "Timestamp" field indicates the time when the content switch event was triggered by the user. The value of the "Timestamp" is equal to the NPT time of the old content that corresponds to the content switch triggering time.

11.2.7.2 XML reporting format

The semantics for calculating Content_Switch_Time is specified in section 11.2.7.1.

All the Content_Switch_Times are summed up over each resolution period and stored in the vector TotalContentSwitchTime. The number of individual events over the resolution duration are summed up and stored in the vector NumberOfContentSwitchEvents. These two vectors are then reported by the PSS client as Metric-Name "TotalContentSwitchTime" and "NumberOfContentSwitchEvents" respectively.

11.2.8 Average Codec Bitrate

11.2.8.1 Default reporting format

The average codec bitrate is the bitrate used for coding "active" media information during the measurement resolution period.

For audio media "active" information is defined by frames containing audio. If the audio codec uses silence frames (SID-frames), these frames are not counted as "active", and the SID-frames and the corresponding DTX time periods are excluded from the calculation. Thus for audio media the average codec bitrate can be calculated as the number of audio bits received for "active" frames , divided by the total time, in seconds, covered by these frames. The total time covered is calculated as the number of "active" frames times the length of each audio frame.

For non-audio media the average codec bitrate is the total number of media bits played out during the measurement resolution period, divided by the length of the playout period. The playout period length is normally equal to the length of the measurement resolution period, but if rebuffering occurs the playout period will be shorter (i.e. any rebuffering time shall be ignored when calculating the codec bitrate).

The syntax for the metric "Average_Codec_Bitrate" is defined in sub-clause 5.3.2.3.2.

For the metric name "Average_Codec_Bitrate", the "Value" field in 5.3.2.3.2 indicates the codec bitrate as defined above. The unit of this metrics is expressed in kbit/s and can be a fractional value.

11.2.8.2 XML reporting format

The semantics for calculating average codec bitrate is specified in section 11.2.8.1.

The average codec bitrate value for each measurement resolution period shall be stored in the vector AverageCodecBitrate. The unit of this metrics is expressed in kbit/s and can be a fractional value. The vector is then reported by the PSS client as Metric-Name "AverageCodecBitrate".

11.2.9 Codec Information

11.2.9.1 Default reporting format

The codec information metrics contain details of the media codec used during the measurement period. The unit of this metric is a string value. No "white space" characters are allowed in the string values, and shall be removed if necessary.

For audio media the codec information contains the audio codec type, represented as in an SDP offer, for instance "AMR-WB/16000/1".

For video media, the codec information contains the video codec type, represented as in an SDP offer . Furthermore, the video profile and level used, as well as the image size used shall be reported. For instance "profile=0;level=45" for the profile and level information and "176×144" for the image size. In some cases the profile and level is reported together, for instance "profile-level-id=42e00a". Note that the image size reported for each measurement resolution period shall be the one actually used, not the maximum size allowed by the SDP negotiation.

For timed text media, the codec information contains the text encoding, represented as in an SDP offer, for instance "3gpp-tt/1000".

The syntax for the metric "CodecInfo", "CodecProfileLevel" and "CodecImageSize" are defined in sub-clause 5.3.2.3.2.

There is the possibility that the codec information is changed during the measurement period. In that case the metrics can occur more than once indicating the codecs used.

The optional "Timestamp" field indicates the time when codec changes have occurred, relative to the beginning of the measurement period.

11.2.9.2 XML reporting format

The semantics for generating codec information, profile/level and codec image size is specified in section 11.2.9.1.

The codec information, profile/level and codec image size value for each measurement resolution period shall be stored in the vectors CodecInfo, CodecProfileLevel and CodecImageSize respectively. If the metric values in these vectors for a measurement resolution period are unchanged from the previous values in the respective vector, it is allowed to put the value "=" in the vector to indicate this. These three vectors are reported by the PSS client as as Metric-Name "CodecInfo", "CodecProfileLevel" and "CodecImageSize" respectively.

11.2.10 Buffer Status

11.2.10.1 Default reporting format

The buffer depth is the number of seconds of future media which resides in the buffer. It is calculated as the difference between the latest playout time of the media units in the buffer minus the current playout time. If the calculation result is negative, the buffer depth shall be set to zero. The buffer depth metric shall be calculated close to the end of each measurement period.

The unit of the metric bufferDepth is in seconds and can be a fractional value. If the length of the media is known, and if all remaining media already is buffered, then the boolean metric allContentBuffered shall be set to true.

The syntax for the metric "bufferDepth" and "allContentBuffered" is defined in sub-clause 5.3.2.3.2.

11.2.10.2 XML reporting format

The semantics for calculating buffer depth is specified in section 11.2.10.1.

The buffer depth close to the end of each measurement period shall be stored in the vector bufferDepth. The vector and the allContentBuffered status is then reported at the end of each reporting period.

11.3 The QoE protocol for RTSP based reporting

11.3.1 General

PSS clients and servers supporting QoE Metrics for RTSP streaming shall support the QoE protocol described below.

The RTSP and SDP based protocol extensions (see clauses 5.3.2.3 and 5.3.3.6) are used for transport and negotiation of the QoE metrics between the PSS client and the PSS server. As an alternative, OMA-DM and HTTP can also be used for QoE configuration and reporting (see clauses 5.3.3.8 and 5.3.2.3.3).

The QoE metrics negotiation starts with the response to the DESCRIBE request, if the metrics information is embedded in the SDP data (as described in example 1 in clause 11.3.2). For the case of locally stored SDP which contains QoE-Metrics attribute, the negotiation starts with client’s SETUP request. If the PSS client supports QoE metrics, then it shall send a SETUP request containing the selected (i.e. accepted by client)/modified (for re-negotiation) QoE metrics for either session level, or the media level, which is being set-up. Such a SETUP request is shown in example 2 in clause 11.3.3.

Upon receiving this SETUP request, the server shall return the RTSP Response with the "accepted" QoE metrics (i.e. metrics and metrics values which are identical to the ones in the client’s request and accepted by the server) and the "re-negotiation" QoE metrics (i.e. metrics and metrics values which are not identical to the ones in the client’s request and modified for re-negotiation by the server) .The echoing of the "accepted" QoE metrics is for re-acknowledging the client. The server may also reject the changes made by the client, i.e. reject the "re-negotiation" QoE metrics. If the server rejects the changes, it shall either set new values or resend the modified metrics back to the client, or it shall ignore the "re-negotiation" metrics and not re-acknowledge them. Any QoE metric that has been acknowledged as "accepted" by the server shall not be re-negotiated, i.e., it shall not be resent in the "3GPP-QoE-Metrics" header in the next RTSP request and shall not be re-acknowledged in the next RTSP response.

If the server does not approve the modifications done by the client, they should continue to re-negotiate. However, negotiations shall not exceed 4 round trips, in order to bound the negotiation process. It must be noted that each time the "QoE-Metrics" header field is sent in an RTSP request, it shall also be present in the response corresponding to that particular request. Otherwise, the receiver of the response shall assume that the other end does NOT support QoE metrics.

If there is no DESCRIBE – RTSP Response pair sending at the beginning of the RTSP signalling (see Figure 11.2), it means that the SDP description is received by other means. If such an SDP contains the "3GPP-QoE-Metrics" attribute, the negotiation happens in the same way as it is described above, i.e. starts with SETUP request containing "3GPP-QoE-Metrics" header. If the SDP does not contain the "3GPP-QoE-Metrics" attribute and the server would still like to check whether the client supports QoE Protocol or not, the server shall include the "3GPP-QoE-Metrics" header containing the initial QoE metrics in the SETUP response. If the PSS client sends the QoE metrics information in the next request (indicating that it supports QoE Protocol), the negotiation shall continue until the mutual agreement is reached or the negotiation limit is reached. If pipelined startup is not in use and the client does not send QoE metrics information in the next request to SETUP response, then the server shall assume that the client does not support QoE metrics. In case pipelined startup is in use, the server may initiate QoE negotiation but it should not expect an answer from the PSS client.

In case of switching without the SDP, the PSS client shall assume that the same QoE metrics as negotiated for the old stream will be used for the new stream. In the PLAY response, the server includes the "3GPP-QoE-Metrics" header to acknowledge the QoE metric mapping to the new media streams or to change them.

During fast content switching with SDP, the client shall indicate the QoE metrics to be used for the new content using the "3GPP-QoE-Metrics" header. The client should use the already negotiated parameters as much as possible to avoid further negotiations. The server shall either acknowledge the proposed QoE metrics or continue negotiation beyond the PLAY response message. It is possible to turn off the metrics during a streaming session. In clause 11.3 an example of messages, where the metrics are set to "Off" is given. The metrics can be set to "Off" at session level or at media level. The request url indicates what level is used. If no url is used, then "Off" applies to session level. The server should use OPTIONS (with Session ID) or SET_PARAMETER RTSP methods to turn off the QoE feedback.

A client should not send QoE feedback during RTSP ready state. After the ready state is ended (i.e., RTSP state=playing), the periodic feedback and normal operations continue. This reduces the network load in the uplink and downlink directions, and the processing overhead for the PSS client. When an RTSP PLAY request is sent by the PSS client after a PAUSE, the clock for the measurement period (based on the defined "Sending Rate") shall be reset.

If there are multiple non-aggregated sessions, i.e. each media delivery is initiated by a different PLAY request, the QoE metrics are negotiated and reported for each session separately.

All the QoE Metrics in the following examples are fictitious. Clause 11.2 defines the actual QoE Metrics.

11.3.2 Metrics initiation with SDP

QoE metrics initiation with SDP shall be done according to clause 5.3.3.6.

This following example shows the syntax of the SDP attribute for QoE metrics. The session level QoE metrics description (Initial buffering duration and rebufferings) are to be monitored and reported only once at the end of the session. Also video specific description of metrics (corruptions and decoded bytes) is to be monitored and reported every 15 seconds from the beginning of the stream until the time 40s. Finally, audio specific description of metrics (corruptions) is to be monitored and reported every 20 seconds from the beginning until the end of the stream.

EXAMPLE 1:

S->C RTSP/1.0 200 OK
Cseq: 1
Content-Type: application/sdp
Content-Base: rtsp://example.com/foo/bar/baz.3gp/
Content-Length: 800
Server: PSSR7 Server

v=0
o=- 3268077682 433392265 IN IP4 63.108.142.6
s=QoE Enables Session Description Example
e=support@foo.com
c=IN IP4 0.0.0.0
t=0 0
a=range:npt=0-83.660000
a=3GPP-QoE-Metrics:metrics={Initial_Buffering_Duration|Rebuffering_Duration };rate=End
a=control:*
m=video 0 RTP/AVP 96
b=AS:397
a=3GPP-QoE-Metrics:metrics={Corruption_Duration|Decoded_Bytes };rate=15;range:npt=0-40
a=control:trackID=3
a=rtpmap:96 H264/90000
a=range:npt=0-83.666000
a=fmtp:96profile-level-id=42c00c;sprop-parameter-sets= Z0LADJWgUH6Af1A=,aM46gA==
m=audio 0 RTP/AVP 98
b=AS:13
a=3GPP-QoE-Metrics:metrics={Corruption_Duration };rate=20
a=control:trackID=5
a=rtpmap:98 AMR/8000
a=range:npt=0-83.660000
a=fmtp:98 octet-align=1
a=maxptime:200

11.3.3 Metrics initiation/termination with RTSP

QoE Metrics initiation with RTSP can be done according to clause 5.3.2.3.1

In the following example it is shown how to negotiate QoE metrics during RTSP session setup.

EXAMPLE 1 (QoE metrics negotiation):

Figure 11.1: QoE metrics negotiation

C->S SETUP rtsp://example.com/foo/bar/baz.3gp/trackID=3 RTSP/1.0
Cseq: 2
3GPP-QoE-Metrics:url="rtsp://example.com/foo/bar/baz.3gp/trackID=3"; metrics={Corruption_Duration|Decoded_Bytes };rate=10; Range:npt=0-40, url="rtsp://example.com/foo/bar/baz.3gp";
metrics={Initial_Buffering_Duration|Rebuffering_Duration };rate=End

In the above SETUP request, the client modifies the sending rate of the QoE metrics for the control URL "rtsp://example.com/foo/bar/baz.3gp/trackID=3" from 15 to 10 (compared to the initial SDP description).

Assuming that the server acknowledged the changes, the server will send back a SETUP response as follows:

S->C RTSP/1.0 200 OK
Cseq: 2
Session: 17903320
Transport: RTP/AVP;unicast;client_port=7000-7001;server_port= 6970-6971
3GPP-QoE-Metrics:url="rtsp://example.com/foo/bar/baz.3gp/trackID=3"; metrics={Corruption_Duration|Decoded_Bytes };rate=10;Range:npt=0-40, url="rtsp://example.com/foo/bar/baz.3gp"; metrics={Initial_Buffering_Duration|Rebuffering_Duration };rate=End

EXAMPLE 2 (QoE metrics negotiation – no DESCRIBE – 200/OK):

An example is shown in Figure 11.2 and can make use of the same RTSP header defined in clause 5.3.2.3.

Figure 11.2: QoE metrics negotiation (no DESCRIBE-200/OK)

EXAMPLE 3 (QoE metrics negotiation – fast content switching with the SDP)

Figure 11.3: QoE metrics negotiation during content switch with SDP

C->S PLAY rtsp://example.com/foo/bar/baz.3gp RTSP/1.0
Cseq: 3
Session: 17903320
Switch-Stream:old="rtsp://example.com/foo/bar/foo.3gp/trackID=1";new=" rtsp://example.com/foo/bar/baz.3gp/trackID=1"; old="rtsp://example.com/foo/bar/foo.3gp/trackID=2";new=" rtsp://example.com/foo/bar/baz.3gp/trackID=2";
3GPP-QoE-Metrics:url="rtsp://example.com/foo/bar/baz.3gp/trackID=1"; metrics={Corruption_Duration|Decoded_Bytes };rate=10; Range:npt=0-40

In the above PLAY request, the client reuses the already negotiated sending rate of the QoE metrics for the control URL "rtsp://example.com/foo/bar/baz.3gp/trackID=1" (compared to the above indicated range in the SDP description, which is 15).

Assuming that the server acknowledged the changes, the server will send back a PLAY response as follows:

S->C RTSP/1.0 200 OK
Cseq: 3
Session: 17903320
RTP-Info: rtsp://example.com/foo/bar/baz.3gp/trackID=1;seq=5000;rtptime=9873984 3GPP-3GPP-QoE-Metrics:url=" rtsp://example.com/foo/bar/baz.3gp/trackID=1;
metrics={Corruption_Duration|Decoded_Bytes };rate=10;Range:npt=0-40

EXAMPLE 4 (QoE metrics negotiation – fast content switching without the SDP)

Figure 11.4: QoE metrics negotiation during content switch with SDP

C->S PLAY rtsp://example.com/foo/bar/baz.3gp RTSP/1.0
Cseq: 3
Session: 17903320
Sdp-Requested:1

In the above PLAY request, the client switches to new content without having the SDP. By consequence, the client does not have any information about the requested QoE parameters and cannot indicate those in the PLAY request.

In the case of a successful switch, the server indicates the QoE metrics in the SDP and in the 3GPP-QoE-Metrics header. The server reuses the already negotiated feedback period of 10 seconds.

S->C RTSP/1.0 200 OK
Cseq: 3
Session: 17903320
RTP-Info: rtsp://example.com/foo/bar/baz.3gp/trackID=1;seq=5000;rtptime=9873984 3GPP-3GPP-QoE-Metrics:url="rtsp://example.com/foo/bar/baz.3gp/trackID=1";
metrics={Corruption_Duration|Decoded_Bytes };rate=10;Range:npt=0-40

v=0
o=- 3268077682 433392265 IN IP4 63.108.142.6
s=QoE Enables Session Description Example
e=support@foo.com
c=IN IP4 0.0.0.0
t=0 0
a=range:npt=0-83.660000
a=control: rtsp://example.com/foo/bar/baz.3gp/trackID=1
m=video 0 RTP/AVP 96
b=AS:397
a=3GPP-QoE-Metrics:{Corruption_Duration|Decoded_Bytes };rate=10;range:npt=0-40
a=control:trackID=3
a=rtpmap:96 H264/90000
a=range:npt=0-83.666000
a=fmtp:96profile-level-id=42c00c ;sprop-parameter-sets= Z0LADJWgUH6Af1A=,aM46gA==
m=audio 0 RTP/AVP 98
b=AS:13
a=control: rtsp://example.com/foo/bar/baz.3gp/trackID=2
a=rtpmap:98 AMR/8000
a=range:npt=0-83.660000
a=fmtp:98 octet-align=1
a=maxptime:200

The client may further negotiate the offered QoE metrics using OPTIONS or SET_PARAMETER methods.

EXAMPLE 4 (setting the metrics off):

In this example, the metrics are switched off at session level (for all media).

C->S, S->C SET_PARAMETER rtsp://example.com/foo/bar/baz.3gp RTSP/1.0
Cseq: 302
Session: 17903320
3GPP-QoE-Metrics: Off
Content-length: 0

The response for setting the metrics off would be:

S->C, C->S RTSP/1.0 200 OK
Cseq: 302
Session: 17903320
3GPP-QoE-Metrics: Off

11.3.4 Sending the metrics feedback with RTSP

QoE Metric feedback with RTSP can be formatted and sent according to clause 5.3.2.3.2.

The following example shows that during the monitoring time 2 corruption periods have occurred. Each value indicates the duration (in milliseconds) of each corruption period.

EXAMPLE 5 (Feedback):

C->S SET_PARAMETER rtsp://example.com/foo/bar/baz.3gp RTSP/1.0
Cseq: 302
Session: 17903320
3GPP-QoE-Feedback: url="rtsp://example.com/foo/bar/baz.3gp/trackID=3";Corruption_Duration={200 1300}
Content-length: 0

The following example shows that during the monitoring time 2 corruption periods have occurred. Each values couple indicates the duration (in milliseconds) of each corruption period and the timestamp of the corruption (for example, the first corruption occurred at second 12 and lasted 200 milliseconds).

EXAMPLE 6 (Feedback with timestamps and range):

C->S SET_PARAMETER rtsp://example.com/foo/bar/baz.3gp RTSP/1.0
Cseq: 302
Session: 17903320
3GPP-QoE-Feedback: url="rtsp://example.com/foo/bar/baz.3gp/trackID=1"; Corruption_Duration={200 12|1300 16};Range:npt=10-20;Content_Switch_Time={1055 34498}
Content-length: 0

In the following example there are no events to report.

EXAMPLE 7 (Feedback with no events):

C->S SET_PARAMETER rtsp://example.com/foo/bar/baz.3gp RTSP/1.0
Cseq: 302
Session: 17903320
3GPP-QoE-Feedback: url="rtsp://example.com/foo/bar/baz.3gp/trackID=3";Corruption_Duration={ }
Content-length: 0