Re: [MMUSIC] RFC 6190 Single Session Transport
Adam Roach <adam@nostrum.com> Mon, 17 June 2013 17:32 UTC
Return-Path: <adam@nostrum.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 A4F7F21F9B5D for <mmusic@ietfa.amsl.com>; Mon, 17 Jun 2013 10:32:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
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 PZk6SIFvtmS3 for <mmusic@ietfa.amsl.com>; Mon, 17 Jun 2013 10:32:52 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0B20821F96D9 for <mmusic@ietf.org>; Mon, 17 Jun 2013 10:32:51 -0700 (PDT)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r5HHWluF081470 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 12:32:47 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <51BF483E.3080606@nostrum.com>
Date: Mon, 17 Jun 2013 12:32:46 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Bernard Aboba <bernard_aboba@hotmail.com>
References: <BLU169-W630D4FBAA70899F6C54A0593830@phx.gbl>
In-Reply-To: <BLU169-W630D4FBAA70899F6C54A0593830@phx.gbl>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
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 17:32:52 -0000
On 6/17/13 12:20, Bernard Aboba wrote: > 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. I don't think that assertion has a basis in reality, but I could simply be misunderstanding what you're trying to say. English is imprecise, and it's clear that we're not having a meeting of minds here. Let's try a different language. You send an e-mail to the list containing the SDP currently exchanged by SIP endpoints for SST. I'll send SDP in an e-mail reply that shows how it works under Plan A. Sound good? /a
- [MMUSIC] RFC 6190 Single Session Transport Bernard Aboba
- Re: [MMUSIC] RFC 6190 Single Session Transport Adam Roach
- Re: [MMUSIC] RFC 6190 Single Session Transport Mo Zanaty (mzanaty)
- Re: [MMUSIC] RFC 6190 Single Session Transport Bernard Aboba
- Re: [MMUSIC] RFC 6190 Single Session Transport Jonathan Lennox
- Re: [MMUSIC] RFC 6190 Single Session Transport Bernard Aboba
- Re: [MMUSIC] RFC 6190 Single Session Transport Jonathan Lennox
- Re: [MMUSIC] RFC 6190 Single Session Transport Roni Even
- Re: [MMUSIC] RFC 6190 Single Session Transport Mo Zanaty (mzanaty)