IETF Logo Mail Archive

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

"Mo Zanaty (mzanaty)" <mzanaty@cisco.com> Thu, 22 October 2015 19:13 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 39C251B3CDA for <mmusic@ietfa.amsl.com>; Thu, 22 Oct 2015 12:13:55 -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 cGOp7L9i4zTt for <mmusic@ietfa.amsl.com>; Thu, 22 Oct 2015 12:13:52 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57BFE1B3CDC for <mmusic@ietf.org>; Thu, 22 Oct 2015 12:13:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12492; q=dns/txt; s=iport; t=1445541232; x=1446750832; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Xsd3sikO3hqmZYwA6SOL+oe+xRB9hvQNkaIR/a6zzL0=; b=dwwds6c2tEr8OtLglNlWyHfl6a0/GoCEHSj7BjXVF1Chs6/VqX5xRhke rfxXB+ae9pNvyNSfR0XBxZMMU90Kw+mkJaeO0xchWqEri7lv9iGPbM5zW OVf4rW+YpGGtn/Zn9qmFYJMoiemnL6/zElu+lKw/2aN4JivOHnEjbHvFD s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D9AQDRNClW/5BdJa1egmlNVG8GvhsBDYFZFwEJhTJKAoFLFCQUAQEBAQEBAYEKhC8BAQMBAQEBKkEQCwIBCD8HJwsUEQIEARKIKAgNxS8BAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZ3hH6ENFUKAYQuBY1NiF4BjR2cJQEfAQFCghEdgVVyhHpDgQYBAQE
X-IronPort-AV: E=Sophos;i="5.20,184,1444694400"; d="scan'208,217";a="200639275"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP; 22 Oct 2015 19:13:51 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t9MJDpI7027898 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Oct 2015 19:13:51 GMT
Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 22 Oct 2015 14:13:30 -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:13:30 -0500
From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Adam Roach <adam@nostrum.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] RID, MID and BUNDLE: Associate received RTP packet with m- line
Thread-Index: AQHRDP285u2rxKIU60W92dkJ1lMZxw==
Date: Thu, 22 Oct 2015 19:13:30 +0000
Message-ID: <D24EACDE.55DA7%mzanaty@cisco.com>
References: <7594FB04B1934943A5C02806D1A2204B37B87AF9@ESESSMB209.ericsson.se> <5628F53F.7030800@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37B89827@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B89827@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_D24EACDE55DA7mzanatyciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/YlVs95Tx6W34lDIDkZcyLODBqa0>
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:13:55 -0000

RID (like MID and all SDES items) is limited to 255 octets. No risk of exhaustion, so offerers are free to make them unique across the whole SDP if they want.

Cheers,
Mo

On 10/22/15, 3:00 PM, mmusic on behalf of Christer Holmberg <mmusic-bounces@ietf.org<mailto:mmusic-bounces@ietf.org> on behalf of christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:

Hi,

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

That's what I assumed, and it's the same way BUNDLE works (where you send the RTP MID until you assume the other endpoint has seen the SSRC).

It would probably be a good idea to modify the text in the draft to reflect that.

BTW, is there a reason why the RID value can't be unique for the whole SDP? Is there a risk we'd run out of values? What is the value range that "fits" into the RID RTP header extension?

Regards,

Christer


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<mailto:mmusic@ietf.org>

https://www.ietf.org/mailman/listinfo/mmusic

v2.23.0 | Report a Bug | By Email