Re: [MMUSIC] Another bundling proposal - Christer's comments

[[e-mail] (Dale R. Worley)]

> From: Christer Holmberg <[e-mail]>
> 
> >>But, as far as I remember, there were never much discussion about it. 
> >>It was an open issue on one of my slides, and people simply indicated 
> >>support for adding explicit information, rather the referencing.

> As far as I remember, there were no real technical reasons - it was
> mostly "cosmetic".

If it's *purely* cosmetic, that is, only for human consumption, a
endpoint can add "a=comment:..." lines to document the PT
configuration of the bundle.

(What?  You've never heard of the "comment" attribute?  It isn't
defined -- and so all endpoints ignore it!)

> But, one issue is if there is an intermediary (e.g. transcoder) that
> modifies the payload type/codec information in the non-BUNDLE m-
> lines, but leaves the BUNDLE m- line untouched and passes the
> "kumquat" payload transparently. The offerer and answerer would not
> have different payload type/codec information.

Although if the PTs were listed in the bundle media description, there
would be no assurance that the intermediary would modify the PTs in
the bundle media description and the constituent media descriptions in
a coordinated way.  (Assuming the intermediary doesn't understand
bundling.)  That would cause demultiplexing to fail.  And that
analysis is true for all of the bundling proposals I've seen that
transmit the constituent media descriptions.

In any case, since we expect the RTP streams to be encrypted, no
transcoding is possible.

> >Adding payload types to the bundle media description makes it more
> >difficult to ensure that a non-supporting answerer rejects the
> >bundle media description.
> 
> It depends on how it's done. You could still only indicate "kumquat"
> on the m- line, but then provide the encapsulated payload type
> information using SDP attributes.

There's a design question "How do you ensure that non-supporting
answerers reject the bundle media description?"  There are three ways
that I know of:

1) an otherwise unused the media type.  Current proposals are
"anymedia" and "multipart".

2) an otherwise unused "proto" value.  No current proposals use this.

3) offering only an otherwise unused codec.

If what you mean is to provide a listing of the codecs used by the
constituent streams, but in some attribute other than a=rtpmap, or to
list them in a=rtpmap attributes but not put the PTs in the "fmt" list
of the m= line, it's not clear what benefit would be gained beyond
what a=comment would provide.  In any case, it's not clear how you
would describe the multiplexed SCTP streams in a way analogous to how
you would describe the RTP streams.

Dale