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
