[MMUSIC] Offer/Answer sections in SDP drafts

Flemming Andreasen <fandreas@cisco.com> Thu, 02 October 2014 20:22 UTC

Return-Path: <fandreas@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id A70B31A86EC for <mmusic@ietfa.amsl.com>; Thu, 2 Oct 2014 13:22:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 5ywTVxEUuBix for <mmusic@ietfa.amsl.com>; Thu, 2 Oct 2014 13:22:12 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 446C51A02DE for <mmusic@ietf.org>; Thu, 2 Oct 2014 13:22:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1464; q=dns/txt; s=iport; t=1412281332; x=1413490932; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=gvxTjVE2Ad/A0HqVMXiQajWwoBSbWKDXiOw6MFuwAE4=; b=CuTOp4JcCa7SDX2+NJhg7LTn6NfSEzeWhm8XDPA25nKLnvxCoTkVmRvR XM2/LfNqSf6ir+l7xqIfqfIxcPWFiN4yMsBUkLrEfNiwE/yLmvR6cV1Yn 32w0TQ1/H7F6ur4g1cJ+sufOv3COUn2HevwYxEv4dfP+uphsXh9FAaeAb c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuYKAD+zLVStJV2T/2dsb2JhbABfgw64DgUBcpt2FgF7hEJ9NAJMDQgBAYg6mHKlLhiGFY5jAQSYb4RMh1yOH4N/IYJ5AQEB
X-IronPort-AV: E=Sophos;i="5.04,640,1406592000"; d="scan'208";a="83552717"
Received: from rcdn-core-11.cisco.com ([]) by alln-iport-6.cisco.com with ESMTP; 02 Oct 2014 20:22:11 +0000
Received: from [] (bxb-fandreas-88112.cisco.com []) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s92KMBgm028228 for <mmusic@ietf.org>; Thu, 2 Oct 2014 20:22:11 GMT
Message-ID: <542DB3F2.808@cisco.com>
Date: Thu, 02 Oct 2014 16:22:10 -0400
From: Flemming Andreasen <fandreas@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: mmusic <mmusic@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/KvtEmJynhX9-aAsCtJEbX-Xj8y8
Subject: [MMUSIC] Offer/Answer sections in SDP drafts
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: <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: Thu, 02 Oct 2014 20:22:14 -0000


One of the things we have tried to emphasize for SDP related drafts is 
the need to have well-defined offer/answer procedures, and as part of 
that, we have been asking people to follow the structure of RFC 3264. 
This means there needs to be the following O/A sections in SDP related 
drafts (in the order shown):

     1. Generating the Initial Offer
     2. Generating the Answer
     3. Offerer Processing of the Answer
     4. Modifying the Session

As part of the bundle-11 draft review, a (general) question came up 
around what actually goes in the "Generating the Answer" section. More 
specifically, should this section
     a) Apply to the initial offer only

     b) Apply to the initial offer and subsequent offers for the parts 
that apply in a general manner to both [parts that apply to subsequent 
offers only would be covered by "Modifying the Session"]

     c) Apply to all offers.

I believe the answer is b), however some feel the answer is c). One of 
the issues I see with that is that you potentially end up depending on 
text/rules from "Modifying the Session", however those procedures have 
not been defined at that point in the document. This can of course be 
solved with forward referencing (as is done in bundle-11), however it 
makes it harder to follow IMO and I also do not believe this is what RFC 
3264 intended.

Comments on the above would be appreciated.


-- Flemming