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

From: "Amy Pendleton" <[email-masked]>
Date: Mon, 3 Jan 2005 13:07:18 -0500

Hi David,

I remember you suggested this previously and I did not take the suggestion
because it would add a lot of extra bytes to the event which is already
pretty big. I am estimating the number of bytes per QoS report to be 950.
If you add each SDP in a two party call, it adds about 400 more bytes.  Thus
we will be just under the ethernet packet size limit of 1400.  

If there is a way to convey this information in a shortened form or if no
one else sees a problem with possible message fragmentation, I will move
forward and add the SDP's; otherwise, the format will not be changed for
WGLC.

Thanks,
Amy  

-----Original Message-----
From: David R Oran [mailto:[email-masked]] 
Sent: Tuesday, December 14, 2004 9:07 AM
To: Pendleton, Amy [NGC:B601:EXCH]
Cc: [email-masked]; [email-masked]; James Kleck; [email-masked];
[email-masked]
Subject: Re: [AVT] video in draft-johnston-sipping-rtcp-summary-04

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.

>  
> 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
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

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

---

From: David R Oran <[email-masked]>
Date: Tue, 4 Jan 2005 12:13:42 -0500

I don't feel all that strongly about this, but it seems that anything 
that helps interpret the context for the performance numbers is 
important and potentially indispensable. The SDP parameters which were 
the input to the stream creation seem to me to be in that category. 
Note that you don't need each entire SDP. You only need the m= and a= 
information for the streams that are reported in the rtcp summary 
report. And you only need one of them in the case of sendrecv RTP - the 
one the was the result of the offer/answer exchange. I would be 
surprised if this exceeded 100 bytes for anything except real corner 
cases. Note that if you are using sdescriptions, that information 
should be excised since it can contain keying material which should not 
be delivered to third parties.

Dave.

On Jan 3, 2005, at 1:07 PM, Amy Pendleton wrote:

> Hi David,
>
> I remember you suggested this previously and I did not take the 
> suggestion because it would add a lot of extra bytes to the event 
> which is already pretty big. I am estimating the number of bytes per 
> QoS report to be 950.  If you add each SDP in a two party call, it 
> adds about 400 more bytes.  Thus we will be just under the ethernet 
> packet size limit of 1400. 
>
>  If there is a way to convey this information in a shortened form or 
> if no one else sees a problem with possible message fragmentation, I 
> will move forward and add the SDP's; otherwise, the format will not be 
> changed for WGLC.
>
> Thanks,
> Amy 
>
> Cc: [email-masked]; [email-masked]; James Kleck; 
> [email-masked]; [email-masked]
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]