From extest-admin@lists.bell-labs.com  Sun Oct  1 06:18:54 2000
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 GAA07684
	for <iptel-archive@odin.ietf.org>; Sun, 1 Oct 2000 06:18:54 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 33FC2444C4
	for <iptel-archive@lists.ietf.org>; Sun,  1 Oct 2000 05:06:35 -0400 (EDT)
Subject: lists.bell-labs.com mailing list memberships reminder
From: mailman-owner@lists.bell-labs.com
To: iptel-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: <20001001090635.33FC2444C4@lists.bell-labs.com>
Date: Sun,  1 Oct 2000 05:06:35 -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, iptel-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 iptel-archive@lists.ietf.org:

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


From iptel-admin@lists.bell-labs.com  Mon Oct  2 00:56:03 2000
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 AAA19092
	for <iptel-archive@odin.ietf.org>; Mon, 2 Oct 2000 00:56:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8DFE444337; Sun,  1 Oct 2000 23:56:01 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 9E9D044336
	for <iptel@lists.bell-labs.com>; Sun,  1 Oct 2000 23:55:29 -0400 (EDT)
Received: from eagle (1Cust97.tnt2.freehold.nj.da.uu.net [63.17.114.97])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id AAA01946;
	Mon, 2 Oct 2000 00:57:23 -0400 (EDT)
From: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
To: "'Jonathan Lennox'" <lennox@cs.columbia.edu>, <iptel@lists.bell-labs.com>
Subject: RE: [IPTEL] CPL time ranges
Message-ID: <000201c02c2d$29e38160$e69ffea9@dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <14805.10812.864120.484144@conrail.cs.columbia.edu>
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 2 Oct 2000 00:56:44 -0400
Content-Transfer-Encoding: 7bit

Good work. Nearly as I can tell, this seems to work. I'd feel a lot better
if there were running code. Step 4 might be a bit tricky to actually
compute, for example, but I think it can be done.

So, we now have the following on the table:

1. a potential working algorithm for a reasonable subset of iCal that runs
in O(1)
2. a few folks joining in on the side of iCal (Jay, EmmanueL)
3. Henning standing firm on iCal, Jonathan it seems also supporting his
proposed subset of iCal
4. James supporting crontab on his last post
5. myself on the fence now

Rough consensus would now seem to support an iCal subset. Running code is
not entirely there, and I suspect it won't be in time for this to move
forward swiftly. As a result, I am now proposing the following:

*IFF* it can be demonstrated that this algorithm works on at least four
example time switches of reasonable complexity, we move forward with this
proposal. To prove correctness, you take a time-switch <time> statement, a
call time, and write out the outputs of each of the steps, explaining in
English how they were arrived at. This exercise (which Jonathan likely did
in any case) will help increase confidence in the correctness of this
algorithm. I think it would also make good text for the specification.

I'd REALLY like to see such a posting in the next few days, hopefully before
WEDNESDAY. Assuming such examples do appear, and no one else switches sides
again or jumps on board in favor of crontab, we'll (hopefully) declare this
closed once and for all and move on with the other open issues in CPL.

Thanks,
Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

> -----Original Message-----
> From: Jonathan Lennox [mailto:lennox@cs.columbia.edu]
> Sent: Friday, September 29, 2000 7:48 PM
> To: iptel@lists.bell-labs.com
> Subject: Re: [IPTEL] CPL time ranges
>
>
> On Thursday, September 28 2000, "Jonathan Lennox" wrote to
> "Henning Schulzrinne, iptel@lists.bell-labs.com" saying:
>
> > I believe a somewhat broader iCal subset will be able to represent
> > all, or almost all, of these attributes naturally, and
> still be resolvable
> > in O(1) time with respect to (now - dtstart); more
> information will be
> > forthcoming soon.
>
> Here it is.  This handles almost all of iCal -- and, I
> believe, all its
> *useful* parts -- in O(1) time.
>
> No running code yet, though implementation of this algorithm should be
> straightforward.
>
> "Beware of bugs in the above code.  I have only proven it
> correct; I haven't
> tried it yet." -- Donald Knuth
>
> Comments *very* welcome.
>
> --
> Jonathan Lennox
> lennox@cs.columbia.edu
>
>


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Mon Oct  2 18:40:04 2000
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 SAA15162
	for <iptel-archive@odin.ietf.org>; Mon, 2 Oct 2000 18:40:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D18D444365; Mon,  2 Oct 2000 17:40:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3FFBE44338; Mon,  2 Oct 2000 17:39:24 -0400 (EDT)
Received: from fokus.gmd.de (dhcp082 [195.37.78.210])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id AAA10539;
	Tue, 3 Oct 2000 00:38:48 +0200 (MET DST)
Message-ID: <39D90E55.217B38D@fokus.gmd.de>
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Organization: GMD Fokus
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: kuthan@fokus.gmd.de
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Subject: [IPTEL] iptel2001 Call for Papers
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 03 Oct 2000 00:38:13 +0200
Content-Transfer-Encoding: 8bit


                            Call for Papers

                         2nd IP Telephony Workshop
	  
            April 2-3, 2001 - Columbia University, New York City
                 http://www.fokus.gmd.de/events/iptel2001/


Objectives
---------- 
Internet telephony is rapidly evolving from research to design
and deployment. The objectives of the IP Telephony Workshop are
to bring together researchers, developers, vendors and service 
providers active in this area and stimulate discussion on 
innovation, research, implementation, deployment experiences and
future directions.

Scope & Topics 
--------------
Original technical articles related to IP telephony are solicited. 
Only papers with significant technical content, not "white papers"
or tutorials, will be considered for publication:

     - Research papers (unique ideas, novel algorithms, 
       architectures, measurements, theoretical and/or analytical 
       contributions) 
     - Surveys, state-of-the-art studies, technology comparisons 
     - Implementation and deployment reports 
     - Standardization reports 

Particular areas of interest include, but are not limited to, the
following: 

     - Integration with Internet services (e.g., web, instant 
       messaging, games) 
     - Added-value services (e.g., call centers, conferencing) 
     - Mobility and 3rd generation wireless 
     - Authentication, authorization, accounting, charging, 
       settlement
     - QoS support 
     - Security (e.g., privacy, authentication, certification 
       authorities, firewall traversal) 
     - Call signaling & processing 
     - Feature creation 
     - Supporting services (e.g., call routing, lookup services) 
     - Audio & video encoding and transmission 
     - Management and provisioning 
     - Interworking with the PSTN 
     - Design and deployment considerations (e.g., performance, 
       scalability, reliability) 

Important Dates
--------------- 
Full paper due                November 27th, 2000
Notification of acceptance    January 12th, 2001
Final version due             January 31st, 2001
Program published and         February 5th, 2001
registration opens
Workshop                      April 2nd-3rd, 2001

iptel2001 Organizing Committee 
------------------------------
Program Chair         
 H. Schulzrinne       Columbia University 
Program Committee 
 M. Arango            Sun Microsystems
 F. Baker             Cisco
 W. Bauerfeld         T-Nova
 G. Bond              AT&T Research
 S. Bradner           Harvard University
 G. Carle             GMD FOKUS
 J. Crowcroft         UCL
 C. Huitema           Microsoft
 G. S. Kuo            National Central University, Taiwan
 J. Kuthan            GMD Fokus
 T. Magedanz          IKV++ GmbH
 W. Marshall          AT&T Research
 K. Mehdi             University of Kansas
 D. Oran              Cisco
 J. Ott               University of Bremen
 T. La Porta          Bell Labs
 B. Rosen             Marconi
 J. Rosenberg         dynamicsoft
 H. Sinnreich         MCI WorldCom
 R. Steinmetz         Technical University of Darmstadt
 H. Stüttgen          NEC CCRLE
 W. Wimmreuter        Siemens
 L. Wolf              University of Karlsruhe
 A. Wolisz            Technical University of Berlin
 M. Zitterbart        Technical University of Braunschweig 

Submission Instructions 
-----------------------
Authors are invited to submit full papers written in English 
before November 27th, 2000. The submissions will be reviewed, and
accepted papers will be included in the program. Notifications of
acceptance will be sent out on January 12th, 2000. Deadline for 
submission of camera-ready copies is January 31st, 2001. Authors 
of accepted papers will need to sign a Copyright Transfer Form and
submit a Netbib entry. 

Papers must be submitted electronically using the Web site at
          http://www.cs.columbia.edu/iptel
Submissions must be in PDF or Postscript; any other documents 
cannot be accepted. Postscript papers must use only standard 
PostScript fonts: Times Roman, Courier, Symbol, and Helvetica. 
Papers must be formatted according to the IEEE Transactions format
except for the font size, which MUST be 11pt. Templates are 
available at the Web site
          http://www.fokus.gmd.de/events/iptel2001/cfp/ 
Because of the size limitation on the final manuscript, and to 
ensure that the reviewed paper and the final version have a 
similar size, papers with more than 11 pages cannot be reviewed.
Submissions must include: title, authors, affiliation, abstract, 
list of keywords, and contact information. One of the authors of 
each accepted paper must present the paper at iptel'2001. 

Contact Address
---------------
Please, send all your inquiries regarding iptel2001 to 
               iptel2001@egroups.com.

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Oct  4 12:23:02 2000
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 MAA24894
	for <iptel-archive@odin.ietf.org>; Wed, 4 Oct 2000 12:23:02 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id DADB9443B1; Wed,  4 Oct 2000 11:23:01 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from unity-mail.icomverse.com (unknown [199.203.140.35])
	by lists.bell-labs.com (Postfix) with ESMTP id 3969744362
	for <iptel@lists.bell-labs.com>; Wed,  4 Oct 2000 11:22:47 -0400 (EDT)
Received: by unity-mail.icomverse.com with Internet Mail Service (5.5.2650.21)
	id <TXHMRQAX>; Wed, 4 Oct 2000 19:22:39 +0300
Message-ID: <479518ED4F21D411B46D0030480035BC279CE5@unity-mail.icomverse.com>
From: "Amar, Yigal" <Yigal_Amar@icomverse.com>
To: iptel@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="windows-1255"
Subject: [IPTEL] h323 and Video
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 4 Oct 2000 19:22:28 +0300

Hi ,

I have two question , and I hope this is the right place to ask ..

1)  why is it that video codecs do not require jitter buffering while audio
codecs do ??

2) I'm cupturing a H.261 video stream and writing it to a file , when
transmiting/playing back  the 
    h.261 frames from the file, I need to indicate that the first frame is
an " I frame " , or else the playback is fuzzy.
    How do I do that  ? is it in the h.261 header or RTP header ??



Thanks in advance

	

Yigal Amar 
972-3-645-4175 
yigal_amar@icomverse.com 



