[MMUSIC] BUNDLE: receiver-id text

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 21 August 2014 09:52 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16C71A00CA for <mmusic@ietfa.amsl.com>; Thu, 21 Aug 2014 02:52:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 yyoHISr50M_R for <mmusic@ietfa.amsl.com>; Thu, 21 Aug 2014 02:52:23 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B6F31A00D1 for <mmusic@ietf.org>; Thu, 21 Aug 2014 02:52:21 -0700 (PDT)
X-AuditID: c1b4fb2d-f793d6d000005356-f1-53f5c15381b2
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 59.AF.21334.351C5F35; Thu, 21 Aug 2014 11:52:20 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0174.001; Thu, 21 Aug 2014 11:52:19 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: BUNDLE: receiver-id text
Thread-Index: Ac+8eVzWUZ+sCQn4TayP+LcUZEdZdgAq84cA
Date: Thu, 21 Aug 2014 09:52:18 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D42516E@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.17]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D42516EESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+JvjW7Iwa/BBo/tLaYuf8ziwOixZMlP pgDGKC6blNSczLLUIn27BK6MnfdZC6aeZqw4eWIyYwPjm82MXYycHBICJhLTbrxlgrDFJC7c W8/WxcjFISRwlFGi/+sLFghnCaPEpv+3gDIcHGwCFhLd/7RBGkQE1CW+7u1hBrGFBRQlHt2A GCoioCZx9ddmJgjbSOLoyQcsIDaLgKrEw1+9rCA2r4CvxO8pU8FsRqDF30+tAatnFhCXuPVk PtRBAhJL9pxnhrBFJV4+/scKcoIE0K7l/XIQ5fkSjR83Q40UlDg58wnLBEahWUgmzUJSNgtJ GURcR2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/FKFqcWlycm25krJdalJlcXJyfp5eXWrKJ ERgRB7f81t3BuPq14yFGAQ5GJR7eByu/BAuxJpYVV+YeYpTmYFES5110bl6wkEB6Yklqdmpq QWpRfFFpTmrxIUYmDk6pBkav6+s5k7I+NPofXsPpELP2W+4CE/05STt03M/+qQ+O/L/GNXrb HI8rwnwtJWkZJ69uPpuglXSocX/Yskknwy36VH/9uXJnfqrk60yHlS7uakcuOisr223f9zv/ rMyx7J1XN7/Z89Uwv+pMT/KlLZUt7+aU+lrx73zC/nL1DIXFyzg0+P8Je7sqsRRnJBpqMRcV JwIADCEYV2kCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/vHDmfYWVinOnD95s3DnlPgpsZjI
Subject: [MMUSIC] BUNDLE: receiver-id text
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 21 Aug 2014 09:52:26 -0000

Hi,

Below is the first version of the "receiver-id" text, which defines the new SDES item and RTP header extension for transporting the mid value.

I intend to organize a phone meeting at some point, to discuss this, but before that I think it's good to have some e-mail discussions :)

Thanks to Colin and Bo for performing an initial review of the text.

Regards,

Christer


--------------

11.  Receiver ID Mechanism

11.1.  General

   SDP Offerers and Answerers [RFC3264] can assign values, mid values,
   to SDP Media Descriptions (m= lines) within SDP Offers and Answers,
   using the procedures in [RFC5888].  Each mid value uniquely
   references an m= line.

   This section defines a new RTP SDES item [RFC3550], 'MID', which is
   used to carry mid values within RTCP SDES packets.  This section also
   defines a new RTP header extension [RFC5285], which can be used to
   carry the mid value in RTP packets.

   The SDES item and RTP header extension makes is possible for a
   receiver to associate received RTCP- and RTP packets with a specific
   m= line, to which the receiver has assigned a mid value, even if
   those m= lines are part of the same RTP session.  The endpoint
  informs the remote endpoint about the mid values using the procedures
   in [RFC5888], and the remote endpoint then inserts the mid values in
   RTCP- and RTP packets sent towards the other endpoint.

   NOTE: This text above defines how the mid value is carried in SDP
   Offers and Answers.  The usage of other signalling protocols for
   carrying the mid value is not prevented, but the usage of such
   protocols is outside the scope of this document.

   The RTP MID SDES item SHOULD be sent in the first few RTCP packets
   sent on joining the session, and SHOULD be sent regularly thereafter.
   The exact number of RTCP packets in which this SDES item is sent is
   intentionally not specified here, as it will depend on the expected
   packet loss rate, the RTCP reporting interval, and the allowable
   overhead.

   The RTP MID header extension SHOULD be included in some RTP packets
   at the start of the session and whenever the SSRC changes.  It might
   also be useful to include the header extension in RTP packets that
   comprise random access points in the media (e.g., with video
   I-frames).  The exact number of RTP packets in which this header
   extension is sent is intentionally not specified here, as it will
   depend on expected packet loss rate and loss patterns, the overhead
   the application can tolerate, and the importance of immediate receipt
   of the mid value.

   For robustness purpose, endpoints need to be prepared for situations
   where the mid value is delayed, and SHOULD NOT terminate sessions in
   such cases, as the mid value is likely to arrive soon.


11.2.  RTP MID SDES Item


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      MID=TBD  |     length    | mid value                   ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The mid value payload is UTF-8 encoded, as in SDP.

11.3.  RTP MID Header Extension

   The payload, containing the mid value, of the RTP MID header
   extension element can be encoded using either the one-byte or two-
   byte header [RFC5285].  The mid value payload is UTF-8 encoded, as in
   SDP.

11.4.  IANA Considerations

   [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
   document.]

   [RFC EDITOR NOTE: Please replace TBD with the assigned SDES
   identifier value.]

   This document adds the MID SDES item to the IANA "RTP SDES item
   types" registry as follows:


       Value:      TBD
       Abbrev.:    MID
       Name:       Media Identification
       Reference:  RFCXXXX


   This document defines a new extension URI in the RTP Compact Header
   Extensions subregistry of the Real-Time Transport Protocol (RTP)
   Parameters registry, according to the following data:


       Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid
       Description:   Media identification
       Contact:       christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>
       Reference:     RFCXXXX