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

"Roni Even" <> Wed, 16 November 2016 02:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 528E11295C0 for <>; Tue, 15 Nov 2016 18:43:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.689
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k7iXlsht722f for <>; Tue, 15 Nov 2016 18:43:05 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3787C1295E2 for <>; Tue, 15 Nov 2016 18:43:05 -0800 (PST)
Received: by with SMTP id 189so39707091pfz.3 for <>; Tue, 15 Nov 2016 18:43:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 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 with ESMTPSA id p64sm47128487pfi.88.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 15 Nov 2016 18:43:03 -0800 (PST)
From: "Roni Even" <>
To: "'Bo Burman'" <>, "'Adam Roach'" <>, <>
References: <017801d23533$eecde1c0$cc69a540$> <> <024b01d235ec$ff25b160$fd711420$> <>
In-Reply-To: <>
Date: Wed, 16 Nov 2016 04:42:56 +0200
Message-ID: <00f501d23fb3$26180550$72480ff0$>
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: <>
Subject: Re: [MMUSIC] RFC5576 support in draft-ietf-mmusic-sdp-simulcast-06
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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?



From: Bo Burman [] 
Sent: Tuesday, November 08, 2016 3:30 PM
To: Roni Even; 'Adam Roach';
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> …





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



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.



From: Adam Roach [] 
Sent: Wednesday, November 02, 2016 10:00 PM
To: Roni Even;
Subject: Re: [MMUSIC] RFC5576 support in draft-ietf-mmusic-sdp-simulcast-06


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


I noticed that section 5 state that “It is possible, but not required to use source-specific signaling [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 and a=sscr:yyy but it is not clear which ssrc is the HD and which is the thumbnail

That's what RID is for.