_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Oct  4 23:34:01 2000
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 XAA09239
	for <iptel-archive@odin.ietf.org>; Wed, 4 Oct 2000 23:34:01 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C170844362; Wed,  4 Oct 2000 22:34:01 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from avmail.smithmicro.com (avmail.smithmicro.com [209.218.67.201])
	by lists.bell-labs.com (Postfix) with ESMTP id 7650C4433A
	for <iptel@lists.bell-labs.com>; Wed,  4 Oct 2000 20:20:48 -0400 (EDT)
Received: by AVMAIL with Internet Mail Service (5.5.2650.21)
	id <T6YFPLDS>; Wed, 4 Oct 2000 18:19:22 -0700
Received: from plong (plong.aus.tx.bbnow.net [24.219.94.194]) by avmail.smithmicro.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id T6YFPLDR; Wed, 4 Oct 2000 18:19:19 -0700
From: Paul Long <Plong@smithmicro.com>
To: iptel@lists.bell-labs.com
Cc: paulej@packetizer.com
Subject: RE: [IPTEL] h323 and Video
Message-ID: <NEBBJPMBKLHPBLLJLOBDKEMKCGAA.plong@smithmicro.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <479518ED4F21D411B46D0030480035BC279CE5@unity-mail.icomverse.com>
Importance: Normal
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 4 Oct 2000 20:20:37 -0500
Content-Transfer-Encoding: 7bit

Yigal,

1) JItter buffers are not required by either audio or video, would benefit
both, but benefit audio the most because of the more ephemeral nature of
audio. Receiver-generated jitter estimates are very useful to a video
encoder and media scheduler. B.14.3/H.245v5 describes the semantics for the
JitterIndication messages as typically applied to a video channel, and SR/RR
interarrival jitter described in RFC 1889 is media neutral. Also check out
sections 4.2 and 4.3 in
http://www.kashpureff.org/nic/drafts/draft-ietf-mmusic-confarch-00.txt.html
and especially section 7.3 in
http://www.tik.ee.ethz.ch/~cobrow/deliverables/d3-2/d3-2.html.

2) Whether a frame is INTER or INTRA is indicated in the MTYPE field within
the H.261 data stream (see Table 2 in the H.261 Recommendation). But a frame
is either an INTER or INTRA frame inherently and cannot be converted from
one to the other simply by changing the MTYPE, so I wouldn't try to modify
the stream. If the first frame you recorded is not an INTRA because, for
example, it got lost in transmission, you might want to search the video
stream for the first INTRA and discard all frames up to that point before
re-transmission/playback.

Hope that helps.

Paul Long
Smith Micro Software, Inc.

-----Original Message-----
From: iptel-admin@lists.bell-labs.com
[mailto:iptel-admin@lists.bell-labs.com]On Behalf Of Amar, Yigal
Sent: Wednesday, October 04, 2000 11:22 AM
To: iptel@lists.bell-labs.com
Subject: [IPTEL] h323 and Video


Hi ,

I have two question , and I hope this is the right place to ask ..

1)  why is it that video codecs do not require jitter buffering while audio
codecs do ??

2) I'm cupturing a H.261 video stream and writing it to a file , when
transmiting/playing back  the
    h.261 frames from the file, I need to indicate that the first frame is
an " I frame " , or else the playback is fuzzy.
    How do I do that  ? is it in the h.261 header or RTP header ??



Thanks in advance



Yigal Amar
972-3-645-4175
yigal_amar@icomverse.com

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Oct  5 09:20:06 2000
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 JAA28430
	for <iptel-archive@odin.ietf.org>; Thu, 5 Oct 2000 09:20:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3C7C044405; Thu,  5 Oct 2000 08:20:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from bettina.informatik.uni-bremen.de (bettina.informatik.uni-bremen.de [134.102.224.3])
	by lists.bell-labs.com (Postfix) with ESMTP id D32FF4433D
	for <iptel@lists.bell-labs.com>; Thu,  5 Oct 2000 03:35:43 -0400 (EDT)
Received: from cabo3 (dienstmann.informatik.uni-bremen.de [134.102.218.46])
	by bettina.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id e958ZYg11870;
	Thu, 5 Oct 2000 10:35:35 +0200 (MET DST)
From: "Dr. Carsten Bormann" <cabo@tzi.org>
To: "Paul Long" <Plong@smithmicro.com>, <iptel@lists.bell-labs.com>
Cc: <paulej@packetizer.com>
Subject: RE: [IPTEL] h323 and Video
Message-ID: <NDBBLDHFKCPEPDKNKJBKAEGGEMAA.cabo@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <NEBBJPMBKLHPBLLJLOBDKEMKCGAA.plong@smithmicro.com>
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 5 Oct 2000 10:35:33 +0200
Content-Transfer-Encoding: 8bit

One minor comment:

>
http://www.kashpureff.org/nic/drafts/draft-ietf-mmusic-confarch-00.txt.html

The most recent version of this document is at:

http://search.ietf.org/internet-drafts/draft-ietf-mmusic-confarch-03.txt

Also, you can find a printed version in

%A Mark Handley
%A Jon Crowcroft
%A Carsten Bormann
%A Jörg Ott
%T Very Large Conferences on the Internet: The Internet Multimedia
Conferencing Architecture
%J Computer Networks
%V 31
%N 3
%D February 1999
%P 191-204

Gruesse, Carsten


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Oct  5 09:55:04 2000
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 JAA29188
	for <iptel-archive@odin.ietf.org>; Thu, 5 Oct 2000 09:55:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BEDBD4440B; Thu,  5 Oct 2000 08:55:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from unity-mail.icomverse.com (unknown [199.203.140.35])
	by lists.bell-labs.com (Postfix) with ESMTP id B3F494433D
	for <iptel@lists.bell-labs.com>; Thu,  5 Oct 2000 08:54:25 -0400 (EDT)
Received: by unity-mail.icomverse.com with Internet Mail Service (5.5.2650.21)
	id <TXHMRQ2R>; Thu, 5 Oct 2000 16:54:13 +0300
Message-ID: <479518ED4F21D411B46D0030480035BC279CE7@unity-mail.icomverse.com>
From: "Amar, Yigal" <Yigal_Amar@icomverse.com>
To: "'Paul Long'" <Plong@smithmicro.com>, iptel@lists.bell-labs.com
Subject: RE: [IPTEL] h323 and Video
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="windows-1255"
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 5 Oct 2000 16:54:10 +0300

Hi Paul,

Thanks for your answers
I'm reading now the links that you send.
As for the second question ,I understand now that I can't modify the MTYPE
of the first frame just like that. I can't also discard all frames up to
first INTRA
because I've look in the H.261 standard and it allowed up to 132 "P frames"
after one INTRA frame,
which is 13 seconds in a 10fps rate - not good.

I think I saw something in H.245 that says to the far endpoint to generate
an INTRA frame
I need to read more about it.

Thanks 



> -----Original Message-----
> From: Paul Long [mailto:Plong@smithmicro.com]
> Sent: Thursday, October 05, 2000 3:21 AM
> To: iptel@lists.bell-labs.com
> Cc: paulej@packetizer.com
> Subject: RE: [IPTEL] h323 and Video
> 
> 
> Yigal,
> 
> 1) JItter buffers are not required by either audio or video, 
> would benefit
> both, but benefit audio the most because of the more 
> ephemeral nature of
> audio. Receiver-generated jitter estimates are very useful to a video
> encoder and media scheduler. B.14.3/H.245v5 describes the 
> semantics for the
> JitterIndication messages as typically applied to a video 
> channel, and SR/RR
> interarrival jitter described in RFC 1889 is media neutral. 
> Also check out
> sections 4.2 and 4.3 in
> http://www.kashpureff.org/nic/drafts/draft-ietf-mmusic-confarc
> h-00.txt.html
> and especially section 7.3 in
> http://www.tik.ee.ethz.ch/~cobrow/deliverables/d3-2/d3-2.html.
> 
> 2) Whether a frame is INTER or INTRA is indicated in the 
> MTYPE field within
> the H.261 data stream (see Table 2 in the H.261 
> Recommendation). But a frame
> is either an INTER or INTRA frame inherently and cannot be 
> converted from
> one to the other simply by changing the MTYPE, so I wouldn't 
> try to modify
> the stream. If the first frame you recorded is not an INTRA 
> because, for
> example, it got lost in transmission, you might want to 
> search the video
> stream for the first INTRA and discard all frames up to that 
> point before
> re-transmission/playback.
> 
> Hope that helps.
> 
> Paul Long
> Smith Micro Software, Inc.
> 
> -----Original Message-----
> From: iptel-admin@lists.bell-labs.com
> [mailto:iptel-admin@lists.bell-labs.com]On Behalf Of Amar, Yigal
> Sent: Wednesday, October 04, 2000 11:22 AM
> To: iptel@lists.bell-labs.com
> Subject: [IPTEL] h323 and Video
> 
> 
> Hi ,
> 
> I have two question , and I hope this is the right place to ask ..
> 
> 1)  why is it that video codecs do not require jitter 
> buffering while audio
> codecs do ??
> 
> 2) I'm cupturing a H.261 video stream and writing it to a file , when
> transmiting/playing back  the
>     h.261 frames from the file, I need to indicate that the 
> first frame is
> an " I frame " , or else the playback is fuzzy.
>     How do I do that  ? is it in the h.261 header or RTP header ??
> 
> 
> 
> Thanks in advance
> 
> 
> 
> Yigal Amar
> 972-3-645-4175
> yigal_amar@icomverse.com
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel
> 

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Oct  5 12:45:04 2000
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 MAA02971
	for <iptel-archive@odin.ietf.org>; Thu, 5 Oct 2000 12:45:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1AB4844431; Thu,  5 Oct 2000 11:38:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from avmail.smithmicro.com (avmail.smithmicro.com [209.218.67.201])
	by lists.bell-labs.com (Postfix) with ESMTP id 82B2B4433D
	for <iptel@lists.bell-labs.com>; Thu,  5 Oct 2000 10:55:20 -0400 (EDT)
Received: by AVMAIL with Internet Mail Service (5.5.2650.21)
	id <T6YFPMGA>; Thu, 5 Oct 2000 08:54:01 -0700
Received: from plong (plong.aus.tx.bbnow.net [24.219.94.194]) by avmail.smithmicro.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id T6YFPMF0; Thu, 5 Oct 2000 08:53:55 -0700
From: Paul Long <Plong@smithmicro.com>
To: iptel@lists.bell-labs.com
Subject: RE: [IPTEL] h323 and Video
Message-ID: <NEBBJPMBKLHPBLLJLOBDMENCCGAA.plong@smithmicro.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <479518ED4F21D411B46D0030480035BC279CE7@unity-mail.icomverse.com>
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 5 Oct 2000 10:55:07 -0500
Content-Transfer-Encoding: 7bit

