From extest-admin@lists.bell-labs.com  Sun Jul  1 05:05:45 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08760
	for <spirits-archive@odin.ietf.org>; Sun, 1 Jul 2001 05:05:45 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 97B6E4440B
	for <spirits-archive@lists.ietf.org>; Sun,  1 Jul 2001 05:05:16 -0400 (EDT)
Subject: lists.bell-labs.com mailing list memberships reminder
From: mailman-owner@lists.bell-labs.com
To: spirits-archive@ietf.org
X-No-Archive: yes
X-Ack: no
Sender: extest-admin@lists.bell-labs.com
Errors-To: extest-admin@lists.bell-labs.com
X-BeenThere: extest@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
Message-Id: <20010701090516.97B6E4440B@lists.bell-labs.com>
Date: Sun,  1 Jul 2001 05:05:16 -0400 (EDT)

This is a reminder, sent out once a month, about your
lists.bell-labs.com mailing list memberships.  It includes your
subscription info and how to use it to change it or unsubscribe from a
list.

You can visit the URLs to change your membership status or
configuration, including unsubscribing, setting digest-style delivery
or disabling delivery altogether (e.g., for a vacation), and so on.

In addition to the URL interfaces, you can also use email to make such
changes.  For more info, send a message to the '-request' address of
the list (for example, spirits-request@lists.bell-labs.com) containing
just the word 'help' in the message body, and an email message will be
sent to you with instructions.

If you have questions, problems, comments, etc, send them to
mailman-owner@lists.bell-labs.com.  Thanks!

Passwords for spirits-archive@lists.ietf.org:

List                                     Password // URL
----                                     --------  
spirits@lists.bell-labs.com              QMKP      
http://lists.bell-labs.com/mailman/options/spirits/spirits-archive%40lists.ietf.org


From spirits-admin@lists.bell-labs.com  Fri Jul  6 13:26:18 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13364
	for <spirits-archive@odin.ietf.org>; Fri, 6 Jul 2001 13:26:18 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3046944337; Fri,  6 Jul 2001 13:27:02 -0400 (EDT)
Delivered-To: spirits@lists.bell-labs.com
Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163])
	by lists.bell-labs.com (Postfix) with ESMTP id 2633544336
	for <spirits@lists.bell-labs.com>; Fri,  6 Jul 2001 13:26:33 -0400 (EDT)
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id TAA03475
	for <spirits@lists.bell-labs.com>; Fri, 6 Jul 2001 19:26:32 +0200 (MET DST)
Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id TAA06603
	for <spirits@lists.bell-labs.com>; Fri, 6 Jul 2001 19:26:30 +0200 (MET DST)
Received: by MCHH273E with Internet Mail Service (5.5.2653.19)
	id <JWJ25NXX>; Fri, 6 Jul 2001 19:26:31 +0200
Message-ID: <F17E6EA41FA1D41188EF006008135F5843E1E5@LNN202E>
From: Samandi Sami <Sami.Samandi@SRIT.siemens.fr>
To: "'spirits@lists.bell-labs.com'" <spirits@lists.bell-labs.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SPIRITS] Is this WG group still alive
Sender: spirits-admin@lists.bell-labs.com
Errors-To: spirits-admin@lists.bell-labs.com
X-BeenThere: spirits@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
Reply-To: spirits@lists.bell-labs.com
List-Help: <mailto:spirits-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:spirits@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/spirits>, <mailto:spirits-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SPIRITS Working Group <spirits.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/spirits>, <mailto:spirits-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/spirits/
Date: Fri, 6 Jul 2001 19:26:31 +0200
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA13364

Dear all,
  
   I am looking for information related to the interworking of an SCP with a SIP application server to trigger SIP services for PSTN users. When I look at the SPIRITS architecture RFC it seems to be the description of the architecture I am looking for, but when I look to the protocol requirements draft I am a little bit disapointed as it is clearly said that SIP is the transport protocol for SPRITS but no details about the usage of SIP are shown (something of the same level than the PINT RFC).

   Is there further work to be done by this group concerning the details of the SIP usage for SPRITS. If no, could someone please tell me if there are any other working group continuing this work or treating the same kind of problem ?

Thank you in advance 
Sami

> Sami SAMANDI
	SIEMENS Réseaux Informatiques et Télécommunications
> 22300 LANNION
> 
> Phone :	+ 33 2 96 48 73 99
> Fax :	+ 33 2 96 48 74 73
> 
> Email :	sami.samandi@srit.siemens.fr
> 
> 
> 
> 

_______________________________________________
SPIRITS mailing list
SPIRITS@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/spirits


From spirits-admin@lists.bell-labs.com  Fri Jul  6 13:58:17 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14504
	for <spirits-archive@odin.ietf.org>; Fri, 6 Jul 2001 13:58:17 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id CBE0A44339; Fri,  6 Jul 2001 13:59:01 -0400 (EDT)
Delivered-To: spirits@share.research.bell-labs.com
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by lists.bell-labs.com (Postfix) with SMTP id 2AD9244339
	for <spirits@share.research.bell-labs.com>; Fri,  6 Jul 2001 13:58:07 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Fri Jul  6 13:57:20 EDT 2001
Received: by lists.bell-labs.com (Postfix)
	id EC1BC4438C; Fri,  6 Jul 2001 13:44:16 -0400 (EDT)
Delivered-To: spirits@lists.bell-labs.com
Received: from ih2mail.ih.lucent.com (ih2mail.ih.lucent.com [135.1.241.39])
	by lists.bell-labs.com (Postfix) with ESMTP id 29D5F4438B
	for <spirits@lists.bell-labs.com>; Fri,  6 Jul 2001 13:44:15 -0400 (EDT)
Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id MAA22446; Fri, 6 Jul 2001 12:44:14 -0500 (CDT)
Message-ID: <3B45F997.14EE00DA@lucent.com>
From: Alec Brusilovsky <abrusilovsky@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en,ru,uk
MIME-Version: 1.0
To: spirits@lists.bell-labs.com
Subject: Re: [SPIRITS] Is this WG group still alive
References: <F17E6EA41FA1D41188EF006008135F5843E1E5@LNN202E>
Content-Type: multipart/mixed;
 boundary="------------948FF52D61B56ECD3D66E969"
Sender: spirits-admin@lists.bell-labs.com
Errors-To: spirits-admin@lists.bell-labs.com
X-BeenThere: spirits@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
Reply-To: spirits@lists.bell-labs.com
List-Help: <mailto:spirits-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:spirits@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/spirits>, <mailto:spirits-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SPIRITS Working Group <spirits.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/spirits>, <mailto:spirits-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/spirits/
Date: Fri, 06 Jul 2001 12:47:03 -0500

This is a multi-part message in MIME format.
--------------948FF52D61B56ECD3D66E969
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Dear Sami,

Please look for two new I-D's that are about to be published. (Beginning of the next week is our target date.)
Hopefully, they will be able to address your protocol questions.

Regarding your comment: we are always looking for good technical proposals. If you happen to have one, please submit it in the I-D form in time for the IETF51. The deadline for initial I-D submissions is July 13th.

Kind regards,
Alec Brusilovsky

Samandi Sami wrote:

> Dear all,
>
>    I am looking for information related to the interworking of an SCP with a SIP application server to trigger SIP services for PSTN users. When I look at the SPIRITS architecture RFC it seems to be the description of the architecture I am looking for, but when I look to the protocol requirements draft I am a little bit disapointed as it is clearly said that SIP is the transport protocol for SPRITS but no details about the usage of SIP are shown (something of the same level than the PINT RFC).
>
>    Is there further work to be done by this group concerning the details of the SIP usage for SPRITS. If no, could someone please tell me if there are any other working group continuing this work or treating the same kind of problem ?
>
> Thank you in advance
> Sami
>
> > Sami SAMANDI
>         SIEMENS Réseaux Informatiques et Télécommunications
> > 22300 LANNION
> >
> > Phone :       + 33 2 96 48 73 99
> > Fax : + 33 2 96 48 74 73
> >
> > Email :       sami.samandi@srit.siemens.fr
> >
> >
> >
> >
>
> _______________________________________________
> SPIRITS mailing list
> SPIRITS@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/spirits

--------------948FF52D61B56ECD3D66E969
Content-Type: text/x-vcard; charset=us-ascii;
 name="abrusilovsky.vcf"
Content-Description: Card for Alec Brusilovsky
Content-Disposition: attachment;
 filename="abrusilovsky.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Brusilovsky;Alec 
tel;fax:+1 630 713 5840 
tel;work:+1 630 713 8401
x-mozilla-html:FALSE
org:e-Services Group;Next Generation Evolution and Architecture
version:2.1
email;internet:abrusilovsky@lucent.com
title:MTS 
adr;quoted-printable:;;IHP 1A-423=0D=0A263 Shuman Blvd,P O Box 3050;Naperville;IL;60566-7050;U S
x-mozilla-cpt:;5312
fn:Alec  Brusilovsky
end:vcard

--------------948FF52D61B56ECD3D66E969--


_______________________________________________
SPIRITS mailing list
SPIRITS@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/spirits


From spirits-admin@lists.bell-labs.com  Fri Jul  6 14:48:18 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15854
	for <spirits-archive@odin.ietf.org>; Fri, 6 Jul 2001 14:48:18 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 549FE44337; Fri,  6 Jul 2001 14:49:02 -0400 (EDT)
Delivered-To: spirits@share.research.bell-labs.com
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by lists.bell-labs.com (Postfix) with SMTP id 3EA6244336
	for <spirits@share.research.bell-labs.com>; Fri,  6 Jul 2001 14:48:07 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Fri Jul  6 14:46:17 EDT 2001
Received: by lists.bell-labs.com (Postfix)
	id CB5354438C; Fri,  6 Jul 2001 14:33:13 -0400 (EDT)
Delivered-To: spirits@lists.bell-labs.com
Received: from hotair.hobl.lucent.com (hotair.hobl.lucent.com [199.118.135.2])
	by lists.bell-labs.com (Postfix) with SMTP id 84D6B4438B
	for <spirits@lists.bell-labs.com>; Fri,  6 Jul 2001 14:33:13 -0400 (EDT)
Received: from bell-labs.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id OAA16637; Fri, 6 Jul 2001 14:33:13 -0400
Message-ID: <3B460466.846D8109@bell-labs.com>
From: Igor Faynberg <faynberg@bell-labs.com>
Reply-To: faynberg@lucent.com
Organization: Lucent Technologies
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5  (Windows NT 5.0; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: spirits@lists.bell-labs.com
Subject: Re: [SPIRITS] Is this WG group still alive
References: <F17E6EA41FA1D41188EF006008135F5843E1E5@LNN202E>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: spirits-admin@lists.bell-labs.com
Errors-To: spirits-admin@lists.bell-labs.com
X-BeenThere: spirits@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:spirits-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:spirits@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/spirits>, <mailto:spirits-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SPIRITS Working Group <spirits.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/spirits>, <mailto:spirits-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/spirits/
Date: Fri, 06 Jul 2001 14:33:10 -0400
Content-Transfer-Encoding: 7bit



Samandi Sami wrote:
> 
> Dear all,
> 
>    I am looking for information related to the interworking of an SCP with a SIP application server to trigger SIP services for PSTN users. >When I look at the SPIRITS architecture RFC it seems to be the >description of the architecture I am looking for, but when I look to >the protocol requirements draft I am a little bit disapointed as it is >clearly said that SIP is the transport protocol for SPRITS but no >details about the usage of SIP are shown (something of the same level >than the PINT RFC).

The PINT Protocol RFC was doing just that--defining the protocol (PINT
never had a requirements document).  The present SPIRITS requirements
RFC, on the other hand, explains what is needed to be done and then
suggests a very specific methodology for doing that. For example, it
provides the requirements for the event definitions for S-BE/NOTIFY,
mapping of the IN events into SPIRITS protocol events, etc.

The protocol work is what is starting right now. There are several I-Ds
in the pipeline for that--they will be published soon. 

Igor

_______________________________________________
SPIRITS mailing list
SPIRITS@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/spirits


From spirits-admin@lists.bell-labs.com  Tue Jul 10 12:23:14 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06948
	for <spirits-archive@odin.ietf.org>; Tue, 10 Jul 2001 12:23:13 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5EEF24434B; Tue, 10 Jul 2001 12:24:02 -0400 (EDT)
Delivered-To: spirits@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by lists.bell-labs.com (Postfix) with SMTP id E9D764433A
	for <spirits@share.research.bell-labs.com>; Tue, 10 Jul 2001 12:23:06 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Jul 10 12:18:27 EDT 2001
Received: by lists.bell-labs.com (Postfix)
	id 040994438F; Tue, 10 Jul 2001 12:08:23 -0400 (EDT)
Delivered-To: spirits@lists.bell-labs.com
Received: from ih2mail.ih.lucent.com (ih2mail.ih.lucent.com [135.1.241.39])
	by lists.bell-labs.com (Postfix) with ESMTP id AAE414438E
	for <spirits@lists.bell-labs.com>; Tue, 10 Jul 2001 12:08:22 -0400 (EDT)
Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id LAA23427; Tue, 10 Jul 2001 11:08:22 -0500 (CDT)
Message-ID: <3B4B2921.17496BD7@lucent.com>
From: Alec Brusilovsky <abrusilovsky@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en,ru,uk
MIME-Version: 1.0
To: SPIRITS list <spirits@lists.bell-labs.com>
Content-Type: multipart/mixed;
 boundary="------------25174B6F9E023A1FAA1B51FB"
Subject: [SPIRITS] Status of the WG
Sender: spirits-admin@lists.bell-labs.com
Errors-To: spirits-admin@lists.bell-labs.com
X-BeenThere: spirits@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
Reply-To: spirits@lists.bell-labs.com
List-Help: <mailto:spirits-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:spirits@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/spirits>, <mailto:spirits-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SPIRITS Working Group <spirits.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/spirits>, <mailto:spirits-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/spirits/
Date: Tue, 10 Jul 2001 11:11:13 -0500

This is a multi-part message in MIME format.
--------------25174B6F9E023A1FAA1B51FB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Group,

Agenda@ietf.org has scheduled our meeting tentatively for
Friday, August 10. I do understand that the date is not
perfect at all, and am working with agenda@ietf.org on
changing.
If you have particular topic for discussion, please forward
it to Steve or myself.

Our milestones:
- Architecture Document - submitted to the IESG,
- Protocol Requirements - submitted to the IESG,

Protocol Proposals:
I expect two new SPIRITS Protocol proposal I-Ds to be
available at the end of this week. Both of them deal with
the IN part of the Protocol (parameters selection), as well
as encoding of IN parameters.

Next step:
"SIP part" of the SPIRITS Protocol, described in detail,
according to the Requirements Document. After that -
combining with the IN parameters and encoding part to
produce SPIRITS Protocol I-D.

Steve and I will keep you posted regarding our scheduling
query. See you in London.

Regards,
Alec

--------------25174B6F9E023A1FAA1B51FB
Content-Type: text/x-vcard; charset=us-ascii;
 name="abrusilovsky.vcf"
Content-Description: Card for Alec Brusilovsky
Content-Disposition: attachment;
 filename="abrusilovsky.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Brusilovsky;Alec 
tel;fax:+1 630 713 5840 
tel;work:+1 630 713 8401
x-mozilla-html:FALSE
org:e-Services Group;Next Generation Evolution and Architecture
version:2.1
email;internet:abrusilovsky@lucent.com
title:MTS 
adr;quoted-printable:;;IHP 1A-423=0D=0A263 Shuman Blvd,P O Box 3050;Naperville;IL;60566-7050;U S
x-mozilla-cpt:;5312
fn:Alec  Brusilovsky
end:vcard

--------------25174B6F9E023A1FAA1B51FB--


_______________________________________________
SPIRITS mailing list
SPIRITS@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/spirits


From spirits-admin@lists.bell-labs.com  Tue Jul 10 14:32:14 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13654
	for <spirits-archive@odin.ietf.org>; Tue, 10 Jul 2001 14:32:13 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id F37E044351; Tue, 10 Jul 2001 14:33:01 -0400 (EDT)
Delivered-To: spirits@share.research.bell-labs.com
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by lists.bell-labs.com (Postfix) with SMTP id 827F744344
	for <spirits@share.research.bell-labs.com>; Tue, 10 Jul 2001 14:32:05 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Tue Jul 10 14:30:45 EDT 2001
Received: by lists.bell-labs.com (Postfix)
	id 2E2C24438F; Tue, 10 Jul 2001 14:17:40 -0400 (EDT)
Delivered-To: spirits@lists.bell-labs.com
Received: from ih2mail.ih.lucent.com (ih2mail.ih.lucent.com [135.1.241.39])
	by lists.bell-labs.com (Postfix) with ESMTP id D762D4438E
	for <spirits@lists.bell-labs.com>; Tue, 10 Jul 2001 14:17:39 -0400 (EDT)
Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id NAA02792; Tue, 10 Jul 2001 13:17:15 -0500 (CDT)
Message-ID: <3B4B4757.A534AFC0@lucent.com>
From: Alec Brusilovsky <abrusilovsky@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en,ru,uk
MIME-Version: 1.0
To: SPIRITS list <spirits@lists.bell-labs.com>,
        Jim Buller <jBuller@unispheresolutions.com>,
        "agenda@ietf.org" <agenda@ietf.org>,
        Dinara Suleymanova <dinaras@ietf.org>
References: <153BDA136259D311859900A0C99B5263FA0CB3@boca-isbu-nt04.boca.unispheresolutions.com>
Content-Type: multipart/mixed;
 boundary="------------8AB10310CF4C302B297875EF"
Subject: [SPIRITS] Meeting on Tuesday 7th August 13.00-14.00 Was: Status of the WG
Sender: spirits-admin@lists.bell-labs.com
Errors-To: spirits-admin@lists.bell-labs.com
X-BeenThere: spirits@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
Reply-To: spirits@lists.bell-labs.com
List-Help: <mailto:spirits-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:spirits@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/spirits>, <mailto:spirits-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SPIRITS Working Group <spirits.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/spirits>, <mailto:spirits-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/spirits/
Date: Tue, 10 Jul 2001 13:20:07 -0500

This is a multi-part message in MIME format.
--------------8AB10310CF4C302B297875EF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Group,

Our meeting (still tentatively) is on Tuesday 7th August
13.00-14.00.

I would like to thank agenda@ietf.org for honoring our request
for change, as well as their quick reaction.
Jim, thanks for pointing the change out.

Regards,
Alec

"Buller, Jeremy" wrote:

> Hi Alec,
>
> > Agenda@ietf.org has scheduled our meeting tentatively for
> > Friday, August 10. I do understand that the date is not
> > perfect at all, and am working with agenda@ietf.org on
> > changing.
> FYI:
>
>   http://www.ietf.org/meetings/agenda_51.txt
>
> already has SPIRITS down for Tuesday 7th August 13.00-14.00
>
> Kind regards,
>
> Jim Buller
>
> ----------------------------------
>  Unisphere Networks,
>  7800 Congress Avenue, Suite 100,
>  Boca Raton, FL 33487. USA
>
>  (+)1 561 981 7011
> ----------------------------------

--------------8AB10310CF4C302B297875EF
Content-Type: text/x-vcard; charset=us-ascii;
 name="abrusilovsky.vcf"
Content-Description: Card for Alec Brusilovsky
Content-Disposition: attachment;
 filename="abrusilovsky.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Brusilovsky;Alec 
tel;fax:+1 630 713 5840 
tel;work:+1 630 713 8401
x-mozilla-html:FALSE
org:e-Services Group;Next Generation Evolution and Architecture
version:2.1
email;internet:abrusilovsky@lucent.com
title:MTS 
adr;quoted-printable:;;IHP 1A-423=0D=0A263 Shuman Blvd,P O Box 3050;Naperville;IL;60566-7050;U S
x-mozilla-cpt:;5312
fn:Alec  Brusilovsky
end:vcard

--------------8AB10310CF4C302B297875EF--


_______________________________________________
SPIRITS mailing list
SPIRITS@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/spirits


From spirits-admin@lists.bell-labs.com  Thu Jul 19 10:37:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12894
	for <spirits-archive@odin.ietf.org>; Thu, 19 Jul 2001 10:37:50 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 770104434F; Thu, 19 Jul 2001 10:36:06 -0400 (EDT)
Delivered-To: spirits@lists.bell-labs.com
Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40])
	by lists.bell-labs.com (Postfix) with ESMTP id F1A9144342
	for <spirits@lists.bell-labs.com>; Thu, 19 Jul 2001 10:35:36 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f6JEZWg09303
	for <spirits@lists.bell-labs.com>; Thu, 19 Jul 2001 15:35:33 +0100 (BST)
Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com;
          Thu, 19 Jul 2001 15:34:58 +0100
Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PF5J28X0>; Thu, 19 Jul 2001 15:33:29 +0100
Message-ID: <A3C2399B2FACD411A54200508BE39C7401EDF4E1@zwcwd00r.europe.nortel.com>
From: "Michael O'Doherty" <mdoherty@nortelnetworks.com>
To: "'spirits@lists.bell-labs.com'" <spirits@lists.bell-labs.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1105F.C6AE8C30"
Subject: [SPIRITS] Half-Pint
Sender: spirits-admin@lists.bell-labs.com
Errors-To: spirits-admin@lists.bell-labs.com
X-BeenThere: spirits@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
Reply-To: spirits@lists.bell-labs.com
List-Help: <mailto:spirits-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:spirits@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/spirits>, <mailto:spirits-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SPIRITS Working Group <spirits.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/spirits>, <mailto:spirits-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/spirits/
Date: Thu, 19 Jul 2001 15:33:28 +0100

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C1105F.C6AE8C30
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1105F.C6AE8C30"


------_=_NextPart_001_01C1105F.C6AE8C30
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,

I have submitted a new draft entitled 'Half-Pint' which as the name (kind of
...) suggests is a lightweight, restricted take on the functionality
provided by the PINT protocol.

The idea is to try to hit the high runner things that web developers wanting
to integrate web applications with the PSTN want to do right now, and make
it available in a way that web developers are familiar with and can work
with right away. 

The natural place to discuss this would have been the PINT group, but
unfortunately it is not around anymore, so I'm sending this notice onto to
some other groups that may be interested in this type of thing to get
feedback and comments.

Cheers,

Mick O'Doherty.

P.S. I've attached the draft to this email as the version in the archives
has picked up a few formatting errors somehow and is not quite fixed up yet.


 <<draft-odoherty-half-pint-00.txt>> 


------_=_NextPart_001_01C1105F.C6AE8C30
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>Half-Pint</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Comic Sans MS">Hi,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Comic Sans MS">I have submitted a new draft =
entitled 'Half-Pint' which as the name (kind of ...) suggests is a =
lightweight, restricted take on the functionality provided by the PINT =
protocol.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Comic Sans MS">The idea is to try to hit the =
high runner things that web developers wanting to integrate web =
applications with the PSTN want to do right now, and make it available =
in a way that web developers are familiar with and can work with right =
away. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Comic Sans MS">The natural place to discuss =
this would have been the PINT group, but unfortunately it is not around =
anymore, so I'm sending this notice onto to some other groups that may =
be interested in this type of thing to get feedback and =
comments.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Comic Sans MS">Cheers,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Comic Sans MS">Mick O'Doherty.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Comic Sans MS">P.S. I've attached the draft =
to this email as the version in the archives has picked up a few =
formatting errors somehow and is not quite fixed up yet.</FONT></P>
<BR>

<P><FONT FACE=3D"Arial" SIZE=3D2 COLOR=3D"#000000"> =
&lt;&lt;draft-odoherty-half-pint-00.txt&gt;&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1105F.C6AE8C30--

------_=_NextPart_000_01C1105F.C6AE8C30
Content-Type: text/plain;
	name="draft-odoherty-half-pint-00.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-odoherty-half-pint-00.txt"
Content-Transfer-Encoding: quoted-printable



Internet Engineering Task Force              Transport Area working =
Group       =20
NTERNET-DRAFT                                              Mick =
O=92Doherty=20
draft-ODoherty-Half-Pint-00.txt                                         =
 =20
Nortel Networks=20
July  2001                                                              =
            =20
                                          =20
=20
                               Half-Pint=20
=20
Status of this Memo=20
=20
   =20
   This document is an Internet-Draft and is in full conformance with =
all=20
   provisions of Section 10 of RFC2026 [1]. =20
   =20
   Internet-Drafts are working documents of the Internet Engineering =
Task Force=20
   (IETF), its areas, and its working groups. Note that other groups =
may also=20
   distribute working documents as Internet-Drafts. =20
   =20
   Internet-Drafts are draft documents valid for a maximum of six =
months and=20
   may be updated, replaced, or obsoleted by other documents at any =
time. It is=20
   inappropriate to use Internet- Drafts as reference material or to =
cite them=20
   other than as "work in progress." =20
   =20
   The list of current Internet-Drafts can be accessed at=20
   http://www.ietf.org/ietf/1id-abstracts.txt =20
   =20
   The list of Internet-Draft Shadow Directories can be accessed at=20
   http://www.ietf.org/shadow.html.=20
   =20
   =20
1. Abstract=20
   =20
   This document defines a simple protocol for interaction between the =
PSTN and=20
   applications in the IP domain. It is not intended to be a full INAP =
or JAIN=20
   like interface, rather to easily enable some of the more common =
interactions=20
   in a way that will allow application developers, with minimal =
telephony=20
   knowledge, to quickly integrate it into new and existing =
applications. This=20
   document includes simple Java HTTP Servlets which implement some =
basic parts=20
   of the protocol as an example (note similar approaches would work =
for CGI=20
   also). To get a quick feel for the protocol go straight to the =
example=20
   section near the end.=20
   =20
2. Overview=20
   =20
   Half-Pint allows developers of web applications, or in fact any type =
of=20
   applications, to interact with the functionality provided by the =
Public=20
   Switched Telephony Network (PSTN) or any other telephony system that =

   conforms to the Half-Pint protocol.=20
   =20
   It supports application to telephony system initiated interactions, =
such as=20
   creating calls between two telephony agents, as well as telephony =
system to=20
   application initiated interactions such as notification of incoming =
calls.=20
   =20
=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


   It is intended to be very easy to integrate into Web applications =
and to=20
   provide a quick way to interact with a small set of common services. =
In this=20
   way it is limited when compared with Intelligent Network (IN) or =
Java JAIN=20
   like protocols, and it is not intended to compete with these more =
complete=20
   solutions.=20
   =20
   The protocol is best described by looking at the messages and =
procedures=20
   that compose it and the remainder of this document follows this =
format.=20
   =20
   A quick way to get a feel for the protocol is to go straight to the =
example=20
   section at the end.=20
   =20
   The appendices include an example Java Servlet implementation that =
shows how=20
   a message might be generated and received.=20
   =20
3. General format of messages=20
   =20
   The protocol is defined in this document using the ABNF scheme =
defined in=20
   [3].=20
   =20
   A half-pint message is defined as:=20
   =20
   Half-Pint-message =3D HalfPintVersion    =20
                       Addressee=20
                       Sender=20
                       TransactionID   =20
                     [ AuthenticationInfo ] =20
                       MessageTypeandParameterPair             =20
   =20
   HalfPintVersion =3D (=93HalfPintVersion=94 | =93v=94) =93:=94 *token =

   =20
   Addressee =3D (=93Addressee=94 | =93a=94) =93:=94 absoluteURI=20
   =20
   Sender =3D (=93Sender=94 | =93s=94) =93:=94 absoulteURI=20
   =20
   TransactionID =3D (=93TransactionID=94 | =93t=94) =93:=94 token [ =
=93@=94 token]=20
   =20
   AuthenticationInfo =3D (=93AuthenticationInfo=94 | =93ai=94) =93:=94 =
*token=20
   =20
   Token =3D 1*< any CHAR  except CTL's  or separators> ; as in SIP =
spec [2]=20
   =20
   CTL =3D <any US-ASCII control character octets 0 -- 31) and DEL =
(127)>=20
   =20
   MessagetTypeandParameterPair =3D (=93MessagetType=94 | =93m=94) =
