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)" <mperumal@cisco.com> Mon, 25 July 2011 12:57 UTC

Return-Path: <mperumal@cisco.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1FD21F881C for <rtcweb@ietfa.amsl.com>; Mon, 25 Jul 2011 05:57:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.799
X-Spam-Level:
X-Spam-Status: No, score=-8.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qrzwgp3QdzvZ for <rtcweb@ietfa.amsl.com>; Mon, 25 Jul 2011 05:57:42 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C2B1721F8453 for <rtcweb@ietf.org>; Mon, 25 Jul 2011 05:57:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=7956; q=dns/txt; s=iport; t=1311598661; x=1312808261; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=i9P+13zyjfmA05LkFM8f3KFsNp2u1yMBI1nbp5mV8ls=; b=JU7fyYPvJSZ3WB7hhMgOAjHVwXKhvjSD7OFS8CkH0OPeyUBsEZq3SS1O hQMxFEf4YEdFx/J2CDeZJMW2ltKkPiCk0DBW97fcmh0y3CRe1Q4pe1BMj 7bJipIdTsdrcYbn8Ind2B3VhiMfEz9X2rRu/DXybxwwBNDu/WbZB9jTcy o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AugAAH5nLU5Io8UR/2dsb2JhbAA0AQEBAQMBAQERARQNBEAXBQIBBwIRBAEBAwIGBh8EAQICAgEBEhgjDggBAQUBCwsMG4QvkyyOVn93iQCiM40jkE6BK4QFMF8Eh1OQLYtY
X-IronPort-AV: E=Sophos;i="4.67,261,1309737600"; d="scan'208";a="104173167"
Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 25 Jul 2011 12:57:38 +0000
Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6PCvcta003477; Mon, 25 Jul 2011 12:57:38 GMT
Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jul 2011 18:27:37 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Mon, 25 Jul 2011 18:27:34 +0530
Message-ID: <1D062974A4845E4D8A343C653804920205F72BDC@XMB-BGL-414.cisco.com>
In-Reply-To: <4E2D620F.5010003@jesup.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] Reasons not to multiplex audio with video (Re: Fwd: I-D Action: draft-rosenberg-rtcweb-rtpmux-00.txt)
Thread-Index: AcxKxvNsKdI6415PTseSX5ZDxOKSvgAAbxOw
References: <4E123C54.10405@jdrosen.net><8785C0A3-31E5-44D7-8557-3BEEE4F95E3D@skype.net><4E2D5C5D.6060402@alvestrand.no> <4E2D5ED5.5060706@jitsi.org> <4E2D620F.5010003@jesup.org>
From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: Randell Jesup <randell1@jesup.org>, rtcweb@ietf.org
X-OriginalArrivalTime: 25 Jul 2011 12:57:37.0933 (UTC) FILETIME=[6E2F13D0:01CC4ACA]
Subject: Re: [rtcweb] Reasons not to multiplex audio with video (Re: Fwd: I-D Action: draft-rosenberg-rtcweb-rtpmux-00.txt)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jul 2011 12:57:43 -0000

A few options to indicate this multiplexing in SDP and being backward compatible with legacy implementations:

1) The simplest option is to use the same port value across multiple "m=" lines in the SDP. Unfortunately, that won't be backward compatible with legacy implementations because of RFC-4566 section 5.14:
<snip>
   The semantics of multiple "m=" lines using the same transport address are undefined.
</snip>

So, if a legacy implementation receives such an offer, the behavior would be unpredictable.

2) Another option is to simply list all the (audio/video) codes in a single "m=" line and define a new (optional) SDP attribute to indicate multiplexing. This also is no way going to be backward compatible with legacy implementations, since a legacy endpoint might typically send an answer with a single codec, resulting in an audio-only/video-only call, when audio + video was intended.

