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

"Roni Even" <ron.even.tlv@gmail.com> Wed, 16 November 2016 02:43 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 528E11295C0 for <mmusic@ietfa.amsl.com>; Tue, 15 Nov 2016 18:43:07 -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 k7iXlsht722f for <mmusic@ietfa.amsl.com>; Tue, 15 Nov 2016 18:43:05 -0800 (PST)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (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 3787C1295E2 for <mmusic@ietf.org>; Tue, 15 Nov 2016 18:43:05 -0800 (PST)
Received: by mail-pf0-x232.google.com with SMTP id 189so39707091pfz.3 for <mmusic@ietf.org>; Tue, 15 Nov 2016 18:43:05 -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=6HdIpUXQMpjuzF3UOla4Wuv82qLbvA2JMnbGu6LfVJY=; b=eA1V8dbyU+z6Lv2qVHuETlwo2D8wJ6/BJNNA9Bg0wWAmlJqp9Fgm3AT4dbt6KX0zJJ a1/PLWpd/I0SusKs5IV09cgZxogm0c2jy7j/CfbH8idc5hg7t7GtkNBoHIFtvkIp9fWH fS9Z8du8ARV0ds+O/thrlb/PPskB5pTC/XUPziaCre5Pv6iAxlYfN1GS4t5m1qkF6P9x NtHzdl8e/h58Fx51Hlj7xSzbL15Tg35EiZz6mJyRWe/4deaX9jgjQNaDeINs8QBqG93F WUkVqsiv/9+xySEYoPfqHZLWCIMFrovaQmG5/UvMzHGbkV8nTKQZEWrml7Ykak5gcIrw x1IA==
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=6HdIpUXQMpjuzF3UOla4Wuv82qLbvA2JMnbGu6LfVJY=; b=OxO+bApFfbD4nArjp1ZuzkRd6qT8Drc1uLreMH155ZHpQ+XecTSGky0YAAya0DEkAf 5lHhwOymXP8b/8W7q9WoFDFAZ/Mx8BWe0hRkM80kDvEIO55JWtTiMNLG0Ky/MZU3kKjg xeETyempf1KH/PgF9rr/iKPM9MD07Ndow4EYpOoQSH1jd6EYY9nN5fm7wmh8hCWRCRqp kFRqyPkPlcz8jxBQUIScPBRq2zqCliimJvlqrSc9i7LwwGJVe1VFvQKni02gl1ocT/st UF0kp/W80zi40PT+GUTt8CaGTDARTFcO1N4P9/5CJIhkRRToo84zTPsDOVlJWFiCoT1t dzBg==
X-Gm-Message-State: ABUngvetMQW9/bBfmmQ2U0slIRUO6xi3p6foiLm3GOqUJvbcPaQi+PLgwtnYvVPNN0s9Vw==
X-Received: by 10.98.13.130 with SMTP id 2mr1227324pfn.185.1479264184844; Tue, 15 Nov 2016 18:43:04 -0800 (PST)
Received: from RoniPC ([2001:67c:370:128:35d1:fafe:51d7:a225]) by smtp.gmail.com with ESMTPSA id p64sm47128487pfi.88.2016.11.15.18.43.01 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 15 Nov 2016 18:43:03 -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>
In-Reply-To: <AM5PR0701MB2577F8BE6920EAD0BF70E72D8DA60@AM5PR0701MB2577.eurprd07.prod.outlook.com>
Date: Wed, 16 Nov 2016 04:42:56 +0200
Message-ID: <00f501d23fb3$26180550$72480ff0$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F6_01D23FC3.E9A20DD0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQMfJL2eg+MLvkyl+NU6EMnaAVWjxwDP8umTAZPnvhMCJq8gqp4cyBVQ
Content-Language: he
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/UdINNSmobDPSeU82Xs4BEpS7xQk>
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 02:43:07 -0000

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>om>; 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