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

From: "Rockson Li (zhengyli)" <[email-masked]>
Date: Thu, 28 Feb 2008 10:07:26 +0800

Paul, 
 
Do you have any comments on this?
 
Regards,
-Rockson

________________________________

From: Rockson Li (zhengyli) 
Sent: Tuesday, February 26, 2008 3:26 PM
To: [email-masked]
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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 28 Feb 2008 11:58:00 -0500

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:
> ------------------------------------------------------------------------
> *From:* Rockson Li (zhengyli)
> *Sent:* Tuesday, February 26, 2008 3:26 PM
> *To:* [email-masked]
> *Subject:* can update be used in Figure 4 in 
>          generated an answer in a reliable provisional response, <NOTE>has
>          received a PRACK for that reliable provisional response</NOTE>, has

---

From: Robert Sparks <[email-masked]>
Date: Thu, 28 Feb 2008 11:16:43 -0600

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

---

From: Takuya Sawada <[email-masked]>
Date: Fri, 29 Feb 2008 22:50:06 +0900

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

> >> Do you have any comments on this?

--------
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
[email-masked]

------------------------------------------------------------------
注意：この電子メールには、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.
-------------------------------------------------------------------