Subject: Re: [AVT] Working Group Last Call: draft-ietf-avt-rtp-midi-format-13 and draft-ietf-avt-rtp-midi-guidelines-13

From: lazzaro <[email-masked]>
Date: Wed, 23 Nov 2005 10:42:33 -0800

Hi Magnus,

> Magnus Westerlund <[email-masked]> wrote:
> I do have some comments on the guidelines draft.
>
> 1. Figure 1 SDP example could benefit from an b:AS or b:TIAS attribute
> to indicate the amount of bandwidth the session uses. As RTCP I  
> guess is
> going to be used, I think the inclusion of b=RR and b=RS is also
> beneficial to set the necessary bandwidth for RTCP. Otherwise 5% of a
> midi session may be to little.

OK, I'll add these ...

> 2. Section 5.1:
>
> typedef struct jsend_chapterw {  /* Pitch Wheel (0xE) */
>    uint8  chapterw[RFC3550]; /* bitfield Figure A.5.1 [RTPMIDI] */
>    uint32 seqnum;      /* extended sequence number, or 0 */
>   } jsend_chapterw;
>
> The array with RFC3550 number of elements seems strange. Find and  
> replace error?
>
> There are further arrays that are initialized with RFC3551, fix  
> also these.

Oops!  Thanks for catching those, copy/replaces were done a late pass
to change the reference methodology ...

Should I push through a -14 series now, or should I wait until WG
Last Call is over and handle all the changes at once?  Let me know ...

---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---

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

---

From: Colin Perkins <[email-masked]>
Date: Wed, 23 Nov 2005 19:15:28 +0000

On 23 Nov 2005, at 18:42, lazzaro wrote:
...
> Last Call is over and handle all the changes at once?  Let me know ...

Wait until the wg last call is done, then submit an update for  
everything.

Colin

---

From: lazzaro <[email-masked]>
Date: Thu, 24 Nov 2005 14:15:46 -0800

> midi session may be to little.

OK, here's the changes related to this that will appear in -14.txt.

The offer SDP from the first party includes these b= lines now:

m=audio 16112 RTP/AVP 96
b=AS:20
b=RS:400
b=RR:0

And the answer SDP from the second party includes these lines:

m=audio 5004 RTP/AVP 101
b=AS:20
b=RS:400
b=RR:0

Explanatory text explains these parameters as follows:

The bandwidth (b=) AS parameter [SDP] [RFC3550] indicates that the
total RTP session bandwidth is 20 kbs.  This value assumes that the
two players send 10 kbs streams concurrently.  To derive the 10 kbs
value, we begin with the analysis of RTP MIDI payload bandwidth in
Appendix A.4 of [NMP], and add in RTP and IP4 packet overhead and a
small safety factor.

The bandwidth RS parameter [RFC3556] indicates that the shared RTCP
session bandwidth for the two senders is 400 bps.  This value supports
one RTCP packet per 5 seconds from each participant, containing a
Sender Report and CNAME information [RFC3550].  As the session
contains no receive-only members, the bandwidth RR parameter [RFC3556]
is set to 0.

---
John Lazzaro

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 25 Nov 2005 10:09:30 +0100

Hi John,

Although I think it will work to set RR to 0 in this particular 
application thanks to guard time. As both end points will be sending 
packets every second the RTCP always interpret each end-point as a 
sender in RTCP meaning. Thus all will use the RS as the bandwidth share.

If one wouldn't use a guard time or it was longer than 2 times the RTCP 
interval then a peer could stop sending RTCP when it get classified as a 
receiver. I don't think that is good for the closed loop policy. Thus I 
would recommend that you put some bandwidth into RR. Please note that a 
sender will use the sum of RR and RS when sending as long as senders / 
receivers > RS/(RR+RS).

Cheers

Magnus

lazzaro wrote:
>> to indicate the amount of bandwidth the session uses. As RTCP I  guess is

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: lazzaro <[email-masked]>
Date: Fri, 25 Nov 2005 09:56:02 -0800

Hi Magnus,

On Nov 25, 2005, at 1:09 AM, Magnus Westerlund wrote:
> application thanks to guard time. As both end points will be  
> sending packets every second the RTCP always interpret each end- 
> point as a sender in RTCP meaning. Thus all will use the RS as the  
> bandwidth share.
>
> If one wouldn't use a guard time or it was longer than 2 times the  
> RTCP interval then a peer could stop sending RTCP when it get  
> classified as a receiver. I don't think that is good for the closed  
> loop policy. Thus I would recommend that you put some bandwidth  
> into RR. Please note that a sender will use the sum of RR and RS  
> when sending as long as senders / receivers > RS/(RR+RS).

Thanks.  I changed the example as follows, please let me know if this
is OK.  If its not, could you suggest a specific RS/RR split, and  
explanatory
text that a newcomer to RTP would be able to understand?  Thanks ...

Both session descriptions now use:

b=RS:0
b=RR:400

And the explanatory text now reads:

The bandwidth RR parameter [RFC3556] indicates that the shared RTCP
session bandwidth for the two parties is 400 bps.  We set the
bandwidth SR parameter to 0 bps, to signal that sending parties and
non-sending parties equally share the 400 bps of RTCP bandwidth (note
that in this particular example, the guardtime parameter value of
44100 ensures that both parties are sending for the duration of the
session).  The 400 bps RTCP bandwidth value supports one RTCP packet
per 5 seconds from each party, containing a Sender Report and CNAME
information [RFC3550].

---
John Lazzaro