Yigal,

Yeah, your original video stream should probably have started with a key
frame (INTRA). Don't know why you don't have one. I have seen some H.323
endpoints, e.g., NetMeeting, loose the first one. To fix it, they just
transmit several at the beginning of a call! :-p

Paul Long
Smith MIcro Software, Inc.

-----Original Message-----
From: Amar, Yigal [mailto:Yigal_Amar@icomverse.com]
Sent: Thursday, October 05, 2000 8:54 AM
To: 'Paul Long'; iptel@lists.bell-labs.com
Subject: RE: [IPTEL] h323 and Video


Hi Paul,

Thanks for your answers
I'm reading now the links that you send.
As for the second question ,I understand now that I can't modify the MTYPE
of the first frame just like that. I can't also discard all frames up to
first INTRA
because I've look in the H.261 standard and it allowed up to 132 "P frames"
after one INTRA frame,
which is 13 seconds in a 10fps rate - not good.

I think I saw something in H.245 that says to the far endpoint to generate
an INTRA frame
I need to read more about it.

Thanks

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Oct  5 16:30:12 2000
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 QAA06423
	for <iptel-archive@odin.ietf.org>; Thu, 5 Oct 2000 16:30:11 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5B5F24442C; Thu,  5 Oct 2000 15:30:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from unity-mail.icomverse.com (unknown [199.203.140.35])
	by lists.bell-labs.com (Postfix) with ESMTP id C881F4441C
	for <iptel@lists.bell-labs.com>; Thu,  5 Oct 2000 15:29:49 -0400 (EDT)
Received: by unity-mail.icomverse.com with Internet Mail Service (5.5.2650.21)
	id <4KGYV22V>; Thu, 5 Oct 2000 23:29:42 +0300
Message-ID: <479518ED4F21D411B46D0030480035BC279CEA@unity-mail.icomverse.com>
From: "Amar, Yigal" <Yigal_Amar@icomverse.com>
To: "'Paul Long'" <Plong@smithmicro.com>, iptel@lists.bell-labs.com
Subject: RE: [IPTEL] h323 and Video
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="windows-1255"
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 5 Oct 2000 23:29:40 +0300

Paul,

The original stream surely have key frame,
but I'm writing an IVR application and need to 'catch' the stream in a
random point
and record it to a file , so I guess I'm missing it.

Yigal


> -----Original Message-----
> From: Paul Long [mailto:Plong@smithmicro.com]
> Sent: Thursday, October 05, 2000 5:55 PM
> To: iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] h323 and Video
> 
> 
> Yigal,
> 
> Yeah, your original video stream should probably have started 
> with a key
> frame (INTRA). Don't know why you don't have one. I have seen 
> some H.323
> endpoints, e.g., NetMeeting, loose the first one. To fix it, they just
> transmit several at the beginning of a call! :-p
> 
> Paul Long
> Smith MIcro Software, Inc.
> 
> -----Original Message-----
> From: Amar, Yigal [mailto:Yigal_Amar@icomverse.com]
> Sent: Thursday, October 05, 2000 8:54 AM
> To: 'Paul Long'; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] h323 and Video
> 
> 
> Hi Paul,
> 
> Thanks for your answers
> I'm reading now the links that you send.
> As for the second question ,I understand now that I can't 
> modify the MTYPE
> of the first frame just like that. I can't also discard all 
> frames up to
> first INTRA
> because I've look in the H.261 standard and it allowed up to 
> 132 "P frames"
> after one INTRA frame,
> which is 13 seconds in a 10fps rate - not good.
> 
> I think I saw something in H.245 that says to the far 
> endpoint to generate
> an INTRA frame
> I need to read more about it.
> 
> Thanks
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel
> 

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Oct  5 22:10:03 2000
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 WAA10818
	for <iptel-archive@odin.ietf.org>; Thu, 5 Oct 2000 22:10:02 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5A0914440A; Thu,  5 Oct 2000 21:10:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from avmail.smithmicro.com (avmail.smithmicro.com [209.218.67.201])
	by lists.bell-labs.com (Postfix) with ESMTP id 8347044444
	for <iptel@lists.bell-labs.com>; Thu,  5 Oct 2000 15:51:47 -0400 (EDT)
Received: by AVMAIL with Internet Mail Service (5.5.2650.21)
	id <T6YFPNLT>; Thu, 5 Oct 2000 13:50:30 -0700
Received: from plong (plong.aus.tx.bbnow.net [24.219.94.194]) by avmail.smithmicro.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id T6YFPNLS; Thu, 5 Oct 2000 13:50:26 -0700
From: Paul Long <Plong@smithmicro.com>
To: iptel@lists.bell-labs.com
Subject: RE: [IPTEL] h323 and Video
Message-ID: <NEBBJPMBKLHPBLLJLOBDEENGCGAA.plong@smithmicro.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <479518ED4F21D411B46D0030480035BC279CEA@unity-mail.icomverse.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 5 Oct 2000 15:51:36 -0500
Content-Transfer-Encoding: 7bit

Yigal,

In that case, your choices are to 1. suffer through the first several
seconds of corrupted video, 2. start recording or playingback/retransmitting
at the next key frame, or 3. generate your own key frame based on the last
key frame and any deltas that have been applied to it. The latter assumes
you are performing the decoding yourself and not merely grabbing a stream
blindly, which unfortunately sounds like what you are doing.

Paul Long
Smith Micro Software, Inc.

-----Original Message-----
From: Amar, Yigal [mailto:Yigal_Amar@icomverse.com]
Sent: Thursday, October 05, 2000 3:30 PM
To: 'Paul Long'; iptel@lists.bell-labs.com
Subject: RE: [IPTEL] h323 and Video


Paul,

The original stream surely have key frame,
but I'm writing an IVR application and need to 'catch' the stream in a
random point
and record it to a file , so I guess I'm missing it.

Yigal

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Oct  5 22:56:01 2000
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 WAA12168
	for <iptel-archive@odin.ietf.org>; Thu, 5 Oct 2000 22:56:01 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 483BF44447; Thu,  5 Oct 2000 21:56:01 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 4C39E4433B
	for <iptel@lists.bell-labs.com>; Thu,  5 Oct 2000 21:55:07 -0400 (EDT)
Received: from ind.cs.columbia.edu (ind.cs.columbia.edu [128.59.19.27])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id WAA18723;
	Thu, 5 Oct 2000 22:54:58 -0400 (EDT)
Received: (from lennox@localhost)
	by ind.cs.columbia.edu (8.9.3/8.9.3) id WAA13593;
	Thu, 5 Oct 2000 22:54:58 -0400 (EDT)
From: Jonathan Lennox <lennox@cs.columbia.edu>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="kjkxUXVr/c"
Content-Transfer-Encoding: 7bit
Message-ID: <14813.16130.408224.903423@ind.cs.columbia.edu>
To: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
Cc: <iptel@lists.bell-labs.com>
Subject: [IPTEL] CPL time ranges: Rough consensus and...
In-Reply-To: <000201c02c2d$29e38160$e69ffea9@dynamicsoft.com>
References: <14805.10812.864120.484144@conrail.cs.columbia.edu>
	<000201c02c2d$29e38160$e69ffea9@dynamicsoft.com>
X-Mailer: VM 6.75 under Emacs 19.34.1
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 5 Oct 2000 22:54:58 -0400 (EDT)


--kjkxUXVr/c
Content-Type: text/plain; charset=us-ascii
Content-Description: message body and .signature
Content-Transfer-Encoding: 7bit

On Monday, October 2 2000, "Jonathan Rosenberg" wrote to "'Jonathan Lennox', <iptel@lists.bell-labs.com>" saying:

> Good work. Nearly as I can tell, this seems to work. I'd feel a lot better
> if there were running code.

I live to please.  I now have running code.

Available for your reviewing pleasure:
<http://www.cs.columbia.edu/~lennox/Cal-Code.jar>.

This is preliminary code, with several known bugs, but I thought it would
be a Good Thing to get it out to the group as soon as possible.

Comments *very* welcome.

See the README file, attached.

-- 
Jonathan Lennox
lennox@cs.columbia.edu


--kjkxUXVr/c
Content-Type: text/plain
Content-Disposition: inline;
	filename="README"
Content-Transfer-Encoding: 7bit

This archive contains sample Java code implementing the logic underneath the
CPL <time-switch> tag.

The class edu.columbia.cpl.Recurrence implements a recurrence.  It has
all the accessors necessary for setting the parameters of a recurrence.
There are two support classes, edu.columbia.cpl.Duration (which represents a
duration interval) and edu.columbia.cpl.DayAndPosition (which represents
byday rules like "fourth thursday").

This code is only a rudimentary implementation of the CPL time-switch.  It
is missing:
        * Parsers
        * Much error-checking
        * Much documentation
          (There is Javadoc documentation of some functions.)

Known bugs with the code are listed in the file 'BUGS'.

CPL time-switch, and this code, is limited from RFC 2445 iCal RRULEs in the
following ways:
        * frequencies and by* rules of less than a day are eliminated
        * "count" is eliminated
        * "bysetpos" is eliminated
        * Durations longer than the minimum interval are not supported.
          (They are currently accepted by this code, but don't work
          correctly.) 

The file TestRecur runs through those examples from RFC 2445 which meet the
above criteria.  (Tests with "count" parameters simply have the count
omitted.  These are marked with a (!) in the test name.)

This code is Copyright 2000 Columbia University.  All Rights Reserved.
Future revisions of this code (once some bugs are worked out) may be under
some type of open-source license, but this release is for informational
purposes only.

Written by Jonathan Lennox <lennox@cs.columbia.edu>, October 5, 2000.  All
comments welcome.

--kjkxUXVr/c--

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Fri Oct  6 01:50:03 2000
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 BAA19273
	for <iptel-archive@odin.ietf.org>; Fri, 6 Oct 2000 01:50:03 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B4B6044452; Fri,  6 Oct 2000 00:50:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from mail.eis.ernet.in (unknown [202.41.97.131])
	by lists.bell-labs.com (Postfix) with ESMTP id CFDA44433B
	for <iptel@lists.bell-labs.com>; Fri,  6 Oct 2000 00:49:19 -0400 (EDT)
Received: from uucp-relay-delhi.ernet.in (vikram.doe.ernet.in
          [202.41.100.90]) by mail.eis.ernet.in (Netscape Messaging Server
          4.15) with ESMTP id G1ZW5D00.619; Fri, 6 Oct 2000 11:17:37 +0500 