=93:=94 =20
         ( =93CreateCall=94 CreateCallParameterSet=20
         | =93AddPartyToCall=94 AddPartyToCallParameterSet=20
         | =93BookConferenceCall=94 BookConferenceCallParameterSet=20
         | =93ConferenceCallResponse=94 =
ConferenceCallResponseParameterSet=20
         | =93GeneralResponse=94 GeneralResponseParameterSet=20
         | =93RegisterCallAlert=94 RegisterCallAlertParameterSet=20
         | =93CancelCallAlert=94 CancelCallALertParameterSet=20
         | =93GetCallLog=94 GetCallLogParameterSet=20
         | =93ClearCallLog=94 ClearCallLogParameterSet=20
         | =93CallLog=94 CallLogParameterSet=20
=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


         | =93CallAlert=94 CallAlertParameterSet=20
         | =93CallAlertResponse=94 CallAlertResponseParameterSet=20
         | =93CallAlertError=94 CallAlertErrorParameterSet=20
         | =93SetSubscriberService=94 SetSubscriberServiceParameterSet=20
         | =93QuerySubscriberService=94 =
QuerySubscriberServiceParameterSet=20
         | =93SubscriberServiceStatus=94 =
SubscriberServiceStatusParameterSet=20
         | =93VoiceMailBoxQuery=94 VoiceMailBoxQueryParameterSet =20
         | =93VoiceMailBoxResponse=94 VoiceMailBoxResponseParameterSet=20
         | =93VoiceMailRequest=94 RetrieveVoiceMailParameterSet=20
         | =93VoiceMail=94 VoiceMailParameterSet )=20
   =20
=20
  An example of a CreateCallMessage is shown below =96 the additional =
parameters=20
  are explained later in the document: =20
  =20
  HalfPintVersion : 1.0=20
   Addressee : teleservice@teleprovider.org  =20
   Sender : 47.23.10.10=20
   TransactionID : 12345  =20
  AuthenticationInfo : X1943667    =20
  MessageType : CreateCall=20
  CallingParty : +441628770770=20
  CalledParty : +12137632212=20
  AnnouncementID : 5t443r=20
  CompletionNotification : n=20
=20
=20
4. Message addressing, transaction id, and authentication info=20
=20
  The Addressee, Sender and TransactionID parts of the message as =
defined=20
  above allow a receiver of a message to know who the message is for, =
who it=20
  is from and give a globally unique identifier for the transaction in =
the=20
  TransactionID. A transaction is a logical groupings of messages, such =
as a=20
  CreateCall and a Response or a CallAlert and a CallAlertError. In =
general,=20
  any message which is sent in reply to another message, should use the =

  transaction-id in the original message.=20
  =20
  In general it is expected that messages will be sent directly from =
the=20
  receiver to the sender, so the receiver of the message will just =
check that=20
  the message is from them (by looking at the Addressee field) and then =
act on=20
  it. However, messages can be proxied in which case the receiver looks =
at the=20
  Addressee and (if it decides to forward the message) sends it on to =
the=20
  receiver (or the next proxy in the path).=20
   =20
   The addressee and sender are defined as standard absolute URI=92s =
for this=20
   version of the document =96 further study is required to decide how =
best to=20
   represent these fields (for example do we need a new URL scheme =
etc).=20
   =20
   In the case where a port number is not specified a default port of =
7071 will=20
   be used.=20
   =20
   The TransactionID is similar to the call-id in the SIP protocol [2] =
from=20
   which this definition is taken and is simply to allow a particular =
request=20
   be uniquely identified: it MUST be a globally unique identifier and =
MUST NOT=20
=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


   be reused for later calls. Use of cryptographically random =
identifiers is=20
   RECOMMENDED. Implementations MAY use the form "localid@host". =
Call-IDs are=20
   case-sensitive and are simply compared byte-by-byte.=20
   =20
   Authentication info is used to identify the sender of a message and =
if=20
   necessary to decide if they have permission to use a particular =
service. The=20
   implementation of Authentication info is a topic for further study.=20
    =20
   =20
5. General message sending and responding procedures =20
   =20
   When a Half Pint message is received that needs to be replied to, =
the reply=20
   MUST be sent to the destination specified in the Sender field in the =

   message.=20
   =20
   All Half Pint messages MUST have the destination address specified =
in the=20
   Addressee field of the message and this is the destination which the =
message=20
   must be delivered to by whatever transport system is being used.=20
   =20
   =20
6. Call Initiation messages and procedures =20
   =20
   The following messages are defined to allow an application request =
that a=20
   call be initiated between two specified parties by the PSTN =
interface proxy:=20
   =20
6.1 CreateCall =20
   =20
   Overview=20
   --------=20
   CreateCall is used to request that a telephony proxy create a call =
between=20
   the parties identified in the parameters of the message. The call =
will be=20
   created by first ringing the =91calling party=92 and presenting them =
with=20
   ringing tone and then establishing a call between them and the =
=91called=20
   party=92. When the called party answers the call is fully set up.=20
   =20
   Message Parameters=20
   ------------------=20
   The definition of the parameters for CreateCall is:=20
   =20
   CreateCallParameterSet =3D   CallingParty=20
                              CalledParty=20
                             [AnnouncementID] =20
                              CompletionNotification=20
                             [CLIPresentation]=20
   =20
   CallingParty =3D (=93CallingParty=94 | =93cp=94) =93:=94 *token=20
   CalledParty =3D (=93CalledParty=94 | =93cdp=94) =93:=94*token=20
   AnnouncementID =3D (=93AnnouncementID=94 | =93aid=94) =93:=94 *token =

   CompletionNotification =3D (=93CompletionNotifictaion=94 | =93cn=94) =
=93:=94 (=93y=94 |  =93n=94)=20
   CLIPresentation =3D (=93CLIPresentation =94 | =93cli=94)  =93:=94   =
Restrict=20
                                                       | Present=20
   Restrict =3D =93Restrict=94 | =93r=94=20
   Present =3D =93Present=94 | =93p=94=20
                                         =20
=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


   =20
   =20
   =20
   Procedures for the generator of the message=20
   -------------------------------------------=20
   The application or entity generating this message, having built the =
message=20
   with all the correct information including the TransactionID, should =
wait=20
   for a GeneralResponse with a matching TransactionID to confirm that =
the=20
   telephony proxy that the message was sent to received the message. =
The=20
   General response will indicate if the request was successful or not. =
This=20
   indicates that the telephony proxy has agreed to make the requested =
call,=20
   not that the call has already been successfully set up. If no =
response is=20
   received within a certain time the application may decide to resend =
the=20
   message until 5 attempts have been made. The timeout period is left =
as=20
   implementation detail.=20
   =20
   Additionally, if an announcementID is included the receiver MUST =
play the=20
   announcement before setting up the call. If they do not have the =
ability to=20
   do this, then they MUST indicate that they cannot service the entire =
request=20
   with a General Request as mentioned above. The value of the =
announcement ID=20
   must be something that the receiver of the message will understand. =
How this=20
   is communicated is left to a implementation/deployment decision (for =

   instance a service provider may provide a special code for a =
customer=20
   announcement or may provide a list of standard announcement ids.=20
   Additionally they may provide some secure facility for a customer to =
load=20
   there own announcement id and then provide a unique id for it).=20
   =20
   If the application has requested CompletionNotification then it =
should be=20
   ready to accept an additional GeneralResponse message, indictaing =
either=20
   that the call has been successfully set up (responseType =3D =
=91ok=92) or that it=20
   has not been set up for some reason (response type =3D =91error=92). =
In both these=20
   cases the responseText field MUST begin with =
=91CreateCallConfirmation=92.=20
   =20
   If the application wishes to specify whether the CLI should be =
restricted or=20
   not it can specify this with the CLIPresentation parameter. If the =
parameter=20
   is not set the default setting for the user is set. Note that if =
this=20
   parameter is used it must be checked that it is supported by and =
within the=20
   rules of the telephony network.=20
   =20
   =20
   Procedures for the receiver of the message=20
   ------------------------------------------=20
  The receiver of the message should determine if it has the capability =
to=20
  service this request and if it does it should return a =
GeneralResponse=20
  message with a ResponseType of =91OK=92. If it does not it should =
return a=20
  GeneralResponse message with a ResponseType of =
=91CannotServiceRequest=92.=20
  =20
  If it is servicing the request the receiver must either directly, or =
through=20
  some other mechanism set up a call firstly to the CallingParty, =
connecting=20
  them to a ringing tone, and then establish a call to the CalledParty. =
If an=20
  AnnouncementID was specified, the CallingParty is first connected to =
the=20
  announcement before being connected to the RingingTone (or the =
CalledParty=20
  if the Announcement is used in place of the RingintTone). If the=20
  AnnouncementID is not receognised a GeneralResponse with an =
ResponseType of=20
=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


  =91Error=92 should be returned. Similarly, if CLIPresentation was =
specified as=20
  either Present or Restrict and this cannot be done, then a =
GeneralResponse=20
  with an ResponseType of =93CannotServiceRequest=94 MUST be sent and =
additionally=20
  a ResponseText reason in a human readable format can be given. =20
  =20
  If the application which sent the CreateCall message indicated that =
it=20
  wanted notification of call setup, an additional GeneralResponse =
message=20
  must be sent back to the application indicating whether the call was =
set up=20
  successfully or not =96 if the call was set up successfully the =
responseType=20
  Parameter is set to =91ok=92 and if not then it is set to =
=91error=92. The=20
  responseText parameter MUST begin with the text =
=91CreateCallConfirmation=92.=20
  =20
   =20
=20
6.2 AddPartyToCall=20
   =20
   Overview=20
   --------=20
   AddPartyToCall is used to request that a telephony proxy add a party =
to an=20
   existing call. The call is identified by one of the subscriber =
numbers=20
   involved in the call. =20
   =20
   Message Parameters=20
   ------------------=20
   The definition of the parameters for AddPartyToCall is:=20
   =20
   AddPartyToCallParameterSet =3D   SubscriberNumToAdd=20
                                  SubscriberNumber=20
                                 [CLIPresentation]=20
                           =20
   =20
   SubscriberNumToAdd =3D (=93SubscriberNumToAdd=94 | =93sna=94) =
=93:=94 *token=20
   SubscriberNumber =3D (=93SubscriberNumber=94 | =93sn=94) =
=93:=94*token=20
   CLIPresentation =3D (=93CLIPresentation =94 | =93cli=94)  =93:=94   =
Restrict=20
                                                       | Present=20
   Restrict =3D =93Restrict=94 | =93r=94=20
   Present =3D =93Present=94 | =93p=94                                  =
    =20
   =20
   =20
   =20
   Procedures for the generator of the message=20
   -------------------------------------------=20
   The application or entity generating this message, having built the =
message=20
   with all the correct information including the TransactionID, should =
wait=20
   for a GeneralResponse with a matching TransactionID and a =
ResponseType of=20
   =91ok=92 to confirm that the new party was added to the call, or a =
ResponseType=20
   other than =91ok=92 if the Party was not added to the call.=20
   =20
   =20
   Procedures for the receiver of the message=20
   ------------------------------------------=20
  The receiver of the message should determine if it has the capability =
to=20
  service this request and if it does it should return a =
GeneralResponse=20
  message with a ResponseType of =91OK=92once it has added the party. =
If it does=20
=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


  not it should return a GeneralResponse message with a ResponseType of =

  =91CannotServiceRequest=92.=20
  =20
  If it determines that the Subscriber number which identifies the call =
that=20
  that the new party is to be added to is not involved in a call, it =
again=20
  returns a GeneralResponse message with a ResponseType of =91error=92 =
and may=20
  additionally indicate in the ResponseText that the SubscriberNumber =
was not=20
  in a call.=20
  =20
  If CLIPresentation is present and is set to a value that it cannot =
comply=20
  with, it should send a GeneralResponse message with a ResponseType of =

  =91CannotServiceRequest=92 and may additionally indicate in the =
ResponseText why=20
  it was not able to comply in a human readable form.=20
  =20
=20
  =20
6.3 BookConferenceCall=20
   =20
   Overview=20
   --------=20
   BookConferenceCall is used to request that a telephony proxy create =
a=20
   conference call at a specified time and for a specified maximum =
number of=20
   participants. The telephony proxy will return host and participant =
dial in=20
   numbers, as well as password for each in a ConferenceCallResponse =
message.=20
   =20
   Message Parameters=20
   ------------------=20
   The definition of the parameters for BookConferenceCall is:=20
   =20
   BookConferenceCallParameterSet =3D   StartTime=20
                                        EndTime=20
                                        MaxParticipants=20
                                        =20
   =20
   StartTime =3D (=93StartTime=94 | =93s=94) =93:=94 DateAndTime=20
   EndTime =3D (=93EndTime=94 | =93e=94) =93:=94 DateAndTime=20
   MaxParticipants =3D (=93MaxParticipants=94 | =93mp=94) =93:=94  =
*Digit=20
   DateAndTime =3D (=93DateAndTime=94 | =93d=94) =93:=94   Date Time=20
   Date =3D Day.Month.Year=20
   Time =3D hour.min=20
   Day =3D =93Mon=94 | =93Tue=94 | =93Wed=94 | =93Thur=94 | =93Fri=94 | =
=93Sat=94 | =93Sun=94=20
   Month =3D firstdigit.seconddigit=20
   Year =3D 4*4Digit=20
   Firstdigit =3D %x30-31; can be =930=94 or =931=94=20
   Seconddigit =3D %x30-39; can be =930=94 to =939=94=20
   Hour =3D hourfirstdigit.hourseconddigit=20
   Hourfirstdigit =3D %x30-32; can be =930=94 or =931=94 or =932=94=20
   Hourseconddigit =3D %x30-39; can be =930=94 to =939=94=20
   Min =3D Minfirstdigit.Minseconddigit=20
   Minfirstdigit =3D %x30-35; can be =930=94 or =931=94 or =932=94 or =
=933=94 or =934=94 or =935=94=20
   Minseconddigit =3D %x30-39; can be =930=94 to =939=94=20
   =20
  =20
                                         =20
=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


   =20
   Procedures for the generator of the message=20
   -------------------------------------------=20
   The application or entity generating this message, having built the =
message=20
   with all the correct information including the TransactionID, should =
wait=20
   for a ConferenceCallResponse with a matching TransactionID to =
confirm that=20
   the telephony proxy that the message was sent to received the =
messageand has=20
   agreed to set up the conference call. If the telephony proxy has not =
agreed=20
   to set up the call this will be indicated in the =
ConferenceCallResponse. If=20
   no response is received within a certain time the application may =
decide to=20
   resend the message until 5 attempts have been made. The timeout =
period is=20
   left as implementation detail.=20
   =20
   If the telephony Proxy has agreed to set up the call then the =
application=20
   should store and/or pass on to the user(s) the host and participant =
numbers=20
   and passwords.=20
   =20
   =20
   Procedures for the receiver of the message=20
   ------------------------------------------=20
  The receiver of the message should determine if it has the capability =
to=20
  service this request and if it does and the resources are available =
at the=20
  requested time, it should return a ConferenceCallResponse message =
with a=20
  confirmation parameter of =91y=92. If it does not it should return a=20
  ConferenceCallResponse message with a confirmation parameter of =
=91n=92.=20
  =20
  If it is servicing the request it must also include the host and =
participant=20
  numbers and paswords.=20
=20
   =20
6.4 ConferenceCallResponse=20
   =20
   Overview=20
   --------=20
   ConferenceCallResponse is used by a telephony proxy to respond to a=20
   BookConferenceCall message.=20
   =20
   Message Parameters=20
   ------------------=20
   The definition of the parameters for ConferenceCallResponse is:=20
   =20
   ConferenceCallResponseParameterSet =3D Confirmation=20
                                       [HostNumber=20
                                        HostPassword=20
                                        ParticipantNumber=20
                                        ParticipantPassword ] =20
                                        =20
   Confirmation =3D (=93Confirmation=94 | =93c=94) =93:=94 (=93y=94 |  =
=93n=94)=20
   HostNumber =3D (=93HostNumber=94 | =93hn=94) =93:=94*token=20
   HostPassword =3D (=93HostPassword=94 | =93hp=94) =93:=94*token=20
   ParticipantNumber =3D (=93ParticipantNumber=94 | =93pn=94) =
=93:=94*token=20
   ParticipantPassword =3D (=93ParticipantPassword=94 | =93pp=94) =
=93:=94*token=20
                                         =20
   =20
=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


   Procedures for the generator of the message=20
   -------------------------------------------=20
   The application or entity generating this message, having built the =
message=20
   with all the correct information including the TransactionID, sends =
the=20
   message and does not expect a response. The host number and =
participant=20
   numbers refer to the numbers the host and the participants should =
dial in=20
   with. The password indicates the password they should enter when =
prompted.=20
   =20
   =20
   Procedures for the receiver of the message=20
   ------------------------------------------=20
  The receiver of the message will receive this in response to a=20
  BookConferenceCall message and should cancel any timers associated =
with the=20
  transaction.=20
   =20
=20
7. Call Alert messages and procedures=20
   =20
   These messages allow a telephony proxy to notify an application =
about an=20
   incoming call and provide a number of alternative actions that the=20
   application can take in response.=20
=20
7.1 RegisterCallAlert=20
   =20
   Overview=20
   --------=20
   RegisterCallAlert is used by a subscriber to indicate that they want =
to be=20
   notified with a CallAlert message when a call is received on the =
specified=20
   number. It may also be used by an application to indicate that it =
wants to=20
   be notified of incoming calls to a particular number (the telephony =
proxy=20
   must decide based on the authentication information whether to grant =
this to=20
   a particular user to avoid misuse of this feature =96 this is an=20
   implementation and deployment decision).=20
   =20
   Message Parameters=20
   ------------------=20
   The definition of the parameters for RegisterCallAlert is:=20
   =20
   RegisterCallAlertParameterSet =3D   SubscriberNumber=20
                                    *URItoAlert=20
                                     =20
   =20
   SubscriberNumber =3D (=93SubscriberNumber=94 | =93sn=94) =93:=94 =
*token=20
   URItoAlert =3D (=93URItoAlert=94 | =93U=94) =93:=94 absoluteURI=20
=20
   =20
   Procedures for the generator of the message=20
   -------------------------------------------=20
   The application or entity generating this message, having built the =
message=20
   with all the correct information including the TransactionID, should =
wait=20
   for a GeneralResponse with a matching TransactionID to confirm that =
the=20
   telephony proxy has accepted this request and will generate =
CallAlert=20
   Messages when appropriate and send them to each URIlisted in the URI =
to=20
   alert list.=20
=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


   =20
   If there was already registered URI=92s to be aletered for this =
Subscriber=20
   number the new URI=92s are added to the list to be alerted.=20
   =20
   Message timeout and retry timeout handling are as for the CreateCall =

   message. =20
   =20
   =20
   Procedures for the receiver of the message=20
   ------------------------------------------=20
  The receiver of the message should determine if it has the capability =
to=20
  service this request and if it does it should return a =
GeneralResponse=20
  message with a ResponseType of =91ok=92. If it does not it should =
return a=20
  GeneralResponse message with a ResponseType of =
=91CannotServiceRequest=92.=20
   =20
7.2 CancelCallAlert=20
   =20
   Overview=20
   --------=20
   CancelCallALert is used by a subscriber to indicate that they no =
longer want=20
   to be notified with a CallAlert message when a call is received on =
the=20
   specified number. It may also be used by an application to indicate =
that it=20
   no longer wants to be notified of incoming calls to a particular =
number (the=20
   telephony proxy must decide based on the authentication information =
whether=20
   to grant this to a particular user to avoid misuse of this feature =
=96 this is=20
   an implementation and deployment decision).=20
   =20
   Message Parameters=20
   ------------------=20
   The definition of the parameters for CancelCallAlert is:=20
   =20
   CancelCallAlertParameterSet =3D   SubscriberNumber=20
                                  [*URItoAlert]=20
   =20
   SubscriberNumber =3D (=93SubscriberNumber=94 | =93sn=94) =93:=94 =
*token=20
   URItoAlert =3D (=93URItoAlert=94 | =93U=94) =93:=94 absoluteURI=20
   =20
   =20
   Procedures for the generator of the message=20
   -------------------------------------------=20
   The application or entity generating this message, having built the =
message=20
   with all the correct information including the TransactionID, should =
wait=20
   for a GeneralResponse with a matching TransactionID to confirm that =
the=20
   telephony proxy has accepted this request and will not generate =
CallAlert=20
   messages to the specified URI when a call arrives on the specified =
number.=20
   =20
   If there are no URItoAlert=92s in the message then all the =
previously=20
   registered URI=92s for this subscriber number are cancelled.=20
   =20
   Message timeout and retry timeout handling are as for the CreateCall =

   message. =20
   =20
   =20
   Procedures for the receiver of the message=20
=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


   ------------------------------------------=20
  The receiver of the message should cancel any notification associated =
with=20
  this number and send back a successful general response message. If =
it had=20
  no notification set on this number it should still reply with a =
Successful=20
  General Response message.=20
   =20
7.3 CallAlert =20
   =20
   Overview=20
   --------=20
   CallAlert is used to indicate that a Call has been received on a =
particular=20
   subscriber number. It may contain a set of allowed actions that may =
be=20
   included in a CallAlertResponse message.=20
   =20
   Message Parameters=20
   ------------------=20
   The definition of the parameters for CallAlert is:=20
   =20
   CallAlertParameterSet =3D   CallingParty=20
                             CalledParty=20
                            [ForwardedFromParty]=20
                            *AlertParameters=20
   =20
   CallingParty =3D (=93CallingParty=94 | =93cp=94) =93:=94 *token=20
   CalledParty =3D (=93CalledParty=94 | =93cdp=94) =93:=94 *token=20
   ForwardedFromParty =3D (=93ForwardedFromParty=94 | =93fp=94) =93:=94 =
*token=20
   AlertParameters =3D  ContactURL =20
                    | CallingName  =20
                    | CallingPictureURL=20
                    | ActionOption=20
   ContactURL =3D (=93ContactURL=94 | =93ctu=94) =93:=94 AbsoluteURI=20
   CallingName =3D (=93CallingName=94 | =93cln=94) =93:=94 *token=20
   CallingPictureURL =3D (=93CallingPictureURL=94 | =93picU=94) =93:=94 =
AbsoluteURI=20
   ActionOption =3D  ActionLabel=20
                  [ActionText] =20
   ActionText =3D *Token=20
   ActionLabel =3D  PreDefinedAction=20
                | SenderDefinedAction=20
   SenderDefinedAction =3D *Token=20
   PreDefinedAction =3D  =93RejectCall=94=20
                     | =93ForwardCallTo=94 =93:=94  *token=20
                     | =93SendToVoiceMail=94=20
   =20
   =20
   Procedures for the generator of the message=20
   -------------------------------------------=20
   The telephony proxy generates this message for each device that is=20
   registered to be notified when a call is received on this number. It =
builds=20
   the messages with all the applicable headers including a =
transaction-id per=20
   message and sends them out. The ActionOptions fields indicate the =
actions=20
   (if any) that the receiver of the message may choose and send back =
in a=20
   CallAlertResponse message. The Actions may be one or more of the set =
of=20
   predefined actions, or a sender defined action represented by a text =
string.=20
   The actions, whether predefined or User defined may be accompanied =
by a text=20
=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


   string which should be suitable for display to a human user, if the=20
   receiving application is capable of and wishes to present it. If the =
call=20
   was previously forwarded and this information is available it should =
be=20
   included in the ForwardedFromParty parameter.=20
   =20
   Once the message has been sent a Response is expected and the sender =
should=20
   wait for this. Message retry and timeout is the same as for Create =
Message=20
   and the timeout period is left to the implementation, but for this =
case it=20
   must allow for the telephony call which is associated with this =
message and=20
   which will almost certainly have its own timers and timeouts.=20
   =20
   When the Response is received, the telephony Proxy should apply =
whatever=20
   action the Response indicates. If no Action is indicated, or if the =
original=20
   message did not include any action options, then the message is =
simply a=20
   confirmation that the message was received and the call telephony =
Server=20
   should apply the default action, which is to allow the call to =
continue as=20
   it would normally.=20
   =20
   If the Response contains an action which is not supported by the =
Telephony=20
   Proxy or which it does not wish to allow for this subscriber number =
or=20
   sending application, or the response does not correspond to any call =
or=20
   CallAlert message sent by the telephony Proxy it MUST reply to the =
message=20
   with a CallAlertError message with a the reason set appropriately =
and=20
   optionally a Human readable error message.=20
   =20
   Once the first response has been received all further responses =
(from other=20
   devices the CallAlert was sent to for example) are ignored and a=20
   CallAlertError message is sent back to the sender with a code of=20
   =91NoCallAlertSent=92.=20
   =20
   =20
   Procedures for the receiver of the message=20
   ------------------------------------------=20
  The receiver of the message should look at the allowed actions (if =
any) and=20
  decide by whatever means it wants (e.g. interaction with a human =
user, rules=20
  table, algorithm etc) which action (if any) it wants to take. If it =
does not=20
  recognize any of the actions in the case where the actions are user =
defined,=20
  then it simply responds with a CallALert message with no Action =
included.=20
  The same reply is used for the case where the CallAlert contained no=20
  ActionOptions.=20
  =20
  =20
7.4 CallAlertResponse =20
   =20
   Overview=20
   --------=20
   CallAlertResponse is sent in reply to a CallAlert message to =
acknowledge=20
   receipt of the CallAlert and to indicate which (if any) of the =
allowed=20
   Actions has been selected.=20
   =20
   Message Parameters=20
   ------------------=20
   The definition of the parameters for CallAlertResponse is:=20
   =20
=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


   CallAlertResponseParameterSet =3D ActionLabel=20
                                  =20
   =20
   Procedures for the generator of the message=20
   -------------------------------------------=20
   This message is sent in response to a CallAlert Message so the =
procedures=20
   are as for the receiver of CallAlert Messages above.=20
   =20
   =20
   Procedures for the receiver of the message=20
   ------------------------------------------=20
  If the receiver has sent a CallAlert which led to this response then =
the=20
  procedures are as defined in the generator of CallAlert messages =
above. =20
  =20
  If the receiver had not generated a CallAlert message and hence did =
not=20
  expect this message then a CallAlertError message is generated with a =
reason=20
  of =91NoCallAlertSent=92 and optionally a human readable error =
message in the=20
  CallError parameter.=20
  =20
   =20
7.5 CallAlertError =20
   =20
   Overview=20
   --------=20
   CallAlertError is used to indicate that an Error has been generated =
during a=20
   CallAlert interaction, usually because the CallAlertResponse has =
some=20
   problem with it. =20
   =20
   Message Parameters=20
   ------------------=20
   The definition of the parameters for CallAlert is:=20
   =20
   CallAlertErrorParameterSet =3D   ErrorType=20
                                  ErrorMessage=20
   =20
   ErrorType =3D =93NoCallAlertSent=94=20
             | =93ResponseFromOtherDeviceReceived=94=20
             | =93UnknownAction=94=20
             | =93ActionNotAllowed=94=20
             | =93CallError=94=20
   =20
   ErrorMessage =3D *Token=20
   =20
   Procedures for the generator of the message=20
   -------------------------------------------=20
   The cases in which a CallAlert Error message can be generated are =
described=20
   in the CallAlert and CallAlertResponse sections above. The generator =
builds=20
   and sends the message with the appropriate error code and an error =
message=20
   which can be presented to a human user if appropriate. =20
   =20
   =20
   Procedures for the receiver of the message=20
   ------------------------------------------=20

=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


  The receiver of the message should look at Error code and Error =
message and=20
  raise an alarm or notify the user as appropriate. =20
   =20
   =20
8. Call Log Messages=20
   =20
   These messages allow an application or user query and manipulate =
call log=20
   details for a specified subscriber number.=20
=20
8.1 GetCallLog=20
   =20
   Overview=20
   --------=20
   GetCallLog is used to request a log of incoming, outgoing or both =
incoming=20
   and outgoing calls from a telephony proxy. The requester can specify =
how=20
   many calls back in the call history they want to go.  =20
   =20
   Message Parameters=20
   ------------------=20
   The definition of the parameters for GetCallLog is:=20
   =20
   GetCallLogParameterSet =3D SubscriberNumber=20
                            Direction=20
                           [NumberOfCalls]   =20
   =20
   =20
   SubscriberNumber =3D (=93SubscriberNumber=94 | =93sn=94) =93:=94 =
*token=20
   Direction =3D (=93Direction=94 | =93D=94) =93:=94 DirectionString=20
   DirectionString =3D (=93Incoming=94 | =93I=94) |(=93Outgoing=94 | =
=93O=94) | (=93both=94 | =93b=94)=20
   NumberOfCalls =3D Integer=20
   =20
   Procedures for the generator of the message=20
   -------------------------------------------=20
   The application or entity generating this message, having built the =
message=20
   with all the correct information including the TransactionID, should =
wait=20
   for a CallLog message with a matching TransactionID.=20
   =20
   Message timeout and retry timeout handling are as for the CreateCall =

   message.=20
   =20
   Note that the NumberOfCalls Parameter can be used to get the last 5, =
10 etc=20
   calls, or simply the last one call making this effectively a get =
