Re: [Sipping] New Version Notification for draft-ietf-sipping-sip-offeranswer-12
Hi Paul,
Additional descriptions in line.
Regards,
Shinji
>---------------------------------------------------------------------
>
>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
<add>
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.
</add>
> 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
<add>
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.
</add>
> 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.
<modify>
| M1 | M3 | M2 | Action | Action |
|(offer1)|(answer1) |(offer2) | of A | of B |
+--------+----------+---------+--------+--------+
| UPDATE | 2xx-UPD | UPDATE | | |
| | +---------| (1) | - |
| | | INVITE | | |
| | +---------+--------+--------+
| | | 1xx-INV | (2) | (4) |
| | +---------+ | |
| | | 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)
</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.
<add>
(4) UA B should reject the later request among an UPDATE and a reINVITE.
</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) |
> |------------------------------>| --+
> | | | 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
_______________________________________________
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
[IETF Announce]
[IETF Discussion]
[Linux SCSI]
[Linux USB Devel]
[Video for Linux]
[Linux Audio Users]
[Photo]
[Yosemite News]
[Yosemite Photos]
[Free Online Dating]
[Linux Kernel]
[Linux SCSI]
[XFree86]
[Big List of Linux Books]
