Subject: RE: [AVT] video in draft-johnston-sipping-rtcp-summary-04

From: "Amy Pendleton" <[email-masked]>
Date: Mon, 13 Dec 2004 17:02:23 -0500

Hi James,

The RTP payload type should already be covered in the CodecInfo line.  The
reason we are not using RTP payload type specifically is to allow permit
reporting for codecs that have not obtained officially IANA assignments.
Also, I realize more parameters are potentially needed to fully describe a
video codec; these are out of scope for the draft.
  
The intention of the draft is remain flexible enough to permit service
quality reporting for applications other than voice but at the same time
report enough useful information.  Some of the parameters, all of which are
optional, should be omitted if using the event for video.  A couple of
examples are echo return loss and the quality scores.

Thanks,
Amy

-----Original Message-----
From: James Kleck [mailto:[email-masked]] 
Sent: Thursday, December 09, 2004 6:30 PM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]; Pendleton, Amy [NGC:B601:EXCH]
Subject: [AVT] video in draft-johnston-sipping-rtcp-summary-04

To add support for Video-over-IP applications, all that may
be needed is to include another field for the StreamInfo:

   StreamInfo  = ("StreamInfo") EQUAL source-info SP dest-info SP pt-info
   pt-info     = ("pt") COLON 1*DIGIT

to identify the RTP payload type in the metrics.

Jim Kleck
8x8, Inc
[email-masked]

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

---

From: David R Oran <[email-masked]>
Date: Tue, 14 Dec 2004 10:07:04 -0500

On Dec 13, 2004, at 5:02 PM, Amy Pendleton wrote:

> Hi James,
>
> The RTP payload type should already be covered in the CodecInfo line.  
> The reason we are not using RTP payload type specifically is to allow 
> permit reporting for codecs that have not obtained officially IANA 
> assignments.  Also, I realize more parameters are potentially needed 
> to fully describe a video codec; these are out of scope for the draft.
>
One thing we could do is instead of continuing to add stuff to the 
report format is to explicitly include the contents of the media and 
associated "a=" lines that were used in SDP to establish the stream. 
That allows this to simply piggyback on registrations done for codecs 
through AVT to IANA.

Just wrap up the SDP stuff in an "SDPInfo=" parameter; then anything 
which is media-type or codec specific gets included without having to 
extend this draft for every weird-ass situation.

This deals with the static descriptor stuff; I agree that including all 
the measurement parameters to characterize the performance of the video 
coder is much more work and should be deferred unless somebody has all 
of it ready and laid out in their back-pockets.

> quality reporting for applications other than voice but at the same 
> time report enough useful information.  Some of the parameters, all of 
> which are optional, should be omitted if using the event for video.  A 
> couple of examples are echo return loss and the quality scores.
>
> Thanks,
> Amy
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]