Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE3E1B2BBE for ; Wed, 29 Jul 2015 14:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQAJbxRtdTYU for ; Wed, 29 Jul 2015 14:52:39 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFCD81B2BE0 for ; Wed, 29 Jul 2015 14:52:37 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so176028002igb.0 for ; Wed, 29 Jul 2015 14:52:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=pw2NZ3g/gVrLQFyK3gHn8vnes6DQS6Bb53FAbk097RE=; b=zxEQ9YQ8JZspcNcTjFrK1ld+CbDbgrnADNSXVn+QFhC7gzcngqsmk4jjHB28+ru7cp pt6xrp9RyGehm2+SZGqcoHrcVaf9tPtPuaNSsUEQALkXmokcEXISt5u3yiuvCqXyBhPm 1eUaRHmSUpQ0ZqCzmNz4XBq+EBHNN3nqYJXc6BRxZ8zAGUyYPzGZn65EVSXB5CjKr7FQ No+7DHh7U3oieCsbptyOmzyK2VIrSXO06prrkZngqJVBRhnh78biEpA5j+s6M/t5Rj9m bRZUaqh1GmCtkUaRttGT4vIPKxX2Vc17Os/qZVK2YPX+ey5S/siqZrzyLBR1OOb4e9Ha wEsg== MIME-Version: 1.0 X-Received: by 10.50.124.1 with SMTP id me1mr1300361igb.83.1438206757372; Wed, 29 Jul 2015 14:52:37 -0700 (PDT) Received: by 10.64.233.4 with HTTP; Wed, 29 Jul 2015 14:52:37 -0700 (PDT) Date: Wed, 29 Jul 2015 16:52:37 -0500 Message-ID: From: Imed Bouazizi To: avt@ietf.org Content-Type: multipart/alternative; boundary=089e01182722e30aad051c0a9ad0 Archived-At: Subject: Re: [AVTCORE] [payload] MMTP vs RTP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 21:52:48 -0000 --089e01182722e30aad051c0a9ad0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear All, Sorry to jump in late as I was not subscribed to this group. Indeed, the idea is that we want to develop the enablers for an All IP system that supports the advanced media consumption use cases we are looking at. The ISOBMFF as a container is the common part so far, but we don=E2=80=99t want= to exclude other container formats in the future. In MMTP, those can be added as new payload types but we still want to keep the number of payload types to a minimum. During the discussion, we agreed that we will provide documents that set the framework for this work (use cases, requirements, ...) I appreciate this interest and hope that people can join in in the next meeting, where we will organize a BoF to discuss this topic. PS: we are not trying to replace RTP and believe that for real-time communication RTP will prevail. Br, Imed All, Thank you for the bit of background. I agree that convergence to a non-prorprietary solution that does the job is a very good thing! I just wanting to provide the background of how we got to where we are now to ensure that whatever new transport that is created overcomes the shortcomings of the past with respect to transport of MPEG based media. If MPEG-DASH provides relief from many of the issues we had in the past and the broadcasters and multicasters are embracing an all IP delivery model, then this is huge progress since the time we developed RTP and the companion payload specifications. Cheers, Michael > On Jul 29, 2015, at 6:52 AM, Bill Ver Steeg (versteb) wrote: > > I have seen lots of activity in the MPEG DASH space in this context. As many you know, the world is converging on delivery of adaptive bitrate video using HTTP Adaptive Streaming. There are lots of proprietary methods, but there seems to be a general consensus that MPEG DASH is the eventual convergence point. This, IMHO, is a very good thing. > > So, the video broadcast world is noticing this, and trying to skate to where the puck is going. They are all moving to get rid of their naked MPEG2TS video flows and move to an "all IP" delivery model. The various broadcasters/multicasters (SCTE, ATSC, CableLabs, DVB, etc) are embracing the delivery of chunked MPEG DASH video over their deliver networks. If there is enough commonality between the various delivery methods, a lot of very interesting functionality is enabled. The most obvious revolve around several devices watching an event and getting there streams from various paths. You can also envision hybrid error recovery, the use of more than one network to deliver a single stream, various DVR/CDN schemes, etc. > > By having a convergence point at the "video chunk" layer, you get a lot of what you need. Once this is in place, it would be really nice to have a common way to deliver these chunks. In the unicast world, that is HTTP. It works great, and we see the uptake. As the broadcasters embrace this technology, they recognize the need for a multicast/broadcast friendly transport that would provide the baseline interoperability between the new "all IP" video delivery model and the HTTP based methods. > > Obviously, the way to do the design is to have a general purpose way to deliver objects over several types of networks, and consider MPEG DASH chunks as one type of object. We do not want to design an MPEG-DASH specific solution, but would design a general purpose system that was suitable for delivering objects that look a lot like DASH chunks. > > This is where the IETF comes in. IMHO, the expertise to tackle this problem lives at the IETF. The other SDOs are currently going down their own paths here, and are starting to recognize the merits of a common transport layer. Without discussing the relative merits of RTP/MMPT/FLUTE/MMT/ROUTE/whatever, I think it is important to have the IETF take this work up and "do the right thing". Once we get the right folks engaged with the right charter, I think we can come up with a design that satisfies the requirements and allows the convergence that is required to make the most compelling use cases practical. > > Bill VerSteeg > > > -----Original Message----- > From: avt [mailto:avt-bounces@ietf.org] On Behalf Of Gorry Fairhurst > Sent: Wednesday, July 29, 2015 5:02 AM > To: Michael Speer > Cc: payload@ietf.org; Thomas Edwards; avt@ietf.org > Subject: Re: [AVTCORE] [payload] MMTP vs RTP > > I can offer a little context here (but not the presenter): > > A proposal was received to the TSV Area that asked if the IETF would be able to work on transport methods for the new MMT specification. This IETF meeting we had a very short "heads up" presentation in the TSV-Area meeting in Prague to open this discussion (see proceedings). > > I udnerstand the first version of the MMT specs had been published, together with considerations about how to transmit this directly over broadcast TV multiplexes. Thought had also been given on how to go beyond the MPEG-2 Transport Stream concepts to provide much more flexible packetisation and multiplexing, and to target IP networks - they also want to work with hybird networks that combine multiple delivery methods. > > The presentation I saw at the IETF suggested this work was open to IETF inputs - expecting methods for real-time delivery and a carousel-based reliable transport framework. Although there are Specs, and RTP was already evaluated and found to not be directly suitable, I heard that there is a hope to define the new methods within the IETF. I can't speak for all involved, I'm currently only watching what goes on, but I think this may be a case of not bringing a transport spec to the IETF, but more of bringing a multimedia architecture and asking how to transport it. It's early stages. > > Gorry > (TSVWG Co-Chair) > > On 28/07/2015 23:40, Michael Speer wrote: >> All, >> >> I agree with you that it=E2=80=99s not clear if MMT is a good candidate = to replace all uses of RTP. When we worked on MPEG-TS Payload format >> years ago, there where a number of challenges including the fact MPEG-TS was not really suited to packet networks such as IP. My >> main question is whether MMT overcomes many of packetization issues we dealt with at the time. RTP does quite well for a variety >> of applications as we all know, so let=E2=80=99s be careful about use of= the words replace. For MPEG streams, it may well be the case, this >> improves the situation for some applications. >> >> The relevant combination of RFCs are to provide context are RFC 3360, >> RFC 2250, RFC 5691 and RFC 3640. The last three RFCs provide MPEG packetization history. >> >> Cheers, >> Michael >> >> >>> On Jul 28, 2015, at 12:00 PM, Thomas Edwards wrote: >>> >>> I will add that MMT is under study by the ATSC TG3/S33 "Specialist Group on Management and Protocols" to be a transport in the ATSC 3.0 digital broadcast television standard. >>> >>> It is not yet clear to me if MMT is a good candidate to replace all uses of RTP, but it certainly appears to be a good candidate to replace the use of MPEG Transport Streams for delivery of completed linear content over IP systems. >>> >>> -Thomas >>> >>> -- >>> Thomas Edwards >>> VP Engineering& Development >>> FOX Networks Engineering and Operations thomas.edwards@fox.com >>> Phone: +1.310.369.6696 >>> 10201 West Pico Blvd. >>> Los Angeles, CA 90035 >>> >>> >>> From: "Mo Zanaty (mzanaty)" >>> Date: Tuesday, July 28, 2015 at 11:22 AM >>> To: Michael Speer >>> Cc: "gorry@erg.abdn.ac.uk", >>> "avt@ietf.org", "payload@ietf.org" >>> Subject: Re: [payload] [AVTCORE] MMTP vs RTP >>> >>> This is not my work. I just became aware of it in the last meeting. This work would replace RTP itself (RFC 3550) and all RTP payload formats (many specs, e.g. RFC 6184 for H.264). The MMT payload format would be the elementary stream as defined by the codec spec for storage in ISOBMFF containers, augmented with MMT specs and features such as generic packetization / fragmentation. >>> >>> Mo >>> >>> >>> On 7/28/15, 2:05 PM, Michael Speer wrote: >>> >>> Mo, >>> >>> Hi, can you post the RFCs you trying to replace? In particular, what >>> RTP payload specification are you trying to replace? >>> >>> Cheers, >>> Michael >>> >>> >>> On Tue, Jul 28, 2015 at 9:15 AM, Mo Zanaty (mzanaty) wrote: >>>> I assumed TSVAREA was already aware of this since it was presented >>>> there and will be in their notes. I wanted to bring this to the >>>> attention of RTP folks that may be interested but probably missed >>>> this. If there are any replies here that may be useful for TSV, I >>>> will forward. I try to avoid cross-posting to lists with significantly different topics and subscribers. >>>> >>>> Mo >>>> >>>> On 7/28/15, 12:05 PM, Ali C. Begen (abegen) wrote: >>>> Is not this thread supposed to cc the transport area, too? >>>> >>>> -----Original Message----- >>>> From: avt on behalf of "Mo Zanaty (mzanaty)" >>>> Date: Tuesday, July 28, 2015 at 7:02 PM >>>> To: "avt@ietf.org", "payload@ietf.org" >>>> Cc: "gorry@erg.abdn.ac.uk" >>>> Subject: [AVTCORE] MMTP vs RTP >>>> >>>>> MMTP (MPEG Media Transport Protocol) aims to replace RTP and MPEG-2 >>>>> TS for media streaming applications, both real-time and >>>>> non-real-time. It integrates FEC, buffering, congestion control and >>>>> other functions. It was presented in TSVAREA in IETF 93. See below >>>>> for the slides and draft. >>>>> https://www.ietf.org/proceedings/93/slides/slides-93-tsvarea-1.pdf >>>>> https://tools.ietf.org/html/draft-bouazizi-tsvwg-mmtp >>>>> >>>>> I found slides 5 and 15 particularly relevant for AVT folks, so >>>>> inlining them. >>>>> >>>>> Why not RTP? (slide 5) >>>>> - Lack of Multiplexing >>>>> - One media session per component and without RTP multiplexing, 2 >>>>> ports per session >>>>> - Server Maintenance >>>>> - RTP Payload Format for every new media codec >>>>> - Support needs to be added to the media server >>>>> - Coupling of Presentation and Delivery >>>>> - RTP carries presentation and synchronization information at the >>>>> transport level >>>>> - Limited support for Non-Real Time Media >>>>> - Presentations consist of timed and non-timed media >>>>> - Need other protocol or countless number of payload formats to >>>>> support NRT >>>>> >>>>> Why are we here? (slide 15) >>>>> - We want to develop MMTP further in the IETF >>>>> - We want to address the Internet (unicast and Multicast) >>>>> - We want to reuse existing components such as congestion control >>>>> and security >>>>> - A protocol is needed by many SDOs: MPEG, ATSC, 3GPP, DVB, ... >>>>> - Can we revive rmt? >>>>> - Can we start a BoF or a new ad-hoc group? >>>>> - Or can we do an informational RFC? >>>>> >>>>> I think there should be some dialogue on RTP evolution with the >>>>> MMTP folks. Some interesting points are raised in this work, such >>>>> as generic packetization vs. specific RTP payload formats. Perhaps >>>>> a generic payload draft can address this generic packetization >>>>> (i.e. fragmentation and perhaps aggregation) in the absence of a >>>>> specific RTP payload format for the elementary media stream. >>>>> >>>>> Thanks to Gorry for bringing this to my attention. >>>>> >>>>> Mo >>>> _______________________________________________ >>>> Audio/Video Transport Core Maintenance avt@ietf.org >>>> https://www.ietf.org/mailman/listinfo/avt > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --089e01182722e30aad051c0a9ad0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Dear All,<= /p>

