Subject: [MMUSIC] Another bundling proposal

From: [email-masked] (Dale R. Worley)
Date: Fri, 22 Feb 2013 16:05:32 -0500 (EST)

I've written an alternative bundling proposal which I think manages
the problems of bundling better.

A series of tutorial examples are here:
http://tools.ietf.org/html/draft-worley-sdp-bundle-02#section-4
so it's easy to see how the proposal works.

Distinctive features of this proposal are:

- A separate m= line describes the bundled media, allowing unambiguous
  attribution of attributes to either the bundle or a constituent, and
  independent rejection of each constituent.

- Backward compatibility is achieved straightforwardly.

- Multiplexed media flows are attributed to their original constituent
  media descriptions without requiring each to be declared
  individually in the SDP.

- The multiplexed media flow is artificially given the media type
  "audio" to prevent rejection by SBCs.

- An encapsulating RTP format is used so demultiplexing can be done
  without coordinating payload types between media descriptions, and
  to ensure the bundled media description is rejected by
  non-supporting endpoints.

- Zero/non-zero ports and valid/null addresses are controlled to avoid
  duplicate port usage, and to ensure SBCs see exactly the media flows
  specified by the SDP.

Filename:	 draft-worley-sdp-bundle
Revision:	 02
Title:		 Kumquat: A Generic Bundle Mechanism for the Session Description Protocol (SDP)
Creation date:	 2013-02-22
Group:		 Individual Submission
Number of pages: 27
URL:             http://www.ietf.org/internet-drafts/draft-worley-sdp-bundle-02.txt
Status:          http://datatracker.ietf.org/doc/draft-worley-sdp-bundle
Htmlized:        http://tools.ietf.org/html/draft-worley-sdp-bundle-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-worley-sdp-bundle-02

Abstract:
   This document defines a generic bundle mechanism for the Session
   Description Protocol (SDP) by which the media described by a number
   of media descriptions ("m= lines") are multiplexed and transmitted
   over a single transport association.  The transport association is
   described by an additional media description, allowing SDP attributes
   to be applied to the aggregate, independently of attributes applied
   to the constituents.  In offer/answer usage, the bundle mechanism is
   backward compatible with SDP processors that do not understand the
   mechanism.  The mechanism is designed to be compatible with the
   limitations of the existing Internet infrastructure.

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 22 Feb 2013 21:39:23 +0000

Hi Dale,

Your proposal has some very nice properties; however, my concern with the overall approach is that I fear the initial offer will not be handled very well by typical pre-BUMDLE implementations. Due to the port being '9' and the connection address being 0.0.0.0, I would expect either:
1) a re-INVITE is needed for things to be renegotiated (best case)
2) the call fails (worst case)
Of course other variations between the best and worst case could happen, but the odds of arriving at the worst case seem unacceptably high to me. That is just my 2 cents without actually testing anything to validate it. I'd like to hear what others think.

Cheers,
Charles

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Dale R. Worley
> Sent: Friday, February 22, 2013 1:06 PM
> To: [email-masked]
> Subject: [MMUSIC] Another bundling proposal
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 22 Feb 2013 18:37:31 -0800

While I do agree that legacy implementations will have issues with using the same port on multiple m= lines, the proposal does explicitly address multiplexing issues via the "kumquat payload format" (an RTP tunnel of sorts).  Describing the implications for RTP in the proposal is better rather than implicitly assuming a given de-multiplexing approach or the presence of RTP extensions (e.g. the capture RTP extensions Roni referred to in a previous post). 

Since the RTP tunnelling approach does require changes to lots of components in the system
(e.g. MCUs), it is not necessarily the easiest thing to deploy.  However, it does appear to obviate the need to declare individual SSRCs, which a number of the other proposals do not (e.g. if payload types are not required to unique among all m-lines, then if multiple media types are multiplexed then SSRC is the only remaining de-multiplex point, so SSRC declaration is required). 

Also, tunnelling proposals can be used to address some of the ICE performance issues as well.  There is really no intrinsic reason why those kind of proposals can't be used to allow multiple endpoints to share a TURN allocation, for example, removing TURN as a performance bottleneck without requiring Trickle ICE. 

> From: [email-masked]
> To: [email-masked]; [email-masked]
> Date: Fri, 22 Feb 2013 21:39:23 +0000
> Subject: Re: [MMUSIC] Another bundling proposal
> 
> Hi Dale,
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 23 Feb 2013 21:47:56 -0500

This is an interesting approach, though Bernard's comments need to be 
considered.

One observation is that this introduces a new level of multiplexing 
based on a special codec. While it can work, there is already a proposal 
on the table for multiplexing multiple RTP sessions on a single 5-tuple: 
draft-westerlund-avtcore-transport-multiplexing-04. ISTM that this new 
bundling proposal could be adapted to use that multiplexing technique.

Bernard already raised issues about port 9 and address 0.0.0.0. I'll add 
that when this is done for multiple m-lines we stand some chance of 
getting errors due to reusing the same transport address. AFAIK there is 
no particular reason to use port 9 in this case, so perhaps it would be 
safer to use a different non-zero port in each such line.

I had originally found little reason to pursue 
draft-westerlund-avtcore-transport-multiplexing-04, but now I start to 
think that this provides an answer to the problem of demuxing without 
having to specify SSRCs or restrict payload types. I think it could be 
used, rather than an RTP header extension, to specify capture-encodings 
for clue. (But it can't specify mapping to multiple capture-encodings.)

	Thanks,
	Paul

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 23 Feb 2013 23:14:17 -0800

> for clue. (But it can't specify mapping to multiple capture-encodings.)

[BA] Yes, I've also begun to wonder if we haven't been giving that (and possibly)
other transport multiplexing approaches insufficient consideration.  A/V 
multiplexing isn't just an SDP issue, it is also an RTP issue.  Say we don't
specify SSRCs and instead require that the payload type is unique among 
all multiplexed m= lines so we can use PT to de-multiplex incoming RTP. 
Without specifying SSRCs, how do we map the RTCP reports, which
only include SSRCs and not payload types to the appropriate media 
stream tracks?   It seems to me that Cullen's "Plan A" has a fundamental
flaw.

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 25 Feb 2013 17:45:29 -0500 (EST)

> From: Paul Kyzivat <[email-masked]>

> bundling proposal could be adapted to use that multiplexing technique.

I haven't had the time to compare the SHIM encapsulation with the
KUMQUAT encapsulation, other than to see that SHIM encapsulation
doesn't produce valid-looking RTP, whereas KUMQUAT does.  Also,
KUMQUAT maintains word(4-octet)-alignment in the RTP payload.

But as the demultiplexing analysis shows, you don't *have* to
encapsulate to allow demultiplexing to work, as long as the payload
types of the constituent MDs are distinct, as well as the SCTP port
numbers in the SCTP constituent MDs.

> safer to use a different non-zero port in each such line.

Using null addresses in offers could be a problem.  But there's a fix
for that.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 25 Feb 2013 17:45:16 -0500 (EST)

> From: Bernard Aboba <[email-masked]>
> 
> Yes, I've also begun to wonder if we haven't been giving that (and possibly)

My understanding is that RTCP is expected to be demultiplexed by
examining the SSRC in each RTCP sub-packet (called an "RTCP packet" in
RFC 3550) and then finding the RTP media stream with the matching
SSRC.  The RTCP gets sent wherever the matching RTP gets sent.  (This
is described in the demultiplexing essay I've sent to the list.)

Dale