Re: [Sipping] I-D ACTION:draft-ietf-sipping-sip-offeranswer-08.txt

[OKUMURA Shinji <[e-mail]>]

Paul,

Paul Kyzivat <[e-mail]>
>Shinji,
>
>I've included comments inline. I don't know what we might do with them 
>at this late date. We will have to think about that.

I think these issue should be discribed as BCP in sec. 6.

>Is there a reason you didn't post these comments to sipping? It would be 
>better to have them there for discussion.

there isn't a serious reason. I would post this reply to sipping.

my comments inline.

Regards,
Shinji


>	Thanks,
>	Paul
>
>OKUMURA Shinji wrote:
>> Hi,
>> 
>> Sorry for my late comment.
>> 
>>> 4.1. Message Crossing Case Handling
>>>
>>> Table 3 summarizes the discussions above.
>>>
>>> offer2 | How to know it's not answer1 | Actions to take
>>> -------+------------------------------+--------------------------
>>> INVITE | Never be an answer           | 491 response
>>> UPDATE | Glare case for UA A          | with Retry-After
>>> -------+------------------------------+--------------------------
>>> PRACK  | This case never happens      | -
>>>        | under the current rules.     |
>>> -------+------------------------------+--------------------------
>>> 1xx-rel| Only one INVITE transaction  | Delay ACK/PRACK
>>> 2xx    | at a time. Then UA can know  | until answer1 is received
>>> -------+------------------------------+--------------------------
>>>
>>> NOTE: 1xx-rel/2xx case is extremely rare case and easily avoidable.
>>> See Figure 4.
>>>
>>> Table 3. UA's action to an offer (offer2) overtaking the previous
>>> answer (answer1)
>>>
>>>  A                               B
>>>  |                               |
>>>  |offer1(e.g. UPD)               |
>>>  |==============================>|
>>>  |re-INV (no offer)              |
>>>  |------------------------------>| --+
>>>  |              answer1 (2xx-UPD)|   |
>>>  |<===========\  /===============|   | The first reliable response
>>>  |             \/          offer2|   |
>>>  |             /\   (1xx-rel/2xx)|   |
>>>  |<===========/  \===============| <-+
>>>  | answer2 (PRACK/ACK)           |
>>>  |------------------------------>| 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, so that I think
>> UA A should not send re-INVITE, until answer1 is received. It is
>> simpler.
>
>It is simpler. But it isn't required. So all this is doing is clarifying 
>that it in fact isn't ambiguous, and what it means.

This situation resembles closely the 3rd case(1xx-rel/2xx) in 4.2.
the result in 4.2 is following

    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.

if the result in 4.1 is Wait-until-answer1, I think the result in 4.2
should be Wait-until-491.

                A                               B
                |                               |
                |re-INV (no offer)              |
                |------------------------------>| --+
                |                        offer2 |   |
                |offer1(UPD)       (1xx-rel/2xx)|   |
                |============\  /===============| <-+ 1st 1xx-rel
                |             \/                |
                |             /\                |
                |<===========/  \==============>|
                |                               |
                |                       491(UPD)|
                |<------------------------------|
                |                               |
                | answer2 (PRACK/ACK)           |
 Wait until 491 |------------------------------>|
                |                               |

We have discussed what UA-A should do. There are two choices for A.
a) waiting for the response for UPDATE request, even if the response
   is 491.
b) not sending UPDATE request, unless offer/answer is done that
   is caused by re-INVITE without offer.

I think b) is BCP.

>>> 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
>>>
>>> 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), 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 discussions above.
>> 
>>     A                               B
>>     |                               |
>>     |                   INV (offer0)|
>>     |<------------------------------|
>>     | 1xx-rel (answer0)             |
>>     |------------------------------>| --+
>>     |                               |   | Acknowledge
>>     | offer1(UPD)        offer2(PRA)| <-+
>>     |============\  /===============|
>>     |             \/                |
>>     |             /\                |
>>     |<===========/  \==============>|
>>     |                               |
>> 
>> I think that the offer1 is a protocol violation,
>> as same as PRACK case in 4.1.
>
>The PRACK cases in 4.1 aren't protocol violations, although they may be 
>unwise usages that *should* have been protocol violations.