=C2=A0

Sorry to jump in late as I was not= subscribed to this group. Indeed, the idea is that we want to develop the enablers for an= All IP system that supports the advanced media consumption use cases we are loo= king at. The ISOBMFF as a container is the common part so far, but we don=E2=80= =99t want to exclude other container formats in the future. In MMTP, those can be added = as new payload types but we still want to keep the number of payload types to = a minimum. During the discussion, we agreed that we will provide documents th= at set the framework for this work (use cases, requirements, ...)

I appreciate this interest and hop= e that people can join in in the next meeting, where we will organize a BoF to discuss this topic.

=C2=A0

PS: we are not trying to replace R= TP and believe that for real-time communication RTP will prevail.

=C2=A0

Br,

Imed

=C2=A0

=C2=A0

=C2=A0

=C2=A0

All,

=C2=A0

Thank you for the bit of backgroun= d.=C2=A0=C2=A0 I agree that convergence to a non-prorprietary solution that does the job is a

very good thing! I just wanting to= provide the background of how we got to where we are now to ensure that whatever=

new transport that is created over= comes the shortcomings of the past with respect to transport of MPEG based media.

If MPEG-DASH provides relief from = many of the issues we had in the past and the broadcasters and multicasters

are embracing an all IP delivery m= odel, then this is huge progress since the time we developed RTP and the companion

