Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session

Harald Alvestrand <harald@alvestrand.no> Sat, 25 August 2012 14:28 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75B721F8496 for <mmusic@ietfa.amsl.com>; Sat, 25 Aug 2012 07:28:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.699
X-Spam-Level:
X-Spam-Status: No, score=-109.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 gzKWFIEmJt+D for <mmusic@ietfa.amsl.com>; Sat, 25 Aug 2012 07:28:01 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 71F3121F8493 for <mmusic@ietf.org>; Sat, 25 Aug 2012 07:28:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 146D739E12F; Sat, 25 Aug 2012 16:28:00 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvI+ZR2L6Va3; Sat, 25 Aug 2012 16:27:59 +0200 (CEST)
Received: from [192.168.11.193] (c-56fbe555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.251.86]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id DCA6C39E125; Sat, 25 Aug 2012 16:27:58 +0200 (CEST)
Message-ID: <5038E0EE.60608@alvestrand.no>
Date: Sat, 25 Aug 2012 16:27:58 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
References: <CE457B53-341D-48C8-8CD7-2A0958407F37@vidyo.com> <50222D44.5040105@alvestrand.no> <BLU401-EAS1263CBF056291C5313CA95193CD0@phx.gbl>, <502258CA.5030009@alvestrand.no> <BLU002-W14079A44079EFA284B8E94793CC0@phx.gbl> <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com>
In-Reply-To: <01C25C86-D664-468E-923F-4EEA506ACEDF@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Aug 2012 14:28:03 -0000

On 08/25/2012 03:41 PM, Cullen Jennings (fluffy) wrote:
> On Aug 9, 2012, at 9:57 , Bernard Aboba wrote:
>
>> Harald said:
>>> Bernard, since I'm so easily confused by how people transmit layers of
>>> layered codecs, can you illustrate the particular scheme you want to
>>> use, and can't think of how to represent in Jonathan's scheme?
>> [BA]  I am looking at RFC 5583 "Signaling Media Decoding Dependency in SDP". An
>> example of how this would be used with H.264/SVC is included in RFC 6190, Section 7.3.4:
>>
>>        a=group:DDP L1 L2
>>        m=video 20000 RTP/AVP 96
>>        a=rtpmap:96 H264/90000
>>        a=fmtp:96 profile-level-id=4de00a; packetization-mode=0;mst-mode=NI-T;
>>        a=mid:L1
>>        m=video 20002 RTP/AVP 97
>>        a=rtpmap:97 H264-SVC/90000
>>        a=fmtp:97 profile-level-id=53001F; packetization-mode=1;
>>         mst-mode=NI-TC; sprop-operation-point-info=<2,0,1,0,53000c,
>>        3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
>>        a=mid:L2
>>        a=depend:97 lay L1:96
>>
>>
>> Here the a=depend line is expressing the decoding dependency (layered in this case).
>>
>> Let us assume that there is also audio, as in Jonathan's example:
>>
>>         m=audio 10000 RTP/AVP 0 8 97
>>         a=mid:foo
>>         b=AS:200
>>         a=rtpmap:0 PCMU/8000
>>         a=rtpmap:8 PCMA/8000
>>         a=rtpmap:97 iLBC/8000
>>
>>
>> Does the entire SDP offer with BUNDLE and dependency grouping  look like this (ignoring RTP/RTCP mux for the moment)?
>>
>>         v=0
>>         o=alice 2890844526 2890844526 IN IP4
>> host.atlanta.com
>>
>>         s=
>>         c=IN IP4
>> host.atlanta.com
>>
>>         t=0 0
>>         a=group:BUNDLE foo L1 L2 baz
>>
>>         a=group:DDP L1 L2
>>         m=audio 10000 RTP/AVP 0 8 98
>>         a=mid:foo
>>         b=AS:200
>>         a=rtpmap:0 PCMU/8000
>>         a=rtpmap:8 PCMA/8000
>>         a=rtpmap:98 iLBC/8000
>>         a=candidate:1 1 UDP 1694498815
>> host.atlanta.com
>>   10000 typ host
>>         m=video 20000 RTP/AVP 96
>>         a=rtpmap:96 H264/90000
>>         a=fmtp:96 profile-level-id=4de00a; packetization-mode=0;mst-mode=NI-T;
>>         a=mid:L1
>>         m=video 20002 RTP/AVP 97
>>         a=rtpmap:97 H264-SVC/90000
>>         a=fmtp:97 profile-level-id=53001F; packetization-mode=1;
>>         mst-mode=NI-TC; sprop-operation-point-info=<2,0,1,0,53000c,
>>        3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
>>         a=mid:L2
>>         a=depend:97 lay L1:96
>>         a=candidate:1 1 UDP 1694498815
>> host.atlanta.com
>>   20002 typ host
>>         m=bundle 10000 RTP/AVP 0 8 96 97 98
>>         a=mid:baz
>>         b=AS:1200
>>         a=full-rtpmap:0 audio/PCMU/8000
>>         a=full-rtpmap:8 audio/PCMA/8000
>>         a=full-rtpmap:98 audio/iLBC/8000
>>         a=full-rtpmap:96 H264/90000
>>         a=full-rtpmap:97 H264-SVC/90000
>>         a=depend:97 lay L1:96
>>         a=candidate:1 1 UDP 1694498815
>> host.atlanta.com
>>   10000 typ host
>>
>>
>>   
>
> I think it will work better if it just looked like
>
>         v=0
>         o=alice 2890844526 2890844526 IN IP4 host.atlanta.com
>         s=
>         c=IN IP4 host.atlanta.com
>
>         t=0 0
>         a=group:BUNDLE foo L1 L2 baz
>
>         a=group:DDP L1 L2
>         m=audio 10000 RTP/AVP 0 8 98
>         a=mid:foo
>         b=AS:200
>         a=rtpmap:0 PCMU/8000
>         a=rtpmap:8 PCMA/8000
>         a=rtpmap:98 iLBC/8000
>         a=candidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host
>         m=video 20000 RTP/AVP 96
>         a=rtpmap:96 H264/90000
>         a=fmtp:96 profile-level-id=4de00a; packetization-mode=0;mst-mode=NI-T;
>         a=mid:L1
>         m=video 20002 RTP/AVP 97
>         a=rtpmap:97 H264-SVC/90000
>         a=fmtp:97 profile-level-id=53001F; packetization-mode=1;
>         mst-mode=NI-TC; sprop-operation-point-info=<2,0,1,0,53000c,
>        3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
>         a=mid:L2
>         a=depend:97 lay L1:96
>         a=candidate:1 1 UDP 1694498815 host.atlanta.com 20002 typ host
>
>
> that seems to have all the same information as the version with m=bundle thing and AFAIC some firewalls are going to remove all the stuff under the m=bundle line as it is not a recognized media type.
Not taking a position, but having firewalls remove all the m=bundle 
stuff (and presumably also the a=group:BUNDLE line) is, in my view, 
actually an advantage of this approach. (If the firewall removes the 
m=bundle and not the a=group:BUNDLE, we're left with a somewhat strange 
SDP.)

Cullen, I note you're using different port numbers on the m= sections. 
Are you assuming the semantics from a=group:TOGETHER - that one picks 
the first one?