Subject: Re: [Sipping] New Version Notification for draft-ietf-sipping-sip-offeranswer-12

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 06 Apr 2010 16:30:11 +0900

Hi Paul,

Additional descriptions for Figure 4f in line.

---------------------------------------------------------------------

4.1.  Message Crossing Case Handling

   When message packets cross in the transport network, an offer may be
   received before the answer for the previous offer/answer exchange, as
   shown in Figure 3.  In such a case, UA A must detect that the session
   description SDP-2 is not the answer to offer1.

         A                  B
         |SDP-1     (offer1)|
      M1 |----------------->|
         |SDP-2    (answer1)|
      M2 |<------\  /-------|
         |        \/        |
         |SDP-3   /\(offer2)|
      M3 |<------/  \-------|

                      Figure 3 Message Crossing Case

   Because of the restrictions on placement of offers and answers
   (summarized in Table 1) there are a limited number of valid exchanges
   of messages that may lead to this message crossing case.  These are
   enumerated in Table 3.  (This table only shows messages containing
   offers or answers.  There could be other messages, without session
   descriptions, which are not shown.)

   There are variants, shown in Figures 4a and 4b, which are dependent
   on an INVITE (Mx) that contains no offer.  These are also included in
   Table 3.

         A                               B
         |                               |
         |SDP-1              offer1(UPD) |
      M1 |==============================>|
         |re-INV              (no offer) |
      Mx |------------------------------>| --+
         |SDP-2         answer1 (2xx-UPD)|   |
      M2 |<===========\  /===============|   | first reliable
         |             \/          offer2|   | response
         |SDP-3        /\   (1xx-rel/2xx)|   |
      M3 |<===========/  \===============| <-+
         |SDP-4       answer2 (PRACK/ACK)|
      My |------------------------------>|
         |                               |

                Figure 4a Avoidable message crossing cases

   To avoid this glare condition as shown in Figure 4a, When an UA A
   has already sent an UPDATE request with an offer, the UA should not
   send a reINVITE even without an offer unless the UPDATE transaction
   is completed. When an UA B has received an UPDATE request with an
   offer, the UA should reject a reINVITE even without an offer by a 491
   response unless the UPDATE transaction is completed.

         A                               B
         |                               |
         |re-INV              (no offer) |
      Mx |------------------------------>| --+
         |SDP-1              offer1(UPD) |   |
      M1 |==============================>|   |
         |SDP-2         answer1 (2xx-UPD)|   |
      M2 |<===========\  /===============|   | first reliable
         |             \/          offer2|   | response
         |SDP-3        /\   (1xx-rel/2xx)|   |
      M3 |<===========/  \===============| <-+
         |SDP-4       answer2 (PRACK/ACK)|
      My |------------------------------>|
         |                               |

                Figure 4b Avoidable message crossing cases

   To avoid this glare condition as shown in Figure 4b, When an UA A
   has already sent a reINVITE without an offer, the UA should not
   send an UPDATE request with an offer unless a PRACK transaction is
   completed, or the UA sends an ACK request. When an UA B has received
   a reINVITE without an offer, the UA should reject an UPDATE request
   with an offer by a 491 response unless a PRACK transaction is
   completed, or the UA receives an ACK request.

   According to RFC3311/5.1, after sending a PRACK request, UA B can send
   the UPDATE request(M2) with new offer, as shown in Figure 4c. To
   avoid this glare condition, UA B should not send the UPDATE request
   unless it has received a 2xx response to the PRACK request.

                    A                               B
                    |                               |
                    |              re-INV (no offer)|
   1st reliable +-- |<------------------------------|
   response     | M1| 1xx-rel (offer1)              |
                +-> |==============================>| --+
                    |                   answer1(PRA)| M3| Acknowledge
                    |<===========\  /===============| <-+
                    |             \/                |
                    |             /\     offer2(UPD)|
                    |<===========/  \===============| M2
                    | 491 (UPD)                     |
                    |------------------------------>|
                    |2xx-PRA                        |
                    |------------------------------>|
                    |                               |

                Fig. 4c Avoidable message crossing cases

   According to RFC3311/5.1, before the completion of initial INVITE
   transaction, UA B cannot send the UPDATE request(M2) with new offer,
   as shown in Figure 4d. But if this INVITE request is a reINVITE,
   B can send it. To avoid this glare condition, UA B should not send
   the UPDATE request unless it has received a PRACK request.

                A                               B
                |                               |
                |re-INV (offer1)                |
             M1 |==============================>|
                |              answer1 (1xx-rel)|
                |<===========\  /===============| M3
                |             \/                |
                |             /\     offer1(UPD)|
            +-- |<===========/  \===============| M2
            |   |491 (UPD)                      |
