[MMUSIC] Offer/Answer PT Questions

"DOLLY, MARTIN C" <md3135@att.com> Sat, 20 February 2016 04:30 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 2663A1B39C4 for <mmusic@ietfa.amsl.com>; Fri, 19 Feb 2016 20:30:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level:
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 u6c8gY7XBmZm for <mmusic@ietfa.amsl.com>; Fri, 19 Feb 2016 20:30:36 -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 D88461B39C1 for <mmusic@ietf.org>; Fri, 19 Feb 2016 20:30:36 -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 u1K4TTc8045024 for <mmusic@ietf.org>; Fri, 19 Feb 2016 23:30:36 -0500
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 215hyqxmfs-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <mmusic@ietf.org>; Fri, 19 Feb 2016 23:30:36 -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 u1K4UZG0026761 for <mmusic@ietf.org>; Fri, 19 Feb 2016 23:30:35 -0500
Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u1K4URsd026670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <mmusic@ietf.org>; Fri, 19 Feb 2016 23:30:28 -0500
Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi408.sfdc.sbc.com (RSA Interceptor) for <mmusic@ietf.org>; Sat, 20 Feb 2016 04:30:12 GMT
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.77]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0248.002; Fri, 19 Feb 2016 23:30:12 -0500
From: "DOLLY, MARTIN C" <md3135@att.com>
To: mmusic WG <mmusic@ietf.org>
Thread-Topic: Offer/Answer PT Questions
Thread-Index: AdFrl0kuiZ+JG67LRQCl2lgEejcpMA==
Date: Sat, 20 Feb 2016 04:30:12 +0000
Message-ID: <E42CCDDA6722744CB241677169E8365615E419C0@MISOUT7MSGUSRDB.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.10.217.62]
Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E8365615E419C0MISOUT7MSGUSRDB_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-20_03:, , 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-1602200070
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/azhNy3ckQhzLyvtGEjFGBGcS-rE>
Cc: "LEWIS, DAVID G" <dl962r@att.com>, "SCHLEIN, EDWARD" <es7912@att.com>
Subject: [MMUSIC] Offer/Answer PT Questions
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: Sat, 20 Feb 2016 04:30:39 -0000

Hello O/A lovers,

Section 8.3.2 of RFC 3264 says the following:

   "However, in the case of RTP, the mapping from a particular dynamic payload type
   number to a particular codec within that media stream MUST NOT change
   for the duration of a session.  For example, if A generates an offer
   with G.711 assigned to dynamic payload type number 46, payload type
   number 46 MUST refer to G.711 from that point forward in any offers
   or answers for that media stream within the session."

Now, assume the following case:


1.      Alice sends an Offer, with the following PT values:

PT 100: AMR-WB(mode-set=2)
PT 111: AMR-WB(mode-set=2, OA)
PT 0: PCMU


2.      Bob sends the associated Answer:

PT 100: AMR-WB (mode-set=2)
PT 0: PCMU


3.      Later Bob sends the following subsequent Offer:

PT 111: AMR(mode-set=0,2,5,7)


QUESTION 1: Is it allowed for Bob to offer PT 111 for AMR in the subsequent Offer, as Alice used PT 111 for AMR-WG in the initial Offer? In other words, does the pt-value-must-only-refer-to-a-specific-payload-for-the-stream-within-the-session text in section 8.3.2 apply to user A only, or to *all* users within the session?

QUESTION 2:   Assuming the text applies to all users, is it allowed to re-use a PT value for the same codec, but for a different CODEC CONFIGURATION? The text only talks about codec.

Now, I agree that the easiest way to avoid trouble is simply to make sure PT values aren't re-used by any party. But, the text still needs to be clear, because this is causing problems in real deployments.

Regards,

Martin