Subject: RE: [MMUSIC] Presenting draft-westerlund-mmusic-sdp-bwparam-00.txt

From: "Lior Sion" <[email-masked]>
Date: Wed, 16 Oct 2002 15:52:53 +0200

Hi Magnus and all,

Comments inline. With ">". I removed some of the old thread for readability.

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Wednesday, October 16, 2002 10:29 AM
> To: Lior Sion
> Cc: [email-masked]
> Subject: Re: [MMUSIC] Presenting 
> draft-westerlund-mmusic-sdp-bwparam-00.txt

> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]]
> >Sent: Wednesday, October 09, 2002 10:03 AM
> >To: [email-masked]
> >Cc: [email-masked]
> >Subject: RE: [MMUSIC] Presenting 
> draft-westerlund-mmusic-sdp-bwparam-00.txt
> 
> >
> >- If b=TIAS is present in an SDP description, then there 
> MUST be a=prate in the attribute list of the media components, right?
> >
> >[Lior]
> >Why do you think this would be necessary?
> >
> 
> The prate attribute is required in all usage scenarios that 
> describe a 
> datagram transport, especially RTP. The reason is that 
> otherwise it will 
> be impossible to calculate the true bitrate this stream requires over 
> the used transport technology. 
> 

although i agree with that, i don't know if we should mandate BOTH packet rate and bitrate, especially if one is used to calculate the other, and both are the MAX unit and not necessarily the actual number. On that thought, maybe we can add a parameter to the prate that describes what block size (max packet size) was used to calculate this prate (or max bw), and maybe we can offer alternatives. 

For example, choosing blocksize 400 would have a prate of 5 while choosing a blocksize of 800 would have 11, etc. with a change of bitrate. 
Maybe we can combine this with the grouping proposal that came up a few days/weeks back?

what do you think?

Regards,
Lior Sion

**************************************************************************************************
The contents of this email and any attachments are confidential.
It is intended for the named recipient(s) only.
If you have received this email in error please notify the system manager or  the 
sender immediately and do not disclose the contents to any one or make copies.

** eSafe scanned this email for viruses, vandals and malicious content **
**************************************************************************************************

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 16 Oct 2002 16:28:22 +0200

Hi Lior,

>Maybe we can combine this with the grouping proposal that came up a few days/weeks back?

The bitrate parameter is the reason you need a packet rate in case it is 
transported using RTP. If somebody is going to use the prate parameter 
only I will not mandate that the b=TIAS is present. The TIAS bandwidth 
modifier is attempt to fix the normal AS (Application-Specific Maximum) 
to work in a variable overhead environment. As we are discussing a 
parameter that are a maximum I think a maximum packet rate is the 
correct thing to take into account. We could define an average bitrate 
and packet rate parameter, but I am questioning the usefulness of it. Is 
this really something an application can use. I find the average packet 
rate a bit more useful as some of the use cases may have rather varied 
packetization. The average can then be used to calculate the probable 
bitrate, but the real maximum can only be had by using the maximum 
packet rate.

Regarding the alternative packet rates with different block sizes I 
don't see how it can work. Unless you tell what block size you are going 
to use it will contain no information. And the actual block size that 
will be used is hard to know in advance. Also I don't want to do is 
create a whole mechanism for alternatives in this solution. For that 
kind of functionality I would strongly suggest that you look at SDP-NG 
and how to add it there.

Regards

Magnus Westerlund 

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