Acknowledge |   |------------------------------>|
            |   |PRACK                          |
            +-> |------------------------------>|
                |                               |

                Fig. 4d Avoidable message crossing cases

   According to RFC3311/5.1, before the completion of initial INVITE
   transaction, UA B cannot send the UPDATE request(M2) with new offer,
   as shown in Figure 4e. But if this INVITE request is a reINVITE,
   B can send it. To avoid this glare condition, UA B should not send
   the UPDATE request unless it has received an ACK request.

                A                               B
                |                               |
                |re-INV (offer1)                |
                |==============================>|
                |                  answer1 (2xx)|
                |<===========\  /===============|
                |             \/                |
                |             /\     offer1(UPD)|
            +-- |<===========/  \===============|
            |   |491 (UPD)                      |
Acknowledge |   |------------------------------>|
            |   |ACK                            |
            +-> |------------------------------>|
                |                               |

                Fig. 4e Avoidable message crossing cases

<add>
   According to RFC3311/5.1, before the completion of initial INVITE
   transaction, A cannot send the UPDATE request(M1) with new offer, as
   shown in Figure 4f. But if this INVITE request is a reINVITE, A can
   send it. To avoid this message crossing condition, UA A should not
   send the UPDATE request unless it has sent a 2xx response to the
   PRACK request and UA B should reject the UPDATE request by a 491
   response unless a PRACK transaction is completed.

                A                               B
                |                               |
                |                re-INV (offer0)|
                |<------------------------------|
                | 1xx-rel (answer0)             |
                |------------------------------>| --+
                |offer1(UPD)                    |   |
             M1 |==============================>|   |
                |              answer1 (2xx-UPD)|   | Acknowledge
                |<===========\  /===============| M3|
                |             \/                |   |
                |             /\     offer2(PRA)| M2|
                |<===========/  \===============| <-+
                | 491-PRA                       |
                |------------------------------>|
                |                               |

                Fig. 4f Avoidable message crossing case
</add>

   Table 4 summarize this section.

<modify>
         | M1     | M3       | M2      | Action | Action |
         |(offer1)|(answer1) |(offer2) |  of A  |  of B  |
         +--------+----------+---------+--------+--------+
         | UPDATE | 2xx-UPD  | UPDATE  |        |        |
         |        |          +---------| (1)    |  -     |
         |        |          | INVITE  |        |        |
         |        |          +---------+--------+--------+
         |        |          | 1xx-INV | (2)    | (4)    |
         |        |          +---------+        |        | 4a/b
         |        |          | 2xx-INV |        |        |
         |        |          +---------+        +--------+
         |        |          | PRACK*  |        | (5)    | 4f
         +--------+----------+---------+--------+--------+
         | PRACK  | 2xx-PRA  | UPDATE  |        |        |
         +--------+----------+---------+        |        |
         | 2xx-INV| ACK      | UPDATE  | (1)    |  -     |
         |        |          +---------+        |        |
         |        |          | INVITE  |        |        |
         +--------+----------+---------+        +--------+
         | 1xx-rel| PRACK    | UPDATE  |        |        | 4c
         +--------+----------+---------+        |        |
         | INVITE | 1xx-rel  | UPDATE* |        | (3)    | 4d
         |        |----------+---------+        |        |
         |        | 2xx-INV  | UPDATE* |        |        | 4e
         +--------+----------+---------+--------+--------+
         (*:invalid sequences if M1 is an initial INVITE)
</modify>

            Table 3. Offer / Answer Crossing Message Sequences

   (1)  This is indistinguishable from true glare.  UA A should respond
      to M2 with a 491 response.

   (2)  This can only occur in situations depicted in figures 4a and 4b.
      It is easier for UA A to avoid these situations than to recover
      from them.  The situation in Figure 4a can be avoided by
      refraining from sending a re-INVITE without offer when an
      unanswered offer is outstanding.  The situation in Figure 4b can
      be avoided by refraining from sending any message containing an
      offer while an INVITE without offer is outstanding.

   (3)  UA B should not send an UPDATE unless M3(answer1) has acknowledged
        by a 2xx response to a PRACK request, a PRACK request or an ACK
        request.

   (4)  UA B should reject the later request among an UPDATE and a reINVITE.

<add>
   (5)  UA B should reject M1 with a 491 response.
</add>

   Summarizing, a UA that has an outstanding unanswered offer should:
   o  refrain from sending a re-INVITE without an offer;
   o  reject (491) an INVITE or UPDATE containing an offer.
   and
   o  a UA that has sent a INVITE without an offer should not send
      UPDATE, before the completion of offer/answer exchanges.
   o  a UA that has received a INVITE without an offer should not
      send UPDATE, before the completion of offer/answer exchanges.
   o  When offer/answer exchanges using reliable provisional response,
      UA should not send UPDATE with offer unless PRACK transaction
      is completed.

4.2.  Glare Case Handling

   When both ends in a dialog send a new offer at nearly the same time,
   as described in Figure 5, a UA may receive a new offer before it
   receives the answer to the offer it sent.  This case is usually
   called a 'glare' case.

      A                  B
      |offer1      offer2|
   M1 |-------\  /-------| M2
      |        \/        |
      |        /\        |
      |<------/  \------>|

                            Figure 5 Glare Case

   When offer2 is in an UPDATE request or (re-)INVITE request, it must
   be rejected with a 491 response.

   When offer2 is in a PRACK request (within the current rules, only
   possible if offer1 is in an UPDATE request), 

   According to RFC3311/5.1, before the completion of initial INVITE
   transaction, UA A cannot send the UPDATE request(M1) with new offer,
   as shown in Figure 6a. But if this INVITE request is a reINVITE, UA
   A can send it. Naturally UA B reject the UPDATE by 491.

                A                               B
                |                               |
                |                re-INV (offer0)|
                |<------------------------------|
                | 1xx-rel (answer0)             |
                |------------------------------>| --+
                | offer1(UPD)        offer2(PRA)| M2| Acknowledge
             M1 |============\  /===============| <-+
                |             \/                |
                |             /\                |
                |<===========/  \==============>|
                |                      491 (UPD)|
                |<------------------------------|
                |                               |

                Fig. 6a Avoidable glare cases

   UA A has a dilemma: all
   PRACKs are supposed to be accepted with 200 response, yet there is no
   way to indicate the problem with a 200 response.  At best it could
   proceed on the assumption that its INVITE will be rejected with a
   491.  To avoid this glare condition, UA A should not send an offer if
   it has already sent a reliable provisional response containing an
   answer to a previous offer and has not received the corresponding
   PRACK request.

   Glare can also occur when offer2 is in a 1xx or 2xx response.
   This is a variant of 4b, as shown in Figure 6b.

                A                               B
                |                               |
                |re-INV (no offer)              |
                |------------------------------>| --+ 1st reliable
                |offer1(UPD)              offer2| M2| response
             M1 |============\  /===============| <-+
                |             \/   (1xx-rel/2xx)|
                |             /\                |
                |<===========/  \==============>|
                |                      491 (UPD)|
                |<------------------------------|
                |                               |

                Fig. 6b Avoidable glare cases

   To avoid this situation, when UA A has sent a (re)INVITE request without
   session description, it should not send an offer until it has
   received an offer in a reliable response to the (re)INVITE, and sent
   an answer to that offer.

   There is a variant of 4a, as shown in Figure 6c.
   To avoid this glare condition, UA A should not send
   the reINVITE request unless UPDATE transaction is completed.

                A                               B
                |                               |
                |offer1(UPD)                    |
                |==========\                    |
                |re-INV     \                   |
                |------------\----------------->| --+
                |(no offer)   \                 |   |1st reliable
                |              \          offer2|   | response
                |<==============\===============| <-+
                |                \ (1xx-rel/2xx)|
                |                 \             |
                |                  \===========>|
                |                      491 (UPD)|
                |<------------------------------|
                |                               |

                Fig. 6c Avoidable glare cases

   Table 4 summarize this section.

    | offer1   | offer2   | Action | Action |
    |  M1      |  M2      |  of A  |  of B  |
    +----------+----------+--------+--------+
    |          | reINVITE |        |        |
    | reINVITE +----------+        |        |
    |          | UPDATE   | (1)    |        |
    +----------+----------+        |        |
    |          | UPDATE   |        |        |
    |          +----------+--------+   (1)  |
    |          | 1xx-rel  |        |        |
    | UPDATE   +----------+ (2)/(3)|        | 6b/c
    |          | 2xx-INV  |        |        |
    +          +----------+--------+        |
    |          | PRACK  * | (3)    |        | 6a
    +----------+----------+--------+--------+
     (*:invalid sequence if INVITE request is an initial one)

            Table 4. Offer / Answer Glare Message Sequences

    (1) 491 response for the offer
    (2) UA should not send reINVITE without an offer unless
        UPDATE transaction is completed.
    (3) When offer/answer exchanges using reliable provisional response,
        UA should not send UPDATE with offer unless PRACK transaction
        is completed.

