Subject: [Sipping] Comments on draft-ietf-sipping-sip-offeranswer-03.txt

From: "B, Nataraju" <[email-masked]>
Date: Mon, 3 Sep 2007 14:43:01 +0530

All, 

Here are few comments about the draft
draft-ietf-sipping-sip-offeranswer-03.txt.

1. In Table-2 option 3 seems to be redundant and is not conveying any
useful information or the intended meaning is not been mentioned clearly
in the this section about offer rejection.

	         Offer                Rejection  
       -----------------------------------------------------  
       1. INVITE Req.          488 INVITE Response  

       3. INVITE Req.          488 INVITE Response (same as Pattern 1.)

       Table 2. Rejection against an Offer

2. in sec 3.1. Message Crossing Case Handling, 
       A                  B  
        |offer1            |  
        |----------------->|  
        |           answer1|  
        |<------\  /-------|  
        |        \/        |  
        |        /\  offer2|  
        |<------/  \-------|  

The paragraph is relatively difficult to understand. Can we divide this
logic into few more sections so that it would be easy to describe the
expected behavior, which include offer/answer in which request/response?

For example 
offer1 - INVITE request
answer1 - 1xx response
offer2 - UPDATE request
Or offer2 - PRACK request
.....................
OR 
Following diagrammatic presentation would convey the information better.

       A                               B  
        |offer1 (INV)                  |  
        |----------------------------->|  
        |              answer1(100-rel)|  
        |<--------------\  /-----------|  
        |                \/            |  
        |                /\ offer2(UPD)|  
        |<--------------/  \-----------|  

We can mention the above set of information per scenario so that any one
can easily understand the logic behind each of the scenarios.
	When offer2 is in an UPDATE request or a re-INVITE request
		Behavior-1 ............
	When offer2 is in a PRACK request
		Behavior-2 ............
	When offer2 is in a reliable provisional response or a
successful final response
		Behavior-3 ............

Probably by drawing a separate diagrams for different scenarios would
help explain the logic in simpler terms and easy for any one to
understand. 

Similarly we can update the section 3.2 also.

Thanks,
Nataraju A B
Sonus Networks India Pvt Ltd.,
_______________________________________________
Sipping mailing list  https://www1.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: "B, Nataraju" <[email-masked]>
Date: Tue, 4 Sep 2007 14:49:59 +0530

Few more minor comments…

Sec 4.2.4. Answering when Initial INVITE had no Offer
       When a UAC has sent an initial INVITE without an offer, and then 
       receives a response with the first offer, it should answer in the 
       same way as a UAS receiving an initial INVITE with an offer.

Comment: 
We can add one more sentence to mention, this offer (one sent in 1st reliable response) is also same as what would have been offered when this sip endpoint initiates an offer/answer negotiation.

Sec 4.2.5. Subsequent Offers and Answers

       o The number of m-lines may not be reduced in a subsequent offer. 
          Previously rejected media streams must remain, or be reused to 
          offer the same or a different stream.

Comment: 
This requirement should have been mentioned as MUST requirement. Change “may not” to “MUST NOT”

Sec 4.3. Hold and Resume of media
    
      If UA2 has been "placed on hold" by UA1 via receipt of "a=inactive", 
       and subsequently wants to initiate its own hold, also using 
       "a=inactive", it need not send a new offer, since the only valid 
       response is "a=inactive" and that is already in effect. However, its 
       local desired state will now be either "inactive". This affects what 
       it will send in future offers and answers.

Comment: 
Incomplete sentence “However, its local desired state will now be either "inactive".”

Sec 5.2 Commit/Rollback of Offer/Answer on Unsuccessful re-INVITE Transaction

       UAC                   UAS  
         | session established |  
         |<===================>|  
         |                     |  
         | F1  re-INVITE (SDP) |  
         |-------------------->|  
         | F2 1xx-rel (SDP)    |  
         |<--------------------|  
         | F3   PRACK          | <- PRACK request may include new offer and 
         |-------------------->|    can complete the offer/answer with  
         | F4 2xx PRA          |    the answer in 2xx PRACK response. 
         |<--------------------|  
         |                     | <- UPDATE method can update the session 
         |                     |    status before receiving the final 
         | F5 4xx/5xx/6xx INV  |    response to re-INVITE request (F1). 
         |<--------------------|  
         | F6     ACK          |  
         |-------------------->|  Issue: What is the correct session status 
         |                     |         after re-INVITE transaction. 
     
Comment:
Here probably dropping all the offer/answer negotiations transacted during open re-INVITE, and roll back to one negotiated during initial INVITE transaction. Let the session status be committed only when the re-INVITE transaction is completed successfully.

One more scenario to be addressed:

       UAC                   UAS  
         | session established |  
         |<===================>|  
         |                     |  
         | F1  re-INVITE (SDP) |  
         |-------------------->|  
         | F2 1xx-rel (SDP)    |  
         |<--------------------|  

         | F3   PRACK          | <- PRACK request may include new offer and 
         |-------------------->|    can complete the offer/answer with  
         | F4 2xx PRA          |    the answer in 2xx PRACK response. 
         |<--------------------|  

         | F5  UPDATE (SDP)    |  
         |-------------------->|  
         | F6 200-UPD (SDP)    |  
         |<--------------------|  

         | F7  UPDATE (SDP)    |  
         |<--------------------|  
         | F8 488-UPD (SDP)    |  offer in UPDATE is not acceptable (o/a failed)
         |-------------------→|  

         | F9 2xx INV          |    Success response to re-INVITE request (F1). 
         |<--------------------|  
         | F10   ACK           |  
         |-------------------->|  Issue: What is the correct session status 
         |                     |         after re-INVITE transaction. 

Here there are two alternatives for session status:
Option-1: 
Commit the session status to one negotiated with UPD/200 F5/F6.

Option-2: 
Commit the session status to one negotiated with UPD/200 F1/F2.

I feel option-2 would be better, since that makes easy to implement and easy to roll back in case of subsequent o/a failure before the re-INVITE transaction completes.

Generic comment:
Also, it might be worth mentioning the sentence “There could be ONLY ONE offer/answer negotiation open at any point in time”. This is inherited from 3264, but it’s the very basic and necessary requirement for all these scenarios. Probably Sec 1.1 is a better place for this one to mention.

Thanks, 
Nataraju A B 

_____________________________________________
From: B, Nataraju 
Sent: Monday, September 03, 2007 2:43 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Comments on draft-ietf-sipping-sip-offeranswer-03.txt

All, 

Here are few comments about the draft draft-ietf-sipping-sip-offeranswer-03.txt.

1. In Table-2 option 3 seems to be redundant and is not conveying any useful information or the intended meaning is not been mentioned clearly in the this section about offer rejection.

	         Offer                Rejection  

The paragraph is relatively difficult to understand. Can we divide this logic into few more sections so that it would be easy to describe the expected behavior, which include offer/answer in which request/response?

For example 
offer1 – INVITE request
answer1 – 1xx response
offer2 – UPDATE request
Or offer2 – PRACK request
…………………
OR 

We can mention the above set of information per scenario so that any one can easily understand the logic behind each of the scenarios.
	When offer2 is in an UPDATE request or a re-INVITE request
		Behavior-1 …………
	When offer2 is in a PRACK request
		Behavior-2 …………
	When offer2 is in a reliable provisional response or a successful final response
		Behavior-3 …………

Probably by drawing a separate diagrams for different scenarios would help explain the logic in simpler terms and easy for any one to understand. 

Thanks,
Nataraju A B

---

From: Takuya Sawada <[email-masked]>
Date: Tue, 4 Sep 2007 22:32:00 +0900

Hi, Nataraju,

Thanks for the comments.
Response inline.

> ----------------
> From: "B, Nataraju" <[email-masked]>
> Date: Mon, 3 Sep 2007 14:43:01 +0530
> To: <[email-masked]>, <[email-masked]>
> Cc: [email-masked]
> Subject: [Sipping] Comments on draft-ietf-sipping-sip-offeranswer-03.txt
> 
> All,
> 
The intention of Table 2 is to show how to reject an offer corersponding
to each offer in Table 1. That is why Table 2 has 6 rows even row 1. and
row 3. is redundant. There is no difference between offers in 1. and 3.
in Table 1, but only difference in answers.
This intention is mentioned in the first paragraph in section 2.1.

       How to reject an offer when it can not be accepted is not so clear 
       and some methods can not allow explicit rejection against an offer. 
       Corresponding to the patterns in Table 1, how to reject an offer is 
       shown in Table 2. 

Does this make sense?

>         |offer1 9:34:12 2007
To: [email-masked]
Subject: Re:[Sipping] Comments on draft-ietf-sipping-sip-offeranswer-03.txt
From: Takuya Sawada <[email-masked]>
Date: Tue, 4 Sep 2007 22:32:00 +0900
Cc: [email-masked], [email-masked]

Hi, Nataraju,

Thanks for the comments.
Response inline.

> ----------------
> From: "B, Nataraju" <[email-masked]>
> Date: Mon, 3 Sep 2007 14:43:01 +0530
> To: <[email-masked]>, <[email-masked]>
> Cc: [email-masked]
> Subject: [Sipping] Comments on draft-ietf-sipping-sip-offeranswer-03.txt
> 
> All,
> 
The intention of Table 2 is to show how to reject an offer corersponding
to each offer in Table 1. That is why Table 2 has 6 rows even row 1. and
row 3. is redundant. There is no difference between offers in 1. and 3.
in Table 1, but only difference in answers.
This intention is mentioned in the first paragraph in section 2.1.

       How to reject an offer when it can not be accepted is not so clear 
       and some methods can not allow explicit rejection against an offer. 
       Corresponding to the patterns in Table 1, how to reject an offer is 
       shown in Table 2. 

Does this make sense?

> 2. in sec 3.1. Message Crossing Case Handling,
I agree that it is relatively difficult to understand.
It is complicated in nature.

Let me try. How about adding a Table and Figures below?

offer2 | How to know it's not answer  | Actions to take
-------+------------------------------+--------------------------
INVITE | Never be an answer           | 491 response 
UPDATE | Glare case for UA A          | with Retry-After
-------+------------------------------+--------------------------
PRACK  | Not a pattern 4. in Table 1. | Wait sending response
       | 1xx-rel must have an answer, | until answer1 is received
       | not an offer.                | 
-------+------------------------------+--------------------------
1xx-rel| Only one INVITE transaction  | Wait sending acknowledge
2xx    | at a time. Then UA can know  | until answer1 is received
-------+------------------------------+--------------------------
NOTE: PRACK and 1xx-rel/2xx case are extremely rare case and
easily avoidable. See Figure X. and Y.

Table X. UA's action to the offer (offer2) overtaken the previous
         answer (answer1)

 A                               B 
 |                               |
 |                   INV (offer0)| 
 |<------------------------------| 
 | 1xx-rel (answer0)             |
 |------------------------------>| --+
 |offer1(e.g. UPD)               |   |
 |==============================>|   |
 |              answer1 (2xx-UPD)|   | Acknowledge
 |<===========\  /===============|   |
 |             \/                |   |
 |             /\     offer2(PRA)|   |
 |<===========/  \===============| <-+
 | answer2 (2xx-PRA)             |
 |------------------------------>| Wait until answer1
 |                               |

Figure X. PRACK as a message with offer2 in message cross case

 A                               B 
 |                               |
 |offer1(e.g. UPD)               | 
 |==============================>| 
 |re-INV (no offer)              |
 |------------------------------>| --+
 |              answer1 (2xx-UPD)|   |
 |<===========\  /===============|   | First reliable response
 |             \/          offer2|   |
 |             /\   (1xx-rel/2xx)|   |
 |<===========/  \===============| <-+
 | answer2 (PRACK/ACK)           |
 |------------------------------>| Wait until answer1
 |                               |

Figure Y. Reliable response as a message with offer2 in message
          cross case

I noticed that 'PRACK' should be 'PRACK or ACK' in the following 
sentence.

       In this case, UA A            | 
I agree that it is relatively difficult to understand.
It is complicated in nature.

Let me try. How about adding a Table and Figures below?

offer2 | How to know it's not answer  | Actions to take
-------+------------------------------+--------------------------
INVITE | Never be an answer           | 491 response 
UPDATE | Glare case for UA A          | with Retry-After
-------+------------------------------+--------------------------
PRACK  | Not a pattern 4. in Table 1. | Wait sending response
       | 1xx-rel must have an answer, | until answer1 is received
       | not an offer.                | 
-------+------------------------------+--------------------------
1xx-rel| Only one INVITE transaction  | Wait sending acknowledge
2xx    | at a time. Then UA can know  | until answer1 is received
-------+------------------------------+--------------------------
NOTE: PRACK and 1xx-rel/2xx case are extremely rare case and
easily avoidable. See Figure X. and Y.

Table X. UA's action to the offer (offer2) overtaken the previous
         answer (answer1)

 A                               B 
 |                               |
 |                   INV (offer0)| 
 |<------------------------------| 
 | 1xx-rel (answer0)             |
 |------------------------------>| --+
 |offer1(e.g. UPD)               |   |
 |==============================>|   |
 |              answer1 (2xx-UPD)|   | Acknowledge
 |<===========\  /===============|   |
 |             \/                |   |
 |             /\     offer2(PRA)|   |
 |<===========/  \===============| <-+
 | answer2 (2xx-PRA)             |
 |------------------------------>| Wait until answer1
 |                               |

Figure X. PRACK as a message with offer2 in message cross case

 A                               B 
 |                               |
 |offer1(e.g. UPD)               | 
 |==============================>| 
 |re-INV (no offer)              |
 |------------------------------>| --+
 |              answer1 (2xx-UPD)|   |
 |<===========\  /===============|   | First reliable response
 |             \/          offer2|   |
 |             /\   (1xx-rel/2xx)|   |
 |<===========/  \===============| <-+
 | answer2 (PRACK/ACK)           |
 |------------------------------>| Wait until answer1
 |                               |

Figure Y. Reliable response as a message with offer2 in message
          cross case

I noticed that 'PRACK' should be 'PRACK or ACK' in the following 
sentence.

       In this case, UA A can not 
       reject offer2 in a reliable response, it is recommended to wait for 
       answer1 before sending a PRACK request with the answer to offer2. 
       Note that this case only occurs when UA A, while waiting for an 
       answer, sends an INVITE request without session description.  

> Similarly we can update the section 3.2 also.
I will try if the direction above is the way to go.

Regards,
Takuya

> Sonus Networks India Pvt Ltd.,

--------
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]

can not 
       reject offer2 in a reliable response, it is recommended to wait for 
       answer1 before sending a PRACK request with the answer to offer2. 
       Note that this case only occurs when UA A, while waiting for an 
       answer, sends an INVITE request without session description.  

> Similarly we can update the section 3.2 also.
I will try if the direction above is the way to go.

Regards,
Takuya

> Sonus Networks India Pvt Ltd.,

--------
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]

---

From: "B, Nataraju" <[email-masked]>
Date: Wed, 5 Sep 2007 13:56:08 +0530

Takuya,

Few responses inline...

Thanks,
Nataraju A B

> -----Original Message-----
> From: Takuya Sawada [mailto:[email-masked]]
> Sent: Tuesday, September 04, 2007 7:02 PM
> To: B, Nataraju
> Cc: [email-masked]; [email-masked]
> > Subject: [Sipping] Comments on
draft-ietf-sipping-sip-offeranswer-03.txt
>        Corresponding to the patterns in Table 1, how to reject an
offer is
[ABN] sounds OK.

> offer2 | How to know it's not answer  | Actions to take
[ABN] looks to be fine, if we try to cover many scenarios in a single
diagram, it would lead to confusion. But we can always club scenarios
which fall into similar pre-conditions.

