Pre review of 3GPP MIME type for RTP payload format

[Magnus Westerlund]

Hi Larry,

Okay I will try to make a more complete explanation of how things fit to 
together.

RTP is protocol that can be used by different applications. However most 
of the applications, like VoIP or Streaming do use SDP (RFC 2327) to 
configure RTP and the used media codecs and payload formats. An example 
of a media block that configures one RTP session is:

    m=video 49170 RTP/AVPF 96 97
    c=IN IP4 192.0.2.0
    a=rtpmap:96 MP4V-ES/90000
    a=rtcp-fb:96 nack
    a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\
    0A21F
    a=rtpmap:97 rtx/90000
    a=fmtp:97 apt=96;rtx-time=3000

Where the m= lines first indicates the media type (video), and the 
a=rtpmap indicates the subtype which represents the actual RTP payload 
formats used in this session. The payload type numbers (96 and 97) are 
used in RTP header to identify the actual payload of a received RTP 
packet. In this case the session support the usage of MPEG-4 video using 
the RTP payload format for elementary streams defined in RFC 3016 
(payload type 96), and the RTP payload format for retransmission 
(payload type 97) which is defined in 
(draft-ietf-avt-rtp-retransmission-10). The mapping of media type and 
subtype to SDP is defined in RFC 3555.

If you would like to have also audio to this session, then you would 
need to have an SDP with another media block which defines the audio 
part. Through the actual definition of a new media block, one defines 
that a completely separated RTP session shall be used. For example the 
following:

     m=audio 49120 RTP/AVP 98
     a=rtpmap:98 AMR-WB/16000
     a=fmtp:98 octet-align=1

Which tells the receiver that it needs the audio codec AMR-WB and the 
RTP payload format specified in RFC 3267, by referencing the registered 
MIME type (audio/AMR-WB). In addition as this payload format has more 
then one configuration the a=fmtp line does tell it to use the 
octet-aligned mode of packetization.

As I previously indicated, there are good reasons why audio and the 
video streams shall be sent over different RTP sessions. And SDP is 
tailored to provide this by specifying the media type at a media block 
level, rather than at each individual payload type.

So it is actually the limited possibility to express that an RTP session 
should contain for example audio/amr-wb and application/rtp.enc.aes128 
that is the blocking factor. But this limitation is good, as it ensure 
that people do not do bad multiplexing decisions. We must also consider 
the huge deployed base of SDP parsing applications that would fold over 
in the face of change to allow different media types in the same media 
block.

Direct comments below.

Larry Masinter wrote:

> Part of the problem is that RFC 3555 (MIME Type Registration
> of RTP Payload Types) isn't marked as updating RFC 2048, even though
> it seems to be intended to.
> 

That, is probably true. And this will be fixed in the update process to 
resolve this whole thing. As I understand it, Ned Freed will provide an 
update version of the MIME registration rules that introduces the domain 
of applicability concept there. To my knowledge a first draft is 
available of that. When that has been resolved we will update RFC 3555 
to ensure that it is consistent with the new rules.

> 
>>[mw]
>>The fact is that RTP and its signalling do require the 
>>registration in the applicable. For RTP there is a clear 
>>explanation in RFC 3550 why it is harmful to mix different 
>>media types in the same RTP session. Due to this reason also 
>>the signalling in SDP does not allow the mixing of multiple 
>>media types in the same RTP session. So due to the above 
>>restrictions one can not register an single 
>>application/rtp.enc.aes128 to secure all the different media 
>>top levels. 
>>[\mw]
> 
> 
> I looked at RFC 3550, and can find no mention
> of MIME or any references to the media type registry,
> so I don't understand where this 'clear explanation'
> might be. There is a definition of a 'RTP media type':
> 
>    RTP media type: An RTP media type is the collection of payload
>       types which can be carried within a single RTP session.  The RTP
>       Profile assigns RTP media types to RTP payload types.
> 
> but I don't see what this has to do with MIME media types.
> Can you be more explicit about where this is clearly explained?
> 

The usage of MIME to label RTP payload format and its associated codec 
is defined by RFC 3555. However I don't think it is properly explained 
if it is not in RFC 3555.


> It's hard to trace from 3555 and 3550 to the requirement that
> different kinds of data need different top-level text/ audio/
> video/ types.
> 

Yes, as explained above, this is a combination of RTP and SDP behavior.


Cheers

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: magnus.westerlund at ericsson.com