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

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 29 February 2016 13:28 UTC

Return-Path: <christer.holmberg@ericsson.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 35BC51A89AF for <mmusic@ietfa.amsl.com>; Mon, 29 Feb 2016 05:28:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 aUJlK7cJFdEQ for <mmusic@ietfa.amsl.com>; Mon, 29 Feb 2016 05:28:16 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EBA41A89A9 for <mmusic@ietf.org>; Mon, 29 Feb 2016 05:28:15 -0800 (PST)
X-AuditID: c1b4fb2d-f79836d000006396-c0-56d4476c2099
Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 5C.18.25494.C6744D65; Mon, 29 Feb 2016 14:28:13 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0248.002; Mon, 29 Feb 2016 14:28:12 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Roman Shpount <roman@telurix.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: [MMUSIC] Offer/Answer PT Questions - text proposal
Thread-Index: AdFv1i1li4hZHAkDRvW27hH21f813wARGIiAAAEzHQAAFHhLgAANDP0AAABf9wAAANkcgAABPnAAAACT0gAAARuRgAAArliAACAJAYAADgPBAABONv0AABK4WIA=
Date: Mon, 29 Feb 2016 13:28:12 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B37E4BD38@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B37E425AB@ESESSMB209.ericsson.se> <CBDE14F9-B68C-4471-9E24-0D7EA7821795@csperkins.org> <56CF9400.2020002@alum.mit.edu> <FDDE79D2-43D4-4382-92B4-4E22FFFEA8AC@csperkins.org> <56D074F4.2080401@alum.mit.edu> <2A2E7C19-3106-4A7D-B533-8A7267A9BAD4@csperkins.org> <56D07D29.2030500@alum.mit.edu> <CAD5OKxt0CBectoG5gpNsK4SPAu0JwnJOn7UimpKgt-TnFo+0zQ@mail.gmail.com> <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>
In-Reply-To: <CAD5OKxt5jp44Saop+ssdPENBsRBNbkFUXFphZHMwqYDFLNWFpg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.16]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37E4BD38ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyM2J7lG6u+5Uwg97J7BZTlz9msVix4QCr xYwLU5kdmD3+vv/A5LFkyU8mj1tTCgKYo7hsUlJzMstSi/TtErgy+vuOMxW8ya843nWEtYHx RU4XIyeHhICJROvtPiYIW0ziwr31bF2MXBxCAocZJWaf2MUC4SxmlOh9sQMow8HBJmAh0f1P G6RBRMBboq+vgx0kzCygLnF1cRBIWFjAXmL6s8dMECUOEre3/mIHGSMi0MUocWTbN1aQBIuA qkRrw1ewIl4BX4kXd9rAbCGBG6wST15Wg9icAoESdz+cYgexGYGO+35qDVgNs4C4xK0n86GO FpBYsuc8M4QtKvHy8T9WCFtRYufZdmaI+nyJfV8+M0PsEpQ4OfMJywRG0VlIRs1CUjYLSdks sNc0Jdbv0ocoUZSY0v2QHcLWkGidM5cdWXwBI/sqRtHi1OLi3HQjY73Uoszk4uL8PL281JJN jMD4O7jlt+4OxtWvHQ8xCnAwKvHwbnC+HCbEmlhWXJl7iFGCg1lJhNfa9UqYEG9KYmVValF+ fFFpTmrxIUZpDhYlcV62T0DVAumJJanZqakFqUUwWSYOTqkGRsOddnq+F01yg08d8X2zlev6 1bTLH0K0tf9226tGvlSsndrlYPw75PXRdf5xOnpi3e5CUTJL0x+mtdYn3S9ve3b+Tub/ekEH PcmTvMLb7r7+9KdTNkp5xsUvC94eaY62U8674M9yWk/Of7fqM3aVhVYJTn2XrY7asGY29b44 dYeJa3p89mJNJZbijERDLeai4kQA0yjTHLsCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/PqRFrnwlqzFLxGyceOAm7b5G8cY>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
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: Mon, 29 Feb 2016 13:28:18 -0000

Hi,

SDP Offer/Answer causes lots of problem. When I read all this it seems like we want to complicate things – which very likely will cause any more problems.

Two endpoints use SDP Offer/Answer to negotiate an “SDP session”. Can’t we try to define what rules apply within that “SDP session”? Why do we have to talk about RTP sessions etc?

Regards,

Christer

From: Roman Shpount [mailto:roman@telurix.com]
Sent: 29. helmikuuta 2016 7:30
To: Paul Kyzivat
Cc: Christer Holmberg; mmusic@ietf.org
Subject: Re: [MMUSIC] Offer/Answer PT Questions - text proposal

On Sat, Feb 27, 2016 at 11:10 AM, Paul Kyzivat <pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu>> wrote:
On 2/27/16 4:29 AM, Roman Shpount wrote:
One potential solution is to generate any offer in such a way that it
will be compatible with all the completed O/A exchanges for this end
point. If an end point receives an offer which is not compatible with
existing state, i.e. an offer which is reusing one of the PT for a
different codec profile similar, this end point must allocate new
transport (use new local address/port or new local set of candidates in
case of ICE) for the answer and consider this a start of the new session
(discard all the PT use history). If new transport cannot be allocated,
for instance if responding to an offer with ICE and existing ufrag, then
offer must be refused with 488 or m line with port 0. This way end point
can always uniquely map the PT to the codec profile based on PT and
local transport where the packet is received. In case of 3pcc, an end
point might get an offer which is incompatible with its PT use history;
allocate new local transport, and handle it as a new RTP session.

What do you think?

While there are probably a lot of details to work out, I like it as the outline of a direction to pursue.

It could get complicated for a focus. It might require the focus to change mixing policies for the offending participant.

PT collisions are already a quite complicated for the conference focus. Conference focus needs to deal with situations when multiple inbound callers (in case of meet-me conference) use the same PT in incompatible way. When outbound calls are placed from the focus, end points can add PT to the answer which can also produce PT collisions. With my proposal these collisions can be resolved using a re-INVITE from the focus which will force new RTP sessions to be created on the clients.

From implementation experience PT collisions do not present a real problem in practice. All practical implementations of RTP mux that I had dealt with either worked with specially pre-provisioned end points which all used the same PT for the same codec profiles or conference focus implemented PT re-mapping on each of the call legs.

Regards,
_____________
Roman Shpount