payload specifications.

=C2=A0

Cheers,

Michael

=C2=A0

> On Jul 29, 2015, at 6:52 AM, = Bill Ver Steeg (versteb) <versteb@cisco.com>= ; wrote:

>

> I have seen lots of activity = in the MPEG DASH space in this context. As many you know, the world is converging on deliver= y of adaptive bitrate video using HTTP Adaptive Streaming. There are lots of proprietary methods, but there seems to be a general consensus that MPEG DA= SH is the eventual convergence point. This, IMHO, is a very good thing.=

>

> So, the video broadcast world= is noticing this, and trying to skate to where the puck is going. They are all moving to get = rid of their naked MPEG2TS video flows and move to an "all IP" delive= ry model. The various broadcasters/multicasters (SCTE, ATSC, CableLabs, DVB, e= tc) are embracing the delivery of chunked MPEG DASH video over their deliver networks. If there is enough commonality between the various delivery metho= ds, a lot of very interesting functionality is enabled. The most obvious revolv= e around several devices watching an event and getting there streams from var= ious paths. You can also envision hybrid error recovery, the use of more than on= e network to deliver a single stream, various DVR/CDN schemes, etc.

>

> By having a convergence point= at the "video chunk" layer, you get a lot of what you need. Once this is= in place, it would be really nice to have a common way to deliver these chunks= . In the unicast world, that is HTTP. It works great, and we see the uptake. As = the broadcasters embrace this technology, they recognize the need for a multicast/broadcast friendly transport that would provide the baseline interoperability between the new "all IP" video delivery model an= d the HTTP based methods.