Received: by uucp-relay-delhi.ernet.in (8.9.3+Sun/SMI-4.1-MHS-7.0)
	id LAA23970; Fri, 6 Oct 2000 11:14:08 -0600 (GMT)
>Received: from gemini.cdotd.ernet.in by cdotd.cdotd.ernet.in (SMI-8.6/SMI-SVR4)
	id LAA11611; Fri, 6 Oct 2000 11:16:58 -0500
Message-ID: <39DD6719.F9C3387D@cdotd.ernet.in>
From: Satish Bansal <sbansal@cdotd.ernet.in>
X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.11.00 9000/785)
X-Accept-Language: en
MIME-Version: 1.0
To: "Amar, Yigal" <Yigal_Amar@icomverse.com>
Cc: "'Paul Long'" <Plong@smithmicro.com>, iptel@lists.bell-labs.com
Subject: Re: [IPTEL] h323 and Video
References: <479518ED4F21D411B46D0030480035BC279CE7@unity-mail.icomverse.com>
Content-Transfer-Encoding: 7bit
Received: from cdotd by vikram.doe.ernet.in; Fri,  6 Oct 2000 11:14 GMT
Content-Type: text/plain; charset=us-ascii
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Fri, 06 Oct 2000 11:16:01 +0530
Content-Transfer-Encoding: 7bit

Hi all,
I here by request all ,please donot send "thanx" type of mails to every member
of
the mailing list. It will save a lot of time of all users.
thanx
satish

"Amar, Yigal" wrote:

> Hi Paul,
>
> Thanks for your answers
> I'm reading now the links that you send.
> As for the second question ,I understand now that I can't modify the MTYPE
> of the first frame just like that. I can't also discard all frames up to
> first INTRA
> because I've look in the H.261 standard and it allowed up to 132 "P frames"
> after one INTRA frame,
> which is 13 seconds in a 10fps rate - not good.
>
> I think I saw something in H.245 that says to the far endpoint to generate
> an INTRA frame
> I need to read more about it.
>
> Thanks
>
> > -----Original Message-----
> > From: Paul Long [mailto:Plong@smithmicro.com]
> > Sent: Thursday, October 05, 2000 3:21 AM
> > To: iptel@lists.bell-labs.com
> > Cc: paulej@packetizer.com
> > Subject: RE: [IPTEL] h323 and Video
> >
> >
> > Yigal,
> >
> > 1) JItter buffers are not required by either audio or video,
> > would benefit
> > both, but benefit audio the most because of the more
> > ephemeral nature of
> > audio. Receiver-generated jitter estimates are very useful to a video
> > encoder and media scheduler. B.14.3/H.245v5 describes the
> > semantics for the
> > JitterIndication messages as typically applied to a video
> > channel, and SR/RR
> > interarrival jitter described in RFC 1889 is media neutral.
> > Also check out
> > sections 4.2 and 4.3 in
> > http://www.kashpureff.org/nic/drafts/draft-ietf-mmusic-confarc
> > h-00.txt.html
> > and especially section 7.3 in
> > http://www.tik.ee.ethz.ch/~cobrow/deliverables/d3-2/d3-2.html.
> >
> > 2) Whether a frame is INTER or INTRA is indicated in the
> > MTYPE field within
> > the H.261 data stream (see Table 2 in the H.261
> > Recommendation). But a frame
> > is either an INTER or INTRA frame inherently and cannot be
> > converted from
> > one to the other simply by changing the MTYPE, so I wouldn't
> > try to modify
> > the stream. If the first frame you recorded is not an INTRA
> > because, for
> > example, it got lost in transmission, you might want to
> > search the video
> > stream for the first INTRA and discard all frames up to that
> > point before
> > re-transmission/playback.
> >
> > Hope that helps.
> >
> > Paul Long
> > Smith Micro Software, Inc.
> >
> > -----Original Message-----
> > From: iptel-admin@lists.bell-labs.com
> > [mailto:iptel-admin@lists.bell-labs.com]On Behalf Of Amar, Yigal
> > Sent: Wednesday, October 04, 2000 11:22 AM
> > To: iptel@lists.bell-labs.com
> > Subject: [IPTEL] h323 and Video
> >
> >
> > Hi ,
> >
> > I have two question , and I hope this is the right place to ask ..
> >
> > 1)  why is it that video codecs do not require jitter
> > buffering while audio
> > codecs do ??
> >
> > 2) I'm cupturing a H.261 video stream and writing it to a file , when
> > transmiting/playing back  the
> >     h.261 frames from the file, I need to indicate that the
> > first frame is
> > an " I frame " , or else the playback is fuzzy.
> >     How do I do that  ? is it in the h.261 header or RTP header ??
> >
> >
> >
> > Thanks in advance
> >
> >
> >
> > Yigal Amar
> > 972-3-645-4175
> > yigal_amar@icomverse.com
> >
> > _______________________________________________
> > IPTEL mailing list
> > IPTEL@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/iptel
> >
>
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel



_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Fri Oct  6 13:03:07 2000
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 NAA08537
	for <iptel-archive@odin.ietf.org>; Fri, 6 Oct 2000 13:03:04 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 23A1A44455; Fri,  6 Oct 2000 12:03:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from beluga.telepar.com.br (unknown [200.203.207.190])
	by lists.bell-labs.com (Postfix) with ESMTP id A49CB44346
	for <iptel@lists.bell-labs.com>; Fri,  6 Oct 2000 12:02:38 -0400 (EDT)
Received: by BELUGA with Internet Mail Service (5.5.2650.21)
	id <S5TYZMVL>; Fri, 6 Oct 2000 14:01:26 -0300
Message-ID: <3D98391A7EA2D31192E5000629385A9602325AA2@correio.telepar.com.br>
From: Luiz Alberto Pasini Melek <pasini@telepar.com.br>
To: iptel@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [IPTEL] unsubscribe pasini pasini
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Fri, 6 Oct 2000 14:01:13 -0300

unsubscribe pasini pasini

-----Mensagem original-----
De: iptel-request@lists.bell-labs.com
[mailto:iptel-request@lists.bell-labs.com]
Enviada em: Sexta-feira, 6 de Outubro de 2000 13:01
Para: iptel@lists.bell-labs.com
Assunto: IPTEL digest, Vol 1 #117 - 4 msgs


Send IPTEL mailing list submissions to
	iptel@lists.bell-labs.com

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.bell-labs.com/mailman/listinfo/iptel
or, via email, send a message with subject or body 'help' to
	iptel-request@lists.bell-labs.com

You can reach the person managing the list at
	iptel-admin@lists.bell-labs.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of IPTEL digest..."


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Sun Oct  8 05:14:05 2000
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 FAA07426
	for <iptel-archive@odin.ietf.org>; Sun, 8 Oct 2000 05:14:05 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 859F644337; Sun,  8 Oct 2000 04:14:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from unity-mail.icomverse.com (unknown [199.203.140.35])
	by lists.bell-labs.com (Postfix) with ESMTP id 19B7844336
	for <iptel@lists.bell-labs.com>; Sun,  8 Oct 2000 04:13:33 -0400 (EDT)
Received: by unity-mail.icomverse.com with Internet Mail Service (5.5.2650.21)
	id <4KGYV2MW>; Sun, 8 Oct 2000 11:13:14 +0200
Message-ID: <479518ED4F21D411B46D0030480035BC279CED@unity-mail.icomverse.com>
From: "Amar, Yigal" <Yigal_Amar@icomverse.com>
To: "'Paul Long'" <Plong@smithmicro.com>, iptel@lists.bell-labs.com
Subject: RE: [IPTEL] h323 and Video
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="windows-1255"
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Sun, 8 Oct 2000 11:13:13 +0200

Paul,

Right now, for prototype purpose I'm not doing any decoding.
I just record the video stream as it comes in a form of RTP packets (with
timestamps)
and when playing it back to the remote endpoint(on user demand),
I renormalize the timestamps according to sender wall clock.

If I'm using only h.261 in my system, why do you think I need decoding for
??

Yigal



> -----Original Message-----
> From: Paul Long [mailto:Plong@smithmicro.com]
> Sent: Thursday, October 05, 2000 10:52 PM
> To: iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] h323 and Video
> 
> 
> Yigal,
> 
> In that case, your choices are to 1. suffer through the first several
> seconds of corrupted video, 2. start recording or 
> playingback/retransmitting
> at the next key frame, or 3. generate your own key frame 
> based on the last
> key frame and any deltas that have been applied to it. The 
> latter assumes
> you are performing the decoding yourself and not merely 
> grabbing a stream
> blindly, which unfortunately sounds like what you are doing.
> 
> Paul Long
> Smith Micro Software, Inc.
> 
> -----Original Message-----
> From: Amar, Yigal [mailto:Yigal_Amar@icomverse.com]
> Sent: Thursday, October 05, 2000 3:30 PM
> To: 'Paul Long'; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] h323 and Video
> 
> 
> Paul,
> 
> The original stream surely have key frame,
> but I'm writing an IVR application and need to 'catch' the stream in a
> random point
> and record it to a file , so I guess I'm missing it.
> 
> Yigal
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel
> 

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Tue Oct 10 07:26:00 2000
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 HAA01445
	for <iptel-archive@odin.ietf.org>; Tue, 10 Oct 2000 07:25:59 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3C0CF4439A; Tue, 10 Oct 2000 06:25:10 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from prserv.net (out4.prserv.net [32.97.166.34])
	by lists.bell-labs.com (Postfix) with ESMTP id 4C66F44338
	for <iptel@lists.bell-labs.com>; Tue, 10 Oct 2000 04:44:51 -0400 (EDT)
Received: from amislaptop ([139.92.232.119]) by prserv.net (out4) with SMTP
          id <2000101009444523900g0uiie>; Tue, 10 Oct 2000 09:44:46 +0000
Reply-To: <amir@tlv.radvision.com>
From: "Ami Amir" <amir@tlv.radvision.com>
To: "'Amar, Yigal'" <Yigal_Amar@icomverse.com>,
        "'Paul Long'" <Plong@smithmicro.com>, <iptel@lists.bell-labs.com>
Cc: "Rudy Shainer (E-mail)" <rudy@tlv.radvision.com>
Subject: RE: [IPTEL] h323 and Video
Message-ID: <001601c032a7$4cb918a0$6496fea9@amislaptop>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <479518ED4F21D411B46D0030480035BC279CED@unity-mail.icomverse.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Tue, 10 Oct 2000 12:34:27 +0200
Content-Transfer-Encoding: 7bit

Yigal

The decoder (receive side codec) will eed to wait for an Key Frame in order
to start providing a meaningful image. If you disregard this issue when
recording, it is highly likely that a significant art of your recording will
be lost.

