Subject: [Sipping] Last Call: draft-ietf-sipping-rtcp-summary (Session Initiation Protocol Package for Voice Quality Reporting Event) to Proposed Standard

From: The IESG <[email-masked]>
Date: Thu, 17 May 2007 09:16:07 -0400

The IESG has received a request from the Session Initiation Proposal 
Investigation WG (sipping) to consider the following document:

- 'Session Initiation Protocol Package for Voice Quality Reporting 
Event'
   <draft-ietf-sipping-rtcp-summary-02.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2007-05-31. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sipping-rtcp-summary-02.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14087&rfc_flag=0

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 28 May 2007 17:36:44 +0200

Hi,

I have reviewed the draft and have a few comments. But my summary is 
that it is far from ready for publication. The biggest problem is that 
it does not support multi-party calls or any form of RTP session that 
has more than a single RTP SSRC. It also does not consider the use of 
multiple payload types, the dynamics of a large number of reported 
values. Also the overload handling needs to be defined in such a way 
that one actually can use it to prevent overload instead of some vague 
notions.

1. Section 3.2:

I think there needs to be some details about how on actually configures 
and ensure that this type of overload situation doesn't happens. Lets 
ensure that we don't have to retrofit overload / congestion handling 
also to this protocol. Instead all mechanisms should be in place to 
ensure that interoperable function exist so that one can prevent overload.

2. Section 3.3:

   "The REPORTER shall populate the Request-URI of the PUBLISH method
    with the address of the resource (AOR) of the COLLECTOR."

Okay, maybe my lack of SIP knowledge shows here. But should this 
sentence really talk about PUBLISH? Or is it a copy paste error?

3. Section 4.6.1

"   SessionDescription  = "SessionDesc" COLON
       [PayloadType WSP]
       [PayloadDesc WSP]
       [SampleRate WSP]
       [FrameDuration WSP]
       [FrameOctets WSP]
       [FramesPerPacket WSP]
       [PacketsPerSecond WSP]
       [FmtpOptions WSP]
       [PacketLossConcealment WSP]
       [SilenceSuppressionState]
       *(WSP Extension)

    ; PayloadType provides the PT parameter used in the RTP packets
    ; i.e. the codec used for decoding received RTP packets
    ; It is recommended that IANA registered values are used
    ; where possible.
    PayloadType  = "PT" EQUAL (1*3DIGIT)

    ; PayloadDesc provides a text description of the codec
    ; It is recommended that IANA registered names are used
    ; where possible.
    PayloadDesc  = "PD" EQUAL word"

This description doesn't seem to work. It doesn't provide a way of 
binding a payload type to an actual description of the codec configured. 
It may depend on a failure to consider the use of multiple payload types 
within a RTP session.

4. Section 4.6.1.

"   ; SampleRate provides the rate at which voice was sampled
    ; in the case of narrowband codecs, the value will typically be 8000
    SampleRate = "SR" EQUAL (1*5DIGIT)"

This should also be bound on a per payload type basis. I also think that 
only 1*5 digits are to little. That doesn't allow for usage with 192kHz 
sampling rate that may occur in a pro-audio application.

5. Section 4.6.1.

"   ; FrameDuration can be combined with the FramesPerPacket to determine
    ; the packetization rate; the units for this are milliseconds.
    FrameDuration = "FD" EQUAL (1*3DIGIT)

This is a static value for many codecs. However there exist some codecs 
that can manipulate this runtime. Thus if one like to have this working 
then one should have this as a reported value.

6. Section 4.6.1.

    ; FrameOctets provides the number of octets in each frame
    ; Used where FrameDuration is not available
    FrameOctets  = "FO" EQUAL (1*4DIGIT)

    ; FramesPerPacket provides the number of frames in each RTP packet
    FramesPerPacket = "FPP" EQUAL (1*2DIGIT)

    ; Packets per second provides the number of packets, including one or
    ; more frames within each, that are transmitted per second
    PacketsPerSecond = "PPS" EQUAL (1*5DIGIT)"

These parameters are all dynamic ones and can vary with time to adapt to 
transport sessions. Some are even so dynamic that they can change on a 
packet by packet basis. Thus a complete different structure and 
definitions are needed to handle this.

7. Section 4.6.1.

"   ; FMTP options from SDP.  Note that the parameter is deliniated
    ; by " " to avoid parsing issues in transitioning between SDP and
    ; SIP parsing
    FmtpOptions = "FMTP" EQUAL DQUOTE word-plus DQUOTE"

This also needs to be on per payload type basis. With the possibility to 
add multiple ones.

8. Section 4.6.1.

I somewhat question the SSRC multiplexing model used in this report 
format. Is it the intention that "SessionReport" applies on the complete 
RTP session as the name hints at or as the fact is on a single source. 
Because with current structure you need to send individual reports for 
each SSRC that takes part of the same session. And in that duplicate a 
lot of information related to the configuration. Please explain.

