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

From: Belling Thomas <[email-masked]>
Date: Fri, 27 Jun 2003 16:18:21 +0200

Dear Colin

I would like to suggest the following additions to the SDP new draft
(denoted by ">>> <<<")

Alternatively, removing the <number of ports> and the corresponding explanations from page 19f is acceptable to me, if nobody has concerns with respect to the backward compatibility.

Thanks, Thomas

On page 13f:

   Bandwidth

      b=<modifier>:<bandwidth-value>

...

      Two modifiers are initially defined:

        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.
>>>         For RTP, if several RTP sessions are part of the conference,
            the conference total refers to total bandwidth of all RTP sessions. <<<

        AS  Application-Specific Maximum
            The bandwidth is interpreted to be application-specific (it
            will be the application's concept of maximum bandwidth).
            Normally this will coincide with what is set on the
            application's "maximum bandwidth" control if applicable.
            For RTP based applications, AS gives the RTP "session
            bandwidth" as defined in section 6.2 of [RFC1889].

      Note that CT gives a total bandwidth figure for all the media at
      all sites.  AS gives a bandwidth figure for a single media at a
      single site, although there may be many sites sending
      simultaneously.

On page 19f:

   Media Announcements

      m=<media> <port> <transport> <fmt list>

      ...

      The second sub-field is the transport port to which the media
      stream is sent. The meaning of the transport port depends on the
      network being used as specified in the relevant "c=" field, and on
      the transport protocol defined in the third sub-field.  Other
      ports used by the media application (such as the RTCP port
      [RFC1889]) MAY be derived algorithmically from the base media port
      or MAY be specified in a separate attribute (e.g. "a=rtcp:" as
      defined in [RTCPSDP]).

      For applications where hierarchically encoded streams are being
      sent to a unicast address, it may be necessary to specify multiple
      transport ports.  This is done using a similar notation to that
      used for IP multicast addresses in the "c=" field:

         m=<media> <port>/<number of ports> <transport> <fmt list>

      In such a case, the ports used depend on the transport protocol.
      For RTP, the default is that only the even numbered ports are used
      for data and the corresponding one-higher odd port is used for
>>>   RTCP >>> belonging to this RTP session, and the <number of ports> denotes the number of RTP sessions<<<.  For example:

         m=video 49170/2 RTP/AVP 31

      would specify that ports 49170 and 49171 form one RTP/RTCP pair
      and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the
      transport protocol and 31 is the format (see below). If non-
      contiguous ports are required, they must be signalled using a
      separate attribute (e.g. "a=rtcp:" as defined in [RTCPSDP])
      ...

-----Ursprüngliche Nachricht-----
Von: Colin Perkins [mailto:[email-masked]]
Gesendet: Mittwoch, 25. Juni 2003 19:03
An: Magnus Westerlund
Cc: [email-masked]; [email-masked]
Betreff: Re: AW: [MMUSIC] RTP bandwidth for multiple media streams

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

-- 
Colin Perkins
[email-masked]

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

---

From: Colin Perkins <[email-masked]>
Date: Wed, 16 Jul 2003 09:57:44 +0200

Thanks. These changes look reasonable: comments from the group?
Colin

--> Belling Thomas <[email-masked]> writes:
> Alternatively, removing the <number of ports> and the corresponding
> explanations from page 19f is acceptable to me, if nobody has concerns
> with respect to the backward compatibility.
> 
> Thanks, Thomas
> 
> 
> 
> On page 13f:
> 
>    Bandwidth
> 
> >>>   RTCP >>> belonging to this RTP session, and the <number of ports>
> >denotes the number of RTP sessions<<<.  For example:
> 
> > > RFCs and draft-ietf-mmusic-sdp-new-12? It would prefere a
> > > clarification there
> > 
> > >              "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.
> > > 
> > > 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.
> > 
> > media level the text indicates the complete media, which in this case
> > is transported over several RTP sessions. So based on these two 
> > > [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.
> > 
> > > 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"
> > >     flow as long as the codecs and the direction attribute present in
> > >     a particular "m" line allow it."
> > > 
> > > Finally I have a question to the group, has anyone seen that "m=
> > > port/2..." ever been used. And in that case how.
> > > 
> > > 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.
> > 
> > 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]