Hi Paul,
Additional descriptions for Figure 4f in line.
---------------------------------------------------------------------
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 are variants, shown in Figures 4a and 4b, which are dependent
on an INVITE (Mx) that contains no offer. These are also included in
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 |------------------------------>|
| |
Figure 4a Avoidable message crossing cases
To avoid this glare condition as shown in Figure 4a, When an UA A
has already sent an UPDATE request with an offer, the UA should not
send a reINVITE even without an offer unless the UPDATE transaction
is completed. When an UA B has received an UPDATE request with an
offer, the UA should reject a reINVITE even without an offer by a 491
response unless the UPDATE transaction is completed.
A B
| |
|re-INV (no offer) |
Mx |------------------------------>| --+
|SDP-1 offer1(UPD) | |
M1 |==============================>| |
|SDP-2 answer1 (2xx-UPD)| |
M2 |<===========\ /===============| | first reliable
| \/ offer2| | response
|SDP-3 /\ (1xx-rel/2xx)| |
M3 |<===========/ \===============| <-+
|SDP-4 answer2 (PRACK/ACK)|
My |------------------------------>|
| |
Figure 4b Avoidable message crossing cases
To avoid this glare condition as shown in Figure 4b, When an UA A
has already sent a reINVITE without an offer, the UA should not
send an UPDATE request with an offer unless a PRACK transaction is
completed, or the UA sends an ACK request. When an UA B has received
a reINVITE without an offer, the UA should reject an UPDATE request
with an offer by a 491 response unless a PRACK transaction is
completed, or the UA receives an ACK request.
According to RFC3311/5.1, after sending a PRACK request, UA B can send
the UPDATE request(M2) with new offer, as shown in Figure 4c. To
avoid this glare condition, UA B should not send the UPDATE request
unless it has received a 2xx response to the PRACK request.
A B
| |
| re-INV (no offer)|
1st reliable +-- |<------------------------------|
response | M1| 1xx-rel (offer1) |
+-> |==============================>| --+
| answer1(PRA)| M3| Acknowledge
|<===========\ /===============| <-+
| \/ |
| /\ offer2(UPD)|
|<===========/ \===============| M2
| 491 (UPD) |
|------------------------------>|
|2xx-PRA |
|------------------------------>|
| |
Fig. 4c Avoidable message crossing cases
According to RFC3311/5.1, before the completion of initial INVITE
transaction, UA B cannot send the UPDATE request(M2) with new offer,
as shown in Figure 4d. But if this INVITE request is a reINVITE,
B can send it. To avoid this glare condition, UA B should not send
the UPDATE request unless it has received a PRACK request.
A B
| |
|re-INV (offer1) |
M1 |==============================>|
| answer1 (1xx-rel)|
|<===========\ /===============| M3
| \/ |
| /\ offer1(UPD)|
+-- |<===========/ \===============| M2
| |491 (UPD) |
Acknowledge | |------------------------------>|
| |PRACK |
+-> |------------------------------>|
| |
Fig. 4d Avoidable message crossing cases
According to RFC3311/5.1, before the completion of initial INVITE
transaction, UA B cannot send the UPDATE request(M2) with new offer,
as shown in Figure 4e. But if this INVITE request is a reINVITE,
B can send it. To avoid this glare condition, UA B should not send
the UPDATE request unless it has received an ACK request.
A B
| |
|re-INV (offer1) |
|==============================>|
| answer1 (2xx)|
|<===========\ /===============|
| \/ |
| /\ offer1(UPD)|
+-- |<===========/ \===============|
| |491 (UPD) |
Acknowledge | |------------------------------>|
| |ACK |
+-> |------------------------------>|
| |
Fig. 4e Avoidable message crossing cases
<add>
According to RFC3311/5.1, before the completion of initial INVITE
transaction, A cannot send the UPDATE request(M1) with new offer, as
shown in Figure 4f. But if this INVITE request is a reINVITE, A can
send it. To avoid this message crossing condition, UA A should not
send the UPDATE request unless it has sent a 2xx response to the
PRACK request and UA B should reject the UPDATE request by a 491
response unless a PRACK transaction is completed.
A B
| |
| re-INV (offer0)|
|<------------------------------|
| 1xx-rel (answer0) |
|------------------------------>| --+
|offer1(UPD) | |
M1 |==============================>| |
| answer1 (2xx-UPD)| | Acknowledge
|<===========\ /===============| M3|
| \/ | |
| /\ offer2(PRA)| M2|
|<===========/ \===============| <-+
| 491-PRA |
|------------------------------>|
| |
Fig. 4f Avoidable message crossing case
</add>
Table 4 summarize this section.
<modify>
| M1 | M3 | M2 | Action | Action |
|(offer1)|(answer1) |(offer2) | of A | of B |
+--------+----------+---------+--------+--------+
| UPDATE | 2xx-UPD | UPDATE | | |
| | +---------| (1) | - |
| | | INVITE | | |
| | +---------+--------+--------+
| | | 1xx-INV | (2) | (4) |
| | +---------+ | | 4a/b
| | | 2xx-INV | | |
| | +---------+ +--------+
| | | PRACK* | | (5) | 4f
+--------+----------+---------+--------+--------+
| PRACK | 2xx-PRA | UPDATE | | |
+--------+----------+---------+ | |
| 2xx-INV| ACK | UPDATE | (1) | - |
| | +---------+ | |
| | | INVITE | | |
+--------+----------+---------+ +--------+
| 1xx-rel| PRACK | UPDATE | | | 4c
+--------+----------+---------+ | |
| INVITE | 1xx-rel | UPDATE* | | (3) | 4d
| |----------+---------+ | |
| | 2xx-INV | UPDATE* | | | 4e
+--------+----------+---------+--------+--------+
(*:invalid sequences if M1 is an initial INVITE)
</modify>
Table 3. Offer / Answer Crossing Message Sequences
(1) This is indistinguishable from true glare. UA A should respond
to M2 with a 491 response.
(2) This can only occur in situations depicted in figures 4a and 4b.
It is easier for UA A to avoid these situations than to recover
from them. The situation in Figure 4a can be avoided by
refraining from sending a re-INVITE without offer when an
unanswered offer is outstanding. The situation in Figure 4b can
be avoided by refraining from sending any message containing an
offer while an INVITE without offer is outstanding.
(3) UA B should not send an UPDATE unless M3(answer1) has acknowledged
by a 2xx response to a PRACK request, a PRACK request or an ACK
request.
(4) UA B should reject the later request among an UPDATE and a reINVITE.
<add>
(5) UA B should reject M1 with a 491 response.
</add>
Summarizing, a UA that has an outstanding unanswered offer should:
o refrain from sending a re-INVITE without an offer;
o reject (491) an INVITE or UPDATE containing an offer.
and
o a UA that has sent a INVITE without an offer should not send
UPDATE, before the completion of offer/answer exchanges.
o a UA that has received a INVITE without an offer should not
send UPDATE, before the completion of offer/answer exchanges.
o When offer/answer exchanges using reliable provisional response,
UA should not send UPDATE with offer unless PRACK transaction
is completed.
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|
M1 |-------\ /-------| M2
| \/ |
| /\ |
|<------/ \------>|
Figure 5 Glare Case
When offer2 is in an UPDATE request or (re-)INVITE request, it must
be rejected with a 491 response.
When offer2 is in a PRACK request (within the current rules, only
possible if offer1 is in an UPDATE request),
According to RFC3311/5.1, before the completion of initial INVITE
transaction, UA A cannot send the UPDATE request(M1) with new offer,
as shown in Figure 6a. But if this INVITE request is a reINVITE, UA
A can send it. Naturally UA B reject the UPDATE by 491.
A B
| |
| re-INV (offer0)|
|<------------------------------|
| 1xx-rel (answer0) |
|------------------------------>| --+
| offer1(UPD) offer2(PRA)| M2| Acknowledge
M1 |============\ /===============| <-+
| \/ |
| /\ |
|<===========/ \==============>|
| 491 (UPD)|
|<------------------------------|
| |
Fig. 6a Avoidable glare cases
UA A has a dilemma: all
PRACKs are supposed to be accepted with 200 response, yet there is no
way to indicate the problem with a 200 response. At best it could
proceed on the assumption that its INVITE will be rejected with a
491. 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.
Glare can also occur when offer2 is in a 1xx or 2xx response.
This is a variant of 4b, as shown in Figure 6b.
A B
| |
|re-INV (no offer) |
|------------------------------>| --+ 1st reliable
|offer1(UPD) offer2| M2| response
M1 |============\ /===============| <-+
| \/ (1xx-rel/2xx)|
| /\ |
|<===========/ \==============>|
| 491 (UPD)|
|<------------------------------|
| |
Fig. 6b Avoidable glare cases
To avoid this situation, 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.
There is a variant of 4a, as shown in Figure 6c.
To avoid this glare condition, UA A should not send
the reINVITE request unless UPDATE transaction is completed.
A B
| |
|offer1(UPD) |
|==========\ |
|re-INV \ |
|------------\----------------->| --+
|(no offer) \ | |1st reliable
| \ offer2| | response
|<==============\===============| <-+
| \ (1xx-rel/2xx)|
| \ |
| \===========>|
| 491 (UPD)|
|<------------------------------|
| |
Fig. 6c Avoidable glare cases
Table 4 summarize this section.
| offer1 | offer2 | Action | Action |
| M1 | M2 | of A | of B |
+----------+----------+--------+--------+
| | reINVITE | | |
| reINVITE +----------+ | |
| | UPDATE | (1) | |
+----------+----------+ | |
| | UPDATE | | |
| +----------+--------+ (1) |
| | 1xx-rel | | |
| UPDATE +----------+ (2)/(3)| | 6b/c
| | 2xx-INV | | |
+ +----------+--------+ |
| | PRACK * | (3) | | 6a
+----------+----------+--------+--------+
(*:invalid sequence if INVITE request is an initial one)
Table 4. Offer / Answer Glare Message Sequences
(1) 491 response for the offer
(2) UA should not send reINVITE without an offer unless
UPDATE transaction is completed.
(3) When offer/answer exchanges using reliable provisional response,
UA should not send UPDATE with offer unless PRACK transaction
is completed.
---------------------------------------------------------------------
Regards,
Shinji
Paul Kyzivat <pkyzivat@xxxxxxxxx>
Mon, 08 Mar 2010 09:25:19 -0500
>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. 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.) 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
