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

[Paul Kyzivat <[e-mail]>]

I think the changes you propose seem good. One comment: your replacement
text includes a reference to Figure 5. Since you propose to remove
figure 4 and renumber, this too will need to be renumbered to be Figure 4.

	Thanks,
	Paul

Takuya Sawada wrote:
> 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:* [e-mail]
>>>> *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 [e-mail] for questions on current sip
>>> Use [e-mail] 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 [e-mail] for questions on current sip
>> Use [e-mail] 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: [phone]
> Fax: [phone]
> [e-mail]
> 
> ------------------------------------------------------------------
> 注意：この電子メールには、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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP