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

[Harald Alvestrand <[e-mail]>]

On 07/25/11 09:35, 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.
I think that's a layering violation. STUN has no references to RTP; 
there is no assumption in STUN that the content of the flow will be RTP. 
I think we should keep it that way.
>   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.
>
> One another benefit to indicating this in STUN is that even if both
> rtcweb endpoints said they supported this mechanism via SDP, the routers
> where QoS, traffic engineering etc are applied to media packets many not
> be there in the signaling path to understand that it is a multiplexed
> media flow using the same port, and in particular that the SSRC space
> has been partitioned as proposed in draft-rosenberg-rtcweb-rtpmux to
> enable them to perform DPI and figure out the media type (audio/video
> etc).
>
> Muthu
>
> |-----Original Message-----
> |From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Matthew Kaufman
> |Sent: Monday, July 25, 2011 6:35 PM
> |To: Harald Alvestrand
> |Cc: [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 8:06 AM, Harald Alvestrand wrote:
> |
> |>  On 07/24/11 16:44, Matthew Kaufman wrote:
> |>>  In all my reading today I have not been able to find anything more
> concrete than the "SHOULD NOT"
> |in section 5.2 of RFC3550. PLEASE follow up if you are aware of any
> other relevant specifications that
> |would argue against using SSRC to multiplex audio and video streams
> over a single RTP session between
> |a pair of compatible endpoints that agree to do so.
> |>  I have found *one* reason not mentioned in the draft:
> |>
> |>  An RTP session with both "audio" and "video" media types cannot be
> represented by an SDP
> |description, since SDP ties RTP sessions 1-1 to the "m" line of the
> description, which contains the
> |top-level type, and the codec descriptions omit the top-level type in
> their codec naming.
> |>
> |>  I've said elsewhere that I consider this to be a design mistake for
> entirely different reasons, but
> |this debate has reinforced my opinion that it is.
> |
> |Good point, but perhaps it just argues for either A) not using SDP or
> B) extending SDP if we use it
> |for RTCWEB (we probably need to do that anyway if we use SDP, given all
> the discussion about "hints"
> |that we want to send from one end to the other)
> |
> |Matthew Kaufman
> |_______________________________________________
> |rtcweb mailing list
> |[e-mail]
> |https://www.ietf.org/mailman/listinfo/rtcweb
>