Re: [Sipping] can update be used in Figure 4 indraft-ietf-sipping-sip-offeranswer-06

Takuya Sawada <tu-sawada@kddi.com> Fri, 29 February 2008 13:50 UTC

Return-Path: <sipping-bounces@ietf.org>
X-Original-To: ietfarch-sipping-archive@core3.amsl.com
Delivered-To: ietfarch-sipping-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33B1628C869; Fri, 29 Feb 2008 05:50:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.634
X-Spam-Level:
X-Spam-Status: No, score=-0.634 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcCmHk6U17Gi; Fri, 29 Feb 2008 05:50:28 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36BC028C3CB; Fri, 29 Feb 2008 05:50:28 -0800 (PST)
X-Original-To: sipping@core3.amsl.com
Delivered-To: sipping@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2CAA28C2DB for <sipping@core3.amsl.com>; Fri, 29 Feb 2008 05:50:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EpLrclOjbQ2 for <sipping@core3.amsl.com>; Fri, 29 Feb 2008 05:50:21 -0800 (PST)
Received: from UTMC1101.kddi.com (athena.kddi.com [210.141.112.39]) by core3.amsl.com (Postfix) with ESMTP id ECBEF3A6F39 for <sipping@ietf.org>; Fri, 29 Feb 2008 05:50:20 -0800 (PST)
Received: from UTMC1132 (unknown [10.5.16.195]) by UTMC1101.kddi.com (Postfix) with SMTP id C41421DAE; Fri, 29 Feb 2008 22:50:12 +0900 (JST)
Received: from localhost (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with SMTP id 62E4519A1; Fri, 29 Feb 2008 22:50:09 +0900 (JST)
Received: from UTMC1118.kddi.com (unknown [10.5.16.33]) by UTMC1123.kddi.com (Postfix) with ESMTP id D08D2192A; Fri, 29 Feb 2008 22:50:06 +0900 (JST)
Received: from KDDI-0403PC0002 ([10.200.211.248] [10.200.211.248]) by post-ims.kddi.com with ESMTPA; Fri, 29 Feb 2008 22:50:06 +0900
To: rjsparks@nostrum.com, pkyzivat@cisco.com
From: Takuya Sawada <tu-sawada@kddi.com>
References: <F86B91A10B14744E88408E80B8A30EF302B3AEEC@xmb-hkg-412.apac.cisco.com> <47C6E818.1020104@cisco.com> <DBE2318F-183A-4C5B-BBE9-8FF6E4345788@nostrum.com>
In-Reply-To: <DBE2318F-183A-4C5B-BBE9-8FF6E4345788@nostrum.com>
Message-Id: <200802292250.AHJ42878.tEUXBBBVT@kddi.com>
X-Mailer: Winbiff [Version 2.50]
X-Accept-Language: ja,en
Date: Fri, 29 Feb 2008 22:50:06 +0900
Mime-Version: 1.0
X-WAuditID: 0802292250090000208983
Cc: zhengyli@cisco.com, sipping@ietf.org
Subject: Re: [Sipping] can update be used in Figure 4 indraft-ietf-sipping-sip-offeranswer-06
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
Sender: sipping-bounces@ietf.org
Errors-To: sipping-bounces@ietf.org

Hi,

I found the discussion below.

http://www.ietf.org/mail-archive/web/sipping/current/msg14479.html

Yes, I agree. Figure 4 is not adequate. It could not be happened.
Some texts in the same section should also be modified.

How about the following changes;

- Remove Figure 4 and renumber the subsequent figures.
- Remove the following sentence
  'Therefore, to simplify implementations, a UA acting
  as a UAS for an INVITE transaction is recommended not to defer
  sending an UPDATE request with an offer until after the reliable
  response with an answer to the offer in the INVITE request is
  acknowledged with a PRACK request.'
  (I know 'not to defer' should've been 'to defer' )
  And probably put the sentence like
  'Fortunately, under the current rules, UA A can not send a new
   offer until the reliable response.'
- Chane the NOTE on Table 3
  <Old>
  'NOTE: PRACK and 1xx-rel/2xx case is extremely rare case and easily
  avoidable. See Figure 4 and Figure 5.'
  <New>
  'NOTE: 1xx-rel/2xx case is extremely rare case and easily
  avoidable. See Figure 5.'
- In Table 3
  <Old>
  -------+------------------------------+--------------------------
  PRACK  | Not a pattern 4. in Table 1. | Delay sending response
         | 1xx-rel must have an answer, | until answer1 is received
         | not an offer.                |
  -------+------------------------------+--------------------------
  <New>
  -------+------------------------------+--------------------------
  PRACK  | This case never happens      |        -
         | under the current rules.     |
  -------+------------------------------+--------------------------

Please comment.

Regards,
Takuya

> It appeared first in -04 if that helps (November 07).
> 
> I don't remember why it got introduced either.
> 
> I agree that 3311 is pretty clear that this is a protocol violation  
> rather than a race-condition.
> 
> RjS
> 
> On Feb 28, 2008, at 10:58 AM, Paul Kyzivat wrote:
> 
> > I saw your query. When I looked back at 3311 it does seem to support
> > your position. I can't remember why we included this case.
> >
> > Does anybody else remember?
> >
> > 	Paul
> >
> > Rockson Li (zhengyli) wrote:
> >> Paul,
> >>
> >> Do you have any comments on this?
> >>
> >> Regards,
> >> -Rockson
> >>
> >> --------------------------------------------------------------------- 
> >> ---
> >> *From:* Rockson Li (zhengyli)
> >> *Sent:* Tuesday, February 26, 2008 3:26 PM
> >> *To:* sipping@ietf.org
> >> *Subject:* can update be used in Figure 4 in
> >> draft-ietf-sipping-sip-offeranswer-06
> >>
> >> In Figure 4 of draft-ietf-sipping-sip-offeranswer-06
> >>
> >> UPDATE is used to send new offer from Callee A.
> >>
> >> However, I  wonder if it's valid to be used here? since as per  
> >> RFC3311
> >> sec5.1
> >>
> >> and for the callee:
> >>
> >>       o  If the UPDATE is being sent before the completion of the  
> >> INVITE
> >>          transaction, and the initial INVITE contained an offer, the
> >>          UPDATE cannot be sent with an offer unless the callee has
> >>          generated an answer in a reliable provisional response,  
> >> <NOTE>has
> >>          received a PRACK for that reliable provisional response</ 
> >> NOTE>, has
> >>          not received any requests (PRACK or UPDATE) with offers  
> >> that it
> >>          has not answered, and has not sent any UPDATE requests
> >>          containing offers that have not been answered.
> >>
> >> Any comments?
> >>
> >> Regards,
> >> Rockson Li
> >>
> >> Cisco R&D Center, Shanghai, PRC
> >>
> >>
> > _______________________________________________
> > Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sip@ietf.org for new developments of core SIP
> 
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 

--------
Takuya Sawada
KDDI Corporation (KDDI)
Garden Air Tower, 3-10-10, Iidabashi, 
Chiyoda-ku, Tokyo 102-8460, Japan
Tel: +81-3-6678-2997
Fax: +81-3-6678-0286
tu-sawada@kddi.com

------------------------------------------------------------------
注意:この電子メールには、KDDI株式会社の機密情報が含まれている
      場合が有ります。正式なメール受信者でない場合、メール複製、
   再配信または情報の使用を固く禁じております。
      エラー、手違い等でこのメールを受け取られましたら、お手数を
   おかけ致しますが、削除を行い配信者に連絡をお願い致します。
NOTE: This electronic mail message may contain confidential and
   privileged information from KDDI Corporation. If you are
   not the intended recipient, any disclosure, photocopying,
      distribution or use of the contents of the received
      information is prohibited. If you have received this e-mail
      in error, please notify the sender immediately and
     permanently delete this message and all related copies.
-------------------------------------------------------------------

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP