Subject: [MMUSIC] RTP bandwidth for multiple media streams

From: Belling Thomas <[email-masked]>
Date: Mon, 16 Jun 2003 17:20:15 +0200

Hy Everybody,

as suggested by Colin, I put my question on the mailing list.
Comments are more then welcome.
Is there an agreement to update the sdp-new draft according
to Colin´s and my own interpretation?

Cheers, Thomas

----------
From: Colin Perkins [mailto:[email-masked]]

Thomas,

The spec is not clear, but I think I agree with your interpretation. I
would suggest you also ask this question on the [email-masked] mailing
list, so we can be sure there is consensus (and update the draft if
necessary).

cheers,
Colin

--> Belling Thomas <[email-masked]> writes:
> Dear Mr. Handley, Mr. Jakobson, and Mr. Perkins,
> 
> I wanted to ask you as the authors of the SDP new draft for your
> interpretation of a problem we a currently discussing within 3GPP (The 3
> Generation Parnership Project standardizing mobile GSM and UMTS
> networks).
> 
> Consider the following SDP:
> 
> c=IN IP4 224.2.1.1/127/2
> m=video 49170/2 RTP/AVP 31 
> b=AS:64
> 
> My problem: How much bandwidth is associated with this "m=" line -
> 64kbits or 128kbits?
> 
> In the draft, you state that "b=AS" is similar to the RTP "session
> bandwidth", as defined in RFC 1889. Consulting this RFC, I got stuck with
> the definition of the "RTP Session". Consulting the definition in the RTP
> new draft instead seems to suggest that the "m=" line describes two RTP
> sessions. Therefore it seems that 128kbits may be the correct answer. Do
> you agree with my interpretation?
> 
> Clarity on this point is quite important for 3GPP, as the derived
> bandwidth will be granted at the air interface, which is a scarce
> resource where a factor of two makes a lot of difference.
> 
> Best Regards and thank you very much for your help
> 
> Th Belling
> 
> 
> ----------------------------------
> Dr. Thomas Belling
> Siemens AG           
> Sankt-Martinsstr. 76 
> D-81542 München Germany
> ICM N PG SP ST N1
> MCH M 34 307
> Tel     +49 89 636 75207
> Fax     +49 89 636 75577
> Mobile  +49 172 2974678
> Email   [email-masked]
> 
> 
> 
> 

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 23 Jun 2003 09:27:13 +0200

Hi,

I would agree with the interpretation, at least when it comes to b=AS as 
it clearly specifies that this is the RTP session bandwidth. When one 
uses a m= line with port/2 it becomes two RTP sessions. However I am not 
certain over how one should in this case interpret any of the other 
bandwidth attributes.

The available bandwidth modifiers are:
CT
RR
RS

Lets look at them:

CT is defined in draft-ietf-mmusic-sdp-new-12 as:
         CT  Conference Total
             If the bandwidth of a session or media in a session is
             different from the bandwidth implicit from the scope, a
             "b=CT:..." line should be supplied for the session giving
             the proposed upper limit to the bandwidth used.  The primary
             purpose of this is to give an approximate idea as to whether
             two or more sessions can co-exist simultaneously.

Based on this I would interpret that a given CT value should be for the 
complete media, i.e. counting the total of both RTP sessions.

When it comes to RR and RS I think they can also be interpreted on a per 
RTP session level. I base this on the fundamental definition of these 
attributes.

 From draft-ietf-avt-rtcp-bw-05:
This memo defines two additional bandwidth modifiers:

      b=RS:<bandwidth-value>

      b=RR:<bandwidth-value>

where "RS" indicates the RTCP bandwidth allocated to active data senders
(as defined by the RTP spec) and "RR" indicates the RTCP bandwidth
allocated to other participants in the RTP session (i.e., receivers).

When it concerns TIAS I will do the same interpretation that the 
bandwidth value apply per RTP session.

My concern is that this simplistic model is probably not what you would 
like if you would actually use this functionality. If one uses multiple 
RTP sessions for a single media you are probably doing some form of 
scalability, etc., and would like to specify the values independently 
per RTP session. Fortunately there exist today alternatives to achieve 
this behaviour today. With the help of grouping of media lines it is 
possible to specify that several m= lines are part of the same media. 
Using FID there is only a pitfall with the following sentence:
"A media agent handling a media flow that comprises several "m"
    lines MUST send a copy of the media to every "m" line part of the
    flow as long as the codecs and the direction attribute present in a
    particular "m" line allow it."

If that is a problem it might be easier to define a new grouping 
attribute for that situation.

Finally I have a question to the group, has anyone seen that "m= port/2 
..." ever been used. And in that case how.

Best Regards

Magnus

-- 

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]