Subject: [rtcweb] ROAP minor bug: Retransmitted non-initial OFFER

From: Harald Alvestrand <[email-masked]>
Date: Mon, 07 Nov 2011 13:11:39 +0100

Hello,

I think this is a nit, but worth completing.
during review of ROAP, I spotted this one:

5.3.1.2.  Answerer Behavior

    A answerer can receive an OFFER in three cases:

    o  A new session (this is detected by seeing a new offererSessionId
       value);
    o  A retransmit of a new OFFER (known offererSessionId, empty
       answererSessionId); or
    o  A request to change media parameters (known offererSessionId,
       known answererSessionId, new seq value).

    The first two situations are described in this section.  The third
    case is described in Section 5.4.  Any other condition represents an
    alien packet and SHOULD be rejected with Error:NOMATCH

I think this is incomplete; if a non-initial OFFER is retransmitted, it 
will have a known offererSessionId, a known answererSessionId, and an 
old seq value. I think the correct response to such an OFFER is the same 
response as to the 2nd bullet: to retransmit the previously sent answer 
(which will either be ANSWER or ERROR), and not change any internal state.

This seems to be the meaning of the last paragraph of the section:

    If an OFFER is received that has already been received and responded
    to and the media session still exists, then the answerer MUST respond
    with the same message as before.  If the session has been terminated
    in the meantime, then an Error:NOMATCH message SHOULD be sent.

but it was a bit hard to parse this - this "if" isn't the inverse of "If 
no media session exists with the given "offererSessionId" value", so 
it's not 100% clear if it's possible to arrive at the end with both 
paragraphs being false (media session exists, but this isn't an OFFER 
that has been responded to).

A somewhat more rigorous structure might be a Good Thing.

                   Harald