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

Christer Holmberg <> Thu, 02 October 2014 20:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2CE671A7D85 for <>; Thu, 2 Oct 2014 13:53:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LuaKonXOaWOM for <>; Thu, 2 Oct 2014 13:53:14 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7310B1A86F0 for <>; Thu, 2 Oct 2014 13:53:13 -0700 (PDT)
X-AuditID: c1b4fb25-f791c6d00000617b-d8-542dbb37ccb2
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id CD.C3.24955.73BBD245; Thu, 2 Oct 2014 22:53:11 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Thu, 2 Oct 2014 22:53:11 +0200
From: Christer Holmberg <>
To: Flemming Andreasen <>, mmusic <>
Thread-Topic: [MMUSIC] Offer/Answer sections in SDP drafts
Thread-Index: AQHP3n6SQ2p6yESBZkaoSXn9EKGU3JwdRvHg
Date: Thu, 2 Oct 2014 20:53:10 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvja75bt0Qg3O3JS3eX9C1mLr8MYsD k8eU3xtZPZYs+ckUwBTFZZOSmpNZllqkb5fAldF7awd7wQ2hitZnHewNjI/4uhg5OSQETCR+ nnvPDGGLSVy4t56ti5GLQ0jgKKPE/9nbmSCcxYwSu3qPMXYxcnCwCVhIdP/TBmkQEXCVOLLw LhOILSxgKXFy+QVmiLiVxKOTJ5ggbCOJB0fPgsVZBFQkTvZuZwGxeQV8JU7MXswKYgsBxZ+t +8oOYnMKqEpM/nIarJcR6KDvp9aA2cwC4hK3nsxngjhUQGLJnvNQR4tKvHz8jxXCVpJYexhi PrOAjsSC3Z/YIGxtiWULXzND7BWUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjGKFqcWJ+Wm GxnrpRZlJhcX5+fp5aWWbGIERsnBLb9VdzBefuN4iFGAg1GJh3fBRp0QIdbEsuLK3EOM0hws SuK8C8/NCxYSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAOJXn2Beb2xOLp+/eefTepZQDEw7l J4VFdly/tm9O8JT0O78bN3T8FLjIGD2h4dIKyQseSZsF/e5tOJjx5VzmsaDQs8dPdKtM5K3c w9TRu649WozVdOXegFVr3D+rfnzc+lVsSbHmpTdcrnlr+8PEnzn5zgk5UizbxSt2a7HwJO5W jRfX9vi8OabEUpyRaKjFXFScCACboWOBcwIAAA==
Subject: Re: [MMUSIC] Offer/Answer sections in SDP drafts
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Oct 2014 20:53:23 -0000


In general, I believe the answer is c).

Of course, if there are major differences in the generating-answer procedures, depending on whether the answer is generated for the initial or a modification offer, they could be put in separate places. But, in the case of BUNDLE, the generating-answer procedures are more or less identical (some part may only apply to one case, though), so I see no need to separate them.

And, unless I've missed something, I believe I got rid of the forward references in version -11 :)



-----Original Message-----
From: mmusic [] On Behalf Of Flemming Andreasen
Sent: 02 October 2014 23:22
To: mmusic
Subject: [MMUSIC] Offer/Answer sections in SDP drafts


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

mmusic mailing list