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

"Roni Even" <ron.even.tlv@gmail.com> Wed, 16 November 2016 21:28 UTC

Return-Path: <ron.even.tlv@gmail.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 B9DC01294E6 for <mmusic@ietfa.amsl.com>; Wed, 16 Nov 2016 13:28:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.689
X-Spam-Level:
X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 (2048-bit key) header.d=gmail.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 AhTbuJX_ifP4 for <mmusic@ietfa.amsl.com>; Wed, 16 Nov 2016 13:27:58 -0800 (PST)
Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6639B129456 for <mmusic@ietf.org>; Wed, 16 Nov 2016 13:27:58 -0800 (PST)
Received: by mail-pf0-x236.google.com with SMTP id 189so44711989pfz.3 for <mmusic@ietf.org>; Wed, 16 Nov 2016 13:27:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :thread-index:content-language; bh=PDDVFkUumFQCo5TIj0w8bdKK3Ggah62AS/QBxJzEEic=; b=I/PU811jgGGRWIYMlSK5586b05FRRMP3+LlqU03hFRISmlIGxSgFFfmXbpEExU45n3 JIZb3Y31SPDqswZms8/t0hWyMoQPTyqix6clEsNpddirCVL/IdPeTDlmP1ap+pay4qhE odFsAo/qJxHRFaFRrZ3FzJblQIzSL5TJsqRrwFmtH+ib7PVYNDjGAPLfmp73O5qEfUzn d3QZ/2Q+BGGAtrtWuW1sVmf1voKojRE0MsojFlu4g9SAKXPIebFUyS+uIWUWDCxMFgcr WoULKPTtk/HXdnall8KbzzJbUpJqrozst7rgFKNjUlMorzd1Hn+ouei1hXmSba4RZqza wPOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=PDDVFkUumFQCo5TIj0w8bdKK3Ggah62AS/QBxJzEEic=; b=JFh5Wl0EK3XJJHsO2m8/GAsCD28k5zrx4CR0GckF+ajyDhEgMPtNB8Ot1e3aMFvnwy 4mru4Rh+w1KlL6hZHrvC2o9aHR//NtfzOwxnG8QLVOIgL3DnGgwsVI64ZDmiyGv8a79D WAhCjox8IR9HWoiKKmoMXwy+jhStw+RjsC55nz+WR5EKdJkHyIab0v7peQznTfC+ZduU 803x3NFLPYsm4TDTrZ84bzZl08gTmA8MJiVGLnaAzEh/UB5ubozz0mapgNABK8Xf6dm8 2jwJrojMVXJx3dsZwczJlBWlx2uRnkjLaowkvj6yIEBv+AeZdxJ9QLGN5eP9VSxjRY0x tx0g==
X-Gm-Message-State: ABUngvcR+FQQQrMIirfA5Nd4jKIj3aTqFDTgGiKWXubyM3vFBfqZ0vvJH/BTRohs4N72EA==
X-Received: by 10.98.213.7 with SMTP id d7mr7550951pfg.3.1479331677932; Wed, 16 Nov 2016 13:27:57 -0800 (PST)
Received: from RoniPC ([2001:67c:370:144:59a:2123:a01d:619b]) by smtp.gmail.com with ESMTPSA id 131sm56784637pfx.92.2016.11.16.13.27.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 16 Nov 2016 13:27:56 -0800 (PST)
From: Roni Even <ron.even.tlv@gmail.com>
To: 'Bo Burman' <bo.burman@ericsson.com>, 'Adam Roach' <adam@nostrum.com>, mmusic@ietf.org
References: <017801d23533$eecde1c0$cc69a540$@gmail.com> <f7091657-0591-903b-792e-8a1b3c1109ec@nostrum.com> <024b01d235ec$ff25b160$fd711420$@gmail.com> <AM5PR0701MB2577F8BE6920EAD0BF70E72D8DA60@AM5PR0701MB2577.eurprd07.prod.outlook.com> <00f501d23fb3$26180550$72480ff0$@gmail.com> <AM5PR0701MB257704A313B09BD6094841828DBE0@AM5PR0701MB2577.eurprd07.prod.outlook.com>
In-Reply-To: <AM5PR0701MB257704A313B09BD6094841828DBE0@AM5PR0701MB2577.eurprd07.prod.outlook.com>
Date: Wed, 16 Nov 2016 23:27:53 +0200
Message-ID: <01ec01d24050$4b987650$e2c962f0$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01ED_01D24061.0F22CCF0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQMfJL2eg+MLvkyl+NU6EMnaAVWjxwDP8umTAZPnvhMCJq8gqgGh8un2AgXpfCGeAMMeMA==
Content-Language: he
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/LKxrO_w_vNhU_XPgNkqXiiLnvNs>
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: Wed, 16 Nov 2016 21:28:01 -0000

Hi Bo,

You can define rid usage but in my view this is a general problem of using ssrc attribute when there is more than one simultaneous stream in an m-line section. So maybe it should be addressed in an update to RFC5576 as a general solution.

Roni

 

From: Bo Burman [mailto:bo.burman@ericsson.com] 
Sent: Wednesday, November 16, 2016 12:37 PM
To: Roni Even; 'Adam Roach'; mmusic@ietf.org
Subject: RE: [MMUSIC] RFC5576 support in draft-ietf-mmusic-sdp-simulcast-06

 

Hi Roni,

 

I thought it was, but when looking a bit more closely it is clear that it is not allowed.

It would still be possible to use source-specific signaling and simulcast independently from one another, but it would not be possible to tell from the SDP which SSRC a specific simulcast stream will have. As said, one way to solve that could be to define source-specific usage of a=rid.

 

/Bo

 

From: Roni Even [mailto:ron.even.tlv@gmail.com] 
Sent: den 16 november 2016 11:43
To: Bo Burman <bo.burman@ericsson.com>; 'Adam Roach' <adam@nostrum.com>; mmusic@ietf.org
Subject: RE: [MMUSIC] RFC5576 support in draft-ietf-mmusic-sdp-simulcast-06

 

Hi Bo,

Are you sure it is allowed to use a=ssrc:<x> fmtp:<p> without any format specific parameters?

Roni

 

From: Bo Burman [mailto:bo.burman@ericsson.com] 
Sent: Tuesday, November 08, 2016 3:30 PM
To: Roni Even; 'Adam Roach'; mmusic@ietf.org
Subject: RE: [MMUSIC] RFC5576 support in draft-ietf-mmusic-sdp-simulcast-06

 

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
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 and a=sscr:yyy 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