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

From: "Lior Sion" <[email-masked]>
Date: Wed, 16 Oct 2002 08:43:58 +0200

comments inline

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]]
Sent: Thursday, October 10, 2002 2:07 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [MMUSIC] Presenting draft-westerlund-mmusic-sdp-bwparam-00.txt

Hi Igor,

Thanks for the comments, see my comments below:

[email-masked] wrote:

>Hi,
>
>two comments on the draft:
>- The computation of the h-size value in section 6.3 should be in Kbps. This is currently not specified.
Yes, I can add such a clarification.

Again, i would like to raise this issue. I know that the original RFC stated that b= fields should be in Kbps, yet in real life, especially on slow and somewhat slow links, we've seen again and again that a more accurate way is needed. I don't see why we shouldn't make this bps.

Another issue that is still not closed is the bit rate issue. What is bit rate - what exactly does it include? media, media + transport headers (RTP), + RTCP as well, + ip as well?
Until we define this, we can't go on defining packet rate, since packet rate is influenced by this.

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 09:24:27 +0200

Hi Lior,

Comments below:

>Again, i would like to raise this issue. I know that the original RFC stated that b= fields should be in Kbps, yet in real life, especially on slow and somewhat slow links, we've seen again and agai…

As I explained in an earlier mail this field is defined as kbps in 
RFC2327 and draft-ietf-mmusic-sdp-new. I can agree that it may be an 
advantage to have the values in bps instead. But I don't want to break a 
definition. However what you propose has been done for the bandwidth 
modifiers RR and RS. And from a parser point of view such a change does 
not effect it. It is the layer that uses the value that needs to take 
care and have different interpretations depending on which modifier it 
is. So I would like some WG chair feedback on this, is it okay?

>Until we define this, we can't go on defining packet rate, since packet rate is influenced by this.

I think that the definition of TIAS is rather clear that it only 
contains media payload and RTP headers in the case of RTP transport. In 
cases when RTP is not used, the bitrate is without transport and IP 
overhead. Thanks to feedback I got here I will change the definition to 
only be media/payload bitrate as it will be a better base for calculation.

I don't see how the actual definition of the bitrate modifier effects 
the definition of the packet rate attribute. I agree that when applied 
the actual value entered will depend on what packetization that will be 
used. But that is true independent if we count IP or not in the TIAS value.

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]

---

From: Colin Perkins <[email-masked]>
Date: Wed, 16 Oct 2002 11:55:05 -0400

--> Magnus Westerlund writes:
>Hi Lior,
>
>Comments below:
>
>Lior Sion wrote:
>
>>Again, i would like to raise this issue. I know that the original RFC
>>stated that b= fields shoul d be in Kbps, yet in real life, especially 
>>on slow and somewhat slow links, we've seen again and a gain that a more
>>accurate way is needed. I don't see why we shouldn't make this bps.
>>
>

I have no objections to using bps, so long as it is clearly documented.

Colin