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

From: "Amir Wolf" <[email-masked]>
Date: Wed, 9 Oct 2002 10:34:52 +0200

Emre and All,

I also agree that the Bandwidth information should include only payload.
regarding the a=prate - I think that the fact that the blocksize header in the SetUp request is not fully implemented in some clients  (since it is not mandatory) and the fact that some servers ignores this header it cause a problem to put correct information in the a=prate.
A server that ignores blocksize header can know this value in the Init state, but a server that handle this header will not be able to.
I think that we should add an additional mandatory header for the setup response which will indicate the max blocksize generated by the server, this value can be based on a blocksize header received in the request or not if the server ignores it.
Having this information and the <b=TIAS> the client will be able to calculate the bandwidth for each media level.

-----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

Hi Magnus, 
Regarding the draft, I think it points out the current problems related to  b=AS quite well.

My comments are as follows:

- Correct me if I am wrong, but the aim is to override the b=AS: with the usage of <b=TIAS + a=prate> and possibly with RR + RS, right? I mean, if an SDP description contains b=AS at any level, then it can not contain b=TIAS also, since there can be only one bandwidth value per session or media component listed in an SDP. I think it should be a little bit clarified, whether b=AS is being killed and replaced by the usage of <b=TIAS + a=prate> + RR and RS for RTP based streaming. 

- If b=TIAS is present in an SDP description, then there MUST be a=prate in the attribute list of the media components, right?

- As Lior stated, wouldn't it be better to use only the <pure media badwidth>(max) in b=TIAS? As the RTP headers can also be calculated using a=prate. This also makes things easier if there will new transport protocols with different header sizes introduced in the future.

Best Regards,
Emre

Emre Baris Aksu

Nokia Mobile Phones
Tampere / Finland
e-mail : [email-masked]
Mobile : +358 40 743 1972
Fax    : +358 7180 70504

> -----Original Message-----
> From: ext Magnus Westerlund [mailto:[email-masked]]
> Sent: 08. October 2002 15:07
> To: Lior Sion
> Cc: IETF MMUSIC WG
> Subject: Re: [MMUSIC] Presenting
> draft-westerlund-mmusic-sdp-bwparam-00.txt
> 
> 
> Hi,
> 
> Yes, we could only count the payload data. I guess that makes it 
> possible to address the cases when somebody are not using RTP at all, 
> but rather a stream based transport. One must however be careful in 
> different application to not think that a payload data rate 
> is enough. 
> In all RTP transported cases it will be required to  know the packet 
> rate to be able to calculate the correct total BW. But I agree that 
> there are cases when the packet rate can influenced by other 
> protocols 
> like the RTSP header blocksize. The total solution for this 
> should also 
> be considered, to see that a server can tell the client the result of 
> its choices.
> 
> Regarding the kbps. I was only following the syntax rules 
> that applies 
> for a bandwidth modifier for the b= line. The SDP specification says 
> that they shall be in kbps. However maybe we should discuss to change 
> this. Already the RR and RS modifiers from 
> draft-ietf-avr-rtcp-bw-05.txt 
> uses bps. So shall all future modifiers use bps?
> 
> Regards
> 
> Magnus
> 
> Lior Sion wrote:
> 
> >Hi,
> >
> >why not go all the way with this solution and signal only 
> the DATA bw value? As i've noted before, sometimes there's a 
> case when the server doesn't know in advance the packet rate 
> and/or the size of these - simply because the server should 
> try and use the client's "blocksize" parameter. Since using 
> this value changes number of packets AND total bw, the client 
> can use the knowledge of the data bw only in order to request 
> the correct blocksize.
> >
> >Also, why not use this opportunity, and use bps instead of KBps?
> >
> >Lior Sion
> >
> >-----Original Message-----
> >From: Magnus Westerlund [mailto:[email-masked]]
> >Sent: Monday, October 07, 2002 1:23 PM
> >To: IETF MMUSIC WG
> >Cc: IETF AVT WG; IETF SIPPING WG
> >Subject: [MMUSIC] Presenting 
> draft-westerlund-mmusic-sdp-bwparam-00.txt
> >
> >
> >Hi all,
> >
> >I have submitted a draft that discuss and tries to address 
> the problem 
> >with having IP and transport level as a part of the SDP bandwidth 
> >modifiers. Specifically it looks at the b=AS:<bw-value>. The 
> problems is 
> >several, but one of the major is a result of having two IP versions 
> >deployed and having translation between the two. Also header 
> compression 
> >and future transport protocols (DCCP) creates problems.
> >
> >So any person working with protocols using SDP (SIP, SAP, RTSP) or 
> >working with SDP and SDP-NG should look at this draft.
> >
> >Until it becomes available in the IETF directories it can be fetched 
> >from here:
> ><http://standards.ericsson.net/westerlund/draft-westerlund-mm
usic-sdp-bwparam-00.txt 
> >
>
>Discussion is encouraged and any comments should be directed to the 
>MMUSIC mailing list. SO PLEASE remove the other lists when replying.
>
>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]
>
>
>_______________________________________________
>mmusic mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/mmusic
>
>**************************************************************************************************
>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 **
>**************************************************************************************************
>

-- 

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]

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

**************************************************************************************************
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, 09 Oct 2002 12:46:19 +0200

Hi Amir,

In the case of RTSP controlled streaming my proposal for handling the 
prate is the following.
- In cases when the server either ignores blocksize or the given 
blocksize allows for the predefined sizes the prate in the SDP from the 
DESCRIBE answer will be used.
-  A client should preferable send blocksize in their DESCRIBE request 
so that a server can modify the value before responding with the SDP.
- In cases when a blocksize is sent with a SETUP request the 
corresponding packet rate needs to be communicated to the client.

I don't think a mandatory maximum blocksize header is useful. The actual 
size of packets sent will be variable and given an upper limit does not 
enable one to calculate the maximum packet rate, rather a minimal packet 
rate. Many codecs actually has easier to calculate a maximum packet rate 
than giving a number on the bit rate. Audio codecs know the maximum 
number of frames they produce each second, and they can give good 
estimates of how many packets each frame will result in. Also 
packetization options like number of frames can easily be taken into 
account. For video codecs the frame rate gives a good starting point and 
the quality and sequence will determine how many packets will be needed 
for each frame. So if we are going to add a RTSP header, a packet rate 
header seems much more useful.

One question I have been asking is it sufficient with a single packet 
rate attribute? The current definition of prate specifies it as a 
maximum. This allows one to calculate the actual maximum bit rate. This 
is seems correct with the TIAS modifier that also is an maximum. But are 
there any need for an average bandwidth specifier?

Best Regards

Magnus

-- 

Magnus Westerlund