Subject: draft-ietf-mmusic-sdp-01.ps

From: Mark Handley <[email-masked]>
Date: Wed, 22 Nov 1995 21:18:33 +0000

I've rushed off a new version of the SDP draft (hopefully) just in
time for the drafts deadline for Dallas.  This is basically the draft
1.4 that we discussed in Stockholm with a few small changes that were
also discussed in Stockholm.

The main changes since pre-draft 1.4 are:

- ttl is now appended to the end of multicast addresses rather than a
separate sub-field (it's IP multicast specific + compulsory)
- a network type subfield has been added preceeding any address type subfield
- multiple ports per stream is allowed for unicast hierarchical encodings
- lots of small cleanups

The changes since draft-ietf-mmusic-sdp-00.ps are too many to go into here.

Until it appears in the internet-drafts archives, it's available as:
http://www.cs.ucl.ac.uk/staff/mhandley/draft-ietf-mmusic-sdp-01.ps
and
http://www.cs.ucl.ac.uk/staff/mhandley/draft-ietf-mmusic-sdp-01.txt

There's still no companion SDAP draft due to ongoing discussions with
the PIM folks.

Mark

BTW, I've been picked up on my use of English for saying "media tool"
(of course it should be "medium tool") but somehow "media tool" seems
to have fallen into general usage.  Does anyone else object to the
terminology "media tool"?

---

From: Stephen Casner <[email-masked]>
Date: Tue, 5 Dec 1995 20:10:02 -0800 (PST)

Mark,

Here are a few very last minute comments on SDP.  I apologize that
several of these have been waiting since our initial email discussion
in August.  These issues seem not to have been addressed in the
revised SDP draft.

We were talking about several aspects related to RTP profiles and
payload formats:

  - I mentioned before the problem that L8, for example, is defined in
    the profile but does not have a static payload type associated
    with it (such a type would also have to specify a sample rate).
    Similarly, two payload formats use L16 (one or two channels).
    Therefore, this name space can't be used to identify RTP static
    payload type assignments.  The payload type numbers should be used
    instead.

  - Payload types are profile-specific; you suggested "AVP-17" rather
    than just "17" to solve this problem, although you commented that
    this was a little to implicit for your liking (I'm not sure I
    understood that).  Instead, I would suggest that the protocol be
    RTP-AVP and the payload type be just 17.  This is prefered because
    an app may use protocol RTP-AVP and switch among payload types 17,
    5 and 12, but it would not likely use protocol RTP and switch
    among payload types AVP-17 and XYZ-5.

  - For dynamic payload type assignments you suggested:

	    m=audio 12346 RTP L16,11025/2
	    a=ptype:97

    to specify dynamic payload type 97 should be assigned to payload
    format "16-bit linear sampling, 11025 Hz sampling rate, 2
    channels".  You also asked if sessions would sometimes need
    multiple dynamic payload type assignments (the answer is yes), in
    which case you suggested

	    a=ptmap:L8,8000 96
	    a=ptmap:L8,11025 97
	    a=ptmap:L16,8000 98

    I would prefer to put the simple parameter first and the variable
    parameter(s) later:

	    a=ptmap:96 L8,8000
	    a=ptmap:97 L8,11025
	    a=ptmap:98 L16,8000

    If we do have this ptmap form, then would it be expected to follow

	    m=audio 12346 RTP-AVP

    without any format spec?  (I've inserted my RTP-AVP suggestion
    here.)

  - There are a number of encoding types that were removed from the
    profile spec, consistent with the plans to be more conservative
    with static payload type assignments (allowing them only for
    interoperable algorithms).  Also, the name IDVI became DVI4.

Some other comments on SDP not related to the above:

  - SDP includes "o" for the originator of the session announcement.
    There may also be a need to specify the host that is the intended
    sender for sessions that will be in the broadcast style.  As in
    other aspects of the lightweight session model, this field would
    simply be a suggestion to the receivers so that they can
    automatically mute any other sources and leave the intended source
    unmuted.  This new field is required because the source may not be
    the same as the session originator.

  - The "o" field builds upon the address of the "originating host".
    Then the session is originated from an sd-like tool, this host
    address is well defined.  What about when a session is created via
    a web browser, for example?

  - Since vat now does support RTPv2, and since a transition from the
    original vat protocol to RTPv2 is to be encouraged, I suggest that
    the wording be changed in a few places.

  - In the discussion of the port field for "m=", should there be a
    discussion of the conventions mrouted uses for priority in rate
    limiting?  (Ports are divided into four classes 0xxxx, 2xxxx,
    4xxxx and 6xxxx, and Bill Fenner can supply the details.)

							-- Steve