last call=20
   message.=20
   =20
   =20
   Procedures for the receiver of the message=20
   ------------------------------------------=20
  The receiver of the message should reply with a CallLog message for =
the=20
  specified direction(s) if it is capable of servicing the request or =
with a=20
  GeneralResponse message with a ResponseType of =
=91CannotServiceRequest=92 if it=20
  is not.=20
   =20
   =20
8.2 ClearCallLog=20
=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


   =20
   Overview=20
   --------=20
   ClearCallLog is used to Clear the Call Log for the specified =
direction(s) on=20
   the telephony proxy for a particular Subscriber number.  =20
   =20
   Message Parameters=20
   ------------------=20
   The definition of the parameters for ClearCallLog is:=20
   =20
   ClearCallLogParameterSet =3D  SubscriberNumber=20
                               Direction=20
   =20
   =20
   SubscriberNumber =3D (=93SubscriberNumber=94 | =93sn=94) =93:=94  =
*token=20
   Direction =3D (=93Direction=94 | =93D=94) =93:=94 DirectionString=20
   DirectionString =3D (=93Incoming=94 | =93I=94) |(=93Outgoing=94 | =
=93O=94) | (=93both=94 | =93b=94)=20
   =20
   Procedures for the generator of the message=20
   -------------------------------------------=20
   The application or entity generating this message, having built the =
message=20
   with all the correct information including the TransactionID, should =
wait=20
   for a General Response message with a matching TransactionID.=20
   =20
   Message timeout and retry timeout handling are as for the CreateCall =

   message. =20
   =20
   =20
   Procedures for the receiver of the message=20
   ------------------------------------------=20
  The receiver of the message should reply with a GeneralREsponse =
message with=20
  a ResposneType of =91ok=92 if it is capable of servicing the request =
or with a=20
  GeneralResponse message with a ResponseType of =
=91CannotServiceRequest=92 if it=20
  is not.=20
   =20
   =20
8.3 CallLog=20
   =20
   Overview=20
   --------=20
   CallLog is used to send a Call Log to an entity that has requested =
one.=20
   =20
   Message Parameters=20
   ------------------=20
   The definition of the parameters for CallLog is:=20
   =20
   CallLogParameterSet =3D SubscriberNumber=20
                         * (Direction=20
                            CallLogReport)=20
   =20
   =20
   SubscriberNumber =3D (=93SubscriberNumber=94 | =93sn=94) =93:=94  =
*token=20
   Direction =3D (=93Direction=94 | =93D=94) =93:=94 DirectionString=20
   DirectionString =3D (=93Incoming=94 | =93I=94) |(=93Outgoing=94 | =
=93O=94) | (=93both=94 | =93b=94)=20
=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


   CallLogReport =3D *token| url=20
   =20
   Procedures for the generator of the message=20
   -------------------------------------------=20
   The application or entity generating this message, having built the =
message=20
   with all the correct information including the TransactionID, sends =
the=20
   message and does not expect a response. The Log Report will consist =
of a=20
   field indicating the direction and then the text for the Call Log =
for that=20
   direction. The format of the Call Log is left to implementations, =
but HTML,=20
   XML or standard Text are probably appropriate. If the length of the =
callLog=20
   is too long for the transport system (for instance if UDP is being =
used and=20
   the total message length exceed 1500 bytes) it may be more =
appropriate to=20
   send a URL to the call log, which the receiver can then use to =
retrieve it.=20
   =20
   =20
   Procedures for the receiver of the message=20
   ------------------------------------------=20
  The receiver of the message will receive this in response to a =
GetCallLog=20
  message. If the message contains a URL for the call log the receiver =
should=20
  access this URL to retrieve the log.=20
   =20
   =20
9. Subscriber Service Management Services=20
   =20
   These messages allow a subscribers service to be set and queried =
through the=20
   telephony Proxy. The format of the service specific information is =
not=20
   specified as part of this document (for now).=20
   =20
9.1 SetSubscriberService =20
   =20
   Overview=20
   --------=20
   This message is used to set a service for a particular telephony =
subscriber =20
   (directory number). Note that setting the service means set it to =
some=20
   state, not necessarily just setting it on =96 this message can be =
used to set=20
   a service off also for example.=20
   =20
   Message Parameters=20
   ------------------=20
   The definition of the parameters for SetSubscriberService is:=20
   =20
   SetSubscriberServiceParameterSet =3D   SubscriberNumber=20
                                        ServiceName=20
                                        ServiceInfo=20
   =20
   SubscriberNumber =3D (=93SubscriberNumber=94 | =93sn=94) =93:=94 =
*token=20
   ServiceName =3D (=93ServiceName=94 | =93svn=94) =93:=94 *token=20
   ServiceInfo =3D (=93ServiceInfo=94 | =93svi=94) =93:=94 *token=20
   =20
   Procedures for the generator of the message=20
   -------------------------------------------=20
   The generator of this message is responsible for setting the Service =
name=20
   and Service info appropriately, so that the telephony proxy =
recognizes it.=20

=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


   For now there is no format specified for this information, as many =
services=20
   are possible with diverse parameter requirements. It is up to the =
sender of=20
   the message to use a scheme that will be understood by the receiver. =
It may=20
   be worth in the future allowing a scheme to specify the format of =
this=20
   information (e.g. by referring to a XML DTD)- this can be left for =
further=20
   study for now.=20
   =20
   The generator of the message waits for a General Response message =
which will=20
   indicate either that the request was successfully serviced or that =
there was=20
   an error. Message retry and timeout is the same as for Create =
Message=20
   =20
   =20
   Procedures for the receiver of the message=20
   ------------------------------------------=20
  The receiver of the message should service the request if it can and =
return=20
  a General Response message with the ResponseType set to =91ok=92. If =
it cannot=20
  service the response (e.g. it does not recognize the service info =
format) it=20
  should repond with a GeneralResponse with the ResponseType set to=20
  =91CannotServiceRequest=92 and optionally a human readable error =
message in the=20
  ResponseText.=20
   =20
   =20
9.2 QuerySubscriberService=20
   =20
   Overview=20
   --------=20
   This message is used to query the status of a service or a number of =

   services for a particular telephony subscriber (directory number).=20
   =20
   Message Parameters=20
   ------------------=20
   The definition of the parameters for QuerySubscriberService is:=20
   =20
   QuerySubscriberServiceParameterSet =3D   SubscriberNumber=20
                                         [ *ServiceName ]=20
   =20
                                          =20
   =20
   SubscriberNumber =3D (=93SubscriberNumber=94 | =93sn=94) =93:=94 =
*token=20
   ServiceName =3D (=93ServiceName=94 | =93svn=94) =93:=94 *token=20
   =20
   Procedures for the generator of the message=20
   -------------------------------------------=20
   The generator of this message generate the message with either the =
names of=20
   all the services that they want status info on, with no service =
names in=20
   which case the status of all services will be returned.=20
   =20
   The generator of the message waits for a SubscriberServiceStatus =
message=20
   which will indicate either that the request was successfully =
serviced or a=20
   GeneralResponse message which will indicate that there was an error. =
Message=20
   retry and timeout is the same as for Create Message=20
   =20
   =20
   Procedures for the receiver of the message=20
=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


   ------------------------------------------=20
  The receiver of the message should service the request if it can and =
return=20
  a SubscriberServiceStatus message. If it cannot service the response =
(e.g.=20
  it does not recognize the service info format) it should respond with =
a=20
  GeneralResponse with the ResponseType set to =
=91CannotServiceRequest=92 and=20
  optionally a human readable error message in the ResponseText.=20
   =20
   =20
9.3 SubscriberServiceStatus=20
   =20
   Overview=20
   --------=20
   This message is used to report the status of a service or a set of =
services=20
   for a particular telephony subscriber (directory number).=20
   =20
   Message Parameters=20
   ------------------=20
   The definition of the parameters for SubscriberServiceStatus is:=20
   =20
   SubscriberServiceStatusParameterSet =3D   SubscriberNumber=20
                                         *[ServiceName=20
                                           ServiceInfo]=20
                                      =20
   SubscriberNumber =3D (=93SubscriberNumber=94 | =93sn=94) =93:=94 =
*token=20
   ServiceName =3D (=93ServiceName=94 | =93svn=94) =93:=94 *token=20
   ServiceInfo =3D (=93ServiceInfo=94 | =93svi=94) =93:=94 *token=20
   =20
   Procedures for the generator of the message=20
   -------------------------------------------=20
   This message is generated in response to a QuerySubscriberService =
message.=20
   =20
   =20
   Procedures for the receiver of the message=20
   ------------------------------------------=20
  The receiver of the message checks the Status and makes it available =
to the=20
  end user (or another process).=20
  =20
   =20
10. Voicemail Messages=20
   =20
   These message allow a user or application interact with a =
subscribers=20
   voicemail via the telephony Proxy.=20
   =20
10.1 VoiceMailBoxQuery=20
   =20
   Overview=20
   --------=20
   VoiceMailBoxQuery is used to query the status of the mailbox for a=20
   particular subscriber number.=20
   =20
   Message Parameters=20
   ------------------=20
   The definition of the parameters for VoiceMailBoxQuery is:=20
   =20
=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


   VoiceMailBoxQueryParameterSet =3D SubscriberNumber=20
   =20
   SubscriberNumber =3D (=93SubscriberNumber=94 | =93sn=94) =93:=94 =
*token=20
   =20
   =20
   Procedures for the generator of the message=20
   -------------------------------------------=20
   The generator of this message build the complete message including =
the=20
   TransactionID and sends the message to the telephony proxy.=20
   =20
   Once the message has been sent a Response is expected and the sender =
should=20
   wait for this. Message retry and timeout is the same as for Create =
Message=20
   and the timeout period is left to the implementation.=20
   =20
   If the request is successful a VoiceMailBoxResponse message will be=20
   received. If there is a problem a GeneralResponse message with an=20
   appropriate error code will be received.=20
   =20
   Procedures for the receiver of the message=20
   ------------------------------------------=20
  The receiver of the message should determine if it can service the =
request=20
  and if so it should do so and return a VoiceMailBoxResponse message.=20
  =20
  If it cannot service the request it should send a GeneralResponse =
message=20
  with the ResponseType set to =91CannotServiceRequest=92.=20
   =20
   =20
10.2 VoiceMailBoxResponse=20
   =20
   Overview=20
   --------=20
   VoiceMailBoxResponse is used to reply to a VoiceMailBoxQuery =
message,=20
   providing the status of the mailbox for a particular subscriber =
number.=20
   =20
   Message Parameters=20
   ------------------=20
   The definition of the parameters for VoiceMailBoxResponse is:=20
   =20
   VoiceMailBoxResponseParameterSet =3D SubscriberNumber=20
                                      NumberOfVoiceMails=20
                                    *[VoiceMailRecord]=20
   =20
   SubscriberNumber =3D (=93SubscriberNumber=94 | =93sn=94) =93:=94 =
*token=20
   NumberofVoiceMails =3D (=93NumberOfVoiceMails=94 | =93nv=94) =93:=94 =
*Digit=20
   VoiceMailRecord =3D VoiceMailID=20
                     CallingNumber=20
                     DateAndTime=20
                     Duration=20
                     ReadTag=20
                    [Urgency]=20
   =20
   VoiceMailID =3D (=93VoiceMailID=94 | =93vmi=94) =93:=94 *token =20
   CallingNumber =3D (=93CallingNumber=94 | =93cn=94) =93:=94 *token=20
   DateAndTime =3D (=93DateAndTime=94 | =93d=94) =93:=94 Date Time; see =
BookConferenceCall=20
=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


   Duration =3D (=93Duration =94 | =93du=94) =93:=94 *digit=20
   ReadTag =3D (=93ReadTag=94 | =93r=94) =93:=94 (=93y=94 | =93n=94)=20
   Urgency =3D (=93Urgency=94 | =93u=94) =93:=94 *token=20
   =20
   =20
   Procedures for the generator of the message=20
   -------------------------------------------=20
   The generator of this message builds this message in response to a=20
   VoiceMailQQueryMessage. =20
   =20
   Procedures for the receiver of the message=20
   ------------------------------------------=20
  The receiver of the message takes the information in the message and =
makes=20
  it available to a user or another application.=20
   =20
   =20
10.3 VoiceMailRequest=20
   =20
   Overview=20
   --------=20
   VoiceMailRequest is used to request an action on a particular =
voicemail for=20
   a given subscriber number.=20
   =20
   Message Parameters=20
   ------------------=20
   The definition of the parameters for VoiceMailRequest is:=20
   =20
   VoiceMailRequestParameterSet =3D SubscriberNumber=20
                                      VoiceMailID=20
                                      RequestType=20
   =20
   SubscriberNumber =3D (=93SubscriberNumber=94 | =93sn=94) =93:=94 =
*token=20
   VoiceMailID =3D (=93VoiceMailID=94 | =93vmi=94) =93:=94 *token =20
   RequestType =3D (=93RequestType=94 | =93r=94) =93:=94  =
RetreiveRequestType=20
                                          | =93Delete=94=20
                                          | ForwardRequestType=20
   =20
   =20
   RetreiveRequestType =3D (=93Retrieve in format=94 | =93rf=94) =
=93:=94 *token=20
   ForwardRequestType =3D (=93Forward to=94 | =93ft=94) =93:=94 *token=20
   =20
   =20
   Procedures for the generator of the message=20
   -------------------------------------------=20
   The generator of this message must know the specific VoiceMailID =
that they=20
   want the request to apply to. They then build and send the message =
and wait=20
   for a VoiceMailResponse message, or a GeneralResponse message. =
Timeout is as=20
   for the CreateCall message.=20
   =20
   Procedures for the receiver of the message=20
   ------------------------------------------=20
  The receiver of the message looks at the VoiceMailID and the =
requesttype and=20
  determines if it can service the request. If it can it does so and =
replies=20
  with a GeneralResponse message with the ResponseType set to =91ok=92, =
or if=20
=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


  retrieval of a voicemail was requested with a VoiceMail message. If =
it=20
  cannot it returns a GeneralResponse with the ResponseType set to=20
  =91CannotServiceRequest=92.=20
  =20
  In the case of a =91retreive in format=92 request where the format is =
not=20
  recognised or not supported, the receiver replies with a =
GeneralResponse=20
  message with the ResponseType set to =91cannotServiceRequest=92 and =
optionally=20
  the ResponseText explaining in a human readable form that the =
requested=20
  format was not recognised or not supported.=20
   =20
   =20
10.4 VoiceMail=20
   =20
   Overview=20
   --------=20
   VoiceMail is used to reply to a VoiceMailRequest with a Voicemail.=20
   =20
   Message Parameters=20
   ------------------=20
   The definition of the parameters for VoiceMailResponse is:=20
   =20
   VoiceMailResponseParameterSet =3D  SubscriberNumber=20
                                    VoiceMailID=20
                                    Format=20
                                    VoiceMail=20
   =20
   SubscriberNumber =3D (=93SubscriberNumber=94 | =93sn=94) =93:=94 =
*token=20
   VoiceMailID =3D (=93VoiceMailID=94 | =93vmi=94) =93:=94 *token =20
   Format =3D (=93Format=94 | =93f=94) =93:=94 *token=20
   VoiceMail =3D (=93VoiceMail=94 | =93v=94) =93:=94 Vmail=20
   Vmail =3D  *token =20
          | absoluteURI=20
=20
   Procedures for the generator of the message=20
   -------------------------------------------=20
   This message is generally sent in response to a VoiceMailRequest =
message.=20
   The sender of this message (VoiceMail) must ensure that the format =
field=20
   matches the format of the Voicemail sent. It may be better in many =
cases to=20
   send a URI for the voicemail than the voicemail itself. If it is =
included in=20
   the message directly, then the format field tells the receiver how =
to=20
   interpret the data represented by *token.=20
   =20
   Procedures for the receiver of the message=20
   ------------------------------------------=20
  The receiver of the message looks at the format field and uses it to =
present=20
  the VoiceMail to a user or another application.=20
  =20
   =20
11. Misc Messages=20
   =20
   Messages whose scope is general.=20
   =20
11.1 GeneralResponse =20
   =20
=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


   Overview=20
   --------=20
   GeneralResponse is used to respond to a received message when there =
is no=20
   specific message for the purpose.=20
   =20
   Message Parameters=20
   ------------------=20
   The definition of the parameters for GeneralResponse is:=20
   =20
   GeneralResponseParameterSet =3D ResponseType=20
                                [Responsetext]  =20
   =20
   ResponseType =3D  (=93ResponseType=94 | =93rt=94) =93:=94 =20
                  (  =93OK=94=20
                   | =93Error=94=20
                   | =93UnexpectedMessage=94=20
                   | =93UnrecognisedMessage=94=20
                   | =93CannotServiceRequest=94=20
                   | *token )=20
   =20
   ResponseText =3D (=93ResponseText=94 | =93rtx=94) =93:=94 *token=20
                                  =20
   =20
   Procedures for the generator of the message=20
   -------------------------------------------=20
   This generator builds the message with the TransactioID equal to the =

   received message and the ResponseType set appropriately. The =
optional=20
   ResponseText can be used to include an error message that is =
understandable=20
   by a human user.=20
   =20
   =20
   Procedures for the receiver of the message=20
   ------------------------------------------=20
   The receiver checks the error code and takes whatever alerting, =
maintenance,=20
   or recovery action is appropriate. This message does not require a =
response.=20
   =20
   =20
   =20
12. Unrecognised or unexpected messages=20
   =20
   The default behaviour for unexpected or unrecognised received =
messages is to=20
   simply ignore them.=20
   =20
   For this reason it is important that all Half Pint messages which =
are resent=20
   on timeout, stick to the limit of 5 retries before abandoning.=20
   =20
   An entity supporting Half-Pint can send back a GeneralResponse =
message with=20
   a ResponseType of UnexpcetedMessage or UnrecognisedMessage if it =
wishes.=20
=20
   =20
13. Message set transported directly on UDP=20
   =20


=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


   While how a Half-Pint message is transported is not specified, and =
many=20
   different options are available, transport over UDP is both simple =
and=20
   likely so it is worth mentioning briefly.=20
   =20
   With UDP the Half-Pint messages can be transported directly on top =
of UDP=20
   over IP. Each UDP datagram should contain one half-pint message. As =
is=20
   common practice (for example see SIP spec [2]), datagrams should not =
be=20
   larger than the path maximum transmission unit (MTU) or 1500 bytes =
if the=20
   MTU is unknown. However, implementations must be able to handle =
messages up=20
   to the maximum datagram size for UDP which is 65,535 bytes.=20
   =20
   =20
14. Versioning and Extending the Half-Pint Protocol=20
   =20
   All new versions of Half-Pint should be backwardly compatible =96 =
i.e. they=20
   must support the message format and procedures from previous =
versions.=20
   =20
   Therefore, if a Half-Pint implementation receives a message from a =
previous=20
   Version it should handle the message as specified in the spec for =
the=20
   previous version.=20
   =20
   If a Half-Pint implementation receives a message from a version =
newer than=20
   itself, it responds with a General Response message indicating which =
version=20
   it supports. The sender of the message can decide how to react to =
this,=20
   perhaps by reverting to an earlier version of the message or by =
abandoning=20
   the request.=20
   =20
   =20
15. Examples=20
   =20
   Click to Call service=20
   ---------------------=20
   A common requirement is to provide a facility for a web user to =
click on a=20
   button and have a call set up between them and the web site owner =
(or some=20
   other party). This type of service can easily be realised with the =
Half Pint=20
   Protocol as follows:=20
   =20
   1) The user clicks on a button on =91ACME inc=92 website to request =
to speak to=20
   a company representative.=20
   2) The web application generates a CreateCall message with the users =
number=20
   as the Calling number and the company=92s Call Centre as the Called =
number.=20
   The users number which is put in the message can either be prompted =
for or=20
   retrieved from some database about the user.=20
   3) The telephony Proxy receives the message and generates the call.=20
   4) The Users phone rings and when they answer it the call is placed =
to the=20
   company=92s Call Centre.=20
   5) The Call Centre representative answers and is connected to the =
user.=20
   Information such as the users account details, if they are a regular =

   customer, can be made available based on the Calling users CLI. =20
   =20
   Call Notification Service=20
   -------------------------=20
   A user working on their computer, or watching their television can =
have an=20
   alert pop up on the computer or TV screen alerting them about an =
incoming=20
=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


   call and indicating who is calling. The user may decide to answer =
the call,=20
   send it to voicemail or forward it to some other number. The flow =
for this=20
   service is as follows:=20
   =20
   1) The user registers with the telephony Proxy for the call alerting =

   service.=20
   2) When a call comes in for the user a Call Alert message is sent to =
the=20
   devices specified in the Call Alerting registration.=20
   3) The user decides what action to take and if they decide, for =
example, to=20
   send the call to voicemail, the user interacts with the computer or =
the TV=20
   GUI and a CallAlertResponse message is generated and sent back to =
the=20
   Telephony Proxy.=20
   =20
   Note that the user will also hear their phone ring (providing they =
are in=20
   the vicinity of it, of course !) when the call arrives. When some =
action is=20
   taken such as forwarding to Voicemail, the ringing stops.=20
   =20
   =20
   Conference Call Application=20
   ---------------------------=20
   A web based conference call controller service might work as =
follows:=20
   =20
   1) The organizer of the conference call enters the details of the =
conference=20
   call into a web based conference service. They might schedule a =
particular=20
   conference for the following day at noon. They also may specify =
email=20
   addresses of the other participants so that they can be notified of =
the call=20
   by email. The web conference controller application sends a=20
   BookConferenceCall message to the telephony proxy with the =
appropriate=20
   details.=20
   2) The next day the telephony proxy creates the conference call (or =
takes=20
   control of the conference equipment =96 the call itself may not be =
created=20
   until the first participant dials in depending on the way the =
telephony=20
   system works) at 11:55 and waits for the host or participants to =
dial in. If=20
   other participants dial in before the host they will be not be =
allowed enter=20
   the conference until the host has arrived and will be put on hold =
(and=20
   likely will be able to listen to either some advertising/branding or =

   =91Greensleeves=92).=20
   3) The host and participants can enter the conference either by =
clicking on=20
   a URL included in the email notification, which will cause the web=20
   conferencing controller application to use the CreateCall message to =
add the=20
   user to the conference call, or by dialing directly a number =
specified in=20
   the email. =20
=20
16. Acknowledgements=20
   =20
   This protocol is a simple extension and formalization of work done =
in Nortel=20
   Networks by the following people: Dave Armstrong, Steve Perkins, =
Laurent=20
   Phelep, John Storrie and Bryan Miller.=20
   =20
17. References=20
   =20
   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP =
9, RFC=20
      2026, October 1996.=20
   =20
=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


   2  Handley, et al., "RFC 2543 SIP: Session Initiation Protocol March =
  =20
      1999=94=20
   =20
   3  Crocker & Overell, =93Augmented BNF for Syntax Specifications: =
ABNF=94=20
   =20
   =20
   Author=92s Address=20
   =20
   Mick O=92Doherty    =20
   Nortel Networks                 =20
   Concorde Road=20
   Maidenhead=20
   Berkshire=20
   SL6 4AG=20
   England=20
   mdoherty@nortelnetworks.com=20
   =20
   =20
   =20
   =20
   =20
   Appendix A =96 Example HTTP servlets=20
   =20
   The example code below consists of three classes. It does not fully=20
   implement a web server based implementation of Half Pint, but it =
gives=20
   enough to suggest one example of an architecture that could.=20
   =20
   The first Class is CreateCall which extends the standard HTTPServlet =
class=20
   and based on the parameters it retrieves, builds and sends a Half =
Pint=20
   CreateCall message. If the user has asked for confirmation of the =
create=20
   call message, a HTML redirect page is sent back to the user to refer =
the=20
   user to the servlet implemented by the third class below.=20
   =20
   The second class is a message handler that simply waits on a =
particular port=20
   (7071 in this case) and stores received half pint messages into a =
hash=20
   table.=20
   =20
   The third class is another servlet that is invoked by a redirect =
HTML Meta=20
   tag from the first servlet. It regularly checks the hash table that =
the=20
   second class is populating with received half pint messages, for the =
message=20
   that matches the transaction id of the original Half Pint message =
sent by=20
   the first class. When it finds the message it removes it from the =
hash table=20
   and informs the user that the call was created successfully.=20
   =20
   First Class =96 CreateCall=20
   ------------------------=20
   =20
   import java.io.*;=20
   import java.text.*;=20
   import java.util.*;=20
   import java.net.*;=20
   import javax.servlet.*;=20
   import javax.servlet.http.*;=20
   =20
