Re: [rtcweb] Reasons not to multiplex audio with video (Re: Fwd:I-D Action: draft-rosenberg-rtcweb-rtpmux-00.txt)

["Muthu Arul Mozhi Perumal (mperumal)" <[e-mail]>]

First refinement:
Define a new SDP attribute "a=muxed-candidate" that is similar to the
"a=candidate" attribute defined by ICE, except that the same
muxed-candidate can appear under multiple media stream descriptions in
SDP. The muxed-candidate identifies the transport address where the
RTCWEB endpoint would like to receive all these (multiplexed) media
streams. Non-RTCWEB endpoints would ignore this attribute.

Define a new comprehension-optional STUN attribute MUXED-CANDIDATE
(similar to the USE-CANDIDATE attribute). This attribute has no content
(the Length field of the attribute is zero) -- it serves as a flag.  It
has an attribute value of 0x802C (the first unassigned value from the
first half of the comprehension-optional range). It can be present in
the STUN connectivity check(s) sent when ICE concludes (i.e those STUN
Binding requests that contain the USE-CANDIDATE attribute) and serves as
an indication to routers and firewalls that any media stream that flows
between the selected pair of candidates is a multiplexed media stream --
for RTP it means that the SSRC space has been partitioned as described
in draft-rosenberg-rtcweb-rtpmux to enable DPI.

IMO, this isn't a layer violation per se, since we aren't carrying any
RTP stuff in STUN, rather just providing an indication for a particular
RTP usage.

Once issue, though -- comprehension-optional STUN attribute aren't
protected by STUN MESSAGE-INTEGRITY. So, MUXED-CANDIDATE would have to
protect itself or a new comprehension-optional STUN needs to be defined
that protects other comprehension-optional STUN attributes.

Muthu

|-----Original Message-----
|From: Matthew Kaufman [mailto:[e-mail]]
|Sent: Monday, July 25, 2011 8:16 PM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: Harald Alvestrand; [e-mail]
|Subject: Re: [rtcweb] Reasons not to multiplex audio with video (Re:
Fwd:I-D Action: draft-rosenberg-
|rtcweb-rtpmux-00.txt)
|
|
|On Jul 25, 2011, at 9:35 AM, Muthu Arul Mozhi Perumal (mperumal) wrote:
|
|> c) Using SDP for legacy interop, but extending STUN, by defining a
|> (comprehension optional) STUN attribute that indicates it is a
|> multiplexed media flow and that the SSRC space has been partitioned
to
|> enable DPI. Since rtcweb apps are expected to use STUN, it should be
|> trivial for them to support this STUN attribute. In addition, the
|> software in on-path routers would have to be upgraded anyway to
support
|> this king of DPI, so they could also be enhanced to detect STUN and
look
|> for this attribute.
|
|Agree with Harald that this is a layering violation, but I would not be
averse to putting a hint in
|STUN for this, or indeed a hint in STUN (as a non-mandatory attribute)
saying that we're doing other
|RTCWEB things, for devices that can only see the RTP/RTCP/STUN packets.
|
|That'd get yet another WG into the mix, of course.
|
|Matthew Kaufman