Hi Paul,
I've tried.
---------------------------------------------------------------------
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
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
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) |
+-> |==============================>| --+
| | | Acknowledge
| answer1(PRA)| M3|
|<===========\ /===============| <-+
| \/ |
| /\ 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
Table 4 summarize this section.
| M1 | M3 | M2 | Action | Action |
|(offer1)|(answer1) |(offer2) | of A | of B |
+--------+----------+---------+--------+--------+
| UPDATE | 2xx-UPD | UPDATE | | |
| | +---------| (1) | |
| | | INVITE | | |
| | +---------+--------+--------+
| | | 1xx-INV | (2) | |
| | +---------+ | |
| | | 2xx-INV | | |
+--------+----------+---------+--------+ |
| PRACK | 2xx-PRA | UPDATE | | |
+--------+----------+---------+ | |
| 2xx-INV| ACK | UPDATE | (1) | |
| | +---------+ | |
| | | INVITE | | |
+--------+----------+---------+ +--------+
| 1xx-rel| PRACK | UPDATE | | |
+--------+----------+---------+ | |
| INVITE | 1xx-rel | UPDATE* | | (3) |
| |----------+---------+ | |
| | 2xx-INV | UPDATE* | | |
+--------+----------+---------+--------+--------+
(*:invalid sequences if M1 is an initial INVITE)
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.
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) |
|------------------------------>| --+
| | | Acknowledge
| offer1(UPD) offer2(PRA)| M2|
M1 |============\ /===============| <-+
| \/ |
| /\ |
|<===========/ \==============>|
| |
| 491 (UPD)|
|<------------------------------|
| |
Fig. 6a Avoidable message crossing 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) |
|------------------------------>| --+
| offer2 | | 1st reliable
|offer1(UPD) (1xx-rel/2xx)| M2| response
M1 |============\ /===============| <-+
| \/ |
| /\ |
|<===========/ \==============>|
| |
| 491 (UPD)|
|<------------------------------|
| |
Fig. 6b Avoidable message crossing 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) \ offer2 | |1st reliable
| \ (1xx-rel/2xx)| | response
|<================\=============| <-+
| \ |
| \ |
| \=========>|
| |
| 491 (UPD)|
|<------------------------------|
| |
Fig. 6c Avoidable message crossing 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)| |
| | 2xx-INV | | |
+ +----------+--------+ |
| | PRACK * | (3) | |
+----------+----------+--------+--------+
(*:invalid sequence if INVITE request is an initial one)
Table 4. 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
>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
_______________________________________________
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
