Subject: [MMUSIC] RTP bandwidth for multiple media streams

From: Belling Thomas <[email-masked]>
Date: Mon, 16 Jun 2003 11:17:52 +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: Belling Thomas <[email-masked]>
Date: Wed, 25 Jun 2003 11:23:39 +0200

Hi Magnus,

I could also agree with removing "m= port/2 ", if nobody uses it.
Obviously, that would also remove the ambiguities with the bandwidth modifiers that are the cause of my concerns.

Thomas

-----Ursprüngliche Nachricht-----
Von: Magnus Westerlund [mailto:[email-masked]]
Gesendet: Mittwoch, 25. Juni 2003 09:52
An: Belling Thomas
Cc: [email-masked]'
Betreff: Re: AW: [MMUSIC] RTP bandwidth for multiple media streams

Hi Thomas,

Even more inline:

Belling Thomas wrote:
> Hi Magnus,
> 
> My answers are inline
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Magnus Westerlund [mailto:[email-masked]]
> Gesendet: Montag, 23. Juni 2003 09:27
> An: Belling Thomas
> Cc: [email-masked]'
> Betreff: Re: [MMUSIC] RTP bandwidth for multiple media streams
> 
> 
> 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.
> 
> [Thomas] Fine, but is that 100 Percent clear from the wording of the RFCs and draft-ietf-mmusic-sdp-new-12? It would prefere a clarification there

Yes, this should probably be clarified. I don't think it is obvious.

> 
> 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.
> 
> [Thomas] I agree that this is an interpretation in line with my understanding of the intentions of the CT bandwidth modifier. However, the wording is not so clear. What is a "session"? If you understand "RTP session", this would contradict your interpretation. As an aside: 3GPP ignores this parameter, so from that perspective a clarification is less urgent than for the AS modifier.

Yes, the session in the quote is a bit unclear. I think it is a larger 
session concept, like the complete streaming session, or probably when 
it was written the conferencing session with all the media included. On 
media level the text indicates the complete media, which in this case is 
transported over several RTP sessions. So based on these two 
interpretations I arrive at my conclusion.

> When it concerns TIAS I will do the same interpretation that the 
> bandwidth value apply per RTP session.
> 
> [Thomas] Makes sense if you take TIAS as a kind of refinement of the AS modifier. I did not yet read the draft with that question in mind, and the draft is still in a stage where this can be clarified.

Yes, it can still be modified. I have made an update and I did not 
address the issue. The reason being is that I think the SDP draft should 
  first address this. Based on this clarification I would add to the 
TIAS draft if necessary.

> 
> 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.
> 
> [Thomas] Take the simple example of stereo sound. Why not use the "m= port/2 " notification for that? Something in that direction might have been the original motification. From a 3GPP perspective, where this relates to thev bandwidth on the air and possibly the rate charged for a service, we should have a clear understanding as this possibility exists and might also be misused otherwise.

I don't think stereo is a good example. First reason is that you 
normally don't split left and right channel into different packets, 
unless they are really big, reasons are like synchronization. Therefore 
most audio codecs are possible to transport over RTP using a single 
source. The sample based codec normally only specify that every other 
sample is left  and the other are right. Frame based codec normally have 
more advanced schemes where they encode left and right together to take 
advantage of the similarities between channels.

My thinking is actually along the lines, if no one uses it, why not 
remove it, we will still have to if no implementations are identified 
when going to draft standard.

Best Regards

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]