9. Section 4.6.1:

    ; LocalAddr provides the IP address, port and ssrc for the
    ; session from the perspective of the endpoint/UA which is
    ; sending the report
    LocalAddr   = "LocalAddr" COLON IPAddress WSP Port WSP Ssrc

    ; RemoteAddr provides the IP address, port and ssrc for the
    ; session from the perspective of the peer of the endpoint/UA
    ; that is sending the report
    RemoteAddr  = "RemoteAddr" COLON IPAddress WSP Port WSP Ssrc

These definitions are not correct by RTP definitions. SSRC represents 
sources in an RTP session. They do have source and destination address 
and ports. However depending on how you are who does the reporting the 
destination may or may not match the reporting entities address. 
Multicast is one such example. But if one actually like translators or 
mixers to use this package then one needs to separate the roles 
correctly. The right way of characterize a RTP flow from a particular 
source would in my view be to:

1. Be explicit on the identify of the reporting entity, and please 
consider that they may not have an SSRC even if most will. (They will if 
they are sending RTCP). But there are reporting entities that only 
consumes RTCP and do not send it and thus do not need an SSRC.

2. Use source address/port tuple and destination address/port tuple plus 
SSRC for identifying each flow.

That way one can avoid the confusion about who is reporting and on what 
in most cases. It might still not be crystal clear in systems that 
employ translators as they rewrite source and destination tuples. But 
the SSRC will be maintained over such entities.

The extension of this is that one needs to be able to provide the report 
data on per reporter basis for each source of an RTP flow. Thus some 
multi-level hierarchy is needed to handle this correctly. The current 
ones assumes a single remote peer point that can provides RTCP data that 
one may like to summarize in this report. Which totally fails in 
multi-party environments using multicast or translators.

10. Section 4.6.1:

One more thing about the identification of who's data and for what. 
Please consider how a REPORTER can provide data for the stream it sent 
itself. Currently it seems that this stream will be impossible to 
include in the report as you must have local data which you don't have. 
You can only have remote data for that stream.

11. section 4.6.1:

    ; RoundTripDelay is recommended to be measured as defined in
    ; RTCP, RFC 3550.
    RoundTripDelay = "RTD" EQUAL (1*5DIGIT) ;0-65535

    ; OneWayDelay is recommended to be measured according to
    ; recommendations provided by the IPPM working group but may be
    ; based on alternative measurement recommendations
    OneWayDelay = "OWD" EQUAL (1*5DIGIT) ;0-65535

These measurements are lacking a clear definition or allows for 
alternative definitions to be used. I can't see how this provide 
interoperable usage of the measurement. The method for the measurement 
should be clear and precise so that is useful.

12. Section 4.6.2.2:

Following SIP and other IETF convention, timestamps are provided
in Coordinated Universal Time (UTC) using the ABNF format provided
in IETF RFC3339 [x].

Reference number is missing.

13. Section 4.6.2:

Aggregation of the metrics over the reporting interval. In RTCP XR the 
reported value it the value of the measurement at the time of sending 
the RTCP packet. However in this summary report I think you need to 
clarify what values actually should be used. Especially if it is the 
intention that a peer should include summary of received RTCP packets 
from other peers. Because to me it seems that using this metric will 
require one to run additional instances of the measurement process then 
for the RTCP reports or for SessionReport or the IntervalReport due to 
the need to reset the values at the start time of the metrics.

So please clarify how the different metrics should be derived before 
being written into the different type of report types.

To make it clear about this example. Lets use Round Trip Delay as an 
example. What value should be included in a SessionReport? RTT values 
may vary substantially during a session. It also is instantaneous value 
for each received RTCP RR from ones peer. So it is the latest for the 
session duration, the largest, the average, the median, some other 
statistical processing. And should I calculate this different in 
IntervalReport or in a AlertReport?

14. Section 8.

Reference [6] needs to be updated to RFC 4234.

Regards

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Colin Perkins <[email-masked]>
Date: Thu, 31 May 2007 11:16:38 +0100

I largely agree with Magnus' comments, and think this draft needs  
significant work before it is ready for publication.

The summary reports specified here do not reflect the inherently  
multiparty nature of RTP sessions. RTP is by definition a group  
communications protocol, designed to scale from point-to-point to  
large group communications. The reports defined here, however, assume  
point-to-point use, and don't support multiparty sessions. That is a  
significant limitation, contrary to the definition of an RTP session.  
(I understand that many implementations are limited to point-to-point  
use, but we shouldn't design protocol extensions around the  
limitations of some current implementations).

In addition, I'm concerned that reports contain an (incomplete and  
poorly specified) subset of the SDP session description, recast in a  
different syntax, rather than returning the complete session  
description.

Colin

