Re: [MMUSIC] Offer/Answer sections in SDP drafts

"Stach, Thomas" <thomas.stach@unify.com> Tue, 07 October 2014 13:07 UTC

Return-Path: <thomas.stach@unify.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 921881A1BFF for <mmusic@ietfa.amsl.com>; Tue, 7 Oct 2014 06:07:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.014
X-Spam-Level:
X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.786] 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 8k8fm6dnNN2D for <mmusic@ietfa.amsl.com>; Tue, 7 Oct 2014 06:07:45 -0700 (PDT)
Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBD01A1BFB for <mmusic@ietf.org>; Tue, 7 Oct 2014 06:07:45 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id E14F21EB8414; Tue, 7 Oct 2014 15:07:43 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.241]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Tue, 7 Oct 2014 15:07:43 +0200
From: "Stach, Thomas" <thomas.stach@unify.com>
To: Flemming Andreasen <fandreas@cisco.com>, mmusic <mmusic@ietf.org>
Thread-Topic: [MMUSIC] Offer/Answer sections in SDP drafts
Thread-Index: AQHP3n6SslbBvuAGmkWAJLrBTe5s5ZwkkRUw
Date: Tue, 7 Oct 2014 13:07:43 +0000
Message-ID: <F81CEE99482EFE438DAE2A652361EE121E224DB6@MCHP04MSX.global-ad.net>
References: <542DB3F2.808@cisco.com>
In-Reply-To: <542DB3F2.808@cisco.com>
Accept-Language: de-AT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/jz_Olgd_eVq5OfGlqi2WAQ20elc
Subject: Re: [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: Tue, 07 Oct 2014 13:07:47 -0000

Fleming,

my initial thoughts also leaned towards b) 
However, things got a bit more complex since 3264 and its structure might not be ideal anymore.

With stuff like ICE, CapNeg or Bundle the subsequent offers are 
different from the initial offer although there might be no intent to modify the existing session.
Nevertheless, some specific procedures might be needed.
E.g. ICE needed to deal with resolution of a race condition for the subsequent fix-up offer.

The following structure seems more appropriate 

  1 Initial offer/answer exchange 
  1.1. Generating the Initial Offer
  1.2. Generating the Answer
  1.3. Offerer Processing of the Answer

  2. Subsequent offer/answer exchange
  2.1. Generating the subsequent Offer
  2.2. Generating the subsequent Answer
  2.3. Offerer Processing of the subsequent Answer   

  3. Modifying the Session
  3.1. Generating the modified Offer
  3.2. Generating the Answer
  3.3. Offerer Processing of the Answer 

With this the answer to the question would be " a) Apply to the initial offer only" 

The answer to a subsequent offer is most likely the same or very similar as for the initial offer.
In that case  2.2./2.3. could be rather short and point to 1.2./1.3. for most of the procedures.
Nevertheless this would give space to cover all peculiarities of subsequent offer/answer handling 
and highlights what needs to be different. 

I can also imagine that you can omit 2. completely, when it is not needed.
Similar for the subsections under 3.


Kind Regards/mit freundlichen Grüßen
Thomas Stach


> -----Original Message-----
> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming
> Andreasen
> Sent: Donnerstag, 2. Oktober 2014 22:22
> To: mmusic
> Subject: [MMUSIC] Offer/Answer sections in SDP drafts
> 
> Greetings
> 
> 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.
> 
> Thanks
> 
> -- Flemming
> 
> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic