Re: [Sipping] New Version Notificationfordraft-ietf-sipping-sip-offeranswer-12

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,

I study RFC3311 again, so I change my comment.

> 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.)

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)|
    |<------------------------------|
    |                               |
    | 1xx-rel (answer0)             |
    |------------------------------>| --+
    |                               |   | Acknowledge
    | offer1(UPD)        offer2(PRA)|   |
    |============\  /===============| <-+
    |             \/                |
    |             /\                |
    |<===========/  \==============>|
    |                               |
    |                      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

>Hi Paul,
>
>>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.
>
>Thank you for your work.
>
>>                                                         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.)
>
>    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 
>>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.
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP

[Index of Archives]     [IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

  Powered by Linux