=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


   /**=20
    * CreateCall Servlet=20
    *=20
    * Instances of this class, like all servlets, wait around for for =
their=20
   doPost or doGet=20
    * methods to be invoked after they have been initialised. doGet =
will build=20
   and send a=20
    * Half-Pint CreateCall message. doPost simply calls doGet.=20
    *=20
    */=20
   =20
   public class CreateCall extends HttpServlet {=20
   =20
   =20
   =20
    /* init method */=20
   =20
        public void init() throws ServletException {=20
   =20
   =20
        =
getServletContext().setAttribute("HalfPint.incomingMsgHndlrRunning",=20
   "No");=20
        }=20
   =20
   =20
    /* doGet method - main method of the servlet called by the Servlet =
engine=20
   or=20
        through doPost */=20
   =20
       public void doGet(HttpServletRequest request,=20
                         HttpServletResponse response)=20
           throws IOException, ServletException=20
       {=20
   =20
        PrintWriter out =3D response.getWriter();=20
        response.setContentType("text/html");=20
   =20
        /* Build the message based on the parameters and the =
environment=20
   variables.=20
           Note - transactioID's should really be created locally */=20
   =20
        CreateCallMessage ccMessage =3D new CreateCallMessage();=20
   =20
        ccMessage.halfPintVersion =3D "1.0";=20
        ccMessage.addressee =3D request.getParameter("addresse");=20
        ccMessage.transactionID =3D =
request.getParameter("transactionID");=20
        ccMessage.authenticationInfo =3D=20
   request.getParameter("authenticationInfo");=20
        ccMessage.messageType =3D "CreateCall";=20
        ccMessage.callingParty =3D =
request.getParameter("callingParty");=20
        ccMessage.calledParty =3D request.getParameter("calledParty");=20
        ccMessage.completionNotifictaion =3D=20
   request.getParameter("completionNotifictaion");=20
   =20
=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


        /* Send the message. Note some of the setup could be moved to =
init code=20
   */=20
   =20
        byte[] messageBytes =3D (ccMessage.buildMessage()).getBytes();=20
        InetAddress telephonyProxyAddress =3D =
InetAddress.getByName("X.X.X.X");=20
        int telephonyProxyPort =3D 7071;=20
        DatagramPacket packet =3D new DatagramPacket(messageBytes,=20
   messageBytes.length,=20
                                                 telephonyProxyAddress, =

   telephonyProxyPort);=20
        DatagramSocket ds =3D new DatagramSocket();=20
   =20
        ds.send( packet );=20
        ds.close();=20
   =20
        /* Is confirmation required ? */=20
   =20
        if (ccMessage.completionNotifictaion.equalsIgnoreCase("yes") |=20
   ccMessage.completionNotifictaion.equalsIgnoreCase("y") ) {=20
        /* Spawn the message waiting handler first checking to see if =
it=20
                   is already alive */=20
                if ( ((String)=20
   =
getServletContext().getAttribute("HalfPint.incomingMsgHndlrRunning")).eq=
uals
   IgnoreCase("No") ) { // there are better ways to do this=20
        =20
        =
getServletContext().setAttribute("HalfPint.incomingMsgHndlrRunning",=20
   "Yes");=20
                        IncomingHPMsgHandler incomingMsgHndlr =3D new=20
   IncomingHPMsgHandler();=20
                        Thread incomingMsgHndlrThread =3D new=20
   Thread(incomingMsgHndlr);=20
                        incomingMsgHndlrThread.start();=20
                }=20
   =20
                /* Generate the wait page */=20
                out.println("<head><title>Page to wait and check for=20
   responses</title>");=20
                out.println("<meta http-equiv=3D\"refresh\"=20
   content=3D\"2;URL=3DCreateCallConfirmationCheck?transactionID=3D" +=20
   ccMessage.transactionID + "\">");=20
                out.println("<meta name=3D\"keywords\" =
content=3D\"automatic=20
   redirection\">");=20
                out.println("</head><body>");=20
                out.println("If your browser doesn't automatically =
refresh=20
   within a few seconds");=20
                out.println("you may want check <a>=20
   href=3D\"http:XXXXXX\"</a>manually every few seconds");=20
                out.println("</body></html>");=20
   =20
       } else {=20
                /* Generate the 'job done' page */=20
                out.println("<html> <body>");=20
                out.println("<h1>Job done - call created</h1>");=20
                out.println("</html> </body>");=20
=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


        }=20
   =20
        out.close();=20
        }=20
   =20
   =20
    /* doPost method - simply calls doGet  */=20
   =20
       public void doPost(HttpServletRequest request,=20
                         HttpServletResponse response)=20
           throws IOException, ServletException=20
       {=20
           doGet(request, response);=20
       }=20
   =20
   }=20
   =20
   =20
   =20
   Second Class =96 IncomingHPMsgHandler=20
   -----------------------------------=20
   =20
   import java.net.*;=20
   =20
   /**=20
    * IncomingHPMsgHndlr=20
    *=20
    * This Class represents an object which sits around waiting for =
incoming=20
   Half-Pint messages=20
    * and then stores them so others can check them.=20
    *=20
    */=20
   =20
   public class IncomingHPMsgHandler implements Runnable {=20
   =20
    public void run() {=20
   =20
         /* Get a reference to the shared singleton ReceivedMessages =
instance=20
   */=20
         ReceivedHalfPintMsgs receivedMsgsHashtable =3D=20
   ReceivedHalfPintMsgs.getInstance();=20
   =20
         HalfPintMessage receivedMessage =3D null;=20
         DatagramSocket ds =3D null;=20
   =20
         /* Bind to port */=20
         try {=20
                 ds =3D new DatagramSocket(7071);=20
         } catch (Exception e) {=20
                 System.out.println("error opening socket in=20
   IncomingHPMsgHndlr");=20
                 return;=20
         }=20
   =20
=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


         /* When an incoming message is received store it */=20
         while (true) {=20
                 DatagramPacket packet =3D new DatagramPacket( new byte =
[1024],=20
   1024);=20
   =20
                 try {=20
                         ds.receive(packet);=20
                 } catch (Exception e) {=20
                         System.out.println("Exception is" + e);=20
                         System.out.println("error receiving packet in=20
   IncomingHPMsgHndlr");=20
                 }=20
   =20
                 receivedMessage =3D =
HalfPintMessage.createHPMessage(new=20
   String(packet.getData()));=20
   =20
                 if (receivedMessage !=3D null) {=20
                         =
receivedMsgsHashtable.addReceivedMsg(receivedMessage);=20
                 }=20
                 else=20
                     System.out.println("received message was null");=20
   =20
         }=20
    }=20
   =20
   }=20
   =20
   =20
   =20
   =20
   =20
   Third Class =96 CreateCallConfirmationCheck=20
   -----------------------------------------=20
   =20
   import java.io.*;=20
   import java.text.*;=20
   import java.util.*;=20
   import javax.servlet.*;=20
   import javax.servlet.http.*;=20
   =20
   /**=20
    * CreateCallConfirmationCheck Servlet=20
    *=20
    * Instances of this class, like all servlets, wait around for for =
their=20
   doPost or doGet=20
    * methods to be invoked after they have been initialised. doGet =
check to=20
   see if a confirmation #=20
    * has been received for the Create Call message corresponding to =
the=20
   transaction rceived.=20
    *=20
    */=20
   =20
   public class CreateCallConfirmationCheck extends HttpServlet {=20
   =20
=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


    /* doGet method - main method of the servlet called by the Servlet =
engine=20
   or=20
        through doPost */=20
   =20
       public void doGet(HttpServletRequest request,=20
                         HttpServletResponse response)=20
           throws IOException, ServletException=20
       {=20
   =20
        PrintWriter out =3D response.getWriter();=20
        response.setContentType("text/html");=20
   =20
        /* Get a reference to the shared ReceivedMessages instance */=20
        ReceivedHalfPintMsgs receivedMsgsHashtable =3D=20
   ReceivedHalfPintMsgs.getInstance();=20
   =20
        /* The message type we are expecting is a =
GeneralResponseMessage but=20
   use a HalfPint=20
           message for now in case the wrong message type was received =
*/=20
        HalfPintMessage confirmMsgReceived;=20
   =20
        /* Check hashtable to see if the confirmation message has been =
received=20
   and if it has=20
           reply that it has. If not then send a waiting page */=20
   =20
        String transactionID =3D request.getParameter("transactionID"); =

   =20
        if(transactionID =3D=3D null) {=20
                /* Problem - tell the client */=20
                out.println("<html> <body>");=20
                out.println("<h1>Error - no transaction id !!!</h1>");=20
                out.println("</html> </body>");=20
        } else=20
        {=20
                if ((confirmMsgReceived =3D=20
   receivedMsgsHashtable.getReceivedMsg(transactionID)) =3D=3D null) {=20
                        /* Generate the wait page as the confirmation =
has not=20
   been received yet */=20
                        out.println("<head><title>Page to wait and =
check for=20
   responses</title>");=20
                        out.println("<meta http-equiv=3D\"refresh\"=20
   content=3D\"2\">");=20
                        out.println("<meta name=3D\"keywords\"=20
   content=3D\"automatic redirection\">");=20
                        out.println("</head><body>");=20
                        out.println("If your browser doesn't =
automatically=20
   refresh within a few seconds");=20
                        out.println("you may want check <a>=20
   href=3D\"http:XXXXXX\"</a>manually every few seconds");=20
                        out.println("</body></html>");=20
          } else {=20
                        /* Check that the call was created successfully =
*/=20


=20
O=92Doherty                                                       Page =
1 =0A=
=0C
Internet Draft                  Half-Pint                     July 2001 =


        =20
        =
if(!(confirmMsgReceived.messageType.equalsIgnoreCase("GeneralResponse")
   )) {=20
                                // UnexpectedMessageHandling;=20
                                System.out.println("Unexected message =
when=20
   waiting for a General response to a Create Call");=20
                        } else {=20
                                /* Check to see if the received =
response is an=20
   'OK' */=20
                                GeneralResponseMessage grm =3D=20
   (GeneralResponseMessage) confirmMsgReceived;=20
                                if =
(grm.responseType.equalsIgnoreCase("ok")) {=20
                                        /* Generate the 'job done' page =
*/=20
                                        out.println("<html> <body>");=20
                                        out.println("<h1>Job done - =
call=20
   created</h1>");=20
                                        out.println("</html> </body>"); =

                                } else {=20
                                        /* Call was not created - tell =
the=20
   client */=20
                                        out.println("<html> <body>");=20
                                        out.println("<h1>Call not =
created=20
   !!!</h1>");=20
                                        out.println("<h1>Error code :" =
+ =20
   grm.responseType + "</h1>");=20
                                        out.println("</html> </body>"); =

                                }=20
                        }=20
                }=20
        }=20
   =20
        out.close();=20
   }=20
   =20
   =20
    /* doPost method - simply calls doGet  */=20
   =20
       public void doPost(HttpServletRequest request,=20
                         HttpServletResponse response)=20
           throws IOException, ServletException=20
       {=20
           doGet(request, response);=20
       }=20
   =20
   }=20
   =20
   =20
   =20
   =20
   =20
=20
=20


=20
O=92Doherty                                                       Page =
1 =0A=
=0C
------_=_NextPart_000_01C1105F.C6AE8C30--

_______________________________________________
SPIRITS mailing list
SPIRITS@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/spirits


From spirits-admin@lists.bell-labs.com  Thu Jul 19 12:48:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09669
	for <spirits-archive@odin.ietf.org>; Thu, 19 Jul 2001 12:48:50 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A14BA4434D; Thu, 19 Jul 2001 12:49:04 -0400 (EDT)
Delivered-To: spirits@share.research.bell-labs.com
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by lists.bell-labs.com (Postfix) with SMTP id F3A2644337
	for <spirits@share.research.bell-labs.com>; Thu, 19 Jul 2001 12:48:09 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Thu Jul 19 12:46:46 EDT 2001
Received: by lists.bell-labs.com (Postfix)
	id EF5F044394; Thu, 19 Jul 2001 12:33:39 -0400 (EDT)
Delivered-To: spirits@lists.bell-labs.com
Received: from hotair.hobl.lucent.com (hotair.hobl.lucent.com [199.118.135.2])
	by lists.bell-labs.com (Postfix) with SMTP
	id A69CA44392; Thu, 19 Jul 2001 12:33:38 -0400 (EDT)
Received: from bell-labs.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id MAA28208; Thu, 19 Jul 2001 12:33:34 -0400
Message-ID: <3B570BB5.93992422@bell-labs.com>
From: Igor Faynberg <faynberg@bell-labs.com>
Reply-To: faynberg@lucent.com
Organization: Lucent Technologies
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5  (Windows NT 5.0; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: spirits@lists.bell-labs.com
Cc: pint@lists.bell-labs.com, sob@harvard.edu, smb@research.att.com
Subject: Re: [SPIRITS] Half-Pint
References: <A3C2399B2FACD411A54200508BE39C7401EDF4E1@zwcwd00r.europe.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: spirits-admin@lists.bell-labs.com
Errors-To: spirits-admin@lists.bell-labs.com
X-BeenThere: spirits@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:spirits-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:spirits@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/spirits>, <mailto:spirits-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SPIRITS Working Group <spirits.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/spirits>, <mailto:spirits-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/spirits/
Date: Thu, 19 Jul 2001 12:32:53 -0400
Content-Transfer-Encoding: 7bit

Mick,

Actually, the PINT mailing list (copied here) remains open for the
discussion. Yet, the scope of your draft, which I had read with
interest, also includes SPIRITS--in my opinion--inasmuch as it discusses
notifications. (By the way, for some reason, your draft makes no
references to any of the PINT or SPIRITS RFCs, nor does it reference
ther architecture.)

You explain the draft as a "ligthweight, restricted take on the
functionality provided by the PINT protocol)," but I think that what
draft describes is effectively an API, not a protocol, and at that it
extends rather than restricts the present PINT services. [You may want
to look at an earlier draft by Lev Slutsman (lslutsman@att.com), which
you could obtain from him directly, since it expired, where he proposed
the requirements for PINT conference calling.] I would not call the API
you describe  "half-PINT"; to me it really looks like "seven-PINT"
(e.g., you describe capabilities for much more than ordering a two-party
call or sending fax from the web).

I use the word API, because what you describe is primitives and
parameters for invoking the services. The protocol, on the other hand,
would address the transport of the information among the involved
entities  (hence the need for the architecture). 

Finally, your draft does not have a security section, and does not
mention security at all, which is again an indication that the
application interface (rather than the protocol) is being discussed.

Having said all that, I believe that your draft presents an interesting
and potentially useful set of framework requirements that would allow to
re-use the existing PINT and in-progress SPIRITS building blocks to
deliver many new services while using the existing protocol.
(Incidentally, SIP was chosen as PINT transport vehicle primarily
because it had already solved security and addressing problems.)

Personally, I would like your work to progress. I would suggest that you
look at the PINT protocol RFC and the present SPIRITS requirements and
see whether the existing protocol could satisfy the requirements of your
API. If not, you should suggest modifications. Then, if Lawrence Conroy
and Scott Petrack agree, the PINT protocol could be extended. At the
same time, if the SPIRITS chairmen agree, the SPIRITS could take your
work in account, too.

Note that PINT has been already implemented as is. (And, in addition,
there are PINT-like services supported by other protocols.)

Respectfully,

Igor Faynberg



> Michael O'Doherty wrote:
> 
> Hi,
> 
> I have submitted a new draft entitled 'Half-Pint' which as the name
> (kind of ...) suggests is a lightweight, restricted take on the
> functionality provided by the PINT protocol.
> 
> The idea is to try to hit the high runner things that web developers
> wanting to integrate web applications with the PSTN want to do right
> now, and make it available in a way that web developers are familiar
> with and can work with right away.
> 
> The natural place to discuss this would have been the PINT group, but
> unfortunately it is not around anymore, so I'm sending this notice
> onto to some other groups that may be interested in this type of thing
> to get feedback and comments.
> 
> Cheers,
> 
> Mick O'Doherty.
> 
> P.S. I've attached the draft to this email as the version in the
> archives has picked up a few formatting errors somehow and is not
> quite fixed up yet.
> 
> <<draft-odoherty-half-pint-00.txt>>
> 
>                                       Name: draft-odoherty-half-pint-00.txt
>    draft-odoherty-half-pint-00.txt    Type: Plain Text (text/plain)
>                                   Encoding: quoted-printable

_______________________________________________
SPIRITS mailing list
SPIRITS@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/spirits


From spirits-admin@lists.bell-labs.com  Fri Jul 20 10:50:37 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25105
	for <spirits-archive@odin.ietf.org>; Fri, 20 Jul 2001 10:50:37 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 536B144343; Fri, 20 Jul 2001 10:50:06 -0400 (EDT)
Delivered-To: spirits@lists.bell-labs.com
Received: from znsgs0ja.europe.nortel.com (unknown [47.165.25.40])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6BBAB44337; Fri, 20 Jul 2001 10:49:07 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f6KEn6g21433;
	Fri, 20 Jul 2001 15:49:06 +0100 (BST)
Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com;
          Fri, 20 Jul 2001 15:48:50 +0100
Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PF5JJTP4>; Fri, 20 Jul 2001 15:48:49 +0100
Message-ID: <A3C2399B2FACD411A54200508BE39C7401EDF4F8@zwcwd00r.europe.nortel.com>
From: "Michael O'Doherty" <mdoherty@nortelnetworks.com>
To: "'faynberg@lucent.com'" <faynberg@lucent.com>, spirits@lists.bell-labs.com
Cc: pint@lists.bell-labs.com, sob@harvard.edu, smb@research.att.com
Subject: RE: [SPIRITS] Half-Pint
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1112B.1685D4E0"
Sender: spirits-admin@lists.bell-labs.com
Errors-To: spirits-admin@lists.bell-labs.com
X-BeenThere: spirits@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
Reply-To: spirits@lists.bell-labs.com
List-Help: <mailto:spirits-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:spirits@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/spirits>, <mailto:spirits-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SPIRITS Working Group <spirits.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/spirits>, <mailto:spirits-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/spirits/
Date: Fri, 20 Jul 2001 15:48:50 +0100

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1112B.1685D4E0
Content-Type: text/plain;
	charset="iso-8859-1"

Igor,

Thanks for the comments and good to see the PINT list still exists.

The idea with Half-Pint was that the protocol is happy to be transported on
whatever is available - we have tested it using UDP, but anything that can
wrap it up and deliver it to a Half-Pint parser should be fine.

To keep it as simple as possible we wanted to avoid making it necessary to
run it with SIP and SDP also, but as you point out it may be worth looking
at how it could be combined with this type of approach if people think this
would be useful. If others are interested in this, let me know.

I've added some other answers in line below.

Cheers,

Mick.

P.S. I think this thread is probably interesting to both Pint and Spirits,
but if anybody is concerned with the cross-posting let me know.

-----Original Message-----
From: Igor Faynberg [mailto:faynberg@bell-labs.com]
Sent: 19 July 2001 17:33
To: spirits@lists.bell-labs.com
Cc: pint@lists.bell-labs.com; sob@harvard.edu; smb@research.att.com
Subject: Re: [SPIRITS] Half-Pint


Mick,

Actually, the PINT mailing list (copied here) remains open for the
discussion. Yet, the scope of your draft, which I had read with
interest, also includes SPIRITS--in my opinion--inasmuch as it discusses
notifications. (By the way, for some reason, your draft makes no
references to any of the PINT or SPIRITS RFCs, nor does it reference
ther architecture.)

>>>>  Oppps - those references should definitely be in there ...

You explain the draft as a "ligthweight, restricted take on the
functionality provided by the PINT protocol)," but I think that what
draft describes is effectively an API, not a protocol, and at that it
extends rather than restricts the present PINT services. [You may want
to look at an earlier draft by Lev Slutsman (lslutsman@att.com), which
you could obtain from him directly, since it expired, where he proposed
the requirements for PINT conference calling.] I would not call the API
you describe  "half-PINT"; to me it really looks like "seven-PINT"
(e.g., you describe capabilities for much more than ordering a two-party
call or sending fax from the web).

I use the word API, because what you describe is primitives and
parameters for invoking the services. The protocol, on the other hand,
would address the transport of the information among the involved
entities  (hence the need for the architecture). 

>>>> Not sure about this - still seems like a protocol to me, but I know
what you are saying here so the label is not too important. I take your
point about the half-Pint vs. Seven Pint name - I guess we thinking more of
its 'quick and simple' rather than flexible and scalable approach (the good
think about Pint is it allows lots of interesting names for related
protocols ...).

Finally, your draft does not have a security section, and does not
mention security at all, which is again an indication that the
application interface (rather than the protocol) is being discussed.

>>>> Security is obviously very important for this type of application - the
intent is to use the authorization info field to convey enough information
to allow the receiver of the message identify and verify the sender. We
haven't fixed on the best way top do this yet which is why it was left for
further study for now (although it is a 'must' so needs to be addressed
ASAP). I am assuming this is the type of security you mean rather than
message encryption etc which I hadn't really given much thought to.

Having said all that, I believe that your draft presents an interesting
and potentially useful set of framework requirements that would allow to
re-use the existing PINT and in-progress SPIRITS building blocks to
deliver many new services while using the existing protocol.
(Incidentally, SIP was chosen as PINT transport vehicle primarily
because it had already solved security and addressing problems.)

Personally, I would like your work to progress. I would suggest that you
look at the PINT protocol RFC and the present SPIRITS requirements and
see whether the existing protocol could satisfy the requirements of your
API. If not, you should suggest modifications. Then, if Lawrence Conroy
and Scott Petrack agree, the PINT protocol could be extended. At the
same time, if the SPIRITS chairmen agree, the SPIRITS could take your
work in account, too.

Note that PINT has been already implemented as is. (And, in addition,
there are PINT-like services supported by other protocols.)

Respectfully,

Igor Faynberg


------_=_NextPart_001_01C1112B.1685D4E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [SPIRITS] Half-Pint</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Igor,</FONT>
</P>

<P><FONT SIZE=3D2>Thanks for the comments and good to see the PINT list =
still exists.</FONT>
</P>

<P><FONT SIZE=3D2>The idea with Half-Pint was that the protocol is =
happy to be transported on whatever is available - we have tested it =
using UDP, but anything that can wrap it up and deliver it to a =
Half-Pint parser should be fine.</FONT></P>

<P><FONT SIZE=3D2>To keep it as simple as possible we wanted to avoid =
making it necessary to run it with SIP and SDP also, but as you point =
out it may be worth looking at how it could be combined with this type =
of approach if people think this would be useful. If others are =
interested in this, let me know.</FONT></P>

<P><FONT SIZE=3D2>I've added some other answers in line below.</FONT>
</P>

<P><FONT SIZE=3D2>Cheers,</FONT>
</P>

<P><FONT SIZE=3D2>Mick.</FONT>
</P>

<P><FONT SIZE=3D2>P.S. I think this thread is probably interesting to =
both Pint and Spirits, but if anybody is concerned with the =
cross-posting let me know.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Igor Faynberg [<A =
HREF=3D"mailto:faynberg@bell-labs.com">mailto:faynberg@bell-labs.com</A>=
]</FONT>
<BR><FONT SIZE=3D2>Sent: 19 July 2001 17:33</FONT>
<BR><FONT SIZE=3D2>To: spirits@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2>Cc: pint@lists.bell-labs.com; sob@harvard.edu; =
smb@research.att.com</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [SPIRITS] Half-Pint</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Mick,</FONT>
</P>

<P><FONT SIZE=3D2>Actually, the PINT mailing list (copied here) remains =
open for the</FONT>
<BR><FONT SIZE=3D2>discussion. Yet, the scope of your draft, which I =
had read with</FONT>
<BR><FONT SIZE=3D2>interest, also includes SPIRITS--in my =
opinion--inasmuch as it discusses</FONT>
<BR><FONT SIZE=3D2>notifications. (By the way, for some reason, your =
draft makes no</FONT>
<BR><FONT SIZE=3D2>references to any of the PINT or SPIRITS RFCs, nor =
does it reference</FONT>
<BR><FONT SIZE=3D2>ther architecture.)</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&gt;&gt;&gt;&nbsp; Oppps - those references =
should definitely be in there ...</FONT>
</P>

<P><FONT SIZE=3D2>You explain the draft as a &quot;ligthweight, =
restricted take on the</FONT>
<BR><FONT SIZE=3D2>functionality provided by the PINT protocol),&quot; =
but I think that what</FONT>
<BR><FONT SIZE=3D2>draft describes is effectively an API, not a =
protocol, and at that it</FONT>
<BR><FONT SIZE=3D2>extends rather than restricts the present PINT =
services. [You may want</FONT>
<BR><FONT SIZE=3D2>to look at an earlier draft by Lev Slutsman =
(lslutsman@att.com), which</FONT>
<BR><FONT SIZE=3D2>you could obtain from him directly, since it =
expired, where he proposed</FONT>
<BR><FONT SIZE=3D2>the requirements for PINT conference calling.] I =
would not call the API</FONT>
<BR><FONT SIZE=3D2>you describe&nbsp; &quot;half-PINT&quot;; to me it =
really looks like &quot;seven-PINT&quot;</FONT>
<BR><FONT SIZE=3D2>(e.g., you describe capabilities for much more than =
ordering a two-party</FONT>
<BR><FONT SIZE=3D2>call or sending fax from the web).</FONT>
</P>

<P><FONT SIZE=3D2>I use the word API, because what you describe is =
primitives and</FONT>
<BR><FONT SIZE=3D2>parameters for invoking the services. The protocol, =
on the other hand,</FONT>
<BR><FONT SIZE=3D2>would address the transport of the information among =
the involved</FONT>
<BR><FONT SIZE=3D2>entities&nbsp; (hence the need for the =
architecture). </FONT>
</P>

<P><FONT SIZE=3D2>&gt;&gt;&gt;&gt; Not sure about this - still seems =
like a protocol to me, but I know what you are saying here so the label =
is not too important. I take your point about the half-Pint vs. Seven =
Pint name - I guess we thinking more of its 'quick and simple' rather =
than flexible and scalable approach (the good think about Pint is it =
allows lots of interesting names for related protocols ...).</FONT></P>

<P><FONT SIZE=3D2>Finally, your draft does not have a security section, =
and does not</FONT>
<BR><FONT SIZE=3D2>mention security at all, which is again an =
indication that the</FONT>
<BR><FONT SIZE=3D2>application interface (rather than the protocol) is =
being discussed.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&gt;&gt;&gt; Security is obviously very important =
for this type of application - the intent is to use the authorization =
info field to convey enough information to allow the receiver of the =
message identify and verify the sender. We haven't fixed on the best =
way top do this yet which is why it was left for further study for now =
(although it is a 'must' so needs to be addressed ASAP). I am assuming =
this is the type of security you mean rather than message encryption =
etc which I hadn't really given much thought to.</FONT></P>

<P><FONT SIZE=3D2>Having said all that, I believe that your draft =
presents an interesting</FONT>
<BR><FONT SIZE=3D2>and potentially useful set of framework requirements =
that would allow to</FONT>
<BR><FONT SIZE=3D2>re-use the existing PINT and in-progress SPIRITS =
building blocks to</FONT>
<BR><FONT SIZE=3D2>deliver many new services while using the existing =
protocol.</FONT>
<BR><FONT SIZE=3D2>(Incidentally, SIP was chosen as PINT transport =
vehicle primarily</FONT>
<BR><FONT SIZE=3D2>because it had already solved security and =
addressing problems.)</FONT>
</P>

<P><FONT SIZE=3D2>Personally, I would like your work to progress. I =
would suggest that you</FONT>
<BR><FONT SIZE=3D2>look at the PINT protocol RFC and the present =
SPIRITS requirements and</FONT>
<BR><FONT SIZE=3D2>see whether the existing protocol could satisfy the =
requirements of your</FONT>
<BR><FONT SIZE=3D2>API. If not, you should suggest modifications. Then, =
if Lawrence Conroy</FONT>
<BR><FONT SIZE=3D2>and Scott Petrack agree, the PINT protocol could be =
extended. At the</FONT>
<BR><FONT SIZE=3D2>same time, if the SPIRITS chairmen agree, the =
SPIRITS could take your</FONT>
<BR><FONT SIZE=3D2>work in account, too.</FONT>
</P>

<P><FONT SIZE=3D2>Note that PINT has been already implemented as is. =
(And, in addition,</FONT>
<BR><FONT SIZE=3D2>there are PINT-like services supported by other =
protocols.)</FONT>
</P>

<P><FONT SIZE=3D2>Respectfully,</FONT>
</P>

<P><FONT SIZE=3D2>Igor Faynberg</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1112B.1685D4E0--

_______________________________________________
SPIRITS mailing list
SPIRITS@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/spirits


From spirits-admin@lists.bell-labs.com  Sat Jul 21 20:29:09 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25821
	for <spirits-archive@odin.ietf.org>; Sat, 21 Jul 2001 20:29:08 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 71BAD4433C; Sat, 21 Jul 2001 20:30:03 -0400 (EDT)
Delivered-To: spirits@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by lists.bell-labs.com (Postfix) with SMTP id E7DED44339
	for <spirits@share.research.bell-labs.com>; Sat, 21 Jul 2001 20:29:15 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Sat Jul 21 20:24:47 EDT 2001
Received: by lists.bell-labs.com (Postfix)
	id E49CA44393; Sat, 21 Jul 2001 20:14:50 -0400 (EDT)
Delivered-To: spirits@lists.bell-labs.com
Received: from ih2mail.ih.lucent.com (ih2mail.ih.lucent.com [135.1.241.39])
	by lists.bell-labs.com (Postfix) with ESMTP id 46F5944392
	for <spirits@lists.bell-labs.com>; Sat, 21 Jul 2001 20:14:50 -0400 (EDT)
Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id TAA11148; Sat, 21 Jul 2001 19:14:47 -0500 (CDT)
Message-ID: <3B5A1BAA.A1AF06D8@lucent.com>
From: Alec Brusilovsky <abrusilovsky@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en,ru,uk
MIME-Version: 1.0
To: SPIRITS list <spirits@lists.bell-labs.com>
Content-Type: multipart/mixed;
 boundary="------------834A56CFFAC18A4005E4329C"
Subject: [SPIRITS] Agenda for London meeting
Sender: spirits-admin@lists.bell-labs.com
Errors-To: spirits-admin@lists.bell-labs.com
X-BeenThere: spirits@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
Reply-To: spirits@lists.bell-labs.com
List-Help: <mailto:spirits-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:spirits@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/spirits>, <mailto:spirits-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SPIRITS Working Group <spirits.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/spirits>, <mailto:spirits-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/spirits/
Date: Sat, 21 Jul 2001 19:17:46 -0500

This is a multi-part message in MIME format.
--------------834A56CFFAC18A4005E4329C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ladies and Gentlemen,

Kindly find below our proposed agenda for the London
meeting:

Date: Tuesday, August 7, 2001
Time: 13:00-14:00

1. Opening and goals of the session - Alec Brusilovsky
- 5 min.
2. Collaboration with ITU-T - Hui-Lan Lu - 5 min.
3. On the Protocol Requirements - Igor Faynberg - 5 min
4. Discussion of the needed components for the
SPIRITS protocol - 35 min.
5. On selection of IN parameters to be carried by the
SPIRITS
Protocol (only if time allows and for information purposes
only)
- Musa Unmehopa - 10 minutes

Please let me know if you have any burning issues that need
to be on the agenda.

Regards,
Alec

P.S. There are two new I-Ds available from the IETF
directory:
http://www.ietf.org/internet-drafts/draft-ietf-spirits-in-00.txt

http://www.ietf.org/internet-drafts/draft-unmehopa-spirits-parameters-00.txt





--------------834A56CFFAC18A4005E4329C
Content-Type: text/x-vcard; charset=us-ascii;
 name="abrusilovsky.vcf"
Content-Description: Card for Alec Brusilovsky
Content-Disposition: attachment;
 filename="abrusilovsky.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Brusilovsky;Alec 
tel;fax:+1 630 713 5840 
tel;work:+1 630 713 8401
x-mozilla-html:FALSE
org:e-Services Group;Next Generation Evolution and Architecture
version:2.1
email;internet:abrusilovsky@lucent.com
title:MTS 
adr;quoted-printable:;;IHP 1A-423=0D=0A263 Shuman Blvd,P O Box 3050;Naperville;IL;60566-7050;U S
x-mozilla-cpt:;5312
fn:Alec  Brusilovsky
end:vcard

--------------834A56CFFAC18A4005E4329C--


_______________________________________________
SPIRITS mailing list
SPIRITS@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/spirits