[salud] How to construct a finite state machine to select an alerting signal

worley@ariadne.com (Dale R. Worley) Tue, 28 June 2016 19:03 UTC

Return-Path: <worley@alum.mit.edu>
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0373C12D50D for <salud@ietfa.amsl.com>; Tue, 28 Jun 2016 12:03:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6WHGEdPq3JdE for <salud@ietfa.amsl.com>; Tue, 28 Jun 2016 12:03:52 -0700 (PDT)
Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6437712D5D6 for <salud@ietf.org>; Tue, 28 Jun 2016 12:03:52 -0700 (PDT)
Received: from resomta-ch2-09v.sys.comcast.net ([]) by resqmta-ch2-02v.sys.comcast.net with SMTP id HyEvb3pwOQRyhHyIZbIgzV; Tue, 28 Jun 2016 19:03:51 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1467140631; bh=V3UNlIgTEH8bUB0RikTLXy1qg2KmuaJOGeyApnjmRfc=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=VvaojpQYU/3alTI6bzqDbaqToorjYluNBDKNMd9RuyXELdmwvhx0YcSNSMh7w32AM H5Jh+FbiBIanvCZ2f+yuM/mKTzCBNw18B2LRUTOtl4ygl4qZrvLadluN3I4q/Jeyzf OsBNSIsZswjl5xfD0Lu5aJKIgGImlBSc9op/6Ufvx4kx01nQ2g2506jYXOmaqzHpPz dz7/rcd87yjTNdyv5zNNBbDMPkTJ9orzx8XaBbKNNqyWiqh+0wGo63nnijjegpB1Y6 krWOj648GhFfb2Do5zm95DATWxKCRgn+kf9fwEsAvo3cfYpGN+bWTYbEUcwn+cZU2M oHoflemCE4DYQ==
Received: from hobgoblin.ariadne.com ([]) by resomta-ch2-09v.sys.comcast.net with comcast id CK3q1t00Z1nMCLR01K3rLg; Tue, 28 Jun 2016 19:03:51 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com []) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5SJ3oMF020866 for <salud@ietf.org>; Tue, 28 Jun 2016 15:03:50 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5SJ3omM020863; Tue, 28 Jun 2016 15:03:50 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com (Dale R. Worley)
To: salud@ietf.org
Sender: worley@ariadne.com (Dale R. Worley)
Date: Tue, 28 Jun 2016 15:03:50 -0400
Message-ID: <87r3bhdtk9.fsf@hobgoblin.ariadne.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/salud/16IDLvSf3nWXsx1rRrW2mCbOcao>
Subject: [salud] How to construct a finite state machine to select an alerting signal
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list <salud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/salud>, <mailto:salud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/salud/>
List-Post: <mailto:salud@ietf.org>
List-Help: <mailto:salud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/salud>, <mailto:salud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jun 2016 19:03:54 -0000

I've worked out how to construct a finite state machine to process the
'alert' URNs in an Alert-Info header to select one of the alerting
signals of a UA.  Once you fix the set of signals and their meanings
(the URNs that the signal indicates), there's an algorithm that
constructs the FSM, and it ensures that FSM satisfies the rules in RFC

I've written a draft to describe the process in detail.  The draft also
points to an implementation of the algorithm in Python, so people can
try out this method and see how it works for them.

I'd like to hear any feedback you have.


A new version of I-D, draft-worley-alert-info-fsm-02.txt
has been successfully submitted by Dale R. Worley and posted to the
IETF repository.

Name:		draft-worley-alert-info-fsm
Revision:	02
Title:		A Simpler Method for Processing Alert-Info URNs
Document date:	2016-06-05
Group:		Individual Submission
Pages:		36
URL:            https://www.ietf.org/internet-drafts/draft-worley-alert-info-fsm-02.txt
Status:         https://datatracker.ietf.org/doc/draft-worley-alert-info-fsm/
Htmlized:       https://tools.ietf.org/html/draft-worley-alert-info-fsm-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-worley-alert-info-fsm-02

   The "alert" namespace of uniform resource names (URNs) can be used in
   the Alert-Info header field of Session Initiation Protocol (SIP)
   requests and responses to inform a VoIP telephone (user agent) of the
   characteristics of the call that the user agent has originated or
   terminated.  Based on the URNs in the Alert-Info header field, the
   user agent must select an the best available signal to present to its
   user to indicate the characteristics of the call.  This document
   describes a method by which a user agent's designer can, based on the
   user agent's signals and their meanings, constructing a finite state
   machine (FSM) to process the URNs to select a signal in a way that
   obeys the restrictions given in the definition of the "alert" URN
   namespace.  In many situations, the resulting FSM is simpler and
   faster than the previously described selection algorithm.