IETF Logo Mail Archive

Re: [MMUSIC] RFC5576 support in draft-ietf-mmusic-sdp-simulcast-06

Bo Burman <bo.burman@ericsson.com> Tue, 08 November 2016 13:30 UTC

Return-Path: <bo.burman@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 D0E9E129690 for <mmusic@ietfa.amsl.com>; Tue, 8 Nov 2016 05:30:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DSffs6uPDb4 for <mmusic@ietfa.amsl.com>; Tue, 8 Nov 2016 05:30:23 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59F16129BC0 for <mmusic@ietf.org>; Tue, 8 Nov 2016 05:30:23 -0800 (PST)
X-AuditID: c1b4fb25-bf4b398000005623-ff-5821d36d33df
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id A0.C4.22051.D63D1285; Tue, 8 Nov 2016 14:30:21 +0100 (CET)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.33) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 8 Nov 2016 14:29:59 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=k0e3wPtGnQFTrvCFtVm0Ug5+MGbVJNfF93o4eA7hLwU=; b=dg6FptN6PkM1kwM618xu3XaEfu1yFAz972QpJT3TfkHYvw1xArT0BT9N1zmrlZTZju/2A3mPLW5tjPMG35nhRy/XRCS3J9iKXvRhmjfBbMAQJLeE0z1ATP1QDX8nFMtd/JWScgwjuYZxNGqcIwKT2sg+Xk08Ct3x1mhOugjlR4I=
Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com (10.173.92.21) by AM5PR0701MB2580.eurprd07.prod.outlook.com (10.173.92.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.1; Tue, 8 Nov 2016 13:29:58 +0000
Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) by AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) with mapi id 15.01.0707.004; Tue, 8 Nov 2016 13:29:58 +0000
From: Bo Burman <bo.burman@ericsson.com>
To: Roni Even <ron.even.tlv@gmail.com>, 'Adam Roach' <adam@nostrum.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] RFC5576 support in draft-ietf-mmusic-sdp-simulcast-06
Thread-Index: AdI1Mvc3mGq0y53uREmavISaxNZWuQAELB8AACpVeIAA9AY64A==
Date: Tue, 08 Nov 2016 13:29:58 +0000
Message-ID: <AM5PR0701MB2577F8BE6920EAD0BF70E72D8DA60@AM5PR0701MB2577.eurprd07.prod.outlook.com>
References: <017801d23533$eecde1c0$cc69a540$@gmail.com> <f7091657-0591-903b-792e-8a1b3c1109ec@nostrum.com> <024b01d235ec$ff25b160$fd711420$@gmail.com>
In-Reply-To: <024b01d235ec$ff25b160$fd711420$@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=bo.burman@ericsson.com;
x-originating-ip: [192.176.1.81]
x-ms-office365-filtering-correlation-id: 3c5d43ec-7cc8-4e9b-596d-08d407db5605
x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2580; 7:M2YzHK0HpDabBJZBZYVjWA630XcsFGqNo4Tsflp7XpAzQoXfOatDsEYTvUqfNXbVCkpwHB4sQMylJ1Kt6h1F7opI/k3bcJv40xS5zX3CFwdMYJU8YdobRh56H1NS8KUYVeKgck3vXQYdCQp+ueciLeBw2TbzHKyafkkS35nv+mB6oWa5Ilq5txFaLtuoxyyQDPux3S4rEj9dS32icmwZmiEnq9EMYbW7c7H5y48HFGvjOcTylj6rzQNSwQRe2k33MMt3uPZJN0qAjDXuwOcFXARQwGu3xompBQR5h7UIJCixbjM7WDBW4u3yNuXY2+LYtYG8TIk3/KegvtC2KLdV9lv2R51djNNKU4uD9yNWudc=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0701MB2580;
x-microsoft-antispam-prvs: <AM5PR0701MB25804468CAEE736842BCB3748DA60@AM5PR0701MB2580.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AM5PR0701MB2580; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2580;
x-forefront-prvs: 01208B1E18
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(189002)(24454002)(377454003)(199003)(122556002)(5660300001)(2950100002)(5001770100001)(97736004)(9326002)(230783001)(87936001)(33656002)(3660700001)(107886002)(101416001)(8936002)(3280700002)(189998001)(76576001)(7696004)(74316002)(7906003)(7736002)(2900100001)(105586002)(586003)(3846002)(106356001)(50986999)(2501003)(54356999)(76176999)(102836003)(86362001)(68736007)(9686002)(7846002)(790700001)(81156014)(2906002)(8676002)(92566002)(81166006)(77096005)(66066001)(6116002)(21314002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2580; H:AM5PR0701MB2577.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB2577F8BE6920EAD0BF70E72D8DA60AM5PR0701MB2577_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2016 13:29:58.6824 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2580
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTURjHO3vfba/S4Dg1n9YgNzNMSC1LVlSWgcxUMKJcEeXKNxXntM0k I0gQy8xEmTpdiiWat9Ku5GUpLUnUrmh5yVm2fVBKMUqWmZnbWeC333n+/+fKYSjhPa6ISVKn sxq1UiXludLliieSzSkDEkXQtM5bZlys5stK6iy0bPEKtZeStxnMfHlNzTxHbmiz0jHUMddd 8awqKYPVBO6Jc00cm/7MSeu8eN7S8BFlocLMPOTCAN4Gfbk2Kg+5MkLcjOBGu4m2C0LcgyCn PsDONL5OwY+sw8Sk50C20cYhj2XTwlwvz+7iYT+oajUjO3tgNTQ2LvLzEMO440gY/3mJhKOg 1NzPJRwGE7dtiDTYAA/ndI4yAhwHbY+naFLfgEA/MuMQXLAM9Nm3HAkIrwFb3x2OnSnsBaPW Kg5ZB0ON8Q1F2BOmLH+5xH8UdEWv+CTuDS/KGmjC0ZBfOe9oBriagtrhEh4R5FBV8N3JqWAt /uLknZBb1MMlCUYEvfVlzkpimO3SOado5kJBYTC5Iwt1d3McU7tjEZgHrzpZDJNjT7mFyM+w YgnCqdAwVcczOK7hBr3lVtqwfEgKb4KW9kBikUDxtQk+YT/Iqajkr4zfRPxG5KlltadSErYG B7CapNNabao6QM2mP0DL/+jZowXfVjTwbZ8JYQZJVwtmS70VQq4yQ5uZYkLAUFIPwcBriUIo iFdmXmA1qSc151Ss1oTWMbTUSxDS8ClWiBOU6Wwyy6axmv8qh3ERZSF+aeefExVe4b+7rBP+ EnHM4OWIVQn9sZLdv4wfig+uHQgZ2j4dGeHytjNKqkpbGvI60yVmx/frQ0LDrfJuW75kR5nF u6P8+dkgY6ybr4clMUx0aHi0u0kWyZ33mam9PzXS4SOWTwZ+VeQWvl8fevzIUsvL3Hcto5ro pgMbJ4NTkqW0NlG5xZ/SaJX/APyGJxZDAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/aCuiJ5Ao4GRiFf29fSL-Go5tPQs>
Subject: Re: [MMUSIC] RFC5576 support in draft-ietf-mmusic-sdp-simulcast-06
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 08 Nov 2016 13:30:27 -0000

Hi Roni,

When would it be necessary to use “a=ssrc” to associate an SSRC with a particular simulcast stream already on SDP level?

Whenever the first RTCP SR is sent for a simulcast stream, it will contain both the SSRC reported on and an RtpStreamId SDES item, which uniquely associates that SSRC to an “a=rid” line. If the RTP SDES header extension is used, RtpStreamId can also be in RTP header extensions. Both methods should allow making this SSRC-to-RtpStreamId association before or at reception of the first RTP packet.

What “it is possible, but not required to use source-specific signaling” meant to say was that use of “a=ssrc” is not needed for use with “a=simulcast” (or “a=rid”), but also not conflicting with other (non-simulcast-related) usages of “a=ssrc”.

If you really want to use a static “a=ssrc” to RtpStreamId mapping in SDP, you can use a 1:1 mapping between RTP payload type and RtpStreamId (not same value, but a 1:1 mapping). It should, for example, be possible to use an SDP like:

a=ssrc:<x> cname:<c>
a=ssrc:<x> fmtp:<p>
a=rid:<r> pt=<p>

If “a=rid” was to be defined as source-level attribute (which it currently is not), you could maybe also use:
a=ssrc:<x> cname:<c>
a=ssrc:<x> rid:<r>
a=rid:<r> …

Cheers,
/Bo

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Roni Even
Sent: den 3 november 2016 17:12
To: 'Adam Roach' <adam@nostrum.com>; mmusic@ietf.org
Subject: Re: [MMUSIC] RFC5576 support in draft-ietf-mmusic-sdp-simulcast-06

Hi,
I am not sure how rid allows you to define an SSRC in the SDP and know in the SDP which SSRC is tied to each RTP payload subtype number explicitly.
Roni

From: Adam Roach [mailto:adam@nostrum.com]
Sent: Wednesday, November 02, 2016 10:00 PM
To: Roni Even; mmusic@ietf.org<mailto:mmusic@ietf.org>
Subject: Re: [MMUSIC] RFC5576 support in draft-ietf-mmusic-sdp-simulcast-06

On 11/2/16 13:07, Roni Even wrote:
Hi,

I noticed that section 5 state that “It is possible, but not required to use source-specific signaling [RFC5576<https://tools.ietf.org/html/rfc5576>] with the proposed solution.”



I was wondering what does it mean since if I try to add a=ssrc   to the example in 6.6.1, there will be two a=sscr:xxx cname:simulcast@example.com<mailto:cname:simulcast@example.com> and a=sscr:yyy canme:simulcast@example.com<mailto:canme:simulcast@example.com> but it is not clear which ssrc is the HD and which is the thumbnail

That's what RID is for.

/a

v2.23.0 | Report a Bug | By Email