>

> Obviously, the way to do the = design is to have a general purpose way to deliver objects over several types of networks, an= d consider MPEG DASH chunks as one type of object. We do not want to design a= n MPEG-DASH specific solution, but would design a general purpose system that= was suitable for delivering objects that look a lot like DASH chunks.

>

> This is where the IETF comes = in. IMHO, the expertise to tackle this problem lives at the IETF. The other SDOs are currently going down their own paths here, and are starting to recognize th= e merits of a common transport layer. Without discussing the relative merits = of RTP/MMPT/FLUTE/MMT/ROUTE/whatever, I think it is important to have the IETF take this work up and "do the right thing". Once we get the right folks engaged with the right charter, I think we can come up with a design = that satisfies the requirements and allows the convergence that is required to m= ake the most compelling use cases practical.

>

> Bill VerSteeg

>

>

> -----Original Message-----

> From: avt [mailto:avt-bounces@ietf.org] On Behalf Of Gorry Fairhurst

> Sent: Wednesday, July 29, 201= 5 5:02 AM

> To: Michael Speer

> Cc: payload@ietf.org; Thomas Edwards; avt@ietf.org

> Subject: Re: [AVTCORE] [paylo= ad] MMTP vs RTP

>

> I can offer a little context = here (but not the presenter):

>

> A proposal was received to th= e TSV Area that asked if the IETF would be able to work on transport methods for the new MM= T specification. This IETF meeting we had a very short "heads up" presentation in the TSV-Area meeting in Prague to open this discussion (see proceedings).

