[Sip] Re: draft-ietf-sip-replaces-04.txt
Rohan Mahy <rohan@cisco.com> Tue, 19 August 2003 19:45 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04423 for <sip-archive@odin.ietf.org>; Tue, 19 Aug 2003 15:45:00 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pCPC-0006zU-DQ for sip-archive@odin.ietf.org; Tue, 19 Aug 2003 15:44:34 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JJiYao026868 for sip-archive@odin.ietf.org; Tue, 19 Aug 2003 15:44:34 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pCOf-0006yJ-Sp; Tue, 19 Aug 2003 15:44:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pCOS-0006xq-Oh for sip@optimus.ietf.org; Tue, 19 Aug 2003 15:43:48 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04347 for <sip@ietf.org>; Tue, 19 Aug 2003 15:43:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pCOR-0006bD-00 for sip@ietf.org; Tue, 19 Aug 2003 15:43:47 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19pCOQ-0006aX-00 for sip@ietf.org; Tue, 19 Aug 2003 15:43:46 -0400
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h7JJhFWu013796; Tue, 19 Aug 2003 12:43:15 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKN84727; Tue, 19 Aug 2003 12:35:18 -0700 (PDT)
Date: Tue, 19 Aug 2003 10:26:22 -0700
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Mime-Version: 1.0 (Apple Message framework v552)
Cc: sip@ietf.org
To: Paul Kyzivat <pkyzivat@cisco.com>
From: Rohan Mahy <rohan@cisco.com>
In-Reply-To: <3F410469.6030609@cisco.com>
Message-Id: <40C3D8B0-D26A-11D7-93EC-0003938AF740@cisco.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: draft-ietf-sip-replaces-04.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Paul, Thanks for bringing this up. I think the draft needs to distinguish between these cases: 1) The UA receives an offer with no compatible media and does not wish to maintain a session with no associated media. 2) The UA receives an offer but does not wish to send/receive media at the moment (possibly because it is negotiating a session using 3pcc on behalf of another UA). I think the same distinction applies to UAs that receive "ordinary" INVITEs. They can accept an offer but reject all the m-lines, or they can send a 4xx response. So... - Do you think 3261 needs any clarification to make this distinction obvious? - Can you propose some text for Replaces that makes clear my original intention (what you do in case 1), while still allowing for case 2? thanks, -rohan On Monday, August 18, 2003, at 09:52 AM, Paul Kyzivat wrote: > "If the UA cannot accept the new INVITE (for example: it cannot > establish required QoS or keying, or it has incompatible media), the > UA MUST return an appropriate error response and MUST leave the > matched dialog unchanged." > > Exactly what is the meaning of "incompatible media" in the above? > > In general, when an INVITE arrives containing an offer, the recipient > may accept the INVITE while rejecting some or all of the media, up to > and including ending up with a call containing no media. If it is ok > to accept a call while rejecting all the media then there is no such > thing as a call with incompatible media. > > I fear that we will begin to have interop problems if some UAs accept > calls under this kind of situation, while others reject them. > > Paul > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
- [Sip] I-D ACTION:draft-ietf-sip-replaces-04.txt Internet-Drafts
- [Sip] Re:draft-ietf-sip-replaces-04.txt Paul Kyzivat
- [Sip] Re:draft-ietf-sip-replaces-04.txt Paul Kyzivat
- [Sip] Re: draft-ietf-sip-replaces-04.txt Rohan Mahy
- [Sip] Re: draft-ietf-sip-replaces-04.txt Rohan Mahy
- [Sip] Re: draft-ietf-sip-replaces-04.txt Paul Kyzivat
- [Sip] Re: draft-ietf-sip-replaces-04.txt Rohan Mahy
- [Sip] Re: draft-ietf-sip-replaces-04.txt Paul Kyzivat
- [Sip] Re: draft-ietf-sip-replaces-04.txt Paul Kyzivat