IETF Logo Mail Archive

[MMUSIC] SDP grouping in a new offer

"Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> Thu, 05 July 2012 11:46 UTC

Return-Path: <mperumal@cisco.com>
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 4B96321F864E for <mmusic@ietfa.amsl.com>; Thu, 5 Jul 2012 04:46:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEiU8y5Cfn2J for <mmusic@ietfa.amsl.com>; Thu, 5 Jul 2012 04:46:55 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8FC21F8501 for <mmusic@ietf.org>; Thu, 5 Jul 2012 04:46:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=7148; q=dns/txt; s=iport; t=1341488829; x=1342698429; h=from:to:cc:subject:date:message-id:mime-version; bh=eMh9z68WVGxK7g1A2lHSS3euB2kZXLVWH2HLhAYmHL8=; b=ldIv4aKti/353nbYZX+PyidH4SWYMBRjuJWWi18WjBRyv9cHQRfMs5te sOf9Jl+51x0f7CVpmpFqQHqmgmgOQ/0ufOHbQMumfsRy0D9ory21NZ1vO eAl9C8Hyl2gDlwGllAO8tjy4KGG1B/h2YJBQC1jDA0YgUxChzkOg/a0Hx c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAOJ99U+tJXG8/2dsb2JhbABFgki0XIEHghoBBBIBGj4OEgEqViYBBA4NGodpmiCfcZEXYAOjVIFmgl8
X-IronPort-AV: E=Sophos; i="4.77,530,1336348800"; d="scan'208,217"; a="99003940"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 05 Jul 2012 11:47:08 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q65Bl8Sb011295 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <mmusic@ietf.org>; Thu, 5 Jul 2012 11:47:08 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.223]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0298.004; Thu, 5 Jul 2012 06:47:07 -0500
From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: mmusic <mmusic@ietf.org>
Thread-Topic: SDP grouping in a new offer
Thread-Index: Ac1ao+bIIyNbq2IgR+ayS6qhne1GYQ==
Date: Thu, 05 Jul 2012 11:47:07 +0000
Message-ID: <E721D8C6A2E1544DB2DEBC313AF54DE2012B443D@xmb-rcd-x02.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [64.103.239.203]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19018.004
x-tm-as-result: No--29.213900-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_E721D8C6A2E1544DB2DEBC313AF54DE2012B443Dxmbrcdx02ciscoc_"
MIME-Version: 1.0
Cc: "Raghavendra S (raghs)" <raghs@cisco.com>, "Toleti Danayya Naidu (naidud)" <naidud@cisco.com>, "Dinesh V (dinv)" <dinv@cisco.com>
Subject: [MMUSIC] SDP grouping in a new offer
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
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, 05 Jul 2012 11:46:56 -0000

Experts,

RFC3264 states that:

   If an SDP is offered, which is different from the previous SDP, the
   new SDP MUST have a matching media stream for each media stream in
   the previous SDP.  In other words, if the previous SDP had N "m="
   lines, the new SDP MUST have at least N "m=" lines.  The i-th media
   stream in the previous SDP, counting from the top, matches the i-th
   media stream in the new SDP, counting from the top.  This matching is
   necessary in order for the answerer to determine which stream in the
   new SDP corresponds to a stream in the previous SDP.  Because of
   these requirements, the number of "m=" lines in a stream never
   decreases, but either stays the same or increases.  Deleted media
   streams from a previous SDP MUST NOT be removed in a new SDP;
   however, attributes for these streams need not be present.

>From section 9.1 of RFC5888, it seems the same is applicable with SDP grouping, but is not explicit. Should there be matching m-lines in the new offer even with SDP grouping? Does SDP grouping change anything w.r.t to the above statements in RFC3264?

thanks,
Muthu

v2.31.3 | Report a Bug | By Email | System Status