The sec 3.1 was confusing mainly due to specifies diagram and the PRACK
message handling explanation.

Keeping table is also fine, but the diagram and explanation must be
clear enough for each of the cross-over scenarios.

Also we could try to cover almost all the race conditions being
discussed in draft draft-ietf-sipping-race-examples-04.txt

---

From: "B, Nataraju" <[email-masked]>
Date: Tue, 4 Sep 2007 14:18:11 +0530

Few more minor comments...

Comment: 

We can add one more sentence to mention, this offer (one sent in 1st
reliable response) is also same as what would have been offered when
this sip endpoint initiates an offer/answer negotiation.

Comment: 

This requirement should have been mentioned as MUST requirement. Change
"may not" to "MUST NOT"

      If UA2 has been "placed on hold" by UA1 via receipt of
"a=inactive", 

       response is "a=inactive" and that is already in effect. However,
its 

       local desired state will now be either "inactive". This affects
what 

Comment: 

Incomplete sentence "However, its local desired state will now be either
"inactive"."

Sec 5.2 Commit/Rollback of Offer/Answer on Unsuccessful re-INVITE
Transaction

       UAC                   UAS  

         | session established |  

         |<===================>|  

         |                     |  

         | F1  re-INVITE (SDP) |  

         |-------------------->|  

         | F2 1xx-rel (SDP)    |  

         |<--------------------|  

         | F3   PRACK          | <- PRACK request may include new offer
and 

         |<--------------------|  

         |<--------------------|  

         | F6     ACK          |  

         |-------------------->|  Issue: What is the correct session
status 

Comment:

Here probably dropping all the offer/answer negotiations transacted
during open re-INVITE, and roll back to one negotiated during initial
INVITE transaction. Let the session status be committed only when the
re-INVITE transaction is completed successfully.

       UAC                   UAS  

         | session established |  

         |<===================>|  

         |                     |  

         | F1  re-INVITE (SDP) |  

         |-------------------->|  

         | F2 1xx-rel (SDP)    |  

         |<--------------------|  

         | F3   PRACK          | <- PRACK request may include new offer
and 

         |<--------------------|  

         | F5  UPDATE (SDP)    |  

         |-------------------->|  

         | F6 200-UPD (SDP)    |  

         |<--------------------|  

         | F7  UPDATE (SDP)    |  

         |<--------------------|  

         | F8 488-UPD (SDP)    |  offer in UPDATE is not acceptable (o/a
failed)

         |--------------------->|  

         | F9 2xx INV          |    Success response to re-INVITE
request (F1). 

         |<--------------------|  

         | F10   ACK           |  

         |-------------------->|  Issue: What is the correct session
status 

Option-1: 

Option-2: 

I feel option-2 would be better, since that makes easy to implement and
easy to roll back in case of subsequent o/a failure before the re-INVITE
transaction completes.

Also, it might be worth mentioning the sentence "There could be ONLY ONE
offer/answer negotiation open at any point in time". This is inherited
from 3264, but it's the very basic and necessary requirement for all
these scenarios. Probably Sec 1.1 is a better place for this one to
mention.

Thanks, 
Nataraju A B 

  _____  

From: B, Nataraju [mailto:[email-masked]] 
Sent: Monday, September 03, 2007 2:43 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [Sipping] Comments on draft-ietf-sipping-sip-offeranswer-03.txt

All, 

                 Offer                Rejection  

        

       A                  B  

        |offer1            |  

        |----------------->|  

        |           answer1|  

        |<------\  /-------|  

        |        \/        |  

        |        /\  offer2|  

        |<------/  \-------|  

For example 

offer1 - INVITE request

answer1 - 1xx response

offer2 - UPDATE request

.....................

OR 

       A                               B  

        |offer1 (INV)                  |  

        |              answer1(100-rel)|  

        |                \/            |  

        |                /\ offer2(UPD)|  

                Behavior-1 ............

                Behavior-2 ............

                Behavior-3 ............

Thanks,

Nataraju A B