Re: [MMUSIC] RFC 6190 Single Session Transport

"Mo Zanaty (mzanaty)" <mzanaty@cisco.com> Mon, 17 June 2013 18:39 UTC

Return-Path: <mzanaty@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C778A21F9D8D for <mmusic@ietfa.amsl.com>; Mon, 17 Jun 2013 11:39:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezhO0N3XOR-H for <mmusic@ietfa.amsl.com>; Mon, 17 Jun 2013 11:38:56 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id EDE6D21F9D88 for <mmusic@ietf.org>; Mon, 17 Jun 2013 11:38:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11048; q=dns/txt; s=iport; t=1371494336; x=1372703936; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=+07TEalJFideO0sQjENhrpQHrenQaQeHQvJKJSikcZs=; b=L+rnFJIXAimGpzbCgXPLObrzRXc2BJySmJNi5Ta1CRPBKrEG5KzkVl81 HlutX59rQNUB87BwihUslOM5MbdaqIbifVxwOzkkiNbziqjmzRIt2D1tz KHQG+myawXOjbdUb/IQYHKLwCLEeVzbA/WXFHh0GXMq19IhKRNDjWMMOi M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhgFACVXv1GtJXHB/2dsb2JhbABbgkVEMUm+fX4WdIIjAQEBBC1cAgEIEQQBAQsdBzIUCQgCBAESCIgGuhWPFjcBgn9hA5NvlRWDD4Io
X-IronPort-AV: E=Sophos; i="4.87,882,1363132800"; d="scan'208,217"; a="220876576"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 17 Jun 2013 18:38:55 +0000
Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5HIcsMw030440 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Jun 2013 18:38:54 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Mon, 17 Jun 2013 13:38:54 -0500
From: "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] RFC 6190 Single Session Transport
Thread-Index: AQHOa38I8DtzGW8/TUuvjDTdB8v21Jk6MqQw
Date: Mon, 17 Jun 2013 18:38:54 +0000
Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D487E63@xmb-rcd-x14.cisco.com>
References: <BLU169-W630D4FBAA70899F6C54A0593830@phx.gbl>
In-Reply-To: <BLU169-W630D4FBAA70899F6C54A0593830@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.82.249.46]
Content-Type: multipart/alternative; boundary="_000_3879D71E758A7E4AA99A35DD8D41D3D91D487E63xmbrcdx14ciscoc_"
MIME-Version: 1.0
Subject: Re: [MMUSIC] RFC 6190 Single Session Transport
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 17 Jun 2013 18:39:01 -0000

My understanding of 6190 SST is a single SSRC for all layers, not multiple SSRCs (one per layer) within one RTP session. 6190 doesn't state this clearly, but otherwise SST would need all the same mst-mode stuff as MST, since mst-mode defines how receivers put packets into decoding order from multiple streams based on timestamps or Cross-Session Decoding Order Numbers (CS-DON).

I think you may be referring to the common industry practice of MST using the same port and thus the same RTP session, i.e. Multi-SSRC (rather than Session) Transmission. That is not standardized in 6190, but often used in practice. This often uses a single m-line, so it has no BUNDLE dependency. If it used multiple m-lines, your argument would be true for that case. BUNDLE (or some similar mechanism to mux m-lines onto one port) would be required for that type of MST to use the same port. But that does not seem to be a limitation of Plan A, since some mux mechanism is always required to do that type of MST regardless of Plan A.

Mo

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Monday, June 17, 2013 1:20 PM
To: mmusic@ietf.org
Subject: [MMUSIC] RFC 6190 Single Session Transport

At the virtual interim, a question arose about RFC 6190 Single Session Transport.

Here is what RFC 6190 Section 1 says:


   This memo defines two basic modes for transmission of SVC data,

   single-session transmission (SST) and multi-session transmission

   (MST).  In SST, a single RTP session is used for the transmission of

   all scalability layers comprising an SVC bitstream; in MST, the

   scalability layers are transported on different RTP sessions.

Section 1.2.2 clarifies the usage scenarios of SST and MST:



   SST should be used in point-to-point unicast applications and, in

   general, whenever the potential benefit of using multiple RTP

   sessions does not justify the added complexity...



   MST should be used in a multicast session when different receivers

   may request different layers of the scalable bitstream.

Since SST implies (by definition), use of a single RTP session to transport multiple layers, were plan A to be used for signaling, negotiation of SST would only be possible if both peers support BUNDLE, since otherwise distinct RTP ports would be required for each layer, which is incompatible with SST.

Today, existing SST implementations typically utilize a single m line.  As Jonathan noted, some implementations utilize the same SSRC for multiple layers, while others utilize distinct SSRCs.  Utilization of the same SSRC is possible, since separation of the layers can be handled within the H.264/SVC implementation.