Ami

-----Original Message-----
From: iptel-admin@lists.bell-labs.com
[mailto:iptel-admin@lists.bell-labs.com]On Behalf Of Amar, Yigal
Sent: 08 October, 2000 11:13
To: 'Paul Long'; iptel@lists.bell-labs.com
Subject: RE: [IPTEL] h323 and Video


Paul,

Right now, for prototype purpose I'm not doing any decoding.
I just record the video stream as it comes in a form of RTP packets (with
timestamps)
and when playing it back to the remote endpoint(on user demand),
I renormalize the timestamps according to sender wall clock.

If I'm using only h.261 in my system, why do you think I need decoding for
??

Yigal



> -----Original Message-----
> From: Paul Long [mailto:Plong@smithmicro.com]
> Sent: Thursday, October 05, 2000 10:52 PM
> To: iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] h323 and Video
>
>
> Yigal,
>
> In that case, your choices are to 1. suffer through the first several
> seconds of corrupted video, 2. start recording or
> playingback/retransmitting
> at the next key frame, or 3. generate your own key frame
> based on the last
> key frame and any deltas that have been applied to it. The
> latter assumes
> you are performing the decoding yourself and not merely
> grabbing a stream
> blindly, which unfortunately sounds like what you are doing.
>
> Paul Long
> Smith Micro Software, Inc.
>
> -----Original Message-----
> From: Amar, Yigal [mailto:Yigal_Amar@icomverse.com]
> Sent: Thursday, October 05, 2000 3:30 PM
> To: 'Paul Long'; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] h323 and Video
>
>
> Paul,
>
> The original stream surely have key frame,
> but I'm writing an IVR application and need to 'catch' the stream in a
> random point
> and record it to a file , so I guess I'm missing it.
>
> Yigal
>
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel
>

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Oct 11 13:55:07 2000
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 NAA16287
	for <iptel-archive@odin.ietf.org>; Wed, 11 Oct 2000 13:55:06 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A561A44348; Wed, 11 Oct 2000 12:55:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 61BDA44339
	for <iptel@lists.bell-labs.com>; Wed, 11 Oct 2000 12:54:29 -0400 (EDT)
Received: from conrail.cs.columbia.edu (conrail.cs.columbia.edu [128.59.19.147])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA24304
	for <iptel@lists.bell-labs.com>; Wed, 11 Oct 2000 13:54:23 -0400 (EDT)
Received: (from lennox@localhost)
	by conrail.cs.columbia.edu (8.9.3/8.9.1) id NAA50506;
	Wed, 11 Oct 2000 13:54:24 -0400 (EDT)
	(envelope-from lennox)
From: Jonathan Lennox <lennox@cs.columbia.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14820.43344.35004.680940@conrail.cs.columbia.edu>
To: <iptel@lists.bell-labs.com>
Subject: Re: [IPTEL] CPL time ranges: Cal-Code 1.0 now available
In-Reply-To: <14813.16130.408224.903423@ind.cs.columbia.edu>
References: <14805.10812.864120.484144@conrail.cs.columbia.edu>
	<000201c02c2d$29e38160$e69ffea9@dynamicsoft.com>
	<14813.16130.408224.903423@ind.cs.columbia.edu>
X-Mailer: VM 6.75 under Emacs 19.34.1
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 11 Oct 2000 13:54:24 -0400 (EDT)
Content-Transfer-Encoding: 7bit

Version 1.0 of my sample Java code for resolving CPL time-switches is now
available from <http://www.cs.columbia.edu/~lennox/Cal-Code/>.

This version is open-source licensed under a standard BSD license.

This version fixes all the known bugs in the version I distributed last
week, and it handles all the applicable test cases from RFC 2445 correctly.
It has also been fairly thoroughly documented.

Comments welcome.

-- 
Jonathan Lennox
lennox@cs.columbia.edu

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Wed Oct 11 14:06:24 2000
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 OAA16651
	for <iptel-archive@odin.ietf.org>; Wed, 11 Oct 2000 14:06:24 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id F0500443FE; Wed, 11 Oct 2000 13:06:00 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id D6006443FD
	for <iptel@lists.bell-labs.com>; Wed, 11 Oct 2000 13:05:08 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA25226;
	Wed, 11 Oct 2000 14:07:10 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <4WS2X24F>; Wed, 11 Oct 2000 14:01:26 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF4D8AD4@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Jonathan Lennox'" <lennox@cs.columbia.edu>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: RE: [IPTEL] CPL time ranges: Cal-Code 1.0 now available
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Wed, 11 Oct 2000 14:01:25 -0400

First off, I'd like to thank Jonathan Lennox for a fantastic job in putting
together an algorithm that works in O(1) and then writing, testing, and
making available this code. Great work.

Given that we seem to now have rough consensus and running code that
supports the somewhat restricted iCal syntax, I am officially declaring this
issue CLOSED. We will go with Jonathan's proposal. 

The next main issue to address is H.323 handling, and specifically, to
answer the ITU liaision statement we got. I'm going to be sending out a
proposed plan of attack shortly. If you have any comments on the statement
itself, please send them asap.

Thanks,
Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

> -----Original Message-----
> From: Jonathan Lennox [mailto:lennox@cs.columbia.edu]
> Sent: Wednesday, October 11, 2000 1:54 PM
> To: iptel@lists.bell-labs.com
> Subject: Re: [IPTEL] CPL time ranges: Cal-Code 1.0 now available
> 
> 
> Version 1.0 of my sample Java code for resolving CPL 
> time-switches is now
> available from <http://www.cs.columbia.edu/~lennox/Cal-Code/>.
> 
> This version is open-source licensed under a standard BSD license.
> 
> This version fixes all the known bugs in the version I 
> distributed last
> week, and it handles all the applicable test cases from RFC 
> 2445 correctly.
> It has also been fairly thoroughly documented.
> 
> Comments welcome.
> 
> -- 
> Jonathan Lennox
> lennox@cs.columbia.edu
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel
> 

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Fri Oct 13 13:22:08 2000
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 NAA09517
	for <iptel-archive@odin.ietf.org>; Fri, 13 Oct 2000 13:22:06 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5849944337; Fri, 13 Oct 2000 12:22:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from avmail.smithmicro.com (avmail.smithmicro.com [209.218.67.201])
	by lists.bell-labs.com (Postfix) with ESMTP id 4277344336
	for <iptel@lists.bell-labs.com>; Fri, 13 Oct 2000 11:24:42 -0400 (EDT)
Received: by AVMAIL with Internet Mail Service (5.5.2650.21)
	id <437CQRMQ>; Fri, 13 Oct 2000 09:22:41 -0700
Received: from plong (plong.aus.tx.bbnow.net [24.219.94.194]) by avmail.smithmicro.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id 437CQRMP; Fri, 13 Oct 2000 09:22:37 -0700
From: Paul Long <Plong@smithmicro.com>
To: iptel@lists.bell-labs.com
Subject: RE: [IPTEL] h323 and Video
Message-ID: <NEBBJPMBKLHPBLLJLOBDCEBFCHAA.plong@smithmicro.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <479518ED4F21D411B46D0030480035BC279CED@unity-mail.icomverse.com>
Importance: Normal
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Fri, 13 Oct 2000 11:24:24 -0500
Content-Transfer-Encoding: 7bit

Yigal,

Unlike audio, video typically has temporal dependencies between frames. You
therefore cannot simply extract a sample from a video stream at an arbitrary
point without risking artifacts during playback. That's just the way it is.
You need to decode the stream in order to throw away all INTER frames up to
the first INTRA.

Paul

-----Original Message-----
From: Amar, Yigal [mailto:Yigal_Amar@icomverse.com]
Sent: Sunday, October 08, 2000 4:13 AM
To: 'Paul Long'; iptel@lists.bell-labs.com
Subject: RE: [IPTEL] h323 and Video


Paul,

Right now, for prototype purpose I'm not doing any decoding.
I just record the video stream as it comes in a form of RTP packets (with
timestamps)
and when playing it back to the remote endpoint(on user demand),
I renormalize the timestamps according to sender wall clock.

If I'm using only h.261 in my system, why do you think I need decoding for
??

Yigal

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Sun Oct 15 10:13:01 2000
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 KAA08637
	for <iptel-archive@odin.ietf.org>; Sun, 15 Oct 2000 10:13:01 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 097D544339; Sun, 15 Oct 2000 09:13:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from unity-mail.icomverse.com (unknown [199.203.140.35])
	by lists.bell-labs.com (Postfix) with ESMTP id 7B58B44336
	for <iptel@lists.bell-labs.com>; Sun, 15 Oct 2000 09:12:53 -0400 (EDT)
Received: by unity-mail.icomverse.com with Internet Mail Service (5.5.2650.21)
	id <4KGYVJ8S>; Sun, 15 Oct 2000 16:12:41 +0200
Message-ID: <479518ED4F21D411B46D0030480035BC279CF8@unity-mail.icomverse.com>
From: "Amar, Yigal" <Yigal_Amar@icomverse.com>
To: "'amir@tlv.radvision.com'" <amir@tlv.radvision.com>,
        "'Paul Long'" <Plong@smithmicro.com>, iptel@lists.bell-labs.com
Cc: "Rudy Shainer (E-mail)" <rudy@tlv.radvision.com>
Subject: RE: [IPTEL] h323 and Video
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="windows-1255"
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Sun, 15 Oct 2000 16:12:38 +0200

Hi Amir,

Sorry for the late response , I wasn't around.  

Do you mean that even after I send the "FastUpdatePicture" H245 command ,
I have to wait for the INTRA frame , and only then start the recording?

Yigal