On 28 May 2007, at 16:36, Magnus Westerlund wrote:
> Hi,
>
> I have reviewed the draft and have a few comments. But my summary  
> is that it is far from ready for publication. The biggest problem  
> is that it does not support multi-party calls or any form of RTP  
> session that has more than a single RTP SSRC. It also does not  
> consider the use of multiple payload types, the dynamics of a large  
> number of reported values. Also the overload handling needs to be  
> defined in such a way that one actually can use it to prevent  
> overload instead of some vague notions.
>
> 1. Section 3.2:
>
> I think there needs to be some details about how on actually  
> configures and ensure that this type of overload situation doesn't  
> happens. Lets ensure that we don't have to retrofit overload /  
> congestion handling also to this protocol. Instead all mechanisms  
> should be in place to ensure that interoperable function exist so  
> that one can prevent overload.
>
>
> 2. Section 3.3:
>
> binding a payload type to an actual description of the codec  
> configured. It may depend on a failure to consider the use of  
> multiple payload types within a RTP session.
>
> 4. Section 4.6.1.
>
> This should also be bound on a per payload type basis. I also think  
> that only 1*5 digits are to little. That doesn't allow for usage  
> with 192kHz sampling rate that may occur in a pro-audio application.
>
> 5. Section 4.6.1.
>
> This is a static value for many codecs. However there exist some  
> codecs that can manipulate this runtime. Thus if one like to have  
> this working then one should have this as a reported value.
>
> 6. Section 4.6.1.
>
> These parameters are all dynamic ones and can vary with time to  
> adapt to transport sessions. Some are even so dynamic that they can  
> change on a packet by packet basis. Thus a complete different  
> structure and definitions are needed to handle this.
>
> 7. Section 4.6.1.
>
> This also needs to be on per payload type basis. With the  
> possibility to add multiple ones.
>
> 8. Section 4.6.1.
>
> format. Is it the intention that "SessionReport" applies on the  
> complete RTP session as the name hints at or as the fact is on a  
> single source. Because with current structure you need to send  
> individual reports for each SSRC that takes part of the same  
> session. And in that duplicate a lot of information related to the  
> configuration. Please explain.
>
>
> 9. Section 4.6.1:
>
> These definitions are not correct by RTP definitions. SSRC  
> represents sources in an RTP session. They do have source and  
> destination address and ports. However depending on how you are who  
> does the reporting the destination may or may not match the  
> reporting entities address. Multicast is one such example. But if  
> one actually like translators or mixers to use this package then  
> one needs to separate the roles correctly. The right way of  
> characterize a RTP flow from a particular source would in my view  
> be to:
>
> consider that they may not have an SSRC even if most will. (They  
> will if they are sending RTCP). But there are reporting entities  
> that only consumes RTCP and do not send it and thus do not need an  
> SSRC.
>
> 2. Use source address/port tuple and destination address/port tuple  
> plus SSRC for identifying each flow.
>
> That way one can avoid the confusion about who is reporting and on  
> what in most cases. It might still not be crystal clear in systems  
> that employ translators as they rewrite source and destination  
> tuples. But the SSRC will be maintained over such entities.
>
> The extension of this is that one needs to be able to provide the  
> report data on per reporter basis for each source of an RTP flow.  
> Thus some multi-level hierarchy is needed to handle this correctly.  
> The current ones assumes a single remote peer point that can  
> provides RTCP data that one may like to summarize in this report.  
> Which totally fails in multi-party environments using multicast or  
> translators.
>
>
> 10. Section 4.6.1:
>
> Please consider how a REPORTER can provide data for the stream it  
> sent itself. Currently it seems that this stream will be impossible  
> to include in the report as you must have local data which you  
> don't have. You can only have remote data for that stream.
>
>
> 11. section 4.6.1:
>
> interoperable usage of the measurement. The method for the  
> measurement should be clear and precise so that is useful.
>
> 12. Section 4.6.2.2:
>
> Aggregation of the metrics over the reporting interval. In RTCP XR  
> the reported value it the value of the measurement at the time of  
> sending the RTCP packet. However in this summary report I think you  
> need to clarify what values actually should be used. Especially if  
> it is the intention that a peer should include summary of received  
> RTCP packets from other peers. Because to me it seems that using  
> this metric will require one to run additional instances of the  
> measurement process then for the RTCP reports or for SessionReport  
> or the IntervalReport due to the need to reset the values at the  
> start time of the metrics.
>
> So please clarify how the different metrics should be derived  
> before being written into the different type of report types.
>
> To make it clear about this example. Lets use Round Trip Delay as  
> an example. What value should be included in a SessionReport? RTT  
> values may vary substantially during a session. It also is  
> instantaneous value for each received RTCP RR from ones peer. So it  
> is the latest for the session duration, the largest, the average,  
> the median, some other statistical processing. And should I  
> calculate this different in IntervalReport or in a AlertReport?
>
> 14. Section 8.
>

-- 
Colin Perkins
http://csperkins.org/