>

> I udnerstand the first versio= n of the MMT specs had been published, together with considerations about how to transmit this directly over broadcast TV multiplexes. Thought had also been given on how = to go beyond the MPEG-2 Transport Stream concepts to provide much more flexibl= e packetisation and multiplexing, and to target IP networks - they also want = to work with hybird networks that combine multiple delivery methods.

>

> The presentation I saw at the= IETF suggested this work was open to IETF inputs - expecting methods for real-time deliver= y and a carousel-based reliable transport framework. Although there are Specs= , and RTP was already evaluated and found to not be directly suitable, I hear= d that there is a hope to define the new methods within the IETF. I can't= speak for all involved, I'm currently only watching what goes on, but I think= this may be a case of not bringing a transport spec to the IETF, but more of bringing a multimedia architecture and asking how to transport it. It's= early stages.

>

> Gorry

> (TSVWG Co-Chair)

>

> On 28/07/2015 23:40, Michael = Speer wrote:

>> All,

>>

>> I agree with you that it= =E2=80=99s not clear if MMT is a good candidate to replace all uses of RTP. When we worked on MPEG-TS Payload format

>> years ago, there where a = number of challenges including the fact MPEG-TS was not really suited to packet netwo= rks such as IP.=C2=A0=C2=A0 My

>> main question is whether = MMT overcomes many of packetization issues we dealt with at the time.=C2=A0 RTP does quite wel= l for a variety

>> of applications as we all= know, so let=E2=80=99s be careful about use of the words replace.=C2=A0=C2=A0 For MPEG streams, it may well be the case, this

>> improves the situation fo= r some applications.

>>

>> The relevant combination = of RFCs are to provide context are RFC 3360,

>> RFC 2250, RFC 5691 and RF= C 3640.=C2=A0 The last three RFCs provide MPEG packetization history.

>>

>> Cheers,

>> Michael

>>

>>

>>> On Jul 28, 2015, at 1= 2:00 PM, Thomas Edwards<Thomas.Edwards@fox.com= >=C2=A0 wrote:

>>>

>>> I will add that MMT i= s under study by the ATSC TG3/S33 "Specialist Group on Management and Protocols" t= o be a transport in the ATSC 3.0 digital broadcast television standard.

>>>

>>> It is not yet clear t= o me if MMT is a good candidate to replace all uses of RTP, but it certainly appears to be a good candidate to replace the use of MPEG Transport Streams for delivery of completed linear content over IP systems.

>>>

>>> -Thomas

>>>

>>> --

>>> Thomas Edwards=

>>> VP Engineering&= =C2=A0 Development

>>> FOX Networks Engineer= ing and Operations thomas.edwards@fox.com=

>>> Phone: +1.310.369.669= 6

>>> 10201 West Pico Blvd.=

>>> Los Angeles, CA 90035=

>>>

>>>

>>> From: "Mo Zanaty (mzanaty)"<mzanaty@cisco.com>

>>> Date: Tuesday, July 2= 8, 2015 at 11:22 AM

>>> To: Michael Speer<= michael.speer@pluribu= snetworks.com>

>>> Cc: "gorry@erg.abdn.ac.uk"= ;<gorry@erg.abdn.ac.uk>, =

>>> "avt@ietf.org"<avt@ietf.org>, "payload@ietf.org"<payload@ietf.org>

>>> Subject: Re: [payload= ] [AVTCORE] MMTP vs RTP

>>>

>>> This is not my work. = I just became aware of it in the last meeting. This work would replace RTP itself (RFC 35= 50) and all RTP payload formats (many specs, e.g. RFC 6184 for H.264). The MMT payload format would be the elementary stream as defined by the codec spec = for storage in ISOBMFF containers, augmented with MMT specs and features such a= s generic packetization / fragmentation.

>>>

>>> Mo

>>>

>>>

>>> On 7/28/15, 2:05 PM, = Michael Speer<michael.spee= r@pluribusnetworks.com>=C2=A0 wrote:

>>>

>>> Mo,

>>>

>>> Hi, can you post the = RFCs you trying to replace?=C2=A0 In particular, what

>>> RTP payload specifica= tion are you trying to replace?

>>>

>>> Cheers,

>>> Michael

>>>

>>>