> -----Original Message-----
> From: Ami Amir [mailto:amir@tlv.radvision.com]
> Sent: Tuesday, October 10, 2000 12:34 PM
> To: 'Amar, Yigal'; 'Paul Long'; iptel@lists.bell-labs.com
> Cc: Rudy Shainer (E-mail)
> Subject: RE: [IPTEL] h323 and Video
> 
> 
> Yigal
> 
> The decoder (receive side codec) will eed to wait for an Key 
> Frame in order
> to start providing a meaningful image. If you disregard this 
> issue when
> recording, it is highly likely that a significant art of your 
> recording will
> be lost.
> 
> Ami
> 
> -----Original Message-----
> From: iptel-admin@lists.bell-labs.com
> [mailto:iptel-admin@lists.bell-labs.com]On Behalf Of Amar, Yigal
> Sent: 08 October, 2000 11:13
> To: 'Paul Long'; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] h323 and Video
> 
> 
> Paul,
> 
> Right now, for prototype purpose I'm not doing any decoding.
> I just record the video stream as it comes in a form of RTP 
> packets (with
> timestamps)
> and when playing it back to the remote endpoint(on user demand),
> I renormalize the timestamps according to sender wall clock.
> 
> If I'm using only h.261 in my system, why do you think I need 
> decoding for
> ??
> 
> Yigal
> 
> 
> 
> > -----Original Message-----
> > From: Paul Long [mailto:Plong@smithmicro.com]
> > Sent: Thursday, October 05, 2000 10:52 PM
> > To: iptel@lists.bell-labs.com
> > Subject: RE: [IPTEL] h323 and Video
> >
> >
> > Yigal,
> >
> > In that case, your choices are to 1. suffer through the 
> first several
> > seconds of corrupted video, 2. start recording or
> > playingback/retransmitting
> > at the next key frame, or 3. generate your own key frame
> > based on the last
> > key frame and any deltas that have been applied to it. The
> > latter assumes
> > you are performing the decoding yourself and not merely
> > grabbing a stream
> > blindly, which unfortunately sounds like what you are doing.
> >
> > Paul Long
> > Smith Micro Software, Inc.
> >
> > -----Original Message-----
> > From: Amar, Yigal [mailto:Yigal_Amar@icomverse.com]
> > Sent: Thursday, October 05, 2000 3:30 PM
> > To: 'Paul Long'; iptel@lists.bell-labs.com
> > Subject: RE: [IPTEL] h323 and Video
> >
> >
> > Paul,
> >
> > The original stream surely have key frame,
> > but I'm writing an IVR application and need to 'catch' the 
> stream in a
> > random point
> > and record it to a file , so I guess I'm missing it.
> >
> > Yigal
> >
> > _______________________________________________
> > IPTEL mailing list
> > IPTEL@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/iptel
> >
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel
> 
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel
> 

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Mon Oct 16 06:48:29 2000
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 GAA01758
	for <iptel-archive@odin.ietf.org>; Mon, 16 Oct 2000 06:48:29 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 231A54437D; Mon, 16 Oct 2000 05:48:03 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from guardian1.tlv.radvision.com (unknown [212.143.185.30])
	by lists.bell-labs.com (Postfix) with ESMTP id 228ED44338
	for <iptel@lists.bell-labs.com>; Mon, 16 Oct 2000 02:17:23 -0400 (EDT)
Received: from nt-mail.tlv.radvision.com ([172.20.2.100])
          by guardian1.tlv.radvision.com (Post.Office MTA v3.5.3
          release 223 ID# 0-0U10L2S100V35) with ESMTP id com;
          Mon, 16 Oct 2000 10:16:09 +0200
Received: by NT-MAIL with Internet Mail Service (5.5.2650.21)
	id <48RJ5TWJ>; Mon, 16 Oct 2000 09:17:33 +0200
Message-ID: <E09383987EE5D3119F2E0008C7097728010170AC@NT-MAIL>
From: Ami Amir <Amir@tlv.radvision.com>
To: "Amar, Yigal" <Yigal_Amar@icomverse.com>,
        Ami Amir <Amir@tlv.radvision.com>,
        "'Paul Long'" <Plong@smithmicro.com>, iptel@lists.bell-labs.com
Cc: Rudy Shainer <rudy@tlv.radvision.com>
Subject: RE: [IPTEL] h323 and Video
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="windows-1255"
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 16 Oct 2000 09:17:32 +0200

Yup,

You cannot control the behaviour of codecs from a variety of vendors, and
hence when will they respond to your request for fastupdate. You can start
recording at will, but it won't do you any good to send an H.26x clip w/o an
initial intra frame.

-----Original Message-----
From: Amar, Yigal [mailto:Yigal_Amar@icomverse.com]
Sent: 15 October, 2000 16:13
To: 'amir@tlv.radvision.com'; 'Paul Long'; iptel@lists.bell-labs.com
Cc: Rudy Shainer (E-mail)
Subject: RE: [IPTEL] h323 and Video

Hi Amir,

Sorry for the late response , I wasn't around. 

Do you mean that even after I send the "FastUpdatePicture" H245 command ,
I have to wait for the INTRA frame , and only then start the recording?

Yigal

> -----Original Message-----
> From: Ami Amir [mailto:amir@tlv.radvision.com]
> Sent: Tuesday, October 10, 2000 12:34 PM
> To: 'Amar, Yigal'; 'Paul Long'; iptel@lists.bell-labs.com
> Cc: Rudy Shainer (E-mail)
> Subject: RE: [IPTEL] h323 and Video
>
>
> Yigal
>
> The decoder (receive side codec) will eed to wait for an Key
> Frame in order
> to start providing a meaningful image. If you disregard this
> issue when
> recording, it is highly likely that a significant art of your
> recording will
> be lost.
>
> Ami
>
> -----Original Message-----
> From: iptel-admin@lists.bell-labs.com
> [mailto:iptel-admin@lists.bell-labs.com]On Behalf Of Amar, Yigal
> Sent: 08 October, 2000 11:13
> To: 'Paul Long'; iptel@lists.bell-labs.com
> Subject: RE: [IPTEL] h323 and Video
>
>
> Paul,
>
> Right now, for prototype purpose I'm not doing any decoding.
> I just record the video stream as it comes in a form of RTP
> packets (with
> timestamps)
> and when playing it back to the remote endpoint(on user demand),
> I renormalize the timestamps according to sender wall clock.
>
> If I'm using only h.261 in my system, why do you think I need
> decoding for
> ??
>
> Yigal
>
>
>
> > -----Original Message-----
> > From: Paul Long [mailto:Plong@smithmicro.com]
> > Sent: Thursday, October 05, 2000 10:52 PM
> > To: iptel@lists.bell-labs.com
> > Subject: RE: [IPTEL] h323 and Video
> >
> >
> > Yigal,
> >
> > In that case, your choices are to 1. suffer through the
> first several
> > seconds of corrupted video, 2. start recording or
> > playingback/retransmitting
> > at the next key frame, or 3. generate your own key frame
> > based on the last
> > key frame and any deltas that have been applied to it. The
> > latter assumes
> > you are performing the decoding yourself and not merely
> > grabbing a stream
> > blindly, which unfortunately sounds like what you are doing.
> >
> > Paul Long
> > Smith Micro Software, Inc.
> >
> > -----Original Message-----
> > From: Amar, Yigal [mailto:Yigal_Amar@icomverse.com]
> > Sent: Thursday, October 05, 2000 3:30 PM
> > To: 'Paul Long'; iptel@lists.bell-labs.com
> > Subject: RE: [IPTEL] h323 and Video
> >
> >
> > Paul,
> >
> > The original stream surely have key frame,
> > but I'm writing an IVR application and need to 'catch' the
> stream in a
> > random point
> > and record it to a file , so I guess I'm missing it.
> >
> > Yigal
> >
> > _______________________________________________
> > IPTEL mailing list
> > IPTEL@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/iptel
> >
>
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel
>
>
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel
>

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Oct 26 10:01:09 2000
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 KAA14184
	for <iptel-archive@odin.ietf.org>; Thu, 26 Oct 2000 10:01:09 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 294B444353; Thu, 26 Oct 2000 09:01:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by lists.bell-labs.com (Postfix) with ESMTP id 2A0294435E
	for <iptel@lists.bell-labs.com>; Thu, 26 Oct 2000 05:47:16 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16281;
	Thu, 26 Oct 2000 06:47:11 -0400 (EDT)
Message-Id: <200010261047.GAA16281@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: iptel@lists.bell-labs.com
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: [IPTEL] I-D ACTION:draft-ietf-iptel-cpl-03.txt,.ps
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 26 Oct 2000 06:47:10 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Telephony Working Group of the IETF.

	Title		: CPL: A Language for User Control of Internet Telephony
                          Services
	Author(s)	: J. Lennox, H. Schulzrinne
	Filename	: draft-ietf-iptel-cpl-03.txt,.ps
	Pages		: 61
	Date		: 25-Oct-00
	
The Call Processing Language (CPL) is a language that can be used to
describe and control Internet telephony services. It is designed to
be implementable on either network servers or user agent servers. It
is meant to be simple, extensible, easily edited by graphical
clients, and independent of operating system or signalling protocol.
It is suitable for running on a server where users may not be allowed
to execute arbitrary programs, as it has no variables, loops, or
ability to run external programs.
This document is a product of the IP Telephony (IPTEL) working group
of the Internet Engineering Task Force. Comments are solicited and
should be addressed to the working group's mailing list at
iptel@lists.research.bell-labs.com and/or the authors.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-03.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-iptel-cpl-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-iptel-cpl-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20001025103222.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-iptel-cpl-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-iptel-cpl-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20001025103222.I-D@ietf.org>

--OtherAccess--

--NextPart--



_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Oct 26 11:00:03 2000
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 LAA27216
	for <iptel-archive@odin.ietf.org>; Thu, 26 Oct 2000 11:00:02 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8692844393; Thu, 26 Oct 2000 09:50:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id C7CCE44392
	for <iptel@lists.bell-labs.com>; Thu, 26 Oct 2000 09:49:37 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA05581;
	Thu, 26 Oct 2000 10:51:46 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <4WS2X01X>; Thu, 26 Oct 2000 10:45:33 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF4C3AF7@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Cc: "Bradner, Scott (E-mail)" <sob@harvard.edu>,
        "Allison Mankin (E-mail)" <mankin@east.isi.edu>
Subject: FW: [IPTEL] I-D ACTION:draft-ietf-iptel-cpl-03.txt,.ps
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C03F5B.643462B6"
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 26 Oct 2000 10:45:29 -0400

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_01C03F5B.643462B6
Content-Type: text/plain;
	charset="iso-8859-1"

Folks,

As you can see, -03 of the CPL spec has just been submitted. It contains the
new time-switch stuff, along with an update to H.323 handling and
organization based on the liaison we received from ITU.

I am happy to now issue a working group last call on this document. In two
weeks time hence (November 9, 2000), if there are no comments, I will submit
this document to IESG for consideration as proposed standard. If you do have
comments on this document, please send them to the list before then for
discussion.

Thanks,
Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Thursday, October 26, 2000 6:47 AM
To: IETF-Announce
Cc: iptel@lists.bell-labs.com
Subject: [IPTEL] I-D ACTION:draft-ietf-iptel-cpl-03.txt,.ps


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the IP Telephony Working Group of the IETF.

	Title		: CPL: A Language for User Control of Internet
Telephony
                          Services
	Author(s)	: J. Lennox, H. Schulzrinne
	Filename	: draft-ietf-iptel-cpl-03.txt,.ps
	Pages		: 61
	Date		: 25-Oct-00
	
The Call Processing Language (CPL) is a language that can be used to
describe and control Internet telephony services. It is designed to
be implementable on either network servers or user agent servers. It
is meant to be simple, extensible, easily edited by graphical
clients, and independent of operating system or signalling protocol.
It is suitable for running on a server where users may not be allowed
to execute arbitrary programs, as it has no variables, loops, or
ability to run external programs.
This document is a product of the IP Telephony (IPTEL) working group
of the Internet Engineering Task Force. Comments are solicited and
should be addressed to the working group's mailing list at
iptel@lists.research.bell-labs.com and/or the authors.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-03.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-iptel-cpl-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-iptel-cpl-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


------_=_NextPart_000_01C03F5B.643462B6
Content-Type: message/rfc822

To: 
Subject: 
Date: Thu, 26 Oct 2000 10:45:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_002_01C03F5B.643462B6"


------_=_NextPart_002_01C03F5B.643462B6
Content-Type: text/plain



------_=_NextPart_002_01C03F5B.643462B6
Content-Type: application/octet-stream;
	name="ATT19919.txt"
Content-Disposition: attachment;
	filename="ATT19919.txt"

Content-type: message/external-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20001025103222.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-iptel-cpl-03.txt

------_=_NextPart_002_01C03F5B.643462B6
Content-Type: message/external-body;
	site="internet-drafts";
	dir="draft-ietf-iptel-cpl-03.txt";
	mode="ftp.ietf.org";
	access-type="anon-ftp"


------_=_NextPart_002_01C03F5B.643462B6--

------_=_NextPart_000_01C03F5B.643462B6--

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Thu Oct 26 11:49:53 2000
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 LAA08476
	for <iptel-archive@odin.ietf.org>; Thu, 26 Oct 2000 11:49:52 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 08C6E44342; Thu, 26 Oct 2000 10:48:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from drago1.ubiquity.net (unknown [194.202.146.92])
	by lists.bell-labs.com (Postfix) with SMTP id D41C744340
	for <iptel@lists.bell-labs.com>; Thu, 26 Oct 2000 10:47:20 -0400 (EDT)
Received: from gecko.ubiquity.co.uk by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 26 Oct 2000 15:47:53 UT
Received: from jundery.ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef)
	id QAA01229; Thu, 26 Oct 2000 16:45:44 +0100 (BST)
