Re: [MMUSIC] RID, MID and BUNDLE: Associate received RTP packet with m- line

"Mo Zanaty (mzanaty)" <> Thu, 22 October 2015 14:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 034641A0404 for <>; Thu, 22 Oct 2015 07:43:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7eWpfkeYCidC for <>; Thu, 22 Oct 2015 07:43:03 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 64DF01AC3ED for <>; Thu, 22 Oct 2015 07:43:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=8651; q=dns/txt; s=iport; t=1445524983; x=1446734583; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DkXcebJf+a9Wj9RhRdHFtA3kMGM/ed6i+hne3ibHS24=; b=BdA1fUNqqCoJWwriXfG/YetJf5oKDV7NSqS0a2cbTyikyiyHDnY3mJ+T crZPVdXkIGa9F+SWUTe74M85B38GX40PxxXGfNV1cGlysVkaoZO/glmle YlWINQe2Mtz4G4rjB9QO9MLFvTxzfQHSts5cDq2cFJzP1tyWESH/DTq2O A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.20,182,1444694400"; d="scan'208,217";a="200534646"
Received: from ([]) by with ESMTP; 22 Oct 2015 14:43:02 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t9MEh2Pg030102 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Oct 2015 14:43:02 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 22 Oct 2015 09:42:42 -0500
Received: from ([]) by ([]) with mapi id 15.00.1104.000; Thu, 22 Oct 2015 09:42:42 -0500
From: "Mo Zanaty (mzanaty)" <>
To: Christer Holmberg <>
Thread-Topic: [MMUSIC] RID, MID and BUNDLE: Associate received RTP packet with m- line
Thread-Index: AdEM0NpupxLRaWp2TMel0/yQAaXVSwABw2m+
Date: Thu, 22 Oct 2015 14:42:42 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_F4B614777BFB4D208F49E200D19A8911ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [MMUSIC] RID, MID and BUNDLE: Associate received RTP packet with m- line
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: Thu, 22 Oct 2015 14:43:06 -0000

MID and RID are both RTCP SDES items that echo SDP identifiers in RTP/RTCP using the generic sdes-hdrext mechanism. Once the identifier value is associated to an RTP stream (identified by its SSRC) via RTCP packets with MID/RID SDES items or RTP packets with MID/RID header extensions, the association can remain in effect without echoing the header extension in every RTP packet.

We should probably add some text to warn implementers not to rely on receiving MID and RID in every RTP packet, and use the last valid association to that SSRC when absent.


On Oct 22, 2015, at 9:53 AM, Christer Holmberg <<>> wrote:


Section 7 of the RID draft says:

"Note that 'rid's are only required to be unique within a media
   section ("m-line"); they do not necessarily need to be unique within
   an entire RTP session.  In traditional usage, each media section is
   sent on its own unique 5-tuple, which provides an unambiguous scope.
   Similarly, when using BUNDLE
   [I-D.ietf-mmusic-sdp-bundle-negotiation], MID values associate RTP
   streams uniquely to a single media description."

However, when BUNDLE is used, the MID value (RTP MID header extension) is not guaranteed to be present in every RTP packet. Section 14.1. of BUNDLE says:

"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

So, if the MID value is NOT included, and RTP packets associated with multiple m- lines use the same RIP value and the same PT value, will it be possible to associate the RTP packets to a single media description?



mmusic mailing list<>