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
OKUMURA Shinji wrote:
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