RFC3311/5.1 Sending an UPDATE
   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.

According to the description above, this UPDATE can't contain an offer.

>
>So this case needs to be judged on its own. This can be viewed as a 
>violation by A, in that it should have awaited the PRACK before sending 
>the UPDATE. But AFAIK there is nothing that formally declares this a 
>protocol error. But if it was a protocol violation, then it was A that 
>made it. B doesn't know that anything is wrong.
>
>>> 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.
>> 
>> In my understanding, the following figure summarizes
>> the discussions above.
>> 
>>     A                               B
>>     |                               |
>>     |re-INV (no offer)              |
>>     |------------------------------>| --+
>>     |                        offer2 |   |
>>     |offer1(UPD)       (1xx-rel/2xx)|   |
>>     |============\  /===============| <-+ The 1st reliable response
>>     |             \/                |
>>     |             /\                |
>>     |<===========/  \==============>|
>>     |                               |
>> 
>> Is it correct ?
>
>Yes, that is the problem case described in that paragraph. Are you 
>suggesting that this be added to the document?

Yes. However, The above-mentioned "Wait-until-491" is better
than this figure. IMO.

>
>> In conclusion, I think as follows.
>> 
>>   offer2 |  Actions to take (UA A)
>>   -------+---------------------------
>>   INVITE |  491 response
>>   UPDATE |  with Retry-After
>>   -------+---------------------------
>>   PRACK  |  This case never happens
>>          |  under the current rules.
>>   -------+---------------------------
>>   1xx-rel|  should not send UPDATE
>>   2xx    |  until answer2 is sent
>>   -------+---------------------------
>
>I was considering odd cases, and I see one more case that *might* be 
>legal (though stupid) for PRACK containing offer2:
>
>    A                               B
>    |                               |
>    |re-INV (offer0)                |
>    |<------------------------------|
>    |183-rel (answer0)              |
>    |------------------------------>|
>    |PRACK (no-sdp)                 |
>    |<------------------------------|
>    |UPDATE (offer1)                |
>    |------------------------------>|
>    |              2xx-UPD (answer1)|
>    |               /===============|
>    |180-rel       / (no-sdp)       |
>    |------------ / --------------->|
>    |PRACK       / (offer2)         |
>    |<--------- / ------------------|
>    |          /                    |
>    |<========/                     |
>    | 200-PRA (answer2)             |
>    |------------------------------>|
>    |                               |

RFC3262/5 The Offer/Answer Model and PRACK
   If the UAC receives
   a reliable provisional response with an answer, it MAY generate an
   additional offer in the PRACK. 

In my interpretation, 2nd PRACK can't contain an offer.

>
>This can of course be avoided if A delays sending th 180 until the 
>response to the update is received. But if it isn't so wise, and does as 
>above, then it must recognize that the sdp in the PRACK is not the 
>answer it is awaiting. It then must await the response to the UPDATE 
>before acting on the PRACK.
>
>But this means that your summary table is not quite right regarding PRACK.
>
>> Regards,
>> Shinji
>> 
>> [e-mail]
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the Session Initiation Proposal Investigation
>>> Working Group of the IETF.
>>>
>>> Title    : SIP (Session Initiation Protocol) Usage of the Offer/Answer Model
>>> Author(s): T. Sawada, P. Kyzivat
>>> Filename : draft-ietf-sipping-sip-offeranswer-08.txt
>>> Pages    : 26
>>> Date     : 2008-4-25
>>>
>>> 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.
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/
>>> draft-ietf-sipping-sip-offeranswer-08.txt
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> Below is the data which will enable a MIME compliant mail reader
>>> implementation to automatically retrieve the ASCII version of the
>>> Internet-Draft.
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP