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

From: Paul Kyzivat <[email-masked]>
Date: 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.
> 
> 
>

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 10 Mar 2010 18:23:36 +0900

Hi Paul,

>to fit them in, not literally, but hopefully in spirit.

Thank you for your work.

>                                                         I had better 
>I don't see that it is.)

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

[OS]>I think that the offer1 is a protocol violation as PRACK case in 4.1.
[OS]>Probably RFC3311(UPDATE) prohibits this operation.

RFC3311/Page 5
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, has
     received a PRACK for that reliable provisional response, 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.

At the time of sending the UPDATE, UA A(callee) has NOT received
a PRACK for that reliable provisional response. According to the
above description, the UPDATE cannot be sent with an offer.

Regards,
Shinji

>                          Ultimately I couldn't figure out how to make 
>> 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.
>>

---

From: [email-masked]
Date: Thu, 11 Mar 2010 09:08:41 +0800

Hi,

I just find time to review the parts about PRACK and non-offer ReINVITE.

I am OK with the PRACK parts now. 

The ReINVITE part is a little complex as it has two levels. The first 
level is the UAS should arrange the offer by it's means. And it has been 
modified, and I am OK with it now.
The second level is the BCP/normative description about the content of the 
offer. I think we still haven't come to an agreement. But I really think 
that as there are people(such as Keith and you) treat it as normative 
description, I am OK with your current text.

Thanks,

Gao

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email-masked]
===================================

Paul Kyzivat <[email-masked]> 
发件人:  [email-masked]
2010-03-08 22:25

收件人
sipping <[email-masked]>
抄送

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

                 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.
> Title:                                  SIP (Session Initiation 
Protocol) Usage of the Offer/Answer Model
> summarizes all the current usages of the offer/answer model in SIP
_______________________________________________
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

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 11 Mar 2010 21:30:16 +0900

Hi all,

I study RFC3311 again, so I change my comment.

> For 4.2 I disagree that 3311 forbids the sending 

I agree. This forbode is not clear.
In initial INVITE transaction, RFC3311 forbids this UPDATE.
But for reINVITE, RFC3311 say little.

>4.1.  Message Crossing Case Handling

I revise the table 3.

     | M1     | M3       | M2      | Action of A         | Action of B                |
     |(offer1)|(answer1) |(offer2) |                     |                            |
     +--------+----------+---------+---------------------+----------------------------+
     | UPDATE | 2xx-UPD  | UPDATE  |                     |                            |
     |        |          +---------| 491 response for M2 |                            |
     |        |          | INVITE  |                     |                            |
     |        |          +---------+---------------------+                            |
     |        |          | 1xx-INV | should not send     |                            |
     |        |          +---------+ Mx until M3 in 4a,  |                            |
     |        |          | 2xx-INV | M1 until My in 4b   |                            |
     +--------+----------+---------+---------------------+                            |
     | PRACK  | 2xx-PRA  | UPDATE  |                     |                            |
     +--------+----------+---------+                     |                            |
     | 2xx-INV| ACK      | UPDATE  | 491 response for M2 |                            |
     |        |          +---------+                     |                            |
     |        |          | INVITE  |                     |                            |
     +--------+----------+---------+                     +----------------------------+
     | 1xx-rel| PRACK    | UPDATE  |                     | should not send UPDATE     |
     +--------+----------+---------+                     | until ACK/PRACK transaction|
     | INVITE | 1xx-rel  | UPDATE* |                     | is completed.              |
     |        |----------+---------+                     |                            |
     |        | 2xx-INV  | UPDATE* |                     | (*:invalid for init-INVITE)|
     +--------+----------+---------+---------------------+----------------------------+

>4.2.  Glare Case Handling

I propose that the following Figures and Table are added in this section.

    A                               B
    |                               |
    |                re-INV (offer0)|
    |                      491 (UPD)|

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

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

    | offer1   | offer2   | Action of A                | Action of B                |
    +----------+----------+----------------------------+----------------------------+
    |          | reINVITE |                            |                            |
    | reINVITE +----------+                            |                            |
    |          | UPDATE   | 491 response for the offer2|                            |
    +----------+----------+                            |                            |
    |          | UPDATE   |                            |                            |
    |          +----------+----------------------------+ 491 response for the offer1|
    |          | 1xx-rel  | should not send UPDATE     |                            |
    | UPDATE   +----------+ until ACK/PRACK transaction|                            |
    |          | 2xx-INV  | is completed               |                            |
    +          +----------+                            |                            |
    |          | PRACK  * | (*:invalid for init-INVITE)|                            |
    +----------+----------+----------------------------+----------------------------+

Regards,
Shinji

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Mar 2010 08:39:05 -0500

[email-masked] wrote:
> The second level is the BCP/normative description about the content of 
> the offer. I think we still haven't come to an agreement. But I really 
> think that as there are people(such as Keith and you) treat it as 
> normative description, I am OK with your current text.

I am not considering anything in this document as normative.
If you see something that you think makes it so, please point it out.

Otherwise, I'm glad to hear you are ok with the text.

	Thanks,
	Paul

> *Paul Kyzivat <[email-masked]>*
>  > 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.
>  >

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Mar 2010 08:45:46 -0500

Shinji,

I have had a lot of difficulty weaving the various suggestions into the 
overall document. If you would like to see changes like this, can I ask 
a favor of you - could you also please propose the specific text changes 
that are necessary to complete the integration into the document?

	Thanks,
	Paul

---

From: [email-masked]
Date: Fri, 12 Mar 2010 09:05:45 +0800

> If you see something that you think makes it so, please point it out.

 I did not mean there's something normative in current text. I means that 
I think my *second level* suggestion is BCP, but you and Keith treat it as 
normative.

As I think this bifurcation is not critical, so I said I am OK with it.

Thanks,

Gao

> > ZTE Information Security Notice: The information contained in this
> mail is solely property of the sender's organization. This mail 
> communication is confidential. Recipients named above are obligated 
> to maintain secrecy and are not permitted to disclose the contents 
> of this communication to others.
> > This email and any files transmitted with it are confidential and 
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please 
> notify the originator of the message. Any views expressed in this 
> message are those of the individual sender.

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 12 Mar 2010 20:16:32 +0900

Hi Paul,

I've tried.

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

   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

         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

   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)              |
                +-> |==============================>| --+
                    |                               |   | Acknowledge
                    |                   answer1(PRA)| M3|
                    |<===========\  /===============| <-+
                    |             \/                |
                    |             /\     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

   Table 4 summarize this section.

     | M1     | M3       | M2      | Action | Action |
     |(offer1)|(answer1) |(offer2) |  of A  |  of B  |
     +--------+----------+---------+--------+--------+
     | UPDATE | 2xx-UPD  | UPDATE  |        |        |
     |        |          +---------| (1)    |        |
     |        |          | INVITE  |        |        |
     |        |          +---------+--------+--------+
     |        |          | 1xx-INV | (2)    |        |
     |        |          +---------+        |        |
     |        |          | 2xx-INV |        |        |
     +--------+----------+---------+--------+        |
     | PRACK  | 2xx-PRA  | UPDATE  |        |        |
     +--------+----------+---------+        |        |
     | 2xx-INV| ACK      | UPDATE  | (1)    |        |
     |        |          +---------+        |        |
     |        |          | INVITE  |        |        |
     +--------+----------+---------+        +--------+
     | 1xx-rel| PRACK    | UPDATE  |        |        |
     +--------+----------+---------+        |        |
     | INVITE | 1xx-rel  | UPDATE* |        | (3)    |
     |        |----------+---------+        |        |
     |        | 2xx-INV  | UPDATE* |        |        |
     +--------+----------+---------+--------+--------+
     (*:invalid sequences if M1 is an initial INVITE)

            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.

   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)             |
                |------------------------------>| --+
                |                               |   | Acknowledge
                | offer1(UPD)        offer2(PRA)| M2|
             M1 |============\  /===============| <-+
                |             \/                |
                |             /\                |
                |<===========/  \==============>|
                |                               |
                |                      491 (UPD)|
                |<------------------------------|
                |                               |

                Fig. 6a Avoidable message crossing 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)              |
                |------------------------------>| --+
                |                        offer2 |   | 1st reliable
                |offer1(UPD)       (1xx-rel/2xx)| M2| response
             M1 |============\  /===============| <-+
                |             \/                |
                |             /\                |
                |<===========/  \==============>|
                |                               |
                |                      491 (UPD)|
                |<------------------------------|
                |                               |

                Fig. 6b Avoidable message crossing 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)     \        offer2 |   |1st reliable
                |                \ (1xx-rel/2xx)|   | response
                |<================\=============| <-+
                |                  \            |
                |                   \           |
                |                    \=========>|
                |                               |
                |                      491 (UPD)|
                |<------------------------------|
                |                               |

                Fig. 6c Avoidable message crossing 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)|        |
    |          | 2xx-INV  |        |        |
    +          +----------+--------+        |
    |          | PRACK  * | (3)    |        |
    +----------+----------+--------+--------+
     (*:invalid sequence if INVITE request is an initial one)

            Table 4. 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

---

From: OKUMURA Shinji <[email-masked]>
Date: Mon, 15 Mar 2010 18:56:06 +0900

Hi Paul,

Additional descriptions in line.

Regards,
Shinji

<add>
   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.
</add>
>                Figure 4b Avoidable message crossing cases
<add>
   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.
</add>
>   unless it has received a 2xx response to the PRACK request.
<modify>
     |        |          +---------| (1)    |  -     |
     |        |          | 1xx-INV | (2)    | (4)    |
     | 2xx-INV| ACK      | UPDATE  | (1)    |  -     |
</modify>
>        by a 2xx response to a PRACK request, a PRACK request or an ACK
<add>
   (4)  UA B should reject the later request among an UPDATE and a reINVITE.
</add>

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 17 Mar 2010 15:51:41 +0900

Hi oa-lovers,

I have two proposals.

|2.2.  Rejection of an Offer
| (snip)
|  Alternatively the UA may terminate the
|  dialog and send an error response to the INVITE request

I propose the alternative text for the above-mentioned one.

-------------------------------------------------------------------
   Alternatively the UA may send an error response to the (re)INVITE
   request to terminate the dialog or to roll back the offer-answer
   status before sending reINVITE request. In this case UAS should not
   continue to retransmit the unacknowledged reliable provisional
   response, UAC should not continue to retransmit a PRACK request.
-------------------------------------------------------------------

|2.2.  Rejection of an Offer
| (snip)
|   (While it may be tempting to respond with a 488 response in this
|   case, that is not recommended, because it does not acknowledge the
|   response.)

488 response to PRACK is still tempting for (hopefully not only) me.

"UAS may respond 488 and UAC should send again PRACK without offer."

I think it doesn't violate the current normative definition,
the process is more effective than always-200OK with a meaningless SDP.

I propose the alternative text for the above-mentioned one.

-------------------------------------------------------------------
   The 488 response is another proposed solution, UAS may respond with
   a 488 response and then UAC should send again a PRACK request without
   an offer.
-------------------------------------------------------------------

By way of caution, I do not deny "always-200OK".

Regards,
Shinji

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 19 Mar 2010 19:58:11 +0900

Hi,

I have some additional comments and proposals.

|2.2.  Rejection of an Offer
| (snip)
|   final response is sent, then a 2xx response should be sent, with a
|   syntactically correct response.

I think "session description" is more appropriate than "response".

I propose the alternative text for the above-mentioned one.
------------------------------------------------------------------------
   final response is sent, then a 2xx response should be sent, with a
   syntactically correct session description.
------------------------------------------------------------------------

|3.1.1.  INVITE Request with SDP
| (snip)
|   not completed yet and the UAC must not send a new offer until it
|   receives the same SDP in the first reliable response, which is the
|   real answer.  After sending the SDP in F6, the UAS must prepare to
|   receive a new offer from the UAC with an UPDATE request or a PRACK
|   request.

"first" is not necessary.
and UAS may not support UPDATE in this case.

I propose the alternative text for the above-mentioned one.
------------------------------------------------------------------------
   not completed yet and the UAC must not send a new offer until it
   receives the same SDP in the reliable non-failure response, which is the
   real answer.  After sending the SDP in F6, the UAS must prepare to
   receive a new offer from the UAC with a PRACK request or an UPDATE
   request if supporting it.
------------------------------------------------------------------------

|3.3.  Offer/Answer Exchange in an Established Dialog
| (snip)
|   needed.  Otherwise, some 3pcc flows will break.

I think it is necessary to clarify the reason why some 3pcc flows will break.
At least there should be "See RFCxxxx Section xx".

|5.2.3.  Answering an Initial INVITE with Offer
| (snip)
|   port number in the answer.  The media lines that are accepted should
|   typically be those that would have been offered had the INVITE not
|   contained an offer, excluding those not offered.

This is a matter of wording.
I propose the alternative text for the above-mentioned one.
------------------------------------------------------------------------
   port number in the answer.  The media lines that are accepted should
   typically be the intersection of the offered ones and the willing
   ones if UAS was an offerer.
------------------------------------------------------------------------

|5.2.3.  Answering an Initial INVITE with Offer
| (snip)
|   support at this time.  However there is little benefit to including
|   added types.

about the "little benefit"

I propose the alternative text for the above-mentioned one.
------------------------------------------------------------------------
   support at this time.  Therefore asymmetric media format is
   tentatively negotiated.  However there is a problem that this
   negotiated status can not be refreshed by sending an offer in the
   opposite direction.  And besides some implementations only support
   sending and receiving symmetric media format.
------------------------------------------------------------------------

|5.2.3.  Answering an Initial INVITE with Offer

adding at the end of the section.
------------------------------------------------------------------------
   When UAS reject all media lines, it may not send the failure response.
   Alternatively it may send the reliable non-failure response including
   the all media line with a zero port.
------------------------------------------------------------------------

|5.2.4.  Answering when the Initial INVITE had no Offer

adding at the end of the section.
------------------------------------------------------------------------
   Even when UAC reject all media lines, it can not reject signally the
   offer included in the reliable non-failure response.  And then it
   must send a PRACK or an ACK request including the all media line with
   a zero port.  Alternatively it may send a CANCEL or a BYE request to
   terminate the dialog.
------------------------------------------------------------------------

|5.2.5.  Subsequent Offers and Answers
| (snip)
|     NOTE: This may be impossible for a B2BUA to follow in some
|     cases (e.g. 3pcc transfer) if it does not terminate media.

I think it is necessary to clarify the reason why some B2BUA can not follow.
At least there should be "See RFCxxxx Section xx".

|5.3.  Hold and Resume of media
| (snip)
|  forced to answer something else.  Without this behavior it is
|  possible to get "stuck on hold" in some cases, especially when a
|  third-party call controller is involved.

I think it is necessary to clarify the reason why some UA "stuck on hold".
At least there should be "See RFCxxxx Section xx".

|5.4.  Behavior on receiving SDP with c=0.0.0.0
| (snip)
|  c=0.0.0.0 has
|  no special meaning for the direction attribute of the accepted stream
|  in the answer.

I propose the alternative text for the above-mentioned one.
------------------------------------------------------------------------
   There is no clear rule for "c=0.0.0.0" in the answer.  But the offerer
   probably stop sending the RTP/RTCP toward the answerer.  Because
   "0.0.0.0" is not an effective IP address.
------------------------------------------------------------------------

Regards,
Shinji