IETF Logo Mail Archive

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

"DOLLY, MARTIN C" <md3135@att.com> Wed, 02 March 2016 16:59 UTC

Return-Path: <md3135@att.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 DF0F11B2C7E for <mmusic@ietfa.amsl.com>; Wed, 2 Mar 2016 08:59:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level:
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] 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 TCE6gSw-1oj2 for <mmusic@ietfa.amsl.com>; Wed, 2 Mar 2016 08:59:37 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF0551B2C7C for <mmusic@ietf.org>; Wed, 2 Mar 2016 08:59:33 -0800 (PST)
Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id u22Gsboa001551; Wed, 2 Mar 2016 11:59:29 -0500
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 21b9d8nr9n-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 02 Mar 2016 11:59:29 -0500
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u22GxR7w029877; Wed, 2 Mar 2016 11:59:28 -0500
Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u22GxHdx029672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 2 Mar 2016 11:59:20 -0500
Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Wed, 2 Mar 2016 16:58:57 GMT
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.77]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0248.002; Wed, 2 Mar 2016 11:58:57 -0500
From: "DOLLY, MARTIN C" <md3135@att.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, Roman Shpount <roman@telurix.com>
Thread-Topic: [MMUSIC] Offer/Answer PT Questions - text proposal
Thread-Index: AdFv1i1li4hZHAkDRvW27hH21f813wARGIiAAAEzHQAAFHhLgAANDP0AAABf9wAAANkcgAABPnAAAACT0gAAARuRgAAArliAACAJAYAADgPBAABONv0AABK4WIAAAjCagAAJzjpQAAHc3IAAAjRVsP//+M8A///qvQCAABy3gP//EC7QgAIshgCAABdfgIAAC8qAgAACyYCAAAR8AP/+rXUwAGEx9QAAAK4ygAABBaqAAAmXjjA=
Date: Wed, 02 Mar 2016 16:58:57 +0000
Message-ID: <E42CCDDA6722744CB241677169E8365615E662A8@MISOUT7MSGUSRDB.ITServices.sbc.com>
References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <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> <CAD5OKxtXzhP9L-V6O5NVtCN4aQHy9X8Fpkc0_xKdWmtR03h4KQ@mail.gmail.com> <56D5EE38.2060706@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E5401A@ESESSMB209.ericsson.se> <56D70A1E.4020108@alum.mit.edu> <CAD5OKxtt2w=RB6FvsHwWeWBb1mSF7pO2+hBZM2VtgKAin846uw@mail.gmail.com> <56D7158B.4060104@alum.mit.edu>
In-Reply-To: <56D7158B.4060104@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.70.235.142]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-02_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1603020309
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/Coju7dJCE3Zx32oNyJRuacKLbeg>
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 16:59:39 -0000

Greetings from the land of Folks who deploy equipment and manage networks,

Where are we?

Thanks,

Martin

-----Original Message-----
From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: Wednesday, March 02, 2016 11:32 AM
To: Roman Shpount <roman@telurix.com>
Cc: mmusic@ietf.org; Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal

On 3/2/16 11:02 AM, Roman Shpount wrote:
> On Wed, Mar 2, 2016 at 10:43 AM, Paul Kyzivat <pkyzivat@alum.mit.edu 
> <mailto:pkyzivat@alum.mit.edu>> wrote:
>
>     On 3/2/16 9:47 AM, Christer Holmberg wrote:
>
>             *If* it is really the case that there is no relationship
>             between O/A and the lifetime of RTP sessions, then
>             we have some work to do to sort out what the relationship is
>             between what is in the O/A and what is in the RTP session.
>
>             IIUC, in the case where the is no RTP session prior an
>             offer, the O/A must at least establish some initial PT
>             bindings for the session-to-be.
>
>             (I have a feeling that what we are discussing is quite
>             fundamental, and I find it shocking if it hasn't been
>             considered in the past.)
>
>
>         I still don't get it... :)
>
>         When you negotiate an SDP session, unless you use BUNDLE, each
>         m- line is associated with a different RTP session. You
>         negotiate what PT bindings you are going to use within that SDP
>         session.
>
>         If some SDP properties change - due to a RTP session change or
>         whatever else - then a new O/A exchange is obviously needed.
>         Nothing new about that.
>
>         But, as has been indicated, the change of RTP session does not
>         automatically mandate new PT bindings, so I don't see why we
>         need to consider RTP sessions when we talk about PT bindings.
>
>
>     The problem is that we have two goals that in some cases seem to
>     conflict.
>
>     On one hand you want to manage O/A state. For the most part that
>     includes the results of the most recent successful O/A exchange (the
>     resulting local and remote SDP), and possibly another offer that is
>     in progress. But based on 3264 it also seems to include, for each
>     m-line, all the PT bindings ever made for the duration of this O/A
>     session.
>
>     OTOH, it seems to be necessary for the PT bindings for an m-line to
>     be consistent with the PT bindings of the RTP session currently in
>     effect for that m-line. If that RTP session can change arbitrarily,
>     then it potentially can be replaced by one that is inconsistent with
>     the PT bindings of the O/A session.
>
>     Somehow that inconsistency needs to be resolved.
>
>
> The problem is that if you have multiple O/A exchanges happening in 
> rapid succession, you can get RTP packets for any of the previous O/A 
> exchanges. This means you can have a new RTP session being set up for 
> any of the recent O/A exchanges. Unless you have an additional way to 
> demultiplex, such as using a different local transport, ssrc or mid, 
> you will need to map the received RTP packet to a particular O/A exchange.
> The only way left is PT.
>
> In reality this means you need to track last successful O/A, O/A in 
> progress, and all the successful O/A exchanges that completed recently 
> for which it is still possible to receive RTP packets. In most cases, 
> O/A exchange typically takes a lot longer then media flow setup, so 
> that you can limit the history to  last successful O/A and O/A in progress.
> On the other hand, if ICE with TURN and DTLS are used, you can have 
> multiple RTP session setups in progress when corresponding O/A 
> exchanges have already completed.

I agree with you, at least in principle.

The question is: how much of this do we need to deal with in a normative way? At some point we may want to simply expect the implementer to avoid shooting himself in the foot.

	Thanks,
	Paul

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

v2.23.0 | Report a Bug | By Email