IETF Logo Mail Archive

Re: [MMUSIC] Offer/Answer PT Questions - text proposal

Colin Perkins <csp@csperkins.org> Wed, 02 March 2016 22:03 UTC

Return-Path: <csp@csperkins.org>
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 272E01B3296 for <mmusic@ietfa.amsl.com>; Wed, 2 Mar 2016 14:03:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_110=0.6] autolearn=no
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 EOwUiHSeSgxM for <mmusic@ietfa.amsl.com>; Wed, 2 Mar 2016 14:03:45 -0800 (PST)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C5EF1B3281 for <mmusic@ietf.org>; Wed, 2 Mar 2016 14:03:36 -0800 (PST)
Received: from [81.187.2.149] (port=45113 helo=[192.168.0.86]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <csp@csperkins.org>) id 1abErl-0005Rb-Tr; Wed, 02 Mar 2016 22:03:34 +0000
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <56D5E81F.2040306@alum.mit.edu>
Date: Wed, 02 Mar 2016 22:03:29 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <E2650620-CC0D-42D7-A775-A44BB4105F76@csperkins.org>
References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <56D08962.3060006@alum.mit.edu> <CAD5OKxtRB-f84=axhq_mkuyGXcq8nLCU2T6+6y=DNv9Ng1tKPQ@mail.gmail.com> <56D09563.9040509@alum.mit.edu> <CAD5OKxvwJwKoaaMHDDA8AKYdd2Rc8vOK_dnOftvozX+FbfqHOQ@mail.gmail.com> <56D1CA6C.70700@alum.mit.edu> <CAD5OKxt5jp44Saop+ssdPENBsRBNbkFUXFphZHMwqYDFLNWFpg@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E4BD38@ESESSMB209.ericsson.se> <56D463A3.8070007@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4D5E9@ESESSMB209.ericsson.se> <56D4B1F1.2070706@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4D951@ESESSMB209.ericsson.se> <66F2264B-3CA3-4650-88B6-89FC64D5FD29@csperkins.org> <7594FB04B1934943A5C02806D1A2204B37E4DB7C@ESESSMB209.ericsson.se> <56D4C0F5.50901@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E4EAD1@ESESSMB209.ericsson.se> <56D5CAA0.2060901@alum.mit.edu> <CAD5OKxtdmhW-opmp2TQou5wYbz70FdUvftr1PAZb9YiW4crevA@mail.gmail.com> <56D5E81F.2040306@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.3112)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/H1DdeFb8KKOocWeR6fkAv9pBTv0>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal
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: Wed, 02 Mar 2016 22:03:46 -0000

> On 1 Mar 2016, at 19:06, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> On 3/1/16 1:23 PM, Roman Shpount wrote:
> 
>> What really bugs me about this discussion is that it is extremely
>> difficult to determine when RTP session is started or stopped based on
>> O/A exchanges. Because of this it is difficult to determine when it is
>> safe to reuse PT for something else just by looking at O/A.
> 
> Well, can we assume that if the addr/port changes at one of the ends then this is to be a new RTP session?

The RTP session is tied to the shared SSRC space. If the same SSRCs are valid after the change, it’s the same RTP session.

> Are there cases where nothing in the SDP changes but a new RTP session is established? (Or can we require signaling in this case?)
> 
> Maybe we need to start using the a=connection attribute with RTP to indicate change of RTP session. :-)
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic



-- 
Colin Perkins
https://csperkins.org/

v2.23.0 | Report a Bug | By Email