[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