Re: [MMUSIC] [RFC4566] Increment of SDP session version when NO modification is made to the session data
"Anh Cao" <cdanh@tma.com.vn> Wed, 16 March 2016 02:36 UTC
Return-Path: <cdanh@tma.com.vn>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21C212DEFF for <mmusic@ietfa.amsl.com>; Tue, 15 Mar 2016 19:36:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.891
X-Spam-Level:
X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
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 bZzTMJ-tg_yj for <mmusic@ietfa.amsl.com>; Tue, 15 Mar 2016 19:36:07 -0700 (PDT)
Received: from mail2.tma.com.vn (mail2.tma.com.vn [120.72.81.4]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D13812D868 for <mmusic@ietf.org>; Tue, 15 Mar 2016 19:36:06 -0700 (PDT)
Received: from smail.tma.com.vn ([192.168.1.42]) by mail2.tma.com.vn (8.13.8/8.13.8) with ESMTP id u2G2ZNFb008930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 16 Mar 2016 09:35:24 +0700
Received: from cdanh ([137.116.158.93]) by smail.tma.com.vn (8.14.7/8.13.8) with ESMTP id u2G2ZJKE002213 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 16 Mar 2016 09:35:20 +0700
From: Anh Cao <cdanh@tma.com.vn>
To: 'Brett Tate' <brett@broadsoft.com>, 'Paul Kyzivat' <pkyzivat@alum.mit.edu>, mmusic@ietf.org, "'Dale R. Worley'" <worley@ariadne.com>
References: <003501d17e5e$f5750e90$e05f2bb0$@tma.com.vn> <d873ebf63ceb6bd0384a261b066cd869@mail.gmail.com> <56E8327A.6040403@alum.mit.edu> <e034700f21469cc0723a5a5319d3285a@mail.gmail.com>
In-Reply-To: <e034700f21469cc0723a5a5319d3285a@mail.gmail.com>
Date: Wed, 16 Mar 2016 09:35:19 +0700
Message-ID: <004001d17f2c$7d812800$78837800$@tma.com.vn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0041_01D17F67.29E09C40"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQHTfaDMpcbJmE+Kz7G3uv8M88wFUQHmLiN5AbFvW+wC5jgyJZ8jbJQg
Content-Language: en-us
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail2.tma.com.vn [10.1.0.4]); Wed, 16 Mar 2016 09:35:26 +0700 (ICT)
X-Virus-Scanned: clamav-milter 0.97.5 at mail2.tma.com.vn
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/TpK9ARUE-pIwXnnpxUVv8vF3MSA>
Subject: Re: [MMUSIC] [RFC4566] Increment of SDP session version when NO modification is made to the session data
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 16 Mar 2016 02:36:10 -0000
Thank everyone for helping me. So, if session data is not changed, session version can be increased but NOT RECOMMENDED because it may cause the other side to do more work :) Best regards, Anh Cao -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Brett Tate Sent: Wednesday, March 16, 2016 12:06 AM To: Paul Kyzivat <pkyzivat@alum.mit.edu>; mmusic@ietf.org Subject: Re: [MMUSIC] [RFC4566] Increment of SDP session version when NO modification is made to the session data Hi, > >> If session data is NOT made any change, is session-version > >> acceptable to increase or it is NOT? > > > > As far as I know, RFC 4028 section 7.4 provides the only related mandate. > > For interoperability reasons, I recommend being lenient when receiving. > > > > Section 7.4: > > > > "It is RECOMMENDED that the UPDATE request not contain an offer [4], > > but a re-INVITE SHOULD contain one, even if the details of the > > session have not changed. In that case, the offer MUST indicate > > that it has not changed. In the case of SDP, this is accomplished > > by including the same value for the origin field as did previous SDP > > messages to its peer. The same is true for an answer exchanged as a > > result of a session refresh request; if it has not changed, that > > MUST be indicated." > > Note that 4028 is only concerned with session timers. IMO its language is > confusing and possibly deceptive in some regards. It is *not* intended to > refine how offer/answer works - only to comment on how standard O/A rules > might best be used for signaling triggered by session timer. I agree that text only applies to devices that support RFC 4028. However AFAIK, it does impose related mandates on devices that support RFC 4028 since the working group decided to use MUST instead of SHOULD. _______________________________________________ mmusic mailing list <mailto:mmusic@ietf.org> mmusic@ietf.org <https://www.ietf.org/mailman/listinfo/mmusic> https://www.ietf.org/mailman/listinfo/mmusic
- [MMUSIC] [RFC4566] Increment of SDP session versi… Anh Cao
- Re: [MMUSIC] [RFC4566] Increment of SDP session v… Brett Tate
- Re: [MMUSIC] [RFC4566] Increment of SDP session v… Dale R. Worley
- Re: [MMUSIC] [RFC4566] Increment of SDP session v… Paul Kyzivat
- Re: [MMUSIC] [RFC4566] Increment of SDP session v… Brett Tate
- Re: [MMUSIC] [RFC4566] Increment of SDP session v… Anh Cao