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

From: [email-masked]
Date: Wed, 9 Oct 2002 14:40:38 +0300

Hi Magnus,
Please find comment inlined:

> -----Original Message-----
> From: ext Magnus Westerlund [mailto:[email-masked]]
> Sent: 09. October 2002 13:25
> To: Aksu Emre (NMP/Tampere); [email-masked]
> Subject: Re: [MMUSIC] Presenting
> draft-westerlund-mmusic-sdp-bwparam-00.txt
> 
> 
> Hi Emre,
> 
> See comments below:
> 
> [email-masked] wrote:
> 
> >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. 
> >
> 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. 
> 

So, does this mean that the SDP line-order structure be changed? Because currently there can be only one "b=" in session level and/or media level. This made me think whether it would be better to define this new bandwidth modifiers as new SDP attribute, which can override the meaning of "b=" field. What do you think?

BR
Emre

> >
> >- 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 transport protocols with different 
> header sizes introduced in the future.
> >
> Yes, I agree and will update my proposal to only include the payload 
> bandwidth.
> 
> 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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 09 Oct 2002 14:25:05 +0200

Hi Emre,

See comments below.

>So, does this mean that the SDP line-order structure be changed? Because currently there can be only one "b=" in session level and/or media level. This made me think whether it would be better to de…
There can be several b= lines as long as they are next to each other. If 
you look at the BNF from draft-ietf-mmusic-sdp-new-10.txt or RFC 2326 
you see this:
bandwidth-fields =    *("b=" bwtype ":" bandwidth CRLF)
Which means that 0 to an infinite number of b= lines are allowed both on 
session and media level. I absolutely think that we should use the b= 
with an appropriate new modifier.

Regards

Magnus Westerlund