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

"Mo Zanaty (mzanaty)" <mzanaty@cisco.com> Thu, 22 October 2015 19:10 UTC

Return-Path: <mzanaty@cisco.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 7B8D91B3C89 for <mmusic@ietfa.amsl.com>; Thu, 22 Oct 2015 12:10:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n_06-1GJfZpU for <mmusic@ietfa.amsl.com>; Thu, 22 Oct 2015 12:10:17 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21C241B3C85 for <mmusic@ietf.org>; Thu, 22 Oct 2015 12:10:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11817; q=dns/txt; s=iport; t=1445541017; x=1446750617; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TOLiq7cxQGledC2ZW/zwW6E+0K3S7FfdMjXICHIFuCU=; b=l7OzrHxcFMSwlREzrGcySc+/gFuAE4V/abmN0lrJSWppGxzVblj4nm8V wjsFTvuzG2Hmf7wNLElktPDgRF0esWVMNmZHxJ2jUvbeQvPqktvz38ooD mmtaMSk2rKd2YvA8EEvGhON1aX9ZvRIHC0NKk9TcoV2RwVyPt7I1gEexE s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D3AQDhMylW/5xdJa1egmlNVG8GvhsBDYFZFwEJhTJKAoFLOBQBAQEBAQEBgQqELwEBBAEBASQGQQsQAgEIPwcnCxQRAgQOBYgwDcU/AQEBAQEBAQEBAQEBAQEBAQEBAQEBFASGd4R+hQkEBgGELgWNTYheAY0dnCUBHwEBQoIRHYFVcoR6Bj2BBgEBAQ
X-IronPort-AV: E=Sophos; i="5.20,184,1444694400"; d="scan'208,217"; a="40013055"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 22 Oct 2015 19:10:16 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t9MJAFiF012989 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Oct 2015 19:10:16 GMT
Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 22 Oct 2015 14:09:55 -0500
Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1104.000; Thu, 22 Oct 2015 14:09:55 -0500
From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Thread-Topic: [MMUSIC] RID, MID and BUNDLE: Associate received RTP packet with m- line
Thread-Index: AQHRDP08FVxa8lCg3UmThUOj4gS+KA==
Date: Thu, 22 Oct 2015 19:09:55 +0000
Message-ID: <D24EAB67.55D9C%mzanaty@cisco.com>
References: <7594FB04B1934943A5C02806D1A2204B37B87AF9@ESESSMB209.ericsson.se> <F4B61477-7BFB-4D20-8F49-E200D19A8911@cisco.com> <7594FB04B1934943A5C02806D1A2204B37B89868@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B89868@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.6.150930
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.81.3.39]
Content-Type: multipart/alternative; boundary="_000_D24EAB6755D9Cmzanatyciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/xB0L74R1_xINVioxAvENiJByaMc>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
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 19:10:20 -0000

Referring to BUNDLE works for warning implementers against relying on MID in every RTP packet. But the same warning is needed for RID regardless of whether BUNDLE is used or not.

Cheers,
Mo

On 10/22/15, 3:01 PM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:

Hi,

>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.

Or, you could simply refer to BUNDLE, because this is only going to be an issue when BUNDLE is used.

Regards,

Christer


Mo

On Oct 22, 2015, at 9:53 AM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> 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<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic