Subject: [AVT] Embedding SDP information in RTCP XR blocks, Flexibility of fields in RTCP XR blocks

From: Rajesh Kumar <[email-masked]>
Date: Tue, 02 Aug 2005 03:01:14 -0700

Re: draft-clark-avt-rtcpxr-bis-00 discussion at the 63rd IETF

1. Mike Ramalho suggested that the session information embedded in RTCP
XR blocks be moved from the High Resolution block to the  Voice Quality
Metric Algorithm Block
which is sent with a much lower frequency. This is because it is
acceptable to send this session information with a lower frequency. It
should be sent when the codec changes due to an upspeed, for instance.
I agree with this assessment.

2. I do not agree with the recommendation that the SDP information
(except the encryption keys) be sent as verbatim text  in any RTCP XR
report. The proposed syntax in the internet draft more streamlined than
a verbatim SDP session descriptor (minus keys, of course). What is
gained by including SDP lines verbatim?

3. Another issue: the flexibilities in this internet draft are due to
flexibilities existing elsewhere. For instance, there are several
standard jitter measurement schemes out there. There will be more than
one standard MOS scheme. The multiple endpoints in a session may not
always use the same scheme.  When several schemes exist,  it is helpful
to indicate how a number was derived. There concern expressed by Magnus
about too much flexibility causing interoperability problems is a valid
one, however, this cannot be solved by limiting the semantic
expressiveness of metrics reporting.

Rajesh Kumar

Cisco Systems

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: [email-masked]
Date: Tue, 2 Aug 2005 06:10:59 -0400

On Aug 2, 2005, at 6:01 AM, Rajesh Kumar wrote:

> 1. Mike Ramalho suggested that the session information embedded in  
> RTCP XR blocks be moved from the High Resolution block to the   
> Voice Quality Metric Algorithm Block which is sent with a much  
> lower frequency. This is because it is acceptable to send this  
> session information with a lower frequency. It should be sent when  
> the codec changes due to an upspeed, for instance. I agree with  
> this assessment.
>
Yes. Good idea.

> (except the encryption keys) be sent as verbatim text  in any RTCP  
> XR report. The proposed syntax in the internet draft more  
> streamlined than a verbatim SDP session descriptor (minus keys, of  
> course). What is gained by including SDP lines verbatim?
>
1. No need for ad hoc case-by case extensions if we discover we need  
a= or fmtp= data for a particular coder in order to properry  
interpret the reports.
2. Ensure that a snooper interprets things exactly the same way a UA  
would interpret the data.
3. the suggestion is to include the m= line and the non-security- 
related information in a a= and fmtp= stuff. It is also useful to  
know the mid information in case you want to corellate quality  
information across streams that are supposed to be coupled.

> 3. Another issue: the flexibilities in this internet draft are due  
> to flexibilities existing elsewhere. For instance, there are  
> several standard jitter measurement schemes out there. There will  
> be more than one standard MOS scheme. The multiple endpoints in a  
> session may not always use the same scheme.  When several schemes  
> exist,  it is helpful to indicate how a number was derived. There  
> concern expressed by Magnus about too much flexibility causing  
> interoperability problems is a valid one, however, this cannot be  
> solved by limiting the semantic expressiveness of metrics reporting.
>
Sure it can (solve the interoperability problem). You may not like  
the consequences and prefer the flexibility, but the point stands.