---------------------------------------------------------------------

Regards,
Shinji

Paul Kyzivat <[email-masked]>
Mon, 08 Mar 2010 09:25:19 -0500
>I just submitted draft-ietf-sipping-sip-offeranswer-12.txt.
>
>It addresses comments received re -11 from Okumura Shinji, Brett Tate, 
>Gao Yang, and Keith Drage.
>
>Shinji had a number of comments regarding sections 4.1 and 4.2. I tried 
>to fit them in, not literally, but hopefully in spirit. I had better 
>luck with section 4.1. For 4.2 I disagree that 3311 forbids the sending 
>of an UPDATE while awaiting a prack. (It probably should have been, but 
>I don't see that it is.) Ultimately I couldn't figure out how to make 
>the comments on that section work. Modulo the parts I agreed with the 
>existing text has equivalent meaning, so I left it unchanged.
>
>Brett pointed out that Retry-After cannot be used with 491. I have 
>removed any suggestion that it should be.
>
>Gao wanted more emphasis on avoiding cases where it might be necessary 
>to fail a prack. I have reworded things to make that more explicit and 
>removed suggestions to use 491 as a response to prack.
>
>Keith objected to normative language in the suggestions that Gao made. I 
>have avoided using normative language.
>
>Please review this carefully - its always possible that subtle issues 
>could have crept in.
>
>	Thanks,
>	Paul
>
>IETF I-D Submission Tool wrote:
>> A new version of I-D, draft-ietf-sipping-sip-offeranswer-12.txt has been successfuly submitted by Paul Kyzivat and posted to 
>> the IETF repository.
>> 
>> Filename:	 draft-ietf-sipping-sip-offeranswer
>> Revision:	 12
>> Title:		 SIP (Session Initiation Protocol) Usage of the Offer/Answer Model
>> Creation_date:	 2010-03-08
>> WG ID:		 sipping
>> Number_of_pages: 22
>> 
>> Abstract:
>> The Session Initiation Protocol (SIP) utilizes the offer/answer model
>> to establish and update multimedia sessions using the Session
>> Description Protocol (SDP).  The description of the offer/answer
>> model in SIP is dispersed across multiple RFCs.  This document
>> summarizes all the current usages of the offer/answer model in SIP
>> communication.
>>                                                                                   
>> 
>> 
>> The IETF Secretariat.