Hi,
I have some comments about section 4.
These comments are almost the same as my comments for draft-08
in last September.
>4.1. Message Crossing Case Handling
>
> 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 is a variant, shown in Figure 4, which is dependent on an
> INVITE (Mx) that contains no offer. This case should be extremely
> rare - it is easily avoided by delaying Mx until answer1 is received.
> It adds another possibility to 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 |------------------------------>| Wait until answer1
> | |
>
> Figure 4 Reliable response as a message with offer2 in message
> crossing case
re-INVITE without SDP must cause new offer-answer exchange,
so that I think UA A should not send re-INVITE, until answer1
is received. It is simpler.
And in section 4.2
> To avoid a glare condition involving an offer in a response, 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.
I think the same rule should be adjusted.
A should delay sending the re-INV(no offer) until M3.
B is recommended to respond 491 for this re-INV.
> | M1 | M3 | M2 |
> |--------+----------+---------|
> | INVITE | 1xx-rel | UPDATE | <-- not happen
> |--------+----------+---------|
> | PRACK | 200-PRA | UPDATE |
> |--------+----------+---------|
> | UPDATE | 200-UPD | UPDATE |
> | | |---------|
> | | | INVITE | (no INV in progress)
> | | |---------|
> | | | 2xx-INV | (INV in progress)
> | | |---------|
> | | | 1xx-rel | (from Figure 4)
> |-----------------------------|
>
> Table 3. Offer / Answer Crossing Message Sequences
1st case is not happen.
Probably RFC3311(UPDATE) prohibits this signaling.
I revise the table 3.
| M1 | M3 | M2 |
+--------+----------+---------+
| UPDATE | 2xx-UPD | UPDATE | 491
| | +---------|
| | | INVITE | 491
| | +---------+
| | | 2xx-INV | A SHOULD Delay re-INV until M3
| | +---------+
| | | 1xx-INV | B is RECOMMENDED to respond 491 for this re-INV
+--------+----------+---------+
| INVITE | 1xx-rel | -- |
|--------+----------+---------+
| INVITE | 2xx-INV | -- |
+--------+----------+---------+
| PRACK | 2xx-PRA | UPDATE | 491
+--------+----------+---------+
| 1xx-rel| PRACK | -- |
+--------+----------+---------+
| 2xx-INV| ACK | UPDATE | 491
| | +---------+
| | | INVITE | 491
+--------+----------+---------+
--:not happen
After all, necessary rules are just three.
While offer-answer exchange is not completed,
UA MUST reject reINVITE and UPDATE with offer by 491.
UA should not send reINVITE without offer.
UA is recommended to reject reINVITE without offer by 491.
>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|
> |-------\ /-------|
> | \/ |
> | /\ |
> |<------/ \------>|
>
> Figure 5 Glare Case
Possible case I think.
| offer1 | offer2 |
+----------+----------+
| reINVITE | reINVITE |
| +----------+
| | UPDATE |
+----------+----------+
| UPDATE | UPDATE |
| +----------+
| | 1xx-rel |
| +----------+
| | 2xx-INV |
+----------+----------+
| PRACK | -- |
+----------+----------+
> When offer2 is in a PRACK request (within the current rules, only
> possible if offer1 is in an UPDATE request), the PRACK may be
> accepted with 200 or may be rejected with a 491 response. A 491
> response is valid to satisfy the offer/answer model but it may delay
> the completion of the reliable response transfer mechanism or, in
> worst case, may result in the failure to complete the SIP transaction
> because there is no clear retry rule when a PRACK request is rejected
> with a 491 response. 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.
In my understanding, the following figure summarizes
the above description.
A B
| |
| INV (offer0)|
|<------------------------------|
| 1xx-rel (answer0) |
|------------------------------>| --+
| | | Acknowledge
| offer1(UPD) offer2(PRA)| |
|============\ /===============| <-+
| \/ |
| /\ |
|<===========/ \==============>|
| |
I think that the offer1 is a protocol violation as PRACK case in 4.1.
Probably RFC3311(UPDATE) prohibits this operation.
> To avoid a glare condition involving an offer in a response, 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.
the following figure summarizes the above.
A B
| |
|re-INV (no offer) |
|------------------------------>| --+
| offer2 | |
|offer1(UPD) (1xx-rel/2xx)| |
|============\ /===============| <-+ The 1st reliable response
| \/ |
| /\ |
|<===========/ \==============>|
| |
In conclusion, I think as follows.
offer2 | Actions to take (UA A)
-------+---------------------------
INVITE | 491 response
UPDATE | with Retry-After
-------+---------------------------
PRACK | This case not happens
| under the current rules.
-------+---------------------------
1xx-rel| should not send UPDATE
2xx | until answer2 is sent
| (B reject UPDATE by 491)
-------+---------------------------
And these rules are almost the same as 4.1.
Regards,
Shinji
Paul Kyzivat <pkyzivat@xxxxxxxxx>
>I just posted a new version of the offeranswer draft.
>This version is intended to resolve all outstanding issues.
>
>Here is a summary of substantial changes made:
>
>- the open issues that were previously in section 6 were
> removed. The doc has been updated as needed to be consistent
> with conclusions about how to deal with those issues.
> Specifically:
>
> - Rejecting PRACK offer has simply been dropped.
> There has been no ongoing interest in no normative work
> to support doing that.
>
> - Commit/Rollback of Offer/Answer on Unsuccessful re-INVITE
> Transaction has been resolved by reference to
> draft-camarillo-sipcore-reinvite-01. New text referencing
> that has been added at multiple places in the document.
>
> - Loosening requirement for Offer in a Reliable Response:
> Again there has been no indication of intent to do anything
> in this space, so the topic has simply been dropped.
>
> - Requesting Hold while already on Hold:
> This was already addressed in the main body of the document.
> The issue was whether this was appropriate, since it rests on
> the interpretation of certain text in 3261 being non-normative.
> That assumption has been restated in the main body.
> I'm unaware of any argument to that in over two years.
>
>- The recommendations for addition of new o/a usage in sip
> (prior section 7) has also been dropped. While these may have
> been helpful during discussion of the draft, they aren't
> helpful after it is finalized.
>
>- I rearranged the order of authors since Takuya has been unavailable
> to work on it for some time. However I have retained him as an author
> because the preponderance of the text is still his.
>
>In addition there hare assorted miscellaneous minor cleanups.
>
> Thanks,
> Paul
>
>Internet-Draft@xxxxxxxx wrote:
>> New version (-11) has been submitted for draft-ietf-sipping-sip-offeranswer-11.
>> txt.
>> http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-11.txt
>> Sub state has been changed to AD Follow up from New Id Needed
>>
>> Diff from previous version:
>> http://tools.ietf.org/rfcdiff?url2=draft-ietf-sipping-sip-offeranswer-11
>>
>> 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