Received: from localhost (jundery@localhost)
	by jundery.ubiquity.net (8.9.3/8.9.3) with ESMTP id QAA06574;
	Thu, 26 Oct 2000 16:45:43 GMT
X-Authentication-Warning: jundery.ubiquity.net: jundery owned process doing -bs
From: James Undery <jundery@ubiquity.net>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: Re: FW: [IPTEL] I-D ACTION:draft-ietf-iptel-cpl-03.txt,.ps
In-Reply-To: <B65B4F8437968F488A01A940B21982BF4C3AF7@DYN-EXCH-001.dynamicsoft.com>
Message-ID: <Pine.LNX.4.10.10010261638090.6441-100000@jundery.ubiquity.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Thu, 26 Oct 2000 16:45:43 +0000 (GMT)



On Thu, 26 Oct 2000, Jonathan Rosenberg wrote:

> I am happy to now issue a working group last call on this document. In two
> weeks time hence (November 9, 2000), if there are no comments, I will submit
> this document to IESG for consideration as proposed standard. If you do have
> comments on this document, please send them to the list before then for
> discussion.

A quick note the durations in the time switches are still wrong

section 5.3 duration="P10M" should be duration="PT10M"

figure 24 duration="P8H" should be duration="PT8H"

according to the definition of DURATION in section 4.3.6 of RFC 2445

James Undery


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Fri Oct 27 02:35:00 2000
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 CAA12554
	for <iptel-archive@odin.ietf.org>; Fri, 27 Oct 2000 02:35:00 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4132C44338; Fri, 27 Oct 2000 01:35:02 -0400 (EDT)
Delivered-To: iptel@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 7143544336
	for <iptel@lists.bell-labs.com>; Fri, 27 Oct 2000 01:34:13 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA13566
	for <iptel@lists.bell-labs.com>; Fri, 27 Oct 2000 02:36:21 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <4WS2YAYX>; Fri, 27 Oct 2000 02:30:07 -0400
Message-ID: <B65B4F8437968F488A01A940B21982BF4C3B04@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [IPTEL] Reply to SG16 liason
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Fri, 27 Oct 2000 02:30:02 -0400

Folks,

Below is the response I plan to send to ITU to the liaison they sent
regarding CPL. All of the items that are mentioned as things we will address
are already incorporated into the -03 draft.

Comments are solicited. If none are received, I'll send one week hence -
Nov. 3.

THanks,
Jonathan R.
> -----Original Message-----
> From: Jonathan Rosenberg 
> Sent: Friday, October 20, 2000 2:28 AM
> To: Jonathan Rosenberg
> Subject: test
> 
> 
> ITU - Telecommunication Standardization Sector 	TD -44c
> STUDY GROUP 16
> 
> 
> Portland, 25 August, 2000
> 
> QUESTIONS:	Q.22/11 (for action) 
> SOURCE:	Q13/16
> TITLE:	COMMENTS ON CPL DRAFT
> LIAISON STATEMENT TO:	IETF IPTEL  WG on CPL
> APPROVAL:	Agreed to at Q.13/16 Rapporteurs meeting 
> (Portland, 21-25 August 2000)
> FOR:	ACTION required response by 1st November 2000
> CONTACTS: 	Mr. Dale Skran, Rapporteur for Q.13/16	
>                 Tel: +1 732 625 3003 x202
>                 Sonus Networks,
>                 4400 Route 9 South, Suite 3500,	
>                 Freehold, NJ 07728, USA	
>                 Email:	dskran@Sonusnet.com
> 
> 
> Abstract: This contribution discusses possible use of CPL in the
> context of H.323 and provides remarks for the current CPL
> specification.
>  
> 
> 
> 1	Trying to apply CPL to H.323 
> 
> According to our understanding, one of the original CPL goals was to
> make the definition independent from the specific underlying Call
> Signaling Protocol. It can be seemed as an "abstract" API definition
> for a specific Application, allowing for different protocols to
> actually implement it.  The CPL, as it is defined today, can be used
> to describe the behavior of an H.323 Server. Nevertheless, the main
> concern is that the CPL specification is not structured in a way
> allowing a separation of the "abstract" concepts from their mapping
> into a specific system or into specific protocol fields.

This does not appear to be the case in the most recent version of CPL.
Active steps were taken to define actions in terms of generalizations, and
then define mappings to SIP and H.323. The address-switch is a good example
of this.

> Moreover,
> many of the CPL "abstracts" are defined by providing examples or
> pointers to SIP-related IETF documents. This forces the writer of the
> CPL script to become familiar with the details and considerations
> behind the SIP design. 

This is a side-effect of the expertise of the authors and developers of CPL.
If, as proposed, ITU incorporates an interpretation of CPL for H.323 into
Annex O, this document is better suited to address examples in a more H.323
centric fashion.


> This situation led for the inclusion of a
> limiting H.323 interpretation into the body of the CPL definition. In
> some cases, this interpretation is inconsistent with the SIP
> interpretation of the CPL.  2 The Proposed "Roadmap" Based on the
> "advanced" CPL standardization stage within the IETF, the following is
> proposed for the consideration:
> 
> For the current CPL version, it is proposed to correct the "editorial"
> errors, described in the following chapter, within the CPL document.

We welcome, as always, input from all sources.

> 
> H.323 community will define a more flexible interpretation of H.323
> behavior being expressed by the CPL. New "features" may be introduced
> by expanding the CPL definitions. (This "extension" practice, in some
> cases, is allowed by the CPL specification.) The output of this work
> will be included into H.323 "Annex O" and will be published as an
> Informational RFC.

We would urge caution and care in defining these extensions. If they result
in an alternate CPL which is really not compatible with the IETF
specification, end users will need to know which system is in use in order
to prepare the IETF version, or the SIP version. This defeats one of the
stated goals of CPL.


> 
> CPL nodes differ in their "abstraction level". A certain group of the
> CPL nodes (such as dealing with the time conditions) is naturally not
> dependent on the Call Signaling Protocol. Another group, such as
> "address-resolution" look-ups, is dependent on the System
> definition. In addition, the CPL "address-processing" and
> "string-processing" nodes define a "lower-level" logic, binding the
> CPL definitions with the certain fields of the Call Signaling
> messages.

It is agreed that there are different levels of abstraction. We will add
text indicating the grouping. The document is more or less already organized
along these lines (switches are primarily call signaling independent).

> 
> Therefore, for the next CPL version, It is proposed to re-arrange the
> CPL Specification by grouping the nodes, based on their "abstraction
> level".  
> - For the "low level" nodes, it is proposed to split between
> their "abstract description" and the actual mapping into a specific
> Signaling protocol

THis is largely done, but it is agreed more work could be done to more
cleanly separate things. 

> - For the benefit of the CPL user (i.e. the CPL script writer), it is
> also proposed to define the meaning of each "node" and provide its
> "design considerations" from the application point of view, without
> referencing to the SIP details. 
> 
> 3 Specific H.323 Comments 
> 
> 3.1 Thedefinition of "incoming" and "outgoing" 
> 
> From the [CPL]: "Two top-level action names are defined: incoming, the
> action performed when a call arrives whose destination is the owner of
> the script; and outgoing, the action performed when a call arrives
> whose originator is the owner of the script."
> 
> In H.323, there is no explicit concept of the "intermediate Call
> Signaling Server" and the CPL "destination" field will NOT usually
> hold the address of the Call Signaling Server itself. Therefore, it is
> proposed to revise the quoted above definition.

Clarification is needed here. No where in CPL is the term "intermediate call
signaling server" used. Neither is the text indicating that the CPL
destination field will hold the address of the call signaling server.

It can be argued that the incoming actions are taken on originating
gatekeepers, and executed on behalf of the user in the sourceAddress field.
Outgoing actions are taken on terminating gatekeepers, taken on behalf of
the user in the destinationAddress field. Thus, it seems that there is a
straightforward mapping from the general statement in the CPL specification
to H.323.

> 
> 3.2 Mapping of ASN.1 structures into ABNF
> 
> Various H.323 ASN.1 definitions should be mapped to ABNF in order to
> be used within text based languages and protocols. Examples include
> H.225.0 AliasAddress definitions for PartyNumber and mobileUIM; and
> the TransportAddress definition. It is proposed to introduce such
> definitions in H.323 "Annex O" and reference them (or reproduce them
> till the "Annex O" is decided).

Sounds like a good plan.