3) Another options is SDP grouping. Unfortunately, RFC-3388 section 7.5.3 forbids grouping multiple "m=" lines using the same transport address:
<snip>
   If several codecs have to be sent to the same IP address and port,
   the traditional SDP syntax of listing several codecs in the same "m"
   line MUST be used.  FID MUST NOT be used to group "m" lines with the
   same IP address/port.  Therefore, an SDP like the one below MUST NOT
   be generated.

       v=0
       o=Laura 289083124 289083124 IN IP4 six.example.com
       t=0 0
       c=IN IP4 131.160.1.112
       a=group:FID 1 2
       m=audio 30000 RTP/AVP 0
       a=mid:1
       m=audio 30000 RTP/AVP 8
       a=mid:2

   The correct SDP for the session above would be the following one:

       v=0
       o=Laura 289083124 289083124 IN IP4 six.example.com
       t=0 0
       c=IN IP4 131.160.1.112
       m=audio 30000 RTP/AVP 0 8

   If two "m" lines are grouped using FID they MUST differ in their
   transport addresses (i.e., IP address plus port).
</snip>

In addition, using the transport address across multiple "m=" lines by itself doesn't define a new group. So, using grouping doesn't look right.

4) The best option I can think of is to define a new media-level SDP attribute (say, a=muxport: <port>) that indicates a multiplexed port where the offerer/answerer is willing to receive media streams, in-addition to the port indicated in the "m=" lines.

So, the offer could look like this:
      m=audio 49170 RTP/AVP 0 8 97
      a=rtpmap:0 PCMU/8000
      a=rtpmap:8 PCMA/8000
      a=rtpmap:97 iLBC/8000
      a=muxport:5000 
      m=video 51372 RTP/AVP 31 32
      a=rtpmap:31 H261/90000
      a=rtpmap:32 MPV/90000
      a=muxport:5000

An endpoint that doesn't support multiplexing would ignore a=muxport and send a answer like this:
      m=audio 49174 RTP/AVP 0
      a=rtpmap:0 PCMU/8000
      m=video 49170 RTP/AVP 32
      a=rtpmap:32 MPV/90000

Whereas an endpoint that understand multiplexing would understand a=muxport and send an answer like this:
      m=audio 40000 RTP/AVP 0
      a=rtpmap:0 PCMU/8000
      a=muxport:4000
      m=video 40000 RTP/AVP 32
      a=rtpmap:32 MPV/90000
      a=muxport:4000

However, the overhead for new implementations is that it needs to listen on both the port listed in the "m=" lines and the port specified in a=muxport, in addition to gathering both candidates for ICE, till it receives the answer. If it wants to be backward compatible with legacy implantations, it needs to pay for it, anyway..

Muthu

|-----Original Message-----
|From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Randell Jesup
|Sent: Monday, July 25, 2011 6:01 PM
|To: rtcweb@ietf.org
|Subject: Re: [rtcweb] Reasons not to multiplex audio with video (Re: Fwd: I-D Action: draft-rosenberg-
|rtcweb-rtpmux-00.txt)
|
|On 7/25/2011 8:17 AM, Emil Ivov wrote:
|> На 25.07.11 14:06, Harald Alvestrand написа:
|>> 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 am not sure I understand this. Why would one need to use the same "m"
|> line? What would be the consequences of using two different "m" lines?
|>
|> Personally, I am still not convinced that multiplexing brings
|> significant improvement over the status quo but if we accept it then it
|> definitely needs to keep separate "m" lines for tons of reasons.
|
|I've been assuming the method of indicating multiplexing would be two m=
|lines with
|the same c= destination and the same port specified.  This is a
|mechanism that has
|been discussed before on the AVT list and/or in drafts (and I'm sure has
|also been
|done before).  It does require avoiding using the same payload values in
|the two m= lines,
|but beyond that it's fairly straightforward.  It also allows for the
|answerer to clearly reject a
|media type explicitly, instead of an implicit rejection by removing the
|payloads of a type.
|
|--
|Randell Jesup
|randell-ietf@jesup.org
|
|_______________________________________________
|rtcweb mailing list
|rtcweb@ietf.org
|https://www.ietf.org/mailman/listinfo/rtcweb