>>> On Tue, Jul 28, 2015 = at 9:15 AM, Mo Zanaty (mzanaty)<mzanaty@cisco.com<= /a>>=C2=A0 wrote:

>>>> I assumed TSVAREA= was already aware of this since it was presented

>>>> there and will be= in their notes. I wanted to bring this to the

>>>> attention of RTP = folks that may be interested but probably missed

>>>> this. If there ar= e any replies here that may be useful for TSV, I

>>>> will forward. I t= ry to avoid cross-posting to lists with significantly different topics and subscribers.=

>>>>

>>>> Mo

>>>>

>>>> On 7/28/15, 12:05= PM, Ali C. Begen (abegen)<abegen@cisco.com>=C2= =A0 wrote:

>>>> Is not this threa= d supposed to cc the transport area, too?

>>>>

>>>> -----Original Mes= sage-----

>>>> From: avt on beha= lf of "Mo Zanaty (mzanaty)"

>>>> Date: Tuesday, Ju= ly 28, 2015 at 7:02 PM

>>>> To: "avt@ietf.org", "payload@ietf.org"=

>>>> Cc: "gorry@erg.abdn.ac.uk"= ;

>>>> Subject: [AVTCORE= ] MMTP vs RTP

>>>>

>>>>> MMTP (MPEG Me= dia Transport Protocol) aims to replace RTP and MPEG-2

>>>>> TS for media = streaming applications, both real-time and

>>>>> non-real-time= . It integrates FEC, buffering, congestion control and

>>>>> other functio= ns. It was presented in TSVAREA in IETF 93. See below

>>>>> for the slide= s and draft.

>>>>> https://www.ietf.org/proceedings/93/slides/slides-93-tsvarea-1.pdf<= /span>

>>>>> https://t= ools.ietf.org/html/draft-bouazizi-tsvwg-mmtp

>>>>>

>>>>> I found slide= s 5 and 15 particularly relevant for AVT folks, so

>>>>> inlining them= .

>>>>>

>>>>> Why not RTP? = (slide 5)

>>>>> - Lack of=C2= =A0 Multiplexing

>>>>>=C2=A0 - One media session per component and without RTP multiplexing, 2

>>>>> ports per ses= sion

>>>>> - Server Main= tenance

>>>>>=C2=A0 - RTP Payload Format for every new media codec

>>>>>=C2=A0 - Support needs to be added to the media server

>>>>> - Coupling of= =C2=A0 Presentation and Delivery

>>>>>=C2=A0 - RTP carries presentation and synchronization information at the

>>>>> transport lev= el

>>>>> - Limited sup= port for Non-Real Time Media

>>>>>=C2=A0 - Presentations consist of=C2=A0 timed and non-timed media

>>>>>=C2=A0 - Need other protocol or countless number of=C2=A0 payload formats to

>>>>> support NRT

>>>>>

>>>>> Why are we he= re? (slide 15)

>>>>> - We want to = develop MMTP further in the IETF

>>>>> - We want to = address the Internet (unicast and Multicast)

>>>>> - We want to = reuse existing components such as congestion control

>>>>> and security<= /span>

>>>>> - A protocol = is needed by many SDOs: MPEG, ATSC, 3GPP, DVB, ...

>>>>> - Can we revi= ve rmt?

>>>>> - Can we star= t a BoF or a new ad-hoc group?

>>>>> - Or can we d= o an informational RFC?

>>>>>

>>>>> I think there= should be some dialogue on RTP evolution with the

>>>>> MMTP folks. S= ome interesting points are raised in this work, such

>>>>> as generic pa= cketization vs. specific RTP payload formats. Perhaps

>>>>> a generic pay= load draft can address this generic packetization

>>>>> (i.e. fragmen= tation and perhaps aggregation) in the absence of a

>>>>> specific RTP = payload format for the elementary media stream.

>>>>>

>>>>> Thanks to Gor= ry for bringing this to my attention.

>>>>>

>>>>> Mo

>>>> _______________________________________________

>>>> Audio/Video Trans= port Core Maintenance avt@ietf.org

>>>> https://www.ietf.org/mailman/listinfo/= avt

>

> _____________________________= __________________

> Audio/Video Transport Core Ma= intenance

> avt@ietf.org

> https://www.ietf.org/mailman/listinfo/avt

=C2=A0

--089e01182722e30aad051c0a9ad0--