> 
> 3.3	CPL "Address Switch"
> 
> Current CPL definition has a concept of two, applicable to H.323,
> "address" field definitions: "origin" and "original-destination". On
> the contrary, H.323 defines many address fields that may be of
> interest of the CPL user. Moreover, more then one alias may exist in a
> single H.323 message. Mandating of choosing one single alias out of a
> number of possibilities is limiting for H.323 systems.

What is needed is to generalize the definition of origin, destination, and
original-destination, and then let ITU SG16 determine the best way to map
these to H.323. We would thus propose that the H.323 mappings for
address-switch (and indeed, for all tags), be moved to an informational
appendix for example only.

> 
> The current CPL version allows for an expression like that: "If one of
> the alias fields of different types matches, the specified for it,
> condition, then ...". Unfortunately, this option is left out of the
> CPL Specification.
> 
> Based on the remarks above, it is proposed that the current CPL
> specification will state that the "Address switch mapping for H.323"
> Chapter is "an illustration only" for how the CPL fields can be mapped
> into the H.323 fields.

Agreed, as above.

> 
> The third CPL "address" definition is called "destination". It
> reflects the SIP concept of intermediate Call Signaling
> Server. Therefore, the current mapping of H.225.0 redirectingNumberIE
> into the CPL "destination" concept is inconsistent with the SIP
> interpretation of the same field. For example, in case of the
> "incoming call", the H.225.0 destCallSignalAddress field fits the
> concept of CPL "destination" more closely. (This redirectingNumberIE
> element is, by mistake, called a "redirectedNumber" by the CPL)

It is our proposal to define this field in general terms, and then let ITU
SG16 define the mapping it feels is most appropriate.

> 
> 3.4	Location Lookup
> 
> The "Lookup" CPL node is a Call Signaling-independent concept. It fits
> both the H.323 and the SIP architectures. Nevertheless, bounding of
> the "location lookup" itself with the further operations to be applied
> to its results (such as capabilities filtering), seems to be a
> limiting design consideration. It is proposed to define these two
> actions (i.e. the lookup and the filtering on the output) as two
> separate CPL nodes.

It turns out that doing so eliminates the possibility of the default action
being to apply caller preferences. This is important. These attributes for
lookup can just be ignored on H.323 systems.

> 
> 3.4.1	"Caller Preferences and Callee Capabilities"
> 
> As a part of CPL "Location Lookup" Switch, a filtering capability on
> "caller preferences" is defined. These CPL parameters are based solely
> on the "caller preferences" specified by one of the SIP extensions
> ["Caller Preferences and Callee Capabilities"].
> 
> The "Generic Framework", lately introduced into H.323, has essentially
> the same concept. Although, the following difference exists: CPL is
> limited to the scope of a Call. The "Generic Framework" of H.323
> addresses both the Registration and the Call Establishment stages.
> H.323 Community will work to apply the "Generic Framework" to the CPL
> work.

That would fit into the general proposal of allowing ITU SG16 define the
mapping of the CPL parameters to H.323.

> 
> 3.5	"Location"
> 
> A significant problem is that CPL generates outbound call signaling
> based on a Location element which currently can only be a URL.  Some
> significant data that should be used in the outgoing signaling, e.g,
> redirection reason, are not available in current H.323 URL and may not
> naturally fit into such URLs.  It would be desirable to have a more
> flexible way to set such parameters, but this may require more study
> than can be accomplished for the current version of CPL.

We would argue that such things are most definitely suited for URL
parameters, as they have applications in other spaces. 

Thank you for your input.	

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Mon Oct 30 11:12:04 2000
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 LAA10556
	for <iptel-archive@odin.ietf.org>; Mon, 30 Oct 2000 11:12:02 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AD9B144341; Mon, 30 Oct 2000 10:12:01 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from crash.netspeak.com (unknown [208.143.140.6])
	by lists.bell-labs.com (Postfix) with ESMTP id E3E0E44336
	for <iptel@lists.bell-labs.com>; Mon, 30 Oct 2000 08:10:13 -0500 (EST)
Received: by crash.engineering.netspeak.com with Internet Mail Service (5.5.2650.21)
	id <VTC7ZQN9>; Mon, 30 Oct 2000 09:10:24 -0500
Message-ID: <6C5713970B1FD411ACBE00AA00DCD9A60B4276@crash.engineering.netspeak.com>
From: Linden deCarmo <ldeCarmo@netspeak.com>
To: "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Subject: [IPTEL] DTMF and CPL
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 30 Oct 2000 09:10:23 -0500

After reading the latest draft of CPL, I can't figure out how DTMF can be
processed (this is especially important when dealing with xGCP devices).  Is
this a feature for a future version or functionality that is not intended
for CPL?

Linden deCarmo
Netspeak Corporation
902 Clint Moore Road
Suite 104
Boca Raton, FL 33487


_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Mon Oct 30 13:59:02 2000
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 NAA17583
	for <iptel-archive@odin.ietf.org>; Mon, 30 Oct 2000 13:59:01 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8C86544348; Mon, 30 Oct 2000 12:59:01 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id BD36144337
	for <iptel@lists.bell-labs.com>; Mon, 30 Oct 2000 12:58:18 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA07741;
	Mon, 30 Oct 2000 14:00:23 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <4WS2Y1HP>; Mon, 30 Oct 2000 13:54:01 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF4C3B40@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Linden deCarmo'" <ldeCarmo@netspeak.com>,
        "'iptel@lists.bell-labs.com'" <iptel@lists.bell-labs.com>
Subject: RE: [IPTEL] DTMF and CPL
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 30 Oct 2000 13:53:58 -0500

CPL is primarily aimed at guiding proxy server behaviors for responding to
or proxying requests, along with some basic logging capabilities. Doing
things like DTMF handling is outside the scope of control it aims for. I do
not see CPL as defined as a useful way to control the behavior of an MGC.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

> -----Original Message-----
> From: Linden deCarmo [mailto:ldeCarmo@netspeak.com]
> Sent: Monday, October 30, 2000 9:10 AM
> To: 'iptel@lists.bell-labs.com'
> Subject: [IPTEL] DTMF and CPL
> 
> 
> After reading the latest draft of CPL, I can't figure out how 
> DTMF can be
> processed (this is especially important when dealing with 
> xGCP devices).  Is
> this a feature for a future version or functionality that is 
> not intended
> for CPL?
> 
> Linden deCarmo
> Netspeak Corporation
> 902 Clint Moore Road
> Suite 104
> Boca Raton, FL 33487
> 
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel
> 

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Mon Oct 30 15:50:05 2000
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 PAA05836
	for <iptel-archive@odin.ietf.org>; Mon, 30 Oct 2000 15:50:05 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 328A64436E; Mon, 30 Oct 2000 14:50:02 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from mailwall.tti.net (216-86-19-5.caprock.net [216.86.19.5])
	by lists.bell-labs.com (Postfix) with ESMTP id 6BB5444337
	for <iptel@lists.bell-labs.com>; Mon, 30 Oct 2000 14:49:19 -0500 (EST)
Received: from mailhost.ttiworld.com (unverified) by mailwall.tti.net
 (Content Technologies SMTPRS 4.1.2) with ESMTP id <B0a0a64074f92cd6fda@mailwall.tti.net>;
 Mon, 30 Oct 2000 14:49:13 -0600
Received: by mailhost.ttiworld.com with Internet Mail Service (5.5.2650.21)
	id <V7A8CG51>; Mon, 30 Oct 2000 14:48:57 -0600
Message-ID: <69DEAC407D3B6A48AA71F5D09966F7DB3DEDAE@mailhost.ttiworld.com>
From: Kevin Summers <Kevin.Summers@ttimail.com>
To: james.yu@neustar.com, iptel@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [IPTEL] Jurisdiction Info Parameter and draft-yu-tel-url-00
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 30 Oct 2000 14:48:57 -0600

James,	

Have you given any thought to supporting the Jurisdiction Info Parameter
(JIP) as part of draft-yu-tel-url-00 ? I know that the various Bellcore GR's
require the JIP in LNP call processing; I don't think that such a parameter
exists in the ITU specifications.

Kevin




**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.inip.com
**********************************************************************

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel


From iptel-admin@lists.bell-labs.com  Mon Oct 30 17:06:22 2000
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 RAA16759
	for <iptel-archive@odin.ietf.org>; Mon, 30 Oct 2000 17:06:22 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 92A5044394; Mon, 30 Oct 2000 16:06:01 -0500 (EST)
Delivered-To: iptel@lists.bell-labs.com
Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66])
	by lists.bell-labs.com (Postfix) with ESMTP id 4055C4438F
	for <iptel@lists.bell-labs.com>; Mon, 30 Oct 2000 16:05:47 -0500 (EST)
Received: by dnspri.npac.com; id QAA25051; Mon, 30 Oct 2000 16:05:41 -0600 (CST)
Received: from unknown(192.168.23.4) by dnspri.npac.com via smap (V5.0)
	id xma024924; Mon, 30 Oct 00 16:05:27 -0600
Received: by chi02.chicago.npac.com with Internet Mail Service (5.5.2650.21)
	id <VMZFKBKD>; Mon, 30 Oct 2000 16:03:57 -0600
Message-ID: <ED88182BFF78D211A4D800A0C9E9435CB1C7E0@dc02.npac.com>
From: James Yu <james.yu@neustar.com>
To: "'Kevin Summers'" <Kevin.Summers@ttimail.com>
Cc: iptel@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [IPTEL] RE: Jurisdiction Info Parameter and draft-yu-tel-url-00
Sender: iptel-admin@lists.bell-labs.com
Errors-To: iptel-admin@lists.bell-labs.com
X-BeenThere: iptel@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:iptel-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:iptel@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=subscribe>
List-Id: <iptel.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/iptel>, <mailto:iptel-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/iptel/
Date: Mon, 30 Oct 2000 16:07:29 -0600

Kevin,

I've been thinking about something like "originating location" that
indicates the location of the caller or the originating switch/network.
That information can be used for LNP/NP and 800/freephone service.

James

> -----Original Message-----
> From: Kevin Summers [mailto:Kevin.Summers@ttimail.com]
> Sent: Monday, October 30, 2000 3:49 PM
> To: james.yu@neustar.com; iptel@lists.bell-labs.com
> Subject: Jurisdiction Info Parameter and draft-yu-tel-url-00 
> 
> 
> James,	
> 
> Have you given any thought to supporting the Jurisdiction 
> Info Parameter
> (JIP) as part of draft-yu-tel-url-00 ? I know that the 
> various Bellcore GR's
> require the JIP in LNP call processing; I don't think that 
> such a parameter
> exists in the ITU specifications.
> 
> Kevin
> 
> 
> 
> 
> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
> 
> This footnote also confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> 
> www.inip.com
> **********************************************************************
> 

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel