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

Adam Roach <adam@nostrum.com> Thu, 22 October 2015 14:40 UTC

Return-Path: <adam@nostrum.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 CDF091B3875 for <mmusic@ietfa.amsl.com>; Thu, 22 Oct 2015 07:40:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 oa7k0sepQlPu for <mmusic@ietfa.amsl.com>; Thu, 22 Oct 2015 07:40:07 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 796D51B3872 for <mmusic@ietf.org>; Thu, 22 Oct 2015 07:40:05 -0700 (PDT)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9MEdxrw048687 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 22 Oct 2015 09:40:00 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <7594FB04B1934943A5C02806D1A2204B37B87AF9@ESESSMB209.ericsson.se>
From: Adam Roach <adam@nostrum.com>
Message-ID: <5628F53F.7030800@nostrum.com>
Date: Thu, 22 Oct 2015 09:39:59 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B87AF9@ESESSMB209.ericsson.se>
Content-Type: multipart/alternative; boundary="------------070709030606010900030704"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/JX5wIoXqG58ucWVlxqrvuoz6Hjs>
Subject: Re: [MMUSIC] RID, MID and BUNDLE: Associate received RTP packet with m- line
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: <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: Thu, 22 Oct 2015 14:40:11 -0000

As long as the recipient has seen both the MID for an SSRC and the RID 
for an SSRC, then it can perform the proper correlation.

If they haven't seen the MID yet, then they can't use the stream because 
they don't know what m-section it goes with.

/a

On 10/22/15 08:53, Christer Holmberg wrote:
>
> Hi,
>
> 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
>
>    I-frames).”
>
> 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?
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic