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

From: [email-masked]
Date: Wed, 9 Oct 2002 11:02:53 +0300

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 09 Oct 2002 12:24:54 +0200

Hi Emre,

See comments below:

>- 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…
The presence of b=TIAS does not outrule the presence of b=AS. It is 
possible to have both as they have different meaning and unfortunatly I 
think it will be requried to have both for certain applications due to 
backwards compatibility. My intention is however that if TIAS is present 
and understood that value should be used. The use of RR and RS is 
dependening if AS or TIAS is used. I will update the draft with text 
specifying this. 

>- If b=TIAS is present in an SDP description, then there MUST be a=prate in the attribute list of the media components, right?
At least for all applications using RTP transport. I don't think it is 
necessary when SDP is used in store and forward applciations where the 
application basically is intressted in the media bitrate.

>- 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…
Yes, I agree and will update my proposal to only include the payload 
bandwidth.

Regards

Magnus Westerlund