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

Harald Alvestrand <harald@alvestrand.no> Mon, 07 November 2011 12:11 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2494721F8508 for <rtcweb@ietfa.amsl.com>; Mon, 7 Nov 2011 04:11:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.255
X-Spam-Level:
X-Spam-Status: No, score=-110.255 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6qqkfVG7xf9 for <rtcweb@ietfa.amsl.com>; Mon, 7 Nov 2011 04:11:41 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0027B21F84D8 for <rtcweb@ietf.org>; Mon, 7 Nov 2011 04:11:40 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 35A3139E119; Mon, 7 Nov 2011 13:11:40 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svaNHCSpTXCU; Mon, 7 Nov 2011 13:11:39 +0100 (CET)
Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 9F03239E112; Mon, 7 Nov 2011 13:11:39 +0100 (CET)
Message-ID: <4EB7CAFB.3070707@alvestrand.no>
Date: Mon, 07 Nov 2011 13:11:39 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>, Cullen Jennings <fluffy@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [rtcweb] ROAP minor bug: Retransmitted non-initial OFFER
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Nov 2011 12:11:46 -0000

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