Subject: Re: AW: [MMUSIC] RTP bandwidth for multiple media streams

From: Tom Taylor <[email-masked]>
Date: Wed, 25 Jun 2003 11:54:45 -0400

Speaking of implementations and moving to draft standard: I have had absolutely no 
reports and no substantive comments on my interoperability report draft.

Magnus Westerlund wrote:

[snip]

> 
> 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]
> 
> 
> _______________________________________________
> 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: Colin Perkins <[email-masked]>
Date: Wed, 25 Jun 2003 13:02:44 -0400

Can you suggest explicit wording changes to clarify the draft? There is
probably still time to incorporate minor edits for clarification.

Colin

--> Magnus
Westerlund<[email-masked]> writes:
> 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.
> 

-- 
Colin Perkins
[email-masked]

---

From: Belling Thomas <[email-masked]>
Date: Wed, 25 Jun 2003 09:31:56 +0200

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

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.

[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.

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).

[Thomas] Agreement, those parameters are closely linked to the algothimns to control the RTCP bandwidth and thus make sense only for a single 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.

[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.

Best Regards

Magnus

Belling Thomas wrote:
>>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?
>>

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research ERA/TVA/A

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 25 Jun 2003 09:51:37 +0200

Hi Thomas,

Even more inline:

Best Regards

Magnus Westerlund