Re: [AVTCORE] [payload] MMTP vs RTP

[정경훈 <[e-mail]>]

Samsung Enterprise Portal mySingle

Hi,

 

RTP just got into the essential nerves of mobile networks

as the transport mechanism of VoLTE. We need its simplicity

and decades of proven track record before we integrate into

the basic architecture of LTE.

 

I would question if a single protocol claims to meet all needs

around the industry.

 

Best regards,

Kyunghun Jung

Samsung Electronics Co., Ltd.

 

------- Original Message -------

Sender : Michael Speer<[e-mail]>

Date : 2015-07-29 03:05 (GMT+09:00)

Title : Re: [payload] [AVTCORE] MMTP vs RTP

 

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) <[e-mail]> 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) <[e-mail]> 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: "[e-mail]", "[e-mail]"
Cc: "[e-mail]"
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" target="_blank" rel="noreferrer nofollow">https://www.ietf.org/proceedings/93/slides/slides-93-tsvarea-1.pdf
>https://tools.ietf.org/html/draft-bouazizi-tsvwg-mmtp" target="_blank" rel="noreferrer nofollow">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
[e-mail]
https://www.ietf.org/mailman/listinfo/avt" target="_blank" rel="noreferrer nofollow">https://www.ietf.org/mailman/listinfo/avt