Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-simulcast-02.txt

Bo Burman <> Wed, 07 October 2015 14:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C3E8E1A9251 for <>; Wed, 7 Oct 2015 07:59:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ePARGBep6ARx for <>; Wed, 7 Oct 2015 07:59:28 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 512411A923E for <>; Wed, 7 Oct 2015 07:59:27 -0700 (PDT)
X-AuditID: c1b4fb2d-f79626d000004282-6d-5615334dcc6c
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id C5.C9.17026.D4335165; Wed, 7 Oct 2015 16:59:25 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Wed, 7 Oct 2015 16:59:24 +0200
From: Bo Burman <>
To: "" <>
Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-simulcast-02.txt
Thread-Index: AQHRAGJMjnjbebOd7EiF2thChZBvF55gFseg
Date: Wed, 07 Oct 2015 14:59:23 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: sv-SE, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvja6vsWiYwYzbohZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxs/t55gLGjQrDpw8xtbA2K3QxcjJISFgIjF/1w0mCFtM4sK9 9WxdjFwcQgJHGSVWnnzOCOEsZpT4ff0vG0gVm4CGxPwddxlBbBEBdYmve3uYQWxhAQ+Jzf8n sUHEPSXWtM2Dso0kdq/qZgWxWQRUJLbsnwMW5xXwlfh6vBksLiTgIPHgZzt7FyMHB6eAo8TK u0ogYUYBWYn73++xgNjMAuISt57MhzpUQGLJnvPMELaoxMvH/1hBWiUEFCWW98tBlOtILNj9 iQ3C1pZYtvA1M8RWQYmTM5+wTGAUnYVk6iwkLbOQtMxC0rKAkWUVo2hxanFxbrqRsV5qUWZy cXF+nl5easkmRmBEHNzyW3cH4+rXjocYBTgYlXh4E1xEwoRYE8uKK3MPMUpzsCiJ87YwPQgV EkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwFhV5iA1QaOYb+Ii953OKdPZv72+2X0xYbXuy4lP a53cJi7Y+Db536+jfVtmJE+Pfl3WWSBVd+P/q6a9Dk25Np5HjqxdsWyaefeObF9FaYEWNv3Z rauucycn79ttJyGYaD45Ln/21ZkVyzc805t86GKce2b9xrNL7CTEVDiEp31oSFw33/7lew8l luKMREMt5qLiRAC7XCLJaQIAAA==
Archived-At: <>
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-simulcast-02.txt
X-Mailman-Version: 2.1.15
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, 07 Oct 2015 14:59:29 -0000

The main update in this version is to introduce use of RTP stream ID (RID) as identifier in addition to SDP format (RTP payload type), and aligns its use in simulcast with that draft (draft-pthatcher-mmusic-rid-00).

Summary of changes from -01:

   o  Relying on the new RID solution for codec constraints and
      configuration identification.  This has resulted in changes in
      syntax to identify if pt or RID is used to describe the simulcast

   o  Renamed simulcast version and simulcast version alternative to
      simulcast stream and simulcast format respectively, and improved
      definitions for them.

   o  Clarification that it is possible to switch between simulcast
      version alternatives, but that only a single one be used at any
      point in time.

   o  Changed the definition so that ordering of simulcast formats for a
      specific simulcast stream do have a preference order.

There are still a few open issues that need discussion (also included as editor's notes, except for the last one):

1) There is currently the possibility to set a simulcast as "sendrecv", but this is not a good match considering the uni-directionality of both PT and RID simulcast stream identifiers. I expect some complexity in this mismatch, requiring additional description, but was not able to investigate it further. It is also just an optimization to save a few bytes of SDP text in case simulcast send and receive direction is exactly the same for a certain simulcast stream identifier. I propose to remove "sendrecv" and just keep "send" and "recv", for simplicity.

2) There is a brief section on declarative use in SDP, but the RID specification currently lacks this, so it is not really possible to define in a good way. Should we add declarative use to RID, or should it be removed here?

3) With the chosen approach (only defining simulcast on SDP media level), it is not possible to spread simulcast streams onto different media transports, thus also making it impossible to use different flow-based QoS, or separate simulcast streams onto different multicast groups. Since this is described as being one potential motivation for using simulcast, either we have to state that the current solution deliberately does not deal with it, remove that motivation, or add the possibility for media transport separation of simulcast streams. The latter approach could possibly involve defining use of the simulcast attribute on SDP session level.

4) Since there are two alternative ways of identifying simulcast streams, should we require all implementations of simulcast to support both, or is one mandatory, and how is use of the optional one negotiated in that case?


> -----Original Message-----
> From: mmusic [] On Behalf Of
> Sent: den 6 oktober 2015 20:10
> To:
> Cc:
> Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-simulcast-02.txt
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.
>         Title           : Using Simulcast in SDP and RTP Sessions
>         Authors         : Bo Burman
>                           Magnus Westerlund
>                           Suhas Nandakumar
>                           Mo Zanaty
> 	Filename        : draft-ietf-mmusic-sdp-simulcast-02.txt
> 	Pages           : 24
> 	Date            : 2015-10-06
> Abstract:
>    In some application scenarios it may be desirable to send multiple
>    differently encoded versions of the same media source in different
>    RTP streams.  This is called simulcast.  This document discusses the
>    best way of accomplishing simulcast in RTP and how to signal it in
>    SDP.  A solution is defined by making an extension to SDP, and using
>    RTP/RTCP identification methods to relate RTP streams belonging to
>    the same media source.  The SDP extension consists of a new media
>    level SDP attribute that expresses capability to send and/or receive
>    simulcast RTP streams.  RTP/RTCP identification using either payload
>    types or a separately defined method for RTP stream configuration are
>    defined.
> The IETF datatracker status page for this draft is:
> There's also a htmlized version available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are
> available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> mmusic mailing list