Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
Christer Holmberg <christer.holmberg@ericsson.com> Mon, 27 August 2012 08:39 UTC
Return-Path: <christer.holmberg@ericsson.com>
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 9BBF221F8551 for <mmusic@ietfa.amsl.com>; Mon, 27 Aug 2012 01:39:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.267
X-Spam-Level:
X-Spam-Status: No, score=-5.267 tagged_above=-999 required=5 tests=[AWL=-0.818, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4]
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 K-D8fHkn0yoM for <mmusic@ietfa.amsl.com>; Mon, 27 Aug 2012 01:39:51 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1302021F850C for <mmusic@ietf.org>; Mon, 27 Aug 2012 01:39:50 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fea6d000002ccb-d8-503b3255554a
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D8.19.11467.5523B305; Mon, 27 Aug 2012 10:39:49 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 27 Aug 2012 10:39:49 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Harald Alvestrand <harald@alvestrand.no>
Date: Mon, 27 Aug 2012 10:39:47 +0200
Thread-Topic: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session
Thread-Index: Ac2EKmPIuZrWJAeWS9GjczdeFq8EYgABNFXw
Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A292D94@ESESSCMS0356.eemea.ericsson.se>
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> <5038E0EE.60608@alvestrand.no>, <BLU401-EAS1449593A32E42F2871B483E93BC0@phx.gbl> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F24@ESESSCMS0356.eemea.ericsson.se> <503B29B6.5000000@alvestrand.no>
In-Reply-To: <503B29B6.5000000@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+JvrW6okXWAwfmbyhb7l1xmtuiYzGZx rK+LzWLq8scsDiweVyZcYfWY8nsjq8fjnjNsHkuW/GQKYInisklJzcksSy3St0vgyri68CNb wWWLiu1t+1gaGDu0uxg5OSQETCSOrWhggbDFJC7cW8/WxcjFISRwilFi5fvZUM4CRolbnbOA qjg42AQsJLr/gTWLCOhIPNzfwARSwyzQzChxdtsJJpAEi4CqxJc9X9lAbGGBeIkV25YyQzQk SOyatJYRZI6IgJHEnCVeIGFegXCJDVeWsEPsusMs0XR6Nlg9p4CuRNfbV2BzGIGu+35qDdh8 ZgFxiVtP5jNBXC0gsWTPeWYIW1Ti5eN/rBD1ohJ32tczQtTrSCzY/YkNwtaWWLbwNTPEYkGJ kzOfsExgFJuFZOwsJC2zkLTMQtKygJFlFaNwbmJmTnq5oV5qUWZycXF+nl5x6iZGYIwd3PJb dwfjqXMihxilOViUxHm5kvb7CwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBs+v7cavcSC6OE 7g3/zbJTp76cvWSDQtfOxIe9p6I0s0U+XpuTLPZc+oxfzh7DXn8mfn0LwbBkeanT79du+i2u ayTN/VGlcO/yoL9R1xNkrKoki9xf+XSLJzqZP93qbyGkXiMV/4ZF4rG+l/hVthDXw9YzWno+ frJ7MO2YqpB9TdmR7otnXJVYijMSDbWYi4oTATs2YIJ/AgAA
Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, "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: Mon, 27 Aug 2012 08:39:52 -0000
Hi, >>> The different port number issue arises in multiple contexts here. >>> Firstly, it arises within the dependency grouping. RFC 6190 allows >>> layers to use different ports as well as allowing multiple layers to >>> be sent to the same port. While the SDP example in RFC 6190 (which I >>> copied) shows different ports being offered, in practice, I believe that H.264/SVC implementations typically prefer using the same port. However, using the same port in an SDP offer can cause answerers to reject the SDP as invalid, which is >>>presumably why that approach was chosen for the RFC 6190 example. So the potential solution is to offer different ports, and have the answer respond with the same port. >> That is what Harald's original TOGETHER proposal was all about, and where I had issues (related to intermediares who assume that the offered ports are used, and if the offer wants to set the multiplex port to zero). >> >> So, IF people think that offering the same port will cause problem, and IF people think that an m=bundle m- line would be removed, maybe the only option is to have 2 offer/answers: the first is a "normal" offer, with different ports, and if the answerer >>indicates that it supports bundle then the second offer will be sent with the same port. >If "m=bundle m-line is removed" means "we'll negotiate the old style session with old equipment", then that's a success, not a failure. Agree. There would be no multiplexing, but the session establishment would still succeed. Regards, Christer > On Aug 25, 2012, at 7:28, "Harald Alvestrand" <harald@alvestrand.no> wrote: > >> 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? >> >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic
- [MMUSIC] Possible BUNDLE alternative syntax: expl… Jonathan Lennox
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Paul Kyzivat
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Harald Alvestrand
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Bernard Aboba
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Harald Alvestrand
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Bernard Aboba
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Harald Alvestrand
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Cullen Jennings (fluffy)
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Harald Alvestrand
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Bernard Aboba
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Harald Alvestrand
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Cullen Jennings (fluffy)
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Cullen Jennings (fluffy)
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Cullen Jennings (fluffy)
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Ejzak, Richard P (Richard)
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Ejzak, Richard P (Richard)
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Lishitao
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Ejzak, Richard P (Richard)
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Ejzak, Richard P (Richard)
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Ejzak, Richard P (Richard)
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Ejzak, Richard P (Richard)
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Lishitao
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Parthasarathi R
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Parthasarathi R
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Jonathan Lennox
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Parthasarathi R
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Cullen Jennings (fluffy)
- Re: [MMUSIC] Possible BUNDLE alternative syntax: … Christer Holmberg