From rem-conf-request@es.net Tue Apr 01 01:22:54 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <14627-0@osi-east2.es.net>; Tue, 1 Apr 1997 01:19:27 -0800
Received: from relay0.jaring.my by osi-west.es.net with ESnet SMTP (PP);
          Tue, 1 Apr 1997 01:19:15 -0800
Received: from walsin.UUCP (root@localhost) by relay0.jaring.my (8.6.13/8.6.12) 
          with UUCP id QAA02215 for rem-conf@es.net;
          Tue, 1 Apr 1997 16:35:54 +0800
Received: by walsin.com.my (UUPC/extended 1.12p);
          Tue, 01 Apr 1997 16:29:15 +0200
Message-ID: <33411bbb.walsin@walsin.com.my>
From: ShouJen <sjn@walsin.com.my>
To: rem-conf@es.net
Date: Tue, 1 Apr 1997 16:16:11 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Writing software for Videoconferencing
Reply-to: sjn@walsin.com.my
X-Confirm-Reading-To: sjn@walsin.com.my
X-pmrqc: 1
Priority: normal
X-mailer: Pegasus Mail for Win32 (v2.42a)

Hi there,

May be you think I am crazy, but I really want to try to write a 
software for Videoconferencing, not for commercial purposes, just for 
the knowledge of how it comes about and the fun of doing it.  I 
wonder if somebody could give me some guidelines for doing so.

Basically I am trying to write one simple program that does 
videoconferencing, however for the time being without the codec part. 
I know that's gonna cost me a lot of bandwidth.  Any advice on where 
or how I should start out.  I want to videoconference over tcp/ic.  I 
have two sets of camera and video capture card with me.  Should I 
work on the video part first or the communication part?  How should I 
start out?

Any comments, any inputs, anything is aprreciated!! 

--------------------------------------------------------------
Shou-Jen Ng
Walsin Technology Corporation (M) Sdn. Bhd.
Voice: 603-9857800
Fax  : 603-9857011                    email : sjn@walsin.com.my



From rem-conf-request@es.net Tue Apr 01 11:07:14 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <20941-0@osi-east2.es.net>; Tue, 1 Apr 1997 11:03:07 -0800
Received: from iris.ctd.comsat.com by osi-west.es.net with ESnet SMTP (PP);
          Tue, 1 Apr 1997 11:02:38 -0800
Received: from simao by iris.ctd.comsat.com with local (Exim 1.61 #1) 
          id 0wC8ow-00042g-00; Tue, 1 Apr 1997 14:02:14 -0500
From: Simao Campos <simao@ctd.comsat.com>
To: schulzrinne@cs.columbia.edu
Subject: Comments on the update to RFC 1890
X-Mailer: VM 6.22 under 20.1 XEmacs Lucid (beta10)
cc: simao@ctd.comsat.com, rem-conf@es.net, rvc@research.att.com, 
    gschroeder@tzd.telekom.de
X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p 
        XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P: 
        GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<}
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: multipart/mixed; boundary="Multipart_Tue_Apr__1_14:02:14_1997-1"
Content-Transfer-Encoding: 7bit
Message-Id: <E0wC8ow-00042g-00@iris.ctd.comsat.com>
Date: Tue, 1 Apr 1997 14:02:14 -0500

--Multipart_Tue_Apr__1_14:02:14_1997-1
Content-Type: text/plain; charset=US-ASCII

Dear Mr.Shulzrinne,

Please find attached a ZIP file with a Word 6 document and its
postscript and PDF versions. This document contains comments on the
proposed update of RFC 1890, as reviewed by coding experts in ITU-T
Study Group 16 (Multimedia Services and Systems) Working Party 3
(Signal Processing). The comments were initially based on the text of
the RFC 1890, and adapted to the proposed new text as found in the
document draft-ietf-avt-profile-new-00.ps (as available from your WEB
site).

Please let me know of any problems or questions.

Best regards,

Simao F.Campos Neto
COMSAT Labs

===========================================================================
Simao Ferraz de Campos Neto, Sr.MTS  Chairman, WP 3/16
COMSAT Laboratories                  Tel:    +1-301-428-4516
22300 Comsat Drive                   Fax:    +1-301-428-9287
Clarksburg MD 20871 - USA            E-mail: simao@ctd.comsat.com
===========================================================================
  ******** Practice random kindness and senseless acts of beauty ********
===========================================================================


--Multipart_Tue_Apr__1_14:02:14_1997-1
Content-Type: application/zip
Content-Disposition: attachment; filename="ietfcom2.zip"
Content-Transfer-Encoding: base64

UEsDBBQAAIAIAKWKfyKYpr3PaTEAADY6AAAMAAAASUVURkNPTTIuUERGxXsHNNzN97cSCaK3
qLE6QVbvvUWJ3kJILBYby2JXryF676JH79GDILroNaK36IgkOsG74nme39PO+f/+73nPefcc
Z+d7534+d+bOnTt3dheThpwCJ/dDHlxspuUvQ2O42DwALgDM9AUutpgYLjbwMdjWEmEF4Bbm
FUY+KUCgCLADAKgABSHAcmAzmDkYF1tCAhcbjnAAg2xwsRWDw/RV4F/qCJvf9169idShd8D8
1pQv9GPytU6jU3idaKA9HgGWQdCpxkl51sXhDG4UD5u1s9bD2EzMo/3tt1Te6m/fSszZm0TZ
vn2btF3HXXdiqQda7sBpnARh5awext8F1l14DSzmNjVX2kduSycbP/d81+yhtqcXiT9b72nE
Ce3y/fhOzEIyqEuN/mdrxtW3vYOMggjhMtj4Zvy9brVFaRK3CFoKfxbchzmB2+zWukFrNXMH
A31EGjq16JGcL5lYeS7w65fxyybFnJYxoV9dWLfIJJvGRIkC7Uu1gFka7Af03WbZMmTW/hOf
u+9cdNbHYwWYHYUfjmW6UypEGB7EI2Kp+hUvYi5N88ub75ClP+2vI47q6Q82HZpMfVYrHAIw
JTzNP5R8Vs17lGrevOeX1v99I/Z1WqsJyxqxV8LcG9tnS1TPdA7RjlXn9qR1hGcP6ot2n+s+
tFak0qw5b9js8jQMV4ko/ygYsQG86gABuc/1Eqkjvom/sl9kfOkkhw7kcZK4TJ0vGQ1FlSIQ
kUjxOqFDq/CrE7vr05pSo7date7OPyvMrvl1OyFL88P7rimf4k9qBXkkn4gOVBaUCO7Doy8B
MZVe2GuxVg0MLlxVNEshw7S9dG0/VABhdcQU5x+eDk34cm+/hkd+tT7UCkZLTxaJtQmV+e7/
VpDjoT65sxmaOjkjg8suasqdmAiMxmalpeem2oJZxVRMM/40LqlPCzm8fD/wzMBf7+5PHqF3
vNXjvtsl6tP81Cp7u63o4dORVpvs+ZU2PNeYJ87L3rwGWJF3ZBSvTOW+KfV4Z3z+yXlKwM3X
dyy2DWcjoZwo0hr37muY7akWaRhgwiu4BHtmt3v63u8SBa3zu7HLo+OHo29DP9/7wF9UtOLQ
LwZmlfAEaQSxA6lLPEtMGJyzJmXCq9cNnnr627KA5Hp/DkSxqVOtvOgRYVuK46p2+trhJQZ9
HdfSsL3/RSOFg9qEHEL0Okil38KhD6B2L809QeAH430xVwdb6raJvN2Eb+BW07t4js9XyssJ
Cf3d4i0+fVqbP0rRcuyiSdEekdfGS6ILb6soDc2S0GAzaVA2cOTk+yHPJ3whR3Xm+VAE61BP
kv+Hag1P4NtN4i2zaP88G126gfZa234Z3lgDIs1N/7VCNkASLd5FTlltZTTpBD61zjveimD+
B7O8RouWrVZXfkUEcIy291vJDU/a0vuLz2uFfA0nm3VHMJrnS7t+BgS8GBRCBSv4KZKxlGWL
trdFlEY9jFLRxAkQP5DPV37Nzq0w+dkuSc4lWSGiA7JSFmnD0kdGlroZVALezxteYKJ22jiL
MtAcXKKwcrk9IWzMubNya+pu6mp2Bp2fD8NljPbddZZsNOIjS1XQvc27hdtEr++kmqHk+3Jq
xwhoiXUCsIZkrXVonLDzb8lPtjHr1rzQJjigDC90AjI155Y3bj5L+ETpaRMoSUjkTZxWxE5g
kD+vE+ix8dPnjm+FWzNIFaBwSNqorviT6nWwlq8QZtjZHYdhpji6VATdRr6w6oZWdrjISWra
PgZtF5lvKuhuhitxi392MHcKAE8HA5tUgoPIWopsQG4Jo4fPJnx8KZDWNSiPizV3h9U3qLR3
pfsL3qMHIu0QIURwOwow3N4BmPi0hJPG8cfC58tzZgX36KasEzq2oja+BAtx5nGXxXpKfD9/
lg/dyrxxlFT1b6k+eb54xMyOff6hiVXHmboISuBoceHaUIqqiEk7xRGOr6hLPkPYfy/Wv3iY
nH/yQNcCXfyOiNW9Ddcd3mO1DuI7xYIyZcGsEkHfm9iYOGywdOdAr9dP0M5hTxl+GL7WLJ9u
5ef4JCRyzEEB6Tm+LR+HkVfVUgIJi8Y9xf92r/PeN0GHPR9JYxxPy89PUya9lKRnGD4XlHQ3
w4rGJ3Hph6hkSWiL6NIRVQY+BiSDlV83S/YhX7sfnyN0hO4Gvokx2G6o9zQU92F9Ziex5cQk
9vSY0NL8qOIr1cftknyLo0a7ReYh/hh5TerEFewzNwLOvNtWd09zUlhUwoDVmY0KiQH3Dvz7
RwRSq4mDiT/EL2Om+NMYxDyE3/5cr6/IQd6opt87kP+csGgv7a1X7Lh4oTS5V/7qEyiP4FC8
MI4Q8QwOYv0Z/Y/ayg2pHcKwcwXNOyzrHeXW0HXKD8muEH8rN/xNcAz48smHqwL8H+FbOC9L
v0tXKw/YK7H5pLnIFm0I+r9wtmrMDNIR4bDIlCpLVBUl6md7zIjVKqpw0Gfe6Pmowx37DFvF
+Bhrp2RWK7TlxffnkjqH0gvuow2fizY1h1iTVwfqvmzkI/JTYilsFfp04kk9Iwq5sQrPHPzY
kqfevyV1DOEP/nAVRbIjSOEoykfUaboc9azm/Im4yuRrTEorHF8e6Vj2j0XSx+BLP4Xuk4/4
1jHS7RgOJnm1D8bw86Mj7vfnBHLUiKnSncuEJGTS350U0NKi0zhuV7srpysqDtESYVdSKom4
t2//AO/LYS2soBcguwXQfgxvKd8zr7hCj1RbF+fwV6B/1W2DOpItsaw66Gv3nctFZP2ZiPRI
WUWcerhZZmzP5veZWAriy29iH+kTLdi/LmvSCWWUXi7Ub8HdPA/PUS7v+DLgYoNtzX8/nZHN
Xyc771+OeA0HmJk2GAF4CkSWAgCgDtgFATC+PuxhtgjALw0FHgAfEqJ13eQD8N80r499oLwL
4pE2AlkM3Cg+0uYGCPyn+/rvd5vC/1ZW8PLy8P53ZUWqvip85iNhE7KsAEWYhFCDbi80Q1af
OL1o2g5JklXuRb0VwEhPIIWiwXexPTbHi45GUGNfC30JEEra9Jq7ODsEbh/v2UooMU+6nV+m
2dVT8d673BSlaH/UksW48qxlIvB4z6jW795X2lszjt/C35e/SFvaP9y8EA3s6Txb2Fsozen7
AjAtZl3UOoFeEKYvmUaSSYo8v2y4RByf6/dIXnq9e4JFKNf8JfjT52pjJkKxb/n4lzWXVMmb
VLzGZEpfz7h3t0cTBpuKdFISUgc/nJLgqOj7qgxxYNz1aPqpFEDIa31nz5UkcPHcpHS4zH5o
v6fp0boToTDNzwr/g1RKHNw0TuPNl4pEMCXni2cV798Dt/mLX+hNfFKreewJbGh+Wlnd+/pI
Ufn+WbowIR7J6H1W/y5eThU92Dt5vZxcAcFFeooZoUZfVHqqpzW6pUU8nyq8KrBHHpfjc47m
d4lhr65qBL0V55sItN0+QjmSUNqMxhfJefbRj1FKCGPy59rp4IKuHi1eUe9Yc0ExntN3g3dv
I8FlNAQOt6u+7ZJ5mRsVbBHPcOgFZ38z3TmqJzfKkGPBHLC2+p54KKln7dQZxKQNLDLtNGVi
wKE0wopbq2MLDZuYKj9Z2cRc0WDB3cnjI29eJGYtfyxmJj9W9HjVRyIP3RKfP51NLD+rGK8D
2yFHm4Ii/0PaEQGfp3tZ5ARR4h0vsR9TWbsBwQopvgNnZ0SlVFImax+cnmfTfmdMZnQ1fxf2
+GRb+bXP65ZuMR/yiCaaRI/i0dQmf7F0MWBPfBlviYosrnfZwzRYrrIoBukEuxT/LtY039DT
T44a/AekrawiRrICXuxjjyt+fvSiAq+vCV1qtpsHacQMnaUA0Vsi5B/GZTK3f/K/osY8WVFV
edMMDJaxhG1KiZiJPlu6RZr4cUWdKCmYkLZoNAptrfcTJXcEyyz+Cj8RTs5UL8m+woCTibpa
goB8RoL63Yk8H69QUCGC7HX4QiZ+inLVRe/ZrRRzgtV8DALL7iPIGGt5TcGk30Pa2529Zk/c
hxgoJDk5Qi45ZhiPb9Fszz7S+kbh0KIUFSqbhmvUe+laKP+101QnpKKUCrRpmdEsdcl5u+2H
T3LWZ7l1na2c1oD+pB9hndM05QJqbd4HQPOo1XTzoZSsD5tQpaGh+rhqy+kg5nvLpB7t6987
45cU575Qt2RE5IT4YsJFDDYe8DT1851OklX6GPHVnVRIoysCFQZDaW7jMmmnegZYNRc4KQWI
FSvcK3H8no5X3/jqw6qjkxyyTrr9XUzUZs9uqUJC/1xZ9BjifYsZZV61QFXWXAGP8DNZgNdL
wAEhO7xLTNPG6hWsxgdVeZXasHnPg85tj7/ni59KGkB29dZGDE1xpUvA6ClC0OUz7ld5sSCo
iRSjMefYWPPHIw4M2mL/lq+2/RN7au4x1a5QRkxlYlaan5lJwzS28QnG4jEPMGrnQtxgY2Sk
I2ZCXtjNNYs4jS/n6FXYa7XFVQz0BC0FRuRf8Vs+P3jn9VxnSKSmnFD7yWLvYGbhixPRF7AJ
79fgSrvAb3kmeFkcit5Yd3iU+O0OmAfS1SEpzrcfD1Por/qmTKKgleH6NLD1ZklWaY/ssXHQ
qxmlZZ+ifceoqvBMMv5SL1D+oyfOMBcwzmYBr/NVrpm6WJFafAN8nbCFFw9XVakPJpWxwpBT
duytFfpG8UqlV67OkGfzraLa2Vdl7Ta7eQAXsWCdgmGF+JLGzpF4EOdHw5rMcX7Tvv3GYv8E
xjXVjerFBy+olKYVIuQtFB9z5ZLHwc4+7VZI1rZsps7p7Uxmlpmy9Fv436t9JKvVuML8Xjyy
7x3q2EdLDRp5vM4Ms8jtiPdpW25ykf0ybhWLUBLTXjUpwk0shrlKvSYSmubCZtkXTrTzOqho
lMJRlgS3qVe3pFVYii++4mo7hfeG2Lw80dGfKc3bZ9rEox0diFVhpF+gyw0Q5GNexD24d8ZH
mHc+I2ZztiwPcTF6iLrDjU8FlyB7+uJcPAJ/IQKcr+fsWDb5WUQyobZn3uun0/Eh5I08fbpy
cqUsgRITVSvS5OCBK/etkNqXhcXAorRLN5+5hfLNETql24uPozOpWfFUC6Pu1mgqNL5O0P+6
RRay79OSB4Ro5qVovaG0Gq3thr9Rfgeje8OeMczlRmD6XQN2TvxjvqFM5ci6AjJ21F9r40ku
90UWexWbPtuTjafGXEGojSF7klX5JfyYguh5kKBahsBhBzZGqq70A8Wgc/ThQfxPCUHnsbJ8
qbu6R/1HngsedfXCaWqNG5HUiuR9YE970AU7+2MB88O7ueKeU6mqlz+jVeeHBTiFuNBflsvc
eyfP3/d0J4me0GQRxQi/xVHWftM17w6Lj08orUVSW2DLCJ8NquXI8UHSvZp6Y8x7QegPT2nz
KtA7c8pXp8Q2Snrh9RlWkHVXbe7Yya5jqup5/GFPDV2fAp9oHKkMoQBSd19z32jnO17bAibe
P/gSfLxK9w6KESqhGxE/4q68XRYSxDf85p7pp+itYRKjCtTi8sqmOBCSbKrgPk4E8kfJ3qoU
EYzHxB8Kdw2Rrtz2YlZvmjwyhKF63PJWgFHOBgEVdIMXo5P91Ae84wvhVnmvIitQHMYONjJ8
eh3O6uTbC6akN78X++klAYDnw0dmezyWp37QKtw9suTT9GqCccWxakfseoyJowIR65h0V1we
CSeR/qR9LhRMwOUblghmyZgLhaFAv5UkzEs3gp8O5LwKgyLqDfYaBfltb9pbLd/6V0WfZ6qz
iHsOK6av3jNZMnXv0tm4N5xw7KJZG8s8XNYxM8pA7swzw4VKpSNjx/1EjpeKaDfwbB4lksTT
tdav6xZ+rGmkWmJ6eOrL8TRVzy/CZhzC4Vn23W2mUc/1Bl9EAend2j4IoBdUaYlbUTxAi9l9
6WcJiyQ9TU1YnZJZ055UiBIX2ZLsXsYwvBUyMn07/KTeMGbysLSzLePORU2/qCbIL5OSwUan
T07hRaPCK+5nUAJsC0wmv7WqU1BywcOi5LC5Z6OyAQ4CCjhkfXbjys8dLflyKEsopuM+8d4V
yntKwNVRmLh64LnysvvLppT1aJ+VyA6CfMPHxSsd2wQMrRYKrkegz0XL7p2tlmi26cdqsqm7
yLwIxjbrcg3muc82aXXkUjbF8nPZwEY0lkeR9xAtVmjEDDTiXDSrldzO8LOH+Vx+hpz6Fn5X
dDVCRqQzp4HWn+EWTlr/4lv2gu7xDusX970NrfZy8MeyrkLI2ggpJEUWdN6rp0SYvAorUXrj
9tVfQbXLXSzq8qNtik+b4CIZuMcJ8HwK1fGkVmeBs/MLQpmDJWrgLWl4j7SD1hBhLbfTofSS
EPaDUkCwDKl/08wJeZQG+SO7WWu79sbBCEy8Foz35jYjYYcFttTDd6V/PBgLsJU4xaGeXRYo
kLtlE3aAhTDRU6xqcx/wx3sgIo7QkY0/F1tEFZ2yVQfkCmvgUd99M55gYzcoh6WXcLjpjc/B
E1yH+TDcXoORp4FLAtOD4Dsr+9KXdQtyrHjSqVeHm7PRse2NmxDVJTHvy1ZF9LKSJ9LvGdI/
rlCCVUSfXCTu/9hUpcLMOmnSavaLfBb85LtbRYVbCKVOzQumcbt+fxINBiamynCNZs+F/q8u
A9PM9viL/B/Lvdcu1sQrwUkKZT8mF1epsSikuznHQwfdLOhLKF9cNZVL40y7r/zImseiaeWV
LjJJ16wmx2faLVM50cAk1psk58q3ywXI6FMpuCDoouo4iHC7QyGEq96VQR1Rj7IGpNK/3T4b
NULox9Ji0YK++jyx6c2UkEymabQNDM8JyM5ILEmMGDhxu+LFkqOZxgVyVJyFee6Q6d7m95l2
U/e6qjF8dvXkbVvyAenxwXFjyo/mdjQfrKqNnFGiwYc2u5oCe9VhLycgqwlM8hOOmM+YGnb3
zAd1UPeeVE+M5MwmPgrpvp/USYj1vst0Mlfj2RR9KUEUhK0lEOXwuKIoqPa+B3OP/WiKZ1VV
4HujBe/s7mLj8Gz3RAfWuBxW8VVzsIVt22wuo/DSg3wps7ceDV/aexcXqc5zozRCbBWqOlqJ
mLKAUS1OHGatDNWk3BuEhlms9rJpZ9+qkrGzQ6lH8wLp0HezB++TRNLE/HyFqUT2aEzjgPDn
hr9GRXupFVFIEncHwza3tTspzxTB2RpOoRUzPm6Dqk6FbFKV935O/35FdcgsoyV7i1mhM+U6
IqJw2zeiJshdjGqqvy6yHlSXKwhGs+Ke7WihhNQUr8/dXlTo2WPMAdH6xeS63cmrTdFfkI/O
PBJ4NOLQRrlne3FsNgbd+YZHKrOWCJsfR5N50vHoXcuwzbv3aUDGrWX8klc80zaEh34TUzYs
q4vzmGCJR954LDpgflEW61eRLy45n5KxsdA9JyuU3cRqgH89Xwv7mZeWFvf9rhieKGvmniZh
kfTWZ9lP5V74yvkfMX7C+g4/5Xuj4aBMP6eY+9frGzfX/4v7G1CBH8DN/X91l+P+6wXyt8sc
j7Dgf32ZM4bNCJF5AoevWhIxzFtMDzjd542cpzeznk+6ONFuuZqYT6/pkDUR0bBcHLrvMbH1
qaWShaJU5iguXwitz7YLhn5+azvPxGEReritb9+RjRW6OJTORHzSYyDM6ZJc1fn1sDjIZtH/
+B33DMKuk8HlhebSRef3w2Kf3OzOhbfP/ZU6WFx72njWlVIrOp/WBeLnH3x7t9i+F+q8D8wg
ujzq8yDpsn9mIU0ZmCFHpaZSF522cGL9Xd0o67GLTtdBzcey3mzG7PgPGGmNiaUFU6w9vp6c
/Ybv3keUyVVlPc/ezB+1YWfXlpx+JP+Zuyp+52KXhYxULCIpOg10/C3IVnRQQkrItQWKw7YS
n6eRIZEdg4bV0ATFyV4hfibTe0ToQb8pqwqNFmmKVdhlFH1QlVvjWCxQRFjD+Sz5h1hKOdea
fcJRRnCgY9mBMs/H/LHDJvMT6QRmQfvWr3Eg9zlK+/wX4PtTzZ+ca17JUL+rBMXP7y55VYEa
QBm2C171q9UrA+/76QCmoLaxk7gMG9g3x0uIxZiKKw/b7c1OiabC3VvxVPevxryn/djXNxmP
gEfA1TJPKImar0H7uC3+dxluf02CnLyttzb4Baoac0kDMgF9HLH0+Nb2rxILK96Lz3YebBhW
j6aNpx3hhqH2rAJ+jsoTdZeJLj8rMJQaSXoBleS5y7vzSPMImHcR6q+C2n5efsJrVD7T+Qht
kI/LxaQI3qd+hz/zhxqNB14KbqZaGTScV0I1zw9wXmMUPKBHXtRl+LlGwrRLQYLc8M5CpFn6
ao9dWuNVW4c8ux77k4jlMRJGL3UZzaUHweUrdjkpNAhZgfidJF+JHGnZR075AxMWpMzCwFDz
oEnUGRpzUQAJotqMYsglVftqo/pkoGunmuUNbLJYqFd4vDgJhSH1MhVQ/zgmDv6VZ60TkfSW
xXjUeZ03LsQz9MuHrupqFzR+1vnC4ywz9xFKDoWXNaxQNiP3w2lqQuO7pdb6aAUuCalmOYl5
kVtlpKWfUsAoi08iNjzmttJ0mU/4LtvWp0oL3oy+q2zSj6eueltTwPi0tXSIxELQYl+yTQiV
qDER1+q+SlYFseITex4cOuofvK/jHqY+HU6jrSwNlk6g/qSntzA1kXQBExTs/hLNDl8s4u4j
tAyVgNETv4KpE0ATnACNQUaNde6IuH0PdisUMdJ+ykprkU0S4PpYlgtRQ6BnXPfDg3ijYgVD
Yf3wu9vPK5cz737nC0CczZNvqN65BeEMwDVnn44/G9lWDvbkRGfGY8/FIgYsV0436zxWYSiY
us04A3WmIcG0S0qjm1QfMlVeDJfmHrvfaMkjsT15JwDzVRSgWBRrSWYINSErtiTeeiqrl2F0
SAsDq0O3G6AJoEQTep8XuLaPH9qJm7WB/KqmqDFX5Vvz47zESk+BQbeBFDzwueTwDyXA5sfy
oxRKU98WKpvMgbCVLU1aaublsP5WpXnqN+/QhncUrPD8QCjJ/cCweMZ45kOi/sIQz9IV+YRn
iQMw1CzQR0FWgg3ogurg5fCjakKz4U6lchqQltqS8s4qv608eFnP6laYKbVhDmVFLO5GwLx0
hn7TaEHXFIFKInjY5vDNEWNMs9aQlSnlOnVRYiJxhPGksQ5r8tkEAYAvXDbc2PBLKygVq5EL
YdnW7Gddtzn5pt2Sfe6n5yQmg2yGiBWfS/pdyD6Wc564zhqKaiCP8rCwrv+GmsypBhu1lYlg
jpWNqfsw1iqlxVj6QkDV6R7th4eP5LKrSsQjRz3a3qi6an7jEAfPqngszbynlu7JNnn8yJSP
hJbez01wehRrnRyviX742bhnMvEzKWnugU0MnqV+4BLzK359dELNPDN4S6j1rLlPh7R7Cew9
gMHH88QclLGT3ZRpJpC0Y0lp8DggrjHJps+ERQq4d7A1IstO4RLGG0oQ72XegM0Dl/OErvjJ
NZlJHfPJN7RH03BCdwXhvh+JTT9vvSc+4+gU9lTKNi8Idp+y7WxmcLY2JhSdovnUxoRjUQHp
9LrLgXYXtQrdjV1PsobQVWxV/m1HLowt5H6BdAg67qRmYQ3aJF5+X9R7RgozJ7WHkb7E9cqM
+q5KZYkKoSx2ZK5oGUku9BS7lukslJd90bsdvFrelEssJ0MUzc5MZAcN95XuAShfNo6hMH+o
j2dZ8lhOGzZ+CZldDOg/Z30rtY7hWciovv6BdKd4Hsv7ivaq43bChn6jTuphzD78ii+7xB6u
1XcnKpwgGV6QCeKyEvlBb13EzJalMvzV0MOxdI4yXvpY5dNWtGfAGgURuZ+0DaMdkZ17Pkrf
Q4gFgNYiiApRSKL4ZY0ohDottVwucX94i1IcHvB6G7B/LoGIviDDVXcjH4k/h32hXsDIaeSX
XJVaDRjobwr4GogmZBep3BTTRYHx+LYbqlpLYwsKLJ6qVCQsB0cAJWFiP/NV85X70ZHF5am4
wanDMMeeELAR473OvZlIwTLaMzcubfVuS9HDLqcX/RFP59IqZgVWY9pl121D76friyPA+Qua
qRifU5IeN+qkOa8ZIOwjmxxL6RIsiL/yNwoEndCPvyw7OmwkC+H196yIxBZwN8kWwaWdxipo
Z5OtsjkEVdHsrCfwoa8pTgiWFzYNC4zfSuUYOupCx3he0aB8e3Iv2ESU0WOGfe1ITC9ybh6r
8pBZg98nbS5T3Vz/u9wCBQic+NB9zKGUwJauw6hUxAzVGTv6Q7mx0v7PTScml/xtQ1pulOrv
ot83nDn5UrwFXMb4hPeLmrQOxdp965YMpgrdpk1PJ9XxLHzCWLKmrHX3V7wT7I/GZUaaRxss
SvAdL07Q8PtQJ5/iSvgv3oo168vx+cjfMMBt8rXfaTSfis3YqGvOQPo5YMhvq9brkOz5vigK
PK5yc6bpi/4XX02LlAh+RqAfP4Aw30KfRtSUr1YJ4/WspdHz1JPCN8cKu+P4mJOZcS9Gx/R8
8zcy15tVL/Qe9jK37zFdBFVj02p43pp5kDnrjY8Wvj+Z3ErSrybmebv50YMM1dZqtEDnfGdx
mVl9RQiIJ+ii+RM+dhB6ldhVt8koT3I1pvZX8lTVu2TMYv4XYRmy31F81cYCizzpxvVEtJN8
Bjsmm/PSi9n4nLJxWOmMES+cC8KtciTq7kG4prQ1PmOOk+J9fnwnzn5L0NAk8daUzsd7JzYD
YU0vkwIXsENQk503OBZ6JASctjSJOUgBaiKvTzU3bSNDMi9I92I7TofDBiYbOsWBbK99g5aD
NnsVx5YUtXLeqTUuuAxkb24Hge5wEPo0w2Pkf5Ibgz8Lbx72lJ3ElDGhfAoe4793JVodVf1h
qsiJf1Jvw6JfYnFu7RyyB1rxo8t4H4Mihf5Awkz002K196z1z8j4VD47i4e4LaczxHNl5neh
tKLT5uXrotmqO0eBrzze6VYOmTQbROo9Ahr6+igw+sQA0cmFbpugEt3+ppuiUNaSLKVTMOK2
p8o8HUDOiS5310+6JOAqaIO2LxOjjJL5q0nQyEVkMD/FT9N1SsLEZZUfX/hUTzub+U+f74Or
pgEE8kuemXuLlTKmpo79IlEytJl9tjKqMlbjPnjNXkMX9tRQHvupcDxWh+7649R9pqdQB+Kt
fFa10M9zFHc+rNR97i5EtVimp9P4vu4hjrkjlY7TEyvxNiXiUSgpcaCCGhhGnpKtAZ3yeOpQ
qkgKwbk/H1igWcWoW2+s9En62YWVm8YtxIfAe3xHhgqv3ks0z8vri7FYMT0RqaivVT8ljREx
3H/aQHNKSnrVk4i/SQq8++Fr6UeSH2IQlre3HRPZOO5IyiRiMD4YU1bcfkg6vC9FbzQ13UOi
02hbrPK5oiYWDlcIexxTYUxad2ViNLHraeJ4+IrkgXPF8geUHZOA+h7xgZwxEdxp2UkRWgOm
Ucx3Pyi/iTyq3ld9g+GS05f9gz8rUYqjVAYgGrxHHPTpYmBJ50vJZwbjXOJNOZu1J19SQ+1Q
g3K9VZ4y6KRVRpEcXp5WnmD0KAOD/v26wff/4esiboF/vWII8An8d1eMEv0ehy/I74vYZa40
ml/iVd4iETB9iFfjRiHsFkpm6WF1ioIqTzT2RAiF1dB7L7HG5E3OdyHTBllGjVtFDq6nP1ZT
BlY7P7m3itVOPXvm8tD5c3+ntyfTxAm2QarcLP5UXkOj3RQe0KNuf7Ksncb5+zhz9uHA5o82
UKvp/sxqp3KdB00XlDTQyAV1prGTUnynOPCD6Ls9gT1YswfRz93ElM7e/TYhOw/YIZuNvlKY
v0nzt70ByUdfbh2jLZBv1NM9d+eIQLvfOS1FTc5u1iwq78gKZtqW2A3Ns5DvHq20fnKWRAY+
01BOMMXYdgQ62xhWyk4flRiUmFqq0O6k9Audt5gtwSOrrCdXRXYq2HjqlauaXTjOWGwo8XAn
oKv2kSUuxWixVuypRkc82uv5joOVedMCQrm2IWqVaSXg4vD3zl5NXu6O+6ftF2h6X5NrN45J
26tKFlSsO05CsfdVugPSHZvN7hIKzUlbdNZG1Tewvzh0NP78Q3JrK9wp5KH7j3rXtZMY5AUA
arOqV1s5yPjeAKz6cKpvxJMf8Iw+DOxN7Z1EGE0xUnXCng1LFy9/0upCBXA08/x6sCs78iE9
j+5ZWsl7GZZDMeqtWtXtsgcNER7xNjPVczE7Q6u1BYTGvTqfxEi+FYkkeGr2NCoauAnFyeeh
jdsf5W0exw1+LhnxoahS93mzs8BF+q06vs5Fjszh6FuHlsXPfvJBn8MYdp3Ue/ZxGsFy1q3t
cvFBRXLqullVrUeY1uoV6tGv2u8/ou5LdRRn+qJjFWrgBI3+mW4TWpsiUXKf9Wzwpw/gCJuh
nuPl+c/81/JAHVsSZrHx8WUj2v0sOmrQnZMUdPJ+ZwP/gZlqGQHh9cqh6kT9PT99xb6T7Uep
G11n7NUfaE0JZ3A5trHu+2Ubpfg9XqKvrUMJmBjcXUv8ZNFh1q8QhNpS6RYlTOFxcbQ9kK90
mn4kX2spMifBOnI8wG0eY6lVficEgSyOiKy7TXg0g99GSwdLVVRjRCVXcIjntFBFRy0bSa5I
U6ui8r+ZZeNEG59PZsXL4ICltL8pcN55WfmEgEK05kzH9V0hFwmOyPFnbdqAuUAREX6bec1o
tyIPsSLaQ4fMfqo5lepziEFvN/1uLp5MizwjMwt55vItyRHNAnAkrxdK/qGaU4i73et7eR8x
R2RvJ+TRnIpxv0FFKUV1soSlPbF4cO4Jn6UDtzlv5ekvkCQ1x0PkVzylOInhbLP4LkEJXY/s
bSX4JW2aqaz21RWPZac1H/fURp3z6mTOURbHDBtiUAKickJ1FzO5ZswmaFsxzhTHIzGZQeG3
36L1QeUxmuUZIFFkjE7qtAGv9LzaxIGvAywoHW0qHb5Tz6bOHemUzNk/gkTJ6ULw9bKI0G3P
joLFAaRFXBsbTbvOTNuk59mN6PeJQi/NH/AIkG5WxifNEFMuZX7DrEN7osmR+jCXGZF70sqh
2VB20GBQ2DCFXieeM4UPSUE7Lev1fOWPTXX6Mug9aHFyl2CzhVDFm4KD4kRCR/RscJ3dyg+A
TfSozm0s2iiO3eukEYA7xfCOjfzk1lZ/GEGURzfhaxQCH3KXTCnHygteKCU2SGlo9XI6wyVr
5qqeWQr79gvrB3z7RoJweQcVJ+Ar2rIEjpaMSMlKvRICENViItVrhzG0BaokRKZSJd3AGHpD
qY6ga4XuchYQBc9QiLpP7SpH5PmnlW4tg9uhaJydUhrZjMJj9ANHkRzE6AwKXTzsFctszvfA
hShiBaS32MEz2UVNZBe48v1xeFMPuGVSNkzm+Wcu5eYMeyJVx+LeJn3x4Lg/Xe15BufkDPIo
X5wcReSKSt4tkbSGaC5mvKtGndoh8/AdvnLaUQw+0sDPc8tIzr4Mbkh+ABrll/Qb93DIMBLL
UQfHLp/m+437N5rjd6d7MA2OL9TvVNYKafDgDFmFrk1bD/JMLkxIfdx9TZPyUrf0hdGl4Uol
KBk3Lh4Mz2LuMtxierVmZpOTiDZgEORoHKFLSymew0OT2j22/l1qWyQd03Sgf6yP2/a5IAfA
QAjTSQdnQuwNGSR8bje+RUsd7fmTsEt7i1nljEdkZ83SyrEG0OwnmjiYiuzv1yYtKkUFP7cL
rajmvoqm3FGTeICmMLra0vBG/FNjAKNm4ru9LRmnrxhEzl54kZ9jE+5PRsBVkgvz8XsBn5g4
AlvThNNX7C1R5XtKtBpe4uXqvFaoVATIEVlqxfCZhlW1t4WmRkgE1OOmltPkhhZ1YnXPeC3P
2kg47AYvtmbW6Y2tbVJ2HurWnh8MF/5MdmpSYIp4aby9qLMZO6eJY+igIFBWbg5X3p6K88NT
MpyX8sZXqCJkMKdaIoVzy7nlsRv1xk074/88Vh6HvLR0XH9t7t6albaj20FArmpwHKFZxs7P
a7FKiGGDgd6QC6oITiCydGttn7WKI/TEmhOVmPU0XWhufuo56yFvOVOrCubtzABpSodmKpZd
emukbioIBiuQZq8ZNCgmODU8MDQC3aJnW6AkDLEbGvN42PlBNOMDVGH2FNv5suQOwcdM+Yzx
sk3620l0/utVD+dJXxnQGMC32LVwzFfDzVCUr6SCXHP6INtf454jLFggj7fBkDcUD3KdI4yh
HDIMCgHL9BK6QPl1UlOMD3sp5fdbpDTyYxrlX2qFb+kTp78yFRsMw8Yjb8HheNndrm/HNyi2
saM6o92zgtHhVVpk3tPgO92c/DilXfvpzlFTXnhJK+ocimUSb9Bdm4Q99hrBabBU7rCVAR2J
5UAsveAtb68VLs9ovIz6bEOaJj7urQA2+WwGPqWA8OJ7r4Vfapm8D3qTXpE/5LPENM/KTFr3
Jqq3zKCSKI2mit4qp5w3T/K1zHPKewqcXSUYPbPTFMEuwUkZuPD6YEWx/uzYW+fo5+TZb+Hi
DSA8D0OtIESnhme4y3gtetjG2BDqDiVdvmmtTa7r/DqIy6z5iaUITK0mhstiMXVAHdj6cuV8
/zHu/TB5mGDqskrS/PlbZ9iOl6VrNXEG1Vl7x4SsLtvrsPL7j4nbhBP8/OB4XhLV4cuTOM8V
FME7ibCih1bNqvDTc0Lq74mjewAhv0MVtrxn0xBcc2RYLJKfROgVPXB9URUtAZjS0LQpKJzg
65bqYXzfWnAvDqdem8dcy+14cCVgo/fBOMGyVv+3ooG3WssTt02fxB7ppUyMOaRsS8RcSl0J
+YSAy0zVMN6uOqjEZbDb778773xOtcFGyUC8E/6qwFsOZmU4NzJYjMmwTPItz+dD8TLdx8KW
5Zk4iZd2L32cD1rViLRHVrzatPo0i+v2G6igj0v0KsRDuBS/F0I4XrkEK73PVD1a6Qhy5qK0
P2Jvkikp/SrHIBYnr4wFeG9Z6gpt3TcY0eluDN2Kvj0HV4dAn/j/NBQnVR8WgKuXqEZuWMlU
k9//GDWf7Leda8pfx6georVlO39/ZKIqzz9cvKF+ZKBbrTaqD62uXchHTofS6FnB2b2AOzFh
8LKOHcGLQBK3K7i864WtX7hBq9RzVBd+CzQoh2l/PjdLjLOw1nxvX+juAhB4KYry0bTh4t9r
Y8H/1x/FAxUEAdxC/3c1819/Y6XjagcGABVBUAsEzBZZIP/R/NXB/SeBGsgGDGCVA1uAHKEI
tusxOIDtHcG2Zq4AAS7ko7StJRQM4ONHNrXtYAgFR1szBARmCwBqwRxtzf86iL/W7Tdj+GMK
1wTSAAsQFH7dVNf4o6moAwD+Zv+vdH+9e9zQXXvzmsnRFPHr+Vp6PZ1f00B6+NpptshLAcTW
EsDD9ZtbZUBw8K9lACqCoU5gBMQM9FdL/P97S3z/rSVOGRj0b376td7/S3v8f2HXdrUxhUH/
xir0v2cV/B9mIQtzdICAHf5qiOev30H9ts6/sSAFchALC7ADMoTAcMBTABfQ0gHkBAaCzBwR
YKAZxMHM0cYCCnYBIiBQczDQBmTmALMFmjqAkTrmMATIzAxsiwCaI62C4RA4ks4ByQo0A5tD
oFAQ0MrR1hLk4GgDBTkigDBLZABbA81A1wxILBQMh0MAvMJAe0cYAon+FbrCAjcDwMUGcPMI
Ak0doVAw4m9v/9E3RU4daAGFIY3eSM1Nb2RgKBRihxwQ0BxkaXntkd8ayP4/T8oO7ICwgjnC
QbbmQO2bgVk6QqC/uKFgCwRQXf6vtpFE/zKWX6q/Wg4QSyvEH0P5jxz5cNP1Gwy5OCC4FZIN
bHPd+M27CAeQOdgG5GANhP9tMDdgGPgfozH43fVAuB3IDJksBPiAZo4ODr9SAreAAHKpYNZg
W1OQA/JJ6I+FAprB7Fx/I3UwtwDbQGwhtki0IA8QCrNE7gOoLeya3srVzgpsC3QAW0LgyNmB
zX+PAHOwpQMYDLSDOsKRWEc4EOEMgzsi/QmBOQARVsi+P55+hRKSy8YRmS55gb+k5tdh84vv
91BBxsYfCOSQbEBwM0forzEJCV132juCHJCI66YVMhne2PhNCL+OFmEeoPRN7ErfBK/0nxZa
+sbB0n/MX/pXnErLA2V/G8D11rqBy9/A5f8El/8Dp3Sjo3Sjo/QnHaU/bQJ5hBVQ7cak+g1A
/Qag/ieA+m8Kf3DbIHMqxA7qep1w4dDrsNC9AevegHX/BNb9A2Vw06ljBXNABgzYwQYZzKbQ
61GAftvKNwqgP6FBN6ZBf5CAfrkDhNzx/3EH+AYOvoGD/wQH/4GD3OhAbnQgf9KB/MkdYKQ7
bG9Mwm4AsBsA7E8A2G8Kf3CbQ5wg1x8XAWE3znC8gTreQB3/BHX8A+N604n45QzX/wzB+G/J
919SogbI8tqYBgi5dxAAwd+SqxYYjkyq17mR9zeJLDLVIjXgAJ7/nO2/8/5bTv+feLm5/k4s
/E9i7r/+r9d/ycz3d2Zu3n+h/rfj9H+kFvwH9Z9Knd+p/1py/Yf5OiZUIObI8+ZXKQX4VUQB
fs0R+far1DL+xe2INH59dKsiIw4kA3MBPL12Fr8wP0CIj+dva8rzb4sqC0KAkAnt11SQdn+f
yV9wf3WtLLJsvC6Z5K7rOFY5EW5hYUEuXl5uZGrk5uZmuykdzR3NkJ9qskojU6EpCAGQQyZH
5KZBingfcgEsYA4AfQiS3RnO9ldTLg5gC1xsLsD1T+m5/ngBBPj5efkBFr/JuHkF+JDL9KvH
9j961x7/q4yHi1fgbzJu5H//8f9dxsPFx/0PPSH+f2D5kJR/l/EK8v4dy8XDzf93PS5+5Osf
dv+px80rdF2O/A0rIMT3d5mQIK/QP7DC3P8Yi5DQP+1y8wv9wy4Pzz/5kCv6dz9z8/D+w/fc
fNz/sIuUCfxpPZDnNgR6XWX8iiBtiBv41xIji24YAsDz+3VBydYCBuDh+f1JDvBUjB9sDhIA
WQgKmvFz83ILWwhZCJly8XLzgAUEeEFcgiCJ/1nD+PfP05En4U18cfPxCCI3DROTvLoCLvb/
AVBLAwQUAACACAB5in8iqBSDOdxWAADDDQEACwAAAElFVEZDT00yLlBTzH1tcxs5kuaX+6QI
/Qdc7G0cGWurCvVefXERJ1GS2xPttsOyp6dj3B9KZEmqdZHFripa0jD83w9PZqIKpKhu70zP
7s7YJokEEgkgkcg3oP/Hv/7Pd1cvTxfNdfkyPPGPj/71X2dtWfRN+536qVotmvtOvbuavX/9
7gNgH6q+Lr9Tb6p523TNTa9+atqFeqleX3y4nL19E5ycv52h3lmzWS2q1e1Z8/Cd0pkKQhWn
qcp0Duh5M98sy1X/Y1kuysX7sms27bzsvlOToi9Xi6lb52qzXtfVc7XeFbd7JWflbbWylb9T
67aZd2WPsYTxeTXvVaj08ZE3/g5yXy3wZVHeONWugce7Xmyvq9UCsK/2i1ettmlwfLTc1F+v
F1652JYP8zuusvDqxbZuioX92bfmT7HqakOhqhfebWf+FF/4e2sIuW3Lrm9aKnjjLZsvZd/g
+w9eXa3ke7vszd8B1Nbm5wA1ONq5KZhvWluh682ftvlMSFfeqrxfF/0dQZZeV/bLom+rB/ye
Lz3Tri1XUnZ8hMK1N6+brrSNTt/PvKKdr/D9w/ttEsdhohbVFxruvwMhiPn3pqIa9dxQJGXz
Yo2iZU29Vn1pyDYfREltK91XCyFuXt2uMBU3Rd2Vx0eY626+tcXbdbNW8vfr1lfValE+qEA+
y1+Hr9FQdHxUrBZDuyCOQbYy/d62xePXbbi1RaHSqm3q+mtbrsuiR5X29nre1E37tbopDTn2
4xoTfjnbXr9X16/U9Znq5piHm9nWMz/KhWdK8e978y8A38+2d+/V3St1Z6vezbYGxR1VvqPK
d7byu9l2/V6tX6m1rbw2eNdUdU1V17Zq9+b4SNYR8/SuXP1kxkDsab6rmL4uHy6VU2n5cLH7
8+PFDhJTsFP/5uyC14Lxnpdf3pedSgPlO7WKTT0wz4J4/aZpl2qxWavlpla8N+RHsVio7te2
Z+zv3jnYr662pgAzc/VnRTsEO2h7240T773nOqaCbBoDbx34xZ+2tLmOj7q75n5d3JbKbi+A
/2W23XRluxi397/Mm3VlhlQuVLmiab28uN7cqEB1ZkCrW+bBy4vb+nF9N3ml1JR/bzWNa4tx
6URxo/mXtlNSl4fNtY6P1pu+WvVl+6WoTZkwJyrY2vMvK2Uqfb1pWhBx9WbrVe+JLm/++M58
HB9584d3t1zwhj4e8IHF0L5PPAxiunlRl/TNV6tym/uq/HVLLYgQ/vnAP1XfqpemRtv0EE4v
taGN2n+lKtQfFszW/behrp1yg/nd8RHQd5trrkfdHu7hGbSmwvGR0KBBBdOwu+toD2MqDncG
pMdHLlad7XY7lD/TA80i5vz4aHcuffP/katPgpiIb3G+0a+BmB3Q8dEOrBoxDKcBLfSftpYf
aGlEUo0bjxjwq63knbVl8RnLbmj0Fg/2J9Xv2w3vmXE/nP549frP5fyvx0c6+Rffu22xrcxX
7RXzTU9fA29etfPN8qY2NJjfoddX9YJAkbcs5m2zwvfYu25LbCzzPfEWTV/M5+WqByj1FlXZ
ll3V4VfmYd/gW+7Ny0VV1wV+nHp3m9Vt0W6WdbHpCc2Z19w2q/IzwDNvXkhP58Bel11XEXmp
9+um6Q321W1NVCUyDsKRzrzroqV+A6fiddFR3Sz0burGEEQ/Iq6xuB7h8fGRV9Z1tbbUm7EV
t7clo0zlh2lBv7O9ucpyb122/V2z6QosOYpOvathKNmZd7upaiKpLm9otrKZ9/aCpkczORaQ
ywDa6vaOJygPB4KHSuMYqB6Vxd71xtTgH4lXrhZFd0c/UgxvOfzMxrXNc6gli3JZtLQA+anX
DXTnDt0OOTOv4baX3s/ukp/6Xrcu5gQ71V75MK+L5aK5J1ynkSgY80fCchp7jyVDEu8aOspK
VvA09bpy3ldMw2m2w1anuTdv1o8jNaenXtMubspltapW3DVTXZdL8A/P1+nMq5vbal7Uq4YL
zr27x/VduWIkF15b3lZdbzpaEPjS4fkz31uUt21J2M+0t643neluQwSdBV5/33SbddlWTcsM
HXr9naluC6laNG61s9hbbuhL4q2LtrhtizUtzFnqUYsFthRIYXSZu4HOcq9Z7aKmGVgW3XxT
yxScOVMwTtXZDE1/3RRtz4x9do6Cu6K+oV8XTLZU4NFder9uyg6LgYUkNDPfOx0kyEx7p8PA
ZoF3urszZqF3OvDaLPJO7Voyptg7tVJilnintB9mqTdzxjvLvIuxt9y7GHs7PT7yLvb6O/Mu
XHaZzbzXY+tz7/XY+sJ7PbZlci69127jc9+76GlhzrX34zCM88B7O+A8D723A87zyFD0dpei
89h7OzZNvLc7PaTeclP31bp+pJ+Z97ari+6OyDnPvY9jP6fex7GfM+/jXi8z7+MO4nPvZ6rO
mC68D3dNy2L10rst22WxWlzXVPXC94qhmwvtFUM3F4FX7E3RRegVw2guIq9wO72IvcIu50Xi
FVwp9ebOcl5kEEVjf7lXjv2deuXusC7OvHKnh5lXjUL/4tyrxsYXXrXX+NKr3MaXvlfycl5q
b0WjIDSXgdcMBF2GXjPgvIy8ZhfnZew1w/gvE6/Z4edLHIFfKoFmXkOLST9ybzP2ceptxj7O
vM3eJF/OvM0O4efe41gfu1TW8vLSexwq/kLac1uWqzkUW4MpGMxZ73U3uyvaLc67m2bVo9xD
yRVpt526LXtWUD6vmvsVVIY3xXpGeu3xETdWq6aHXiKHzNfqRq3Ke2DzLlbzBkY+obEWFOmx
jOicpOfWUHztHx9ZYSo0yc+vW1IYrBZG3UvzszM0LZxjwtK0HYtMe/y73xyaz6WhcTtMjGj8
QvuqWJbHR7DTZGpQAMUKjc6rtpz3TfuonNo8RTQbnjufx0c7KG6q1QI/aPqluXLrq2XxUJer
2/5u9Dq48C1r6ovN2rt8fQ4FF1+HqS5/3Q4WlaAp2rZ4VDgeLb3DYpDp8ZVb7MNooVz1Gma1
/L5p2sLUkCYweM3HjxifOyMGgdJBavDpON8e5Ar0LJzDtBjMStRSVZCjBF3bEhlRoKpF9WXL
qykW+cBPx0fEGzuU2LEtyptqRVMpo9mpJSbe1dn2cmbG9PEH0x20565vsfT4EAKgT2Olyb5T
t/1WQ5c3+Mwfb359RQ3A0g+vFhVQPPr498G3eNh8ZM/GYI15j5pq4V9lvj9qciIpU2D+7NrH
jJhWuvqiqHtCJBWZBoCYXR73imXNi+vOdHwr6IB9t6Gst7d4vHjo24J2xOKBvoNGMx4zsDeY
jq21Nnx1NjNESSVpSGMuaLiwvL9uBX58tFOBYLJVbz7+sLX4Fw8ffzCozD/tsle8LuiTeiS7
DkvpKzgsHGPstlNt3as5Gna1+usvpkpX9qTvdr0i14C6uXpr+jk+ko6u3pqOzD8HOlLf0M/x
0bMdrXbdJeQUggTyRLR4px2ZTGAcsIN38yHEJPN3Q9Lw3QzHVL96pH8fUK79E7LxvaYFu6mX
KCBL1Su7OephUQxgRwZ5D9KlT9LoUX7JB4o+/mCaHx8BB+QQ/eTRi0GOzWno3FI3hEZZpBbd
7mQdHw39gNWHr5ihv149kDl99UhMuYfoF8WdXwzeAHiv5s1qXliH5bL4zJu7K3v63MPoK4tK
XFvwZ+1goPF8/GErTk8WGhC15svr1U0DoeV9XC1K8q++a7oKOvDx0Sj8cRTOmk1ble0w0ZAK
v40BpcdH2hdXjc9bm+gbps6jHUA7kD4t9/rqJNyrCtHzSCzjEUtLZdMMjNS03zi+D3fV/POq
7Lq/f4ADir0RXj1CIHnzRzsU7IdltdoGfFLd8kEHsiGpASweBHh8VD+Bzt5tvRsw0nZ707Oz
ZF5X66/bsqFPObi6vlmvTSU7/roAUSxXS/oJyVgNB1/dMPp1wXOlnViALSPFQc7AD4/rUoW0
d/DzDXPVXzVx4Uv6+GWAnp01BgaITsyfX9ibOJyPV32xWhTtYigA9GxT1QvScazX2rT11YDk
+MiMY17M78pF+aUioxt/WOwIHZp8UebvL1szhq/Vsrgtl0X32QwUZ6C3hpfVQFRo/ZzoemtP
fSBI6egL6FBBTWLXUFxVOPdJQ2Q4T+9ztQSJofFQLVIKbJV0t0rgIAIXiHN0fVPV9dZ7V/SX
dM7zKtHc2rNfxIM3v5ucmv/Baav+4qskUn/R25/hAkzUz/52xxX7RuEcpRMKOorT4Zey7bem
+T1aY0Q/4ygxaH5Q3eCyvWvav20N4P746Geu9RffIv4L+4F36t8squJ2wEoYTTXzWw764yMc
OVwfHd6bDrcjStP7z0NdNVYF6usB9fERj3cPN8nKb0d/fLRbn/Trj1te9vmXSulYSek5K0pU
ikkuROP6/j048e76unk4Pjr96P1MKpD58hf+cu797MsXEEGN7nid78krq8L0hCM14l7Fkvon
+sm5vxJ1q/x1iyWBBGElzhRgIW1BgAJaBFNC6rYKUXQtRVQpsmiUbRoPzZStSVEDCCdoT+pm
qYKYBs46322nLmfKiiwMCSKLPkUREjVlqXQcJhSw4pZX37+H5vE9tZ69oxp+EI2ovQ/L9RAp
UbQtFIqG2MjN8vhIx9Tg7kmPtC5bCht1tXo3w+JCCrvxn1c/bdklTjblF0W1ZdVR+bzhCir2
D8MFnAF6fLQPvnq35bhVueCgVblQ9Im54m8JvjXt1l1jWjCC0qr+9fwn9eqnXTg3DhjcPAM/
PgrH9urZaswFO7XGyiSOpTZFoLZLNV+S3IYVQBEECGUJ3rJ09lWY+Kpo52q+VkvVLTmoePpq
63Wk9HWk9Jl/MamRtdcMbPf3EzjHLoaCoi9WXhEAF3/VgtZgYtJMiYGfvp99xXKfEvHHR0L9
6SsmjsKLO+PCMN4AbulHlffvy3m/xXTxGf5mtDRF+kUq4N8/mP/P6dx9/34223otmVCjcTSY
U7SlHnxYPeAb5kLS5E3JI5WbZi3msm9UhDPT2osMgoWhj48O1/BtDf8ZFL7tw1Q4PjpQww7C
ajXEuBKaYsa1pzjNztdtcHxEFSXWg+F/HabWewxo2PTvY6fMz4dA7L9lwVvyoTNlx0eP++WP
csaYZhS/QlUpehiLHn23FusjD/6Tai11bPpYVivW+Ts0YZ7ZWw6xrHbWI/idBTlc4/hoZ0UO
I3GX5DASMCQWZj9s7717t922dS8VUfL2DPKZhGmqQuJN75Ete9qBD+pxjNeJdSS2yQMdomx2
jFXQIFUvGRXJKdPiTJFovqUj8mz7xls8suJOgTwYMDhbfWWK8WXxILYM2Zxrlg2zs+2ZgqKr
yEt30bbfF6tFXbbbsm0bDmlTkH1wLtGayvfbnk44py7ptNDqTdFdWa+p0PEcKrecPWddX8w/
b6D339TN/aRZly1OFipWQzl0LUMvfkMdW0z6u6pjsxSfjfXRLFS1UgX1VzWron2kyPqf3xCJ
k8dmo+5wsm06U9OMC3ppf1eqdUuB9P/dqWW5bLiV6a5/XJfzu3L+mcnqm1bdF50qH9aIKK1u
qaebmxI2gUJl1dwoGYGgqBruulqtN73XbHqonVSkmvl805ZUEfrzFn6k6kbtzSZyOmhNqHz7
v7gtgeCF4lLPfhsdBWrIVUBSURrwNvMeSImnTavyk4S+fV/WX8q+mhejm/FE6rt67/ER+JCP
nMlbM2xKxVKzZgn/v/q/aoouvbn8hheONFZMjMcGAb5C79tOIGAMxWIoTOdfkJBBNH8tH8q5
oe6RiICuCEkx9nxB45Tejo9o2GCEoS9w7ETtdqDQA6GfqO+E0H2SDjXZIWp/aXa4eaBDjN7t
g1gwwzjksD7YiLya4scCM8DfgZbRoRm4or3xf2kUqqGdsn06YZozF2wrdWAp1O8Om223MfFF
yPsqPCumHxLkLlZDLh0l25w380GLFPi7tqmb2yGb7qrsYQXs5cYdH41SyPTbF/2mc6ac9Kh/
b677alk22Ero/Uktp8AzlWmGJ7+ZXTgle5BnvqkXoGe26tW82bD/nOURhr213gB1fLTdr+A0
rXu13U/8U1/RCBkxz7fDCtIpbogx9WFJfVWiYuOL+n0Ki+j46L+eyr8ebTkP4MSnvyd5Zv6q
kyxQJ4n5GifqJDKfgfmr1YlvfvrcY99QQ7aewMQvXY1PdtOmpgo3dWP6hmXI1a3WanNkUCpY
HLM8cArYJHPaWZe5SwvvZamk5nVZtAL5qpDBiTgkRATFHsRNxH61slUj6BdD6QNY2MJka8he
4MzT7xD6sD8OJaheXcHX66sgVqFWaZoorZNchb6vrt4cH4UBqdJRgD/s5Akz5Yh58iDrQNlw
lmLxzlVvZsdHgU5UGOjUoM/UZHefoOjqDD65wOdKOg/UJNQv3xTtyzyd0m+qkQXRb9ewlCb4
41uqf59SHUeRQaJVnGo1mdVF+7m73rS3L5TpAW4g/cKA0RMqPNdT6PT08qypF9JduN/dbWfw
ZCrTBmmogjxVszOepCDPVZCpyeUUH+gI2bfSWZjhjyxA8g92ZgYc+onKfTV5//bNFF/2uvsj
xxaGEY3NDHHy3RQfv9XZtyyZ6UdHWazSXKWpHjpK85gnMdFq8vrDx5cf1NUr09+USv4JIwzN
V7t6YeabztXkwxQf/4TVGzqLYoMsVaGvJm+n+PhnjiyNaWR//NrFEa2d7QhrRx2FtHgXHy7V
j2V/37SfccJ+hjLxqm2gZq8W6nSzqJqXf64WZaM+QPitm7a39aaMw9K5xyuRodv2F4WR0lgz
wjyl73/kXMYJzWWs9cAlsakchmoC2Rf+oVyy31mUqzjwlY5TNXn744fT2Ycp/fgnDjDyeYB/
KLOkBqHwiu0Ha4d+oiRTk6tq+SmMwkZdnsyK5brpwDfNlIC7PGDojRlPMsqLOMlVEBiCZ3dF
heSjF2pKBd86T7/N50/61H6AH5mKstQQD/E0MPi7ou0fVWgIAPCbF+rtdV39uimFkPxbCYn9
jAjRsZp8moA5hi51jMswFhYE4Qh9DlnIyEKcoVfV7aqo1bu2mSNJFlsyTMcdqXM/d7FHv4s9
D6KxwXSH1D+GsxIzXssRSRAbXKmazN6+uTr9oH4orhuy16uymxLEYas0JUlmqI4GJDr2U8YS
ZWryoay/U/+mX4a+fhkF2csoxoEEkIvGISXNR1IybUYTqEkQQB+bNcuu6NV5W30ppwR4jhLB
wZQACYTqZfGwQ0keZOmUQIcpScN4oCQNU1Mz2NOPzlXgZ6meEugZWiwWogVoElMwuVgWVf2d
6qpl0fy/eb84mdPY8DGlGs+QlI8SIM1DZT4mH69Op/hiW0DM5n6ooihRk/OyaNWb9kRdze82
9d/aarUqX0wJdiUiWfvaIDaI3q7U1PTCAIOcADrSanLNmahT84uFdhRKuzhUkwaQmAmIDIGM
MFMTeIOmKuMDGsojQQIdjtIGwka4Oc2ewZlF0pLOKtZrcMjxuuV0vQLQMFCTq36zeCRoxGqz
9hM7kEAOOhqHgIPYH+nVyYuRXh2GDghTOIIiLSDzj5q8OzkFUPs8N5qOAIImvoG2zXXXA7EW
JtFJGstUxGY8mAKedJ36w1giNblvNvWCxiLgLMwZnJmh1NVnml2eIxIRPHsG1jfj7Ok8zS3S
RE26zfWy6klHcDggMQSFBjst2U1T1809BDLcT+Wq71Rb3hYteahQYbNewJPa3NCvtvxSwQX4
/sM7nniZpDi2mKOYpuGmqkua+8QdbYJtriYweqcqyQVEzEJUmeGQukO4ZYZzP2JwrtUECtFU
WTMpz22v2gyHVKQpfR8Gix9BCvnWrMjdOC87rEHGLBH7PtfB3rqv+jtaWsaegGLADO3wgayq
ZVEDLrsmxVQzPCb8fdvUtPQZI8gTLQQEhvI1pq7ZdPUjnbliCupMkERmABV2SCwTBs2X0fuG
/PeXM2DWwslhbPuGYmyQ+MSUoWCN8pTBmU/H7lRlAokzwZrE2AKQATLNSZwJyiBSk0VZ1B2h
lKlO80MzJW0zCBAeaaAmb5BKvSwXVTGlgnExTF8adtjVY9eXS8Kf82JFOmb4uMjYbrRGtmlg
uptclS3SLDrSXDT3nwa5IAdX39+VLbMeo87STNrLBhSBm2PnohzsUSwxSbL1fOIKtNiXXoEM
GF+oxiC+EgvJ7EAz051VdjBQ2aERjA6qAK5gLWgUcDrRAYMxFNKO8m8y+H9PMdJJYvtNA+hA
0HREdxlZVmdRaCcrp30sSg00FygjKP4Wcp7TRALtB3at1OQFBj7yB3aFTjStYYVbWpBF3bpZ
ddV1XZKrDDKoW5clcilXC/WFrCJJ1+kkf6f6W0EpXsW8r75UfVV2J1PGO/QUhuwQ+AlSLGcS
Qj9ngPYjNQk92h3YfMyf0krjgLgu53CMYt6ER7HhCIxlK+4L4UCe1TQUzONhx5scJzsBnAM0
EKa1CDODcN6sehLNUzJBmElTfx+psC+lAB/EqoNxjI5QEdYLA8GodcpCBdBAoBEOZkBHSRVa
aRMJJYAQlXY3xLEdRgQZSi4m50BOfe32mOep22MWBM6cL8uyl60kowl8P7LNNe371TgaXmYI
LbD7/bgPU576MA8Y7sgzK4ug1gD0ZP5iljG+Ml1DRt5UK84mnJqSSE6FlKvsL0sG+/sg1tyS
ilNpsi7mn81IhYdxVGV27QRBEIVYAeQdDpUiWfsoFtrHYzaVtYeZc5gAnfixTNau0iWrmIYZ
g8HcGWSSBWTattNq8vm66j3iUbEode6ndr7QZ1PXL3/dFHXVP06paFioCF7JxAxL9jb2q6yT
oZHBUOnmzaJs6YyNWJzG4HVuncqKlHR4pKyYJLnAR66VPWkKuOHukGX7YWAEBeHvy/mJs1Hy
3JKENX51kgY5ge3JraOM4TGcO9SnVUB9aYmzgQKx48mMZw8YqymZrFny0lBz7ZwcqEEcjfVL
Y0f7GuZw1fTVnGchsdpXIB3jeO3vih7cLkRlwwLAM9A1LNjEO6RzqCEEhRYkFwK7cYJ5+fLM
OQkFkArAYTcmFw4rghzQbCJoywTbkUGircGvCiDUGhaxcmQnmXQWQCNuNv3L5uYl9FZSE+TM
4qGYSk90Ld8XikjFWBdtX803ddGSjiEabqD1M+PRQS69kw1gL01OiSd55ZJQ8EMMFotFy6cq
7VxZ//QAfrt6xMTAv8urgj2HZAEYOl0YjDpd4Pu2IdiY9+eUfgxLF8eBoRNRhtPzd7M3qqhv
m7bq75bq0+RVGiAlUz02m1Yt5P2PT9MTdbpYkNwr6vrxBc7ktqT4/qpRqILRk1ViEA9KfM59
jaNLLYdlmZARpLydEOcQK4loTPxE4ctkII79VlrM05SrQIcSzWE0eUhkExQie1mQsuXzwiVp
xjBM3DXR5ItwEMAoxHnKMl/I2dkr1jgdCAE+yosou94RRhoMzx2O0jm0hoDPIOz+U+/Po16i
AzuEADJuvmvIDNIdzM3jBM1fypYGmlvlPmIoqSeQ4MK6CYUqgBuOCnv2kPAIIm1FgJBGhs6K
HdVQqUT88BolqISNucsc96W6KeteFet126zbCrYk1r+QWtawJDFKOh2+hSd65ERW3zJH3qRJ
xkfK9819+YVPBOtZiELNFSAJSNDF9lj3GfBkA8cQOoDwqopqJ6dfavphIDRWGDYklAMmJwsE
imVDlszgnclx3HK7SE0oecbRbXySqBiGNmSuN9d11d3xtIueamgRBOAmMj/sWoehpRe+ATbQ
SdxnuT3qBTu8EJMvZdtZgWT5IRfc+1Jbp3H4zCzpLLQzEfgkt3kirBRKLFG729DKGt9Oh6Ho
NdqNywlFL4ADi7KWSI0nsc0kRYlUQQ06MgUQ27Z5hkPv3rXddcYgzB05gWTkSZYKYF8/SmFS
EyUhadzsDDmhjWBVbhzfpJVClnzg89sKE97cBMWkW0eJcwoEaeRUcFcldVRsqpCRhjevNwva
5doqCUkgRA77OLJeplCa4phebZbXLACshpBFMiH7Ek3nvswizpPJuqnEzoiskm1bJuTCn6rE
kcwZHfJYcPNrDkNtQVf375u2v2PXUbW6faHueJ8qkpjSx7xYqWtcAmwr3J7AJo9CR3nPs4hd
Y1dWzIrpGccCxBp263Je3VRzGmwoOmHGFSjUMbi1pioQ9LTUhAG2JnvApoPfiPwF1Ny0Botb
8e5LK8cPNTgMLL2xrybrusR7Fq5GmAQMhzF3U5b1KCZ0ABOJ0Jqh3uBC7pT4S/w8AhwdfdbF
o4dZCNlALOa9u8VjwFAB7g2awMx6epLUoba7s55HS20GyUXUjjJN2CzXtinUs1XJDB5YdQMH
BXVJEutxUFAp4O8jaoIgwc2mhcqg5nXRYunYiGlaheyukylVGlrBgciOn2o1L9uyfnwxpYKh
BkxzqMZucEztRscy7VRP/W+IeFBViNEIsm4Ml/30TolnIJIT4B91zCSh7QnbaMcv89T9YjeI
Vv8yO5C95RkaN0V9g3XhfEZ+yoyysy7+pN5f2eSYD21R1ZxEs5crQ4mLA/Wo8G97ZRQsPQiQ
oY7pOIEK/kvTcbSfB9gyOHTUcOhoeHhiegRvEkAsDEv+n5m6444q/9ZYNEtGn2Xfq3JVtkXN
6tFzuMGMV4/L66Z2UOCMg+f4E1TKYZv+vfMd5JoOSVg/p92o1IZJROXY9KxkiMYexFSuodPr
PA9fOBZnHHMjnGOif7DwScKMWyGyMZu9/kBGkOgCacbAmFSB8VTPEvaXaOQa1c3qlo9FOdzo
RGecWk3Kh6rrO9e7oHWUEjwbRb4V2xG3jCHq6toJZ4RaC84Yw76p5hX7WMWTqyOhCc64SVu6
2rz1LydZyDOXitiXmdNp9MzsaGiiQ7fwDclIrZWVpgLOOMpNM+goaFjDHCkqMTk86NRckGju
IH1wDmZWh/KpKh3O4/EhUpvoMFBE/K1SJgdokBMkzqy1FYzm94AQtA0mrqUey0zUAesB6rBo
kW9NoThgdPDjll9K0rGsVp2kMk6YaDejMqlh6wLgzKzVnWAe5RLLJFV9PvjdJI4T+JT2pYlR
oI5PlT1z0FeYs6q+bst5aVW60eFBcLsX2NOUicMjJCCO+CtiAzFc44zKo1gcGeL+S31GNo5B
dmKacgOdRKMTx1E94RohOGI/QwDFqvZ+GjDa3OoD1nGo44ggueVkRwfXuHdHVFomtlONdDwA
AhZBwove6w8fSUmzvmPIKPxNnqy5XfLQGtbQzVAX09+s3G2RyxRqRKaYWaf0Y1icLFXQlQz9
xUKN3Pe0R6gmgvZb5SySrv5YORvBCIsgOd6xmrlqyKIuemtWw7dkrWpMqVzzwMje1XgWbLFR
Pzob+3rjAqeM/VvI/N2QU+r7RC+7ZrvBdPh7x69Tg4AmAJzoDoK8Ec9SfXhpsuSPXhpydJP4
FJnuZFfFOqUKo0SXLZ7FVE429Sj3xFAJEgJSmuCe2COBPOgzGSPZlchDKDmJCDwI3iHrIWJA
GD3BD/Q2ipP6TDvZrZ8m82Jd9UX9aeqIMZ3JBFAkoC1IwR9TSEg+Apyx/3m1Ix+RT0XSYtLu
0vBpUjf3sBSKrvw0faGKTt0V63VpRl+t1JU4WqOT+CSDu/IkDbJPU/BCIEP/h3WtBL5VOHDg
Cz0Z/dR/L58gzwQZP1YhFUUJypMpzRI1+ZkFrIQdbXXf8SGJwyE25YDhJCtouYbUG8JFBtr9
GGFI4pxxRdGOk1p0ncx0ATCYhADiNsuSUChO2DubOEdDnjN94GrytVlvNow9i41c0oJN+3kq
6ALrkX7h2JCm2E7QzkkUW4blMTsnkc3SCRhCPGqd0FOyjsUcZoJwDEsAZLCHZcbyMdSTD6kp
/u7gtXsuZjIWRKbIF2QdRfCY2tGTNmpHn+eyBjjtWR2d0g9rgCRZ9ORUhyMwIZubfVbz8sTx
QIaZQOFbcPyhNmwUpxHBnSnTwg8xAeDO+Fyu+9HjDPc3NRnVCNGmsTjoa5+FEkl4SYRQ2TBq
HJz2s+Dg6DQU/4O9mRFqgpCr18YfXrhBmUhzjT1uSawGkT6DOfFzaQetgMxoNcaZdBrynA6G
y6AkymQ7rDL4ajK7ELu8IlkHvpbhD7wirhE/ZiKZV/rBwwNuSMNAYUNYhi4X5I+U3QB3IWrA
HnpNm0/Mqyyg8n39XCKiAUOHwyCJhhAatQJrQqlg144svJ8RED4q7J4XzsBzgdFcblaSqqaD
QRIwXpoyjvX5Nl3PkMRDdNaXM3tsRl+YRoLcPR6HBfZ9mYHD56N1rGZJKmPLHNd0MKiIPI8I
q3JUMbVafZITJKIpgXdoXJrMVyECvGJUVitFW1MxhlDCzDF50n1ypRV1B1lgrag4Jci+jEgF
+Z7FKnyURTFBx13EJOH4RTkWiO7kOoGIzFJLynYyHhXaBy8cwKZ9IZuYobtrWl5xbbdsFh+k
XeOyDQ131MNtzCJgKiCG5hTNGCS3LxBfTXCZc6pSG/BO04Fy54SjnEuiDm54ur4/Gpk60UzC
sHetDZkk0goWMO3PE8errDOf5wKShNI0rfUXpNIZqS7V6rNr48CmpQE/OVZox1vqydK0SZjw
qAMAtfix2ex41GE9w5i6L2gJbYZdiFw+AxpNKbmclfpUDnomn8uS0l39RCxLRjfMnvhXdEzF
5H24Luaf74t20e1k02VcIWLv+broq+sKSRtOUCZPuRI0Fps944+8Q8NwNrzVUy25ZOxmue+G
0igDAlDnpAqtFAgJEpOcgMwShFHIg6GgR0O8E1nRkMvMRKOj2rdhFJ0emhqdxDxlOuUDLHlJ
uosWeaCRw0Pw/fPPxlKygOG49fIJwrDsEHAPRw8jIiZPBoh7XBRKgUC5adqy4zCAzbOOIwK7
TCbKXuQTBEzbq+EqHaQOivfGl/gp44kQr3n5wtEN85gpQ/p99BLzKBlqqeYmgwNMvCJZzGOh
eFPkvxyTf+wK+CHT9txkYVYzdvmqyZJez95hBoaOx5QVJImgRbZAsVjwylq/eJQzvaNEs+EQ
mSlHF4hGgcF0JohN9Ju2RI7DlFaDT/2EZwdumNPVaLvpLAy5KcJxkig9HdPb4HOjdpHk6yRW
GYh48szvyV2xGAHI5kfsNuIY5BBP6xvVbW5vkU5gsyChX9lZvS7BNIi1d8U9p2vY+GNfPvSq
6r6bMtI/wq4PEZCFI3xXzxOLJQsZuK/oxCymKAY/hO0kV0tOPgRQqWm059ZC9gJ36Oa/WN0k
FXLCMDtkxdo0BvLJExZ7ACQvHFtbh7EQmIkXMiLxlA3B2ZjB4KAweOHKGsrSFhB7pgZQLtPx
ZANpyj4BKM4kFduyeIo4Go/Xd9PqbPZ3NswHjJ3TRbHu6ZKMvXPAC5TAqQiF59y+tAE/9LtN
3ZUvZ82iVG+axaa2hjZl/3yasmcNhJI7r5M8nsF9isuFhNrZR3rnCkD+1OZLdGzp2R2P3V+B
pRd5cfxiiE31tJmEOpAqkOdLQ/6oR9JwMVLayhNyfVXdngPvRJ2uVLVc1yWUzGI/9SRxEp9M
2+JLUdUFko6LTiEfDLQk2l6yoBRuzedHczNklDMhiK5iF0zEAYeLuc1NTznBH5qmVj9U123R
PqqbtlkOXrqroi47JdntL5R46kyReLmYVQdvS+xLTwmCId+/RHradEyaBCGc3iVhIvYcCH/Q
ViQlFvzqO/xKdx4oQAQj5uq+6v9WtrXkY8jl2yyUOqR0fLJqrVU78lCQkyeIHoFxLXg/CRkc
Igvvru/X33ne/f39SdVvTipOL8OE2txiLSPBpvzAbnl7lQH5sHyvYEcqWKsemaHU0kCvPvzg
JFSlgc+gUUbZOzmJNKJMvjnSqCSHwy69HTy8VdePTmQGjmaeulBNiiGqyEtBF2NgLFTzcsW5
AeIrgJ4i8GwngVUULXhtCD4KxWTw9XPD3eFrsdSl2wOWam5hYqnCU+AabHEk4JzWd2Be+BRs
ImuUSR2o4H3T8GURq+eFYE+AEz1c9hkWNGTQkxiFhkeWQEHOVvlONj9umsdO2jHNSbpnn2eh
tpOCVbBXiawPIo9SoSsnaTwcvLRKoY5USAESuWAwJKCRUzFMHHET0TUNQ+aPTV9+5/QRUb6y
ZpuRk38lWykMbDOO9Owov0k8QA8wc0pZsTrYXU3npgC13PE7hFYb9wUMfyByNKfK5hP7SAyl
lkgKWpbtrXCezVeKY6epKPn2sIySZynSUZTtkRS6OlqMi1MAp5SHSyeMFWwJZco+nQfrmMnS
A90Ot5D8vW6Tk9FZwMuWaNY/Tmv8Z2Ju7xztnl7GoAow1lvHh6/FtElDqTGYYaJdwi1EgAO7
LbOwPb+Q3W2U9ptoV0Gw6WZ5tNcydFsGlNOdPInDWiuZ9BnARxV68JoJRNM++NJUi3JB3Dhk
k9JUJm40dLgnloROt3L1xr236EtTSjXHW0lOqrkdkSMXrK7sUmt6HPxgtG6x9ke1Qs6qCFoS
AHtahQ242Ha7nCRHNd08ISgp9ZT6PGqiWWZR4xwfNYPxvpr2wcSoMu6rgRER6yWY41q1F4l0
kElDnCDUbkjrTCxNrl5tNzLdSgF0OAiS4e6lQJDpJbcK7FGX0DUFkDJa41aNoTQ4wMbVGA3d
VEhJHS+BE2SjyTXtI3hFdp0EbVl0zQpJu5G/+4TMfzioRgdxLGrM6aqxUSU5TEKsAcGhN1KG
ccGuvcH37XOF8aDPxvxQAgwOlVBSwjUDRleD3Ouh2AIAsSybHPxpLkQ6Vn08XiIh8tzojbiu
4XRkf8OQJzHc7KKsPrSDC/DTyAn28LXEOyIjtZF1oXLfgzE42zJbIXeucyC2hllLbPaJJRzb
3+ZujnendIa0RMbC2nh18yjXGUTqkVt7mEh3P3MCt384ShCGgQAPRxgi2EyA70tgugdEDTHw
8mFdV/Oqp7u2luqUMpBNFbI/6SKAsDvpE4C4DpZIol+xNNqPIVC2PyAh7pXuBS6npjQdg69M
8sCD1rfty2AGN6rd0WEikD0n8CgL7DTsB1PoGkDKN6YlWKRcx1csc/D0tEnD5OkkDD5QmSCI
/KqnzAvLCdn+6KymbKebMtxvNqu5vRQwpaKRF5Cug7B5+eum+lLUJXk+7fWwiFLZTZX9LJIo
FQBsRMvqJ04WPB1UVAEHwIe7cvXC8Rqk2AjUtfX3SvqStq0QcRhu5YsCwotuoDR/C9ec9yn5
eodQq2elgvKp7wn5ZdzbMx5HMBdXeMaLFj2PPB6QZ26imXuJlDwNB4nG4xPP4OU9ganDwSum
8uAgFidFQAckaiE8RUay8wYBlAQn0cqmAqQM2Q01hzYUHgk0c28C0WjkEhiUf9QYdoVkAXDS
/6Eu+RKFv59+IZpqhssxBMUpd/XhBw6CWDENTRPQ8URIHd1glxAbOAmfDj5wpDpAuCQ4EW+f
3AiJrLdbeqQsCjj2xkMjBqMQrXQ14Lr5Uu74MJPU9kwv4Jw9OqdGip1ymCrEmwiUk5rz+MK9
VZTHsiTWz2wD1nSfjoghGQ+ddzq4r5gBooxeL5vsuWTwxJdc9oORjmpDQoKc+jEUarrPANuz
6ruSXyvx7WLnDN4/8/Ecy4Bw5RztGVFLFu2utLV7PhZwNrI7P25hvVOwuqkKtCxy6zhRziCQ
9s5Osir62POh8GYUpHakDv9ZRTKmDWGg2N3Nis46ayHzPZFojHBEAxv4tsedPRaMQTBuB/t5
d21OkIAeuvf1sxwvweEVg7K9K9Yd384v5w0dLDY7KcZhhapPtDSZvpSzFxJ4Eif3FSXT2oSD
WLqBJn1bkQYladR5ZNEiO2DZsIPCsiapHwTFaY//pNsYw7IPeOgglI6fxD8DGABE0hM3J4K+
jBlrxvGCnXvyaSDwPbPMLo1vKYNtgQsxHCgdMqlI8nIHMeXNVbtZDXQHg6gedKDMuYIFiHM6
Dbd4pBHyxmFzD0EMzijHneRMnoSxkXg80lx287Zau95SVsKv8V/Q7ellhSx7PqzwH8q14vsj
AZ/mfJQHz6dxfVO2FZK0fXq4gF6nMuRzPGSlOid5LFZ8zl+XivioWJS/bszo6keZgOtyAUcw
3xSiWEoYPZtw/x+OpQQISEDzpXHD/exGR0IJHuKmJtUcHYFiyiIlHIA9l4m4H5LIdnAwOmJD
n7hSw1isYAjcVCfkrXHvOY6P1M3mzQQExfHz939zdErceyYQHuhjd9zLwWMQDEk1OnQGAEcT
DW8IBSLKRnAI7iRyAgtZHliiI+sCkATA0VcX6Cx1QnfRkFhHgAAWzJNDyLoaU9xUQLXB02gP
E3odxgCeCIiMliNLD09kjvRzgj7xLNj9j6gv97mfVqZxg5wa0wUr9yQaTpRUeh+8C1b1wNUh
gvAjE62r38c6OTxMHSfRM+PUyGNjag7xnSHRgnGT1HUiW1s0twggrhAZGdQyWrYgTBR0+Mm3
xEumpqoTd6bG5GgdspqH3BVc6QAY9jrn4luCgkBAdIHbDbzYdxRCvPQa2CdJJO7iOI50nAZS
YTfyYjk2xSpQ72PoRY9nL4Gg77mxl1ED5HmhENyh0EtEnQN8KPSCN2oI+k2Rlxw3LlD7aeAF
uZ3czcHAi060tHwSeAlwtwegkbUHTUi6exJ4sbpvIk3HwIs/Xnbmce1lc8SQPoRzP/RiHWC+
Hch+7MWqQ4lQNcrcfLxwICuRyhyMqhktEx4CpteW2SHMYRYnmsJBk+FNo71oR3OjOHoBI/1w
PIKQ/zEHL92Zhxr16urNyegu+LuP3YAuKeGWMvL0P1BeJqKq6v27i5c/0NNxkTiKUlv3OWvA
xjFsvQNauA3w+zFXearOxZohB9Q5unv+NMNwePUoFLCo4DuBDnhbmHh4W2icSMSgDEarprOP
wdQZs0CsV0WngjtOBovPDcDkqYz5UHZZLI0P+deCiD1aqb3dTM9jlXhEal5CzeG8mb4h3sND
9KLcyfvrjnYUnSTq06S46Utm1IsPV6/tLZNPU6hCqf9ttzq+SRWKEc3aD9BI+CDGbkQFx0wV
dy6sSWoKmTMymV2EDGcRw/dO3cCmDfqx9D6IJitftE7GbjnJzH2SiUBYhMJ5UVMHmZYed6MP
w+3t3BKUjKFO5pvBhBPcJGH6/dzmNPb36bXniJaurTyMHb/N0GTmhq4DGWHu8xNLQzIfrUkC
8DNqksw/hDOqjQFZ8a/omAFPvEhpljNkb8nsYue4AcnwJ4rSkECmpcoTdWi44BJLlUEdsmNG
nJAgrjpkDw5f7w9nuFoYPhnPsF6ZUHM4chkHlth9dSh01CGi6KA6RO+Iwrdj1aHRCRjrSOC4
lf8JYoov5wizJJHP8Dxx3BPWeogZ5oxIgmCBYE15POME4eVE6Q9ZIqSJOazp42ofgZPxwcYX
zgMNOqDJtwgGFc0igKky9CwqWj66RAT3noo2rINvce+paJZt8JIlV9hLjsnGSCTBAQ78FzuR
yIDOq0PJMbITIBFSep51R0MTBS7VmYB3NDQx8TJwK6C/raEl2plFVB9VtDwZQwvcz674GQL0
vrQcVDTnTBOsg2Cxb8uSAklI93Q0u6y4LUMVRh0tHx+z5ZFZf5QNNGYWJ562Eh1tOqS785TD
xb2noUVjMjPB97NjYiih1PBQdkySBQw9EK9PLexgdkyufYE+nxyjiQdQ52ByDHQFAj9NjgmS
nEFPb6wgjZFAzybHRI5ZRlOS7ifAZ5au3eQYqw3n0vnT2FA2zEk4pMeMDlJaJHo5R2eOqGYt
NdD/mC5J6kxOL92Od15HHR6bgcA5P3xXOs84Jj6DXO3JpnpkDHIi5jJWBBEI9Jw+KpcqQiFr
38tMD8cAMKgEg11qO4VWMimQtTksnh4YQHofbx7ZYCE4nUh+6kXOf4dkG9bF/iXShu1pN66d
Kno87E+bvi+cULXOUguGh/a8XJXiIR/uydihHbrSEOSUp7h3LU9Yh54SwK3evUAmyXkAniSg
4M4PQegZTOTpnjoRKHmqILBJcpHtn1Rs1mr/j2OQ57AZqAK45M65PjfE9XL/GUo0zjduvGs7
OE8BE9gxhO1uTjNpiYV2noKy4ZqY3kpI2FvD6SU2WpMMc5qGEny3edTDe4GBzOr+zfssEsiY
E6THcK2sFF45aNre6lJJMl6GYqwI6K1G6+q//Vs0AuMr4OPjNKEK/5s/ThP+pz9OY9+XgZ9q
0mEzFLVa10WPF0U68kb0eHC5bcs50ivWRccPvjhBmdwNJFo724f4QFaZuBmUE6zRAbcibdBP
TrTvOuzoIfScb471bCEP6n0Qy2s4PnbRvG9aerFND1p+xsPZv9SF/7gK98hvzvJlKxtnTSxa
vA2MCA1e/XMTZCgfAreVxttPdnfiNuThGaCn+emSPvZPW91Wq6Ke7rzNH9DjDlHOVhjd+mjq
LyU/mxYGeHjquuoV704OZ63b5rrGW+p4/lghE8uUr25Vs1Jvrs7fXtGzantviP/djiLyaUEF
eDd7c+rYsyE9AxJRLpM8kyNXUeldkYgfpTGNPoKc8B97aiHGnTrnCr0ofIhF0o146+hPhywQ
lD93NobDzWXUGo9d+zQNsvzDHevIHud5IGSwm1/vZOshORPQODLkvHTebQuE+qf3QcIkZoQY
2KcgiV/Wxb27EZBaTEOJfMm5W9lQyuDRDFImd7zKOqRlRtzveBE1D8dr7NTxU8+avaMsPYf0
LOHwX3Milti9Xx0776pE++diPDylTsAdj5qsIqYti55caYYrN9y5PS2rq30qf5ozYT0/EJnZ
blJTNpz8e8TLBYZMiKfI8eA+cx7J10KNk4aRDTnT/h6h2Xifjadk59paOAZnqNleOiLd+DhI
pYY3zBJR7iQBJhGP+YkOiaTXw8jwajnPI2UFsqOQLoVa5RH+mNC9vi+aCr3sYem4bvq7MZ2H
3r8JFLwp45tD8CjqmA4S+pp8N6Uaf5QHEXdb6JmSIAhPTk5G+YtnggGEO+nHhpIMcnsdJicI
XFx/1fqXF04ub4IBoNX4AJj1WzNgVPPTwa8V0xNYhxxmVt7w0R84SSpW8cO9ELqf89SnZS2B
gAcyurSsABGcjkcrD8e0z1juDzfOf4BAx5EmwBPvj05wMy14ElW2ThTk0RCZ+96sdPRm2Yl7
4swit+bzviz2mz7ryiJP5WFP1q532HFkEeCQH4v7es6NRdDf8mINzQ86sWyvT31YjPg3XFjs
CH/eg0Xw5x1Y1im9778iX+5vu6/ISfms94qgzzmvAPx235X1vj51XT11o7qeK2p32HFFTttD
fivC+BtuK+sjfuK1oiEdcFrxPDznsyL34vMuK4APeazYJfqMw4ocuIf9VdTuOXcVAX/bW0VV
nnVWAXrYV7XnN3ZcVYB8i6eKZuKQo4qn4jk/1f9v7mp640iO7GVPBvwfag8GSICi6rsqF1gs
OJJnPcB4bFha+8JLkV2Saofs5lY3h+b++u33IiIz66OlmRHXsA6jUUd+VVZWZGTEi5eQrrup
xE1+wktF5y1ONhMnldzKZ+TAX+OoEpw05upqn3yXeNYWTdC+SJQaWKjyDrsp3RyCxE2WSQru
sN0fQEi3+5BMGfKmBUl8Vp8e+S8y74ksU1S+eyGyK5eFA67GCcuGv8L39rcIa1rmTn6f265V
WlNADOBdtwnKAooSkmA25ZpNV2rHpV2HEXGoIFsL0tgmVGuxkQFHqRwajbIGJzxcLqS0Sm8T
086MRVdR6pWInRAK+X0B7DYa0Va6hDGjX150xwtHuYhBVXmtI1HokYtHAtZISl3spr2MLq/J
2lomdEkmFbEVocBa1JneI/JCK4O+MVQVIgv2qK7XtklWHWvw3EJwgpauLD1hGZudZR60pUu8
e2zYqq8ixn2muQ62ZH5NRJiXB2qKqZfsNHXvL2JExNFN3JGNMl/6/DnvskizxHx38Wxl5XF0
Murap6iGPGEaDVaPa9ojv6tCZrNKztqY7MRpeydIBlJ7o1ly9rjXUfoU+FxGyQSg2932vx8/
dof+VdhXJEE80+Ds/jA+3hpSVk+VeFCWABYP67G/GbvhFgDB/lX/99tBTnKlfjBtqcW5K9wN
274b48wMJiPTeyVEq3BF6obj8/LqVsrglHZ2ffbm3aurN7///s9CexAQib9W30liZcrz7bF9
JlUF0t9GRNFJwgeVnQ59Euk3r17daM1g2PiUnVQkAdHuwh4pTc5TPyxBi1R00qxXnm2UumXN
LlK3UkIq1xI/TI23UmhOnsbcLQgqJhHtwymESHZWUWCCUYbAY5bWao7SJRbM/a/a7cjTlhIu
3UTzE84vv3YJtMgf5JB1z7NUQJu5E24oUzytzhGJO67P7juFwhpaKY1n5Ga3eY5mJCszncfI
NCqjjDGIllGMyoYMf8fhaRefAZHHz+7gCe222/7v/V7JcZwZw6W17PdzW2G2EmapVB7BpP0C
GAXWOB8qE1IHkoYgxvNg2QWBBMfz3X4YxuM/H7qx+zh2D5+A7Aai2yELdQN0Uqrg2RchvcE5
zBtI86R/CJekN43WOk16o+0uSW8K63CV9KYS6RdJb2zYRnrjZqQ3NsCVHckAlpmWWdAtVLXV
nu5JpvQa6z1sSoYOtun0u1Ib/JT62NNtqYiyHyDHh8RtyQd8lWoDdLku3pTizafQzaepMin7
pc3HMnxcI+Vnu0+RBqcM5QiuRNsPbfSY0LCqteNw8g3UdXWuncwZCDwqrK21H1OVnlk014df
xXBRccBunOsenk/lfZdq/bTYxFB+CW1HahVV0EnwOnMd2dkCvJ7pME6D13FgZJEFeB1OBZGY
u82eu0x1tDTmhu2h/zhO6fYrLHGUWAG+16X2uAC+14zUHCUgLpx9YOf8McxtNbe4FexfghIG
0shbpbmKJFiAaDHJNakVqjZ2V+lJv1TJ1F+ldkILK4LSub+qrgKENtQPwHiD03EutGP1WJkW
yQtrew6Mtxdkz7PwWZmqaKzAzGmVRraMTYgC4+OkNIg+D4zPSuEPmwDj25ArTPEUGK9BBBii
kH4BGK/Ij0q7QhTmKubMxDDZDA4eiM8g6+zw/GrsN4+3ksvT+MOddknFGcf/zSYsCu3F61zb
rlvtP1o5TUzNkUapJy4OMpCpgOIlq4Vt2dY4tOKwh2USzW9Vn97HmHiOEvN9rMJHzapo8wo2
RDQoJNhINZvNIiTmlhOChjRoJwgmrrBMvV1Ou5p+jS4AcETs6FvGboeN/ApKml5mjwZGvhKL
roTpSAJTTczYNjjgpYMlg4y911Zr88W/eWVGrd8XrfUc3ompsj7nj4F+I10yT4O6n4Il3ywt
QIhO6t8aXwlKzNUvwAAimGlfOKKlzbnyNZrQUgvEurcOp3B5iLn/LyU4M111d2aZCYNFcxnR
GxMoJc3aisojUwcCZAOc/bQbbvtX3e1h+MmYTY0yJbOHwsvf9Ifgm/FcCVDsfKylD7KpbUok
SvthNx7C8JQ4BaTGBKwN+z75yGt8lIfvr1dvX7/54T+vzyNCOtjq3lubSv3IIeujkrk2vYAe
4E4Nila3KVJqivjkvk5yJBRZ7OsVUrxYeakafH65VZ6lLmYt1ysqT5VDFnjUpeJR+k2UxkwG
PghgPiKZNWbgq9MZsFMPplApkM20YxqylCElL25QDt+IcriIUHoA2EtDeIdPn3aCSFSeAkJg
KD2pBLAYpMi6Esidyk+h7s2ygT2Gcgseu7rQeVgJ9+O5pfeTsHlkN7HIAjbvGh0aRt4FEJhM
PHkqZppAN/gq1wJxdLL2jOQUBV2vDB7CQzNl+1JQYuNUNlMDXvGo2LSAbqxk6cPvdAF9uNuR
afLVw04os3P7mMh9xuaXpriRsFiRU6Fei63XWXg82cotvkQKzwnHhkEMXKpz4hkU3Hnwx9ek
amGzafzBMnn+Bnih4xDuu00fEVkePo3MpwmslGQWcm9g3nyzO4gktEX7ih2ELqsJrimi4YLE
O2/sTKw1ps6bOhgFbC44+3UxkPqmSk8lApJ9EvJ5HmBrTc7SAF2RaYNQ+6qfbiN25Sz1I60K
H8+7nDDhlYWUiJIhzZKz8SCvFIfOQyfOZrPkSkJJqlTQ0cMWQDr/JefRDSssFKl1D83QvgnP
2d0cOjuweYgqudM4JzOHnbw155IK68QyIId9cjcQJzNs+dLfJHg9uN7oKx2gnhUC7/fsW4+d
QSzlvnu2gBjdN+cs9GKuGefy+O0YcXYmkrl/ogk6n+IZlZ36CLBrQozwSBQyjM7jJDtFkfnO
BrgMBStISGx37BUfhnn4vI8aVoqXeg+fD7qm2t/cZuIRmPWmW7wlnBXa7NJiIdHK9Bk8xKj+
XJu1sweZbt4ea6q154ZYW+ukRR+/sQDiDEpRCW4NkkU1UZYBuBxyGt7bQz+SKVi2rlxXPLPm
UGrJWclcNJJBYGZ75SBRhYTIrQjhbSPHRXwtDfgxKCaMPKbqStPSWp047w3OY50uMp6ZJs0m
vfPeXnLum4y5673CKbTFWdAzg29LZoj3pQx7bG2Pw/5TnGGANa+UGAWmeDROPXPAgQdMCmDp
3vSHp15u0LMgo8tsqkDadax+z5ThKnpLbkVTYrukZOpAdf6SGqkWlqftB6lWK4Ugw11FX3Cb
NiaVL7i/3Ue+H5zVRYy8hid9N0aGltbaKff43cNhuB/+VyY7JKxr+8vJRgK4rzz2DyDtFxix
p2RKcxvcNGLn47H20NFa9cRc2vGcwIcXXUIAP9+ngQmyHpbc2gOBTOR/HjuEZi7CJ6lkI7Dt
0KzclyNTehg7uHwINNaRan2mqHfbhMQ9fx/uwXGfV79LgoMjoYODFEHn0nTE4dDEK0EtgyoX
CQJzduCJlCpuRqF85ThiIV5tYa6yWswOq66qJADkpZ6dJ0xQW4NzGjt81jLYpo1o/gRkav6x
wrpd8pr6h2UQZDN8xNVpcZZIBaQMO4AHfj/cP94dum2/441Eee05ULQU9IAcXvn55IHYWAaw
QmycIxEF+VGbTvJ61IItTSaQmIcHu9hyHyHCyOCHQtGXqRKXiyS60sVgFE4kIX5e+2smKaAK
ftzLx2ZpRmmlUv9WfTyeLwEjzXP17G99dNe74AstFH9OVWBOk46nZ78ybHTSM5T/GDme67zQ
irVVvKJp2Hi2Ju3V73JtYE77TJfO5qjATj56RkXljoAPwwz/q4jylHlBghJ38Ckb0qINXw6l
tRmjA9+muXhIpVPozWRMs1AHrktTrcnshNtDP7sJN8XjsAD2uadPg5wYs3g3mwHljVmoTOdP
9M2E2QMrTOS595hEbPXyduSZM/OZRDFRsPutTYkdsrL61Jw0gbmdJZByU57HzO15YZeLyZTE
1EJfk9BIfoYSH863Rmpz+DSMmyiSudteJN8lcuGQD3fqbR6eoeoyuUruhy1IRJ4fdpAMyg5p
qBCnvS3t0IY5dEcR9M4NWT3NkdnygmZySHB1bvpx2H68mKT8wT3BIoh0cysJ+ojPWNHPUDZK
KgbNx70kS5NruLwxSXd3z0l3N3zc9pvrcwwfh4Pdg9FRwAlDmFsMhzNBSsH12cirY8h4yN+/
z8Vlw82oPB3O/2UUKcwJUsuleCFsnPABCFDAsFKV/QydfPWxG4S1VA+zpbEmeDIRDZIw35nE
BN6m1iVQlyqJ4XPqvi3TwHMg1o2efFxlg5sA6CzLi0n4+eRCIk8qnykNQoShswBTqmQSTAaV
63LET2huyqZZsCuY1VtZXcTSPENdFBn1MxBfSVWFe53yCZLXZ0SkEQvF1Fln34Jr55NUB/pL
fZ5MFFtxyTtC65AAobQNcCx4ON1Tr3xzvCovQjWsIhqOct5MPOOfq14O1pDjkieYzLK2GbZT
TUBuJYjneQq0Wlhv4fW1CHudalW/mxeeYVeqrmUWOMlzPw1s8AQrrQ2g8JN/EWfplE1q/WQC
bXj7qKaXJdk67QsmKugMI6r6urUHnBnvZmvbOBlMxcljnJA0Qrny6R0tQn9Q12R5UuYlZzD2
hvt+M3T0BuncYkNDEZJwYgIet5FlVmgxZBpKS6AtPYzddn8/HA6aEVbYxoyTK0oFCIZZtsj3
hwRfW3VZ4Gtrow8Rosjosw/Rxo9a9aRWaV0x20/Z+BT/kMXhAmk6IP/tPNTogFY85zbrWHZ8
GoM/ZBGFDQTrFDZt/YvgDyy/Cn+g5PPwB+lsDf4glT8Lf2CRVfiDSNbgD9Ls5+APLHEC/iDD
XYM/UPJF+ENOvHCkAaNAQlWqPE7XUUhcLVQHMQJC1xidpQbDFgSEKmNhDc7mCIgi+Nx0NDME
REjcq6L6HgFh1KwkobOOBQHhfGjXep4jIHyEDBwZLDFDQFgTTautzxAQTcw7Y9jqBe8MFcpK
4o6eYOvUCAWmAAgFdzS5cQZMU3f0vGY8Bl/I3bF1atwEPrbSzAgPTgVXmohFyUOZI/SD56Mw
igO/Lu2w0LQLNgbLOAM0Slt1fjGGDwHDLwQSu+AAM7hpJiUCpVapSYCVVl1sdrYwi0Kr2man
kwUKcak6cUhYrDmtcq2nU1kXwW9YTNC5jcW/W5XEQbGAD7WHnH+QHgeaSoGg2T1RdeVKkQVk
g0eW2NQsw2Hm6UTyjT5paUHN6Lz7T08SIZwQZVL+k3NClP9wToiXic+kX0iJrbGJuXRhaTYM
T6STSHbI7SahwslUWfLQu3SZKpvqkObZu1nGmE+6Amhpoti8+rdnSbZFK3UXSbZlIY82ASWY
LixrfYhgxl7Ge1aj5Bjev+RCyjZntXBzNMs5fww+DLcGZVGdB8qxY4EFzgkIAtacOWX0mej8
g3jiktGt3cFdB8YvxCEidEtIEshg+7MIjrkx6gVjt+0Y56ti1dxqQvYySkRuV59CK8Nf8jbU
rczZXEN6Vk46upTryPcaTqliT8bXCwToFX4/CYMBcI8VZ6FCMk617ToEpoFjGpWmAJgW3pc2
SnzTVdFWUnwFOOVUtDgvWVwHcCAZxwTVUlnkUasvbfM08nSjxBTU4i1KGFftqcT43Fv4bj69
ZcACQYDphR7wiAFu7MUaKbZGOKvSsUDQArqtZ4X87pWA4eCk/FIHmBO1ojxWAcExAsncn+LI
n9FMX4vB4NpWhz9XAFlItC2WIQ07dKXapR2I/NtYH0pWZStj8dRS2tXs2zDbA+QGMtYyrPH9
hMSykdaxyG+Gg399fEkk4ylIMLEfPPAupndFkfm1BjBt8Ts4veyYu1eLMS8N/KzNY+3247gb
xTi3kwH5SCIWUHN0plgaxLzOCKDTcEaGfC39OdceS5Bw3ag/vKjDeYGDXp7yLYWOy4/PVUyj
L5cxo0tbSUN4XUTpRFBIp7I12EdJV72baE6yN3m8RwI3oQFsbp6TLvHgGMPAnEsTX+vuroiR
gUmDA/8WPuzg37qlK2x/wIdEt13MQzx3hrEATFMReErjTX/XH3om/DTZy1kt4HQFrcTZFZPQ
h31y7G23EeRMkSb3x4Eg3rBPLi8v+8Pt5TmLv4jHuYkczs0LOZybfJ6YVpSV/rrCYAfEJIQr
UOsKDpI8Cm41SYi51E7qSepnrCb0rAuQLAoEzasuraLh78Rg9vc3vSZTB7Oh1G5J8/T2z2/+
OGHnz/RhFjdEBWbfUkrAYn76NIhPz0eScqmPA/ynLk6AQJZWs0ZjzAMpW6xIjHMYh+1e4WWW
mVPomLFz3XYPmjIZHD98201MPqXkiSACJZFtmZxtxt3Dg+G+9PVUUq+R+M0+RNhBhcEWPVlP
6UmymjWuXxI5sCuyCckaD3tQqz3Re/C0Gzf7yERxbSOd+Z3G0qzLUmoxKH131/80iI/V35YA
/BtLIAS17Q/Hpn+cZ5VAnosjdAsv+Qw5By0qRSQyvBmCDs3zEDxHmcjlaEZF7mQAkxUDyEQb
3k2L7BfGVSJOcn2EwlWUB25wtfZwFwMrtpW8ncPYd/cRPKSupWYu/uP7h+4wKJZJI4zwN6JE
HNAI5NiQrNsTUsvjYmuJ49aBdoCNel5Jz0mZN1IRMZ+bbj+lMSgrHczCIwwyVU5B+GqMcBSU
cEeJj7oUIaNZJrWcp4bbG6vsISpiIoY7SbcrLXc0ldmdWzfMXYZgLXWZubnw28u0JKI/IiKE
7xhbDTRiDG11QMg0Sb89jM8L6nw53NwlQpYpyacXSccQTVuepuUoktdvdo/j0I+irtO5tv64
T/KGF8hhvYCe7o1nWaiFpoufKfMfDZL8cWTFQiri8h2rCDAuOe7I79XB+n7NnSvcsGCVS6oN
OLSsMr5+9troUn4tLZzzl6iujVjoE6RylpPPQMd8v7duZ2O2qmUZVS0brZpXrPrQ3f7YH875
75W6gHanWeZniv8grQ3eYLCbltPkqxG0zGqVn6hgDi6nyFfEHPEfnKT8orgoL5LdmFSfnSRf
nbPEf6H6D6+vPKfHyvyEWmWjtSomzXnrH5W+CsMLOB/OmPzUu2TbP/krIa7P+suPl0Le5q7P
8UkM230/ivnVpi+Zbp2GdOvYvihdJcLgK9IjNgDzrLV01Ob+siyp6h21qWcT0Q4nvFOG83Ui
PRGVNIa9HGuQrZj2bah9TV6WjcjxmhGSrF5dRMHzildZHcU4b5QUeQ9sVgVRMRU5feqIWqIJ
BzaKcLXRWf6KMTn7ePMmSptGzAXumonVpVZDm0oB2chBXD1o6MKSqStrAZbK8IHegcPAU3Ou
8C4SdLAVuIweHu/2k2uZUqbQL9IFjCEW2R7sAY6Q+93m8a6bpFdbWLjkDFaRu6wJDHjS/tKB
UQXPkHRywlEZJx/lmmnAm02j5CMk5yzMK9CgUjI1l7WezK9bc3TZqm3y0LLdkOg87RpFAWun
iC7yALm1gGPrk8m02XmInneQUTIHTGR8CPyHYKtw+2Eb58E7jUeOvedrr5ooHYJ9LqkI0xPT
R79E6HWFjNA6XbARtoGNkCVW6Qh5m1/MR0iWWvcy57iMLx9r/g95Lcih03bBzzrIYYpBTEC6
p7Pku4SEVP/9uD8kAtVRywXoG4q6rZovcGH84fI4DMv8eOie73bdBuixXoyYi+TmUfNXLK6G
fAX054Hq/mSTFSIh/Wp0V+Q5f/FUHtTXdSaLzPaR6tKGEt93eCzAXy8I5frrsOnBNs3EDAz+
bvdEBmSCNSbICCNDqz9zTP5l7w3oEIZq3/O7YevV111mUDDDFuq6woeVfLdNtPGL8Lb+/D4p
gfYx/xs0+vG3Y2v4Eb8l74SxiiVvCOGu/+NcGn2ZZ8clunxh3+9u/YVkf+nviNgaLTB2eZ58
brp/Fl9OwW0lJZb6LHmnjOPb3aGHEW0I65Xmj//zWhjd44E3x17hJ71GsNkbUb/aFsISaMo8
8BEb4TWwjY20N3FTF8zW4rWjrb/wQHfTNFxfjBLUkEaxHoxMZh1RjkMv/Ib7KLRCth12PLsw
oXWVCBZ8jMKFxgZbMTo8q5ABr1stAZYfQEz1FgWzIjKmsJXTe8jM4ql1QMGX4ylRVLLijmnD
vZOr00h2Y62czncvC4xByp6rGVyG7Fcc7zLrvG11nub0VLJHrM5gnqY2hXir/ra/1pNdk5J1
7Yo4XBgpQuDH7Z7k4OKQ51R2e4VLpp7plhLHLLHnEGiUFQKJwxlekk70bNOabO5Fb1sd5eJu
YFdrFZ84qWB9zqLl1sQMhVWAlsk4jhU18cnCOLmNnlmP+h0oNC1zwaUgQ2p49UYEFZWr61ce
I6u4zpVg/2N/iC8klWzHNe593v3NrsJVHIZb4DK1pJnr4BX0SH3k1QvTgRAK3j1u+v25B3Hw
/bewO1MFuGfZRaKeF/yVX1CH49IDvefs+nxymankT51UpOuariUO5EU1Hfl9FuHBJmTPCwHQ
lEhK8UdZKuJlIBkvDBIY1ccHHsYAqyKPAhuVvBXyiyWBmheHf8oXacJZSt2AqvjqfvjT+5gI
DelhMppIAbTBAUZZUACW891qraWXF7zF0tvUT15Ghws/GK8CPP9watKKDsjn+GhT0/BffUbx
TLYR7K/2Hk0dKv0UkxilrVp7ocspyNNGu2Suxwf/xXMR0AcfwFV6nIfh4piyBahsD4NND4F5
Zsm0WhnukZAoFWCrlQF8nZSLTqsG10CatcQAPIjdB6fbaAD7HiGhQ38nxIN29iCUgjMz3zNc
GZ0xUCSwqtpk15nVxkJ9eBxvP3WSBp6nbUDKsAig9O8/ccPybxmuZAqDU8KwwG2lM2OHKafv
oSjDVPzUj8/+VCJvQlYVj6K78aCKXo+EJcEmACnjaCHJntTQF1GMsWaCc1tJ1th+0ANvzGMB
6WK9c5OU7nkYf3iWJIvgF8/SRivHNkEd5zC3mkzEEOM+pmjJXXOi46zwzQZFXRiDZimiRSpt
BeXD/rDJev9DHLnm2R5F4DI3JKplVTc2l0tGXYRfT82ERmnSsoprI7Nde8VbzFPsyLN50PhN
UYp4weRUZVrRcyo4by1IgytOEgCoKIwYgxVQW7RabY550U8SYBnIF859h0QQeYIp2Y5Hl9sT
QrVd3e13FzFZX17pE9IHIVHlaQyLien+UeWzMQRD29ioF2/VsDx1Nn9kD1UobGSr6XdtXZ14
ZEnrmM9WnNbBt3qsR1/U1UYiTkhl4qenXn/EvFkKuuIgOl8/XclRR05W0PgaE0IyISSTTU19
QM6pbGkRWyAulRLRAiiCZqUI0agPYx9l42bwqmrDgD3vnrZ0CUTIniLTEtHHYxw0oLyVh1kY
XUxWYsPTTTMLPEsiBtPj337/TZw33+Q6yS0V14E4bhtPm5lwSb/kdG758h4ie7sIASIWWESI
8FoxF/CoRQ5CjfR4bMR//eV7uCwQ7PNZeOes9EvMtxwe6pc133IsjBNrUpPEkP2JUtFhQ0kH
s1IkQp3vCbHVMFD6kpTgqz3PIhbJz1uRLI+G7jhMqbQ4kbaljTbgiG49FCyEKrXXxVEtb9MT
TWdFpb1+5tRZam1AG797F8LjRECfaLdm7nwb0dwYACDT1qY62fSMTSzMsGszqswwSNP1Nkk3
carNHDx2vlp8as4BHpaJhSM5AIWxOpAllJX4Eu87mGW78TmhXagplXZRg6CEuh/7ffIw9rf9
hl8B9i7xGI6wNjfMRP1XSbIs85OsMetrHxGxF177eeOY4v4eeXT+GAqGeYroa/mpvz0+NbWB
ZbFhY4Q80sSVxwZKzaW21VO4q6VEpG3VR1PrgBZcyw47PludEqq4cJEAxcGjYfGPPBcJw/Y9
AwD+QIMFuFoLyMH5EA0qQz6B5vR5jzhB6XJBgVi5ZjFtZkU3RXh2BUSUEaWFdJnLmUVpFHwC
lMu1cgjre9oxnThoroO84zbW6Hz+NY0Obznjx+SrGDrNWlDFBic3i3gVY3RlrQr80UsNC0mx
R7V1Jm/dwFzdasMzTrMstS6XpF+w5CgCgnJ2hLpg8qP3nLShDfHXWxtUbhKFyZjUaPQuRfSC
VgfWwGJhzQzh9u7HPuYIBCKDUl7qolGf1LtItNE4IbiMXo/N5PL1EFVUxSTsBk/ECxuQ4YXF
Nz5u94le5XD3bOGLx30/Xud5vk8e7roDmLWYoF+dTvr+OQqFSGOG1oEXTeI/5yEBFDwrXy6V
/5y2QvrH6w/3SX78ddN/QNTQJXnC0VRZkTCL5tvf/mb7/59No9iUtZSZX51fozLZDfCDH8O7
v77d3SKqgMH+9jccrYzrOB6k4yTvx8f+PUJUbILXi/zYP/8bRMc/f3z3/n2R3eZdm/x7Utze
NG+vxqG7+zbln7yWv25u8desSrFZrdLzL+zPx//OqlTFapUuqjLvpeq/2Mu8Su0+U2X9WZry
MwM7UeWDVZHX8nMepu2++PzzKXOVVTHQ0w/906m+fvdWk/vfPQIT3W+ixfkw7m73/SH527At
qrdY+EVy7Cyu9UPfbyZ1/lELGj/9/k/f/vY3//J/UEsDBBQAAAAIALqKfyJ6dAiMkGAAAACY
AQAMAAAASUVURkNPTTIuRE9D7H0JYBzFlfYbaazLGt/Gt10+ZCQ8GluHTyB4dFq30IxtfHC0
ZkqaRj3dQ3ePZJndhMuGcIRDgmQD4Qixlyxkl0BgkxCyAQLkIGCuhHCEK4EESGIuG9sJ/quq
e2a6Z0al1ibZzf5R2089Xe+rV6/u6uqqVweemvrabd+c+zqkXSdDLnx6vBDyLG45VsAUIAgA
F6FPjx8/DubvLxA6Pn79n7m6QCH/dEBQDzK5qzAIY7lOgAnJ/KblAQqNUvIDg91gxe71vDvh
k1O/55pA+bmGmwtqSfhRiEEHdMO5MNZrGuS4rPFx6q/bvG8loasQhjpyD0GcaIJZOji95prh
u81y78TPNYQO5brYbyPWmIStQyfLCwnGlv4ul8usmyOFv7dw6Ycfnfo9V+JO3Z7zVM/Y6H7O
Q/39mfj71EI0LvmECmh2EioiNJHQfEIeQpMITTaaAJjK8gBgOqEZhGYynQBmEZpNaA5LI4B5
hD5HaAGhhYQWEUKEFhNaQmgpoWWESggtJ3QioVJCZYROInQVp12pJLwqQtWEVhNaQ2gtoXWE
1hPawNozgFMInUroM4ROI7SRkJ9QDaFaQl/6B2u7LiTxnQABVuqjILC63wQy9LA6QV10EMlv
GUa+SiHHlmbg4KJlDuU6QTq7xhr+X/v6vxx+ov+m2eFm5QFYn5+t/hdb6v+nDsvY+PX3fUVj
ipZeJhaa+RwQo4KCaoVsmI20X3mw7oQ3zf4k28Uwf8S3HB4Nc/57b/EwtGzm54/ETWGmlPIx
G1mHPePodA5modmXtYkhVdGUHh1tVdQwWuNbZQ/LzQ+Kyckx+x+ezqNdo43P/9L8dxEpuUXm
2CFt7DY/azqgOiUUj2JZZ+1CW4C6Eyc2GqC/fQm+b41NU+ubhMsk2o4A0PCztUuv7bnlgyMd
kSl3XlsAK06895eriNvBHKP9yTf7a6rxy2Z+bHQZbVbYZbRVl7mMdusul1GeD7iMcctHLmPs
MjvHaNtOyTHGMOeYsi/JMdq9O3KMsvAEuVeurqhCM9aumTnT45dlvAudXlnhq0VduF/UcBgF
aX5T/Wo37Nza1F7XsTWwsy3Q0dDQVFtPHbZ2dNXtDNa3dbb6g/U72zu62vytvrqOYEaZoS5N
wc3lQSzhkBKNxmUxJOiiIqOALshhQQ2Lu81nHNIVtTCIozFFFdTBZL4g8yqvR6VbO1HVyoo1
ZbYwrHU7osiDMKlGUImAjhPbjGd87PzaSjgxzXVabURQJayhBlHf3YtVQQoT5ODBKigxkP4U
NovEumpnuJrVUJaByxZ2/THt3DXOsX1rHWPjRetgUZpmRc0KRnU4FBdVwEfP8Kx3Lm3pBufY
JSc7x9af4hzbdGoi9ZPIKRl+9xx7sPMzcEIr8V2jKgMy5LVgGbUoULL/fM9pMNkf1yOKKu7G
YbRZw+pGWJLmAsVtYh9GNfFQn4QHYW9OfbvfAeibNQ5Aw7UOQPfUOQAF6x2AvtLgAHRzIyyx
uaUnEezNPaVhE9T50RZBihPHVHtaG9d0JUogDtIHluee+WwTVPDEZARN/DzXPEY/PbnnHmqB
FakSMI/nvf7xOxpaHei/ow0WtQqqKnRjjNp8KBAV9Qjkb5b7ZBoGvdqhqKlfkFEXxmHcAfNT
DzCxRpQk1BDXVUGCPW+f3NJpczod8vx1wS5/exeglN6ZhXt/zqaDAVvhNrwBPnyOKwgLU4z0
RmnP4b5fbYbFrT5Uh2tp/d9RmaWS7Tu8hU4nzKsTQ31EkCCHdXsUPUVnwNI00ZPqhH6MWkU5
3I3V3gjsO1L7+DZYSlzFsMU5HVZ/6KXtsDwNtXjVqiy4yh1QMrq4ed0rdmYITMeRAIjAjWeO
CgR8yI+rlp6VEXJLNg0fOxtKWXqKGDUKqh4ZEEQdw+T0QOoPI3TOCL2S3Ss+fFK94BTZ0O0k
Vx4NAUoVgGyN7L7DYShqUDFROR4SNMwrUfjIuYM9MD8FsFeZx3K/8+NemBKIYEnojaBaQZKE
iCBHwGukSaMPtQoDKpZDGGYkUH5ZTiIBHx2eL2bnnQu16YLHJNcF+46+lNf3F0qZDyVHH7hf
GpOfCdGxwIeeGJNGQz9ToCwjSlMzBew7emvYExuT6E/OGxP8sDom+GvamOC/0scEfzU+Jvjr
/WOC/3pgTCUgZ9fYiurgmJT53e4xSc87f0zwwn8aE7z4n8cEn/zZMcEnfc6EYw0FsNovhrAX
dUpCCCPq1M5eMTQvqt1UXlFZUYEasYz7Mapc5UWBAVHfjVVJkMOoVJA0BYUiONSHIroe27By
5cDAgE/U4z5R1st8KBjBiL3OoECwFYkaCin9mLaR3YNIQBIJVtZokD2iTBxF2QR34ZCPRKRi
fQUqDSg9+oCgYqQriqShHkVFOpGqpb0OKT1IiIdFBVG9tBjGoQgSpF5FFfVIVCvzeTztio43
oCYZVaxfT+JhC2ltZQUaEDQUxWovUYREMZJiVRHFdCXdwxof8kt6RIn3RpCKezBLcaKkVSTV
xZCgEaBEoo2R0K+IYRz2sliElLAo9yJ9MIaTMauqRH3dor5SM0P013XWtqXiwvTswzEdkXsj
DUWUiT9RQ10NtUxItxDqGxDUMJEejQm62C1Koj5IlBQ0RdZ8Ho9fVkhAKhJiMVURQhGaMUTx
sEJFDipxFKH9n6wMoNLGZDRIjMuJahoOsbJR5kURZQD3EzFREomeQRYPoj7zYaKoVLwrJokh
UZcGkSYMEoigM5zK3m+xHDbyj6ggK0hS5F4ikcSIRCSEWcjMh6hTRE9cZnIFiUjD58XFfkGi
b7wkGFM/VuRkL2pCAyzBhXCYck3FrDEwlbBkHHUQ+gVREswUU3oMjzS3LRkgGn6T5dpLk810
1OK9vVjTMQkV79KR0K30Yx8qrRlk3AFhkIDNwiFGYxKmL+xmAZZJJDUs9diTwlRIwqhHVaLp
ASuyNGgKXJMm0FeGOrEaEWKaoRgOKXI4leUDdATdK/ZjFFVUIlzCuxIFxYxKT1yPE45ZcjUl
ihWZNQ8iq4wsaclTSBVjiRpIvRlFq1vUVUHHWiJdw4lJIY+ncW2lkU1GEpHQEjlS7VvtW21m
XLepmBDG58WJJBJPI7BuHKbp3aNIkjKgbTDk0TTTYjgk9ohp7Yi1jNFkqkSla1Hfpt1Ga1Fu
VkBa4YmvNdVm1SvzIb+ckUOp4lBpLQ6aJZOIZjFB1RNYM6sSTVhQUSTUKnaz+RprfqKAIP0D
NcWNgTamEBFFUw91ddaXtwY70xM8lazpVc70TTTAXjSQrHap1sUoHjRrNSKO1XAaUjiMk+0B
JtqZ2RSKqyptR1IFsdq3BpUKPTo2olgfDDRR3yrWtLINHk+y5afMhPa2IiErOom/qXEihVij
n4h0LW398QiFLFPmf6uMlQaCrWX/yCWtU8KCRvsyHScKB1EoLc1pdshICAsxeyakwYj6zXFd
F1AdljFtm2lXSdlMhlFCh/yWDmQ4UaBOTvSVXnsxRsRJo77Z2IN2o6JRPrsx67zNDFdoE9lP
XzNRTBL0HkWNakbXqBCYqpJApEEUEzSjqW8MtKFVa3wVq5BO60Q/myjWfKiJJhEt5UoU62IU
G8Mc1marYq8oE/GsRBKpmiL1YwZEVZUrK9bQ9hzFFFVPdI0xVSGaETUGIlg2daW1jajaFqjr
CNCkr23zMy3Jj8389rSiAvnLGfa+ckkYMAYuMmuZaSFgBY7XGDSx0YGl781sBoy+ZuQmINFM
sJ68W9EjyZEOaw0qVjP12M81GzyeIZ/Ph9qJdLSjouJML2MKGTH873YN/+DVdtjj8WuoKVG3
qApmUx8zqjMbttFMHLIPyisqhr1EM03HAsvYodrapmBwJU0/C8QYg6z3oa2YFa9eSWAlQlZ0
MWQ2E8lRsFFehGTXkIgTHQWsT2ntQ5usNVwWojjZlGcMdEXZrLWoNPVeMFRrDEWIr0SS6Ghd
4lUgrlFeSJHPjfcKOi7XdDUeYuMzogLuVgUxRMcyuBzvCom0CkiijAUVxVQcFg3NS2sD5f7a
+tbOsuEyrzmyNjsjWRl9JCzqWqLLSmHTyntpVGC1JzyYkI/0AZrNMt6F6aBqKzaHdxKd74ol
xqdKlg5cVMljTFCFXlWIRWh5o8PD9fQ1JmyM+tY7H/Wt9/7N03fYqEGptMnev7P6k3hXGnkQ
SdsSWce9rM03W41s8fqfbiT8rG2mLwv6YDmJezyEw8lezDJAtlSNjFwyPqD6be/K61HpEM1S
/3AZKzq0tFmSsjxbUtI0s/cMIyecGQqNQL8ihnC5ENLFflq0w1g3qzYNl8SuRyG+ZEXUMOrF
MlbNor3FX7eytr2xzBKxEdqCESJckzXCNbQyDkQUzVZ0/oL42gKh8e2RFOJf7i2PKQQ5cuUd
IffYi2I3HQwQTFQIY0v4ekRNjoKNukcnDNbXlvlQjWKOLSwjWLNJMCsGbXptXYyZZqFEX2NU
qJBCFAzR90Q67hGSjbDSrQupmpTonkSN/GRjAHOUYATm83gakkMBNmwTBpNDN9bmeDw0MLNl
MN8KU31SQlqqfVN6Eikls7CMh0TRpnHridNZCpo5qhLDKkswNuLC9P2bvSZ7kabYWmEZG4OT
MIkD0SAuahEiRzVeqbE+gDHTI2okTWMifFZzWERDGhqg4pSYLkbZJzmdtu0xFWts6GfEj6kh
oIjYG0HnxQXaxNNCSD0aonRVoM0GGwCafkwcS3s6WqYTCbvEqKBjVLm6xNIsINYssCkIM1XN
qmOfQklUClFLTQURdan4sNgr6oKENDEal3RBxkpcM6oti21Y0AUavmQujTDGwiGiVDdGcc3I
e9aUG7NFRnSNDCLS2Q8/rRlpTqhHpd02K3AikVqxCikhHesaTRuRFXezetSktRNpHqtNf7TU
JZpnPSKqYUt/prBJKjrr0Jfq9FKDVGPSgyoZFWXazAzGFGPowIDdgzodtYexmqgALM1Y6hG1
S/uxqoshNk0mSGKvjMNl1DebkYslavpQxbB1sMScVg2jUlXsjZhTV6i1sswYLlURXXpJ7Njr
Nm/UFI+FBWMMnpr1SRQ42yCDTYz6KiwjpwHb6MAyKsg6ImAFW8icDCIynQ8MCNiLhurigoTo
fJWlAcAqS01aAsUoDosCsq3H0WgdkbWoqOusqdDRal8VK4hryN0YVfyvDAlo9P/HBwVpfUyW
AQFVa2xDAubjbzYUYCXvbzUYcBJZ+3CAlcO/1TDAiCsLtTYjiROqaewdX8OyJpqJQV8EjDKu
sdzEqqqoGpvtTrwFshqidNPG0VJRrG3zX2ckYPQjMm0eUw1AyJiY1ml0k1MZiam89NaCAWhR
MhjJWcEwlrCO6RuFn72Sihoi7krYyKqqVSiqGc27hnw+H9ZDRnO41pf+PWitJSUFGeFoN2av
jhmfbyJiKIIigjFXI8q6KsoaiWpIiFnetsKqEovRNqGb6my2+gnFBhQ1zN6aBEnC/SJtt2Ss
E9c+2gfRFpNmF53vF808CFqT30t+mtOXdJaShqCrWIgmvxclBiqpb11eNkPVLdDOlWYeVV9A
qZckTYyKkqAmP7Ww7xFpMR9hmkagQ461JG66Osi+j1knaIw6JyE9MfFT7aumBXCDx8MSQ5R7
8zWB1o+VLJPyaWRWGi75Uc10JD9iQqgP6/n5NCzTR36lt8pLpCkqWp3fvtKfX7kqP9/DJnKQ
jAeSb/yl2NfrM2Z+1pdRDUVZw6pRZpjqjjubtV40tLrci6oJVZUb7+CV5ayrYBqlCg2bi6Qf
Z8JiD2sNdJFW7LikYaPKRJVwXBLM906/o0H92iyDetukmpD45KNiY5pl9Jkqn8ezqXJNFZ1b
ZLMl58Y13RwRhNMnUmQzj2mbsclHfCWKdUwYlBQ6mKBfQVlOe1F3nMqxfV+yfCha7UtISEt6
5upFQ8NbxDBWEuN4GqKkDLAGjvXytp6czgcFWRpU++jnYfO3N6V6ZxBVs6+tll6JuFVUmp9g
SfwDxjwOQ3Yb3xpP83halVAyG7qwxMZFKtaUuBrCGvFkTurS2Wltg8eoHqlJr8ScL21Wk23A
EHsFoQPFYbP+yGP7FkXnSxMfBgcVZ8sF5l4Apc7Wxrzy3oVQmsnIWMtEoVsvcir11usudqzA
h5c4VmDbHlhsWdabiXn06GtT9sKS1DqtkdZAXwollvWRikqXZNNchEK2IqwmrvbC/tyitsuc
4XZ+3hlu4HJnuG1XOMPhK53hzrvKGW7HF2BSEKtYE1AA1cX7sHY1LGxWIjJqE3pFSYLi2ogq
amiTIGtYhp68k/quGQUgXTsKIHIdLBttfWKe+851QzA/zdW2WnMYlqeyfWb2yOL9c5/yXJ9Z
PuxrDK/fX/7ADQ5Ae77oAHTllxyAbvoXmNsshPpQG9FUhsKUB/xi/TlftknYhNUoXWrrQwFR
6hZ76bLeJz37b8y+DHz3ZTeNnrr7Dl1S8RUnsIvfv9kR7OlbHMHevdUR7MPbRoeVHMLTvuoE
Fr77dkeB3vs1R4H69jlK3ur9jmCr/5XBrK7ZVtXOucMRLPfrjmDuf3MEgzsdwSbc5Qg26RuO
YFP/3REM/QdM7BJDCmoTpH5BvXv0xMYfeeu/CcWdQlxC9T5UQxzvgVlBJYoasaAO2puWe6Gw
TVD7UBcWw9+iNZV270GlV7C4Q4N75lX3QVGKef9IyL3ua8T/HIm5P/fdX397JGaP+6pXvsMR
q38XFqVF1KIQRZQ8wEWQAF783miI3zwIC9MQaTp+fzQRj/3XaIj3fzAa4o8PjYY4+DDMSilm
y9JHoKD5bLUXdej6D6G4X5Qx1lFfPCqoj8J866M9anMOPgYLLIHYfMJ+94rHH+fzH/4RzE0J
TNP3kx9zmL/5CYd58Ke8LNnv9r79BHi6mmo3+bvqUI2/pb7rZzDf9gwFzYeM9IC97utef5IT
jb3uZYNPcfgN7uY3DnD9L337ab78C57h+5/yLN//hc/xs+He5/n+L/o5n3/rL7j8Hd99gQ52
JUy3IAT6VEFGzarvl7DE4ieTDw3uFvFFfsD9L0FhI11xEIwo0ZdhbvJ3WkW/ducrMD/FtMvp
cQfrfzUye7/7pIJXuez817jsotdHZi93F5e8wWNPfOxNLvvJX3OFf/k3XHbXWyOzG9zT+t/m
+g78lsu+/XdczZ9+h8s+8C5X+Jb3uJrrv+f63vYHLnvHH7nCBw5yfW99n8ve/gGXfcaHXPbO
j7jsGz/mar7rEJd9wWEue/cnXPaFR7jsi45yNb/pGJd9y5+4peWXf+aGffGnXN8vHOeGjYEr
fI+Ly96bwxX+lVwu+2b3yOy97mV5E7hhX5rHFd6TzxU+o4DLnlnIZXuKuGFfPpHL/nwxN2JX
eLjsKydx2ddO5obtm8JlXzGVK/wL07i+z5/OZV8yg8v+wkxu2FefwPW9ZxaXffFsXoYu+cUc
ru9L53LZV83jan7NfK7vqxdw2dcu5Gp+aBGX/R3EFT60mOd7qXsJlz1hKZedt4zLzi/hsguW
czW/5kRuvI+VctnPlnHZL5zEZT+/gpff0wNebov843LeeG3edB+XPW8llz1jFZc9v4Kn+Yxr
K7nsK6u47KureWPFFXev5qqWs4Yr/Jq1vCzZccU6LvvK9Vz2VRu4YQ+dzGUPn8Jl33Aql339
Z7jJ4j4NZqfYtle3ZzbyBDe/4ee8NMyp4Va+ybUcvwvruH6n1HP8zmrIfH1Ngfe6h/Iaee+3
BHDCJphUvsL6rwmKOgVFUtDmgL+pGQqCYhRtist6C8zrjIiSGEN+NYzlFIOI+cn8VsitVXa1
wUQ2M1SjDEQFuR0mtmD6ebW+X5C1DlhgebIBoeTDr97XyefvOx0KOpuNsLvSVUkwIC9f/3kA
imuCTB3Im7jg4iDkdYnn9ml4M3hY2gTikiSSMLawpAihfkXTtjIbRUWm7S9q689r2jSi9vTC
hOj0R4zQjYT2UZs5bDIE4AChZwgdozbFXAD5hCoJnUKohtD0xTOOz7xg+gL29wT2d1Z2lwKY
ENZ6ZWWASHqrks22QOL3G65iq5GqJbUbdm4OdO0MNLX5O3Y2BTfvXL92VdXOpvpgQ21HW5uv
rqP2b4ivHMf/9fHHN/pjMTqxIWhY3aqKdENWpxTXoLUzWLEBYsbnYRgBlLyKcrfm1sElsGgH
NS3lgneKlIIw+5UwRJULOeAlPz91uSBlhGrkf86vM3Iedm2H7RaZ1vsdltDw/3w8/kftv/7q
oruonbdV/+D2X2nr9Yfn4e/C/utY7cX9pfZfj/8FV3kWW7Uridtfy/5rHaF6s9A2EtpEbbER
aibUQqiV2rtjtopovgF0EjqdUBe1p2babttMaAsrVwBnENpGiFb9HYR2EjqT0FmEzqb25ggJ
ZlkMmf0pJtRDqJdQhJBIiNaKPkK0ZETNPlcx+93zCKmEaBtBS22cUL9pn3MXudPavJvQ+YT+
idA/E/qs2Z+P238dD3/c/us/9vU3t//64NuHP/oLbcT+X7b/uo6DGbf/Om7/9X/b/ivbcCbI
g8ldZiFJUOnSe3PdqooiWIr5PJ6AKIewiqVBr4dexP+bCmrwmc0Dase64qntaAv4g6hV6KYr
5BRVxJqnNiKIdIWZF5m6oNKhgNhLjQ10qkoIa3Tj7XCZx1PcaKz19iG6+VvpoWaaqozd1GwX
t8UmDt4lanRXFlurLUkETBSmC6STy6CTdmfonkHiw9gInrYmWxtOGLehpo7oFuxsK7e1YS/C
/VhGorGMNhbvTmxuoDvRMN0CHMJ0Pw1V2IcCStIWUMKAgLGzji4nTm1ct+1MtwQ3TI36JK3u
sA1OWdUa9qFsxi1wwkqJZdVvwhzJkLn1J57Y+TPMllkPZewIGvZ5uqw7tbImi8WkVdpS99KQ
EKP798roYusIs6AiyOn2nkolZYAWNxKBMralJCLEYlhm65wDFntA61ApXXa9ztyGVuFD25Ir
ym3L9M019mvoVqykCS2vJe1t2z0tRrqyWp6y7Eqjfpm9LUueWgxvpXa5JQIzTR7occ2246gi
kQ/JFd5sR0QqGWk+GqvmvSgusz1w1KRXQrxmsVlmywhjRwldmp/NglbCfoaNF1PpNq0b2Jr6
iKKSAAmblju6i7IX010ZISWW3OVa4bPvVRR7WKoMCIbtrT6MY8RHwu6YlmZ4zNhLQmJSsY4a
XqM+w2zfoLHdVciwzFVKYk+LMEVSuw8aTpRvAq5YU+5FldWGuZDqVeXmBv6E3yjbvJjcR2Kz
ZWVYdTI2KNLNhhGB7vGSNTHMth5ZNhwmN3ORuCckGzYomLUhYYDqpiLVbP7NfZvGhpAx7D5c
40VD1au8qKqSRslo0CrWJGwS+BObQOqsm0A66SaQ8lq6CaQtuQkElbLNNmXDhgzWzCTbwJRB
ObYPme1XjFL/rImghuNsmo1i+spmCW3c9NW4FcJxK4TjVgj/d60Qsoph228ujG6ZcNwS4Xhz
/L9kiTB9l+u4JcJxS4R/x5YIDbt/43YIx+0QjtshHLdDOG6HcNwO4bgdwvTWddwO4bgdwnE7
hON2CP/R7BCKetIMofXzx9/IGuFQa+XwuD3CcXuE4/YIx+0RjtsjHLdH+Pdgj3D1uD3CcXuE
o9kjHDdH6MwcofFClFhXQr/tpWa82ODSVIcmY0QZoCC6WoXKo5OFpUZjJsohKU5HFGyezZto
MtjnMqOU06lp88OGfX7T50n2fuZ8jdk3iGpi+oh1D+0dwZFiE4zgQWO6OEt/b3zupWWEVSf7
52fjBYJ61TDtKdi3RsunV0VFsbgaigjGOykdhtNmrx+rg7Se0WlxWTff2ViaeZEmstEte3+N
DRpjaZZPrH/TkilHBCWrdipBRvZj9pQ95ktLohgmXvYlTfGanSXNKrv0xItOamECGw+Ejd6B
viawycvBZELbk6BHxXQkPyCzSpr2PXprfQ2Js46NfItZPj1nTCwmO/XNXa3J72SJFx6PXR1a
MhOfoK3LBxIybI1bqvw3BayJVWr5zTIuSqejdUUdtBWPxCy1UfKEPqwllhhS5WkWGK0UXcJl
fuFfXOZDnqDlI4tR/mzJZplToe/mkmS8qKip4V6i8NGEoLLlRMdnTIhi491aFJgaPVk+M5gJ
ay/URtuZWAmokEj30a+kqmXJYsYLifEdBxv1QY3LmuXzktnwxDWsXqclv0P5PJ7CwkLyZxGa
jjr9jfVoRvVMtMjjmY4amlrr2/1t9QjtPAm11Xc11jfQ9bdBNMO60XBm4XQU8G+pr/MH69HO
jWhJOFze1tZWPji4JMNfVUV5m6CWr19LPXV2NbUHmS/n3v5u1fJ45sDVrn856Wt7fPse9u+P
T/jX+IQ7mid8fULenYXWpcrj1/8nl6cV4BuE7iHU2QGwuwvgz0GA3M0AbYSObzE2s7kJPUQo
sg3gze0A7xP6wQ6ARWcCfI7QJYSmnQXwWUIPEnqMkP9sgFgIYIjQWxjg/h6ABwid0wuwtg/g
RkKPEHqU0E8INUcBbiX0FKEDMsAzhH5B6AYF4GZCvyc0MQZwmwqwj9C9hL5N6CFCLxA6TOgo
odkawE91IofQAULPEnqO0IuEXiL0MqFXCL1K6DVCrxN6g9CfCP2ZUGEcoIjQRELFhKoJrSb0
GUKnEdpIyE+oj5BEKE6on9AAoV2EBgkNERomdCuh2wh9ldDthH5K6Ik43fgAf8pKqb9H2V/6
L3l9AvDBQfoP4N2Mf5afBXFXnbFDJbdzKomH+UR+55zlgtwzcyFny4WQs/nCM6kuzxP6OaFf
EHqBUE4/8UeomJCH0GRCUwhNJeTtZ5v6jX8AR2D8+j925cRdqfJRvKkWoJ3QdkI7CJ1N6KuE
bid0F6EfEHqI0MOEHiF0hNBRQscITa4DWEaohNByQusJtRPqINRJCBO6kNBFhC4mdCmhywh9
ntDlhG4ldBuhrgaAAKGHNwEcBldukcdFbjAv1/WucUs65hiO7Pam4fgquC4qzqW3uz25rmeM
26tJXtG8Atdjxu1VRx7+erwfguvGpRk39/Ebl86ckHTMpzdzv9NEgNmuOa5vS/Ad1/cLIGf4
uFJ0+nK2lynlXgS51P0nsygndzpMyJ3tgvxpBDE53/X2Ate2BSNIaiT4gmlwwi4rdClN80cI
3dMEcC+h0maAMkLVhFYTWkNoLaF1hNoICYQ+T+hyQtcTerCFBNUKcJfZj3R0GP1I7HSA8043
+pPzCf0paPQrrWn9yg/MfkXcBnAuoTe2G/3Lf+2gTSRLpE8h17iZTzm2p//OrSD1xK5XaKbc
kfsKdTxqPL1kQN6CT+nTljzz6QWaYe+Sm8u4uektgaS8t1JP5HYQkv4mWJFU5s9dSV6eTYrb
KoUiH8xJ1V43wJSXXFMP5AAC8EycGnFN/9KnxdXHXXTnm1GQIuZGyv8crSUguOU0nRP9OCL0
WbM/33i20X+fFwJQCV1n9uO/DQP8jtDbmPwmdF+P0a+f3Wv06+v6ANYT+rLZv//Q7N+bokb/
HiB0DiGJUJzQ5whdQGgPoSsJfYnQTYRuMccCtxF6MgqJ9DhiT0f7jabVV9xJpGdE5BEj344Y
uXgkLRdz0mUmc+oIFHNkutJz+PZc8+kQuNa5X6C32XnsduuEFyyO9PZb25MDpD301HguWfO/
PwkmDB//mnt4YvG0+bO889leydkuSwlyAZQ9aY63njbHW9crxnjrPXO8NS8GMO08gDl0TEXo
J7p9bJUYPyXGPpPSxgv2FM+aqvaaYj69QCEP57xgxOoFo0qajiby+YQHdj1r3MynpzlP9tvf
/eWaQmgyy70Jrr9CrbflPzXTAb+ppPtdaW4VsX3AbnAvpjuDgfzNATei1gFykGHjBODsfCKD
+Ju/3PBp7KF1wT1sN+5Bl3VfM7X6QXcRLyG00rTSQa2fXMAOWAC4gdAXCT1J6ClCb5pDyqO0
JBNJSwktI7Se0BZCWwntIHQmobMIiUSX9wqIvEKCLQaonwTQPhkATSPKE3p2OglnBsD1hE49
AWBoNnkm9OEcgBlEsZmE6hFAD6EHFwM8QBStWgZQTai4FEAmpBD6EqEFJwE0EQoSOoeQRChG
SCf0VUK3E9q3AuAhL8Bb5QC3rAK4uYLcCd1eYaYV63USf+nIwRjgmL9zLL/ZgMIYSCRc6CBm
ZO5YXVKaGL2fUcXM5sT4y+qszWVChkueA4wnwyVTcnGGiyvThTZ8ib+0ZbS7jCz/YKLss/bD
hkxeU01jTKeZFspoMb6/ynhDpm9J9M1nHsyHU6gNGcI7yw2wdhZAQTkAHUXTkRTtTWmLSuvS
AlgIiwDBZ+A02Ah++LQxZTHeZgXLBcVWs205MKlLGWAfumsFVVPkXFhks8RgQ8Py6Zdf4oZF
NjebeNg7vXrqBJhUh+mu7AiqEdRurOZxhTZMH96ZD1NbhKiEtQgK+lAQDwiyWAA5NcFCmOdH
WwQpjsPIci5KXNOVKFaLYBmHS/3DY9Pvzp8IkxpUQe5DW0VJEoWoVjy6v/3Tv7HWA7PIrzS/
sHz6w6dPgmWEw1ONwh6f7AT2yN4pUHRS8poK0zrZHCX9IJyATYMcPTQd5mVyKANK3v/umhkw
LYhDEVmRlF4R76afm+LRmTCZmRqsZ989+kRZOwGmNgX9rZ1dHW0dwaaOdhToap0FhXU4iNvo
t+zZ4PLNgak+ixPszevbMTfTbee8TLffzs9wO7drARQzg/GdCl1+0bcQ8tuwGoqrg4vY2RYi
iU1EiHbT6X6Yb7LSOdAzsTq0mMuOLYF5W5Sw0EM3bW3WsJoMB/ZO3PDDpeCxcZfx0E+U8Lg/
W87jPnYij/t4KUytEdVekW6peLQPq1JcDpeBp0OSMKpXxT5NU+STwKMSAFZRhH4I0lbAYttz
Ghz2urdXeGGx3dEugmIuKof8WixJMtZ9MEEIR5TQSpjO7kkG7Hc9N3sVuOnenwooaBJkVKeI
vZUwnbqkHKDk43d+X5XN9XfV2VzfWZ3N9Y9rsrm+tzab6/vrsrkeXJ/F9V33hmyuXzs5m2vO
Kdnk3nNqNtd7P5NNwgWnZcN+e2M27C5/NtfLa8BDzXCUswUlyB+ohUmdiqZHBVlG9eqAKNdB
cY2iaRg9qunqoWg9LLM+ZilTsLfg3poGR7C6Rkew+k2OYA1No5TE/QUPbG8GZMfYYkfF/K5l
VMgfWkeFHGyDggGhW6SfcNqhxI7Orv/8Dme43k5nuEWng9u/atW6LphthzNXaCh4uTYA7irU
0hiESaxo5G6uqYKSI8O+zeBpE/v6FNQiyFjtF7bAbAawuwL+5IEDW0dkPX0GzGlX+kQBtRmr
lTojiow1hFDX8rptsIx5GxkBe47829ztcKJd9+nJ0staCth3aMZE6Cm4c9oOcLcGVwZ2jpYz
35p6Jh+yv+CBM84aFbLt7FEh289xlk8+wRmuodsZrjHkDHdyeNQoBLEDUfvdN+X38HrIqm/1
wswEOzVAZNb/CpsVum9TDmERZiV/21HnwqyE7xQcGor8z/dl5ewvWvKmBIUB5O/RsST0RWFh
8neGevsL3n9bZpaSra6FSkTG1ODPbsBHh89UYGHKIV3C3oL3gjGLj/MA1basXrW+YlN9dXUD
TGpWNByLoEAoEpcwNUX9yHoVPJ24r09ALUJMkDG1eWzxosOkxrgsCyrqGgzLWJLi4NkkyHIc
bfIRH6rYP4o67QOjxPj3u6AoIEYVGXWKfXgQJvslSdTIY62ikhDV3VDYJYb6UKOI1fNhSiCk
6DoNfCtdvKzI/wRz2JiPrndGdKCH2XrcRlWJx/4Zpgd0uqLVr4aF3kj5VkHSsfpZ8LQqkoCa
hZDSrWH5czCVmqUWUCvGqJlEhgR+AUuEioqK01dVV2+6EAo7VSWmaIKkXQQeZhK6VhVDERL+
xemJesmoSR7dMypkw95RISdfCtO3dLS2tPm7UKB2k7+robzFH9x+Gczxy1qvoKIarPayvnMg
JqDKdb5V6z4PS1NZkc0z7M+95w+XO0H9/gqYukmQNdSJWbfWLsSweiUsTvnMZEND/sWHroIT
muMRAfklobxViKuiJKCVqL2t8wujBnt/7j3PXu0E9cQ1vDJ3f8EzD13LrWVn/+HM63jF+uWC
p4JDowDah0fR4YnrYSItbahN6BUl6QaYY3myNzpfhMmG/6T59C+Bxx9cHkSdgiqEB2X8L5DX
gmXUonwZUIsqahGZmodAbXFVF6Gwgb4t1cTVXsAf3fTUjTAlHXKTBfOVUSX87GZqI52GlikJ
9nx022W3wGxrXEzVCOulL94KhUElihqxoA7eBpNqBFUdRB0ntgkRRR78KhS2Yg3VqCTit8PC
5O90HOw7Gqn6GkyrjQgqXbXSIOq7e+laufA+IsGH6nBtXFT3w5Lk72xY2Hf45K/9KxRH6WaD
AbqoM9R3hwkUMWoUVD0yIIg6/jrM7BLCdEtOrW0HwL+BL6t7NhlQ/8Gdl945Rg+X3QVzrdrZ
S8U3YKblZVpRqVk6Ku7foSSVctkhgD+e+95/sFJpscl/NyxJecym0r6Py3/0TQegH9/jAPTk
vQ5AT32LnjUQ6kNtRHP5PpiberCUFcAf1J9zP0zbhKnlO9TlQwFR6hZ7sfqfgDId7cn4bZsa
WdD173o+/g5MahNDEQFLqFES5NDgd6G4NqKKGqKtHJYfgBlmIbfJ/h6ckJKdqAYlH+8+9GB2
xvme78PCjCplE/lfMLVVUFWhG2PURrSMinrkB7AsrX1Iz1rYd+iDiodGh9UfeqnkYUewkx9x
BFv+Q0ew0kcdwU58zBFsw+OOYGU/cgSr+LEjWOVPHMGqfuoItuIJR7DynzmC+Z50BFv5lCNY
9QFHsDVPO4KtfcYRbOOzjmDrnxsdhg+9ufR5R9Ie+7kj2M9/4Qh25AVHMOGXTmAvr3rREazs
JUewFS87gp30iiOY61eOcuHjVx3BDr3mCPbJ6450O+8NR7kQehMmtviafcg4teXXUNSldKMW
BctY/g1M6qK9gRpGW3yoVtn1Fiy1O2RILDmE574Ni1KNfvqIDuoPI/RbmJVC2Jr930FRs4JR
HQ7FRfUdmO6XdToSosHVqyFFEmTlXViWgmRFwJ73n3nxPZixSWGG4lqJqnGZru2PCNHfQ1FQ
6R5E7eIuRf4DTGrBIVFALT6iTDyE/whl2Tylw6D+/Ue+fNAx9ocfvw9LswzMLFGFko/rv/WB
E9Q1HzpBffMj8LQJuh4RBQJT8eDHsDBtcJkaQcKEw633HYKlaYBseXsYJtbRt9QaVZDD+icw
x/Jkz8kjUNxGx3Q18VCfhAePOtH6yWNOUP/+Jyeop/48KgofPcPzKeT09ByHKe2KMSAStGhc
0zCJw5wMJ4KEksPHrnbBVKNUN/pQqzDAlpjn0A8f1G2rouhYzoVJ7QKzT9uJhZAS6nPDYruD
HQ/4cKh/wqiYcE7e6JiJ+TCpRhWIE91zrElYLaCjS1lBNYLcpxWCx/DRjNgkQxEU0bOl2hRN
F8ITYXbqwZ6hxTDP5s/O9UBBfdg4TGoSLLIHbw0d9hzue3UyeAMRLAm9EbpdE9UKkiSQKGVJ
Vij55BuNU+DELDmZlsBQf+zkJ6Y6RT41zSnyyekwsdVX7wvoQoygZ8BSSwnK9rqFjw0enAke
tslYQB3UhjQ+AebZnu1pNwvmWd8jLQP+vNyHL50NU4yK6U9WzTmwON3JVrD3ffT1A3OhLAOT
Td2STzZcMA9y69oD82GGRQZ1gZJjryxaACemNQwjiVnoMMj6Y/pLi5xjP0GOsXFY7Bx71hLn
2G1LnWO3L3OO3VHiHLtzuXPsmSc6x7pLHWO1rjLn2J0nOdeheIVz7Ayvcx2uLHcud47POXbB
SufYhaucY+dWQEkGNn1aCB87v7bSUa2kbVGVM4l11c5wNaudp/65a5xj+9Y6T6WidbAoTbP0
fn29c2lLNzjHLjnZObb+FOfYplMTqZ9EZrT6sOfYg52fyTqjsv98z2kw2R/XI4rKrOLQtQgb
YUmai31IBntz6tv9DkDfrHEAGq51ALqnzgEoWO8A9JUGB6CbG2GJzS09iWBv7ikNm6COt2zH
QfrA8twzn22CCp6YjKCJn+eax+inJ/fcQy2wIlUCuAuO6h+/o6HVgf472mBRxmSbfYjSDkVN
/XQwjHEYd8D81ANMrKGb7BviuipIsOftk1s6bU6nQ56/Ltjlb+8ClNI7s3Dvz9l0MGAr3IY3
wIfPcQV5s+R7Dvf9ajMsTr3O7KjMOgu+he4MmDfiC4un6IxRX4H2Hal9fBssdfBevR2Wp6EW
r1qVbTptB5SMLm5e94qdGQLTcSQAOoF05qhAwIf8uGrpWRkht2TT8LGzoTTLrHXWF/tzRuiV
7F7x4ZPqBafIhm4nufJoCNBoX0HCUMS+77TG6ekgvBKFj5w72APzUwB7lXks9zs/7oUpiVeY
xOtLBLyZ7y8zsr7o4KPD88XsvHOhNl3wmOS6YN/Rl/L6/kIp86Hk6AP3S2PyMyE6FvjQE2PS
aOhnCpRlRCnLC+O+o7eGPbExif7kvDHBD6tjgr+mjQn+K31M8FfjY4K/3j8m+K8HxlQCcnaN
ragOjkmZ3+0ek/S888cEL/ynMcGL/3lM8MmfHRN80ufGBJ97AZQ6qxuvvHchlGYyMtoyCt16
kVOpt153sWMFPrzEsQLb9sBiy7A+E/Po0dem7M38vJr5DnQplGT/QGz54r8/t6jtMme4nZ93
hhu43Blu2xXOcPhKZ7jzrnKG2/EFmBTEKtYEFEB18T6sXQ0LrVNRto+/0JN3Ut81owCka0cB
RK4b/btEnvvOdUMwP83VNlobhuWjf/3fP/cpz/WjfX6/fn/5Azc4AO35ogPQlV9yALrpX0b8
wP9i/TlfHvVD/ZOe/Tdmfw3cfdlNTr6RX1LxFSewi9+/2RHs6Vscwd691RHsw9tGh5UcwtO+
6gQWvvt2R4He+zVHgfr2OUre6v2OYKv/lcGsrtlG1XPucATL/bojmPvfHMHgTkewCXc5gk36
hiPY1H93BEP/ARO7xJCC2gSpX1DvdvDZ9CNv/TehmK1orPexJYP3wKzkCi1703IvFLKdNF1Y
DH+L1lRqlyyo9AoWd2hwz7zqPvphI8G8fyTkXvc14n+OxNyf++6vvz0Ss8d91Svf4YjVvwuL
0iJqUYgiSh7gIkgAL35vNMRvHmSLCK2INB2/P5qIx/5rNMT7PxgN8ceHRkMcfBhmpRSzZekj
UNB8ttqLOnT9h1DcL8oY66gvHhXUR2G+9dEetTkHH4MFlkBsPmG/e8Xjj/P5D/8I5qYEpun7
yY85zN/8hMM8+FNelux3e99+AjxdTXS1aB2q8bfUd/0M5tueoaD5kJEesNd93etPcqKx171s
8CkOv8Hd/MYBrv+lbz/Nl3/BM3z/U57l+7/wOX423Ps83/9FP+fzb/0Fl7/juy/Qwa6E6RRE
oE8VZNSs+n4JSyx+MvnQ4G4RX+QH3P8SFDYK6iAKRpToyzA3+Tutol+78xWYn2La5fS4g/W/
Gpm9331Swatcdv5rXHbR6yOzl7uLS97gsSc+9iaX/eSvucK//Bsuu+utkdkN7mn9b3N9B37L
Zd/+O67mT7/DZR94lyt8y3tczfXfc31v+wOXveOPXOEDB7m+t77PZW//gMs+40Mue+dHXPaN
H3M133WIy77gMJe9+xMu+8IjXPZFR7ma33SMy77lT9zS8ss/c8O++FOu7xeOc8PGwBW+x8Vl
783hCv9KLpd9s3tk9l73srwJ3LAvzeMK78nnCp9RwGXPLOSyPUXcsC+fyGV/vpgbsSs8XPaV
k7jsaydzw/ZN4bKvmMoV/oVpXN/nT+eyL5nBZX9hJjfsq0/g+t4zi8u+eDYvQ5f8Yg7X96Vz
ueyr5nE1v2Y+1/fVC7jsaxdyNT+0iMv+DuIKH1rM873UvYTLnrCUy85bxmXnl3DZBcu5ml9z
Ijfex0q57GfLuOwXTuKyn1/By+/pAS+3Rf5xOW+8Nm+6j8uet5LLnrGKy55fwdN8xrWVXPaV
VVz21dW8seKKu1dzVctZwxV+zVpeluy4Yh2XfeV6LvuqDdywh07msodP4bJvOJXLvv4z3GRx
nwazU2zbq9szG3mCm9/wc14a5tRwK9/kWo7fhXVcv1PqOX5nNWS+vqbAe91DeY2891sCOGET
TCpfYf3XBEWdgiIpaHPA39QMBXQV66a4rLfAPJsJmiSDiPnJ/FbIrVV2tcFENjNUowxEBbkd
JrZgeiwEW8zaQfcAJp9sQCj58Kv3dfL5+06Hgs5mI+yudFUSDMjL138egOKaIFMH8iYuuDgI
ecaK/M3gYWkTiEuSSMLYwpIihPoVTdvKbGIVscW5hqUhL6H1hE4mFCZEpz9ihG4ktM+0RPQI
oQOEnmEmV5n5L8gnVEnoFNNK0fTFM47PvGD6Avb3BPZ3VnaXApgQ1nplhdrfeovZ7TJscdHf
b7hsJoOW1G7YuTnQtTPQ1Obv2NkU3Lxz/dpVVTtNu9Rt1C713xG+chw/Ov74Rn8sRic2BA2r
W1WRboLulOIatHYGKzZAzDjWAkYAJa+i3K25dXAJLNpBTb654J0ipSDMfhl26KhlrBzwkp+f
ulyQMjQ58j/n1xk5D7u2w3aLTOv9Dkto+P+beLgucMGTK4FRIbWbdwH9RZE/XUnN7ZnhxsnD
IKFLCV1J6HpCd600QNTDeysNG3RfI/QfhO4mdC+hbxG6j1BzJUALoTcJ/brStFVX6K1lahTe
phr3feb9XvP+bfP+kHl/wbwfNu9H2R0KZxsJX0htRlL3A+b9JfP+sm7wXzXvr5nur5vP1LY2
vQ+Yd2pfkt6nsPs2mHnCNS6AIDuWpB0PoC6FNurFxDUHAoPRbkWCicspxK+KggRTV9PftUpc
FaklADwAM5cQlwmbsNQP9A+mh9VByRJwg6vgytkAB3LAtK/4rWPTlwf+NH35RkIFcDVxyc8H
mFJKzSrOAPr34imbASzGFlMliqia8znyN8BOqsASth37ggLmsQ/ibvOZneRQGMRR+p1UHUR1
icPrzKu8HpVu7URVKyvWlEGaTTm7BbjkdeCpqa/d9s25r6dcXt6H4dQfFLqBqI/BcuUCfFgN
8IfnIeOipYheG3mlvgZY9UneLzHdOXeagHmXGo/byfNdOaln653i5l5qWJZcQ+7VFv7Dz9ES
ARB5ynim94vI/R3zOdu9gNw/eMromz81n3/7NLO4Ce+YtkOt9xJyn/wMwI/I/Rfm/ZZnARZS
i5fPAwTJXSF3mtkPPmv02xmXGe+8AylbmQvATcJO1zD9SvhI3B98Nk1SWsqOJOfcS0lsGzPl
pd8z5KQ9//bp7PJnENxccvddYox2RisBifAS8ujzGy5rCv0trlpJUPu07rja66XWWkIRVFXh
RRXr1681zszckG+e7NOIKtbk5wcV4lAfbKBmNtj5ZlsVasLPtO/Cjithx7aVb2EHPgXpcXUx
emSfDZefX2scJrshPyBG31RQg8+oqVSskk+u2ogg0vUEXiPgpPdOQdUHURUqHQqIvbIgoU5V
CWGNHrIzXEb9dbQF/EHUKlBbj7qiiljLD2JpA1pRUV61qqK8unJdefVqGpP8ysqqVauo4QdN
0FGdKvbj/AZhlw25vnLdWirUmkZ1qHLVurUV+fVRQSRyNdrObAzpYV+ISaI34mVzwE/+euqw
oKI21WfYidmtirKMvR5PBz0hNSJIPYkjbxLRpc9meuvx8KCZqhVrvExIp8/voxHu1nR6Zmn6
0ZzdUdE8sjt5wq5xDg07r7GXNq3mmZbGkaCp45j6RXqOXFewk0rvEc0Dc1hGsiw1MrNWkc1j
ajTjOLo2USaxlyhDVxXJS4/p6ReVuGacUtPVUIsq1q1f5TPzMIwFKeEzdTZhYFDTcdQ46cY8
E1NLnKTahISoLW0cFQOveaQfO9BWiymyJlrPAEocOk7C67eeSqal9T/mGZQipsfHmv0M6sYh
IYqRMEDPCTLTjx43yxLZfE7Em6YBPSzQqFa0SqEoNqwhkejJaMCMTPKoROPcUetJSsYpeQmN
0k9eTp36lDw+XVckqTxxQrD17FQvShwRKVoOxEueTt1EDxUS6UFLLB3Z0a+2Y+OME4iNk8gy
Y8pSI66XKz3ltGR5aSD0SCcxFGenEEaSfumZZqqRUxb9qyoTEUg/nZGeY11BxQ0qcTV5fm1Z
luOyiAr0TERZSZ0nrWQ7ay9RPOhBa90sE1ncRFmnC8x0o+iv3EKzNVnclX6sIiGZHTiMZKP9
S9djAKMeLOlIiMVUJaaKtJpRHQQTlUg5luysDNJfVb6KlH6aD3k8m5QB3E9zTTCqtEZLHa0y
XpoQKELnHGLxbknUIkQZQTardBgRT5olnK6G2kR8m1BcDhMuLea0bsjKAPHFoptoJnwoGGG1
xmgQErJEOSTFw1hDApLj1F4SlR5TRFrmjaodopWMCCeeBhRVjxjqiHKvF0WMmBiJbHoKCbQB
RFimNrtw2OfxBFjxiuGQ2COGUs2W0ZJ5WULFJCxoNHmxhHpUzBq9kNGNIOo5wppDmjoyZmky
iHriKi0YKCQJKhVsVB0S4QiWYjRUEjOitDTo9dAr0RchS2fkydKjeFK9U6JdyNoQeTzFdDOt
Kkg+5PGzWlOxfn2V12jya5uCQVpaJUXuJTriXaKma0ZUBUkiYKKwSCQy87pGMTQLNG0FiI8h
Q0QXNpIrbNguGk6kBM3fboyGkpXdhvIi3I9lJJrtDC1KZvKwriGm4hCmWU4V9qGAQqugpRpr
ZgtNk5spSHUzFFpJAkwLjoRG7c6aiqlYCGdXa9iHPJ1GNssKqzlm8TcbjUSppiGwEqyjoU5q
vxeF46g9Ef/ueMqZvhGZ7j5PVyIlqbJZkyWhYjdO46DSkBATdUEqQ6rAyhTbfq2mgSRlgBY3
EoEyLxI0FBFiMUzEisbrDMVU+1b71qFSWu3Xlfk8Htq++dC2RKUWkIwHko0l+U+Ba2gzkGwj
vZa0TzZ1NKWSDXqFkTqJoiWy7iKE6TZ3s1mhfvtwTLc1zYmmlvVFZktr8ROX2ViDNvoJLtEl
ezoaTQ7tFjLVyHSOqaKsoxvoTy2iqLqXsmmJoQ1FL9aRgEJKbJBmP4ueDzXR7kruM+It9vy/
9r4EPooi+/9NMrkzISHcCdAkJHIkAyHh9mCSTEJOYjKAXEIz08m0M+mOPTMJwd/ugkhU1PUA
j3U9ECTerqLiweoqKKyuAt6siqh4Awoo4ZT8X3X3HD2Z9HR+f/2sv/2kk+/UVL1vva6prq56
3VWvW/w9LTQqcfOUg2GaMMdS2upooQWbi3QnTbSbXcqKo6I43HpHLqkmbLzYlqR+g1TDpNz8
Cb5qGeXhnKTxEWY9LzAuxtsykZw3KTeHmlCQK563BeNz5WHMm7eRbbC7SXOibTZp7BVPYI/b
IzBkEPN23GTgsNO2wI5UtOkaGsiQtJQh+yUcF90ijYTePtrNLHNTrGua1JDIcZd70aCRPrCZ
ik0qh1pbMD6Hyp9Aii91O3mTfKOwjW5ys80MVczWi+eMm/RENR6ni8kt4m0MVcXbPE650YtD
9uh1kg6xM/D1VP5xnW9iBHFEoBpJfvFEZl1BJRMrhG1scjKkcdHBA+akALsA89LNNOukiWlH
u0RrI6B7IBY0X+8WzTQLzzupSnapeBOhXuAbfX1IHe30iHaAt+nQNtIAvAdPPMvkM4yU3M63
EBJpkERDnaWSGiWbmt4RstQ4OS8vx1vDJJgg1UtpXRVVW2POrbTUjFYUwmiQLQCJPlWio5AV
KPJo4mVk3BUYqnqWJdSPtFSSQZtpFTk0J5oxDQLtVHCJGUx+UzMT1GNJZjfJ6mIwA+1mnK0B
9UpsgyaPYLXTLka2DUi9E8OglRwnXnCTirOxLjfLiXWWQ7lYsYMlIxzf1CqI7V88W6zEiHL5
ag4V2byNy18h1m7zFIl2rFgkn8kkm09TjZTJ6eJzKCdrZTjRtFRql/MoDC6jQbTcfuns7CT3
R1bJF+KrEW0IcjvlGsS1iDWI6xDXI8itn87e7b9m81nupHeXR38X3eo3PbxGqaI38vdDZXWB
rXNUwHfxTGkk15RuXmhVnI/eS03pVKcdjMtrcJFzR7zYEK0yMizKffyI0UbKYCGDQbN4X1Tq
FJSnasCFhYtqYZxOEgacMDm+s52MdkQ3Z5MGGjdRLJ1/jU1OlhaLUS/2J8reWO7Xlb1Ijmhy
ee0inmqkHQzl8ggBBpzPiPXWDtkRSxygxEHDw5FRWkC1bunegXiXwsUIt7ioJiftJhav0WCI
i4vDj+FUKlVjKjVT/fL7U8MNhlSqpKzSXG2qMlPUwjFUlbm21Fwyq7bKZKH6BU4B9Y9LpepM
c8zFJouZWjiDyrDZcquqqnJbWzO65MvPy62ihdypk0mmmtqyaouYS3u2322xDIbBcKPuL2Pu
X23ctM3U7ol6wBP1YHnUQ1HRj8SFuD8ubdMhEs51xkF0QFrgjX1Ilu4Wk/i5zs5Ob3Ln734j
9/nTERkII2IcIh/RjGhBrEDcirgNcTviPsSziDcRbyF2IXYjTiJOIU4TXXqATMRIxGzEHMRc
xELEIsRLUQDvIs6LBrg/DqA0HmWIRYhLEYsRDYhPEwA+R6xMBGhDvJEE8HMKgKsfQCtiO8Iz
AKAZsXyA9DaeTwcBLBgCwCKmpAHcng5wAnEWsWYoQAdi4jCACxHPI77NAEjIxP1mAWRnA4xF
7EE8MAbTxwLkIyYipiFeyAFIzgW4CDHDCFCIKEXEjAPog3gsH+BJxGbEM/nS24PgFzhD/k+d
OX4KfiKf/v8fv/9RBHwLP3UL/+fX4ue38CXAp2LrSvDoivXkS00KRFyqg8hFkRAxeyXEzllJ
g946ACBaDiPmrISY2Svnr1wUgSwEJupJfC4p498RLyJeQvwD8QpiO+JVxKeI/YiDiEOIw4gf
EAMKAAYiKMQIRAYiE1GFqEbMRVyCmI9YgPAgmhFXIlYhrkKsRjyGeBzxLOI5xPOIFxBfIr4i
80+IHxHHCqT5qKSJAGRekrxxqRoxH7EAsRixAbER8SjiFcQ2xHbEW4gDiJOIU4jTiDOIkcUA
WYhsRDViFqIGsRJxJWIV4hrEtYjvzQCdiLoSgD1lAK5ylCGuRaxBXIdYi4ivlN4Y9csJ/INj
Gv7gyBE4DAfJ/3cHv/oODpBP///+j/aLgL1wAKCnxxciPDqI9bYTRYuJRMBscv6naegD1gX1
A4Hn/oGg89+gV/YBU4P6gQUBfQF5i9ZJqbM8Ks//eAMdpEXqPpECX2KElCgG78mTmt5A94Qh
UrddCvyJ8WmxumelwJ94ZSKhhM7w68megYCNjA0JAIN0g3XPOeF53UuxELGuk4+/OFucefSn
x0MkSX9jIJFEpkJU5CAdxPRFRp8Y3TdDdfOGdqOpFPmxfWHAMgU1ui8E5EM9URH+OEXq343w
ILKjpT75tliA2xFtcQBXI84ifkHExgPEIeIRCYhExAjExIC+m0XcnABwCLEiUeq7X0+S+u7v
kwEOJkt9+HGE0E/qy7cF9eWTBkp9+Tmp4s6RN7VF6s6Rl7f1j/LGIEYK5FikIhahiP1vglh/
TNz2eQNMPA37pJfleQtIYk1Syb6GvaRk5HTVSYH4KjrfT4khFJkpBkfAly8qkEl0fqA7F/yW
Oj1A8se6lD0RQAEYElLsutQ7ziUWdOrIrLVkkkgrFQCehTAb8rJJPe8fBPAZYv4QaeycnOYf
O+9AdMhj6HPymPldBsD3iPhMaexcMhKARizOwu+IrGxpLN0tj6UPjgF4CBE/VhpTC+Qx9fkc
aUzdjtiD+ATxFeJHxBHEccTZHOkNe2ekFw2eAvmZpXpSLaek2jlF6urFCDl2RqpHH1MXzLxb
72MaumWekY7bGekoyjEfMyJY5wc6X75EFZ26QBnJtzFSlnVILzHEYFC0GJDXG/oTSfCtNyZu
SqZvM/j6hZeSIGpd5/36dQmJfdMH5qSLFuogaZmRrxWNJnWbiOiTK9k2KYgLZRvHJNs40eMk
G2cR4lJ5hdGq8QBn8gAemwDwaL7S9tkm2w/z5PH/COJowBheKo/fv0hF/kX6XT9KwWEp8bBU
LXLwrVT/XplU44GUI0EZdkpvehSDByN3SqernChredW7I2ndiCL2skpMGTwn9RJPSgGE2FT7
X9AlI/qIxyZK9yuc0/7+QaelNQxLgn64Fx1UQB8x/zCAGUc7IzCMFh+r6yQaISoyGhZFAE3W
CQVvGWCacazzPgwHFDP1tMfpFt8C0iDQTXaqhOfcAVwKhs/QwTEMo2cytI084wz32ycWIj5L
fnmELoIwKGRE6JBRQh6USxjJCsYgGD1jA6ToBpE1vA0MVS1OyRHt2XCO10GGLhv0RDskQV+I
EvPmx3wzVAfRQMfFWgfAJJE3QTcJYsq4et7GWwH6QypyY3SxupQ1UanNp/tEgW5NFFl0t0gv
Z+tdK9K7VqR3rUjvWpGy3rUivWtF/lvWisB/ZN16TQT8KuvW30bsQ8RNAEhAJCL6IJIRfREz
EIWIIkQJohRRNsG/3t2OcCPWIzYgNiLaEQ8gHkJ8iPg34iPEPsSniM9+83Xy5E3jgevkc5u1
rJPXxRllXpxHCqfJ8XQ5fr4cp+T4Rc3SHeqezv+RZe9k3pDc6b4Zv9+CWCs+6gvgVsRt4ivi
pPXUf0HcKfs13YW4G3EPWS+NWI+4D7EBsZGsK5d9n9oRD8hN6iHEw4hHEI+KLxkDeBzxN8QT
iCcRm8VnAQE8jSC3XLbIhvJziOcRLyC2im+/AngR8ZL42irJrn9Ftv23y1cEryF2IHaCtK77
dcQbxIr/L533JO3gQrk9mOT2USfHi+T4XDleIsc9nlB+Gbq4mbJ8vRy3yPGn5PgcOf6sHJ8n
x9+X4wvk+PdyfJEc/0GOL2mW9pfY/LvwA5l9VvIFifu/7Afi9/8YGdL/oyPERe3v2f/jjQid
6P9BnZXiJCT92wY5Hiok/h4Pn5X6qy1yfP05aUZvg3w/LjAk/h87z0n9w42dUjgXdKL/B7kJ
YCGelRiSg+zB9NnyaBfK/+OlsxDk/xFcwuDNm8MbeuRm5dMUVLPd6SH+H1vcXfUFh130BMXX
nwutv6f+Hy8F6SNx4v/hr6Fe/4/ea/rea/rea/rea/rea/rea/pe/49e/49e/49e/49e/49e
/4//vf8HMRF5j2BlXEaqjrRzTCJ9j2uaoYxUrPcMY2yUSxa7xRss8qFc20iTb8wy9zqpUdBc
z0pJHDhqGMFON0ktrNcd5TdyR+neteR34Y7S1aBt9VW0sgpE48fGt3BOnrYpDl6uhZprLqRc
LDHBRZtJbljKJfjyyekzt2bXVnqHU9rGXO6h3YzsHdPrHfF/2DuioNc74tf1jjAUBJYsPw9z
TZ0sB91LVBT2bv/xjaxVfwyxGVEzC2B5LcAvFoDI2QBViM454s1t0CNeQdjnARyYD3AU8fIC
gOGLAP6EuArR91KAPyJeROxAmBYDNFkB1iK+ZgC21ANsRSxpAJjsAPgrYjviNcQbiPJGgPWI
3Yg9HMA7iA8Rt/EA9yAOIxKaAMg8K5ljJfOrZG6VzKuSOVUyn0rmUsk86r/cqAdB5lDfRbyH
+AhBnjlG5lH3Icg8KplDJfOnXyDOIn5BkPnTeA9ZLQ+QiChATESQebKLEDMQJoQD4USQ+TAy
F0bmwZYhWhFrEesQZC7sPsQGxEbEvxBvesSlwGdDwv95Wvw8BwH3108CHDtC/gAOdvkL+Opf
8U9W+Yf0E5mzkvgSLCJlIfNvHyA+ROxFRDRjPgSZZzMgyDwbmWNLQZC5aTIfTeaayfwymVMm
88hk7pDMF5I5QjIPSOb+yHwfmeMj83pkLo/M3y1F/KFZfKCl9EcWyZ5QtslTPW7FvZu2jbQG
hUfI0HB+NC8H+dIE+s/0KVb60EwN8qNhgnxprg7wp1mDWI+4D1FbIvnVbJsJcAJ0kfEG3QnJ
7eOgFPgSI6REMTggJe6XHC/2Sx4X70jBfp+MuH3skIL9mjL8erJXpTXBQYHkxeBLjJGXDf+H
vEMySZ1vR2wuA3gKMaocYDSiADERMQkxGTEFUYWgA3yebkW8WIG7qgR4VB5HZs2SxpGmiwEu
v1gaT65AnLVI40pl0LjysjyusPMALkN8MV8aX/6xwO/48ds7d0jLxIOdOyQnDRKbE63u3CG7
c2hw7vDr9Dl37JVcG3z59IFaJNeG387/g9SzdxynEH+Ux/MZi6Xx+3IrgIC4RR7Hv7UBfIf4
hsHviGfqpXF9cYM0rk9xAExF3CmP76/K43tZozS+1yGWIJwID+JPiBWI1YjrEXcg7kLcK9sC
9yF2NYK3Pk4p61EZSM4dPqahW+YprzuH7I+hPIoRwTp9R+qU5NzRjU5d8BHeGHmu584dWpnK
vffA/0PhITB6l2xvvS3bW7fykr11SLa30poA+l4OMJjYVIg33Erbyms/eW2fpCB7gdgKyloP
WbPKs0WO7ZX8NWTvlr3SaSknysz3vRnE7V2vl5W4va0SCxn8Pjdd8m/oITKIpJBVjHGiZRYj
rnHTQ/SITtQdgZ8REE11dkZCBEXSybY4BnUMBEjPltc/is8114mr8CLgiE5cOuRb0yKt0slA
jEPky88cXyGvFrxNXim4C0EeJ3pAtv5Ok5aMmjIRIxFTEXMQcxELEIsQlyLYGIBDsagvDrmJ
AOYkgOo+AFRfgBGId1NxP/0AbkVcMABg7SCMI34aDNAvHaA/wkwB1CNeHAGwNQMgfyRAASJx
FACH4BF3IIaOAShDWBBLEE5EE8KN2IDYiNg0FuCVHICvcwHuHQ9wTx6GedIaVrGuJC8h+ZNY
DpKBI3+PCPguGhSSIeFNIUZM99KepvhLIo1+0ukldyfSp3i+KlKiuqREa+AYuqR01ZzYJUXX
NYV0fN5P0e1NkdK9/iNAfp0nSuo7FEzfliKvOL1IB1Cok1bAEe94coVMrpLIVUsapMP5cIEo
I56zxHuSeNARK5pYUmQ0JT0q6fWGwjAYDhRcCBfBDDDBFnfMbM7B8S1c0Bo9HSTW2Fkn20SZ
BBvDRUBSLd/iJHe+imjBxXORMFyxik/BhuzUNVfpYbgiTbnqry21ICUKkooZMoNrpwppYSkj
RKsqLUldtzAGUiroRifjslMWI2VhWmiOjYWIQkscpJmoObTTw9ioKtYq8C6+3k0VeVxuvpER
4mGkipTkhx2pT8QkQFKJQHMOai7rdLJ0oysxfL721McmG2AgfgvKC9mp2y5OgpEoUSsaoe3s
o4W2vS0Z4sf4thToWyPeoyTzUl5aX4hwW1MhrauECCDr6AuT+kFfC2O1c7yTb2CZ5QznFjyN
/aFPFS04KLM47+FgOdcASCmzmCpramdVzbKUzaqm6morB0JcMWNhqvilrHMQ6IyDIcUYkARt
0Y4FQ7qmLUzrmvZtepe0y2qHQmIx7WSoGp5MFDuGQUwVI1g9QutwSCqmm1kbWXdE1jq4KEiX
RcESqE8osI5QFTdlQNoc3kbXk9nM2S5G8O0H2hKmvZoJBoV0pBr7zSw16VvZatId56lJd46C
lEJWaGDdbpp6zcEITg9nGw2GWU4nQ5kF1uFy8dwYMAhIYATKTiaCXGNhhCIeRIc2/fy8HBih
TFSqIJwrcyGmiHE6OcZthCjaZuet4yBVDH0CaNe9N2g86M2WurI8iC2jOaqYZxsmQCpJ8SdA
1vHvD+eHSv2uIFTq9xNDpf44KVTqocmhUo9OCZV6ZGqI1IP6aaFS758eKjXi/FB6N18QKvWp
C0NpWHFRKO5zM0Jxl5lCpa4pBANZnp3bSM4aylRXBEk1vMvdSHMcZRZaWK4YEgt5l4uhXnO5
hY5GM4wMjIZoU9AW+1RhiSZacakmmnmmJlpJWZiW2B67dX45UEqO4tcRNd9VhKX8UBmWcqQK
YlvopSyZwqmGLCU7dPnTZ2njNdRo4w2/GPSm8eOn1MIgJV1MhZLYT4rqQJ9PVZRaIElsGpGz
C/Mh69Q642wwVLEOB09V0BwjNNNzYJBIUKYCc3Lrnrndit6+BAZX8w6WpsQumaFq7DzHuCiK
qs0ungcjxWzdM2D1qYeHzIfzlGVP9bVesaeATR39EqA+9pG+C0BfaRlXtzDckXk6ZZE6pT12
6yWXhqXMWxyWMn+JtuNkpLXxSpZq45VatfGm28L+BAujQVW7/q6YerURMv/pBujvFfsNRNzs
EFfO0xxVxlkZFgb6vitZl8FAb24/HUriTe87Qkra4zMOOCGujjLVuxkn7WiEYb7vXYrXHnv0
Gw6GBaXG8XaOIYsDlwNzet0iHob5E4I1tMUesjQF5LgcqKKKieOn5s00FxSUQFI572Ka7NLy
cEaAev32qQIYahiHg6Yq6CaaYzgXJARkcUNSqYfjaIGqbbVxjNPpAcNMmuM81Ewj5hDY5jDF
qW4J84sPL4P4OraR56ga1sG0Qh+T08m6MFrEC7hHYTnE1bJWB1XKMsIVkFxn5d1usvO5LOdy
89z/wGDR5mOttJMsfXZIK57Flex/gNQ6N9PMECubbrDnzqWdbkb4IxgqeSdNldNWfqmL4f4E
KZUsZ6OpSoahynk7hztfIVZCXl7exeMLCmauhLgagW/iXbTTdSUYamiPkyoia0lx/6uCK/Wq
sFXeuDosZVpbWMr0qyF1zqzKiipTLVVXNNNUW5JbYbLMvwYGmzhXAy1QhYzQII6dLU00NWGK
cfyUayHTfyhCZYb2yM0/rNHCOnwdpMykORdVw4jDWjXdxAjXwwh/zq5iKIlZ1XEDDCj32GnK
5KRzK2mPwDppahxVXVXz57C73RK5+d0btbDevEmtzW2JfeeVm1XPssU/LLpFrVl/ErvbsjYM
oXpdmDK8eSskkNZGVdENrNN5GwwOiCk7nduhj5SftFPM32C/AwwmS7ZFfPKHrZVj/gLRFQxH
VfB3AlUhsC47R1OlRqrKI7hZiCshV0uFHqEBmJ/v2v1XSA6m3BXAuTushrfugaHS3rpqgtU/
33fNvTAo8LfIRUPRx7evhzgL30iVMrTQeh8kFdKC0ErNOq+KtvNc6waIq2RcVKHAt3AbYZjv
ezAPNp22598PfYvstEBWrZSw7uUNZK2cbRNqMFLFTJGHFdohw/c9FBc2nZh+/wOQ2EhWmbaw
nIuxOh6UiSxDldKC295Cs27mIehfS9tYl5147/g9B10PgzFkeigdYD72yNWP9DDDNY/CkMDS
KVvFY9A/4GKaF4i7IlH3OGT5ay40BZjjQw79TWyVjL9RPQEZ/oyhirTpeO4/n9RAen2zBtKu
pzSQdj8N8eW01UFV8QLNPQND/JGAtgLMMfOSLdB3JiM67tQaqTrWuZRtYIRngeqaqKzG5xTF
CME2HzQcfx6SqlirnWacVKmT5qytL0BikV1gXRTp5RhuK/STG7lC999hgF+39zTIOr6848XQ
gisML8GwLqeUQuU/IKWSFgR6KcNQVUaqrpF121+GkUH9Q/ChhU0dx/JeCU8zd3yctU0Tbfp2
TbTsVzXRRr2miXbeDk20aTs10Ub/UxMt73VNtAlvaKLl/0sTbeybmmi5b2miGXdpoo3brYlW
sEcTbdLbmmiT39FEm/GuJtrU98LTmI4Dme9r0rbjA020Dz7URDu1VxON/rcW2ifjP9JEG/2x
JtrYTzTRxuzTRNN9qukoHN+vidbxmSbayc81le3yLzQdBesBSKgwlhupWvYyh4v5EuJr+aVU
Bc9wDPcVJNWS0UCwUXOMVBG/7GvIVCZ00ZjVwQz5Bob7O/1giw7MJyjqWxjoZyi6/e8gvpxn
qGLG6mGF7yHVxLmJJUR2ZxasvJPm+IMw0k8JyYDVR9/56BD0m8kTRxWq0kgVeTiytt9ONx6G
eAu/tJWqZpfx3A+QVMFYWZqqMFKFgsfK/AijQ2UKpoH56PY7j2jmvnr8KGSGMMwCfipkHTc/
fUwL66aftLCe/BkMVbTbbWdppAlM63EYFmRc+i1IiDpR+UwHZAYRQh3bE5BQTK5SCwWas7lP
wuCAmPJInoLEKmLTFXqsDifTelpLqXed0cJ6/KwW1u5fwrKY05cYzkFEfX0nJItPJeSoWtrV
6HG5GA7IbbKgJGRC1okzN+ogRWrVpUaqkm4Rl5hHkIkPkjaXPF6Qi4Skalr0ZathaCtvdehh
hDJByQfmhLU5KizHFhEdnpMQA0mFAo1JxMvM5WSEWGJdcjxVSHMOVxwYpBzllHiTIR7iLWwj
VcW73LQtAQb5I8oDmghpinxKqQFizTbK3ExzriQYrtx94N5h9QnH/j6QU2dnnHSDnTJxHFVE
O520neZCVCtknXysNBnOC3EkgyoYzGemv5milbm7r1bmrlRIqDSajXVuugnZ/SAzoAWFutxi
zrQe6Q8G4qLaTFOziL8pMwDSFHFl3Q2EtMDryACDPzpy29WDIFk6MU2+U3MwjAhOUjTsTT8/
tGcIjO7CCVXcrJPTVqRBZHF1XTr0C9BBUiDrzL7hQ+G8oI6hOzXDNO7SfMb98XDt3JOUZq4H
RmjnXpqhnTsvUzt3/kjt3AVZ2rkLs7VzF52nnasfpZnrqh2tnbtwjPYyJI7Vzu2Xo70M1+dq
1zvYqJ07dJx27rDx2rlD8iCrCzf4thBz5oqiCZrOStIX5WvTWFygjVc4UXvtXzZJO9cxWXst
xU+B4UElCx7Xp2rXljlNOzdjunau+Xzt3LILvLXvY3bp9WH1mRdrLgx5R6X9CsNF0Mfkcdt5
QXyOBlmLMAMyglKUJhm0RZirTRpITxZqIK0r0kDaXKyBZDFrIN1dooF0TylkKNKCqwjaIs8v
mQnFast2NNQPZEcuercM8tTUdNk15nmvvId56iMv66iAsf4WoLrgyLzzwZJKDeVfUAXDu9xs
U5oo1RBf1kyMYYaxMbMg3R+BhELW6aRKPG6BdsLqb6ZX1CiSLoZoU7Gl1lRdC5S/3F0bd3vE
zCN1isYtZQPmxBKdRe0u+eoTjk9nwwj/5cyCCSHvgs8hngFp3V6wGOIvCXsJtOlU0c55kKnh
uno+ZAexRowfH+p22gLICq8ubenYhV0UBvNwB+QG0qKwRGA6TEx+5qVd9lwRqoQ7FsOoEHet
Q17YL+lmVFJmZU6MMdNamSVLtRyV16xAhZsFsUG8OL9T6SFPElFrUcypy1rrId1PUJ4yOyKf
f70Bkr2XMN7LFzvkdL1+6RfyQoc5vS6dDS27DIqCFfdIrw42nf442vH/qSUdsk5v3eLsUZ6o
xp7Q177ZoxKtfYuH0V1+UogLxk2n19sMTT1SffLyHtFPCD2if+bqEf1Td4/o+z09on/e3CP6
ly09agERy3rWVFt7VJjvlvdIe/QVPaLH/U+P6Il/6BG9zx97RE/6U4/oQ1bAKG3nxr5DK2FU
V0GXvoxQ516pVev6W1ZpLsBPV2kuwLzVMCLArO/Kee30Z8ltXadXu14DXQ1ZoSeIA2b82yPj
q67Rxlt4rTZeyxptvHnXaeMx12vjXX6DNt6CP0OShTyej6bqqGKPg3HdCMMCb0UpJn+hPnqM
46YwBOfNYQj2W8LPS0TrH5myFtKDUhXW2jrIDj/73z5kt+HWcNPvt7bnbr1NA2n17RpI19+h
gXTXX7qd4P/IvOTOsBP1uwztfw19Gbj8mru0zJFflXe3Ftqqo/door19rybawfWaaD/dF56W
1cH03aCFZntio6adPnW/pp0aN2mq3oJ2TbSJD4i0wNRQVvXgBzXRIh/SRNM/rIkGj2iiRT2q
iZb0mCZayuOaaNTfIKGWtfJUFe1spoUnNEyb/pxjfhISxRWNZqO4ZHAzDPSt0FJ2LU9BnOhJ
U8uwtqfJmUqeS2bhG+iAdCjR97/hGTKx4RVu6Y7Zpr+JfbY7YXvkwS+f605Yr79h3/Mqat0v
wPCgHxpQIMLI2qrKwB189PdwjK9eFBcRBjKCyvhSOBU7/hGOcfTlcIwfXwnHOLINBvoLpjik
2yG2fLHQQM1yu1+FxGaWYxg35fA00sJrkB4YVf60wUd2wNCAnShyQrt+7M6d6vJt/4QhfoVB
5T35uorwqzdUhEf+pXZI2vU537wJhtoyslq0mCo0VZhr34J0RRxiyzuk+oA2/S2f71L5GW36
ka27VeQl+vIv9qjmz/zmbXX9K95Rz5/8rnr+le+pH4an3lfPf+UH6vL1H6rKF7ywlxi7Tobc
gqhzCDRHlQvGf0NGQJ6ucijRV7Afqe+4+WOIKyXPV7TY+cZPYIjve9CJfvPCfZDuFyr11Ost
5k+7F7frx8TuVxXHfKYqjv+8e3G2PjHrCzVxwo4DquJdX6oqv/MrVXHt192LS/R9m79RzV33
rap443eqJX/7e1XxnoOqyuccUi25+7Bq7nk/qIoX/KiqvOWIau65R1XF84+pii/5SVW88GdV
8V+Pq5Z8WYeqeMUJVfHyk6riladUxVeeVi35XWdUxfeeVW0t//5Fdd+rzqnm3tupum8GVJWv
1qmK2yJUld8dqSq+R9+9uE0/MjpKdd9XR6sqr49RVd4vVlXcP05VbIhX3feaBFXxtYmqP+w6
g6r4+iRV8c19VPdtTFYVX5eiqvzPfVVzX5GqKr6qn6r4z/1V933jANXcqweqilcNUjugGR8O
Vs199RBV8Q1pqiW/KV01941DVcU3D1MtecdwVfHzlKrytSPUcmfqM1TFUZmq4uiRquKYLFVx
bLZqyW86T/V3nxmlKn53tKp47xhV8ftj1Y53al2Oao/8eq6avZaWalQVp41TFfcbrypOz1Mr
eb+bJ6iKr89XFd9YoGYrjn1iomrRIiapKr9pstohWXDdFFXx9VNVxTdMU9332umq4nXnq4pv
u0BVfOuFqtWivwgG+cWKS7d3ZqgpLv/CpHLRMLhQ9eTrU6SSd1ixat5ks0regSVdL1/95Db9
2uhStetbJAyYCUm5YwP/yiC+huadPDW7zlRWDrFkFetMD+eugDTFI2h8AlTzRnolRBbxy6og
QbwzVMi3NNJcNSRUMORlBuJi1lnEB9AXUxAh66cNz9SoyzddDLE15dK+a4OL4hVAdIz7gzpI
LLSIxYHohKGrLBAtrcifDQaxbuo8TieL+5gjVoWVauZdrrm965Z71y33rlvuXbfcu265d93y
72rd8v8DUEsBAhQAFAAAAAgApYp/Ipimvc9pMQAANjoAAAwAAAAAAAAAAAAgAAAAAAAAAElF
VEZDT00yLlBERlBLAQIUABQAAAAIAHmKfyKoFIM53FYAAMMNAQALAAAAAAAAAAEAIAAAAJMx
AABJRVRGQ09NMi5QU1BLAQIUABQAAAAIALqKfyJ6dAiMkGAAAACYAQAMAAAAAAAAAAEAIAAA
AJiIAABJRVRGQ09NMi5ET0NQSwUGAAAAAAMAAwCtAAAAUukAAAAA

--Multipart_Tue_Apr__1_14:02:14_1997-1--

From rem-conf-request@es.net Tue Apr 01 15:24:43 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <22571-0@osi-east2.es.net>; Tue, 1 Apr 1997 15:20:29 -0800
Received: from sirius.ctr.columbia.edu by osi-west.es.net with ESnet SMTP (PP);
          Tue, 1 Apr 1997 15:20:22 -0800
Received: from cornet.ctr.columbia.edu (angin@cornet.ctr.columbia.edu [128.59.68.45]) 
          by sirius.ctr.columbia.edu (8.8.5/8.6.4.287) with ESMTP id SAA15754;
          Tue, 1 Apr 1997 18:20:14 -0500 (EST)
Received: from localhost (angin@localhost) 
          by cornet.ctr.columbia.edu (8.8.5/8.6.4.788743) with SMTP 
          id SAA03026; Tue, 1 Apr 1997 18:20:12 -0500 (EST)
Date: Tue, 1 Apr 1997 18:20:10 -0500 (EST)
From: Oguz Angin <angin@ctr.columbia.edu>
To: rem-conf@es.net
cc: mnl@ctr.columbia.edu
Subject: Comet Group Seminar: Don Towsley, University of Massachusetts, 
         "Reliable Multicast"
Message-ID: <Pine.SUN.3.95q.970401181738.2970B-100000@cornet.ctr.columbia.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


MBone Broadcast Announcement

Title:
    RELIABLE MULTICAST
 
Speaker:
    Don Towsley
    Department of Computer Science,
    University of Massachusetts

Date:
    Thursday, April 03, 1997

Time:
    12:00 NOON - 1:00 PM EST

Multicast Address:
    audio:  DVI, RTP, 224.2.194.51/21104 , ttl=127
    video:  H.261, RTP, 224.2.170.239/57392 , ttl=127

Contact:
    Andrew T. Campbell <campbell@ctr.columbia.edu>

URL:
    http://comet.ctr.columbia.edu/activities/seminars/

Place:
    Interschool Lab.
    Schapiro Research Building
    Center for Telecommunications Research
    Columbia University
    New York City, USA

Abstract:

Multicast applications are important applications in the  
wide-area-networks. Examples of such applications include
teleconferencing, lecture  dissemination, and distributed interactive
simulation (DIS). These  applications require the use of reliable network
services for components such as whiteboards, drawing packages, and
control that can scale to handle 100s to 1000s of participants. 

This talk describes and compares different approaches for providing 
reliable multicast (mcast) to such applications. These include:

- shifting responsibilities to receivers

- use of NAK suppression

- use of multiple multicast groups

- use of hierarchical recovery structures

- use of forward error correction (FEC)

Simple analytical models are used to compare these different approaches
in  the context of two types of applications: (i) a one-to-many
application (e.g. telelecturing/teleconference, ftp) consisting of one
sender sending data to many receivers and (ii) a many-many application
(e.g., distributed interactive simulation) in which all participants
simultaneously send and receive. 





From rem-conf-request@es.net Tue Apr 01 15:39:08 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <22811-0@osi-east2.es.net>; Tue, 1 Apr 1997 15:33:46 -0800
Received: from mail1.noc.ntt.co.jp by osi-west.es.net with ESnet SMTP (PP);
          Tue, 1 Apr 1997 15:33:40 -0800
Received: by mail1.noc.ntt.co.jp (8.8.5/NOC-MAIL1) id IAA09652;
          Wed, 2 Apr 1997 08:33:34 +0900 (JST)
Received: from nsi1.noc.ntt.co.jp by mail1.noc.ntt.co.jp via vms id sma009465;
          Wed Apr 2 08:31:48 1997
Received: from shinjuku.hqs.ntt.co.jp by nsi1.noc.ntt.co.jp (8.8.5/NOC-NSI1) 
          id IAA08450; Wed, 2 Apr 1997 08:31:48 +0900 (JST)
Received: from ops.nw.hqs.ntt.co.jp 
          by shinjuku.hqs.ntt.co.jp (8.8.5/Shinjuku2.14) with ESMTP 
          id IAA06393; Wed, 2 Apr 1997 08:31:24 +0900 (JST)
Received: from [10.8.57.172] (nw57172.nw.hqs.ntt.co.jp [10.8.57.172]) 
          by ops.nw.hqs.ntt.co.jp (8.8.5/3.4W4-nw.CO-02) with SMTP id IAA18832;
          Wed, 2 Apr 1997 08:31:27 +0900 (JST)
Message-Id: <199704012331.IAA18832@ops.nw.hqs.ntt.co.jp>
X-Sender: ochi@ops.nw.hqs.ntt.co.jp
X-Mailer: Macintosh Eudora Pro Version 2.1.3-Jr3
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Date: Wed, 2 Apr 1997 08:34:38 +0900
To: ochi@ops.nw.hqs.ntt.co.jp
From: ochi@nw.hqs.ntt.co.jp (Ochi Toshiyuki)
Subject: Re: 7-11 April is going to be tight on the MBONE
Cc: rem-conf@es.net, rodgers@nlm.nih.gov

FCFS priority also doesn't work since some events schedule/advertise
Mbone transmissions only after most of the registration period is over,
in the (possibly misguided) belief that they don't want the freebie
Mbone to cannibalize the paying attendance base.



From rem-conf-request@es.net Tue Apr 01 15:45:52 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <22815-0@osi-east2.es.net>; Tue, 1 Apr 1997 15:34:59 -0800
Received: from mail1.noc.ntt.co.jp by osi-west.es.net with ESnet SMTP (PP);
          Tue, 1 Apr 1997 15:34:52 -0800
Received: by mail1.noc.ntt.co.jp (8.8.5/NOC-MAIL1) id IAA09677;
          Wed, 2 Apr 1997 08:33:44 +0900 (JST)
Received: from nsi1.noc.ntt.co.jp by mail1.noc.ntt.co.jp via vms id sma009501;
          Wed Apr 2 08:32:02 1997
Received: from shinjuku.hqs.ntt.co.jp by nsi1.noc.ntt.co.jp (8.8.5/NOC-NSI1) 
          id IAA08476; Wed, 2 Apr 1997 08:32:01 +0900 (JST)
Received: from ops.nw.hqs.ntt.co.jp 
          by shinjuku.hqs.ntt.co.jp (8.8.5/Shinjuku2.14) with ESMTP 
          id IAA06403; Wed, 2 Apr 1997 08:31:37 +0900 (JST)
Received: from [10.8.57.172] (nw57172.nw.hqs.ntt.co.jp [10.8.57.172]) 
          by ops.nw.hqs.ntt.co.jp (8.8.5/3.4W4-nw.CO-02) with SMTP id IAA18840;
          Wed, 2 Apr 1997 08:31:40 +0900 (JST)
Message-Id: <199704012331.IAA18840@ops.nw.hqs.ntt.co.jp>
X-Sender: ochi@ops.nw.hqs.ntt.co.jp
X-Mailer: Macintosh Eudora Pro Version 2.1.3-Jr3
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Date: Wed, 2 Apr 1997 08:34:52 +0900
To: ochi@ops.nw.hqs.ntt.co.jp
From: ochi@nw.hqs.ntt.co.jp (Ochi Toshiyuki)
Subject: Re: 7-11 April is going to be tight on the MBONE (Was: Broadcasting of 
         Infocom'97)
Cc: rem-conf@es.net, oka@kobe-u.ac.jp, dem@hep.net, likavec@igd.fhg.de


>The announcement from Kobe indicates that there will be at least four
>conferences of international scope contending for MBONE bandwidth during
>the week of 7-11 April.

Fortunately they're all in different timezones, so the overlap is not
as bad as it could be unless you want to listen to all of them.  The
problem is the rebroadcasts that people are discussing.  These could
always be moved to a different week - the potential audience is likely
to be larger if it's not split between sessions.

According to all the ISPs present at the MBoned WG at the last IETF,
no major ISP is running rate-limiting anymore, and we've regularly
seen traffic rates above the old nominal 512Kbps.  The Mbone is slowly
growing up.  It *should* be able to handle four simultaneous
conferences.  But lets not push our luck...

Mark



From rem-conf-request@es.net Tue Apr 01 15:56:12 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <22823-0@osi-east2.es.net>; Tue, 1 Apr 1997 15:37:09 -0800
Received: from mail1.noc.ntt.co.jp by osi-west.es.net with ESnet SMTP (PP);
          Tue, 1 Apr 1997 15:37:02 -0800
Received: by mail1.noc.ntt.co.jp (8.8.5/NOC-MAIL1) id IAA10029 
          for <rem-conf@es.net>; Wed, 2 Apr 1997 08:37:01 +0900 (JST)
Received: from nsi1.noc.ntt.co.jp by mail1.noc.ntt.co.jp via vms id sma009815;
          Wed Apr 2 08:35:04 1997
Received: from shinjuku.hqs.ntt.co.jp by nsi1.noc.ntt.co.jp (8.8.5/NOC-NSI1) 
          id IAA08800 for <rem-conf@es.net>;
          Wed, 2 Apr 1997 08:35:03 +0900 (JST)
Received: from ops.nw.hqs.ntt.co.jp 
          by shinjuku.hqs.ntt.co.jp (8.8.5/Shinjuku2.14) with ESMTP 
          id IAA06521 for <rem-conf@es.net>;
          Wed, 2 Apr 1997 08:34:39 +0900 (JST)
Received: from [10.8.57.172] (nw57172.nw.hqs.ntt.co.jp [10.8.57.172]) 
          by ops.nw.hqs.ntt.co.jp (8.8.5/3.4W4-nw.CO-02) with SMTP id IAA18896;
          Wed, 2 Apr 1997 08:34:41 +0900 (JST)
Message-Id: <199704012334.IAA18896@ops.nw.hqs.ntt.co.jp>
X-Sender: ochi@ops.nw.hqs.ntt.co.jp
X-Mailer: Macintosh Eudora Pro Version 2.1.3-Jr3
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Date: Wed, 2 Apr 1997 08:37:53 +0900
To: ochi@ops.nw.hqs.ntt.co.jp
From: ochi@nw.hqs.ntt.co.jp (Ochi Toshiyuki)
Subject: Re: AVT meetings at April IETF
Cc: rem-conf@es.net

I received word today that the AVT schedule for the Memphis meeting
has been changed.  Our time is now all on Wednesday, which is the day
chopped into shorter 1-hour slots.  We have three assigned:

    Wednesday Morning I  (9:00-10:00)
    Wednesday Evening I and Evening II (contiguous, 20:00-22:00)

This is one hour less than we have had for recent meetings, but it
seems that we may need less time at this meeting.  I received a few
requests for agenda items (MIB, H.263, MPEG); are there others?

There has not been as much activity since the last meeting as I
anticipated, especially with regard to specification of additional
profiles for other RTCP scenarios.  It may be that some of the more
complicated ideas have fatal problems or simply require more time to
develop -- more research than engineering.  Bernard Aboba responded
with a suggestion that perhaps the only new profile we need is one
that allows the RTCP bandwidth fraction to be specified, and my
response was to wonder where that parameter would be signalled.

Based on a recent conversation with Mark Handley, I think that
instead of defining a new profile, perhaps all we need is to change
the current profile to establish 5% as the default, but to allow the
fraction to be specified as a session parameter.  For example, in SDP
where there is now a "session bandwidth" attribute, we could define
an additional, separate attribute to specify the RTCP bandwidth.  In
fact, because one may want to reduce the bandwidth for reception
reports to zero, but one would usually still want sender reports to
establish the CNAME and provide synchronization timestamps, Mark
suggested an attribute with two paramaters: one giving the RTCP
bandwidth for data senders, and a second giving the RTCP bandwidth
for receivers.  (Currently, senders get at least 1/4 of the 5% BW).

This would cover the applications Bernard wanted (some with a low
feedback BW fraction, and some with none at all).  For sessions that
might adapt the coding over a large BW range, this separate attribute
would also allow specifying an RTCP BW corresponding to a nominal
session BW that might be significantly below the max BW given by the
existing attribute for the overall session BW.

Beyond this, I think the outcome of the discussion at the last
meeting is that "timer reconsideration" should be added to the
interval calculation algorithm to manage simultaneous joins.  I also
believe the current fixed minimum interval value of 5 seconds and
corresponding initial interval value of 2.5 seconds should be scaled
with the RTCP bandwidth so that there is enough time for timer
reconsideration to work on low bandwidth lines.  These things would
just be edits to the RTP spec before Draft Standard.

Do others agree with this summary of where we are?  Are there issues
to be discussed (though let's not simply repeat the discussion from
last time, please)?  Other new ideas?
                                                        -- Steve



From rem-conf-request@es.net Tue Apr 01 16:11:16 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <22832-0@osi-east2.es.net>; Tue, 1 Apr 1997 15:37:33 -0800
Received: from mail1.noc.ntt.co.jp by osi-west.es.net with ESnet SMTP (PP);
          Tue, 1 Apr 1997 15:37:11 -0800
Received: by mail1.noc.ntt.co.jp (8.8.5/NOC-MAIL1) id IAA10048 
          for <rem-conf@es.net>; Wed, 2 Apr 1997 08:37:09 +0900 (JST)
Received: from nsi1.noc.ntt.co.jp by mail1.noc.ntt.co.jp via vms id sma009847;
          Wed Apr 2 08:35:18 1997
Received: from shinjuku.hqs.ntt.co.jp by nsi1.noc.ntt.co.jp (8.8.5/NOC-NSI1) 
          id IAA08840 for <rem-conf@es.net>;
          Wed, 2 Apr 1997 08:35:17 +0900 (JST)
Received: from ops.nw.hqs.ntt.co.jp 
          by shinjuku.hqs.ntt.co.jp (8.8.5/Shinjuku2.14) with ESMTP 
          id IAA06535 for <rem-conf@es.net>;
          Wed, 2 Apr 1997 08:34:53 +0900 (JST)
Received: from [10.8.57.172] (nw57172.nw.hqs.ntt.co.jp [10.8.57.172]) 
          by ops.nw.hqs.ntt.co.jp (8.8.5/3.4W4-nw.CO-02) with SMTP id IAA18901;
          Wed, 2 Apr 1997 08:34:56 +0900 (JST)
Message-Id: <199704012334.IAA18901@ops.nw.hqs.ntt.co.jp>
X-Sender: ochi@ops.nw.hqs.ntt.co.jp
X-Mailer: Macintosh Eudora Pro Version 2.1.3-Jr3
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Date: Wed, 2 Apr 1997 08:38:07 +0900
To: ochi@ops.nw.hqs.ntt.co.jp
From: ochi@nw.hqs.ntt.co.jp (Ochi Toshiyuki)
Subject: RE: AVT meetings at April IETF
Cc: "rem-conf@es.net" <rem-conf@es.net>

The idea of separate attributes for sender and receiver report bandwidths
is a good one.

Question: will this bandwidth be specified as an absolute number, or as
a fraction of 5 percent? The fraction might be better security-wise so that
someone could not increase the bandwidth unreasonably.



From rem-conf-request@es.net Tue Apr 01 16:27:45 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <22942-0@osi-east2.es.net>; Tue, 1 Apr 1997 15:48:53 -0800
Received: from mail1.noc.ntt.co.jp by osi-west.es.net with ESnet SMTP (PP);
          Tue, 1 Apr 1997 15:48:38 -0800
Received: by mail1.noc.ntt.co.jp (8.8.5/NOC-MAIL1) id IAA11582 
          for <rem-conf@es.net>; Wed, 2 Apr 1997 08:48:36 +0900 (JST)
Received: from nsi1.noc.ntt.co.jp by mail1.noc.ntt.co.jp via vms id sma011129;
          Wed Apr 2 08:45:16 1997
Received: from shinjuku.hqs.ntt.co.jp by nsi1.noc.ntt.co.jp (8.8.5/NOC-NSI1) 
          id IAA10065 for <rem-conf@es.net>;
          Wed, 2 Apr 1997 08:45:15 +0900 (JST)
Received: from ops.nw.hqs.ntt.co.jp 
          by shinjuku.hqs.ntt.co.jp (8.8.5/Shinjuku2.14) with ESMTP 
          id IAA06950 for <rem-conf@es.net>;
          Wed, 2 Apr 1997 08:44:51 +0900 (JST)
Received: from [10.8.57.172] (nw57172.nw.hqs.ntt.co.jp [10.8.57.172]) 
          by ops.nw.hqs.ntt.co.jp (8.8.5/3.4W4-nw.CO-02) with SMTP id IAA19294;
          Wed, 2 Apr 1997 08:44:54 +0900 (JST)
Message-Id: <199704012344.IAA19294@ops.nw.hqs.ntt.co.jp>
X-Sender: ochi@ops.nw.hqs.ntt.co.jp
X-Mailer: Macintosh Eudora Pro Version 2.1.3-Jr3
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Date: Wed, 2 Apr 1997 08:48:05 +0900
To: ochi@ops.nw.hqs.ntt.co.jp
From: ochi@nw.hqs.ntt.co.jp (Ochi Toshiyuki)
Subject: Re: Encrypting RTP streams
Cc: rem-conf@es.net


>In H.323, encryption is applied just to the RTP payload; the headers
>remaining in the clear.

>      of the IV is always equal to the length of a block. All modes
>      except Electronic Code Book (ECB) mode require an IV. In all
>      cases, an IV shall be constructed from the first B octets of:
>      (Seq# + Timestamp + Seq#) from the RTP header.

I don't claim to be an encryption expert, but my understanding was
that the IV was supposed to be secret unless the first block contains
random data.  If this is not the case, chained ciphers are weakened
significantly.

Thus taking the IV from the plain text header doesn't seem to be a
good idea without additional precautions.  A better bet might be to
use a fixed IV and add a random block of dummy data to the front of
the payload before encryption.  This way the second block which
contains predictable data is chained from the random first block
rather than from a known IV.

Mark



From rem-conf-request@es.net Tue Apr 01 16:47:18 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <22940-0@osi-east2.es.net>; Tue, 1 Apr 1997 15:48:53 -0800
Received: from mail1.noc.ntt.co.jp by osi-west.es.net with ESnet SMTP (PP);
          Tue, 1 Apr 1997 15:48:12 -0800
Received: by mail1.noc.ntt.co.jp (8.8.5/NOC-MAIL1) id IAA11521;
          Wed, 2 Apr 1997 08:48:10 +0900 (JST)
Received: from nsi1.noc.ntt.co.jp by mail1.noc.ntt.co.jp via vms id sma011060;
          Wed Apr 2 08:44:44 1997
Received: from shinjuku.hqs.ntt.co.jp by nsi1.noc.ntt.co.jp (8.8.5/NOC-NSI1) 
          id IAA10017; Wed, 2 Apr 1997 08:44:43 +0900 (JST)
Received: from ops.nw.hqs.ntt.co.jp 
          by shinjuku.hqs.ntt.co.jp (8.8.5/Shinjuku2.14) with ESMTP 
          id IAA06919; Wed, 2 Apr 1997 08:44:19 +0900 (JST)
Received: from [10.8.57.172] (nw57172.nw.hqs.ntt.co.jp [10.8.57.172]) 
          by ops.nw.hqs.ntt.co.jp (8.8.5/3.4W4-nw.CO-02) with SMTP id IAA19273;
          Wed, 2 Apr 1997 08:44:22 +0900 (JST)
Message-Id: <199704012344.IAA19273@ops.nw.hqs.ntt.co.jp>
X-Sender: ochi@ops.nw.hqs.ntt.co.jp
X-Mailer: Macintosh Eudora Pro Version 2.1.3-Jr3
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Date: Wed, 2 Apr 1997 08:47:33 +0900
To: ochi@ops.nw.hqs.ntt.co.jp
From: ochi@nw.hqs.ntt.co.jp (Ochi Toshiyuki)
Subject: Re: earn $75
Cc: hermenh@ix.netcom.com, rem-conf@es.net

On Wed, 26 Feb 1997, Christine Perey wrote:

> How is your study going?
>
> CP

No problems.

Seppo



From rem-conf-request@es.net Tue Apr 01 17:10:27 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <22980-0@osi-east2.es.net>; Tue, 1 Apr 1997 15:54:38 -0800
Received: from mail1.noc.ntt.co.jp by osi-west.es.net with ESnet SMTP (PP);
          Tue, 1 Apr 1997 15:54:10 -0800
Received: by mail1.noc.ntt.co.jp (8.8.5/NOC-MAIL1) id IAA12397;
          Wed, 2 Apr 1997 08:54:06 +0900 (JST)
Received: from nsi1.noc.ntt.co.jp by mail1.noc.ntt.co.jp via vms id sma011706;
          Wed Apr 2 08:49:46 1997
Received: from shinjuku.hqs.ntt.co.jp by nsi1.noc.ntt.co.jp (8.8.5/NOC-NSI1) 
          id IAA10738; Wed, 2 Apr 1997 08:49:45 +0900 (JST)
Received: from ops.nw.hqs.ntt.co.jp 
          by shinjuku.hqs.ntt.co.jp (8.8.5/Shinjuku2.14) with ESMTP 
          id IAA07174; Wed, 2 Apr 1997 08:49:21 +0900 (JST)
Received: from [10.8.57.172] (nw57172.nw.hqs.ntt.co.jp [10.8.57.172]) 
          by ops.nw.hqs.ntt.co.jp (8.8.5/3.4W4-nw.CO-02) with SMTP id IAA19370;
          Wed, 2 Apr 1997 08:49:23 +0900 (JST)
Message-Id: <199704012349.IAA19370@ops.nw.hqs.ntt.co.jp>
X-Sender: ochi@ops.nw.hqs.ntt.co.jp (Unverified)
X-Mailer: Macintosh Eudora Pro Version 2.1.3-Jr3
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Date: Wed, 2 Apr 1997 08:52:35 +0900
To: ochi@ops.nw.hqs.ntt.co.jp
From: ochi@nw.hqs.ntt.co.jp (Ochi Toshiyuki)
Subject: Re: Encrypting RTP streams
Cc: John H Wilson <John_H_Wilson@ccm.jf.intel.com>, rem-conf@es.net

Mark Handley wrote:
>
> >In H.323, encryption is applied just to the RTP payload; the headers
> >remaining in the clear.
>
> >      of the IV is always equal to the length of a block. All modes
> >      except Electronic Code Book (ECB) mode require an IV. In all
> >      cases, an IV shall be constructed from the first B octets of:
> >      (Seq# + Timestamp + Seq#) from the RTP header.
>
> I don't claim to be an encryption expert, but my understanding was
> that the IV was supposed to be secret unless the first block contains
> random data.  If this is not the case, chained ciphers are weakened
> significantly.
>
> Thus taking the IV from the plain text header doesn't seem to be a
> good idea without additional precautions.  A better bet might be to
> use a fixed IV and add a random block of dummy data to the front of
> the payload before encryption.  This way the second block which
> contains predictable data is chained from the random first block
> rather than from a known IV.

See Kaufman/Perlman/Speciner, "Network Security", p. 83. The book
recommends a random IV (not necessarily secret), so that the same
plaintext doesn't get encrypted into the same ciphertext. In particular:
"A randomly chosen IV guarantees that even if the same message is sent
repeatedly, the ciphertext will be completelely different each time.
Finally, a randomly chosen IV prevents attackers from supplying chosen
plaintext to the underlying encryption algorithm even if they can supply
chosen plaintext to the CBC." A random initial message block would have
the same effect. Choosing the IV from the *payload* plaintext would
defeat this randomization purpose of the IV and you might as well use,
say, 0. Given that the same payload transmitted twice is very unlikely
to have the same seq. #/ts combination, this seems ok.

Schneier (2nd ed., p. 194) says "... So, if there are n blocks, there
are n-1 exposed 'IVs,', even if the original IV is kept secret. So
there's no reason to keep the IV secret; the IV is just a dummy
ciphertext block...".


>
> Mark

Henning



From rem-conf-request@es.net Tue Apr 01 17:44:34 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <22978-0@osi-east2.es.net>; Tue, 1 Apr 1997 15:54:38 -0800
Received: from mail1.noc.ntt.co.jp by osi-west.es.net with ESnet SMTP (PP);
          Tue, 1 Apr 1997 15:54:05 -0800
Received: by mail1.noc.ntt.co.jp (8.8.5/NOC-MAIL1) id IAA12386;
          Wed, 2 Apr 1997 08:54:02 +0900 (JST)
Received: from nsi1.noc.ntt.co.jp by mail1.noc.ntt.co.jp via vms id sma011704;
          Wed Apr 2 08:49:43 1997
Received: from shinjuku.hqs.ntt.co.jp by nsi1.noc.ntt.co.jp (8.8.5/NOC-NSI1) 
          id IAA10730; Wed, 2 Apr 1997 08:49:43 +0900 (JST)
Received: from ops.nw.hqs.ntt.co.jp 
          by shinjuku.hqs.ntt.co.jp (8.8.5/Shinjuku2.14) with ESMTP 
          id IAA07169; Wed, 2 Apr 1997 08:49:18 +0900 (JST)
Received: from [10.8.57.172] (nw57172.nw.hqs.ntt.co.jp [10.8.57.172]) 
          by ops.nw.hqs.ntt.co.jp (8.8.5/3.4W4-nw.CO-02) with SMTP id IAA19363;
          Wed, 2 Apr 1997 08:49:20 +0900 (JST)
Message-Id: <199704012349.IAA19363@ops.nw.hqs.ntt.co.jp>
X-Sender: ochi@ops.nw.hqs.ntt.co.jp (Unverified)
X-Mailer: Macintosh Eudora Pro Version 2.1.3-Jr3
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Date: Wed, 2 Apr 1997 08:52:32 +0900
To: ochi@ops.nw.hqs.ntt.co.jp
From: ochi@nw.hqs.ntt.co.jp (Ochi Toshiyuki)
Subject: Re: Encrypting RTP streams
Cc: John H Wilson <John_H_Wilson@ccm.jf.intel.com>, rem-conf@es.net

Mark Handley wrote:
>
> >In H.323, encryption is applied just to the RTP payload; the headers
> >remaining in the clear.
>
> >      of the IV is always equal to the length of a block. All modes
> >      except Electronic Code Book (ECB) mode require an IV. In all
> >      cases, an IV shall be constructed from the first B octets of:
> >      (Seq# + Timestamp + Seq#) from the RTP header.
>
> I don't claim to be an encryption expert, but my understanding was
> that the IV was supposed to be secret unless the first block contains
> random data.  If this is not the case, chained ciphers are weakened
> significantly.
>
> Thus taking the IV from the plain text header doesn't seem to be a
> good idea without additional precautions.  A better bet might be to
> use a fixed IV and add a random block of dummy data to the front of
> the payload before encryption.  This way the second block which
> contains predictable data is chained from the random first block
> rather than from a known IV.

See Kaufman/Perlman/Speciner, "Network Security", p. 83. The book
recommends a random IV (not necessarily secret), so that the same
plaintext doesn't get encrypted into the same ciphertext. In particular:
"A randomly chosen IV guarantees that even if the same message is sent
repeatedly, the ciphertext will be completelely different each time.
Finally, a randomly chosen IV prevents attackers from supplying chosen
plaintext to the underlying encryption algorithm even if they can supply
chosen plaintext to the CBC." A random initial message block would have
the same effect. Choosing the IV from the *payload* plaintext would
defeat this randomization purpose of the IV and you might as well use,
say, 0. Given that the same payload transmitted twice is very unlikely
to have the same seq. #/ts combination, this seems ok.

Schneier (2nd ed., p. 194) says "... So, if there are n blocks, there
are n-1 exposed 'IVs,', even if the original IV is kept secret. So
there's no reason to keep the IV secret; the IV is just a dummy
ciphertext block...".


>
> Mark

Henning



From rem-conf-request@es.net Tue Apr 01 17:46:25 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <23019-0@osi-east2.es.net>; Tue, 1 Apr 1997 15:58:55 -0800
Received: from mail1.noc.ntt.co.jp by osi-west.es.net with ESnet SMTP (PP);
          Tue, 1 Apr 1997 15:58:13 -0800
Received: by mail1.noc.ntt.co.jp (8.8.5/NOC-MAIL1) id IAA12977 
          for <rem-conf@es.net>; Wed, 2 Apr 1997 08:58:10 +0900 (JST)
Received: from nsi1.noc.ntt.co.jp by mail1.noc.ntt.co.jp via vms id sma012115;
          Wed Apr 2 08:52:20 1997
Received: from shinjuku.hqs.ntt.co.jp by nsi1.noc.ntt.co.jp (8.8.5/NOC-NSI1) 
          id IAA11178 for <rem-conf@es.net>;
          Wed, 2 Apr 1997 08:52:18 +0900 (JST)
Received: from ops.nw.hqs.ntt.co.jp 
          by shinjuku.hqs.ntt.co.jp (8.8.5/Shinjuku2.14) with ESMTP 
          id IAA07279 for <rem-conf@es.net>;
          Wed, 2 Apr 1997 08:51:54 +0900 (JST)
Received: from [10.8.57.172] (nw57172.nw.hqs.ntt.co.jp [10.8.57.172]) 
          by ops.nw.hqs.ntt.co.jp (8.8.5/3.4W4-nw.CO-02) with SMTP id IAA19593;
          Wed, 2 Apr 1997 08:51:57 +0900 (JST)
Message-Id: <199704012351.IAA19593@ops.nw.hqs.ntt.co.jp>
X-Sender: ochi@ops.nw.hqs.ntt.co.jp (Unverified)
X-Mailer: Macintosh Eudora Pro Version 2.1.3-Jr3
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Date: Wed, 2 Apr 1997 08:55:09 +0900
To: ochi@ops.nw.hqs.ntt.co.jp
From: ochi@nw.hqs.ntt.co.jp (Ochi Toshiyuki)
Subject: Re: HELP
Cc: rem-conf@es.net

Holger,

The rem-conf@es.net mailing list does not use listserv commands.
What kind of help do you need from the rem-conf@es.net list
maintainer?

Thanks,


Marcy L. Kamps
************************************************************************
National Energy Research Scientific Computing Center (NERSC)
Energy Sciences Network (ESnet)  Lawrence Berkeley National Laboratory
Phone   : 1-510-486-6448         One Cyclotron Road, Bldg. 50C, Room 103
 (or)   : 1-800-66-NERSC         Berkeley, CA 94720  USA
Email   : kamps@nersc.gov        Internet: postmaster@es.net
************************************************************************

----- Begin Included Message -----

>From rem-conf-postmaster-request@es.net Wed Mar  5 07:58 PST 1997
To: rem-conf-request <rem-conf-request@es.net>
From: Holger Kruse <kruse@nordicglobal.com>
Date: Wed, 05 Mar 1997 18:55:41 -0400
Reply-To: kruse <kruse@nordicglobal.com>
X-Mailer: GoodNews 1.5 (Dec 28 1996)
Subject: HELP
Organization: Nordic Global Inc.
Content-Type: text
Content-Length: 90

HELP
--
Holger Kruse   kruse@nordicglobal.com
               http://www.nordicglobal.com



----- End Included Message -----



From rem-conf-request@es.net Tue Apr 01 17:57:15 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <23228-0@osi-east2.es.net>; Tue, 1 Apr 1997 16:29:22 -0800
Received: from mail1.noc.ntt.co.jp by osi-west.es.net with ESnet SMTP (PP);
          Tue, 1 Apr 1997 16:28:47 -0800
Received: by mail1.noc.ntt.co.jp (8.8.5/NOC-MAIL1) id JAA17136;
          Wed, 2 Apr 1997 09:23:32 +0900 (JST)
Received: from nsi1.noc.ntt.co.jp by mail1.noc.ntt.co.jp via vms id sma016527;
          Wed Apr 2 09:20:09 1997
Received: from shinjuku.hqs.ntt.co.jp by nsi1.noc.ntt.co.jp (8.8.5/NOC-NSI1) 
          id JAA16331; Wed, 2 Apr 1997 09:20:07 +0900 (JST)
Received: from ops.nw.hqs.ntt.co.jp 
          by shinjuku.hqs.ntt.co.jp (8.8.5/Shinjuku2.14) with ESMTP 
          id JAA09334; Wed, 2 Apr 1997 09:19:42 +0900 (JST)
Received: from [10.8.57.172] (nw57172.nw.hqs.ntt.co.jp [10.8.57.172]) 
          by ops.nw.hqs.ntt.co.jp (8.8.5/3.4W4-nw.CO-02) with SMTP id JAA20452;
          Wed, 2 Apr 1997 09:19:45 +0900 (JST)
Message-Id: <199704020019.JAA20452@ops.nw.hqs.ntt.co.jp>
X-Sender: ochi@ops.nw.hqs.ntt.co.jp (Unverified)
X-Mailer: Macintosh Eudora Pro Version 2.1.3-Jr3
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Date: Wed, 2 Apr 1997 09:22:58 +0900
To: deleon@hplabsz.hpl.hp.com, rodgers@nlm.nih.gov, rem-conf@es.net, 
    oka@kobe-u.ac.jp, dem@hep.net, likavec@igd.fhg.de, infocom411@ckp.or.jp, 
    Michael.Speer@Eng.Sun.COM, mjh@isi.edu, rodgers@nlm.nih.gov, 
    likavec@igd.fhg.de, shimojo@center.osaka-u.ac.jp, mnl@ctr.columbia.edu, 
    John_H_Wilson@ccm.jf.intel.com
From: ochi@nw.hqs.ntt.co.jp (Ochi Toshiyuki)
Subject: Sorry

I am sorry.
This mornig I made mistake. I send  many unrelizable mail for everyone.



From rem-conf-request@es.net Tue Apr 01 18:38:48 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <23594-0@osi-east2.es.net>; Tue, 1 Apr 1997 17:26:25 -0800
Received: from mail.arc.nasa.gov (actually nick.arc.nasa.gov) 
          by osi-west.es.net with ESnet SMTP (PP);
          Tue, 1 Apr 1997 17:25:42 -0800
Received: from [128.102.80.28] by mail.arc.nasa.gov (8.8.5/1.35) id RAA29996;
          Tue, 1 Apr 1997 17:22:03 -0800 (PST)
Date: Tue, 1 Apr 1997 17:22:03 -0800 (PST)
Message-Id: <v02140b16af66f155b2a8@[128.102.80.28]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 1 (Highest)
To: rem-conf@es.net
From: mallard@mail.arc.nasa.gov (Mark Allard)
Subject: NASA-Shuttle Mission (STS-83) MBone Coverage

MBone Broadcast Announcement and Request for Comment

Continuous MBone coverage of NASA Space Shuttle Mission STS-83
(Microgravity Science Laboratory - 1) will be made available as a public
service to the MBone community by NASA-Ames Research Center.

Coverage is expected to start Wednesday morning (4/2/97) and run through
the duration of the mission, approximately 17 days.

Realizing this is an especially heavily scheduled month for the MBone, I
would like to ask for any feeback or suggestions to assure that as many
people as possible can benefit from this unique coverage without seriously
impacting the large number of other simultaneous transmissions being
scheduled.

This mission will have a number of unique activities associated with it
including use of a new laser based vehicle tracking system during the
launch.

Send any comments, suggestions, or schedule issues to -
Mark Allard
mallard@mail.arc.nasa.gov

Thanks,
M




From rem-conf-request@es.net Tue Apr 01 20:50:45 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <24546-0@osi-east2.es.net>; Tue, 1 Apr 1997 19:47:44 -0800
Received: from rx7.ee.lbl.gov by osi-west.es.net with ESnet SMTP (PP);
          Tue, 1 Apr 1997 19:47:14 -0800
Received: by rx7.ee.lbl.gov (8.8.2/1.43r) id TAA26236;
          Tue, 1 Apr 1997 19:50:32 -0800 (PST)
Message-Id: <199704020350.TAA26236@rx7.ee.lbl.gov>
To: Toerless Eckert <Toerless.Eckert@Informatik.Uni-Erlangen.de>
cc: vinay@agni.nuko.com (Vinay Bannai), sjn@walsin.com.my, rem-conf@es.net
Subject: Re: Video Format
In-reply-to: Your message of Tue, 25 Mar 97 09:25:30 N.
Date: Tue, 01 Apr 97 19:50:31 PST
From: Van Jacobson <van@ee.lbl.gov>

> i.e.: a CIF-picture is supposed to transport a video picture
> that has a square-pixel resolution of 375x288. This is often not
> done correctly (i.e.: i think vic and a lot of other
> videoconferencing applications actually transport square
> pixel-video-content in the 352x288 resolution).

Toerless,

Where did you obtain this rather amazing & totally incorrect
piece of information?  Please read the third paragraph of
section 3.1 of the ITU H.261 standard.  It's the one that
starts

   "In the first format (CIF), the luminance sampling structure is
    352 pels per line, 288 lines per picture ..."

I don't know about "a lot of other videoconferencing applications" but
vic follows the ITU standard *very* closely & its data stream has
successfully interoperated with a number of hardware codecs.

 - Van

From rem-conf-request@es.net Wed Apr 02 06:34:23 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <01606-0@osi-east2.es.net>; Wed, 2 Apr 1997 06:13:00 -0800
Received: from bungo.wago.de by osi-west.es.net with ESnet SMTP (PP);
          Wed, 2 Apr 1997 06:12:25 -0800
Received: by bungo.wago.de (5.0/GEN-1.2.0) via EUnet for es.net id AA18024;
          Wed, 2 Apr 1997 16:11:22 --100
>Received: from cc-smtp1.wago.de by donau.wago.de (SMI-8.6/SMI-SVR4) id 
           PAA12636; Wed, 2 Apr 1997 15:53:08 +0200
Received: from cc-smtp1.wago.de by donau.wago.de (SMI-8.6/SMI-SVR4) id PAA12636;
          Wed, 2 Apr 1997 15:53:08 +0200
Received: from cc:Mail by cc-smtp1.wago.de id AA859989314;
          Wed, 02 Apr 97 15:55:14 CET
Date: Wed, 02 Apr 97 15:55:14 CET
From: Regis_Le-Roux_at_WG-REN@wago.de
Message-Id: <9703028599.AA859989314@cc-smtp1.wago.de>
To: rem-conf@es.net
Content-Type: text
Content-Length: 409

     Dear sir or Madam,
     
     I've heard about your videophone mailing list on www.bitscout.com. As 
     I am really interested in getting some info about videoconferencing, 
     H320 and especially troubleshooting conflicts, I would be very pleased 
     to register on your mailing list.
     
     I look forward to hearing from you soon.
     
     Regis LeRoux
     e-mail: regis.le-roux@wago.de



From rem-conf-request@es.net Wed Apr 02 09:20:59 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <02263-0@osi-east2.es.net>; Wed, 2 Apr 1997 08:54:45 -0800
Received: from faui40.informatik.uni-erlangen.de by osi-west.es.net 
          with ESnet SMTP (PP); Wed, 2 Apr 1997 08:54:29 -0800
Received: from faui45r.informatik.uni-erlangen.de (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) 
          by faui40.informatik.uni-erlangen.de (8.8.5/8.0.5-FAU) with ESMTP 
          id SAA18735; Wed, 2 Apr 1997 18:54:16 +0200 (MET DST)
From: Toerless Eckert <Toerless.Eckert@Informatik.Uni-Erlangen.de>
Message-Id: <199704021654.SAA18735@faui40.informatik.uni-erlangen.de>
Subject: Re: Video Format
To: van@ee.lbl.gov (Van Jacobson)
Date: Wed, 2 Apr 1997 18:54:15 +0200 (MET DST)
Cc: Toerless.Eckert@Informatik.Uni-Erlangen.de, vinay@agni.nuko.com, 
    sjn@walsin.com.my, rem-conf@es.net
In-Reply-To: <199704020350.TAA26236@rx7.ee.lbl.gov> from "Van Jacobson" at Apr 1, 97 07:50:31 pm
Organisation: CSD IMMD IV, University of Erlangen, Germany
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

> > i.e.: a CIF-picture is supposed to transport a video picture
> > that has a square-pixel resolution of 375x288. This is often not
> > done correctly (i.e.: i think vic and a lot of other
> > videoconferencing applications actually transport square
> > pixel-video-content in the 352x288 resolution).
> 
> Toerless,
> 
> Where did you obtain this rather amazing & totally incorrect
> piece of information?  Please read the third paragraph of
> section 3.1 of the ITU H.261 standard.  It's the one that
> starts
> 
>    "In the first format (CIF), the luminance sampling structure is
>     352 pels per line, 288 lines per picture ..."
> 
> I don't know about "a lot of other videoconferencing applications" but
> vic follows the ITU standard *very* closely & its data stream has
> successfully interoperated with a number of hardware codecs.

I think what i wrote is correct, it's only incomplete without the
paragraph that it was written as a reply to:

CIF is 352x288 right, but these 352x288 pixels are in intention not
square-pixel, which is something that people doing H.261 and other
CIF-resolution software on computers often miss. the 352 pixels per
line are 1/2 of 704 pixels which is the active-video resolution of
CCIR-601 video lines. The total resolution of a CCIR-601 video scanline
is 720 pixels.CCIR-601 video is expected to be displayed with an
aspect ratio of 4:3, thus the video picture conveyed in 720x576 pixels
is not square-pixel. 768x576 would be square-pixel. Thus the square-pixel
resolution of 375 in a CIF-picture. Instead of scaling the encoded
352 (non-square) video pixels horizontally to be 375, people often already
encode square-pixel information into the 352 pixel, which leads to
problems when communicating between systems that do (correctly_) not interpret
the 352 pixels as square-pixel.

Anything wrong with this ?

Toerless

From rem-conf-request@es.net Wed Apr 02 22:24:13 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <04885-0@osi-east2.es.net>; Wed, 2 Apr 1997 16:48:25 -0800
Received: from precept.com (actually hydra.precept.com) by osi-west.es.net 
          with ESnet SMTP (PP); Wed, 2 Apr 1997 16:47:40 -0800
Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4) id QAA27654;
          Wed, 2 Apr 1997 16:40:54 -0800
Date: Wed, 2 Apr 1997 16:42:55 -0800 ()
From: Stephen Casner <casner@precept.com>
To: rem-conf@es.net
Subject: AVT agenda for Memphis
Message-ID: <Pine.WNT.3.95.970402164131.-207261H-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

AVT Working Group:

Here's the proposed agenda for next week's meeting.  If you requested
a slot and I forgot about it, or if there is some other topic you
believe should be included, please let me know.  We have been
scheduled on Wednesday, the day of one-hour sessions.  The morning
session is just one hour, then we have two contiguous hours in the
evening.  The morning can carry over to the evening as needed.

Note the reading associated with each topic.  As agreed at the last
meeting, I have submitted requests for IESG Last Call on the
Compressed RTP spec and payload formats for Redundant Audio and H.263.

                                                -- Steve Casner



                       Audio/Video Transport WG
                                   
			     A G E N D A

Wednesday, April 9, 9:00-10:00

  - Introduction and status [Casner]			 5

      - Last Call on Redundant Audio payload
	    draft-perkins-rtp-redundancy-03.txt

  - IP/UDP/RTP header compression [Casner]		10
	draft-ietf-avt-crtp-02.txt

      - Changes as agreed in San Jose
      - Request for Last Call submitted

  - RTP payload formats

      - Last Call on payload format for H.263 [Zhu]	 5
	    draft-ietf-avt-rtp-payload-03.txt
      - Revisions to MPEG2 payload format [Civanlar]	15
	    RFC 2038, draft-civanlar-bmpeg-00.txt

  - RTP MIB specification [Baugher]			15
	    draft-ietf-avt-rtp-mib-00.txt

  - Request for liaison with T1A1.5 on performance
    specifications for Internet multimedia [Hauch]	10


Wednesday, April 9, 20:00-22:00

  - RTCP "timer reconsideration" [Rosenberg]		40

      - Simulation results
      - Open issues

  - Advancing RTP to Draft Standard [Casner]		30
	RFC 1889, draft-aboba-rtpscale-02.txt

      - Adding timer reconsideration
      - Scaling minimum interval
      - BYE flood avoidance
      - Some spec edits
      - Proof of interoperability requirements
      - Scalability analysis / applicability statement

  - Advancing RTP Profile to Draft Standard [Casner]	15
	draft-ietf-avt-profile-new-00.txt, .ps

      - Making RTCP bandwidth fraction adjustable

  - Wrapping up AVT work [Casner]			10


From rem-conf-request@es.net Thu Apr 03 12:44:35 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <06017-0@osi-east2.es.net>; Thu, 3 Apr 1997 12:30:58 -0800
Received: from mail1.fw-sj.sony.com by osi-west.es.net with ESnet SMTP (PP);
          Thu, 3 Apr 1997 12:30:25 -0800
Received: by mail1.fw-sj.sony.com id MAA02085;
          Thu, 3 Apr 1997 12:29:48 -0800 (PST)
Received: by mail2.sjc.in.sel.sony.com id MAA11336;
          Thu, 3 Apr 1997 12:29:47 -0800 (PST)
Received: from pc-compaq51 by sosfc (4.1/SMI-4.1) id AA28676;
          Thu, 3 Apr 97 12:29:44 PST
Message-Id: <3.0.32.19970403123043.00945b10@sosfc.adc.sel.sony.com>
X-Sender: dmc@sosfc.adc.sel.sony.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 03 Apr 1997 12:30:48 -0800
To: Toerless Eckert <Toerless.Eckert@Informatik.Uni-Erlangen.de>, 
    van@ee.lbl.gov (Van Jacobson)
From: Donald Craig <Donald_Craig@adc.sel.sony.com>
Subject: Re: Video Format
Cc: rem-conf@es.net
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

This is pretty good, an opportunity to step into a hissing match
over CIF, of all the disgusting lo-res blind-leading-the-blind
flickery magic lantern formats there ever was...(Just kidding, guys)

However, I happen to have a copy of ITU-R BT601-4 sitting on a
colleague's desk (thanks, Hugo), and to clarify Toerless's
last paragraph (just the 601 bits, I am NOT a CIF expert):

	CCIR-601 is officially known these days as ITU-R BT601-4.
	Total samples per line is 858 for 525/60 and 864 for 625/50.
	Active picture samples per line is 720 for both 525/60 and 625/50.

	For 525/60 (and drawing on SMPTE 125M-1995), active lines
	are 20 to 263 inclusive for field 1, and 283 to 525 inclusive
	for field 2, giving a vertical picture resolution of 487 lines
	circa 30 times a second.  (I don't have the EBU 625 spec handy,
	so I won't pontificate on that exact vertical picture resolution.)

These specifications (particularly the active lines one) are much abused
in practice, and if you go someplace like Japan you'll get to see nominal
4:3 aspect ratio happily displayed on your Bazooka TV in 16:9, with many
little fat people wandering around...

All this, and much, much, more is in a handy book snappily titled:
"Standards for Advanced Television and High Definition Production with
Supplemental Standards including Ancillary Audio", ISBN 0-940690-31-4,
available from:	The Society of Motion Picture and Television Engineers
			595 W. Hartsdale Avenue
			White Plains, New York  10607
Phone: (914) 761-1100
Also on the web at:	www.smpte.org

cheers,
Don Craig
(Definitely not speaking for his current employer, who probably makes
a CIF something, somewhere...)
----------------------------------------------------------------------------
At 06:54 PM 4/2/97 +0200, Toerless Eckert wrote:
>> > i.e.: a CIF-picture is supposed to transport a video picture
>> > that has a square-pixel resolution of 375x288. This is often not
>> > done correctly (i.e.: i think vic and a lot of other
>> > videoconferencing applications actually transport square
>> > pixel-video-content in the 352x288 resolution).
>> 
>> Toerless,
>> 
>> Where did you obtain this rather amazing & totally incorrect
>> piece of information?  Please read the third paragraph of
>> section 3.1 of the ITU H.261 standard.  It's the one that
>> starts
>> 
>>    "In the first format (CIF), the luminance sampling structure is
>>     352 pels per line, 288 lines per picture ..."
>> 
>> I don't know about "a lot of other videoconferencing applications" but
>> vic follows the ITU standard *very* closely & its data stream has
>> successfully interoperated with a number of hardware codecs.
>
>I think what i wrote is correct, it's only incomplete without the
>paragraph that it was written as a reply to:
>
>CIF is 352x288 right, but these 352x288 pixels are in intention not
>square-pixel, which is something that people doing H.261 and other
>CIF-resolution software on computers often miss. the 352 pixels per
>line are 1/2 of 704 pixels which is the active-video resolution of
>CCIR-601 video lines. The total resolution of a CCIR-601 video scanline
>is 720 pixels.CCIR-601 video is expected to be displayed with an
>aspect ratio of 4:3, thus the video picture conveyed in 720x576 pixels
>is not square-pixel. 768x576 would be square-pixel. Thus the square-pixel
>resolution of 375 in a CIF-picture. Instead of scaling the encoded
>352 (non-square) video pixels horizontally to be 375, people often already
>encode square-pixel information into the 352 pixel, which leads to
>problems when communicating between systems that do (correctly_) not
interpret
>the 352 pixels as square-pixel.
>
>Anything wrong with this ?
>
>Toerless
>
>

From rem-conf-request@es.net Fri Apr 04 07:50:19 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <07545-0@osi-east2.es.net>; Fri, 4 Apr 1997 05:52:55 -0800
Received: from mailcom.videoconferencing.com by osi-west.es.net 
          with ESnet SMTP (PP); Fri, 4 Apr 1997 05:52:21 -0800
Received: by mailcom.videoconferencing.com 
          with Microsoft Exchange (IMC 4.0.837.3) 
          id <01BC40D5.A257B540@mailcom.videoconferencing.com>;
          Fri, 4 Apr 1997 08:53:15 -0500
Message-ID: <c=US%a=_%p=Intellect_Video_%l=MAILCOM-970404135232Z-665@mailcom.videoconferencing.com>
X-MS-TNEF-Correlator: <c=US%a=_%p=Intellect_Video_%l=MAILCOM-970404135232Z-665@mailcom.videoconferencing.com>
From: Matthew Feldman <mfeldman@VideoConferencing.com>
To: "'rem-conf@es.net'" <rem-conf@es.net>
Subject: H.32x for Dummies
Date: Fri, 4 Apr 1997 08:52:32 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3
Encoding: 14 TEXT, 38 UUENCODE
X-MS-Attachment: WINMAIL.DAT 0 00-00-1980 00:00

I am looking for a document which most closely resembles "H.32x for 
Dummies".

Specifically, I am looking for a simplistic explanation on how video get 
framed, encoded, packetized, etc. and then how it travels from software to 
hardware to networks.

Thank you,

Matthew Feldman
Chief Technology Officer
Intelect Visual Communications
(212) 317-9600


begin 600 WINMAIL.DAT
M>)\^(A -`0:0" `$```````!``$``0>0!@`(````Y 0```````#H``$(@ <`
M& ```$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`06 `P`.````S0<$``0`
M" `T`" `!0`]`0$@@ ,`#@```,T'! `$``@`- `A``4`/@$!"8 !`"$````P
M14$U138S,T,V04-$,#$Q0C5!-S X,# R0CE%,4-$0@!"!P$-@ 0``@````(`
M`@`!!( !`!(```!(+C,R>"!F;W(@1'5M;6EE<P"N!0$#D 8`) 4``!D```! 
M`#D`\)";<?] O $>`' ``0```!(```!(+C,R>"!F;W(@1'5M;6EE<P````(!
M<0`!````%@````&\0/Y+#3/FI1"LQA'0M:<(`"N>'-L```,`!A!VZ#_ `P`'
M$"(!```>``@0`0```&4```!)04U,3T]+24Y'1D]2041/0U5-14Y45TA)0TA-
M3U-40TQ/4T5,65)%4T5-0DQ%4R)(,S)81D]21%5-34E%4R)34$5#249)0T%,
M3%DL24%-3$]/2TE.1T9/4D%324U03$E35$E#``````,`$! ``````P`1$ ``
M```"`0D0`0```/L!``#W`0```0,``$Q:1G42HO:'_P`*`0\"%0*D`^0%ZP*#
M`% 3`U0"`&-H"L!S973N,@8`!L,"@S(#Q@<3`H.R,Q,/9C0/?Q"'-1$GN'!R
M<1(@!VT"@S8$UE$7A4UA= AP80705$,&``4$0V%P:0&0;/IS`H!]"H (SPG9
M`H *@8,-L0M@;F<Q,#,4( <+"A+R`= @22!A;9(@'%!O:PN 9R "$,,%P!J 
M9&]C=0> `C!0('=H:1&P( 1@<XT%0&,<4!'P;'D@', +$? &T&P'D2)(+C-4
M,G@@TT0A<&T(D'/,(BX*A0J%4W %D :0=R'P!T BT"P@#R$1`)!MBPM0! !T
M(? @97@+42IN&D!I`B @*1%H;XD'X'9I#;!O(&<2`/<@T!IP!X!D)H )\ 6@
M#;"3*J$*L&-K$@!I>BJ3"'1C+B:P;F0@=+YH"? I8QMP+* :<'8BP%<$( -2
M)\!O`8!W"L!E5RR@*? 1P60NAFX2`'<I!;!K<R3=5!' ;FOT('D(8"PD[ K[
M&3(?X=<:,2RQ!^!&(L!D`X$R1_<+9!<!'])#(> -P!?@!9#4:&X<06<BX$\-
MT"'P>P20,D5)`C BP 60!4!6G00`=0= &S #<&UU`P`+)C H\G,R12@R,3(`
M*2 S,3<M.39^, WP"U454CKP)48;X0`!/0```P#Q/PD$```#`"8```````,`
M-@```````@%'``$````X````8SU54SMA/2 [<#U);G1E;&QE8W0@5FED96\@
M.VP]34%)3$-/32TY-S T,#0Q,S4R,S):+38V-0`"`?D_`0```&$`````````
MW*= R,!"$!JTN0@`*R_A@@$`````````+T\]24Y414Q,14-4(%9)1$5/($-/
M3D9%4D5.0TE.1R]/53U)5D,M3EE#+T-./5)%0TE0245.5%,O0TX]34%45$A%
M5T8`````'@#X/P$````0````36%T=&AE=R!&96QD;6%N``(!^S\!````80``
M``````#<IT#(P$(0&K2Y" `K+^&"`0`````````O3SU)3E1%3$Q%0U0@5DE$
M14\@0T].1D5214Y#24Y'+T]5/4E60RU.64,O0TX]4D5#25!)14Y44R]#3CU-
M05142$571@`````>`/H_`0```! ```!-871T:&5W($9E;&1M86X`0 `',)"7
MFW'_0+P!0 `(,/#^YW'_0+P!`P`--/T_```"`10T`0```! ```!4E*' *7\0
M&Z6'" `K*B47'@`]``$````!``````````L`*0``````"P`C```````"`7\`
M`0```%@````\8SU54R5A/5\E<#U);G1E;&QE8W1?5FED96]?)6P]34%)3$-/
M32TY-S T,#0Q,S4R,S):+38V-4!M86EL8V]M+G9I9&5O8V]N9F5R96YC:6YG
(+F-O;3X`<UPQ
`
end

From rem-conf-request@es.net Fri Apr 04 11:57:50 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <08136-0@osi-east2.es.net>; Fri, 4 Apr 1997 11:44:01 -0800
Received: from ietf.org by osi-west.es.net with ESnet SMTP (PP);
          Fri, 4 Apr 1997 11:43:39 -0800
Received: from ietf.ietf.org by ietf.org id aa24878; 4 Apr 97 14:46 EST
To: rem-conf@es.net
Subject: Multicast Schedule for Memphis IETF
From: agenda@ietf.org
Date: Fri, 04 Apr 1997 14:46:13 -0500
Sender: scoya@ietf.org
Message-ID: <9704041446.aa24878@ietf.org>

	   Memphis IETF Multicast Guide (as of 03/28/97)


Following is the tentative schedule of plenary meetings and working
group sessions to be transmitted; to interpret the acronyms, see the
agenda (available via FTP from ds.internic.net as /ietf/0mtg-agenda.txt).
It is possible that this schedule will be modified.

MULTICAST GUIDE


Note that times are in US Central Time (CT). UTC (aka GMT)
also provided.


MONDAY      0930-1130   1300-1500   1530-1730    1930-2200
     (UTC)  1430-1630   1800-2000   2030-2230    0030-0300
==========+===========+===========+============+============+
 CHAN 1   | mobileip  | mboned    | icp-BOF    | mboned     |
==========+===========+===========+============+============+
 CHAN 2   | http      | tcpimp    | omarea     | http       |
==========+===========+===========+============+============+


TUESDAY     0900-1130   1300-1500   1530-1730
     (UTC)  1400-1630   1800-2000   2030-2230
==========+===========+===========+===========+
 CHAN 1   | ion       | ion       | idmr      |
==========+===========+===========+===========+
 CHAN 2   | mmusic    | rsvp      | issll     |
==========+===========+===========+===========+


WEDNESDAY  0900-1000   1015-1115   1300-1400   1415-1515   1545-1645
    (UTC)  1400-1500   1515-1615   1800-1900   1915-2015   2045-2145
=========+===========+===========+===========+===========+===========+
 CHAN 1  | avt       | otsv      | pppext    | ipcdn     | rsvp      |
=========+===========+===========+===========+===========+===========+
 CHAN 2  | ipsec     | ipsec     | issll     | issll     | mcwww-BOF |
=========+===========+===========+===========+===========+===========+

    WEDNESDAY (CON'T)  1700-1800   2000-2100   2100-2200
		(UTC)  2200-2300   0100-0200   0200-0300
	    =========+===========+===========+===========+
	     CHAN 1  | mmusic    | iab       | iahc      |
	    =========+===========+===========+===========+
	     CHAN 2  | xxxxxx    | avt       | avt        |
	    =========+===========+===========+===========+


THURSDAY    0900-1130   1300-1500    1530-1630     1630-1830
     (UTC)  1400-1630   1800-2000    2030-2130     2130-2330
==========+===========+===========+==============+============+
 CHAN 1   | idmr      | ipngwg    | presentation |open plenary|
==========+===========+===========+==============+============+
 CHAN 2   | tcpsat    | nfsv4-BOF |      "       |     "      |
==========+===========+===========+==============+============+


There will be no multicasting of sessions on Friday, April 11, 1997.


Each day's program may also be replayed by tape delay from: 2330
						     (UTC): 0430

Advice for remote participants:

Please keep your microphones muted and your video transmissions
disabled during the plenaries and working group sessions, unless
or until invited to respond by the chair of the session.

Vat users can disable reception of accidental sources of audio
multicasts (such as people who forget to mute their mics) by
clicking in the box next to that source's name.


NOTE: Due to the number of multicast sessions scheduled for the week,
      there will be NO rebroadcast of the IETF sessions. However, we
      anticipate ftp-able files being made available.

From rem-conf-request@es.net Fri Apr 04 12:39:49 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <00348-0@osi-east2.es.net>; Fri, 4 Apr 1997 12:28:40 -0800
Received: from mail1.isdnet.net (actually mail1.hol.fr) by osi-west.es.net 
          with ESnet SMTP (PP); Fri, 4 Apr 1997 12:28:16 -0800
Received: from LOCALNAME (ppp13.par.hol.fr [194.149.169.152]) 
          by mail1.isdnet.net (8.8.5/Havas On Line) with SMTP id WAA22442;
          Fri, 4 Apr 1997 22:27:48 +0200 (CEST)
Message-ID: <3345E1F9.529B@hol.fr>
Date: Fri, 04 Apr 1997 21:24:10 -0800
From: francois Haignere <francois.haignere@hol.fr>
Reply-To: francois.haignere@hol.fr
Organization: famille
X-Mailer: Mozilla 3.0 (Win16; I)
MIME-Version: 1.0
To: rem-conf@es.net, casner@precept.com, garys@pictel.com
CC: isabelle.haignere@issy.cnet.fr, francois.haignere@hol.fr
Subject: Liaison Statement from ITU
Content-Type: multipart/mixed; boundary="------------79B17BC55B1F"

This is a multi-part message in MIME format.

--------------79B17BC55B1F
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mail1.isdnet.net id WAA22442

Here you will find some document about a proposed liaison statement
between ITU and IETF. The chairman of the video subgroup is Mr Gary
SULLIVAN from PictureTel, he is now the chairman of the complete
corresponding ITU group (SG16-WP3).
I propose to add some short presentation of this document when
discussing the RTP payload formats on wenesday morning.
I thank you very much.


Isabelle HAIGNERE


FRANCE TELECOM/BD - CNET/DSE/SGV
38-40 rue du g=E9n=E9ral Leclercq
92131 Issy-Moulineaux
Tel : 33 1 45 29 40 08
Fax : 33 1 45 29 52 94
Email : isabelle.haignere@issy.cnet.fr

--------------79B17BC55B1F
Content-Type: application/octet-stream; name="LIAISON.DOC"
Content-Disposition: attachment; filename="LIAISON.DOC"
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAADAAAAAAA
AAAAEAAADQAAAAEAAAD+////AAAAAAsAAAD/////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
///////////////////////////////////cpWgAY+AMBAAAAABlAAAAAAAAAAAAAAAAAwAA
LwoAAAcUAAAAAAAAAAAAAAAAAAAAAAAALwcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAABAAAGYAAAAAEAAAZgAAAGYQAAAAAAAAZhAAAAAAAABmEAAAAAAAAGYQAAAAAAAA
ZhAAABQAAACQEAAAAAAAAJAQAAAAAAAAkBAAAAAAAACQEAAAAAAAAJAQAAAAAAAAkBAAAAoA
AACaEAAACgAAAJAQAAAAAAAACRMAADEAAACkEAAAAAAAAKQQAAAAAAAApBAAAAAAAACkEAAA
AAAAAKQQAAAAAAAApBAAAAAAAACkEAAAAAAAAKQQAAAAAAAABBEAAAIAAAAGEQAAAAAAAAYR
AAAAAAAABhEAAD0AAABDEQAA1AAAABcSAADUAAAA6xIAAB4AAAA6EwAAWAAAAJITAAB1AAAA
CRMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZhAAAAAAAACkEAAAAAAAAAAABgAHAAEAAQCkEAAA
AAAAAKQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKQQAAAAAAAApBAAAAAAAAAJEwAAAAAAAKQQ
AAAAAAAAZhAAAAAAAABmEAAAAAAAAKQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKQQAAAAAAAA
pBAAAAAAAACkEAAAAAAAAKQQAAAAAAAApBAAAAAAAABmEAAAAAAAAKQQAAAAAAAAZhAAAAAA
AACkEAAAAAAAAAQRAAAAAAAAAAAAAAAAAADA0v5uFiu8AXoQAAAIAAAAghAAAA4AAABmEAAA
AAAAAGYQAAAAAAAAZhAAAAAAAABmEAAAAAAAAKQQAAAAAAAABBEAAAAAAACkEAAAYAAAAKQQ
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABJVFUgVGVsZWNvbW11bmlj
YXRpb25zIFN0YW5kYXJkaXNhdGlvbiBTZWN0b3INU3R1ZHkgR3JvdXAgMTUsIFdvcmtpbmcg
UGFydHkgMTUvMQ1FeHBlcnRzIEdyb3VwIG9uIExvdyBCaXRyYXRlIFZpZGVvIFRlbGVwaG9u
eQ1OaWNlLCBGcmFuY2UsIEZlYnJ1YXJ5IDI1LTI4LCAxOTk3DQ0NDQ1UT6A6IAkJSUVURiBv
cmdhbmlzYXRpb24gLSBBVlQgq6BBdWRpbywgVmlkZW8gVHJhbnNwb3J0IFN1Ymdyb3VwoLsN
DVRJVExFoDogCVByb3Bvc2VkIExpYWlzb24gU3RhdGVtZW50IGNvbmNlcm5pbmcgSC4yNjMr
IHBhY2tldGlzYXRpb24uDQ1GT1KgOiAJCUluZm9ybWF0aW9uDQ1DT05UQUNUoDoNCUdhcnkg
U3VsbGl2YW4JCWdhcnlzQHBpY3RlbC5jb20NCQ0JSXNhYmVsbGUgSGFpZ25lcukJCWhhaWdu
ZXJlQGlzc3kuY25ldC5mcg0NDQ0JV2UgYXJlIGdsYWQgdG8gc2VlIHRoYXQgdGhlIElUVSB2
aWRlbyBzdGFuZGFyZHMgSC4yNjEgYW5kIEguMjYzLCBhbmQgdGhlIGF1ZGlvIHN0YW5kYXJk
IEcuNzIzLjEgaGF2ZSBiZWVuIHVzZWQgYnkgdGhlIElFVEYgZm9yIGFzIHZpZGVvIGFuZCBh
dWRpbyBjb21wcmVzc2lvbiB0b29scy4gVGhlIElFVEYgaGFzIGFkb3B0ZWQgdGhlc2UgdG9v
bHMgdGhyb3VnaCB0aGUgdXNlIG9mIHRoZSBwYXlsb2FkcyB0byBiZSBpbnRlcmZhY2VkIHdp
dGggUlRQIGFuZCB0byBiZSB0cmFuc21pdHRlZCBvbiBJbnRlcm5ldC4gTW9yZW92ZXIgc29t
ZSBleGNoYW5nZXMgaGF2ZSBhbHJlYWR5IGJlZW4gbWFkZSBiZXR3ZWVuIHRoZSBJVFUgb3Jn
YW5pc2F0aW9uIGFuZGQgSUVURiB3aXRoIHRoZSBhZG9wdGlvbiBvZiBSVFAtUmVhbC1UaW1l
IFRyYW5zcG9ydCBQcm90b2NvbCAtIGluIEguMjI1LjAgaW4gdGhlIEguMzIzIHN0YW5kYXJk
Lg0NVGhlIElUVSBpcyBkZXZlbG9waW5nIHNvbWUgbmV3IGltcHJvdmVtZW50cyB0byBhZGQg
dG8gdGhlIEguMjYzIHN0YW5kYXJkIGluIGl0cyCroEguMjYzK6C7IHN0YW5kYXJkaXNhdGlv
biBhY3Rpdml0eS4gVGhlc2Ugb3B0aW9uYWwgZW5oYW5jZW1lbnRzIGFyZSBwbGFubmVkIHRv
IHJlYWNoIKugZGV0ZXJtaW5lZKC7IHN0YXR1cyBpbiBNYXJjaCBvZiAxOTk3LiBTZXZlcmFs
IG9mIHRoZSBhbm5leGVzIGluIHRoZSBuZXcgZHJhZnQgb2YgdGhpcyBzdGFuZGFyZCBhZGRy
ZXNzIG5ldHdvcmtpbmcgcmVxdWlyZW1lbnRzLCBpbiBwYXJ0aWN1bGFyIEFubmV4IEugOiB0
aGUgc2xpY2Ugc3RydWN0dXJlZCBtb2RlLCBBbm5leCBOoDogdGhlIHJlZmVyZW5jZSBwaWN0
dXJlIHNlbGVjdGlvbiBtb2RlLCBBbm5leCBPoDogdGhlIFNOUiBhbmQgU3BhdGlhbCBhbmQg
VGVtcG9yYWwgU2NhbGFiaWxpdHkgbW9kZSwgYW5kIEFubmV4IFKgOiB0aGUgaW5kZXBlbmRl
bnRseSBzZWdtZW50ZWQgZGVjb2RpbmcgbW9kZS4NDUJlY2F1c2Ugb2Ygb3VyIGFyZWFzIG9m
IG11dHVhbCBpbnRlcmVzdCwgd2Ugd2ljaCB0byBjb25mZXIgd2l0aCB0aGUgSUVURiBpbiB0
aGUgZGV2ZWxvcG1lbnQgb2Ygb3VyIHN0YW5kYXJkcyB0b3dhcmRzIHRoZSBkZWZpbml0aW9u
IG9mIHRoZSBwYXlsb2FkcyBpbiB0aGUgq6BhdnSgOiBhdWRpbywgdmlkZW8gdHJhbnNwb3J0
IGdyb3VwoLsuDQ1UaGUgSVRVIGV4cGVydHMgd291bGQgbGlrZSB0byBiZSBpbnZvbHZlZCBp
biB0aGUgZGVmaW5pdGlvbiBvZiBpbnRlcmFjdGlvbnMgYmV0d2VlbiB0aGUgSC4yNjMrIGFu
ZCB0aGUgUlRQIHByb3RvY29sIHRvd2FyZCB0aGUgZGVmaW5pdGlvbiBvZiBhIGdvb2QgSC4y
NjMrIHBheWxvYWQgZm9ybWF0LiBXZSBob3BlIHRvIGNyZWF0ZSBhIGNsb3NlIGFuZCBwb3Np
dGl2ZSBjb2xsYWJvcmF0aW9uIGJldHdlZW4gSUVURiBhbmQgSVRVLg0VAKSCLqXGQaaJBaeJ
BaiJBamJBaoAACBkdSBwYXF1ZXQgZGFucyBsZSBHT0IgKGluZm9ybWF0aW9uIGlzc3VlIGR1
IGNvZGV1cikNClxwYXIge1xwbnRleHRccGFyZFxwbGFpblxmMSBcJ2I3XHRhYn19XHBhcmQg
XHFqXGZpLTI4M1xsaTI4M3tcKlxwbiBccG5sdmxibHRccG5mMVxwbnN0YXJ0MVxwbmluZGVu
dDI4M1xwbmhhbmd7XHBudHh0YiBcJ2I3fX17XGZzMjQgUiAoMiBiaXRzKSA6IGNoYW1wIHJc
J2U5c2VydlwnZTksIGRvaXQgXCdlYXRyZSBcJ2U5Z2FsIFwnZTAgMCwNClxwYXIge1xwbnRl
eHRccGFyZFxwbGFpblxmMSBcJ2I3XHRhYn19XHBhcmQgXHFqXGZpLTI4M1xsaTI4M3tcKlxw
biBccG5sdmxibHRccG5mMVxwbnN0YXJ0MVxwbmluZGVudDI4M1xwbmhhbmd7XHBudHh0YiBc
J2I3fX17XGZzMjQgSSAoMWJpdClcfjogdHlwZSBkZSBjb2RhZ2UgZGUgbFxycXVvdGUgaW1h
Z2UgKDA9aW50cmFcfjsgMT1pbnQAAwAAoQMAAKUDAACoAwAA6QMAAO4DAAAvBAAAMgQAAEQE
AABLBAAALwoAAEYKAAD9APr9+v36/fr9+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnUBAAVVgWMYAANjGAAACwADAAAuAwAA
UQMAAH4DAAChAwAAogMAAKMDAACkAwAApQMAAOgDAADpAwAALgQAAC8EAABDBAAARAQAAE4E
AABvBAAAcQQAAJsEAACcBAAAnQQAAJ4EAAByBgAAcwYAAHQIAAB1CAAAOAkAADkJAAAvCgAA
/gABcCMgAf4AAXAjIAH+AAFwIyAB/gABcCMgAf4AAXAj8AD+AAFwI/AA/gABcCPwAP4AAXAj
8AD+AAFwIyAB/gABcCMgAf4AAXAjIAH+AAFwIyAB/gABcCMgAf4AAXAjIAH+AAFwIyAB/gAB
cCMgAf4AAXAjIAH+AAFwIyAB/gABcCMgAf4AAXAjIAH+AAFwIyAB+wAGcCMgAfsAAXAjIAH7
AAZwIyAB+wABcCMgAfsAA3AjIAH7AAFwIyAB+wADcCMgAQAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAACAAAFAwABAAAcDgAPAAgAAQBLAA8AAAAAABoAAEDx/wIAGgAGTm9ybWFsAAIA
AAADAGEMBAAAAAAAAAAAAAAAAAAAAAAAAAAeAEFA8v+hAB4AEVBvbGljZSBwYXIgZOlmYXV0
AAAAAAAAAAAAAAAAAAAAAC8HAAAMAC8KAAAKAP////8BAAQg//8BAAAAAAAvBwAAAAAAAAAA
AAMAAEYKAAAGAAADAAAvCgAABwBgABpHYXRld2F5IDIwMDAgTGljZW5zZWQgVXNlchhDOlxJ
SFxOb3JtZXNcTGlhaXNvbi5kb2MaR2F0ZXdheSAyMDAwIExpY2Vuc2VkIFVzZXIOQTpcTGlh
aXNvbi5kb2P/QEhQIExhc2VySmV0IDRTaSBNWABcXERhaW1caHAyNTVlAEhQUENMNU1TAEhQ
IExhc2VySmV0IDRTaSBNWABIUCBMYXNlckpldCA0U2kgTVgAAAAAAAAAAAAAAAAAAAAEAQSU
AEAAA3cABAEACQAAAAAAAAABAAkBWAIBAAIAWAIEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAA
AAAAAQBAAE1TVUROA0hQIExhc2VySmV0IDRTaSBNWAAAAAAAAAAAAAAAAAAA5QEAAA0BAAA7
AQAAAAAEAGQACgAAAEhQIExhc2VySmV0IDRTaSBNWAAAAAAAAAAAAAAAAAAAAAQBBJQAQAAD
dwAEAQAJAAAAAAAAAAEACQFYAgEAAgBYAgQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAB
AEAATVNVRE4DSFAgTGFzZXJKZXQgNFNpIE1YAAAAAAAAAAAAAAAAAADlAQAADQEAADsBAAAA
AAQAZAAKAAAAAwABAKUAAAAvBwAADAABAAEApQAAAAUAAAClAAAAMQAVFpABAABUaW1lcyBO
ZXcgUm9tYW4ADBaQAQIAU3ltYm9sAAsmkAEAAEFyaWFsACIABAAxCIgYAADEAgAAqQEAAAAA
aTwTpmk8E6ZlPBOmAgAAAAAACQEAAOwFAAABAAMAAAAEAIMQDAAAAAAAAAAAAAAAAQABAAAA
AQAAAAAAAABZAgAAAAB1AAAALUlUVSBUZWxlY29tbXVuaWNhdGlvbnMgU3RhbmRhcmRpc2F0
aW9uIFNlY3RvcgAAABpHYXRld2F5IDIwMDAgTGljZW5zZWQgVXNlchpHYXRld2F5IDIwMDAg
TGljZW5zZWQgVXNlcgAAAAAAAAAAAABvcm1lIGguMjYzIChzYW5zIGxlcyBvcHRpb25zIHN1
cHBsXCdlOW1lbnRhaXJlcyBkdWVzIFwnZTAgbFxycXVvdGUgYXBwcm9jaGUgXGxkYmxxdW90
ZSBcfkguMjYzK1x+XHJkYmxxdW90ZSApLCBsXHJxdW90ZSBvcHRpb24gYW5uZXhHIA0KXGxk
YmxxdW90ZSBcflBCLWZyYW1lXH5ccmRibHF1b3RlICBlc3QgdmFsaWRcJ2U5ZS4gTGEgcGFx
dWV0aXNhdGlvbiBzZSBmYWl0IGF1IG5pdmVhdSBtYWNyby1ibG9jIHBvdXIgbGUgZmx1eCBo
LjI2My4NClxwYXIgfVxwYXJkIFxxaiB7XGZzMjQgDQpccGFyIHtccG50ZXh0XHBhcmRccGxh
aW5cZjEgXCdiN1x0YWJ9fVxwYXJkIFxxalxmaS0yODNcbGkyODN7XCpccG4gXHBubHZsYmx0
XHBuZjFccG5zdGFydDFccG5pbmRlbnQyODNccG5oYW5ne1xwbnR4dGIgXCdiN319e1xmczI0
IEYgKDFiaXQpXH46IGluZGlxdWUgbGUgbW9kZSAwPW1vZGUgQVx+OyAxPW1vZGUgQiBvdSBD
OyBkYW5zIGNlIGNhcyBGPTENClxwYXIge1xwbnRleHRccGFyZFxwbGFpAQAAAAIAAAADAAAA
BAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAP7////9////DwAAAP7///8XAAAA/v//////
///////////////////////////////////+////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
//////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAA
AQAAAEsAAAABAAAAAAAAAJAgAAABAAAAFgAFAf//////////AQAAAAAJAgAAAAAAwAAAAAAA
AEYAAAAAAFxfYxYrvAHA0v5uFiu8AQ4AAAAABAAAAAAAAFcAbwByAGQARABvAGMAdQBtAGUA
bgB0AAAAQADsl0gAQTpcAEgATm9ybWVzAAAAAJYAAAAmEgAAUhoAAAAAAAAaAAIBAgAAAAMA
AAD/////AAAAAAAAAAAAAAQAAAAAAAAAAACDLsdBAQAAAAkAAAAJAQAAAAAAAAcUAAAAAAAA
AQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAAAAUAAAAAAAAAAAQAAAkB
AABU/BEBIAAAABIAAgH///////////////8AAAAAAAAAAAAAAAD/////DAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAagAAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkA
bwBuAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAKAACAf////8EAAAA/////wAAAAAAAAAA
AAAAAP9/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAMAgAAJwAcAAEAAAD+////AwAAAAQA
AAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAD+////DAAAAA0AAAAOAAAADwAAAP7/////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////AQD+/wMKAAD/////AAkCAAAAAADAAAAAAAAARhgAAABEb2N1bWVudCBN
aWNyb3NvZnQgV29yZAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjYA9DmycQAA
AAAAAAAAAAAAANDPEeChsRrhAAAAAAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAAAAAA
AAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAADcAQAAEgAAAAEAAACYAAAAAgAAAKAAAAADAAAA
2AAAAAQAAADkAAAABQAAAAgBAAAGAAAAFAEAAAcAAAAgAQAACAAAADQBAAAJAAAAWAEAABIA
AABkAQAACgAAAIwBAAALAAAAmAEAAAwAAACkAQAADQAAALABAAAOAAAAvAEAAA8AAADEAQAA
EAAAAMwBAAATAAAA1AEAAAIAAADkBAAAHgAAAC4AAABJVFUgVGVsZWNvbW11bmljYXRpb25z
IFN0YW5kYXJkaXNhdGlvbiBTZWN0b3IAQAAeAAAAAQAAAAALRwAeAAAAGwAAAEdhdGV3YXkg
MjAwMCBMaWNlbnNlZCBVc2VyAPAeAAAAAQAAAADURgAeAAAAAQAAAAAAAAAeAAAACwAAAE5v
cm1hbC5kb3QAAB4AAAAbAAAAR2F0ZXdheSAyMDAwIExpY2Vuc2UFAEQAbwBjAHUAbQBlAG4A
dABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAP//
/////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsAAAAUAQAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAEAAAAC1c3VnC4bEJOXCAArLPmu
MAAAAOQAAAAIAAAAAQAAAEgAAAAPAAAAUAAAAAQAAAB0AAAABQAAAHwAAAAGAAAAhAAAAAsA
AACMAAAAEAAAAJQAAAAMAAAAnAAAAAIAAADkBAAAHgAAABsAAABHYXRld2F5IDIwMDAgTGlj
ZW5zZWQgVXNlcgAAAwAAAAAwAAADAAAADAAAAAMAAAADAAAACwAAAAAAAAALAAAAAAAAAAwQ
AAACAAAAHgAAAC4AAABJVFUgVGVsZWNvbW11bmljYXRpb25zIFN0YW5kYXJkaXNhdGlvbiBT
ZWN0b3IAAwAAAAAAAAAAACBcJ2I3XHRhYn19XHBhcmQgXHFqXGZpLTI4M1xsaTI4M3tcKlxw
biBccG5sdmxibHRccG5mMVxwbnN0YXJ0MVxwbmluZGVudDI4M1xwbmhhbmd7XHBudHh0YiBc
J2I3fX17XGZzMjQgQSAoMWJpdClcfjogaW5kaXF1ZSBsXHJxdW90ZSB1dGlsaXNhdGlvbiBv
dSBub24gZGUgbFxycXVvdGUgb3Bpb24gXGxkYmxxdW90ZSBcfmFkdmFuY2VkIHByZWRpY3Rp
b24gbW9kZVx+XHJkYmxxdW90ZSANCiAoMD1vZmYsIDE9b24pIChpbmZvcm1hdGlvbiBpc3N1
ZSBkdSBjb2RldXIgaW5kaXF1XCdlOWUgZGFucyBsZSBcbGRibHF1b3RlIFx+UFRZUEVcflxy
ZGJscXVvdGUgIGRlIEguMjYzKSwNClxwYXIge1xwbnRleHRccGFyZFxwbGFpblxmMSBcJ2I3
XHRhYn19XHBhcmQgXHFqXGZpLTI4M1xsaTI4M3tcKlxwbiBccG5sdmxibHRccG5mMVxwbnN0
YXJ0MVxwbmluZGVudDI4M1xwbmhhbmd7XHBudHh0YiBcJ2I3fX17XGZzMjQgSE1WMSxWTVYx
ICg3Yml0cyBjaGFjdW4pOiBwclwnZTkNCmRpY3RldXJzIGR1IHZlY3RldXIgbW91dmVtZW50
IHBvdXIgbGUgcHJlbWllciBtYWNyby1ibG9jIGR1IHBhcXVldCBzaSB2ZWN0ZXVyIDE2KjE2
LCBwb3VyIGxlIHNvdXMtYmxvYyAxIGR1IG1hY3JvLWJsb2Mgc2kgdmVjdGV1cnMgOCo4LiBI
TVYxIGV0IFZNVjEgc29udCBlbiBjb21wbFwnZTltZW50IFwnZTAgMi4NClxwYXIge1xwbnRl
eHRccGFyZFxwbGFpblxmMSBcJ2I3XHRhYn19XHBhcmQgXHFqXGZpLTI4M1xsaTI4M3tcKlxw
biBccG5sdmxibHRccG5mMVxwbnN0YXJ0MVxwbmluZGVudDI4M1xwbmhhbmd7XHBudHh0YiBc
J2I3fX17XGZzMjQgSE1WMixWTVYyIDogcHJcJ2U5ZGljdGV1cnMgZHUgdmVjdGV1ciBtb3V2
ZW1lbnQgcG91ciBsZSBzb3VzLWJsb2MgMy4gQ2VzIGNoYW1wcyBuZSBzb250IHBhcyB1dGls
aXNcJ2U5cyBzaSBsXHJxdW90ZSBvcHRpb24gDQoNClxwYXIge1xwbnRleHRcdGFifX1ccGFy
ZCBccWp7XCpccG4gXHBubHZsY29udFxwbmYxXHBuc3RhcnQxXHBuaW5kZW50MjgzXHBuaGFu
Z3tccG50eHRiIFwnYjd9fXtcZnMyNCANClxwYXIge1xwbnRleHRcdGFifX1ccGFyZCBccWpc
ZmktMjgzXGxpMjgze1wqXHBuIFxwbmx2bGNvbnRccG5mMVxwbnN0YXJ0MVxwbmluZGVudDI4
M1xwbmhhbmd7XHBudHh0YiBcJ2I3fX17XGZzMjQgDQpccGFyIH1ccGFyZCBccWoge1xmczI0
IEZsdXggSC4yNjNcfjogbGUgZmx1eCBILjI2MyBlc3QgZnJhZ21lbnRcJ2U5IHN1ciBsYSBi
YXNlIG1hY3JvLWJsb2NzIGV0IGNvbnRpZW50IHVuIG5vbWJyZSBlbnRpZXIgZGUgbW90cyBk
ZSAzMiBiaXRzLiANClxwYXIgfVxwYXJkIFxxaiB7XGZzMjQgDQpccGFyIA0KXHBhciANClxw
YXIgfVxwYXJkIFxxaiB7XGJcZnMyNCBEZXNjcmlwdGlvbiBkZXMgaW50ZXJmYWNlc1x+Og0K
XHBhciANClxwYXIgSW50ZXJmYWNlIGNvZGV1ciAtZW50aXRcJ2U5IFxsZGJscXVvdGUgXH5w
YXlsb2Fkc1x+XHJkYmxxdW90ZSAgZXQgbXVsdGlwbGV4IFxsZGJscXVvdGUgXH5ydHBcflxy
ZGJscXVvdGUgIDoNClxwYXIgDQpccGFyIH1ccGFyZCBccWoge1xmczI0IExccnF1b3RlIFwn
ZTljcml0dXJlIGRlcyBwYXlsb2FkcyBhdSBjb2RldXIgc2UgZFwnZTlmaW5pdCBwYXIgXGxk
YmxxdW90ZSBcfmxpcmVkYXRhKCZpbmZvMSlcflxyZGJscXVvdGUgIG9cJ2Y5IGNldHRlIGZv
bmN0aW9uIGVzdCBhcHBlbFwnZTllIHBhciBsYSBjb3VjaGUgZGUgY29tbXVuaWNhdGlvbiwg
XGxkYmxxdW90ZSBcfmxpcmVkYXRhKCZpbmZvMSlcflxyZGJscXVvdGUgDQogYXBwZWxsZSB1
bmUgcm91dGluZSBDL0MrKyBcbGRibHF1b3RlIFx+UEwoJmluZm8xKVx+XHJkYmxxdW90ZSAg
cXVpIGVsbGUtbVwnZWFtZSBhcHBlbGxlIFxsZGJscXVvdGUgXH5jb2RldXIoJmluZm8yKVx+
XHJkYmxxdW90ZSAsIGNldHRlIGZvbmN0aW9uIHZhIGxpcmUgZW4gZmFpdCB1biBlc3BhY2Ug
bVwnZTltb2lyZSBsb2NhbGlzXCdlOSBwYXIgbGUgcG9pbnRldXIgXGxkYmxxdW90ZSBcfiZp
bmZvMlx+XHJkYmxxdW90ZSANCiBhdmVjIGRlcyBpbmZvcm1hdGlvbnMgY29uc3RpdHV0aXZl
cyBkXHJxdW90ZSB1biBvdSBwbHVzaWV1cnMgcGFxdWV0cywgdW4gcGFxdWV0IHNlcmEgbHUg
Z3JcJ2UyY2UgXCdlMCBcbGRibHF1b3RlIFx+JmluZm8yXH5ccmRibHF1b3RlICwgdHJhaXRc
J2U5IHBhciBsYSBmb25jdGlvbiBcbGRibHF1b3RlIFx+UEwoJmluZm8xKVx+XHJkYmxxdW90
ZSAgZXQgc3RvY2tcJ2U5IGRhbnMgXGxkYmxxdW90ZSBcfiZpbmZvMVx+XHJkYmxxdW90ZSAu
IA0KDQpccGFyIH1ccGFyZCBccWoge1xmczI0IENlIG1cJ2U5Y2FuaXNtZSBmb25jdGlvbm5l
IHBhcXVldCBwYXIgcGFxdWV0LCB1biB0ZXN0IGVzdCBuXCdlOWNlc3NhaXJlIHBvdXIgdGVz
dGVyIHNpIGxhIG1cJ2U5bW9pcmUgcmVtcGxpZSBwYXIgbGUgY29kZXVyIGVzdCB2aWRlIG91
IG5vbiB9e1xpXGZzMjQgKG91IHBsYWNlciBjZSB0ZXN0ID8pLiB9e1xmczI0IExlIGNvZGV1
ciBxdWFudCBcJ2UwIGx1aSByZW1wbGkgbFxycXVvdGUgZXNwYWNlIG1cJ2U5DQptb2lyZSBx
dWkgbHVpIGVzdCBhbGxvdVwnZTkgXCdlMCBwYXJ0aXIgZHUgcG9pbnRldXIgXGxkYmxxdW90
ZSBcfiZpbmZvMlx+XHJkYmxxdW90ZSAuDQpccGFyIH1ccGFyZCBccWoge1xmczI0IGluZm8x
IGVzdCBsYSBzdHJ1Y3R1cmUgZFxycXVvdGUgaW50ZXJmYWNlIA0KXHBhciB9XHBhcmQgXHFq
IHtcYlxmczI0IA0KXHBhciBJbnRlcmZhY2UgZFwnZTljb2RldXIgLWVudGl0XCdlOSBcbGRi
bHF1b3RlIFx+cGF5bG9hZHNcflxyZGJscXVvdGUgIGV0IG11bHRpcGxleCBcbGRibHF1b3Rl
IFx+cnRwXH5ccmRibHF1b3RlICA6DQpccGFyIA0KXHBhciANClxwYXIgDQpccGFyIA0KXHBh
ciBEZXNjcmlwdGlvbiBkZXMgdFwnZTJjaGVzXH46DQpccGFyIA0KXHBhciBcJ2U5Y3JpdHVy
ZSBldCBmYWJyaWNhdGlvbiBkZXMgcGF5bG9hZHMgOg0KXHBhciB9XHBhcmQgXHFqIHtcZnMy
NCBMZXMgbW9kZXMgQiBldCBDIHNvbnQgdXRpbGVzIGxvcnNxdWUgbGEgdGFpbGxlIGRccnF1
b3RlIHVuIEdPQiBlc3Qgc3VwXCdlOXJpZXVyZSBcJ2UwIGxhIHRhaWxsZSBkXHJxdW90ZSB1
biBwYXF1ZXQgclwnZTlzZWF1LCBkYW5zIGNlIGNhcyBsZSBkXCdlOWNvdXBhZ2UgZW4gbWFj
cm8tYmxvY3MgZXN0IHBsdXMgYXBwcm9wcmlcJ2U5LiBUb3V0ZWZvaXMgbm91cyBhdm9ucyB2
dSBkYW5zIGxlIHBhcmFncmFwaGUgDQpcbGRibHF1b3RlIFx+ZGVzY3JpcHRpb24gZGUgbGEg
Zm9uY3Rpb24gcGF5bG9hZHNcflxyZGJscXVvdGUgIHF1ZSBsXHJxdW90ZSBhcHJvY2hlIG1v
ZGUgQSBlc3QgY29tcGF0aWJsZSBwb3VyIGxlIHJcZCBVc2VyAAAeAAAAAgAAADIAMDAeAAAA
HgAAAE1pY3Jvc29mdCBXb3JkIGZvciBXaW5kb3dzIDk1AAAAQAAAAAAAAAAAAAAAQAAAAABe
cscVK7wBQAAAAAB2f1YWK7wBQAAAAAB2f1YWK7wBAwAAAAEAAAADAAAACQEAAAMAAADsBQAA
AwAAAAAAAADQzxHgobEa4QAAAAAAAAAAAAAAAAAAAAA+AAMA/v8JAAYAAAAAAAAAAAAAAAEA
AAAMAAAA/v8AAAQAAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAA
5AAAAAgAAAABAAAASAAAAA8AAABQAAAABAAAAHQAAAAFAAAAfAAAAAYAAACEAAAACwAAAIwA
AAAQAAAAlAAAAAwAAACcAAAAAgAAAOQEAAAeAAAAGwAAAEdhdGV3YXkgMjAwMCBMaWNlbnNl
ZCBVc2VyAAADAAAAADAAAAMAAAAMAAAAAwAAAAMAAAALAAAAAAAAAAsAAAAAAAAADBAAAAIA
AAAeAAAALgAAAElUVSBUZWxlY29tbXVuaWNhdGlvbnMgU3RhbmRhcmRpc2F0aW9uIFNlY3Rv
cgADAAAAAAAAAAAA0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAA
AAA=
--------------79B17BC55B1F--


From rem-conf-request@es.net Fri Apr 04 14:39:46 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <01088-0@osi-east2.es.net>; Fri, 4 Apr 1997 14:31:15 -0800
Received: from gateway-gw.pictel.com (actually gateway.pictel.com) 
          by osi-west.es.net with ESnet SMTP (PP);
          Fri, 4 Apr 1997 14:22:01 -0800
Received: from roadrunner.pictel.com 
          by gateway-gw.pictel.com (4.1/cf.gw.940128.1740) id AA21071;
          Fri, 4 Apr 97 17:21:15 EST
Received: from python.pictel.com by roadrunner.pictel.com (4.1/runner.910925.1) 
          id AA15734; Fri, 4 Apr 97 17:20:58 EST
Received: by python.pictel.com (5.x/SMI-SVR4) id AA21866;
          Fri, 4 Apr 1997 17:19:13 -0500
Date: Fri, 4 Apr 1997 17:19:13 -0500
From: garys@pictel.com (Gary Sullivan)
Message-Id: <9704042219.AA21866@python.pictel.com>
To: Donald_Craig@adc.sel.sony.com, Toerless.Eckert@Informatik.Uni-Erlangen.de, 
    rem-conf@es.net, van@ee.lbl.gov
Subject: Re: Video Format (definition of CIF)
Cc: webberr@es.net


Regarding the definition of CIF:

The attached prior conversation was passed on to me regarding
the definition of CIF as used in Recommendations H.261 and H.263,
and its relationship to Recommendation 601.  My understanding is
that Toerless Eckert is not quite right about the definition of
CIF, but he's pretty close.

Actually, the H.261 and H.263 standards define the square-pixel
area equivalent of the image region covered by a 352x288 CIF
picture to be 384x288, not 375x288.  The explanation is a bit
complex, but that is the bottom line.

(I am the Rapporteur in charge of Advanced Video Coding in the
ITU-T.  With the help of Associate Rapporteur Keiichi Hibi and
other experts, I am responsible for H.261 and H.263, and thus
I am the keeper of the flame at the heart of the canonical
CIF magic lantern. :-)

Incidentally, you may all be happy to hear that new "H.263+"
optional extensions to H.263 are now being standardized in the ITU
which will allow the use of square-pixel formats and flexible
picture sizes.  For further information on that topic, see
  ftp://standard.pictel.com/video-site/h263plus


H.261, for example, says there are "352 pels per line, 288 lines"
and that the "picture area covered by these numbers of pels and
lines has an aspect ratio of 4:3" ...   (Therefore, each pixel has
width:height aspect ratio of 12:11.)

H.263 says basically the same thing, and it in fact explicitly
says the pixel aspect ratio is 12:11.

The references made in H.261 and H.263 to Recommendation 601 are
*not* used to define the pixel aspect ratio.  That is defined
explicitly in H.261 and H.263 themselves.

Thus for a square-pixel image which is 288 lines tall to represent
a CIF image, it should be precisely (352*12)/11 = 384 pixels wide.

We had a discussion of this topic in the ITU about a year ago,
and this was the conclusion of that discussion.  I won't go into
the details of the entire history.  However, I will point out
that Recommendation 601 is not itself exactly where you would look
to find its pixel aspect ratio either.  Recommendation 601 defines
a digital sampling of an analog signal at a certain frequency
(6.75 and 3.375 MHz).  Therefore it is the definition of the
underlying analog signal that defines what you will get from the
sampling.  The timing of that analog signal differs depending on
whether it is defined for a 625 or 525 line system.  The 720 pixel
lines of Recommendation 601 somewhat overscan the actual 4:3 picture
content.  In fact the picture content is about 704 pixels wide, and
therefore the pixels are at least very close to being 12:11.  In
order to resolve the problem of trying to figure out what *precisely*
was the aspect ratio of a Recommendation 601 pixel, the people who
wrote H.261 and H.263 found that whatever it was, it was very close
to 12:11 and that if we *define* it to be 12:11, it will henceforth
be simpler to deal with than if we just carry it over "normatively"
>from Recommendation 601.  H.261 and H.263 do contain a "note"
section that say that the CIF sampling has "a simple relationship"
with Recommendation 601, but it does not exactly use Recommendation
601 to define CIF (except for the color space and scaling).

In short, do *not* look in Recommendation 601 to find the
definition of CIF.  It is not there.  It is in H.261 and H.263.
I believe the only part of the definition of CIF that uses
Recommendation 601 is the definition of the color space and scaling.


Best Wishes,

Gary Sullivan  Tel: +1 508-623-4324 Fax: 749-2804 <garys@pictel.com>
PictureTel Corp. M/S 635, 100 Minuteman Road, Andover MA 01810  USA

(The usual disclaimers apply.)

-----------------------------------------------------------
>Return-Path: <rem-conf-request@es.net>
>X-Sender: dmc@sosfc.adc.sel.sony.com
>Date: Thu, 03 Apr 1997 12:30:48 -0800
>To: Toerless Eckert <Toerless.Eckert@Informatik.Uni-Erlangen.de>,
>        van@ee.lbl.gov (Van Jacobson)
>From: Donald Craig <Donald_Craig@adc.sel.sony.com>
>Subject: Re: Video Format
>Cc: rem-conf@es.net
>
>This is pretty good, an opportunity to step into a hissing match
>over CIF, of all the disgusting lo-res blind-leading-the-blind
>flickery magic lantern formats there ever was...(Just kidding, guys)
>
>However, I happen to have a copy of ITU-R BT601-4 sitting on a
>colleague's desk (thanks, Hugo), and to clarify Toerless's
>last paragraph (just the 601 bits, I am NOT a CIF expert):
>
>	CCIR-601 is officially known these days as ITU-R BT601-4.
>	Total samples per line is 858 for 525/60 and 864 for 625/50.
>	Active picture samples per line is 720 for both 525/60 and 625/50.
>
>	For 525/60 (and drawing on SMPTE 125M-1995), active lines
>	are 20 to 263 inclusive for field 1, and 283 to 525 inclusive
>	for field 2, giving a vertical picture resolution of 487 lines
>	circa 30 times a second.  (I don't have the EBU 625 spec handy,
>	so I won't pontificate on that exact vertical picture resolution.)
>
>These specifications (particularly the active lines one) are much abused
>in practice, and if you go someplace like Japan you'll get to see nominal
>4:3 aspect ratio happily displayed on your Bazooka TV in 16:9, with many
>little fat people wandering around...
>
>All this, and much, much, more is in a handy book snappily titled:
>"Standards for Advanced Television and High Definition Production with
>Supplemental Standards including Ancillary Audio", ISBN 0-940690-31-4,
>available from:	The Society of Motion Picture and Television Engineers
>			595 W. Hartsdale Avenue
>			White Plains, New York  10607
>Phone: (914) 761-1100
>Also on the web at:	www.smpte.org
>
>cheers,
>Don Craig
>(Definitely not speaking for his current employer, who probably makes
>a CIF something, somewhere...)
>----------------------------------------------------------------------------
>At 06:54 PM 4/2/97 +0200, Toerless Eckert wrote:
>>> > i.e.: a CIF-picture is supposed to transport a video picture
>>> > that has a square-pixel resolution of 375x288. This is often not
>>> > done correctly (i.e.: i think vic and a lot of other
>>> > videoconferencing applications actually transport square
>>> > pixel-video-content in the 352x288 resolution).
>>> 
>>> Toerless,
>>> 
>>> Where did you obtain this rather amazing & totally incorrect
>>> piece of information?  Please read the third paragraph of
>>> section 3.1 of the ITU H.261 standard.  It's the one that
>>> starts
>>> 
>>>    "In the first format (CIF), the luminance sampling structure is
>>>     352 pels per line, 288 lines per picture ..."
>>> 
>>> I don't know about "a lot of other videoconferencing applications" but
>>> vic follows the ITU standard *very* closely & its data stream has
>>> successfully interoperated with a number of hardware codecs.
>>
>>I think what i wrote is correct, it's only incomplete without the
>>paragraph that it was written as a reply to:
>>
>>CIF is 352x288 right, but these 352x288 pixels are in intention not
>>square-pixel, which is something that people doing H.261 and other
>>CIF-resolution software on computers often miss. the 352 pixels per
>>line are 1/2 of 704 pixels which is the active-video resolution of
>>CCIR-601 video lines. The total resolution of a CCIR-601 video scanline
>>is 720 pixels.CCIR-601 video is expected to be displayed with an
>>aspect ratio of 4:3, thus the video picture conveyed in 720x576 pixels
>>is not square-pixel. 768x576 would be square-pixel. Thus the square-pixel
>>resolution of 375 in a CIF-picture. Instead of scaling the encoded
>>352 (non-square) video pixels horizontally to be 375, people often already
>>encode square-pixel information into the 352 pixel, which leads to
>>problems when communicating between systems that do (correctly_) not
>interpret
>>the 352 pixels as square-pixel.
>>
>>Anything wrong with this ?
>>
>>Toerless
>>
>>
>
>


From rem-conf-request@es.net Sat Apr 05 01:06:13 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <05480-0@osi-east2.es.net>; Sat, 5 Apr 1997 00:58:49 -0800
Received: from faui40.informatik.uni-erlangen.de by osi-west.es.net 
          with ESnet SMTP (PP); Sat, 5 Apr 1997 00:58:26 -0800
Received: from faui45r.informatik.uni-erlangen.de (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) 
          by faui40.informatik.uni-erlangen.de (8.8.5/8.0.5-FAU) with ESMTP 
          id KAA13302; Sat, 5 Apr 1997 10:58:17 +0200 (MET DST)
From: Toerless Eckert <Toerless.Eckert@Informatik.Uni-Erlangen.de>
Message-Id: <199704050858.KAA13302@faui40.informatik.uni-erlangen.de>
Subject: Re: Video Format (definition of CIF)
To: garys@pictel.com (Gary Sullivan)
Date: Sat, 5 Apr 1997 10:58:14 +0200 (MET DST)
Cc: Donald_Craig@adc.sel.sony.com, Toerless.Eckert@Informatik.Uni-Erlangen.de, 
    rem-conf@es.net, van@ee.lbl.gov, webberr@es.net
In-Reply-To: <9704042219.AA21866@python.pictel.com> from "Gary Sullivan" at Apr 4, 97 05:19:13 pm
Organisation: CSD IMMD IV, University of Erlangen, Germany
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Thanks a lot for the explanation.

From rem-conf-request@es.net Sat Apr 05 09:52:18 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <11416-0@osi-east2.es.net>; Sat, 5 Apr 1997 09:48:53 -0800
Received: from mail2.isdnet.net (actually mail2.hol.fr) by osi-west.es.net 
          with ESnet SMTP (PP); Sat, 5 Apr 1997 09:48:47 -0800
Received: from LOCALNAME (ppp81.par.hol.fr [194.149.172.160]) 
          by mail2.isdnet.net (8.8.5/Havas On Line) with SMTP id TAA08457;
          Sat, 5 Apr 1997 19:48:02 +0200 (MET DST)
Message-ID: <33470E04.26D3@hol.fr>
Date: Sat, 05 Apr 1997 18:44:21 -0800
From: francois Haignere <francois.haignere@hol.fr>
Reply-To: francois.haignere@hol.fr
Organization: famille
X-Mailer: Mozilla 3.0 (Win16; I)
MIME-Version: 1.0
To: karl@precept.com, rja@corp.home.net, casner@precept.com, rem-conf@es.net
CC: garys@pictel.com, haignere@issy.cnet.fr, francois.haignere@hol.fr
Subject: Liaison statement from LBC
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mail2.isdnet.net id 
                      TAA08457

Hereafter you will find the last version of the liaison statement from
ITU to IETF,
this version is a text one. I attach also a *.doc file of the same
version.=20

Isabelle HAIGNERE

-------------------------------------------------------------------------=
----
ITU Telecommunications Standardisation Sector			LBC-97-091
Study Group 15, Working Party 15/1
Experts Group on Low Bitrate Video Telephony
Nice, France, February 25-28,  1997


TO :		IETF organisation - AVT "Audio, Video Transport" Subgroup.

TITLE :	Liaison Statement concerning H.263+ packetisation.

SOURCE :	Richard Schaphorst, Rapporteur for Very Low Bitrate Video
Telephony
(Question 2/15)

PURPOSE :	Liaison Statement

APPROVAL: Approved at the Rapporteur=92s Group meeting

CONTACTS :=20

Gary Sullivan, H.263+ Chairman/Editor		garys@pictel.com

Isabelle Haigner=E9					haignere@issy.cnet.fr


We are glad to see that the ITU video standards H.261 and H.263, and the
audio standard G.723.1 have been used by the IETF for video and audio
compression tools. The IETF has adopted these tools through the use of
the payloads to be interfaced with RTP and to be transmitted on the
Internet.  Moreover some exchanges have already been made between the
ITU organization and IETF with the adoption of RTP-Real-Time Transport
Protocol - into H.225.0 for the H.323 standard.

The ITU is developing some new improvements to add to the H.263 standard
in its =93H.263+=94 standardization activity.  These optional enhancement=
s
are planned to reach =93determined=94 status in March of 1997. Several of
the annexes in the new draft of this standard address networking
requirements=97in particular Annex K: the Slice Structured mode,  Annex N=
:
the Reference Picture Selection mode, Annex O: the Temporal, SNR and
Spatial Scalability mode, and Annex R: the Independently Segmented
Decoding mode. =20

Because of our areas of mutual interest, we wish to confer with the IETF
in the development of our standards towards the definition of the
payloads in the =AB avt : audio, video transport subgroup =BB.

The ITU experts would like to be involved in the definition of
interactions between the H.263+ and the RTP protocol toward the
definition of a good H263+ payload format.  We hope to create a close
and positive collaboration between IETF and ITU.

From rem-conf-request@es.net Sun Apr 06 05:42:59 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <21420-0@osi-east2.es.net>; Sun, 6 Apr 1997 05:39:35 -0700
Received: from netman.iscs.nus.sg by osi-west.es.net with ESnet SMTP (PP);
          Sun, 6 Apr 1997 05:39:26 -0700
Received: from decunx.iscs.nus.sg (qinpeng@decunx.iscs.nus.sg [137.132.87.9]) 
          by netman.iscs.nus.sg (8.8.5/8.8.5) with ESMTP id UAA27169 
          for <rem-conf@es.net>; Sun, 6 Apr 1997 20:39:20 +0800 (GMT+0800)
Received: (from qinpeng@localhost) by decunx.iscs.nus.sg (8.8.5/8.8.5) 
          id UAA16637 for rem-conf@es.net; Sun, 6 Apr 1997 20:39:18 +0800 (SST)
From: JoM <qinpeng@iscs.nus.sg>
Message-Id: <199704061239.UAA16637@decunx.iscs.nus.sg>
Subject: Subscribe
To: rem-conf@es.net
Date: Sun, 6 Apr 1997 20:39:18 +0800 (SST)
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

subscribe

From rem-conf-request@es.net Sun Apr 06 05:48:39 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <21474-0@osi-east2.es.net>; Sun, 6 Apr 1997 05:45:11 -0700
Received: from smtp.algonet.se (actually tomei.algonet.se) by osi-west.es.net 
          with ESnet SMTP (PP); Sun, 6 Apr 1997 05:45:02 -0700
Received: (qmail 17702 invoked from network); 6 Apr 1997 12:46:19 -0000
Received: from sleipner.algonet.se (194.213.74.40) by tomei.algonet.se 
          with SMTP; 6 Apr 1997 12:46:19 -0000
Date: Sun, 6 Apr 1997 14:46:42 +0200 (MET DST)
From: Algonet Staff / Dennis Wennstrom <dew@algonet.se>
To: rem-conf@es.net
Message-ID: <Pine.SOL.3.92.970406144621.791A-100000@sleipner.algonet.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII




From rem-conf-request@es.net Mon Apr 07 07:31:03 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <03336-0@osi-east2.es.net>; Mon, 7 Apr 1997 07:27:21 -0700
Received: from gateway-gw.pictel.com (actually gateway.pictel.com) 
          by osi-west.es.net with ESnet SMTP (PP);
          Mon, 7 Apr 1997 07:27:14 -0700
Received: from roadrunner.pictel.com 
          by gateway-gw.pictel.com (4.1/cf.gw.940128.1740) id AA29857;
          Mon, 7 Apr 97 10:27:13 EDT
Received: from python.pictel.com by roadrunner.pictel.com (4.1/runner.910925.1) 
          id AA10098; Mon, 7 Apr 97 10:27:10 EDT
Received: by python.pictel.com (5.x/SMI-SVR4) id AA22315;
          Mon, 7 Apr 1997 10:25:25 -0400
Date: Mon, 7 Apr 1997 10:25:25 -0400
From: garys@pictel.com (Gary Sullivan)
Message-Id: <9704071425.AA22315@python.pictel.com>
To: rem-conf@es.net
Subject: Re: Video Format (definition of CIF)



(I got an error message indicating that my previous message
on this topic was refused for rem-conf posting, due to excessive
inclusion of quoted prior text.  I am therefore reposting it
without the attached prior text.  Apologies to those who might
find some comments to be out of context.)


Regarding the definition of CIF:

The attached prior conversation was passed on to me regarding
the definition of CIF as used in Recommendations H.261 and H.263,
and its relationship to Recommendation 601.  My understanding is
that Toerless Eckert is not quite right about the definition of
CIF, but he's pretty close.

Actually, the H.261 and H.263 standards define the square-pixel
area equivalent of the image region covered by a 352x288 CIF
picture to be 384x288, not 375x288.  The explanation is a bit
complex, but that is the bottom line.

(I am the Rapporteur in charge of Advanced Video Coding in the
ITU-T.  With the help of Associate Rapporteur Keiichi Hibi and
other experts, I am responsible for H.261 and H.263, and thus
I am the keeper of the flame at the heart of the canonical
CIF magic lantern. :-)

Incidentally, you may all be happy to hear that new "H.263+"
optional extensions to H.263 are now being standardized in the ITU
which will allow the use of square-pixel formats and flexible
picture sizes.  For further information on that topic, see
  ftp://standard.pictel.com/video-site/h263plus


H.261, for example, says there are "352 pels per line, 288 lines"
and that the "picture area covered by these numbers of pels and
lines has an aspect ratio of 4:3" ...   (Therefore, each pixel has
width:height aspect ratio of 12:11.)

H.263 says basically the same thing, and it in fact explicitly
says the pixel aspect ratio is 12:11.

The references made in H.261 and H.263 to Recommendation 601 are
*not* used to define the pixel aspect ratio.  That is defined
explicitly in H.261 and H.263 themselves.

Thus for a square-pixel image which is 288 lines tall to represent
a CIF image, it should be precisely (352*12)/11 = 384 pixels wide.

We had a discussion of this topic in the ITU about a year ago,
and this was the conclusion of that discussion.  I won't go into
the details of the entire history.  However, I will point out
that Recommendation 601 is not itself exactly where you would look
to find its pixel aspect ratio either.  Recommendation 601 defines
a digital sampling of an analog signal at a certain frequency
(6.75 and 3.375 MHz).  Therefore it is the definition of the
underlying analog signal that defines what you will get from the
sampling.  The timing of that analog signal differs depending on
whether it is defined for a 625 or 525 line system.  The 720 pixel
lines of Recommendation 601 somewhat overscan the actual 4:3 picture
content.  In fact the picture content is about 704 pixels wide, and
therefore the pixels are at least very close to being 12:11.  In
order to resolve the problem of trying to figure out what *precisely*
was the aspect ratio of a Recommendation 601 pixel, the people who
wrote H.261 and H.263 found that whatever it was, it was very close
to 12:11 and that if we *define* it to be 12:11, it will henceforth
be simpler to deal with than if we just carry it over "normatively"
>from Recommendation 601.  H.261 and H.263 do contain a "note"
section that say that the CIF sampling has "a simple relationship"
with Recommendation 601, but it does not exactly use Recommendation
601 to define CIF (except for the color space and scaling).

In short, do *not* look in Recommendation 601 to find the
definition of CIF.  It is not there.  It is in H.261 and H.263.
I believe the only part of the definition of CIF that uses
Recommendation 601 is the definition of the color space and scaling.


Best Wishes,

Gary Sullivan  Tel: +1 508-623-4324 Fax: 749-2804 <garys@pictel.com>
PictureTel Corp. M/S 635, 100 Minuteman Road, Andover MA 01810  USA

(The usual disclaimers apply.)

From rem-conf-request@es.net Mon Apr 07 08:20:29 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <03623-0@osi-east2.es.net>; Mon, 7 Apr 1997 08:16:24 -0700
Received: from explorer.csc.com by osi-west.es.net with ESnet SMTP (PP);
          Mon, 7 Apr 1997 08:16:17 -0700
Received: from ftroy.herndon.csc.com(really [20.3.15.60]) by explorer.csc.com 
          via smtpd with smtp id <m0wEG8s-001BBHC@explorer.csc.com> 
          for <rem-conf@es.net>;
          Mon, 7 Apr 1997 11:15:34 -0400 (EDT) (Smail-3.2.0.92 1997-Feb-9 #2 built 1997-Mar-11)
Message-Id: <m0wEG8s-001BBHC@explorer.csc.com>
Comments: Authenticated sender is <ftroy@explorer.csc.com>
From: Frank Troy <ftroy@explorer.csc.com>
To: rem-conf@es.net
Date: Mon, 7 Apr 1997 11:11:42 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: mrouter
Reply-to: ftroy@csc.com
Priority: normal
X-mailer: Pegasus Mail for Win32 (v2.42)

To all:

Can someone please tell me where I can find detailed information (other than 
man pages) on configuring and using the multicast router for soloaris.

Thanks
Frank

-----------------------------------------------------------------------
Frank P. Troy                                     E-mail: ftroy@csc.com
Computer Sciences Corporation                     Phone: (703) 471-3694
3001 Centreville Road                             Fax:   (703) 471-1575    
Herndon, VA  20171                                Page:  (888) 808-0593

From rem-conf-request@es.net Mon Apr 07 09:11:54 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <03926-0@osi-east2.es.net>; Mon, 7 Apr 1997 09:05:04 -0700
Received: from msri.org by osi-west.es.net with ESnet SMTP (PP);
          Mon, 7 Apr 1997 09:04:43 -0700
Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id JAA01012 
          for <rem-conf@es.net>; Mon, 7 Apr 1997 09:04:42 -0700 (PDT)
X-Authentication-Warning: msri.org: smap set sender to <nobody@msri.org> using 
                          -f
Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) 
          id sma001004; Mon Apr 7 09:04:04 1997
Received: by hille.msri.org (8.7/MSRI) id JAA24442;
          Mon, 7 Apr 1997 09:04:03 -0700 (PDT)
Date: Mon, 7 Apr 1997 09:04:03 -0700 (PDT)
Message-Id: <199704071604.JAA24442@hille.msri.org>
To: rem-conf@es.net
From: joe <joe@msri.org>
Reply-to: joe@msri.org
Subject: Van Jacobson "Pathchar - How to infer the characteristics of Internet 
         paths"

	MBone Broadcast Announcement
	----------------------------

Title:       
	Van Jacobson "Pathchar - How to infer the characteristics of Internet paths"
Date:        
	Apr 21, 1997

Time:        
	16:00 PST8PDT 1 hours

Contact:     
	joe@msri.org

URL:         
	http://www.msri.org/sched/empennage/jacobson.html

Description:        
	Van Jacobson's MSRI-Evans Monday Lecture for  <a href="http://forum.swarthmore.edu/maw/">  Math Awareness Week  </a> - Mathematics and the Internet.









mbone broadcast schedule http://www.msri.org/mbone

From rem-conf-request@es.net Mon Apr 07 10:32:09 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <04463-0@osi-east2.es.net>; Mon, 7 Apr 1997 10:22:20 -0700
Received: from msri.org by osi-west.es.net with ESnet SMTP (PP);
          Mon, 7 Apr 1997 10:21:57 -0700
Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id KAA02772 
          for <rem-conf@es.net>; Mon, 7 Apr 1997 10:21:56 -0700 (PDT)
X-Authentication-Warning: msri.org: smap set sender to <nobody@msri.org> using 
                          -f
Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) 
          id sma002759; Mon Apr 7 10:21:30 1997
Received: by hille.msri.org (8.7/MSRI) id KAA24890;
          Mon, 7 Apr 1997 10:21:30 -0700 (PDT)
Date: Mon, 7 Apr 1997 10:21:30 -0700 (PDT)
Message-Id: <199704071721.KAA24890@hille.msri.org>
To: rem-conf@es.net
From: m1 <m1@msri.org>
Reply-to: m1@msri.org
Subject: Not Knot

	MBone Broadcast Announcement
	----------------------------

Title:       
	Not Knot
Date:        
	Apr 15, 1997

Time:        
	12:00 PST8PDT 1 hours

Contact:     
	m1@msri.org

URL:         
	http://www.geom.umn.edu/video/NotKnot/

Description:        
	Not Knot is a guided tour into computer-animated hyperbolic space. It proceeds from the world of  knots to their complementary spaces -- what's not a knot. Profound theorems of recent mathematics  show that most known complements carry the structure of hyperbolic geometry, a geometry in which  the sum of three angles of a triangle always is less than 180 degrees. 









mbone broadcast schedule http://www.msri.org/mbone

From rem-conf-request@es.net Mon Apr 07 10:44:28 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <04473-0@osi-east2.es.net>; Mon, 7 Apr 1997 10:24:30 -0700
Received: from msri.org by osi-west.es.net with ESnet SMTP (PP);
          Mon, 7 Apr 1997 10:24:03 -0700
Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id KAA02851 
          for <rem-conf@es.net>; Mon, 7 Apr 1997 10:24:02 -0700 (PDT)
X-Authentication-Warning: msri.org: smap set sender to <nobody@msri.org> using 
                          -f
Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) 
          id sma002840; Mon Apr 7 10:24:01 1997
Received: by hille.msri.org (8.7/MSRI) id KAA24924;
          Mon, 7 Apr 1997 10:24:01 -0700 (PDT)
Date: Mon, 7 Apr 1997 10:24:01 -0700 (PDT)
Message-Id: <199704071724.KAA24924@hille.msri.org>
To: rem-conf@es.net
From: m1 <m1@msri.org>
Reply-to: m1@msri.org
Subject: Outside In

	MBone Broadcast Announcement
	----------------------------

Title:       
	Outside In
Date:        
	Apr 16, 1997

Time:        
	12:00 PST8PDT 1 hours

Contact:     
	m1@msri.org

URL:         
	http://www.geom.umn.edu/docs/outreach/oi/

Description:        
	The award-winning computer animation Outside In explains the amazing discovery, made by Steve  Smale in 1957, that a sphere can be turned inside out by means of smooth motions and self  intersections, without cutting or tearing. It convincingly demonstrates how valuable visualization can  be in the communication of mathematics. 









mbone broadcast schedule http://www.msri.org/mbone

From rem-conf-request@es.net Mon Apr 07 11:09:02 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <04485-0@osi-east2.es.net>; Mon, 7 Apr 1997 10:27:34 -0700
Received: from msri.org by osi-west.es.net with ESnet SMTP (PP);
          Mon, 7 Apr 1997 10:27:06 -0700
Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id KAA02948 
          for <rem-conf@es.net>; Mon, 7 Apr 1997 10:27:05 -0700 (PDT)
X-Authentication-Warning: msri.org: smap set sender to <nobody@msri.org> using 
                          -f
Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) 
          id sma002932; Mon Apr 7 10:26:18 1997
Received: by hille.msri.org (8.7/MSRI) id KAA24958;
          Mon, 7 Apr 1997 10:26:19 -0700 (PDT)
Date: Mon, 7 Apr 1997 10:26:19 -0700 (PDT)
Message-Id: <199704071726.KAA24958@hille.msri.org>
To: rem-conf@es.net
From: m1 <m1@msri.org>
Reply-to: m1@msri.org
Subject: Fermat's Last Tape

	MBone Broadcast Announcement
	----------------------------

Title:       
	Fermat's Last Tape
Date:        
	Apr 17, 1997

Time:        
	12:00 PST8PDT 1 hours

Contact:     
	m1@msri.org

URL:         
	http://www.msri.org/fermat/Fermat.html

Description:        
	On July 28, 1993, over a thousand people gathered at the Palace of Fine Arts Theater in San  Francisco in order to celebrate the announcement by Andrew Wiles, just five weeks earlier,  that he had solved mathematics' most famous unsolved problem, known as "Fermat's Last  Theorem". The event was sponsored jointly by MSRI and the Exploratorium of San Francisco. MSRI has  produced a videotape, consisting mainly of an edited recording of this event, that provides a unique glimpse  into the excitement of this rare moment in mathematical history. 









mbone broadcast schedule http://www.msri.org/mbone

From rem-conf-request@es.net Mon Apr 07 13:16:56 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <04973-0@osi-east2.es.net>; Mon, 7 Apr 1997 11:40:35 -0700
Received: from nobozo.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP);
          Mon, 7 Apr 1997 11:40:16 -0700
Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) 
          by nobozo.CS.Berkeley.EDU (8.6.10/8.6.3) with SMTP id LAA16888 
          for <rem-conf@es.net>; Mon, 7 Apr 1997 11:40:14 -0700
Date: Mon, 7 Apr 1997 11:40:14 -0700
Message-Id: <199704071840.LAA16888@nobozo.CS.Berkeley.EDU>
X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU
X-Mailer: Windows Eudora Version 2.1.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: rem-conf@es.net
From: Jerrlyn Iwata <jerrlyn@postgres.Berkeley.EDU>
Subject: [Reminder] Berkeley Multimedia & Graphics Seminar

                Berkeley Multimedia and Graphics Seminar 
        (Wednesday April 9, 1997 12:30-2:00 PDT 405 Soda Hall) 

"Newsreels and Digital Technology: Prototypes for Retrieval and Use" 

                                Steven Ricci 
                              UCLA Film School 

        MBONE BROADCAST BEGINS AT 12.40 PDT (GMT - 8 HOURS)


From rem-conf-request@es.net Mon Apr 07 13:46:18 1997 
Received: from osi-east.es.net by osi-east2.es.net via ESnet SMTP service 
          id <05609-0@osi-east2.es.net>; Mon, 7 Apr 1997 13:33:11 -0700
Received: from enterprise.pulver.com by osi-east.es.net with ESnet SMTP (PP);
          Mon, 7 Apr 1997 13:32:42 -0700
Received: (from jeff@localhost) by enterprise.pulver.com (8.6.12/8.6.12) 
          id QAA21794; Mon, 7 Apr 1997 16:31:22 -0400
Date: Mon, 7 Apr 1997 16:31:20 -0400 (EDT)
From: Jeff Pulver <jeff@Pulver.COM>
To: rem-conf@es.net
Subject: Call for Speakers - Fall '97 Voice on the Net Conference
Message-ID: <Pine.SUN.3.91.970407162508.21101A-100000@enterprise.pulver.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi There,

The recent Spring '97 Voice on the Net  Conference (April 1-3) in San 
Francisco was a complete sellout. Over 500 people from 29 countries 
attended - representing all of the major players in the VON/VoIP 
industry.  About one third of the delegates were international.

I'm now in the planning stages for the Fall '97 VON Conference - which 
will be held in Boston September 23-25 at the World Trade Center.

Based on feedback from the attending delegates - I'd like to establish a
VON Technologies/Developers Track for the Fall conference.
tracks.  

I'm looking for speakers - both keynote and general sessions speakers for 
the Fall conference.

If anybody on this list would be interested in speaking - or could 
recommend somebody as a speaker - I'd appreciate it.

Best Regards,

Jeff Pulver                                            Tel.    516.487.1424 
pulver.com                                             Fax.    516.487.7269
                                                       http://pulver.com

From rem-conf-request@es.net Tue Apr 08 03:19:57 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <10223-0@osi-east2.es.net>; Tue, 8 Apr 1997 03:10:49 -0700
Received: from mbone.evitech.fi by osi-west.es.net with ESnet SMTP (PP);
          Tue, 8 Apr 1997 03:08:37 -0700
Received: (from erikp@localhost) 
          by mbone.evitech.fi (950413.SGI.8.6.12/950213.SGI.AUTOCF) 
          id NAA00102; Tue, 8 Apr 1997 13:08:32 +0300
From: Erik Patynen <erikp@mbone.evitech.fi>
Message-Id: <9704081308.ZM100@mbone.evitech.fi>
Date: Tue, 8 Apr 1997 13:08:32 +0000
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: mbone-fi@lut.fi
Subject: Enable97
Cc: rem-conf@es.net
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii


Enable '97 conference MBone transmission


(audio 64 kbps, video 128 kbps and random load
>from the whiteboard).

Conference days:

28 May, 7.00 am - 4.00 pm UTC (GMT)
29 May, 7.00 am - 4.00 pm UTC (GMT)
30 May, 7.00 am - 4.00 pm UTC (GMT)

Test transmissions occasionally during:

27 May, 10.00 am - 6.00 pm UTC (GMT)

Scope: world

More information: http://www.evitech.fi/CONFERENCE/enable97/

Technical contact: erik.patynen@evitech.fi

Administrational contact: erkki.ramo@evitech.fi




From rem-conf-request@es.net Tue Apr 08 08:20:29 1997 
Received: from osi-west.es.net by osi-east2.es.net via ESnet SMTP service 
          id <14776-0@osi-east2.es.net>; Tue, 8 Apr 1997 08:05:35 -0700
Received: from postoffice2.mail.cornell.edu by osi-west.es.net 
          with ESnet SMTP (PP); Tue, 8 Apr 1997 08:04:58 -0700
Received: from pclab.gsm.cornell.edu ([128.253.207.117]) 
          by postoffice2.mail.cornell.edu (8.8.5/8.8.5) with SMTP id KAA27176;
          Tue, 8 Apr 1997 10:26:27 -0400 (EDT)
Message-Id: <3.0.32.19970408102408.006da390@postoffice3.mail.cornell.edu>
X-Sender: eer2@postoffice3.mail.cornell.edu
X-Mailer: Windows Eudora Pro Version 3.0 (32) -- [Cornell Modified]
Date: Tue, 08 Apr 1997 10:25:54 -0400
To: eer2@cornell.edu
From: Ethan Rafferty <eer2@cornell.edu>
Subject: NFS research project -- Please complete soon
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Hello,

On the following web site resides the research instrument for the NFS
server research project.  It is a simple form which should take 15 or 20
minutes to complete.  It's kind of fun:  you get to analyze different
attributes of an NFS server and make trade-offs between them.

1.	Please forward this e-mail right away to anyone you know of who may be
interested in participating in the research project.
2.	Please complete and submit the form on the web site below by Friday,
April 11.

<http://www.gsm.cornell.edu/courses/nba564/NFS.htm>

This study is being performed by MBA students at Cornell's Johnson Graduate
School of Management in order to analyze the market for NFS service in
general and for specialized NFS server appliances in particular.  The
submission of the form is anonymous unless you choose to fill out the
fields asking who you are.

Thank you for your participation!

Ethan Rafferty
eer2@cornell.edu


From rem-conf-request@tmpmail.es.net Tue Apr 08 13:31:25 1997 
Received: from mail1 (actually mail1.es.net) by osi-west.es.net 
          with ESnet SMTP (PP); Tue, 8 Apr 1997 10:31:22 -0700
Received: from list by mail1 with local (Exim 1.61 #3) id 0wEeCM-0000u6-00;
          Tue, 8 Apr 1997 09:56:46 -0700
From: Joe Metzger <metzger@scl.ameslab.gov>
Message-Id: <9704081156.ZM20307@ender.scl.ameslab.gov>
Date: Tue, 8 Apr 1997 11:56:44 -0500
Organization: ESnet
X-Phone: (515)294-1939
X-Fax: (515)294-4491
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: rem-conf@tmpmail.es.net
Subject: Test, please ignore
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Resent-Message-ID: <"Hv9R12.0.Ls.EZdIp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Tue, 8 Apr 1997 09:56:46 -0700

This is test 0 of the new rem-conf@es.net mailing list software.
Please ignore.

Thanks.
--
*************************************************************************
* Joe Metzger                          Ames Office: (515)294-1939       *
* Computer Systems Engineer            LBNL Office: (510)486-5740       *
* Network Information Services Group   metzger@es.net                   *
* ESnet, Lawrence Berkeley Laboratory  314 Wilhelm, ISU, Ames IA, 50011 *
*************************************************************************


From rem-conf-request@es.net Tue Apr 08 20:28:29 1997 
Received: from gateway-gw.pictel.com by osi-west.es.net with ESnet SMTP (PP);
          Tue, 8 Apr 1997 17:28:24 -0700
Received: from roadrunner.pictel.com 
          by gateway-gw.pictel.com (4.1/cf.gw.940128.1740) id AA29831;
          Tue, 8 Apr 97 20:26:39 EDT
Received: from python.pictel.com by roadrunner.pictel.com (4.1/runner.910925.1) 
          id AA17302; Tue, 8 Apr 97 20:26:36 EDT
Received: by python.pictel.com (5.x/SMI-SVR4) id AA24089;
          Tue, 8 Apr 1997 20:24:50 -0400
Date: Tue, 8 Apr 1997 20:24:50 -0400
From: garys@pictel.com (Gary Sullivan)
Message-Id: <9704090024.AA24089@python.pictel.com>
To: ITU-SG16@MAILBAG.INTEL.COM, itu-adv-video@listserv.iterated.com, 
    rem-conf@es.net
Subject: Re: RTP Payload Format for H.263 Stream
Cc: czhu@ibeam.intel.com, jtoga@ibeam.jf.intel.com, maxm@MICROSOFT.com, 
    tnixon@MICROSOFT.COM, webberr@es.net



I would like to suggest some editorial clarifications of the
description of the RTP payload format specification for H.263.
I also have a couple of questions.  I understand that this topic
will be discussed tomorrow at the IETF meeting in Memphis.

I have discussed most of these issues informally already with
Mr. Chad Zhu, the author of the Internet draft (but I have not
been able to reach him this week).  My concerns are listed in
no particular order below:



ITEM 1:

Regarding the definition of the MBA field (section 5.2).

The document (draft version 4 from Chad Zhu) as I have it says
that the MBA field is 9 bits long and contains "The absolute
address of the first MB within its GOB, counting from 0".

I found this statement very hard to understand.  The word "absolute"
is part of the problem, since it is actually describing a
relative address (relative to the start of the GOB).  Since it says
it is the "absolute address of the first MB", it sounds like
it means the address relative to the MB in the upper left hand
corner of the *picture*.  However, I don't think that is actually
the case.  I think it is the address relative the the MB in the
upper left hand corner of the *GOB* (otherwise, it needs to be
13 bits long instead of 9 bits).  It sort of says what it means
when it uses the phrase "within its GOB", but that seems
insufficiently clear to me.  It is not clear whether the phrase
"absolute address" applies to the "first MB" which is
just incidentally remarked as being "within its GOB", or whether
it is trying to say it is the address within the GOB.

I suggest some kind of clarification.

Perhaps:

"The address within the GOB of the first MB in the packet,
 counting from zero.  For example, the third MB in the
 fifth GOB is given MBA = 2."



ITEM 2:

The length of the RR field in Section 5.3 was described in
version 3 as 19 bits.  Version 4 does not seem to explictly say
how long the RR field is.  That should be fixed.



ITEM 3:

The document discusses a cross-GOB data dependency in the
prediction of motion vector values when GOB headers are
not present.  Due to this dependency, it mentions that
it is advisable to use GOB headers on lossy packet nets.

It should also point out that another cross-GOB data
dependency exists in the OBMC part of the Advanced Prediction
(AP) option.  This dependency is much less severe in its
quality impact, but the document should probably mention
that it exists.  Due to this dependency, it may be advisable
to not use AP on lossy packet nets (also in regard to the desire
to easily decode packets that are received out of order).



ITEM 4:

The document describes a packetization with headers that
duplicate the functionality of virtually all of the content
of the video bitstream picture header.  This led me to
wonder whether the picture header was still sent, or whether
the packetization headers were just a wrapper around the
existing bitstream definition with a duplication of much
of its content.  After talking with Mr. Zhu, I have concluded
that it is just a wrapper and that the entire H.263 bitstream
is sent in the payload without alteration.  I agree that it
is desirable to sent the entire H.263 bitstream in the payload.
I think it might be helpful to clarify the document to make
sure that this is understood.



ITEM 5:

The document describes a "Mode A" packetization which can be
used to fragment the H.263 bitstream at picture header boundaries
or at GOB boundaries, and discusses how the presence of GOB headers
can aid in this process.  I did not understand from reading the
document whether fragmentation at GOB boundaries was allowed even
when GOB headers were not present.  After talking with Mr. Zhu,
I have concluded that the fragmentation *is* allowed without the
presence of GOB headers.  Some clarifying wording to that effect
might be helpful.



ITEM 6:

The email message that was sent with version 4 of the proposed
packetization specification says that the changes for this revision
are "mostly editorial".  It is very important for us to know whether
*any* of those changes affect the technical content, especially
since the ITU just "determined" their packetization definition based
on the third draft.



ITEM 7:

It has come to my attention that some company may have implemented
the first-draft version of the packetization definition without
indicating in any way that they have done a non-standard packetization.
Is it possible to detect whether first draft or the current draft was used
by looking at the bits in the headers?  Should it be?  This issue has
caused a controversy in some recent ITU email discussions (on
ITU-SG16@MAILBAG.INTEL.COM).

It may be useful to have some form of "in-band" detection of the
packetization method (just as H.263 has an "in-band" indication of which
of its options are in use).  As I understand it, there used to be a
version number in the packet header, but that was removed from the current
draft.  Why?  (I understand that it was not meant to distinguish between
draft versions of the standard, especially since draft 1 has expired, but
that is one way to have a detectable in-band signal of the type of
packetization.)



ITEM 8:

The ITU has a project called "H.263+", which is working on adding new
optional enhancements into H.263.  In January, the ITU plans to approve
final adoption of a set of those enhancements.  Thus, in January, the
packetization described in this Internet draft will no longer be up
to date with all of H.263.  (Further enhancements may also be adopted
into H.263 later.)  Some of the new enhancements are meant specifically
for improving packet-network performance.  Therefore a new
packetization definition for H.263 will soon be needed.

The draft packetization document makes no mention of H.263+ or its
impending impact on the packetization plan.  At a minimum, it should
do two things:

1) mention the existence of the planned enhancements, and

2) describe some plan for later accommodating those enhancements

This topic again brings up the issue of having a way of detecting
the packetization method.



ITEM 9:

In order to help coordinate the development of H.263 packetization,
I would like to provide the following information to those receiving
this message:

Further information on the H.263+ project can be found at
   ftp://standard.pictel.com/video-site/h263plus

The ITU email reflector which discusses all video coding issues is
   itu-adv-video@listserv.iterated.com


The IETF email reflector which discusses H.263 packetization is
   rem-conf@es.net

An archive of the discussions on that reflector can be found at
   ftp://nic.es.net/pub/mailing-lists/mail-archive/rem-conf


The ITU email reflector which discusses packet-network terminals is
   ITU-SG16@MAILBAG.INTEL.COM


Best Wishes,
Gary Sullivan

From rem-conf-request@tmpmail.es.net Tue Apr 08 20:47:03 1997 
Received: from mail1 (actually mail1.es.net) by osi-west.es.net 
          with ESnet SMTP (PP); Tue, 8 Apr 1997 17:46:59 -0700
Received: from list by mail1 with local (Exim 1.61 #3) id 0wElFW-00027F-00;
          Tue, 8 Apr 1997 17:28:30 -0700
Date: Tue, 8 Apr 1997 20:24:50 -0400
From: garys@pictel.com (Gary Sullivan)
Message-Id: <9704090024.AA24089@python.pictel.com>
To: ITU-SG16@MAILBAG.INTEL.COM, itu-adv-video@listserv.iterated.com, 
    rem-conf@es.net
Subject: Re: RTP Payload Format for H.263 Stream
Cc: czhu@ibeam.intel.com, jtoga@ibeam.jf.intel.com, maxm@MICROSOFT.com, 
    tnixon@MICROSOFT.COM, webberr@es.net
Resent-Message-ID: <"LR5Lp.0.8_1.kAkIp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Tue, 8 Apr 1997 17:28:30 -0700



I would like to suggest some editorial clarifications of the
description of the RTP payload format specification for H.263.
I also have a couple of questions.  I understand that this topic
will be discussed tomorrow at the IETF meeting in Memphis.

I have discussed most of these issues informally already with
Mr. Chad Zhu, the author of the Internet draft (but I have not
been able to reach him this week).  My concerns are listed in
no particular order below:



ITEM 1:

Regarding the definition of the MBA field (section 5.2).

The document (draft version 4 from Chad Zhu) as I have it says
that the MBA field is 9 bits long and contains "The absolute
address of the first MB within its GOB, counting from 0".

I found this statement very hard to understand.  The word "absolute"
is part of the problem, since it is actually describing a
relative address (relative to the start of the GOB).  Since it says
it is the "absolute address of the first MB", it sounds like
it means the address relative to the MB in the upper left hand
corner of the *picture*.  However, I don't think that is actually
the case.  I think it is the address relative the the MB in the
upper left hand corner of the *GOB* (otherwise, it needs to be
13 bits long instead of 9 bits).  It sort of says what it means
when it uses the phrase "within its GOB", but that seems
insufficiently clear to me.  It is not clear whether the phrase
"absolute address" applies to the "first MB" which is
just incidentally remarked as being "within its GOB", or whether
it is trying to say it is the address within the GOB.

I suggest some kind of clarification.

Perhaps:

"The address within the GOB of the first MB in the packet,
 counting from zero.  For example, the third MB in the
 fifth GOB is given MBA = 2."



ITEM 2:

The length of the RR field in Section 5.3 was described in
version 3 as 19 bits.  Version 4 does not seem to explictly say
how long the RR field is.  That should be fixed.



ITEM 3:

The document discusses a cross-GOB data dependency in the
prediction of motion vector values when GOB headers are
not present.  Due to this dependency, it mentions that
it is advisable to use GOB headers on lossy packet nets.

It should also point out that another cross-GOB data
dependency exists in the OBMC part of the Advanced Prediction
(AP) option.  This dependency is much less severe in its
quality impact, but the document should probably mention
that it exists.  Due to this dependency, it may be advisable
to not use AP on lossy packet nets (also in regard to the desire
to easily decode packets that are received out of order).



ITEM 4:

The document describes a packetization with headers that
duplicate the functionality of virtually all of the content
of the video bitstream picture header.  This led me to
wonder whether the picture header was still sent, or whether
the packetization headers were just a wrapper around the
existing bitstream definition with a duplication of much
of its content.  After talking with Mr. Zhu, I have concluded
that it is just a wrapper and that the entire H.263 bitstream
is sent in the payload without alteration.  I agree that it
is desirable to sent the entire H.263 bitstream in the payload.
I think it might be helpful to clarify the document to make
sure that this is understood.



ITEM 5:

The document describes a "Mode A" packetization which can be
used to fragment the H.263 bitstream at picture header boundaries
or at GOB boundaries, and discusses how the presence of GOB headers
can aid in this process.  I did not understand from reading the
document whether fragmentation at GOB boundaries was allowed even
when GOB headers were not present.  After talking with Mr. Zhu,
I have concluded that the fragmentation *is* allowed without the
presence of GOB headers.  Some clarifying wording to that effect
might be helpful.



ITEM 6:

The email message that was sent with version 4 of the proposed
packetization specification says that the changes for this revision
are "mostly editorial".  It is very important for us to know whether
*any* of those changes affect the technical content, especially
since the ITU just "determined" their packetization definition based
on the third draft.



ITEM 7:

It has come to my attention that some company may have implemented
the first-draft version of the packetization definition without
indicating in any way that they have done a non-standard packetization.
Is it possible to detect whether first draft or the current draft was used
by looking at the bits in the headers?  Should it be?  This issue has
caused a controversy in some recent ITU email discussions (on
ITU-SG16@MAILBAG.INTEL.COM).

It may be useful to have some form of "in-band" detection of the
packetization method (just as H.263 has an "in-band" indication of which
of its options are in use).  As I understand it, there used to be a
version number in the packet header, but that was removed from the current
draft.  Why?  (I understand that it was not meant to distinguish between
draft versions of the standard, especially since draft 1 has expired, but
that is one way to have a detectable in-band signal of the type of
packetization.)



ITEM 8:

The ITU has a project called "H.263+", which is working on adding new
optional enhancements into H.263.  In January, the ITU plans to approve
final adoption of a set of those enhancements.  Thus, in January, the
packetization described in this Internet draft will no longer be up
to date with all of H.263.  (Further enhancements may also be adopted
into H.263 later.)  Some of the new enhancements are meant specifically
for improving packet-network performance.  Therefore a new
packetization definition for H.263 will soon be needed.

The draft packetization document makes no mention of H.263+ or its
impending impact on the packetization plan.  At a minimum, it should
do two things:

1) mention the existence of the planned enhancements, and

2) describe some plan for later accommodating those enhancements

This topic again brings up the issue of having a way of detecting
the packetization method.



ITEM 9:

In order to help coordinate the development of H.263 packetization,
I would like to provide the following information to those receiving
this message:

Further information on the H.263+ project can be found at
   ftp://standard.pictel.com/video-site/h263plus

The ITU email reflector which discusses all video coding issues is
   itu-adv-video@listserv.iterated.com


The IETF email reflector which discusses H.263 packetization is
   rem-conf@es.net

An archive of the discussions on that reflector can be found at
   ftp://nic.es.net/pub/mailing-lists/mail-archive/rem-conf


The ITU email reflector which discusses packet-network terminals is
   ITU-SG16@MAILBAG.INTEL.COM


Best Wishes,
Gary Sullivan


From rem-conf-request@es.net Tue Apr 08 23:16:16 1997 
Received: from xenon.chromatic.com (actually 204.182.30.3) by osi-west.es.net 
          with ESnet SMTP (PP); Tue, 8 Apr 1997 20:16:11 -0700
Received: from wei.chromatic.com ([172.16.192.221]) 
          by xenon.chromatic.com (8.7.5/8.7.3) with SMTP id UAA06573 
          for <rem-conf@es.net>; Tue, 8 Apr 1997 20:16:09 -0700 (PDT)
Message-Id: <2.2.32.19970409041416.006ba0e8@xenon.chromatic.com>
X-Sender: wding@xenon.chromatic.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 08 Apr 1997 20:14:16 -0800
To: rem-conf@es.net
From: Wei Ding <wding@chromatic.com>
Subject: subscribe

subscribe wding@chromatic.com
----------------------------------------------------------
Wei Ding, Ph.D.                    Voice: (408) 752 - 9507
Chromatic Research, Inc.             Fax: (408) 752 - 9301	   
615 Tasman Drive               E-mail: wding@chromatic.com	
Sunnyvale, CA 94089               http://www.chromatic.com


From rem-conf-request@es.net Wed Apr 09 03:36:23 1997 
Received: from burdell.cc.gatech.edu by osi-west.es.net with ESnet SMTP (PP);
          Wed, 9 Apr 1997 00:36:06 -0700
Received: from morticia.cc.gatech.edu (kevin@morticia.cc.gatech.edu [130.207.8.11]) 
          by burdell.cc.gatech.edu (8.8.4/8.6.9) with ESMTP id DAA25118 
          for <rem-conf@es.net>; Wed, 9 Apr 1997 03:36:02 -0400 (EDT)
Received: (from kevin@localhost) by morticia.cc.gatech.edu (8.8.4/8.6.9) 
          id DAA23421 for rem-conf@es.net; Wed, 9 Apr 1997 03:36:00 -0400 (EDT)
Date: Wed, 9 Apr 1997 03:36:00 -0400 (EDT)
From: kevin@cc.gatech.edu (Kevin C. Almeroth)
Message-Id: <199704090736.DAA23421@morticia.cc.gatech.edu>
To: rem-conf@es.net
Subject: MBone Bandwidth


A quick report from what I see at Georgia Tech (though I'm officially
in Japan) is that bandwidth use seems to be pretty reasonable though
approaching that tiresome implied limit of 512 Kb/s+

approx 1 Kb/s of sdr announcement traffic
approx 10 Kb/s of video control traffic
approx 300 Kb/s of video data traffic
approx 15 Kb/s of audio control traffic
approx 100 Kb/s of audio data traffic

Note:  these numbers are rough estimates of high end averages as
computed using visual estimation based on data collected at 5
minute intervals.

I'm not in a position to judge qualitative quality but I haven't
heard (or seen on this list) complaints about high loss.  Any
such comments from any of the time zone regions?

-Kevin Almeroth

From rem-conf-request@tmpmail.es.net Wed Apr 09 03:53:31 1997 
Received: from mail1 (actually mail1.es.net) by osi-west.es.net 
          with ESnet SMTP (PP); Wed, 9 Apr 1997 00:53:22 -0700
Received: from list by mail1 with local (Exim 1.61 #3) id 0wErvX-0003As-00;
          Wed, 9 Apr 1997 00:36:19 -0700
Date: Wed, 9 Apr 1997 03:36:00 -0400 (EDT)
From: kevin@cc.gatech.edu (Kevin C. Almeroth)
Message-Id: <199704090736.DAA23421@morticia.cc.gatech.edu>
To: rem-conf@es.net
Subject: MBone Bandwidth
Resent-Message-ID: <"Ne5e62.0.j-2.pRqIp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Wed, 9 Apr 1997 00:36:19 -0700


A quick report from what I see at Georgia Tech (though I'm officially
in Japan) is that bandwidth use seems to be pretty reasonable though
approaching that tiresome implied limit of 512 Kb/s+

approx 1 Kb/s of sdr announcement traffic
approx 10 Kb/s of video control traffic
approx 300 Kb/s of video data traffic
approx 15 Kb/s of audio control traffic
approx 100 Kb/s of audio data traffic

Note:  these numbers are rough estimates of high end averages as
computed using visual estimation based on data collected at 5
minute intervals.

I'm not in a position to judge qualitative quality but I haven't
heard (or seen on this list) complaints about high loss.  Any
such comments from any of the time zone regions?

-Kevin Almeroth


From rem-conf-request@es.net Wed Apr 09 09:51:31 1997 
Received: from igw3.watson.ibm.com by osi-west.es.net with ESnet SMTP (PP);
          Wed, 9 Apr 1997 06:51:08 -0700
Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) 
          by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id JAA12176;
          Wed, 9 Apr 1997 09:41:04 -0400
Received: from wildbird.watson.ibm.com (wildbird.watson.ibm.com [9.2.23.71]) 
          by mailhub1.watson.ibm.com (8.8.2/01-15-97) with SMTP id JAA44488;
          Wed, 9 Apr 1997 09:50:52 -0400
Received: from chowchow.watson.ibm.com 
          by wildbird.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA28024;
          Wed, 9 Apr 1997 09:50:47 -0400
Message-Id: <9704091350.AA28024@wildbird.watson.ibm.com>
From: Ping Pan <pan@watson.ibm.com>
To: "Kevin C. Almeroth" <kevin@cc.gatech.edu>, rem-conf <rem-conf@es.net>
Subject: Re: MBone Bandwidth
Date: Wed, 9 Apr 1997 09:50:35 -0400
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1161
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

> I'm not in a position to judge qualitative quality but I haven't
> heard (or seen on this list) complaints about high loss.  Any
> such comments from any of the time zone regions?

Hi,

In the IBM site here, we have experienced very high loss in the IETF
channels, (as much as 40-50% for vic). But we suspect one of the routers in
the building may have screwed up. Did anyone else have the similar problem
yesterday?

Thanks!

--
Ping Pan

IBM Research Center, pan@watson.ibm.com, (914)-784-6579

From rem-conf-request@tmpmail.es.net Wed Apr 09 10:16:23 1997 
Received: from mail1 (actually mail1.es.net) by osi-west.es.net 
          with ESnet SMTP (PP); Wed, 9 Apr 1997 07:16:14 -0700
Received: from list by mail1 with local (Exim 1.61 #3) id 0wExmX-0004MS-00;
          Wed, 9 Apr 1997 06:51:25 -0700
Message-Id: <9704091350.AA28024@wildbird.watson.ibm.com>
From: Ping Pan <pan@watson.ibm.com>
To: "Kevin C. Almeroth" <kevin@cc.gatech.edu>, rem-conf <rem-conf@es.net>
Subject: Re: MBone Bandwidth
Date: Wed, 9 Apr 1997 09:50:35 -0400
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1161
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"Dn0UC3.0._54.TxvIp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Wed, 9 Apr 1997 06:51:25 -0700

> I'm not in a position to judge qualitative quality but I haven't
> heard (or seen on this list) complaints about high loss.  Any
> such comments from any of the time zone regions?

Hi,

In the IBM site here, we have experienced very high loss in the IETF
channels, (as much as 40-50% for vic). But we suspect one of the routers in
the building may have screwed up. Did anyone else have the similar problem
yesterday?

Thanks!

--
Ping Pan

IBM Research Center, pan@watson.ibm.com, (914)-784-6579


From rem-conf-request@es.net Wed Apr 09 10:18:58 1997 
Received: from cs.columbia.edu by osi-west.es.net with ESnet SMTP (PP);
          Wed, 9 Apr 1997 07:18:37 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) 
          by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id KAA21172;
          Wed, 9 Apr 1997 10:18:35 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) 
          by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id KAA23630;
          Wed, 9 Apr 1997 10:18:34 -0400 (EDT)
Sender: hgs@cs.columbia.edu
Message-ID: <334BA539.5F3F@cs.columbia.edu>
Date: Wed, 09 Apr 1997 10:18:33 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Ping Pan <pan@watson.ibm.com>
CC: "Kevin C. Almeroth" <kevin@cc.gatech.edu>, rem-conf@es.net
Subject: Re: MBone Bandwidth
References: <9704091350.AA28024@wildbird.watson.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I'm seeing about 50% loss for both video and audio. 
-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From rem-conf-request@tmpmail.es.net Wed Apr 09 10:32:37 1997 
Received: from mail1 (actually mail1.es.net) by osi-west.es.net 
          with ESnet SMTP (PP); Wed, 9 Apr 1997 07:32:31 -0700
Received: from list by mail1 with local (Exim 1.61 #3) id 0wEyDJ-0004er-00;
          Wed, 9 Apr 1997 07:19:05 -0700
Sender: hgs@cs.columbia.edu
Message-ID: <334BA539.5F3F@cs.columbia.edu>
Date: Wed, 09 Apr 1997 10:18:33 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Ping Pan <pan@watson.ibm.com>
CC: "Kevin C. Almeroth" <kevin@cc.gatech.edu>, rem-conf@es.net
Subject: Re: MBone Bandwidth
References: <9704091350.AA28024@wildbird.watson.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"pyJU_2.0.qN4.PLwIp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Wed, 9 Apr 1997 07:19:05 -0700

I'm seeing about 50% loss for both video and audio. 
-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs


From rem-conf-request@es.net Wed Apr 09 13:00:08 1997 
Received: from alpha.xerox.com by osi-west.es.net with ESnet SMTP (PP);
          Wed, 9 Apr 1997 09:59:53 -0700
Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com 
          with SMTP id <17982(8)>; Wed, 9 Apr 1997 09:59:40 PDT
Received: from localhost by crevenia.parc.xerox.com with SMTP id <177490>;
          Wed, 9 Apr 1997 08:37:29 -0700
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
cc: Ping Pan <pan@watson.ibm.com>, "Kevin C. Almeroth" <kevin@cc.gatech.edu>, 
    rem-conf@es.net
Subject: Re: MBone Bandwidth
In-reply-to: Your message of "Wed, 09 Apr 97 07:18:33 PDT." <334BA539.5F3F@cs.columbia.edu>
Date: Wed, 9 Apr 1997 08:37:21 PDT
Sender: Bill Fenner <fenner@parc.xerox.com>
From: Bill Fenner <fenner@parc.xerox.com>
Message-Id: <97Apr9.083729pdt.177490@crevenia.parc.xerox.com>

Henning Schulzrinne <schulzrinne@cs.columbia.edu> wrote:
>I'm seeing about 50% loss for both video and audio. 

Most of that is on the tunnel from Sprint to Columbia.  (use mtrace).

  Bill

From rem-conf-request@es.net Wed Apr 09 13:03:23 1997 
Received: from alpha.xerox.com by osi-west.es.net with ESnet SMTP (PP);
          Wed, 9 Apr 1997 10:03:14 -0700
Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com 
          with SMTP id <17623(9)>; Wed, 9 Apr 1997 10:02:22 PDT
Received: from localhost by crevenia.parc.xerox.com with SMTP id <177486>;
          Wed, 9 Apr 1997 08:41:15 -0700
To: Ping Pan <pan@watson.ibm.com>
cc: "Kevin C. Almeroth" <kevin@cc.gatech.edu>, rem-conf <rem-conf@es.net>
Subject: Re: MBone Bandwidth
In-reply-to: Your message of "Wed, 09 Apr 97 06:50:35 PDT." <9704091350.AA28024@wildbird.watson.ibm.com>
Date: Wed, 9 Apr 1997 08:41:10 PDT
Sender: Bill Fenner <fenner@parc.xerox.com>
From: Bill Fenner <fenner@parc.xerox.com>
Message-Id: <97Apr9.084115pdt.177486@crevenia.parc.xerox.com>

Ping Pan <pan@watson.ibm.com> wrote:
>In the IBM site here, we have experienced very high loss in the IETF
>channels, (as much as 40-50% for vic).

Can you use mtrace to isolate the loss?  (Use the "mtrace from" button
on vat or vic, and only look at the right-hand column of numbers).

The median loss has been around 2-5%, but the mean is much higher because
about 20-30% of the receivers have problems.  The problems I've seen include
some inter-provider links and one massively overloaded mrouter, but are
mostly tail-circuits from providers to customers.

Everyone should use mtrace to find out where the loss is happening; saying
things like "I'm seeing 50% loss" is not at all useful.  Saying "I'm seeing
28% loss on the ProviderA<>ProviderB link" lets provider A and provider B
see if they can do something about it.

  Bill

From rem-conf-request@tmpmail.es.net Wed Apr 09 13:14:24 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Wed, 9 Apr 1997 10:14:09 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wF0mU-0005XF-00; Wed, 9 Apr 1997 10:03:34 -0700
To: Ping Pan <pan@watson.ibm.com>
cc: "Kevin C. Almeroth" <kevin@cc.gatech.edu>, rem-conf <rem-conf@es.net>
Subject: Re: MBone Bandwidth
In-reply-to: Your message of "Wed, 09 Apr 97 06:50:35 PDT." <9704091350.AA28024@wildbird.watson.ibm.com>
Date: Wed, 9 Apr 1997 08:41:10 PDT
Sender: Bill Fenner <fenner@parc.xerox.com>
From: Bill Fenner <fenner@parc.xerox.com>
Message-Id: <97Apr9.084115pdt.177486@crevenia.parc.xerox.com>
Resent-Message-ID: <"W5reE1.0.WC5.clyIp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Wed, 9 Apr 1997 10:03:34 -0700

Ping Pan <pan@watson.ibm.com> wrote:
>In the IBM site here, we have experienced very high loss in the IETF
>channels, (as much as 40-50% for vic).

Can you use mtrace to isolate the loss?  (Use the "mtrace from" button
on vat or vic, and only look at the right-hand column of numbers).

The median loss has been around 2-5%, but the mean is much higher because
about 20-30% of the receivers have problems.  The problems I've seen include
some inter-provider links and one massively overloaded mrouter, but are
mostly tail-circuits from providers to customers.

Everyone should use mtrace to find out where the loss is happening; saying
things like "I'm seeing 50% loss" is not at all useful.  Saying "I'm seeing
28% loss on the ProviderA<>ProviderB link" lets provider A and provider B
see if they can do something about it.

  Bill


From rem-conf-request@tmpmail.es.net Wed Apr 09 13:14:41 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Wed, 9 Apr 1997 10:14:15 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wF0j9-0005W8-00; Wed, 9 Apr 1997 10:00:07 -0700
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
cc: Ping Pan <pan@watson.ibm.com>, "Kevin C. Almeroth" <kevin@cc.gatech.edu>, 
    rem-conf@es.net
Subject: Re: MBone Bandwidth
In-reply-to: Your message of "Wed, 09 Apr 97 07:18:33 PDT." <334BA539.5F3F@cs.columbia.edu>
Date: Wed, 9 Apr 1997 08:37:21 PDT
Sender: Bill Fenner <fenner@parc.xerox.com>
From: Bill Fenner <fenner@parc.xerox.com>
Message-Id: <97Apr9.083729pdt.177490@crevenia.parc.xerox.com>
Resent-Message-ID: <"ZP94p1.0.RB5.NiyIp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Wed, 9 Apr 1997 10:00:07 -0700

Henning Schulzrinne <schulzrinne@cs.columbia.edu> wrote:
>I'm seeing about 50% loss for both video and audio. 

Most of that is on the tunnel from Sprint to Columbia.  (use mtrace).

  Bill


From rem-conf-request@tmpmail.es.net Wed Apr 09 17:23:46 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Wed, 9 Apr 1997 14:23:40 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wF4cR-000701-00; Wed, 9 Apr 1997 14:09:27 -0700
From: Joe Metzger <metzger@scl.ameslab.gov>
Message-Id: <9704081138.ZM20284@ender.scl.ameslab.gov>
Date: Tue, 8 Apr 1997 11:38:50 -0500
Organization: ESnet
X-Phone: (515)294-1939
X-Fax: (515)294-4491
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: rem-conf@es.net
Subject: Test message, please ignore
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Resent-Message-ID: <"an9kl1.0.Sa6.7M0Jp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Wed, 9 Apr 1997 14:09:27 -0700

Hello,
rem-conf@es.net is being moved to a new mail system at ESnet.  The new
system will support auto subscribe and unsubscribe functions and
automated bounce processing.  This is a test message to exercise the new
system.

I will post a more detailed message after the transition is complete.

Thank You.
*************************************************************************
* Joe Metzger                          Ames Office: (515)294-1939       *
* Computer Systems Engineer            LBNL Office: (510)486-5740       *
* Network Information Services Group   metzger@es.net                   *
* ESnet, Lawrence Berkeley Laboratory  314 Wilhelm, ISU, Ames IA, 50011 *
*************************************************************************


From rem-conf-request@es.net Thu Apr 10 07:05:24 1997 
Received: from soleil.uvsq.fr by osi-west.es.net with ESnet SMTP (PP);
          Thu, 10 Apr 1997 04:05:08 -0700
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1]) 
          by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id NAA05432 ;
          Thu, 10 Apr 1997 13:01:28 +0200 (METDST)
Received: from bernadotte.prism.uvsq.fr (bernadotte.prism.uvsq.fr [193.51.25.141]) 
          by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with SMTP id MAA29835 
          for <congres>; Thu, 10 Apr 1997 12:32:16 +0200 (MET DST)
Message-ID: <334CC3C6.2A80@prism.uvsq.fr>
Date: Thu, 10 Apr 1997 12:41:10 +0200
From: Khaldoun AL AGHA <Khaldoun.Alagha@prism.uvsq.fr>
Organization: PRiSM
X-Mailer: Mozilla 3.01Gold [fr] (Win95; I)
MIME-Version: 1.0
To: congres@prism.uvsq.fr
Subject: MWCN'97
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by soleil.uvsq.fr id 
                      NAA05432

Advance Program and Registration Form


MWCN'97
First International Workshop On Mobile and Wireless Communications
Networks.

Workshop Location:
Room Louis Liard, Sorbonne, Place de la Sorbonne, Quartier Latin, Paris,
France
May 12-15, 1997
Tutorials 12-13 and Workshop 14-15

Sponsored by the University of Versailles-PRiSM Laboratory=20
and in cooperation with the
ACM SIGMOBILE (pending)
IFIP TC6, WG6.8
IEEE ComSoc Technical Committee on Communications System Integration and
Modeling

General Co-Chairs:
Guy Pujolle, University of Versailles
Guy Omidyar, Illinois Institute of Technology Research Institute


Technical Program Committee:

A. Charbonnier, France Telecom, France
J.P. Claude, PRiSM, University of Versailles, France
J. Daigle, University of Mississippi, USA
Ph.Godlevski, ENST, France
V.B. Iversen, TUD, Denmark
B. Jabbari, George Mason University, USA
O. Martikainen Telecom Finland, Finland
M. Naghshineh, IBM, T.J. Watson research, USA
G. Omidyar, Illinois Institute of Technology Research Institute, USA
K. Pahlavan, Worcester Polytechnic Institute, USA
H. Perros, NCSU, USA
R. Pickholtz, The George Washington University, USA
G. Pujolle, PRiSM, University of Versailles, France
I. Rubin, UCLA, USA
K.S. Shanmugan, University of Kansas, USA
M. Schwartz, Columbia University
J. Slavik, Testcom, Czech Rep.
O. Spaniol, Technical University Aachen, Germany
S. Tabbane, ESPTT, Tunisia
V. Veque, LRI, University of Paris XI, France
D. Zeghlache, INT, France


MWCN Standing Committee:
Guy Omidyar:  Chair

Local arrangement: K. Al Agha (PRiSM)

For workshop information and program visit the Web location:
http://www.prism.uvsq.fr
or
http://www.prism.uvsq.fr/~marefat/mwcn/mwcn97.html

-----------------------------------------------
Tutorials  Before the Workshop

Registration will be open from 8:00 am=20
Both for Tutorials and the MWCN'97 Workshop
(Location and address for Tutorials will Be Announced)

Monday 12 May (Morning)
Tutorial - 1
Wired and Wireless ATM
G. Omidyar (Illinois Institute of Technology Research Institute, USA)

 8:30am to 10:30am
10:30am  coffee break
11:00am to 12:00pm

Monday 12 May (Afternoon)
Tutorial - 2=20
UMTS (Universal Mobile Telecomunication System)
P. Lucas (GIE CEGETEL, France)
1:30pm to 3:30pm
3:30pm coffee break
4:00pm to 5:00pm

Tuesday  13 May (Morning)
Tutorial - 3=20
Wireless ATM
E. Ayanoglu (Bell Labs, Lucent/AT&T, USA)

8:30am to 10:30am
10:30am  coffee break
11:00am to 12:00pm

Tuesday  13 May (Afternoon)
Tutorial - 4=20
Wireless LANs=20
A. Wolisz (Technical University of  Berlin, Germany)

1:30pm to 3:30pm
3:30pm coffee break
4:00pm to 5:00pm

------------------------------------------------------

MWCN'97 Workshop Advance program

Wednesday 14 May, 1997
Registration will be open from 8:00 am

--------------------------------------

Wednesday 14 May

9:00 am        =20
Opening Remarks: G. Omidyar and G. Pujolle

=20
Track 1 : Access techniques
Chairman : O. Spaniol=20
(Technical University Aachen, Germany)

1- GSM in the future evolution towards UMTS
R Thomas (CNET, France Telecom)

2- An overview of Third Generation Mobile Networks : Architecture
Principles
P. Lucas (GIE CEGETEL, France)

10 :30 am=20
Break

11:00
Track 2 : The Next Steps
Chairman : J. Slavik (Testcom, Czech Rep.)

1- The next steps for Mobile Computing and Communication
G. Q. Maguire Jr. (KTH/Inst. for Teleinformatik, Sweden)

2- Ubiquitous and Personal
I. Chlamtac (The University of Texas at Dallas, USA)

3- Packet access techniques for wireless systems
F. Borgonovo, A. Capone, L. Fratta, L. Musumeci=20
(Politecnico di Milano, Italy)

12 :30 pm
Lunch

13:30 pm - 14:00 pm
Standing Committee Meeting (All Invited)
Planning for the Next Year Conference/Workshop (MWCN'98 Conference)

14 :00 pm=20
Track 3 : Mobile, Wireless and Internet
Chairman : D. Zeghlache, (INT, France)

1- Mobile IP : a Tutorial
C. E. Perkins (Sun, USA)

2- Wireless LANs in Internet=20
A. Wolisz (Technical University of Berlin, Germany)

3- Local Wideband Wireless Networks
K. Pahlavan, (Worcester Polytechnic Institute, USA)

15:30 pm=20
Break

16:00 pm=20
Track 4 : Channel control
Chairman : K. Pahlavan, Worcester Polytechnic Institute, USA=20

1- Optimal Channel utilization and Service Protection in Cellular
Communication Systems
V. B. Iversen (Technical University of Denmark, Denmark)

2- Metaservices Channel Assignment in Third Generation Wireless Network
F. Valois (PRiSM), University of Versailles, France)
V. Veque, LRI, University of Paris-Sud, France)

3- An Application of Intelligent Agents for Mobile Network Resource
Allocation.
K. Al Agha (INT and PRiSM, France)

19:30 pm  Dinner (Location to be provided)

---------------------------
Second Day
Thursday 15 May
---------------------------

Registration will be open from 8:00 am

09:00 am=20
Track 5 : Towards a new generation
Chairman : S. Tabbane, (ESPTT, Tunisia)

1- An introduction of Location Management in Third Generation Cellular
Networks
N. Faggion (GIE CEGETEL, France)

2- Planification of the fixed network in a cellular network
M. Marzoug (CNET, France T=E9l=E9com, France)

3- Services Continuation from Fixed to Wireless ATM Network
J. Ben-Othman (PRiSM, University of Versailles, France)
V. Veque (LRI, University of Paris-Sud, France)

10:30 am
Break

11 :00 am=20
Track 6 : Wireless and ATM
Chairman : J.P. Claude (PRiSM, France)

1- Wireless ATM overview - case WAND
J. Ala-Laurila (Nokia, Finland)

2- On some issues in Wireless ATM
M. Gagnaire (ENST, France)

3- ATM as transport technology in Mobile systems
H. Eriksson (Ericsson, Sweden)

12:30 pm
Lunch

14:00 pm=20
Track 7 : Services in Wireless and Mobile Networks
Chairman : G. Omidyar (Illinois Institute of Technology Research
Institute)

1- Issues in the survivability of wireless mobile networks
T. A. Dahlberg, (University of North Carolina at Charlotte, USA)
S. Ramaswamy and D. Tipper, (University of Pittsburgh, USA)

2- UPT Services and the Intelligent Network
R. Nevoux (CNET France T=E9l=E9com, France)

3- Towards Intelligent Management of Mobile Cellular Networks
R. Boutaba (CRIM, Canada)

15 :30 pm
Break

16:00 pm=20
Track 8 : Ressource Management
Chairman : V. Veque (LRI, University of Paris Sud, France)

1- Congestion problem due to handover traffic
X. Lagrange (ENST, France)

2- Comparison of Different Handover Policies for Joint Voice-Data
Cellular Networks
D. Calin and D. Zeghlache. (INT, France)

3- PRP : A New Policy with Channel Reservation and Prediction in
Cellular Communication Systems
S. Boumerdassi, G. Pujolle (PRiSM, University of Versailles, France)

_________________________________________________________________

REGISTRATION

CHARGES
The registration fee :
1400 FF for IFIP, IEEE and ACM members=20
1800 FF for non IFIP, IEEE and ACM members
(includes proceedings, coffee breaks, and one dinner/reception).=20
Tutorial fees are 500 FF for half a day and 1000 FF for a full day.

TOTAL PAYMENT: _____________________
Method of payment (delete as not applicable):
PAID BY Check (enclosed, payable to DNAC)=20
or
PAID BY Credit card (details below)
_________________________________________________________________________=
___
CREDIT CARD DETAILS
Visa card and Master card
No.     ________ ________ ________ ________
Expiry date ____ / ____
I authorize you to charge the sum of ______________ to my credit card
numbered as above

Signature       ________________
Date            ________________
_________________________________________________________________________=
___
YOUR DETAILS

Name                    _____________________________________________
Position (or job title) _____________________________________________
Affiliation             _____________________________________________
Address         _____________________________________________
                        _____________________________________________
                        _____________________________________________
Country                 _____________________________________________
Phone #                 _____________________________________________
FAX #                   _____________________________________________
E-mail                  _____________________________________________
_________________________________________________________________________=
___

SEND THIS FORM
by post with check or credit card payment to:
Guy Pujolle
PRiSM, University of Versailles
45 av. des Etats-Unis
78000 Versailles, France
FAX: (33) 1 39 25 40 57,=20
e-mail: mwcn@prism.uvsq.fr
_________________________________________________________________________=
___
_________________________________________________________________________=
___

You can choose your hotel and make reservation.
The Workshop will take place in "La Sorbonne" and the "arrondissements"
of Paris corresponding to the location are 5th and 6th arrondissement
(Quartier Latin). A list of hotels situated near "La Sorbonne" is as
follows (from the best to the more economical ; from **** to * stars):


----------------------- **** ----------------------
RIVES DE NOTRE DAME (Les)=20
15, quai Saint Michel; 75005 PARIS
Metro Saint Michel
RER Saint Michel - Notre Dame
phone : (331)43.54.81.16
fax : (331)43.26.27.09
http://www.paris.org/paris-cgi/PDB/hotel.cgi?htl1879

RELAIS CHRISTINE=20
3, rue Christine; 75006 PARIS
Metro Od=E9on
RER Saint Michel - Notre Dame
phone : (331)43.26.71.80
fax : (331)43.26.89.38
http://www.paris.org/paris-cgi/PDB/hotel.cgi?htl1983
----------------------- *** -----------------------
CALIFORNIA =20
32, rue des Ecoles; 75005 PARIS
Metro Maubert Mutualit=E9
RER Saint Michel - Notre Dame
phone : (331)46.34.12.90
fax : (331)46.34.75.52
http://www.paris.org/paris-cgi/PDB/hotel.cgi?htl1883

GRANDS HOMMES (Des)
17, place du Panth=E9on; 75005 PARIS
Metro Maubert Mutualit=E9
RER Luxembourg
phone (331)46.34.19.60
fax (331)43.26.67.32
http://www.paris.org/paris-cgi/PDB/hotel.cgi?htl1889
---------------------- ** --------------------------
CLUNY SORBONNE=20
8, rue Victor Cousin; 75005 PARIS
Metro Cluny - Sorbonne
RER Luxembourg
Phone : (331)43.54.66.66
fax : (331)43.29.68.07
http://www.paris.org/paris-cgi/PDB/hotel.cgi?htl1914

SAINT SEVERIN=20
40, rue Saint-S=E9verin; 75005 PARIS
Metro Saint Michel
RER Saint Michel - Notre Dame
phone : (331)46.34.05.70
fax : (331)46.33.84.47
http://www.paris.org/paris-cgi/PDB/hotel.cgi?htl1936
------------------------ * --------------------------
EXCELSIOR=20
20 Rue Cujas; 75005 PARIS
Metro Luxembourg
RER Luxembourg
phone : (331)46.34.79.50
fax : (331)43.54.87.10
http://www.paris.org/paris-cgi/PDB/hotel.cgi?htl1950

GERSON -  - F - Legend
14, rue de la Sorbonne; 75005 PARIS
Metro Cluny - Sorbonne
RER Luxembourg
phone : (331)43.54.28.40
http://www.paris.org/paris-cgi/PDB/hotel.cgi?htl1953
--------------------------------------------------



--=20
-----------------------------------------------------------------------
          __                  _______  _______      _______  _    __
         / /\                / ___  / / ___  / __  / _____/ / | _/ /
        / /  \ Laboratoire  / /__/ / / /__/ / /_/ / /____  /  |/  /
       / / /\ \            / _____/ / _  __/ __  /____  / / /|_/ /
      / / /\ \ \          / /      / / | |  / / _____/ / / /  / /
     / / /  \ \ \        /_/      /_/  |_| /_/ /______/ /_/  /_/
    / / /    \ \ \
   / / /      \ \ \
  / /_/________\ \ \   Khaldoun AL AGHA - Equipe R=E9seaux
 /_/____________\_\/\  Email : Khaldoun.Alagha@prism.uvsq.fr
 \_\_______________\/  http://www.prism.uvsq.fr/public/alagha =20

Universite Versailles Saint Quentin          =20
45, avenue des Etats-Unis                      tel : +33 (1) 39 25 40 92
78 035 VERSAILLES Cedex (France)               Fax : +33 (1) 39 25 40 57=20
------------------------------------------------------------------------

From rem-conf-request@tmpmail.es.net Thu Apr 10 07:32:48 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Thu, 10 Apr 1997 04:32:25 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wFHfc-000208-00; Thu, 10 Apr 1997 04:05:36 -0700
Message-ID: <334CC3C6.2A80@prism.uvsq.fr>
Date: Thu, 10 Apr 1997 12:41:10 +0200
From: Khaldoun AL AGHA <Khaldoun.Alagha@prism.uvsq.fr>
Organization: PRiSM
X-Mailer: Mozilla 3.01Gold [fr] (Win95; I)
MIME-Version: 1.0
To: congres@prism.uvsq.fr
Subject: MWCN'97
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by soleil.uvsq.fr id 
                      NAA05432
Resent-Message-ID: <"_p6aB3.0.Fu1.0cCJp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Thu, 10 Apr 1997 04:05:36 -0700

Advance Program and Registration Form


MWCN'97
First International Workshop On Mobile and Wireless Communications
Networks.

Workshop Location:
Room Louis Liard, Sorbonne, Place de la Sorbonne, Quartier Latin, Paris,
France
May 12-15, 1997
Tutorials 12-13 and Workshop 14-15

Sponsored by the University of Versailles-PRiSM Laboratory=20
and in cooperation with the
ACM SIGMOBILE (pending)
IFIP TC6, WG6.8
IEEE ComSoc Technical Committee on Communications System Integration and
Modeling

General Co-Chairs:
Guy Pujolle, University of Versailles
Guy Omidyar, Illinois Institute of Technology Research Institute


Technical Program Committee:

A. Charbonnier, France Telecom, France
J.P. Claude, PRiSM, University of Versailles, France
J. Daigle, University of Mississippi, USA
Ph.Godlevski, ENST, France
V.B. Iversen, TUD, Denmark
B. Jabbari, George Mason University, USA
O. Martikainen Telecom Finland, Finland
M. Naghshineh, IBM, T.J. Watson research, USA
G. Omidyar, Illinois Institute of Technology Research Institute, USA
K. Pahlavan, Worcester Polytechnic Institute, USA
H. Perros, NCSU, USA
R. Pickholtz, The George Washington University, USA
G. Pujolle, PRiSM, University of Versailles, France
I. Rubin, UCLA, USA
K.S. Shanmugan, University of Kansas, USA
M. Schwartz, Columbia University
J. Slavik, Testcom, Czech Rep.
O. Spaniol, Technical University Aachen, Germany
S. Tabbane, ESPTT, Tunisia
V. Veque, LRI, University of Paris XI, France
D. Zeghlache, INT, France


MWCN Standing Committee:
Guy Omidyar:  Chair

Local arrangement: K. Al Agha (PRiSM)

For workshop information and program visit the Web location:
http://www.prism.uvsq.fr
or
http://www.prism.uvsq.fr/~marefat/mwcn/mwcn97.html

-----------------------------------------------
Tutorials  Before the Workshop

Registration will be open from 8:00 am=20
Both for Tutorials and the MWCN'97 Workshop
(Location and address for Tutorials will Be Announced)

Monday 12 May (Morning)
Tutorial - 1
Wired and Wireless ATM
G. Omidyar (Illinois Institute of Technology Research Institute, USA)

 8:30am to 10:30am
10:30am  coffee break
11:00am to 12:00pm

Monday 12 May (Afternoon)
Tutorial - 2=20
UMTS (Universal Mobile Telecomunication System)
P. Lucas (GIE CEGETEL, France)
1:30pm to 3:30pm
3:30pm coffee break
4:00pm to 5:00pm

Tuesday  13 May (Morning)
Tutorial - 3=20
Wireless ATM
E. Ayanoglu (Bell Labs, Lucent/AT&T, USA)

8:30am to 10:30am
10:30am  coffee break
11:00am to 12:00pm

Tuesday  13 May (Afternoon)
Tutorial - 4=20
Wireless LANs=20
A. Wolisz (Technical University of  Berlin, Germany)

1:30pm to 3:30pm
3:30pm coffee break
4:00pm to 5:00pm

------------------------------------------------------

MWCN'97 Workshop Advance program

Wednesday 14 May, 1997
Registration will be open from 8:00 am

--------------------------------------

Wednesday 14 May

9:00 am        =20
Opening Remarks: G. Omidyar and G. Pujolle

=20
Track 1 : Access techniques
Chairman : O. Spaniol=20
(Technical University Aachen, Germany)

1- GSM in the future evolution towards UMTS
R Thomas (CNET, France Telecom)

2- An overview of Third Generation Mobile Networks : Architecture
Principles
P. Lucas (GIE CEGETEL, France)

10 :30 am=20
Break

11:00
Track 2 : The Next Steps
Chairman : J. Slavik (Testcom, Czech Rep.)

1- The next steps for Mobile Computing and Communication
G. Q. Maguire Jr. (KTH/Inst. for Teleinformatik, Sweden)

2- Ubiquitous and Personal
I. Chlamtac (The University of Texas at Dallas, USA)

3- Packet access techniques for wireless systems
F. Borgonovo, A. Capone, L. Fratta, L. Musumeci=20
(Politecnico di Milano, Italy)

12 :30 pm
Lunch

13:30 pm - 14:00 pm
Standing Committee Meeting (All Invited)
Planning for the Next Year Conference/Workshop (MWCN'98 Conference)

14 :00 pm=20
Track 3 : Mobile, Wireless and Internet
Chairman : D. Zeghlache, (INT, France)

1- Mobile IP : a Tutorial
C. E. Perkins (Sun, USA)

2- Wireless LANs in Internet=20
A. Wolisz (Technical University of Berlin, Germany)

3- Local Wideband Wireless Networks
K. Pahlavan, (Worcester Polytechnic Institute, USA)

15:30 pm=20
Break

16:00 pm=20
Track 4 : Channel control
Chairman : K. Pahlavan, Worcester Polytechnic Institute, USA=20

1- Optimal Channel utilization and Service Protection in Cellular
Communication Systems
V. B. Iversen (Technical University of Denmark, Denmark)

2- Metaservices Channel Assignment in Third Generation Wireless Network
F. Valois (PRiSM), University of Versailles, France)
V. Veque, LRI, University of Paris-Sud, France)

3- An Application of Intelligent Agents for Mobile Network Resource
Allocation.
K. Al Agha (INT and PRiSM, France)

19:30 pm  Dinner (Location to be provided)

---------------------------
Second Day
Thursday 15 May
---------------------------

Registration will be open from 8:00 am

09:00 am=20
Track 5 : Towards a new generation
Chairman : S. Tabbane, (ESPTT, Tunisia)

1- An introduction of Location Management in Third Generation Cellular
Networks
N. Faggion (GIE CEGETEL, France)

2- Planification of the fixed network in a cellular network
M. Marzoug (CNET, France T=E9l=E9com, France)

3- Services Continuation from Fixed to Wireless ATM Network
J. Ben-Othman (PRiSM, University of Versailles, France)
V. Veque (LRI, University of Paris-Sud, France)

10:30 am
Break

11 :00 am=20
Track 6 : Wireless and ATM
Chairman : J.P. Claude (PRiSM, France)

1- Wireless ATM overview - case WAND
J. Ala-Laurila (Nokia, Finland)

2- On some issues in Wireless ATM
M. Gagnaire (ENST, France)

3- ATM as transport technology in Mobile systems
H. Eriksson (Ericsson, Sweden)

12:30 pm
Lunch

14:00 pm=20
Track 7 : Services in Wireless and Mobile Networks
Chairman : G. Omidyar (Illinois Institute of Technology Research
Institute)

1- Issues in the survivability of wireless mobile networks
T. A. Dahlberg, (University of North Carolina at Charlotte, USA)
S. Ramaswamy and D. Tipper, (University of Pittsburgh, USA)

2- UPT Services and the Intelligent Network
R. Nevoux (CNET France T=E9l=E9com, France)

3- Towards Intelligent Management of Mobile Cellular Networks
R. Boutaba (CRIM, Canada)

15 :30 pm
Break

16:00 pm=20
Track 8 : Ressource Management
Chairman : V. Veque (LRI, University of Paris Sud, France)

1- Congestion problem due to handover traffic
X. Lagrange (ENST, France)

2- Comparison of Different Handover Policies for Joint Voice-Data
Cellular Networks
D. Calin and D. Zeghlache. (INT, France)

3- PRP : A New Policy with Channel Reservation and Prediction in
Cellular Communication Systems
S. Boumerdassi, G. Pujolle (PRiSM, University of Versailles, France)

_________________________________________________________________

REGISTRATION

CHARGES
The registration fee :
1400 FF for IFIP, IEEE and ACM members=20
1800 FF for non IFIP, IEEE and ACM members
(includes proceedings, coffee breaks, and one dinner/reception).=20
Tutorial fees are 500 FF for half a day and 1000 FF for a full day.

TOTAL PAYMENT: _____________________
Method of payment (delete as not applicable):
PAID BY Check (enclosed, payable to DNAC)=20
or
PAID BY Credit card (details below)
_________________________________________________________________________=
___
CREDIT CARD DETAILS
Visa card and Master card
No.     ________ ________ ________ ________
Expiry date ____ / ____
I authorize you to charge the sum of ______________ to my credit card
numbered as above

Signature       ________________
Date            ________________
_________________________________________________________________________=
___
YOUR DETAILS

Name                    _____________________________________________
Position (or job title) _____________________________________________
Affiliation             _____________________________________________
Address         _____________________________________________
                        _____________________________________________
                        _____________________________________________
Country                 _____________________________________________
Phone #                 _____________________________________________
FAX #                   _____________________________________________
E-mail                  _____________________________________________
_________________________________________________________________________=
___

SEND THIS FORM
by post with check or credit card payment to:
Guy Pujolle
PRiSM, University of Versailles
45 av. des Etats-Unis
78000 Versailles, France
FAX: (33) 1 39 25 40 57,=20
e-mail: mwcn@prism.uvsq.fr
_________________________________________________________________________=
___
_________________________________________________________________________=
___

You can choose your hotel and make reservation.
The Workshop will take place in "La Sorbonne" and the "arrondissements"
of Paris corresponding to the location are 5th and 6th arrondissement
(Quartier Latin). A list of hotels situated near "La Sorbonne" is as
follows (from the best to the more economical ; from **** to * stars):


----------------------- **** ----------------------
RIVES DE NOTRE DAME (Les)=20
15, quai Saint Michel; 75005 PARIS
Metro Saint Michel
RER Saint Michel - Notre Dame
phone : (331)43.54.81.16
fax : (331)43.26.27.09
http://www.paris.org/paris-cgi/PDB/hotel.cgi?htl1879

RELAIS CHRISTINE=20
3, rue Christine; 75006 PARIS
Metro Od=E9on
RER Saint Michel - Notre Dame
phone : (331)43.26.71.80
fax : (331)43.26.89.38
http://www.paris.org/paris-cgi/PDB/hotel.cgi?htl1983
----------------------- *** -----------------------
CALIFORNIA =20
32, rue des Ecoles; 75005 PARIS
Metro Maubert Mutualit=E9
RER Saint Michel - Notre Dame
phone : (331)46.34.12.90
fax : (331)46.34.75.52
http://www.paris.org/paris-cgi/PDB/hotel.cgi?htl1883

GRANDS HOMMES (Des)
17, place du Panth=E9on; 75005 PARIS
Metro Maubert Mutualit=E9
RER Luxembourg
phone (331)46.34.19.60
fax (331)43.26.67.32
http://www.paris.org/paris-cgi/PDB/hotel.cgi?htl1889
---------------------- ** --------------------------
CLUNY SORBONNE=20
8, rue Victor Cousin; 75005 PARIS
Metro Cluny - Sorbonne
RER Luxembourg
Phone : (331)43.54.66.66
fax : (331)43.29.68.07
http://www.paris.org/paris-cgi/PDB/hotel.cgi?htl1914

SAINT SEVERIN=20
40, rue Saint-S=E9verin; 75005 PARIS
Metro Saint Michel
RER Saint Michel - Notre Dame
phone : (331)46.34.05.70
fax : (331)46.33.84.47
http://www.paris.org/paris-cgi/PDB/hotel.cgi?htl1936
------------------------ * --------------------------
EXCELSIOR=20
20 Rue Cujas; 75005 PARIS
Metro Luxembourg
RER Luxembourg
phone : (331)46.34.79.50
fax : (331)43.54.87.10
http://www.paris.org/paris-cgi/PDB/hotel.cgi?htl1950

GERSON -  - F - Legend
14, rue de la Sorbonne; 75005 PARIS
Metro Cluny - Sorbonne
RER Luxembourg
phone : (331)43.54.28.40
http://www.paris.org/paris-cgi/PDB/hotel.cgi?htl1953
--------------------------------------------------



--=20
-----------------------------------------------------------------------
          __                  _______  _______      _______  _    __
         / /\                / ___  / / ___  / __  / _____/ / | _/ /
        / /  \ Laboratoire  / /__/ / / /__/ / /_/ / /____  /  |/  /
       / / /\ \            / _____/ / _  __/ __  /____  / / /|_/ /
      / / /\ \ \          / /      / / | |  / / _____/ / / /  / /
     / / /  \ \ \        /_/      /_/  |_| /_/ /______/ /_/  /_/
    / / /    \ \ \
   / / /      \ \ \
  / /_/________\ \ \   Khaldoun AL AGHA - Equipe R=E9seaux
 /_/____________\_\/\  Email : Khaldoun.Alagha@prism.uvsq.fr
 \_\_______________\/  http://www.prism.uvsq.fr/public/alagha =20

Universite Versailles Saint Quentin          =20
45, avenue des Etats-Unis                      tel : +33 (1) 39 25 40 92
78 035 VERSAILLES Cedex (France)               Fax : +33 (1) 39 25 40 57=20
------------------------------------------------------------------------


From rem-conf-request@es.net Thu Apr 10 12:09:29 1997 
Received: from alpha.xerox.com by osi-west.es.net with ESnet SMTP (PP);
          Thu, 10 Apr 1997 09:09:11 -0700
Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com 
          with SMTP id <17057(5)>; Thu, 10 Apr 1997 09:08:47 PDT
Received: from localhost by crevenia.parc.xerox.com with SMTP id <177486>;
          Thu, 10 Apr 1997 09:08:39 -0700
To: "W. Richard Stevens" <rstevens@kohala.com>
cc: ietf@ietf.org, rem-conf@es.net
Subject: Re: lack of mbone next Friday
In-reply-to: Your message of "Thu, 03 Apr 97 13:11:54 PST." <199704032111.OAA09630@kohala.kohala.com>
Date: Thu, 10 Apr 1997 09:08:30 PDT
Sender: Bill Fenner <fenner@parc.xerox.com>
From: Bill Fenner <fenner@parc.xerox.com>
Message-Id: <97Apr10.090839pdt.177486@crevenia.parc.xerox.com>

The historical reasons for not multicasting on Friday are lack of
equipment (rented A/V equipment) and lack of staff.  Van Jacobson
brought a spare camera, and we have enough volunteers that I think we
can multicast this Friday's IPNGWG session.  The video quality might
not be as good as the rest of the week but we will hopefully have most
of the slides available in wb.

I think that the IETF's organizers need to know if the IETF community
thinks this should be a continuing commitment (e.g. get rid of the
tradition of not multicasting on Friday), since there's not much
likelyhood that we will have volunteers and spare equipment for every
meeting.

  Bill

From rem-conf-request@tmpmail.es.net Thu Apr 10 12:29:10 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Thu, 10 Apr 1997 09:28:49 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wFMPi-0003Ci-00; Thu, 10 Apr 1997 09:09:30 -0700
To: "W. Richard Stevens" <rstevens@kohala.com>
cc: ietf@ietf.org, rem-conf@es.net
Subject: Re: lack of mbone next Friday
In-reply-to: Your message of "Thu, 03 Apr 97 13:11:54 PST." <199704032111.OAA09630@kohala.kohala.com>
Date: Thu, 10 Apr 1997 09:08:30 PDT
Sender: Bill Fenner <fenner@parc.xerox.com>
From: Bill Fenner <fenner@parc.xerox.com>
Message-Id: <97Apr10.090839pdt.177486@crevenia.parc.xerox.com>
Resent-Message-ID: <"Vab9D2.0.V03.w2HJp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Thu, 10 Apr 1997 09:09:30 -0700

The historical reasons for not multicasting on Friday are lack of
equipment (rented A/V equipment) and lack of staff.  Van Jacobson
brought a spare camera, and we have enough volunteers that I think we
can multicast this Friday's IPNGWG session.  The video quality might
not be as good as the rest of the week but we will hopefully have most
of the slides available in wb.

I think that the IETF's organizers need to know if the IETF community
thinks this should be a continuing commitment (e.g. get rid of the
tradition of not multicasting on Friday), since there's not much
likelyhood that we will have volunteers and spare equipment for every
meeting.

  Bill


From rem-conf-request@es.net Thu Apr 10 12:38:05 1997 
Received: from iltwd02.italtel.it (actually ns.italtel.it) by osi-west.es.net 
          with ESnet SMTP (PP); Thu, 10 Apr 1997 09:37:54 -0700
Received: by iltwd02.italtel.it (5.65/sal-941215); id AA20112;
          Thu, 10 Apr 97 18:38:25 +0200
Received: by iltwd03.settimo.italtel.it (5.65/sal-941220); id AA03470;
          Thu, 10 Apr 97 18:16:53 +0200
Received: by ic8u32.settimo.italtel.it; id AA12092;
          Thu, 10 Apr 1997 18:14:28 +0200
Message-Id: <9704101614.AA12092@ic8u32.settimo.italtel.it>
Received: from iltd26.settimo.italtel.it by ilt9h01 with SMTP (1.37.109.4/16.2) 
          id AA01154; Thu, 10 Apr 97 18:02:51 -0400
Comments: Authenticated sender is <gobbi@ilt9h01>
From: Roberta GOBBI <gobbi@settimo.italtel.it>
To: distribution:; (see end of body)
Date: Tue, 22 Apr 1997 18:05:22 +0000
Subject: IS&N'97 conference in Italy
Cc: roberta.gobbi@italtel.it, eurorim@iao.fhg.de, sii@iao.fhg.de
Priority: urgent
X-Mailer: Pegasus Mail for Windows (v2.23)

Dear Madame/Sirs

You all have, I hope, received copies of the "Call for Partecipation"
brochure for the IS&N'97 Conference.  

The IS&N'97 conference will be the European  event on Technology for 
Cooperative Competion: it will be held on 27-29 May 97 in Cernobbio, 
on Como lake in Italy(what has benn called the most beautiful lake in 
the world.

The conference provides a forum for the discussion of issues and the
exchange of outstanding technical results related to the engineering
of advanced communication services and experiments on their use.

Topics to be addressed at the conference include: 
 
   open architectures and interfaces
   evolution of Intelligent Networks and migrationissues 
   open distributed processing for communication services 
   human machine interfaces 
   management, security and integrity of services and systems
   interdomain management
   service interaction .
   intelligent agent technology 
   quality of service 
   service analysis and design 
   new trends in multimedia and mobile services.

The confence will also include background seminar on person-to person 
real time communications over Internet, mobile agents, CORBA 
standards and architectures for multimedia services.

If you not aware about this event, please have a look at the Web 
Site:

  www.italtel.it/drsc/isn97/head.htm

or feel free to contact me !


See you in Cernobbio


     regards


                                    Roberta Gobbi
                       IS&N'97 Organising Committee


                    
----------------------------------------------------------
Roberta Gobbi
Italtel
Central Reserch Laboratories
20019 Castelletto di Settimo Milanese (MI) Italy

tel. +39.2.43887240
fax. +39.2.43887989
E-Mail: gobbi@settimo.italtel.it
----------------------------------------------------------

%%% overflow headers %%%
To: chiueh@cs.sunysb.edu, chlamtac@BCN.BU.EDU, cnom@maestro.bellcore.com,
        commsoft@cc.bellcore.com, comswtc@gmu.edu,
        cost237-transport@comp.lancs.ac.uk, danzig@pollux.usc.edu,
        dbarbara@bellcore.com, dboff@ddn-pac.ddn.mil, dbworld@cs.wisc.edu,
        eddie.hsu@jpl.nasa.gov, end2end-interest@isi.edu, epitoura@cc.uoi.gr,
        f-troup@CODEX.CIS.UPENN.EDU, grossman@uic.edu, helm@seas.gwu.edu,
        hfk@research.att.com, hipparch@sophia.inria.fr,
        ian@cesdis1.gsfc.nasa.gov, ieeetcpc@ccvm.sunysb.edu,
        jimf@aro.nctu.edu.tw, mhd@seas.smu.edu, mobile-ip@Tadpole.com,
        msmith@osat.hq.nasa.gov, nishida@dc.kdd.com,
        padmanab@joyride.CS.Berkeley.EDU, pat.gary@gsfc.nasa.gov,
        ralonso@peanut.sarnoff.com, randy@cs.Berkeley.edu, rem-conf@es.net,
        reres@laas.fr, rgopal@hns.com, rhoward@sses2.cta.com,
        kuvs-elg@fokus.gmd.de, sig-dsm@doc.ic.ac.uk, parva@uni-paderborn.de,
        cabernet-events@ncl.ac.uk, comsoc.tac@tab.ieee.org,
        end2end-interest@venera.isi.edu, rem-conf-request@es.net,
        multicomm@cc.bellcore.com, globecom@signet.com.sg,
        cnom@maestro.bellcore.com, enternet@bbn.com, ietf@CNRI.Reston.VA.US,
        itc@fokus.gmd.de, tccc@cs.umass.educ, omsoc-tcii@ieee.com,
        commsoft@cc.bellcore.com, comswtc@gmu.edu, ifip-nm@bbn.com,
        nmf-members@nmf.com, ieee.announce@bellcore.com,
        cellular@dfv.rwth-aachen.edu, aurel@ctr.columbia.edu,
        tosca-all@teltec.dcu.ie, osm@osm.net, rfmlist@olympus.algo.com.gr,
        allprospect@fokus.gmd.de, otm@sics.se, BM-List1@cs.ucdavis.edu,
        cabernet-events@ncl.ac.uk, cellular@dfv.rwth-aachen.edu,
        cnom@maestro.bellcore.com, comcoc.bog@tab.ieee.org,
        commsoft@cc.bellcore.com, comsoc.bog@tab.ieee.org,
        comsoc.tac@tab.ieee.org, comsoc-chapters@ieee.org,
        comsoc-gicb@ieee.org, comsoc-itii@ieee.com, comsoc-tcii@ieee.com,
        comsoft@cc.bellcore.com, comswtc@gmu.edu,
        cost237-transport@comp.lancs.ac.uk, ctc-members@redbank.tinac.com,
        a.m.clarke@lut.ac.uk, a.whitefield@ucl.ac.uk,
        a_valle@ccuma0.sci.uma.es, abensour@ralvm29.vnet.ibm.com,
        abosch@samba.cnb.uam.es, abot@fel.tno.nl, abugos@gte.com,
        acampos@sesa.es, acparmij@si.ehu.es, dmin-red@uned.es,
        aedima@fme.upc.es, ag@cray-communications.co.uk,
        agostino.moncalvo@cselt.stet.it, agtagg@oxford-brookes.ac.uk,
        ahmed@res.enst.fr, ajc@inesc.pt, ajw@mari.co.uk, akt@sasig.saic,
        al@vnet.ibm.com, alain_combastel@eurokom.ie,
        alarcon@mozart.econom.uv.es, alba@iit.upco.es, alcatel@cnuce.cnr.it,
        alexander_kotsanas@eurokom.ie, alfon@micalet.cap.gva.es,
        alfonso@ccucvx.unican.es, algayres@verilog.fr,
        allkins_m_d@bt-web.bt.co.uk, altwegg@tech.ascom.ch,
        ana.segovia@madrid.iber.es, ana@cica.es, analysys@cix.compulink.co.uk,
        ananos@av.es, ade.es@yeti.dit.upm.es, andre.boulard@lannion.cnet.fr,
        andreas.grebe@fernuni-hagen.de, andreas_papoulias@eurokom.ie,
        andres@die.upm.es, angelo.pelissier@eurokom.ie,
        antonio.ruiperez@human.uned.es, apatel@ccvax.ucd.ie,
        apfeiffer@sigos.de, seiv10!apr@ic8u32.settimo.italtel.it, apr@sesa.es,
        ardito@crrai.it, arek@rsc.sel.de, arg@stu.spb.su, ariaudo@crrai.it,
        aribeiro@marconi.pt, asepulcr@cc.upv.es, asko.vilavaara@tel.vtt.fi,
        aspa@tech.ascom.ch, atte.kortekangas@tic.vtt.fi,
        awalker@intgp1.att.com, awu@dg13.cec.be, b.evans@ee.surrey.ac.uk,
        b.mobasser@eurokom.ie, baets@intec.rug.ac.be, balu_g_l@bt-web.bt.co.uk,
        balzui@@iboenea.bitnet, baradel@itmi.fr, barbera@iris-dcp.es,
        barg@emit.bremer.vulkan.de, bauerfeld@deteberkom.detecon.d400.de,
        baumgart@informatik.settimo.italtel.it, bdunn@hq.teagasc.ie,
        belda@mozart.econom.uv.es, benolie@tid.es, bensberg.itc@eurokom.ie,
        bermudez@aimat.cesga.es, iabgsz!bernd@ic8u32.settimo.italtel.it,
        berts@idca.tds.philips.nl, beuker@prl.philips.nl,
        beum033@mailer.cira.it, bfs@lab.jt.dk, bienvenido@ugr.es, bierduempel
%%% end overflow headers %%%

From rem-conf-request@tmpmail.es.net Thu Apr 10 12:50:12 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Thu, 10 Apr 1997 09:50:04 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wFMse-0003c4-00; Thu, 10 Apr 1997 09:39:24 -0700
Message-Id: <9704101614.AA12092@ic8u32.settimo.italtel.it>
Comments: Authenticated sender is <gobbi@ilt9h01>
From: Roberta GOBBI <gobbi@settimo.italtel.it>
To: distribution:; (see end of body)
Date: Tue, 22 Apr 1997 18:05:22 +0000
Subject: IS&N'97 conference in Italy
Cc: roberta.gobbi@italtel.it, eurorim@iao.fhg.de, sii@iao.fhg.de
Priority: urgent
X-Mailer: Pegasus Mail for Windows (v2.23)
Resent-Message-ID: <"IS8y2.0.3P3.yUHJp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Thu, 10 Apr 1997 09:39:24 -0700

Dear Madame/Sirs

You all have, I hope, received copies of the "Call for Partecipation"
brochure for the IS&N'97 Conference.  

The IS&N'97 conference will be the European  event on Technology for 
Cooperative Competion: it will be held on 27-29 May 97 in Cernobbio, 
on Como lake in Italy(what has benn called the most beautiful lake in 
the world.

The conference provides a forum for the discussion of issues and the
exchange of outstanding technical results related to the engineering
of advanced communication services and experiments on their use.

Topics to be addressed at the conference include: 
 
   open architectures and interfaces
   evolution of Intelligent Networks and migrationissues 
   open distributed processing for communication services 
   human machine interfaces 
   management, security and integrity of services and systems
   interdomain management
   service interaction .
   intelligent agent technology 
   quality of service 
   service analysis and design 
   new trends in multimedia and mobile services.

The confence will also include background seminar on person-to person 
real time communications over Internet, mobile agents, CORBA 
standards and architectures for multimedia services.

If you not aware about this event, please have a look at the Web 
Site:

  www.italtel.it/drsc/isn97/head.htm

or feel free to contact me !


See you in Cernobbio


     regards


                                    Roberta Gobbi
                       IS&N'97 Organising Committee


                    
----------------------------------------------------------
Roberta Gobbi
Italtel
Central Reserch Laboratories
20019 Castelletto di Settimo Milanese (MI) Italy

tel. +39.2.43887240
fax. +39.2.43887989
E-Mail: gobbi@settimo.italtel.it
----------------------------------------------------------

%%% overflow headers %%%
To: chiueh@cs.sunysb.edu, chlamtac@BCN.BU.EDU, cnom@maestro.bellcore.com,
        commsoft@cc.bellcore.com, comswtc@gmu.edu,
        cost237-transport@comp.lancs.ac.uk, danzig@pollux.usc.edu,
        dbarbara@bellcore.com, dboff@ddn-pac.ddn.mil, dbworld@cs.wisc.edu,
        eddie.hsu@jpl.nasa.gov, end2end-interest@isi.edu, epitoura@cc.uoi.gr,
        f-troup@CODEX.CIS.UPENN.EDU, grossman@uic.edu, helm@seas.gwu.edu,
        hfk@research.att.com, hipparch@sophia.inria.fr,
        ian@cesdis1.gsfc.nasa.gov, ieeetcpc@ccvm.sunysb.edu,
        jimf@aro.nctu.edu.tw, mhd@seas.smu.edu, mobile-ip@Tadpole.com,
        msmith@osat.hq.nasa.gov, nishida@dc.kdd.com,
        padmanab@joyride.CS.Berkeley.EDU, pat.gary@gsfc.nasa.gov,
        ralonso@peanut.sarnoff.com, randy@cs.Berkeley.edu, rem-conf@es.net,
        reres@laas.fr, rgopal@hns.com, rhoward@sses2.cta.com,
        kuvs-elg@fokus.gmd.de, sig-dsm@doc.ic.ac.uk, parva@uni-paderborn.de,
        cabernet-events@ncl.ac.uk, comsoc.tac@tab.ieee.org,
        end2end-interest@venera.isi.edu, rem-conf-request@es.net,
        multicomm@cc.bellcore.com, globecom@signet.com.sg,
        cnom@maestro.bellcore.com, enternet@bbn.com, ietf@CNRI.Reston.VA.US,
        itc@fokus.gmd.de, tccc@cs.umass.educ, omsoc-tcii@ieee.com,
        commsoft@cc.bellcore.com, comswtc@gmu.edu, ifip-nm@bbn.com,
        nmf-members@nmf.com, ieee.announce@bellcore.com,
        cellular@dfv.rwth-aachen.edu, aurel@ctr.columbia.edu,
        tosca-all@teltec.dcu.ie, osm@osm.net, rfmlist@olympus.algo.com.gr,
        allprospect@fokus.gmd.de, otm@sics.se, BM-List1@cs.ucdavis.edu,
        cabernet-events@ncl.ac.uk, cellular@dfv.rwth-aachen.edu,
        cnom@maestro.bellcore.com, comcoc.bog@tab.ieee.org,
        commsoft@cc.bellcore.com, comsoc.bog@tab.ieee.org,
        comsoc.tac@tab.ieee.org, comsoc-chapters@ieee.org,
        comsoc-gicb@ieee.org, comsoc-itii@ieee.com, comsoc-tcii@ieee.com,
        comsoft@cc.bellcore.com, comswtc@gmu.edu,
        cost237-transport@comp.lancs.ac.uk, ctc-members@redbank.tinac.com,
        a.m.clarke@lut.ac.uk, a.whitefield@ucl.ac.uk,
        a_valle@ccuma0.sci.uma.es, abensour@ralvm29.vnet.ibm.com,
        abosch@samba.cnb.uam.es, abot@fel.tno.nl, abugos@gte.com,
        acampos@sesa.es, acparmij@si.ehu.es, dmin-red@uned.es,
        aedima@fme.upc.es, ag@cray-communications.co.uk,
        agostino.moncalvo@cselt.stet.it, agtagg@oxford-brookes.ac.uk,
        ahmed@res.enst.fr, ajc@inesc.pt, ajw@mari.co.uk, akt@sasig.saic,
        al@vnet.ibm.com, alain_combastel@eurokom.ie,
        alarcon@mozart.econom.uv.es, alba@iit.upco.es, alcatel@cnuce.cnr.it,
        alexander_kotsanas@eurokom.ie, alfon@micalet.cap.gva.es,
        alfonso@ccucvx.unican.es, algayres@verilog.fr,
        allkins_m_d@bt-web.bt.co.uk, altwegg@tech.ascom.ch,
        ana.segovia@madrid.iber.es, ana@cica.es, analysys@cix.compulink.co.uk,
        ananos@av.es, ade.es@yeti.dit.upm.es, andre.boulard@lannion.cnet.fr,
        andreas.grebe@fernuni-hagen.de, andreas_papoulias@eurokom.ie,
        andres@die.upm.es, angelo.pelissier@eurokom.ie,
        antonio.ruiperez@human.uned.es, apatel@ccvax.ucd.ie,
        apfeiffer@sigos.de, seiv10!apr@ic8u32.settimo.italtel.it, apr@sesa.es,
        ardito@crrai.it, arek@rsc.sel.de, arg@stu.spb.su, ariaudo@crrai.it,
        aribeiro@marconi.pt, asepulcr@cc.upv.es, asko.vilavaara@tel.vtt.fi,
        aspa@tech.ascom.ch, atte.kortekangas@tic.vtt.fi,
        awalker@intgp1.att.com, awu@dg13.cec.be, b.evans@ee.surrey.ac.uk,
        b.mobasser@eurokom.ie, baets@intec.rug.ac.be, balu_g_l@bt-web.bt.co.uk,
        balzui@@iboenea.bitnet, baradel@itmi.fr, barbera@iris-dcp.es,
        barg@emit.bremer.vulkan.de, bauerfeld@deteberkom.detecon.d400.de,
        baumgart@informatik.settimo.italtel.it, bdunn@hq.teagasc.ie,
        belda@mozart.econom.uv.es, benolie@tid.es, bensberg.itc@eurokom.ie,
        bermudez@aimat.cesga.es, iabgsz!bernd@ic8u32.settimo.italtel.it,
        berts@idca.tds.philips.nl, beuker@prl.philips.nl,
        beum033@mailer.cira.it, bfs@lab.jt.dk, bienvenido@ugr.es, bierduempel
%%% end overflow headers %%%


From rem-conf-request@es.net Thu Apr 10 13:48:29 1997 
Received: from iltwd02.italtel.it (actually ns.italtel.it) by osi-west.es.net 
          with ESnet SMTP (PP); Thu, 10 Apr 1997 10:48:23 -0700
Received: by iltwd02.italtel.it (5.65/sal-941215); id AA24497;
          Thu, 10 Apr 97 19:15:37 +0200
Received: by iltwd03.settimo.italtel.it (5.65/sal-941220); id AA20790;
          Thu, 10 Apr 97 15:37:27 +0200
Received: by ic8u32.settimo.italtel.it; id AA09022;
          Thu, 10 Apr 1997 15:35:02 +0200
Message-Id: <9704101335.AA09022@ic8u32.settimo.italtel.it>
Received: from iltd26.settimo.italtel.it by ilt9h01 with SMTP (1.37.109.4/16.2) 
          id AA00406; Thu, 10 Apr 97 15:22:39 -0400
Comments: Authenticated sender is <gobbi@ilt9h01>
From: Roberta GOBBI <gobbi@settimo.italtel.it>
To: distribution:; (see end of body)
Date: Tue, 22 Apr 1997 15:25:09 +0000
Subject: IS&N'97 conference in Italy
Cc: roberta.gobbi@italtel.it, eurorim@iao.fhg.de, sii@iao.fhg.de
Priority: urgent
X-Mailer: Pegasus Mail for Windows (v2.23)

Dear Madame/Sirs

You all have, I hope, received copies of the "Call for Partecipation"
brochure for the IS&N'97 Conference.  

The IS&N'97 conference will be the European  event on Technology for 
Cooperative Competion: it will be held on 27-29 May 97 in Cernobbio, 
on Como lake in Italy(what has benn called the most beautiful lake in 
the world.

The conference provides a forum for the discussion of issues and the
exchange of outstanding technical results related to the engineering
of advanced communication services and experiments on their use.

Topics to be addressed at the conference include: 
 
   open architectures and interfaces
   evolution of Intelligent Networks and migrationissues 
   open distributed processing for communication services 
   human machine interfaces 
   management, security and integrity of services and systems
   interdomain management
   service interaction .
   intelligent agent technology 
   quality of service 
   service analysis and design 
   new trends in multimedia and mobile services.

The confence will also include background seminar on person-to person 
real time communications over Internet, mobile agents, CORBA 
standards and architectures for multimedia services.

If you not aware about this event, please have a look at the Web 
Site:

  www.italtel.it/drsc/isn97/head.htm

or feel free to contact me !


See you in Cernobbio


     regards


                                    Roberta Gobbi
                       IS&N'97 Organising Committee


                    
----------------------------------------------------------
Roberta Gobbi
Italtel
Central Reserch Laboratories
20019 Castelletto di Settimo Milanese (MI) Italy

tel. +39.2.43887240
fax. +39.2.43887989
E-Mail: gobbi@settimo.italtel.it
----------------------------------------------------------

%%% overflow headers %%%
To: chiueh@cs.sunysb.edu, chlamtac@BCN.BU.EDU, cnom@maestro.bellcore.com,
        commsoft@cc.bellcore.com, comswtc@gmu.edu,
        cost237-transport@comp.lancs.ac.uk, danzig@pollux.usc.edu,
        dbarbara@bellcore.com, dboff@ddn-pac.ddn.mil, dbworld@cs.wisc.edu,
        eddie.hsu@jpl.nasa.gov, end2end-interest@isi.edu, epitoura@cc.uoi.gr,
        f-troup@CODEX.CIS.UPENN.EDU, grossman@uic.edu, helm@seas.gwu.edu,
        hfk@research.att.com, hipparch@sophia.inria.fr,
        ian@cesdis1.gsfc.nasa.gov, ieeetcpc@ccvm.sunysb.edu,
        jimf@aro.nctu.edu.tw, mhd@seas.smu.edu, mobile-ip@Tadpole.com,
        msmith@osat.hq.nasa.gov, nishida@dc.kdd.com,
        padmanab@joyride.CS.Berkeley.EDU, pat.gary@gsfc.nasa.gov,
        ralonso@peanut.sarnoff.com, randy@cs.Berkeley.edu, rem-conf@es.net,
        reres@laas.fr, rgopal@hns.com, rhoward@sses2.cta.com,
        kuvs-elg@fokus.gmd.de, sig-dsm@doc.ic.ac.uk, parva@uni-paderborn.de,
        cabernet-events@ncl.ac.uk, comsoc.tac@tab.ieee.org,
        end2end-interest@venera.isi.edu, rem-conf-request@es.net,
        multicomm@cc.bellcore.com, globecom@signet.com.sg,
        cnom@maestro.bellcore.com, enternet@bbn.com, ietf@CNRI.Reston.VA.US,
        itc@fokus.gmd.de, tccc@cs.umass.educ, omsoc-tcii@ieee.com,
        commsoft@cc.bellcore.com, comswtc@gmu.edu, ifip-nm@bbn.com,
        nmf-members@nmf.com, ieee.announce@bellcore.com,
        cellular@dfv.rwth-aachen.edu, aurel@ctr.columbia.edu,
        tosca-all@teltec.dcu.ie, osm@osm.net, rfmlist@olympus.algo.com.gr,
        allprospect@fokus.gmd.de, otm@sics.se, BM-List1@cs.ucdavis.edu,
        cabernet-events@ncl.ac.uk, cellular@dfv.rwth-aachen.edu,
        cnom@maestro.bellcore.com, comcoc.bog@tab.ieee.org,
        commsoft@cc.bellcore.com, comsoc.bog@tab.ieee.org,
        comsoc.tac@tab.ieee.org, comsoc-chapters@ieee.org,
        comsoc-gicb@ieee.org, comsoc-itii@ieee.com, comsoc-tcii@ieee.com,
        comsoft@cc.bellcore.com, comswtc@gmu.edu,
        cost237-transport@comp.lancs.ac.uk, ctc-members@redbank.tinac.com,
        a.m.clarke@lut.ac.uk, a.whitefield@ucl.ac.uk,
        a_valle@ccuma0.sci.uma.es, abensour@ralvm29.vnet.ibm.com,
        abosch@samba.cnb.uam.es, abot@fel.tno.nl, abugos@gte.com,
        acampos@sesa.es, acparmij@si.ehu.es, dmin-red@uned.es,
        aedima@fme.upc.es, ag@cray-communications.co.uk,
        agostino.moncalvo@cselt.stet.it, agtagg@oxford-brookes.ac.uk,
        ahmed@res.enst.fr, ajc@inesc.pt, ajw@mari.co.uk, akt@sasig.saic,
        al@vnet.ibm.com, alain_combastel@eurokom.ie,
        alarcon@mozart.econom.uv.es, alba@iit.upco.es, alcatel@cnuce.cnr.it,
        alexander_kotsanas@eurokom.ie, alfon@micalet.cap.gva.es,
        alfonso@ccucvx.unican.es, algayres@verilog.fr,
        allkins_m_d@bt-web.bt.co.uk, altwegg@tech.ascom.ch,
        ana.segovia@madrid.iber.es, ana@cica.es, analysys@cix.compulink.co.uk,
        ananos@av.es, ade.es@yeti.dit.upm.es, andre.boulard@lannion.cnet.fr,
        andreas.grebe@fernuni-hagen.de, andreas_papoulias@eurokom.ie,
        andres@die.upm.es, angelo.pelissier@eurokom.ie,
        antonio.ruiperez@human.uned.es, apatel@ccvax.ucd.ie,
        apfeiffer@sigos.de, seiv10!apr@ic8u32.settimo.italtel.it, apr@sesa.es,
        ardito@crrai.it, arek@rsc.sel.de, arg@stu.spb.su, ariaudo@crrai.it,
        aribeiro@marconi.pt, asepulcr@cc.upv.es, asko.vilavaara@tel.vtt.fi,
        aspa@tech.ascom.ch, atte.kortekangas@tic.vtt.fi,
        awalker@intgp1.att.com, awu@dg13.cec.be, b.evans@ee.surrey.ac.uk,
        b.mobasser@eurokom.ie, baets@intec.rug.ac.be, balu_g_l@bt-web.bt.co.uk,
        balzui@@iboenea.bitnet, baradel@itmi.fr, barbera@iris-dcp.es,
        barg@emit.bremer.vulkan.de, bauerfeld@deteberkom.detecon.d400.de,
        baumgart@informatik.settimo.italtel.it, bdunn@hq.teagasc.ie,
        belda@mozart.econom.uv.es, benolie@tid.es, bensberg.itc@eurokom.ie,
        bermudez@aimat.cesga.es, iabgsz!bernd@ic8u32.settimo.italtel.it,
        berts@idca.tds.philips.nl, beuker@prl.philips.nl,
        beum033@mailer.cira.it, bfs@lab.jt.dk, bienvenido@ugr.es, bierduempel
%%% end overflow headers %%%

From rem-conf-request@tmpmail.es.net Thu Apr 10 14:06:13 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Thu, 10 Apr 1997 11:06:02 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wFNxX-00048P-00; Thu, 10 Apr 1997 10:48:31 -0700
Message-Id: <9704101335.AA09022@ic8u32.settimo.italtel.it>
Comments: Authenticated sender is <gobbi@ilt9h01>
From: Roberta GOBBI <gobbi@settimo.italtel.it>
To: distribution:; (see end of body)
Date: Tue, 22 Apr 1997 15:25:09 +0000
Subject: IS&N'97 conference in Italy
Cc: roberta.gobbi@italtel.it, eurorim@iao.fhg.de, sii@iao.fhg.de
Priority: urgent
X-Mailer: Pegasus Mail for Windows (v2.23)
Resent-Message-ID: <"uEQ8J2.0.Ou3.lVIJp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Thu, 10 Apr 1997 10:48:31 -0700

Dear Madame/Sirs

You all have, I hope, received copies of the "Call for Partecipation"
brochure for the IS&N'97 Conference.  

The IS&N'97 conference will be the European  event on Technology for 
Cooperative Competion: it will be held on 27-29 May 97 in Cernobbio, 
on Como lake in Italy(what has benn called the most beautiful lake in 
the world.

The conference provides a forum for the discussion of issues and the
exchange of outstanding technical results related to the engineering
of advanced communication services and experiments on their use.

Topics to be addressed at the conference include: 
 
   open architectures and interfaces
   evolution of Intelligent Networks and migrationissues 
   open distributed processing for communication services 
   human machine interfaces 
   management, security and integrity of services and systems
   interdomain management
   service interaction .
   intelligent agent technology 
   quality of service 
   service analysis and design 
   new trends in multimedia and mobile services.

The confence will also include background seminar on person-to person 
real time communications over Internet, mobile agents, CORBA 
standards and architectures for multimedia services.

If you not aware about this event, please have a look at the Web 
Site:

  www.italtel.it/drsc/isn97/head.htm

or feel free to contact me !


See you in Cernobbio


     regards


                                    Roberta Gobbi
                       IS&N'97 Organising Committee


                    
----------------------------------------------------------
Roberta Gobbi
Italtel
Central Reserch Laboratories
20019 Castelletto di Settimo Milanese (MI) Italy

tel. +39.2.43887240
fax. +39.2.43887989
E-Mail: gobbi@settimo.italtel.it
----------------------------------------------------------

%%% overflow headers %%%
To: chiueh@cs.sunysb.edu, chlamtac@BCN.BU.EDU, cnom@maestro.bellcore.com,
        commsoft@cc.bellcore.com, comswtc@gmu.edu,
        cost237-transport@comp.lancs.ac.uk, danzig@pollux.usc.edu,
        dbarbara@bellcore.com, dboff@ddn-pac.ddn.mil, dbworld@cs.wisc.edu,
        eddie.hsu@jpl.nasa.gov, end2end-interest@isi.edu, epitoura@cc.uoi.gr,
        f-troup@CODEX.CIS.UPENN.EDU, grossman@uic.edu, helm@seas.gwu.edu,
        hfk@research.att.com, hipparch@sophia.inria.fr,
        ian@cesdis1.gsfc.nasa.gov, ieeetcpc@ccvm.sunysb.edu,
        jimf@aro.nctu.edu.tw, mhd@seas.smu.edu, mobile-ip@Tadpole.com,
        msmith@osat.hq.nasa.gov, nishida@dc.kdd.com,
        padmanab@joyride.CS.Berkeley.EDU, pat.gary@gsfc.nasa.gov,
        ralonso@peanut.sarnoff.com, randy@cs.Berkeley.edu, rem-conf@es.net,
        reres@laas.fr, rgopal@hns.com, rhoward@sses2.cta.com,
        kuvs-elg@fokus.gmd.de, sig-dsm@doc.ic.ac.uk, parva@uni-paderborn.de,
        cabernet-events@ncl.ac.uk, comsoc.tac@tab.ieee.org,
        end2end-interest@venera.isi.edu, rem-conf-request@es.net,
        multicomm@cc.bellcore.com, globecom@signet.com.sg,
        cnom@maestro.bellcore.com, enternet@bbn.com, ietf@CNRI.Reston.VA.US,
        itc@fokus.gmd.de, tccc@cs.umass.educ, omsoc-tcii@ieee.com,
        commsoft@cc.bellcore.com, comswtc@gmu.edu, ifip-nm@bbn.com,
        nmf-members@nmf.com, ieee.announce@bellcore.com,
        cellular@dfv.rwth-aachen.edu, aurel@ctr.columbia.edu,
        tosca-all@teltec.dcu.ie, osm@osm.net, rfmlist@olympus.algo.com.gr,
        allprospect@fokus.gmd.de, otm@sics.se, BM-List1@cs.ucdavis.edu,
        cabernet-events@ncl.ac.uk, cellular@dfv.rwth-aachen.edu,
        cnom@maestro.bellcore.com, comcoc.bog@tab.ieee.org,
        commsoft@cc.bellcore.com, comsoc.bog@tab.ieee.org,
        comsoc.tac@tab.ieee.org, comsoc-chapters@ieee.org,
        comsoc-gicb@ieee.org, comsoc-itii@ieee.com, comsoc-tcii@ieee.com,
        comsoft@cc.bellcore.com, comswtc@gmu.edu,
        cost237-transport@comp.lancs.ac.uk, ctc-members@redbank.tinac.com,
        a.m.clarke@lut.ac.uk, a.whitefield@ucl.ac.uk,
        a_valle@ccuma0.sci.uma.es, abensour@ralvm29.vnet.ibm.com,
        abosch@samba.cnb.uam.es, abot@fel.tno.nl, abugos@gte.com,
        acampos@sesa.es, acparmij@si.ehu.es, dmin-red@uned.es,
        aedima@fme.upc.es, ag@cray-communications.co.uk,
        agostino.moncalvo@cselt.stet.it, agtagg@oxford-brookes.ac.uk,
        ahmed@res.enst.fr, ajc@inesc.pt, ajw@mari.co.uk, akt@sasig.saic,
        al@vnet.ibm.com, alain_combastel@eurokom.ie,
        alarcon@mozart.econom.uv.es, alba@iit.upco.es, alcatel@cnuce.cnr.it,
        alexander_kotsanas@eurokom.ie, alfon@micalet.cap.gva.es,
        alfonso@ccucvx.unican.es, algayres@verilog.fr,
        allkins_m_d@bt-web.bt.co.uk, altwegg@tech.ascom.ch,
        ana.segovia@madrid.iber.es, ana@cica.es, analysys@cix.compulink.co.uk,
        ananos@av.es, ade.es@yeti.dit.upm.es, andre.boulard@lannion.cnet.fr,
        andreas.grebe@fernuni-hagen.de, andreas_papoulias@eurokom.ie,
        andres@die.upm.es, angelo.pelissier@eurokom.ie,
        antonio.ruiperez@human.uned.es, apatel@ccvax.ucd.ie,
        apfeiffer@sigos.de, seiv10!apr@ic8u32.settimo.italtel.it, apr@sesa.es,
        ardito@crrai.it, arek@rsc.sel.de, arg@stu.spb.su, ariaudo@crrai.it,
        aribeiro@marconi.pt, asepulcr@cc.upv.es, asko.vilavaara@tel.vtt.fi,
        aspa@tech.ascom.ch, atte.kortekangas@tic.vtt.fi,
        awalker@intgp1.att.com, awu@dg13.cec.be, b.evans@ee.surrey.ac.uk,
        b.mobasser@eurokom.ie, baets@intec.rug.ac.be, balu_g_l@bt-web.bt.co.uk,
        balzui@@iboenea.bitnet, baradel@itmi.fr, barbera@iris-dcp.es,
        barg@emit.bremer.vulkan.de, bauerfeld@deteberkom.detecon.d400.de,
        baumgart@informatik.settimo.italtel.it, bdunn@hq.teagasc.ie,
        belda@mozart.econom.uv.es, benolie@tid.es, bensberg.itc@eurokom.ie,
        bermudez@aimat.cesga.es, iabgsz!bernd@ic8u32.settimo.italtel.it,
        berts@idca.tds.philips.nl, beuker@prl.philips.nl,
        beum033@mailer.cira.it, bfs@lab.jt.dk, bienvenido@ugr.es, bierduempel
%%% end overflow headers %%%


From rem-conf-request@es.net Thu Apr 10 14:14:09 1997 
Received: from j51.com (actually gorplex.j51.com) by osi-west.es.net 
          with ESnet SMTP (PP); Thu, 10 Apr 1997 11:14:04 -0700
Received: from sprylnet.com ([209.48.0.15]) by j51.com (8.8.5/8.8.5) with SMTP 
          id OAA06822; Thu, 10 Apr 1997 14:12:42 -0400 (EDT)
Message-Id: <3.0.1.32.19970410125205.00692e24@ucs.net>
X-Sender: mark@ucs.net
X-Mailer: Windows Eudora Light Version 3.0.1 (32)
Date: Thu, 10 Apr 1997 12:52:05 -0400
To: Bill Fenner <fenner@parc.xerox.com>
From: Mark Endelman <mark@telematrix.com>
Subject: Re: lack of mbone next Friday
Cc: "W. Richard Stevens" <rstevens@kohala.com>, ietf@ietf.org, rem-conf@es.net
In-Reply-To: <97Apr10.090839pdt.177486@crevenia.parc.xerox.com>
References: <Your message of "Thu,
            03 Apr 97 13:11:54 PST." <199704032111.OAA09630@kohala.kohala.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

How do I unsubscribe to MBone
Mark Endelman, Executive Director, Telematrix
(ph)1-914-353-0311    (fax)1-914-353-0311

From rem-conf-request@tmpmail.es.net Thu Apr 10 14:25:46 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Thu, 10 Apr 1997 11:25:43 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wFOMM-0004RT-00; Thu, 10 Apr 1997 11:14:10 -0700
Message-Id: <3.0.1.32.19970410125205.00692e24@ucs.net>
X-Sender: mark@ucs.net
X-Mailer: Windows Eudora Light Version 3.0.1 (32)
Date: Thu, 10 Apr 1997 12:52:05 -0400
To: Bill Fenner <fenner@parc.xerox.com>
From: Mark Endelman <mark@telematrix.com>
Subject: Re: lack of mbone next Friday
Cc: "W. Richard Stevens" <rstevens@kohala.com>, ietf@ietf.org, rem-conf@es.net
In-Reply-To: <97Apr10.090839pdt.177486@crevenia.parc.xerox.com>
References: <Your message of "Thu,
            03 Apr 97 13:11:54 PST." <199704032111.OAA09630@kohala.kohala.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"k59Jr1.0.sA4.otIJp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Thu, 10 Apr 1997 11:14:10 -0700

How do I unsubscribe to MBone
Mark Endelman, Executive Director, Telematrix
(ph)1-914-353-0311    (fax)1-914-353-0311


From rem-conf-request@es.net Thu Apr 10 15:53:12 1997 
Received: from engr.orst.edu by osi-west.es.net with ESnet SMTP (PP);
          Thu, 10 Apr 1997 12:53:00 -0700
Received: from eel (eel.ENGR.ORST.EDU [128.193.55.69]) 
          by engr.orst.edu (8.8.5/8.8.5) with SMTP id MAA05022 
          for <rem-conf@es.net>; Thu, 10 Apr 1997 12:52:57 -0700 (PDT)
Received: from localhost by eel (SMI-8.6/ENGR-Client) id MAA06892;
          Thu, 10 Apr 1997 12:52:25 -0700
Date: Thu, 10 Apr 1997 12:52:25 -0700 (PDT)
From: Stephane Chatre <chatre@ENGR.ORST.EDU>
To: rem-conf@es.net
Subject: MBone-VCR
Message-ID: <Pine.SOL.3.95.970410124627.6677E-100000@eel.ENGR.ORST.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

I am using the MBone-VCR to record MBone sessions.
So far during playback, there is no synchronization between audio and
video, rendering the VCR useless. For example a 1 minute video stream
takes 5 seconds to be played entirely.

Has anyone been successful in using the VCR to record AND playback a
session?

If the official version of VCR doesn't work, has anybody written a patch
or found a subsidiary tool for recording and playing back?

Thanks,
Stephane.

========================
Stephane Chatre                   Email: chatre@cs.orst.edu          
Department of Computer Science    Phone: (541) 737-5583  (office)     
Oregon State University			 (541) 757-3376   (home)      
                            
Life is what happens to you while you're busy making other plans.
                                        - John Lennon            


From rem-conf-request@tmpmail.es.net Thu Apr 10 16:06:06 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Thu, 10 Apr 1997 13:06:03 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wFPuD-00054m-00; Thu, 10 Apr 1997 12:53:13 -0700
Date: Thu, 10 Apr 1997 12:52:25 -0700 (PDT)
From: Stephane Chatre <chatre@ENGR.ORST.EDU>
To: rem-conf@es.net
Subject: MBone-VCR
Message-ID: <Pine.SOL.3.95.970410124627.6677E-100000@eel.ENGR.ORST.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-ID: <"lirOc.0.xm4.fKKJp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Thu, 10 Apr 1997 12:53:13 -0700

I am using the MBone-VCR to record MBone sessions.
So far during playback, there is no synchronization between audio and
video, rendering the VCR useless. For example a 1 minute video stream
takes 5 seconds to be played entirely.

Has anyone been successful in using the VCR to record AND playback a
session?

If the official version of VCR doesn't work, has anybody written a patch
or found a subsidiary tool for recording and playing back?

Thanks,
Stephane.

========================
Stephane Chatre                   Email: chatre@cs.orst.edu          
Department of Computer Science    Phone: (541) 737-5583  (office)     
Oregon State University			 (541) 757-3376   (home)      
                            
Life is what happens to you while you're busy making other plans.
                                        - John Lennon            



From rem-conf-request@es.net Fri Apr 11 01:07:24 1997 
Received: from msri.org by osi-west.es.net with ESnet SMTP (PP);
          Thu, 10 Apr 1997 22:07:14 -0700
Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id WAA25150 
          for <rem-conf@es.net>; Thu, 10 Apr 1997 22:07:12 -0700 (PDT)
X-Authentication-Warning: msri.org: smap set sender to <nobody@msri.org> using 
                          -f
Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) 
          id sma025090; Thu Apr 10 22:06:08 1997
Received: by hille.msri.org (8.7/MSRI) id WAA28586;
          Thu, 10 Apr 1997 22:06:09 -0700 (PDT)
Date: Thu, 10 Apr 1997 22:06:09 -0700 (PDT)
Message-Id: <199704110506.WAA28586@hille.msri.org>
To: rem-conf@es.net
From: oka <oka@nanotsu.kobe-u.ac.jp>
Reply-to: oka@nanotsu.kobe-u.ac.jp
Subject: Re-broadcasting of Infocom'97

	MBone Broadcast Announcement
	----------------------------

Title:       
	Re-broadcasting of Infocom'97
Date:        
	Apr 15, 1997

Time:        
	08:00 PST8PDT 8 hours

Contact:     
	oka@nanotsu.kobe-u.ac.jp

URL:         
	http://www.ieee.org/comsoc/infocom

Description:        
	Channel-1  8:00 - 16:00 Gigabit WorkShop  









mbone broadcast schedule http://www.msri.org/mbone

From rem-conf-request@es.net Fri Apr 11 01:14:19 1997 
Received: from msri.org by osi-west.es.net with ESnet SMTP (PP);
          Thu, 10 Apr 1997 22:14:13 -0700
Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id WAA25252 
          for <rem-conf@es.net>; Thu, 10 Apr 1997 22:14:12 -0700 (PDT)
X-Authentication-Warning: msri.org: smap set sender to <nobody@msri.org> using 
                          -f
Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) 
          id sma025246; Thu Apr 10 22:13:50 1997
Received: by hille.msri.org (8.7/MSRI) id WAA28613;
          Thu, 10 Apr 1997 22:13:49 -0700 (PDT)
Date: Thu, 10 Apr 1997 22:13:49 -0700 (PDT)
Message-Id: <199704110513.WAA28613@hille.msri.org>
To: rem-conf@es.net
From: oka <oka@nanotsu.kobe-u.ac.jp>
Reply-to: oka@nanotsu.kobe-u.ac.jp
Subject: Re-broadcasting of Infocom'97

	MBone Broadcast Announcement
	----------------------------

Title:       
	Re-broadcasting of Infocom'97
Date:        
	Apr 16, 1997

Time:        
	08:00 PST8PDT 6.5 hours

Contact:     
	oka@nanotsu.kobe-u.ac.jp

URL:         
	http://www.ieee.org/comsoc/infocom

Description:        
	Channel-1   8:00 - 10:00 Keynotes  10:00 - 11:30 ATM Switching I  11:30 - 13:00 ATM Traffic Control  13:00 - 14:30  ATM ABR Services I    Channel 2  10:00 - 11:30 Wireless Networks I  11:30 - 13:00 Optical Networks I  13:00 - 14:30 Panel 1: Broadband Service to the Home









mbone broadcast schedule http://www.msri.org/mbone

From rem-conf-request@es.net Fri Apr 11 01:14:37 1997 
Received: from sirius.ctr.columbia.edu by osi-west.es.net with ESnet SMTP (PP);
          Thu, 10 Apr 1997 22:14:16 -0700
Received: from meteor.ctr.columbia.edu (angin@meteor.ctr.columbia.edu [128.59.68.29]) 
          by sirius.ctr.columbia.edu (8.8.5/8.6.4.287) with ESMTP id BAA22863;
          Fri, 11 Apr 1997 01:14:09 -0400 (EDT)
Received: from localhost (angin@localhost) 
          by meteor.ctr.columbia.edu (8.8.5/8.6.4.788743) with SMTP 
          id BAA14049; Fri, 11 Apr 1997 01:14:07 -0400 (EDT)
Date: Fri, 11 Apr 1997 01:14:07 -0400 (EDT)
From: Oguz Angin <angin@ctr.columbia.edu>
To: rem-conf@es.net
cc: mnl@ctr.columbia.edu
Subject: Comet Group Seminar: John R. Nicol, Distributed Multimedia , 
         Applications Group, GTE Laboratories Incorporated, ``Experiences of , 
         Constructing Distributed Business Multimedia Applications``
Message-ID: <Pine.SUN.3.95q.970411010422.14001A-100000@meteor.ctr.columbia.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



MBone Broadcast Announcement

Title:
    EXPERIENCES OF CONSTRUCTING DISTRIBUTED BUSINESS 
    MULTIMEDIA APPLICATIONS
 
Speaker:
    John R. Nicol, 
    Distributed Multimedia Applications Group,
    GTE Laboratories Incorporated

Date:
    Monday, April 14, 1997

Time:
    12:00 NOON - 1:00 PM EST

Multicast Address:
    audio:  DVI, RTP, 224.2.194.51/21104 , ttl=127

Contact:
    Andrew T. Campbell <campbell@ctr.columbia.edu>

URL:
    http://comet.ctr.columbia.edu/activities/seminars/

Place:
    Interschool Lab. (7th Floor)
    Schapiro Research Building
    Center for Telecommunications Research
    Columbia University
    New York City, USA

Abstract:

As bandwidth becomes increasingly plentiful, a key success factor for
major players in the telecommunications marketplace will center on the
provision of value-added services -- the applications and services that
will ultimately make the underlying network sophistication worthwhile to
its end-users. Based on this belief, GTE Laboratories has been conducting
research in the area of distributed multimedia applications for several
years.

This talk will offer a broad perspective of our experiences of building
prototype distributed business multimedia applications over high speed
networks and more recently the Internet, and will include discussion of
our rational for and approach to developing "concept" multimedia
applications; examples of multimedia applications we have built to date
and how we have used them; as well as coverage of some of the distributed
systems techniques we used to construct our prototypes. 


From rem-conf-request@es.net Fri Apr 11 01:20:20 1997 
Received: from msri.org by osi-west.es.net with ESnet SMTP (PP);
          Thu, 10 Apr 1997 22:20:15 -0700
Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id WAA25411 
          for <rem-conf@es.net>; Thu, 10 Apr 1997 22:20:13 -0700 (PDT)
X-Authentication-Warning: msri.org: smap set sender to <nobody@msri.org> using 
                          -f
Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) 
          id sma025366; Thu Apr 10 22:19:15 1997
Received: by hille.msri.org (8.7/MSRI) id WAA28640;
          Thu, 10 Apr 1997 22:19:15 -0700 (PDT)
Date: Thu, 10 Apr 1997 22:19:15 -0700 (PDT)
Message-Id: <199704110519.WAA28640@hille.msri.org>
To: rem-conf@es.net
From: oka <oka@nanotsu.kobe-u.ac.jp>
Reply-to: oka@nanotsu.kobe-u.ac.jp
Subject: Re-broadcasting of Infocom'97

	MBone Broadcast Announcement
	----------------------------

Title:       
	Re-broadcasting of Infocom'97
Date:        
	Apr 17, 1997

Time:        
	08:00 PST8PDT 7.5 hours

Contact:     
	oka@nanotsu.kobe-u.ac.jp

URL:         
	http://www.ieee.org/comsoc/infocom

Description:        
	Channel-1   8:00 -  9:30 ATM ABR Services II  11:00 - 12:30 Panel2: Routing vs Switching  12:30 - 14:00 ATM Traffic Cntrl II  14:00 - 15:30 ATM ABR Services III    Channel 2   8:00 -  9:30 Optical Networks II   9:30 - 11:00 Wireless Networks II  12:30 - 14:00 Optical Networks III  14:00 - 15:30 Wireless Networks IV









mbone broadcast schedule http://www.msri.org/mbone

From rem-conf-request@tmpmail.es.net Fri Apr 11 01:24:10 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Thu, 10 Apr 1997 22:24:07 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wFYfI-00002E-00; Thu, 10 Apr 1997 22:14:24 -0700
X-Authentication-Warning: msri.org: smap set sender to <nobody@msri.org> using 
                          -f
Date: Thu, 10 Apr 1997 22:13:49 -0700 (PDT)
Message-Id: <199704110513.WAA28613@hille.msri.org>
To: rem-conf@es.net
From: oka <oka@nanotsu.kobe-u.ac.jp>
Reply-to: oka@nanotsu.kobe-u.ac.jp
Subject: Re-broadcasting of Infocom'97
Resent-Message-ID: <"dCSzO2.0.92.mYSJp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Thu, 10 Apr 1997 22:14:24 -0700

	MBone Broadcast Announcement
	----------------------------

Title:       
	Re-broadcasting of Infocom'97
Date:        
	Apr 16, 1997

Time:        
	08:00 PST8PDT 6.5 hours

Contact:     
	oka@nanotsu.kobe-u.ac.jp

URL:         
	http://www.ieee.org/comsoc/infocom

Description:        
	Channel-1   8:00 - 10:00 Keynotes  10:00 - 11:30 ATM Switching I  11:30 - 13:00 ATM Traffic Control  13:00 - 14:30  ATM ABR Services I    Channel 2  10:00 - 11:30 Wireless Networks I  11:30 - 13:00 Optical Networks I  13:00 - 14:30 Panel 1: Broadband Service to the Home









mbone broadcast schedule http://www.msri.org/mbone


From rem-conf-request@tmpmail.es.net Fri Apr 11 01:25:16 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Thu, 10 Apr 1997 22:24:13 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wFYYb-0007ln-00; Thu, 10 Apr 1997 22:07:29 -0700
X-Authentication-Warning: msri.org: smap set sender to <nobody@msri.org> using 
                          -f
Date: Thu, 10 Apr 1997 22:06:09 -0700 (PDT)
Message-Id: <199704110506.WAA28586@hille.msri.org>
To: rem-conf@es.net
From: oka <oka@nanotsu.kobe-u.ac.jp>
Reply-to: oka@nanotsu.kobe-u.ac.jp
Subject: Re-broadcasting of Infocom'97
Resent-Message-ID: <"amUht.0.kI7.HSSJp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Thu, 10 Apr 1997 22:07:29 -0700

	MBone Broadcast Announcement
	----------------------------

Title:       
	Re-broadcasting of Infocom'97
Date:        
	Apr 15, 1997

Time:        
	08:00 PST8PDT 8 hours

Contact:     
	oka@nanotsu.kobe-u.ac.jp

URL:         
	http://www.ieee.org/comsoc/infocom

Description:        
	Channel-1  8:00 - 16:00 Gigabit WorkShop  









mbone broadcast schedule http://www.msri.org/mbone


From rem-conf-request@tmpmail.es.net Fri Apr 11 01:25:18 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Thu, 10 Apr 1997 22:25:14 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wFYfX-00003B-00; Thu, 10 Apr 1997 22:14:39 -0700
Date: Fri, 11 Apr 1997 01:14:07 -0400 (EDT)
From: Oguz Angin <angin@ctr.columbia.edu>
To: rem-conf@es.net
cc: mnl@ctr.columbia.edu
Subject: Comet Group Seminar: John R. Nicol, Distributed Multimedia , 
         Applications Group, GTE Laboratories Incorporated, ``Experiences of , 
         Constructing Distributed Business Multimedia Applications``
Message-ID: <Pine.SUN.3.95q.970411010422.14001A-100000@meteor.ctr.columbia.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-ID: <"y0DdE2.0.33._YSJp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Thu, 10 Apr 1997 22:14:39 -0700



MBone Broadcast Announcement

Title:
    EXPERIENCES OF CONSTRUCTING DISTRIBUTED BUSINESS 
    MULTIMEDIA APPLICATIONS
 
Speaker:
    John R. Nicol, 
    Distributed Multimedia Applications Group,
    GTE Laboratories Incorporated

Date:
    Monday, April 14, 1997

Time:
    12:00 NOON - 1:00 PM EST

Multicast Address:
    audio:  DVI, RTP, 224.2.194.51/21104 , ttl=127

Contact:
    Andrew T. Campbell <campbell@ctr.columbia.edu>

URL:
    http://comet.ctr.columbia.edu/activities/seminars/

Place:
    Interschool Lab. (7th Floor)
    Schapiro Research Building
    Center for Telecommunications Research
    Columbia University
    New York City, USA

Abstract:

As bandwidth becomes increasingly plentiful, a key success factor for
major players in the telecommunications marketplace will center on the
provision of value-added services -- the applications and services that
will ultimately make the underlying network sophistication worthwhile to
its end-users. Based on this belief, GTE Laboratories has been conducting
research in the area of distributed multimedia applications for several
years.

This talk will offer a broad perspective of our experiences of building
prototype distributed business multimedia applications over high speed
networks and more recently the Internet, and will include discussion of
our rational for and approach to developing "concept" multimedia
applications; examples of multimedia applications we have built to date
and how we have used them; as well as coverage of some of the distributed
systems techniques we used to construct our prototypes. 



From rem-conf-request@es.net Fri Apr 11 01:28:19 1997 
Received: from msri.org by osi-west.es.net with ESnet SMTP (PP);
          Thu, 10 Apr 1997 22:28:14 -0700
Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id WAA25584 
          for <rem-conf@es.net>; Thu, 10 Apr 1997 22:28:13 -0700 (PDT)
X-Authentication-Warning: msri.org: smap set sender to <nobody@msri.org> using 
                          -f
Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) 
          id sma025579; Thu Apr 10 22:28:01 1997
Received: by hille.msri.org (8.7/MSRI) id WAA28705;
          Thu, 10 Apr 1997 22:28:01 -0700 (PDT)
Date: Thu, 10 Apr 1997 22:28:01 -0700 (PDT)
Message-Id: <199704110528.WAA28705@hille.msri.org>
To: rem-conf@es.net
From: oka <oka@nanotsu.kobe-u.ac.jp>
Reply-to: oka@nanotsu.kobe-u.ac.jp
Subject: Re-broadcasting of Infocom'97

	MBone Broadcast Announcement
	----------------------------

Title:       
	Re-broadcasting of Infocom'97
Date:        
	Apr 18, 1997

Time:        
	08:00 PST8PDT 6 hours

Contact:     
	oka@nanotsu.kobe-u.ac.jp

URL:         
	http://www.ieee.org/comsoc/infocom

Description:        
	Channel-1   8:00 -  9:30 ATM ABR Services III   9:30 - 11:00 ATM Traffic Cntrl III  11:00 - 12:30 LANs and MANs  12:30 - 14:00 ATM ABR Services IV    Channel 2   8:00 -  9:30 Wireless Networks IV   9:30 - 11:00 Panel 3: Micro cellular Communication Systems:PHS,DECT and PACS  11:00 - 12:30 Optical Networks IV  12:30 - 14:00 Wireless Networks V









mbone broadcast schedule http://www.msri.org/mbone

From rem-conf-request@tmpmail.es.net Fri Apr 11 01:31:37 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Thu, 10 Apr 1997 22:31:24 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wFYl3-0000Qn-00; Thu, 10 Apr 1997 22:20:21 -0700
X-Authentication-Warning: msri.org: smap set sender to <nobody@msri.org> using 
                          -f
Date: Thu, 10 Apr 1997 22:19:15 -0700 (PDT)
Message-Id: <199704110519.WAA28640@hille.msri.org>
To: rem-conf@es.net
From: oka <oka@nanotsu.kobe-u.ac.jp>
Reply-to: oka@nanotsu.kobe-u.ac.jp
Subject: Re-broadcasting of Infocom'97
Resent-Message-ID: <"1HqrH1.0.xP.LeSJp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Thu, 10 Apr 1997 22:20:21 -0700

	MBone Broadcast Announcement
	----------------------------

Title:       
	Re-broadcasting of Infocom'97
Date:        
	Apr 17, 1997

Time:        
	08:00 PST8PDT 7.5 hours

Contact:     
	oka@nanotsu.kobe-u.ac.jp

URL:         
	http://www.ieee.org/comsoc/infocom

Description:        
	Channel-1   8:00 -  9:30 ATM ABR Services II  11:00 - 12:30 Panel2: Routing vs Switching  12:30 - 14:00 ATM Traffic Cntrl II  14:00 - 15:30 ATM ABR Services III    Channel 2   8:00 -  9:30 Optical Networks II   9:30 - 11:00 Wireless Networks II  12:30 - 14:00 Optical Networks III  14:00 - 15:30 Wireless Networks IV









mbone broadcast schedule http://www.msri.org/mbone


From rem-conf-request@tmpmail.es.net Fri Apr 11 01:34:01 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Thu, 10 Apr 1997 22:33:57 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wFYsm-0000s9-00; Thu, 10 Apr 1997 22:28:20 -0700
X-Authentication-Warning: msri.org: smap set sender to <nobody@msri.org> using 
                          -f
Date: Thu, 10 Apr 1997 22:28:01 -0700 (PDT)
Message-Id: <199704110528.WAA28705@hille.msri.org>
To: rem-conf@es.net
From: oka <oka@nanotsu.kobe-u.ac.jp>
Reply-to: oka@nanotsu.kobe-u.ac.jp
Subject: Re-broadcasting of Infocom'97
Resent-Message-ID: <"YUSlH1.0.Sq.qlSJp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Thu, 10 Apr 1997 22:28:20 -0700

	MBone Broadcast Announcement
	----------------------------

Title:       
	Re-broadcasting of Infocom'97
Date:        
	Apr 18, 1997

Time:        
	08:00 PST8PDT 6 hours

Contact:     
	oka@nanotsu.kobe-u.ac.jp

URL:         
	http://www.ieee.org/comsoc/infocom

Description:        
	Channel-1   8:00 -  9:30 ATM ABR Services III   9:30 - 11:00 ATM Traffic Cntrl III  11:00 - 12:30 LANs and MANs  12:30 - 14:00 ATM ABR Services IV    Channel 2   8:00 -  9:30 Wireless Networks IV   9:30 - 11:00 Panel 3: Micro cellular Communication Systems:PHS,DECT and PACS  11:00 - 12:30 Optical Networks IV  12:30 - 14:00 Wireless Networks V









mbone broadcast schedule http://www.msri.org/mbone


From rem-conf-request@es.net Fri Apr 11 11:02:00 1997 
Received: from gateway-gw.pictel.com by osi-west.es.net with ESnet SMTP (PP);
          Fri, 11 Apr 1997 08:01:54 -0700
Received: from roadrunner.pictel.com 
          by gateway-gw.pictel.com (4.1/cf.gw.940128.1740) id AA19236;
          Fri, 11 Apr 97 10:57:47 EDT
Received: from python.pictel.com by roadrunner.pictel.com (4.1/runner.910925.1) 
          id AA04430; Fri, 11 Apr 97 10:57:42 EDT
Received: by python.pictel.com (5.x/SMI-SVR4) id AA25479;
          Fri, 11 Apr 1997 10:55:54 -0400
Date: Fri, 11 Apr 1997 10:55:54 -0400
From: garys@pictel.com (Gary Sullivan)
Message-Id: <9704111455.AA25479@python.pictel.com>
To: miska.hannuksela@research.nokia.com
Subject: RE: RTP Payload Format for H.263 Stream
Cc: SG16@mailbag.intel.com, advid@pictel.com, czhu@ideal.JF.intel.com, 
    jtoga@ideal.JF.intel.com, leon@nrctre.research.nokia.com, rem-conf@es.net




I received the following message this morning from Miska Nannuksela
of Nokia Research.  It is in response to my previous message listing
eight items of concern regarding the IETF draft (March '97 version)
RTP payload specification for H.263.  My response is intermingled
with the quoted text.


---------------------------------------------------------------------
>From: miska.hannuksela@research.nokia.com (Hannuksela Miska NRC/Tre)
>Date: Fri, 11 Apr 1997 12:46:03 +0200
>Subject: RE: RTP Payload Format for H.263 Stream


>Dear Mr. Sullivan,

>Having read through your concerns of the RTP payload format I agree on   
>most of the items. However, I would like to point out my opinion on item   
>5 and also one additional concern. Since I am only a member of Advanced   
>Video reflector, I do not know to whom I should post this message. Would   
>you be so kind and forward this message to appropriate persons (if you   
>think it is worthwhile).

>I have refered "RTP Payload Format for H.263 Video Stream" v3, dated 5   
>Jan 1997 in this message. I don't know if newer versions of the document   
>affect my concerns.


The document that I was discussing is a newer draft dated March 15, '97.
Many ITU people are not aware of the existence of this draft, as it was
emailed out on the opening day of our Geneva meeting and was not provided
there.  As stated in Item 6 of my prior message, the changes between the
two drafts are stated to be "mostly editorial".  I have not found any
technical difference between the two drafts.  The new draft can be found
in the email archives of the rem-conf mailing list, which are available
at   ftp://nic.es.net/pub/mailing-lists/mail-archive/rem-conf
The draft was sent to that mailing list on March 17.

(The ftp availability of a well-organized archive of the mailing list
appears to me to be a very valuable resource, one which the people who
maintain the various ITU mailing lists should think about).



>In item 5 you came to a conclusion that the packet fragmentation is also   
>possible for GOBs without a header. I don't see that it is possible. If   
>mode A is used to packetize a GOB without a header, no motion vector   
>information of the previous macroblock row (which is needed for motion   
>vector predictor calculation) is given. Thus, if the packet including the   
>previous macroblock row is lost, the motion vector predictors for the GOB   
>are likely to have wrong values. Modes B and C do not help much because   
>only the motion vector predictors for the first macroblock of the packet   
>are included in the payload header. In conclusion, the target "to be able   
>to process each packet independent on other packets" (from section 4 of   
>the RTP Payload document) is not reached.

>A similar situation to the previous paragraph is faced when we are trying   
>to packetize a GOB having multiple macroblock rows in it (4CIF or 16CIF   
>source format). Let us assume that one macroblock row is put into one   
>packet. If a packet, which contais a macroblock row above some other   
>macroblock row within the same GOB, is lost, we do not have any motion   
>vector information of the lost macroblock row. Thus, we face the same   
>situation as described in the previous paragraph.

>I think that these concerns are contradictory to the independent packet   
>processing target mentioned in the RTP Payload document. Therefore I   
>suggest that either
> - all GOBs should have a non-empty header and a GOB should contain one   
>macroblock row only, or
> - the impacts of using GOBs without headers and GOBs containing multiple   
>macroblock rows should be clearly indicated.

>Best Regards,
>Miska Hannuksela
>Nokia Research Center
>miska.hannuksela@research.nokia.com


I agree with the basic technical description above, but believe that
the *second* of the two alternative suggestions above is the right one
in our situation.  These issues should be clearly described in the
packetization specification document (they are not all that clearly
described at present).  This is in fact a big part of what I was
trying to say in my prior message.  The fact that Miska seems to interpreted
the draft document in an incorrect way (relative to the intent of the
author of that document) dramatically underscores my assertion that
the document is not sufficiently clear.

I agree that the "target" of desiring independent processing of packets
is not fulfilled whenever:

1) GOBs are sent without headers, 

2) The Advanced Prediction mode is in use, or

3) Mode B packetization is used in pictures having multiple rows of
   macroblocks in a single GOB


In fact, that target is also not really fulfilled whenever

4) predictive coding of pictures is in use!

(because if you've lost some packets of some prior picture, you can't
properly create a decoded new picture).  Only Intra-pictures with all
GOB headers and picture sizes no larger than CIF really fulfill
the "target" desire.  Sometimes the IETF people such as Van Jacobsen
advocate not using motion compensation or even frame-difference
coding for this reason.  Only Intra data is totally packet friendly
(at least in the absence of a back-channel).

This is why I consider it so important that these issues be clearly
discussed in the packetization specification document (that is what
my Item 3 was about).

There are several things to consider:

1) The use of GOB headers is optional for the encoder

2) Some encoder-decoder pairs may not even be aware that the
   bitstream transport is packetized

3) We want to be interoperable with systems designed before
   the packetization method was created

4) We can't change the requirements of the existing H.263 standard
   (although we can add optional features that make it work better,
   which is what H.263+ is all about)

If we could change the way H.263 was designed, we could eliminate
the redundancy of the header information as well (making the whole
header optional to allow those things to be signalled out-of-band),
but we can't do that.  This is a packetization for H.263 bitstreams,
so the bitstream data contained in the payload must conform to H.263.
It is too late to try to make H.263 conform to the desires of the
packetization.  We want (I hope) to be *able* to packetize *any*
H.263 bitstream.

However, it is very important for the document to make clear
what kinds of H.263 bitstreams are the most "packet-friendly".
By making this very clear, we can encourage the designers of
H.263-based systems to use the standard in the best possible
way, taking into account their network transport characteristics
and using their best judgement.

Also, the restrictions that are proposed to make H.263 more
"packet-friendly" all do something else too.  They all make it
less efficient.  Restricting H.263 to only use Intra pictures
with all GOB headers present and no advanced prediction and no
picture sizes larger than CIF is obviously not what we want.
Encoder designers should be free to make their own judgements
about the necessary trade-offs between efficiency and packet-
friendly design.


Best Wishes,

Gary Sullivan  Tel: +1 508-623-4324 Fax: 749-2804 <garys@pictel.com>
PictureTel Corp. M/S 635, 100 Minuteman Road, Andover MA 01810  USA


---------
Addendum:

The most relevant items of my prior message are quoted below for
context:


>>Subject:  Re: RTP Payload Format for H.263 Stream
>>From: garys@pictel.com (Gary Sullivan)


>>ITEM 3:

>>The document discusses a cross-GOB data dependency in the
>>prediction of motion vector values when GOB headers are
>>not present.  Due to this dependency, it mentions that
>>it is advisable to use GOB headers on lossy packet nets.

>>It should also point out that another cross-GOB data
>>dependency exists in the OBMC part of the Advanced Prediction
>>(AP) option.  This dependency is much less severe in its
>>quality impact, but the document should probably mention
>>that it exists.  Due to this dependency, it may be advisable
>>to not use AP on lossy packet nets (also in regard to the desire
>>to easily decode packets that are received out of order).


>>ITEM 4:

>>The document describes a packetization with headers that
>>duplicate the functionality of virtually all of the content
>>of the video bitstream picture header.  This led me to
>>wonder whether the picture header was still sent, or whether
>>the packetization headers were just a wrapper around the
>>existing bitstream definition with a duplication of much
>>of its content.  After talking with Mr. Zhu, I have concluded
>>that it is just a wrapper and that the entire H.263 bitstream
>>is sent in the payload without alteration.  I agree that it
>>is desirable to sent the entire H.263 bitstream in the payload.
>>I think it might be helpful to clarify the document to make
>>sure that this is understood.


>>ITEM 5:

>>The document describes a "Mode A" packetization which can be
>>used to fragment the H.263 bitstream at picture header boundaries
>>or at GOB boundaries, and discusses how the presence of GOB headers
>>can aid in this process.  I did not understand from reading the
>>document whether fragmentation at GOB boundaries was allowed even
>>when GOB headers were not present.  After talking with Mr. Zhu,
>>I have concluded that the fragmentation *is* allowed without the
>>presence of GOB headers.  Some clarifying wording to that effect
>>might be helpful.

From rem-conf-request@tmpmail.es.net Fri Apr 11 11:20:46 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Fri, 11 Apr 1997 08:20:43 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wFhpz-0004C1-00; Fri, 11 Apr 1997 08:02:03 -0700
Date: Fri, 11 Apr 1997 10:55:54 -0400
From: garys@pictel.com (Gary Sullivan)
Message-Id: <9704111455.AA25479@python.pictel.com>
To: miska.hannuksela@research.nokia.com
Subject: RE: RTP Payload Format for H.263 Stream
Cc: SG16@mailbag.intel.com, advid@pictel.com, czhu@ideal.JF.intel.com, 
    jtoga@ideal.JF.intel.com, leon@nrctre.research.nokia.com, rem-conf@es.net
Resent-Message-ID: <"WiBTL3.0.ux3.h9bJp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Fri, 11 Apr 1997 08:02:03 -0700




I received the following message this morning from Miska Nannuksela
of Nokia Research.  It is in response to my previous message listing
eight items of concern regarding the IETF draft (March '97 version)
RTP payload specification for H.263.  My response is intermingled
with the quoted text.


---------------------------------------------------------------------
>From: miska.hannuksela@research.nokia.com (Hannuksela Miska NRC/Tre)
>Date: Fri, 11 Apr 1997 12:46:03 +0200
>Subject: RE: RTP Payload Format for H.263 Stream


>Dear Mr. Sullivan,

>Having read through your concerns of the RTP payload format I agree on   
>most of the items. However, I would like to point out my opinion on item   
>5 and also one additional concern. Since I am only a member of Advanced   
>Video reflector, I do not know to whom I should post this message. Would   
>you be so kind and forward this message to appropriate persons (if you   
>think it is worthwhile).

>I have refered "RTP Payload Format for H.263 Video Stream" v3, dated 5   
>Jan 1997 in this message. I don't know if newer versions of the document   
>affect my concerns.


The document that I was discussing is a newer draft dated March 15, '97.
Many ITU people are not aware of the existence of this draft, as it was
emailed out on the opening day of our Geneva meeting and was not provided
there.  As stated in Item 6 of my prior message, the changes between the
two drafts are stated to be "mostly editorial".  I have not found any
technical difference between the two drafts.  The new draft can be found
in the email archives of the rem-conf mailing list, which are available
at   ftp://nic.es.net/pub/mailing-lists/mail-archive/rem-conf
The draft was sent to that mailing list on March 17.

(The ftp availability of a well-organized archive of the mailing list
appears to me to be a very valuable resource, one which the people who
maintain the various ITU mailing lists should think about).



>In item 5 you came to a conclusion that the packet fragmentation is also   
>possible for GOBs without a header. I don't see that it is possible. If   
>mode A is used to packetize a GOB without a header, no motion vector   
>information of the previous macroblock row (which is needed for motion   
>vector predictor calculation) is given. Thus, if the packet including the   
>previous macroblock row is lost, the motion vector predictors for the GOB   
>are likely to have wrong values. Modes B and C do not help much because   
>only the motion vector predictors for the first macroblock of the packet   
>are included in the payload header. In conclusion, the target "to be able   
>to process each packet independent on other packets" (from section 4 of   
>the RTP Payload document) is not reached.

>A similar situation to the previous paragraph is faced when we are trying   
>to packetize a GOB having multiple macroblock rows in it (4CIF or 16CIF   
>source format). Let us assume that one macroblock row is put into one   
>packet. If a packet, which contais a macroblock row above some other   
>macroblock row within the same GOB, is lost, we do not have any motion   
>vector information of the lost macroblock row. Thus, we face the same   
>situation as described in the previous paragraph.

>I think that these concerns are contradictory to the independent packet   
>processing target mentioned in the RTP Payload document. Therefore I   
>suggest that either
> - all GOBs should have a non-empty header and a GOB should contain one   
>macroblock row only, or
> - the impacts of using GOBs without headers and GOBs containing multiple   
>macroblock rows should be clearly indicated.

>Best Regards,
>Miska Hannuksela
>Nokia Research Center
>miska.hannuksela@research.nokia.com


I agree with the basic technical description above, but believe that
the *second* of the two alternative suggestions above is the right one
in our situation.  These issues should be clearly described in the
packetization specification document (they are not all that clearly
described at present).  This is in fact a big part of what I was
trying to say in my prior message.  The fact that Miska seems to interpreted
the draft document in an incorrect way (relative to the intent of the
author of that document) dramatically underscores my assertion that
the document is not sufficiently clear.

I agree that the "target" of desiring independent processing of packets
is not fulfilled whenever:

1) GOBs are sent without headers, 

2) The Advanced Prediction mode is in use, or

3) Mode B packetization is used in pictures having multiple rows of
   macroblocks in a single GOB


In fact, that target is also not really fulfilled whenever

4) predictive coding of pictures is in use!

(because if you've lost some packets of some prior picture, you can't
properly create a decoded new picture).  Only Intra-pictures with all
GOB headers and picture sizes no larger than CIF really fulfill
the "target" desire.  Sometimes the IETF people such as Van Jacobsen
advocate not using motion compensation or even frame-difference
coding for this reason.  Only Intra data is totally packet friendly
(at least in the absence of a back-channel).

This is why I consider it so important that these issues be clearly
discussed in the packetization specification document (that is what
my Item 3 was about).

There are several things to consider:

1) The use of GOB headers is optional for the encoder

2) Some encoder-decoder pairs may not even be aware that the
   bitstream transport is packetized

3) We want to be interoperable with systems designed before
   the packetization method was created

4) We can't change the requirements of the existing H.263 standard
   (although we can add optional features that make it work better,
   which is what H.263+ is all about)

If we could change the way H.263 was designed, we could eliminate
the redundancy of the header information as well (making the whole
header optional to allow those things to be signalled out-of-band),
but we can't do that.  This is a packetization for H.263 bitstreams,
so the bitstream data contained in the payload must conform to H.263.
It is too late to try to make H.263 conform to the desires of the
packetization.  We want (I hope) to be *able* to packetize *any*
H.263 bitstream.

However, it is very important for the document to make clear
what kinds of H.263 bitstreams are the most "packet-friendly".
By making this very clear, we can encourage the designers of
H.263-based systems to use the standard in the best possible
way, taking into account their network transport characteristics
and using their best judgement.

Also, the restrictions that are proposed to make H.263 more
"packet-friendly" all do something else too.  They all make it
less efficient.  Restricting H.263 to only use Intra pictures
with all GOB headers present and no advanced prediction and no
picture sizes larger than CIF is obviously not what we want.
Encoder designers should be free to make their own judgements
about the necessary trade-offs between efficiency and packet-
friendly design.


Best Wishes,

Gary Sullivan  Tel: +1 508-623-4324 Fax: 749-2804 <garys@pictel.com>
PictureTel Corp. M/S 635, 100 Minuteman Road, Andover MA 01810  USA


---------
Addendum:

The most relevant items of my prior message are quoted below for
context:


>>Subject:  Re: RTP Payload Format for H.263 Stream
>>From: garys@pictel.com (Gary Sullivan)


>>ITEM 3:

>>The document discusses a cross-GOB data dependency in the
>>prediction of motion vector values when GOB headers are
>>not present.  Due to this dependency, it mentions that
>>it is advisable to use GOB headers on lossy packet nets.

>>It should also point out that another cross-GOB data
>>dependency exists in the OBMC part of the Advanced Prediction
>>(AP) option.  This dependency is much less severe in its
>>quality impact, but the document should probably mention
>>that it exists.  Due to this dependency, it may be advisable
>>to not use AP on lossy packet nets (also in regard to the desire
>>to easily decode packets that are received out of order).


>>ITEM 4:

>>The document describes a packetization with headers that
>>duplicate the functionality of virtually all of the content
>>of the video bitstream picture header.  This led me to
>>wonder whether the picture header was still sent, or whether
>>the packetization headers were just a wrapper around the
>>existing bitstream definition with a duplication of much
>>of its content.  After talking with Mr. Zhu, I have concluded
>>that it is just a wrapper and that the entire H.263 bitstream
>>is sent in the payload without alteration.  I agree that it
>>is desirable to sent the entire H.263 bitstream in the payload.
>>I think it might be helpful to clarify the document to make
>>sure that this is understood.


>>ITEM 5:

>>The document describes a "Mode A" packetization which can be
>>used to fragment the H.263 bitstream at picture header boundaries
>>or at GOB boundaries, and discusses how the presence of GOB headers
>>can aid in this process.  I did not understand from reading the
>>document whether fragmentation at GOB boundaries was allowed even
>>when GOB headers were not present.  After talking with Mr. Zhu,
>>I have concluded that the fragmentation *is* allowed without the
>>presence of GOB headers.  Some clarifying wording to that effect
>>might be helpful.


From rem-conf-request@es.net Fri Apr 11 13:41:41 1997 
Received: from nobozo.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP);
          Fri, 11 Apr 1997 10:41:36 -0700
Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) 
          by nobozo.CS.Berkeley.EDU (8.6.10/8.6.3) with SMTP id KAA11079;
          Fri, 11 Apr 1997 10:41:33 -0700
Date: Fri, 11 Apr 1997 10:41:33 -0700
Message-Id: <199704111741.KAA11079@nobozo.CS.Berkeley.EDU>
X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU
X-Mailer: Windows Eudora Version 2.1.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: 298-list@bmrc.Berkeley.EDU, rem-conf@es.net
From: Jerrlyn Iwata <jerrlyn@postgres.Berkeley.EDU>
Subject: Berkeley Multimedia & Graphics Seminar

                Berkeley Multimedia and Graphics Seminar 
        (Wednesday April 16, 1997 12:30-2:00 PDT 405 Soda Hall) 

"Issues in Delivering Images and Text from Diverse Environments via University
Information Systems: Lessons from the Museum Educational Site Licensing
Project" 

                                Howard Besser 
                                SIMS and BMRC 
                                UC Berkeley 

The Museum Educational Site Licensing Project (MESL) is a major
demonstration project designed to identify the problems of licensing and
delivery of high-quality museum digital images and information to
educational institutions. The project is serving as a laboratory for
developing and testing the legal,
administrative and technical mechanisms needed to enable the full
educational use of museum collections.  Through MESL, 7 major repositories
have distributed an identical set of about 10,000 images and fielded text to
7 Universities. 

In this talk Howard Besser, one of the MESL founders, will describe MESL as
a whole, and discuss a number of the important issues tacked by the project.
Specifically he will address issues of metadata and image standards,
distribution and deployment schemes, teaching issues, and the development of new
interactions between museums and universities. He will also describe the
recent Mellon grant he has received to study the cost and use of networked
digital information through the MESL project. 

-------------------------------------------------------------------------------

This seminar will be broadcast on the Internet MBONE. The broadcast will
begin at 12:40 PDT (GMT - 8 hrs). See sdr or http://bmrc.berkeley.edu/298
for instructions on setting up, connecting to, and operating the MBONE tools.

Please direct all technical questions to davesimp@cs.berkeley.edu


From rem-conf-request@tmpmail.es.net Fri Apr 11 14:02:26 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Fri, 11 Apr 1997 11:02:21 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wFkQ7-0005va-00; Fri, 11 Apr 1997 10:47:31 -0700
Date: Fri, 11 Apr 1997 10:41:33 -0700
Message-Id: <199704111741.KAA11079@nobozo.CS.Berkeley.EDU>
X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU
X-Mailer: Windows Eudora Version 2.1.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: 298-list@bmrc.Berkeley.EDU, rem-conf@es.net
From: Jerrlyn Iwata <jerrlyn@postgres.Berkeley.EDU>
Subject: Berkeley Multimedia & Graphics Seminar
Resent-Message-ID: <"QA3rp3.0.5a5.padJp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Fri, 11 Apr 1997 10:47:31 -0700

                Berkeley Multimedia and Graphics Seminar 
        (Wednesday April 16, 1997 12:30-2:00 PDT 405 Soda Hall) 

"Issues in Delivering Images and Text from Diverse Environments via University
Information Systems: Lessons from the Museum Educational Site Licensing
Project" 

                                Howard Besser 
                                SIMS and BMRC 
                                UC Berkeley 

The Museum Educational Site Licensing Project (MESL) is a major
demonstration project designed to identify the problems of licensing and
delivery of high-quality museum digital images and information to
educational institutions. The project is serving as a laboratory for
developing and testing the legal,
administrative and technical mechanisms needed to enable the full
educational use of museum collections.  Through MESL, 7 major repositories
have distributed an identical set of about 10,000 images and fielded text to
7 Universities. 

In this talk Howard Besser, one of the MESL founders, will describe MESL as
a whole, and discuss a number of the important issues tacked by the project.
Specifically he will address issues of metadata and image standards,
distribution and deployment schemes, teaching issues, and the development of new
interactions between museums and universities. He will also describe the
recent Mellon grant he has received to study the cost and use of networked
digital information through the MESL project. 

-------------------------------------------------------------------------------

This seminar will be broadcast on the Internet MBONE. The broadcast will
begin at 12:40 PDT (GMT - 8 hrs). See sdr or http://bmrc.berkeley.edu/298
for instructions on setting up, connecting to, and operating the MBONE tools.

Please direct all technical questions to davesimp@cs.berkeley.edu



From rem-conf-request@es.net Fri Apr 11 14:38:15 1997 
Received: from marmot.nsg.nwu.edu by osi-west.es.net with ESnet SMTP (PP);
          Fri, 11 Apr 1997 11:38:10 -0700
Received: by marmot.nsg.nwu.edu (8.8.5/8.6.12) id NAA14927 ;
          Fri, 11 Apr 1997 13:38:09 -0500 (CDT)
From: Tim Ward <tward@marmot.nsg.nwu.edu>
Message-Id: <199704111838.NAA14927@marmot.nsg.nwu.edu>
Subject: Workshop on High-Performance Digital Communications
To: rem-conf@es.net
Date: Fri, 11 Apr 1997 13:38:08 -0500 (CDT)
Reply-To: tpw@nwu.edu
X-Mailer: ELM [version 2.4ME+ PL17 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

         Workshop on High-Performance Digital Communications/vBNS
	  Hosted by Metropolitan Research and Education Network 
	       Sponsored by National Science Foundation

            Thursday, April 24, and Friday, April 25, 1997
	           8:00 AM - 5:00 PM CDT both days


The Metropolitan Research and Education Network is an innovative advanced
network with a primary focus on high performance digital communications 
in support of research applications.  

This workshop has been chartered to advance key issues related to building 
the next generation of high-performance networks. The workshop will address 
a range of fundamental HPDN/vBNS topics, and for each topic, the following 
issues will be addressed:

     Core requirements 
     State of standards development 
     Current state of technology 
     Availability of standards/solutions/products to address specific 
	requirements 
     Identification of areas where major development efforts are still required

Each topic will be addressed by a panel of at least two speakers; three 
where necessary to address the topics or where there is an opportunity 
to recruit three particularly knowledgeable speakers on a given topic.

See a detailed agenda at:
            http://www2.uchicago.edu/ns-acs/mren/agenda.html

General information about the conference can be found at:
            http://www2.uchicago.edu/ns-acs/mren/conference.html

Questions about the broadcast can be directed to tpw@nwu.edu.


From rem-conf-request@tmpmail.es.net Fri Apr 11 14:52:27 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Fri, 11 Apr 1997 11:52:21 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wFlDE-0006UA-00; Fri, 11 Apr 1997 11:38:16 -0700
From: Tim Ward <tward@marmot.nsg.nwu.edu>
Message-Id: <199704111838.NAA14927@marmot.nsg.nwu.edu>
Subject: Workshop on High-Performance Digital Communications
To: rem-conf@es.net
Date: Fri, 11 Apr 1997 13:38:08 -0500 (CDT)
Reply-To: tpw@nwu.edu
X-Mailer: ELM [version 2.4ME+ PL17 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"nPnQ72.0.b56.OKeJp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Fri, 11 Apr 1997 11:38:16 -0700

         Workshop on High-Performance Digital Communications/vBNS
	  Hosted by Metropolitan Research and Education Network 
	       Sponsored by National Science Foundation

            Thursday, April 24, and Friday, April 25, 1997
	           8:00 AM - 5:00 PM CDT both days


The Metropolitan Research and Education Network is an innovative advanced
network with a primary focus on high performance digital communications 
in support of research applications.  

This workshop has been chartered to advance key issues related to building 
the next generation of high-performance networks. The workshop will address 
a range of fundamental HPDN/vBNS topics, and for each topic, the following 
issues will be addressed:

     Core requirements 
     State of standards development 
     Current state of technology 
     Availability of standards/solutions/products to address specific 
	requirements 
     Identification of areas where major development efforts are still required

Each topic will be addressed by a panel of at least two speakers; three 
where necessary to address the topics or where there is an opportunity 
to recruit three particularly knowledgeable speakers on a given topic.

See a detailed agenda at:
            http://www2.uchicago.edu/ns-acs/mren/agenda.html

General information about the conference can be found at:
            http://www2.uchicago.edu/ns-acs/mren/conference.html

Questions about the broadcast can be directed to tpw@nwu.edu.



From rem-conf-request@es.net Fri Apr 11 17:29:49 1997 
Received: from mailbag.jf.intel.com by osi-west.es.net with ESnet SMTP (PP);
          Fri, 11 Apr 1997 14:29:31 -0700
Received: from ideal.jf.intel.com (ideal.jf.intel.com [134.134.130.5]) 
          by mailbag.jf.intel.com (8.8.5/8.7.3) with ESMTP id OAA13363;
          Fri, 11 Apr 1997 14:31:49 -0700 (PDT)
Received: from zoo (zoo.jf.intel.com [134.134.158.177]) 
          by ideal.jf.intel.com (8.8.5/8.8.4) with SMTP id OAA23429;
          Fri, 11 Apr 1997 14:26:48 -0700 (PDT)
Message-Id: <1.5.4.32.19970411213032.009d0cd8@ibeam.intel.com>
X-Sender: czhu@ibeam.intel.com
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 11 Apr 1997 14:30:32 -0700
To: garys@pictel.com (Gary Sullivan)
From: "C. Zhu" <czhu@mailbox.jf.intel.com>
Subject: Re: RTP Payload Format for H.263 Stream
Cc: rem-conf@es.net

Gary,

Sorry for the delayed response. I lost email connection at Memphis. Thanks
to Steve Casner and Philip Lantz, I was able to read your mail and discussed
it with Steve before my presenation at Memphis.

I agree with item 1, 2 and 3, and they are excellent comments. We had some
discussions on version field and H.263+ at IETF San Jose meeting. It was
decided then to remove the version field and start a separate payload draft
for H.263+. In fact, some of us at Intel are reviewing a draft internally,
and we will release it to this mailing list for comments. Everyone is more
than welcome to provide input and work with us on it.

Please see my comments below for more detailed explainations.

Regards.

--Chad


At 08:24 PM 4/8/97 -0400, you wrote:


>
>ITEM 4:
>
>The document describes a packetization with headers that
>duplicate the functionality of virtually all of the content
>of the video bitstream picture header.  This led me to
>wonder whether the picture header was still sent, or whether
>the packetization headers were just a wrapper around the
>existing bitstream definition with a duplication of much
>of its content.  After talking with Mr. Zhu, I have concluded
>that it is just a wrapper and that the entire H.263 bitstream
>is sent in the payload without alteration.  I agree that it
>is desirable to sent the entire H.263 bitstream in the payload.
>I think it might be helpful to clarify the document to make
>sure that this is understood.
>

This is actually clearly stated in the current draft in section 4, Usage of RTP.

>
>ITEM 5:
>
>The document describes a "Mode A" packetization which can be
>used to fragment the H.263 bitstream at picture header boundaries
>or at GOB boundaries, and discusses how the presence of GOB headers
>can aid in this process.  I did not understand from reading the
>document whether fragmentation at GOB boundaries was allowed even
>when GOB headers were not present.  After talking with Mr. Zhu,
>I have concluded that the fragmentation *is* allowed without the
>presence of GOB headers.  Some clarifying wording to that effect
>might be helpful.
>

I agree it would be helpful, but do not see that absolutely necessary. 

What was speficied in the draft was that a "Mode A" packet starts at a GOB
boundary. It did not "require" a GOB header to be present, because we do not
want to redefine what a GOB is, or how it is coded. We would rather leave
that decision to each implemenaters, the same way that ITU H.263 only specifies
bitstream, but leave encoding options to implementers.

However, we did recommend the use of GOB header to improve performance in the
presence of packet loss. We tried very hard to avoid imposing any additional 
requirements on H.263 encoder than H.263 spec.

 
>
>ITEM 7:
>
>It has come to my attention that some company may have implemented
>the first-draft version of the packetization definition without
>indicating in any way that they have done a non-standard packetization.
>Is it possible to detect whether first draft or the current draft was used
>by looking at the bits in the headers?  Should it be?  This issue has
>caused a controversy in some recent ITU email discussions (on
>ITU-SG16@MAILBAG.INTEL.COM).
>
>It may be useful to have some form of "in-band" detection of the
>packetization method (just as H.263 has an "in-band" indication of which
>of its options are in use).  As I understand it, there used to be a
>version number in the packet header, but that was removed from the current
>draft.  Why?  (I understand that it was not meant to distinguish between
>draft versions of the standard, especially since draft 1 has expired, but
>that is one way to have a detectable in-band signal of the type of
>packetization.)

We had discussed this in IETF meeting at San Jose. The group consensus was
to remove it mainly because it introduced another multilexing points. Steve
and Mark might help to explain this again if this is not clear enough.


>
>ITEM 8:
>
>The draft packetization document makes no mention of H.263+ or its
>impending impact on the packetization plan.  At a minimum, it should
>do two things:
>
>1) mention the existence of the planned enhancements, and
>
>2) describe some plan for later accommodating those enhancements
>
>This topic again brings up the issue of having a way of detecting
>the packetization method.
>
>
This was also discussed at IETF meeting in San Jose while version field was
debated. The suggestion from the AVT working group was to separate H.263+
new features from current H.263, and design a separate payload format.
Considering that H.263+ effort is still ongoing, some of us at Intel already
started along that path. We have a draft payload format that is being
reviewed internally at Intel. I announced in Memphis that we welcome any
constructive input to the new payload format draft for h.263+. 





From rem-conf-request@tmpmail.es.net Fri Apr 11 17:38:43 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Fri, 11 Apr 1997 14:38:40 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wFntH-000014-00; Fri, 11 Apr 1997 14:29:51 -0700
Message-Id: <1.5.4.32.19970411213032.009d0cd8@ibeam.intel.com>
X-Sender: czhu@ibeam.intel.com
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 11 Apr 1997 14:30:32 -0700
To: garys@pictel.com (Gary Sullivan)
From: "C. Zhu" <czhu@mailbox.jf.intel.com>
Subject: Re: RTP Payload Format for H.263 Stream
Cc: rem-conf@es.net
Resent-Message-ID: <"fonSD3.0.11.FrgJp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Fri, 11 Apr 1997 14:29:51 -0700

Gary,

Sorry for the delayed response. I lost email connection at Memphis. Thanks
to Steve Casner and Philip Lantz, I was able to read your mail and discussed
it with Steve before my presenation at Memphis.

I agree with item 1, 2 and 3, and they are excellent comments. We had some
discussions on version field and H.263+ at IETF San Jose meeting. It was
decided then to remove the version field and start a separate payload draft
for H.263+. In fact, some of us at Intel are reviewing a draft internally,
and we will release it to this mailing list for comments. Everyone is more
than welcome to provide input and work with us on it.

Please see my comments below for more detailed explainations.

Regards.

--Chad


At 08:24 PM 4/8/97 -0400, you wrote:


>
>ITEM 4:
>
>The document describes a packetization with headers that
>duplicate the functionality of virtually all of the content
>of the video bitstream picture header.  This led me to
>wonder whether the picture header was still sent, or whether
>the packetization headers were just a wrapper around the
>existing bitstream definition with a duplication of much
>of its content.  After talking with Mr. Zhu, I have concluded
>that it is just a wrapper and that the entire H.263 bitstream
>is sent in the payload without alteration.  I agree that it
>is desirable to sent the entire H.263 bitstream in the payload.
>I think it might be helpful to clarify the document to make
>sure that this is understood.
>

This is actually clearly stated in the current draft in section 4, Usage of RTP.

>
>ITEM 5:
>
>The document describes a "Mode A" packetization which can be
>used to fragment the H.263 bitstream at picture header boundaries
>or at GOB boundaries, and discusses how the presence of GOB headers
>can aid in this process.  I did not understand from reading the
>document whether fragmentation at GOB boundaries was allowed even
>when GOB headers were not present.  After talking with Mr. Zhu,
>I have concluded that the fragmentation *is* allowed without the
>presence of GOB headers.  Some clarifying wording to that effect
>might be helpful.
>

I agree it would be helpful, but do not see that absolutely necessary. 

What was speficied in the draft was that a "Mode A" packet starts at a GOB
boundary. It did not "require" a GOB header to be present, because we do not
want to redefine what a GOB is, or how it is coded. We would rather leave
that decision to each implemenaters, the same way that ITU H.263 only specifies
bitstream, but leave encoding options to implementers.

However, we did recommend the use of GOB header to improve performance in the
presence of packet loss. We tried very hard to avoid imposing any additional 
requirements on H.263 encoder than H.263 spec.

 
>
>ITEM 7:
>
>It has come to my attention that some company may have implemented
>the first-draft version of the packetization definition without
>indicating in any way that they have done a non-standard packetization.
>Is it possible to detect whether first draft or the current draft was used
>by looking at the bits in the headers?  Should it be?  This issue has
>caused a controversy in some recent ITU email discussions (on
>ITU-SG16@MAILBAG.INTEL.COM).
>
>It may be useful to have some form of "in-band" detection of the
>packetization method (just as H.263 has an "in-band" indication of which
>of its options are in use).  As I understand it, there used to be a
>version number in the packet header, but that was removed from the current
>draft.  Why?  (I understand that it was not meant to distinguish between
>draft versions of the standard, especially since draft 1 has expired, but
>that is one way to have a detectable in-band signal of the type of
>packetization.)

We had discussed this in IETF meeting at San Jose. The group consensus was
to remove it mainly because it introduced another multilexing points. Steve
and Mark might help to explain this again if this is not clear enough.


>
>ITEM 8:
>
>The draft packetization document makes no mention of H.263+ or its
>impending impact on the packetization plan.  At a minimum, it should
>do two things:
>
>1) mention the existence of the planned enhancements, and
>
>2) describe some plan for later accommodating those enhancements
>
>This topic again brings up the issue of having a way of detecting
>the packetization method.
>
>
This was also discussed at IETF meeting in San Jose while version field was
debated. The suggestion from the AVT working group was to separate H.263+
new features from current H.263, and design a separate payload format.
Considering that H.263+ effort is still ongoing, some of us at Intel already
started along that path. We have a draft payload format that is being
reviewed internally at Intel. I announced in Memphis that we welcome any
constructive input to the new payload format draft for h.263+. 






From rem-conf-request@es.net Fri Apr 11 19:05:58 1997 
Received: from mailbag.jf.intel.com by osi-west.es.net with ESnet SMTP (PP);
          Fri, 11 Apr 1997 16:05:53 -0700
Received: from ideal.jf.intel.com (ideal.jf.intel.com [134.134.130.5]) 
          by mailbag.jf.intel.com (8.8.5/8.7.3) with ESMTP id QAA17717;
          Fri, 11 Apr 1997 16:06:52 -0700 (PDT)
Received: from zoo (zoo.jf.intel.com [134.134.158.177]) 
          by ideal.jf.intel.com (8.8.5/8.8.4) with SMTP id QAA26666;
          Fri, 11 Apr 1997 16:01:50 -0700 (PDT)
Message-Id: <1.5.4.32.19970411230535.0136932c@ibeam.intel.com>
X-Sender: czhu@ibeam.intel.com
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 11 Apr 1997 16:05:35 -0700
To: garys@pictel.com (Gary Sullivan)
From: "C. Zhu" <czhu@mailbox.jf.intel.com>
Subject: RE: RTP Payload Format for H.263 Stream
Cc: rem-conf@es.net, miska.hannuksela@research.nokia.com

Gary and Mista,

I seemed to that you are asking for clarifications of the draft, not changes
in design, which I am more than happy to do. Thanks for identifying all the
points of confusions in the current draft.

--Chad


At 10:57 AM 4/11/97 -0400, you wrote:
>
>
>I received the following message this morning from Miska Nannuksela
>of Nokia Research.  It is in response to my previous message listing
>eight items of concern regarding the IETF draft (March '97 version)
>RTP payload specification for H.263.  My response is intermingled
>with the quoted text.
>


From rem-conf-request@tmpmail.es.net Fri Apr 11 19:13:40 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Fri, 11 Apr 1997 16:13:30 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wFpOJ-0000wo-00; Fri, 11 Apr 1997 16:05:59 -0700
Message-Id: <1.5.4.32.19970411230535.0136932c@ibeam.intel.com>
X-Sender: czhu@ibeam.intel.com
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 11 Apr 1997 16:05:35 -0700
To: garys@pictel.com (Gary Sullivan)
From: "C. Zhu" <czhu@mailbox.jf.intel.com>
Subject: RE: RTP Payload Format for H.263 Stream
Cc: rem-conf@es.net, miska.hannuksela@research.nokia.com
Resent-Message-ID: <"RM_b-.0.zu.NFiJp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Fri, 11 Apr 1997 16:05:59 -0700

Gary and Mista,

I seemed to that you are asking for clarifications of the draft, not changes
in design, which I am more than happy to do. Thanks for identifying all the
points of confusions in the current draft.

--Chad


At 10:57 AM 4/11/97 -0400, you wrote:
>
>
>I received the following message this morning from Miska Nannuksela
>of Nokia Research.  It is in response to my previous message listing
>eight items of concern regarding the IETF draft (March '97 version)
>RTP payload specification for H.263.  My response is intermingled
>with the quoted text.
>



From rem-conf-request@es.net Fri Apr 11 20:28:09 1997 
Received: from gateway-gw.pictel.com by osi-west.es.net with ESnet SMTP (PP);
          Fri, 11 Apr 1997 17:28:04 -0700
Received: from roadrunner.pictel.com 
          by gateway-gw.pictel.com (4.1/cf.gw.940128.1740) id AA29679;
          Fri, 11 Apr 97 20:26:35 EDT
Received: from python.pictel.com by roadrunner.pictel.com (4.1/runner.910925.1) 
          id AA21272; Fri, 11 Apr 97 20:26:31 EDT
Received: by python.pictel.com (5.x/SMI-SVR4) id AA26305;
          Fri, 11 Apr 1997 20:24:37 -0400
Date: Fri, 11 Apr 1997 20:24:37 -0400
From: garys@pictel.com (Gary Sullivan)
Message-Id: <9704120024.AA26305@python.pictel.com>
To: czhu@mailbox.jf.intel.com
Subject: Re: RTP Payload Format for H.263 Stream
Cc: ITU-SG16@MAILBAG.INTEL.COM, itu-adv-video@listserv.iterated.com, 
    rem-conf@es.net




Some comments in response to Chad Zhu's response to my 9-item
list of issues.  The following comments ask for further
editorial clarification and further understanding, but
*no* changes in technical content:


--------------------------------------
>Date: Fri, 11 Apr 1997 14:30:32 -0700
>To: garys@pictel.com (Gary Sullivan)
>From: "C. Zhu" <czhu@mailbox.jf.intel.com>
>Subject: Re: RTP Payload Format for H.263 Stream
>Cc: rem-conf@es.net
>
>Gary,
>
>Sorry for the delayed response. I lost email connection at Memphis. Thanks
>to Steve Casner and Philip Lantz, I was able to read your mail and discussed
>it with Steve before my presenation at Memphis.


Good.  I'm glad my comments were able to get to you one way or another.


>
>I agree with item 1, 2 and 3, and they are excellent comments. We had some
>discussions on version field and H.263+ at IETF San Jose meeting. It was
>decided then to remove the version field and start a separate payload draft
>for H.263+. In fact, some of us at Intel are reviewing a draft internally,
>and we will release it to this mailing list for comments. Everyone is more
>than welcome to provide input and work with us on it.
>
>Please see my comments below for more detailed explainations.
>
>Regards.
>
>--Chad
>
>
>At 08:24 PM 4/8/97 -0400, you wrote:
>
>
>>
>>ITEM 4:
>>
>>The document describes a packetization with headers that
>>duplicate the functionality of virtually all of the content
>>of the video bitstream picture header.  This led me to
>>wonder whether the picture header was still sent, or whether
>>the packetization headers were just a wrapper around the
>>existing bitstream definition with a duplication of much
>>of its content.  After talking with Mr. Zhu, I have concluded
>>that it is just a wrapper and that the entire H.263 bitstream
>>is sent in the payload without alteration.  I agree that it
>>is desirable to sent the entire H.263 bitstream in the payload.
>>I think it might be helpful to clarify the document to make
>>sure that this is understood.
>>
>
>This is actually clearly stated in the current draft in section 4, Usage of RTP.
>


I just re-read that section and I still don't think it is clearly
stated.  I'm looking for perhaps one sentence that says something like:

  "The H.263 payload bitstream itself is carried without alteration,
   including the picture start code and the entire picture header
   (even though much of the picture header information is duplicated
   in the RTP header)."

I could not find anything like that.  Can you quote me the sentences
that you think "clearly state" that, specifically in reference to the
picture header information and picture start codes?

(I was not the only one who was confused about this topic.)

Again, all I was asking for is for the text to be made more clear.
You may think it is clear, but I am not convinced.  The people who
wrote a document often tend to think it is more clear than others do.
It should not hurt to try to make it even more clear.



>>
>>ITEM 5:
>>
>>The document describes a "Mode A" packetization which can be
>>used to fragment the H.263 bitstream at picture header boundaries
>>or at GOB boundaries, and discusses how the presence of GOB headers
>>can aid in this process.  I did not understand from reading the
>>document whether fragmentation at GOB boundaries was allowed even
>>when GOB headers were not present.  After talking with Mr. Zhu,
>>I have concluded that the fragmentation *is* allowed without the
>>presence of GOB headers.  Some clarifying wording to that effect
>>might be helpful.
>>
>
>I agree it would be helpful, but do not see that absolutely necessary. 
>
>What was speficied in the draft was that a "Mode A" packet starts at a GOB
>boundary. It did not "require" a GOB header to be present, because we do not
>want to redefine what a GOB is, or how it is coded. We would rather leave
>that decision to each implemenaters, the same way that ITU H.263 only specifies
>bitstream, but leave encoding options to implementers.
>
>However, we did recommend the use of GOB header to improve performance in the
>presence of packet loss. We tried very hard to avoid imposing any additional 
>requirements on H.263 encoder than H.263 spec.
>


I'm not sure that you understand that I'm completely *agreeing* with you.
GOB headers are not required for using Mode A at GOB boundaries, and
should not be required.  I just want the document to say that very clearly.
Perhaps something like:

  "Mode A can be used at GOB boundaries even if no GOB header was used in
   the bitstream (although this use is discouraged due to the dependencies
   it creates across GOB boundaries)."

Again, all I was asking for is for the text to be made more clear.


> 
>>
>>ITEM 7:
>>
>>It has come to my attention that some company may have implemented
>>the first-draft version of the packetization definition without
>>indicating in any way that they have done a non-standard packetization.
>>Is it possible to detect whether first draft or the current draft was used
>>by looking at the bits in the headers?  Should it be?  This issue has
>>caused a controversy in some recent ITU email discussions (on
>>ITU-SG16@MAILBAG.INTEL.COM).
>>
>>It may be useful to have some form of "in-band" detection of the
>>packetization method (just as H.263 has an "in-band" indication of which
>>of its options are in use).  As I understand it, there used to be a
>>version number in the packet header, but that was removed from the current
>>draft.  Why?  (I understand that it was not meant to distinguish between
>>draft versions of the standard, especially since draft 1 has expired, but
>>that is one way to have a detectable in-band signal of the type of
>>packetization.)
>
>We had discussed this in IETF meeting at San Jose. The group consensus was
>to remove it mainly because it introduced another multilexing points. Steve
>and Mark might help to explain this again if this is not clear enough.


I will respect your judgement on that.  I am mostly concerned because
of the company that goofed up and implemented the first draft.  Perhaps
they will just have to fix their implementation.

(And I am also thinking about this because having a version number
would be one possible way to deal with the H.263+ issue.)

I'm not totally sure what you mean by saying it "introduced another
multiplexing point".  I guess I would like to hear the explanation.
Sorry to be so ill-informed.  I don't see how "in-band" signaling of a
packetization type differs from the "in-band" signaling of modes in
H.263, or why it is a problem (other than being a waste of bits).


>>
>>ITEM 8:
>>
>>The draft packetization document makes no mention of H.263+ or its
>>impending impact on the packetization plan.  At a minimum, it should
>>do two things:
>>
>>1) mention the existence of the planned enhancements, and
>>
>>2) describe some plan for later accommodating those enhancements
>>
>>This topic again brings up the issue of having a way of detecting
>>the packetization method.
>>
>>
>This was also discussed at IETF meeting in San Jose while version field was
>debated. The suggestion from the AVT working group was to separate H.263+
>new features from current H.263, and design a separate payload format.
>Considering that H.263+ effort is still ongoing, some of us at Intel already
>started along that path. We have a draft payload format that is being
>reviewed internally at Intel. I announced in Memphis that we welcome any
>constructive input to the new payload format draft for h.263+. 


You need to remember, however, that H.263+ and H.263 are *not* two
separate things.  They are one single standard.  "H.263+" is just a nickname
for some new optional enhancements that will be part of H.263 itself.  When
you get a copy of the H.263 standard a year from now, it will just say it
is H.263.  It will *not* say it is H.263+, although it will have many H.263+
features in it.  "H.263+" is just a nickname for a project aimed at
enhancing a living standard, it is not the name of the standard itself.

I still strongly reiterate the two things that I say should be
done as shown above.

I'm suggesting that you add a couple of sentences such as:

  "The packetization method described in this document applies
   to the 1996 version of H.263.  Although new enhancement features
   are scheduled for adoption into H.263 in 1998 or later, the
   packetization method for H.263 bitstreams which use those new
   optional features is beyond the scope of this specification.
   A different kind of packetization will probably be needed
   for bitstreams using any of the new features adopted after 1996."

If you don't even *mention* those enhancements, someone will someday
pick up your RFC and pick up the current version of H.263 and get
very confused, because the document says it can packetize H.263
but H.263 has a lot of stuff in it that is completely beyond the
scope of what the document's packetization can handle.

I know that you're well aware of H.263+ (after all, you helped
design it).  But this document indicates no awareness of it at all.

Again, I think all I am asking for here is for clarity.  The document
should clearly indicate its scope -- it applies only to the 1996
version of H.263 and does not apply to bitstreams that use the new
enhancement features being added to create the 1998 version of H.263.
It should say that.  Clearly.


I would love to see a copy of your drafted ideas for H.263+
packetization.  That is certain to be a very valuable contribution.
When do you think your draft will be distributed?



One more comment.  Chad, you left out my ITEM 6.  I will ask you
again directly:  Were there any technical changes made since
the January draft?  This is an important question.  A copy of my ITEM 6
is attached.

& ITEM 6:
& 
& The email message that was sent with version 4 of the proposed
& packetization specification says that the changes for this revision
& are "mostly editorial".  It is very important for us to know whether
& *any* of those changes affect the technical content, especially
& since the ITU just "determined" their packetization definition based
& on the third draft.


I am sure that we don't want the ITU to decide to use a different
packetization than the IETF.  In order to avoid that, the ITU
must be fully involved, fully aware, and fully in agreement with
what is happening in the IETF (and vice versa).  Personally, I might
like to see the two organizations using verbatim "common text" in
this case.

I don't understand the process of standardization in the IETF,
but I hope it can be coordinated in some way with the needs of
the ITU.  The ITU is planning to "decide" (i.e., specify a completely
final standard for) a packetization in January of 1998.

I would like to request that discussions about this topic be
copied to *both* the itu-adv-video@listserv.iterated.com and
the rem-conf@es.net email reflectors.  (The people on the
itu-sg16@mailbag.intel.com might be interested too, but I'm
not sure.)


and here's a new one:

ITEM 10:

Also, as pointed out by Miska Hannuksela, the document should
probably also discuss the difficult situation for large picture
formats (4CIF and 16CIF) which have multiple rows of macroblocks
per GOB.  This can create a packet-to-packet data dependency
when using Mode B or Mode C packetization.

Perhaps adding a few sentences like:

  "The use of large picture formats (4CIF and 16CIF) in H.263 is
   another situation which is problematic for the Mode B
   and Mode C packetization.  These large pictures have more
   than one row of macroblocks per GOB, and the lower rows
   of macroblocks in each GOB are predicted in a manner similar to
   that of GOBs sent without headers in the smaller format pictures.
   This can create a data dependency between a Mode B or Mode C packet
   and some other packet sent for the picture.  The use of Mode B or
   Mode C packet types is allowed for these large pictures, but
   designers of systems using such video should be aware of the
   packet-crossing dependency that this can create, and its possible
   impact on decoding quality when some packet is lost or received in
   error."


Best Wishes,
Gary Sullivan

From rem-conf-request@tmpmail.es.net Fri Apr 11 20:44:22 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Fri, 11 Apr 1997 17:44:03 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wFqfr-0001pb-00; Fri, 11 Apr 1997 17:28:11 -0700
Date: Fri, 11 Apr 1997 20:24:37 -0400
From: garys@pictel.com (Gary Sullivan)
Message-Id: <9704120024.AA26305@python.pictel.com>
To: czhu@mailbox.jf.intel.com
Subject: Re: RTP Payload Format for H.263 Stream
Cc: ITU-SG16@MAILBAG.INTEL.COM, itu-adv-video@listserv.iterated.com, 
    rem-conf@es.net
Resent-Message-ID: <"eiDnD1.0.2k1.RSjJp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Fri, 11 Apr 1997 17:28:11 -0700




Some comments in response to Chad Zhu's response to my 9-item
list of issues.  The following comments ask for further
editorial clarification and further understanding, but
*no* changes in technical content:


--------------------------------------
>Date: Fri, 11 Apr 1997 14:30:32 -0700
>To: garys@pictel.com (Gary Sullivan)
>From: "C. Zhu" <czhu@mailbox.jf.intel.com>
>Subject: Re: RTP Payload Format for H.263 Stream
>Cc: rem-conf@es.net
>
>Gary,
>
>Sorry for the delayed response. I lost email connection at Memphis. Thanks
>to Steve Casner and Philip Lantz, I was able to read your mail and discussed
>it with Steve before my presenation at Memphis.


Good.  I'm glad my comments were able to get to you one way or another.


>
>I agree with item 1, 2 and 3, and they are excellent comments. We had some
>discussions on version field and H.263+ at IETF San Jose meeting. It was
>decided then to remove the version field and start a separate payload draft
>for H.263+. In fact, some of us at Intel are reviewing a draft internally,
>and we will release it to this mailing list for comments. Everyone is more
>than welcome to provide input and work with us on it.
>
>Please see my comments below for more detailed explainations.
>
>Regards.
>
>--Chad
>
>
>At 08:24 PM 4/8/97 -0400, you wrote:
>
>
>>
>>ITEM 4:
>>
>>The document describes a packetization with headers that
>>duplicate the functionality of virtually all of the content
>>of the video bitstream picture header.  This led me to
>>wonder whether the picture header was still sent, or whether
>>the packetization headers were just a wrapper around the
>>existing bitstream definition with a duplication of much
>>of its content.  After talking with Mr. Zhu, I have concluded
>>that it is just a wrapper and that the entire H.263 bitstream
>>is sent in the payload without alteration.  I agree that it
>>is desirable to sent the entire H.263 bitstream in the payload.
>>I think it might be helpful to clarify the document to make
>>sure that this is understood.
>>
>
>This is actually clearly stated in the current draft in section 4, Usage of RTP.
>


I just re-read that section and I still don't think it is clearly
stated.  I'm looking for perhaps one sentence that says something like:

  "The H.263 payload bitstream itself is carried without alteration,
   including the picture start code and the entire picture header
   (even though much of the picture header information is duplicated
   in the RTP header)."

I could not find anything like that.  Can you quote me the sentences
that you think "clearly state" that, specifically in reference to the
picture header information and picture start codes?

(I was not the only one who was confused about this topic.)

Again, all I was asking for is for the text to be made more clear.
You may think it is clear, but I am not convinced.  The people who
wrote a document often tend to think it is more clear than others do.
It should not hurt to try to make it even more clear.



>>
>>ITEM 5:
>>
>>The document describes a "Mode A" packetization which can be
>>used to fragment the H.263 bitstream at picture header boundaries
>>or at GOB boundaries, and discusses how the presence of GOB headers
>>can aid in this process.  I did not understand from reading the
>>document whether fragmentation at GOB boundaries was allowed even
>>when GOB headers were not present.  After talking with Mr. Zhu,
>>I have concluded that the fragmentation *is* allowed without the
>>presence of GOB headers.  Some clarifying wording to that effect
>>might be helpful.
>>
>
>I agree it would be helpful, but do not see that absolutely necessary. 
>
>What was speficied in the draft was that a "Mode A" packet starts at a GOB
>boundary. It did not "require" a GOB header to be present, because we do not
>want to redefine what a GOB is, or how it is coded. We would rather leave
>that decision to each implemenaters, the same way that ITU H.263 only specifies
>bitstream, but leave encoding options to implementers.
>
>However, we did recommend the use of GOB header to improve performance in the
>presence of packet loss. We tried very hard to avoid imposing any additional 
>requirements on H.263 encoder than H.263 spec.
>


I'm not sure that you understand that I'm completely *agreeing* with you.
GOB headers are not required for using Mode A at GOB boundaries, and
should not be required.  I just want the document to say that very clearly.
Perhaps something like:

  "Mode A can be used at GOB boundaries even if no GOB header was used in
   the bitstream (although this use is discouraged due to the dependencies
   it creates across GOB boundaries)."

Again, all I was asking for is for the text to be made more clear.


> 
>>
>>ITEM 7:
>>
>>It has come to my attention that some company may have implemented
>>the first-draft version of the packetization definition without
>>indicating in any way that they have done a non-standard packetization.
>>Is it possible to detect whether first draft or the current draft was used
>>by looking at the bits in the headers?  Should it be?  This issue has
>>caused a controversy in some recent ITU email discussions (on
>>ITU-SG16@MAILBAG.INTEL.COM).
>>
>>It may be useful to have some form of "in-band" detection of the
>>packetization method (just as H.263 has an "in-band" indication of which
>>of its options are in use).  As I understand it, there used to be a
>>version number in the packet header, but that was removed from the current
>>draft.  Why?  (I understand that it was not meant to distinguish between
>>draft versions of the standard, especially since draft 1 has expired, but
>>that is one way to have a detectable in-band signal of the type of
>>packetization.)
>
>We had discussed this in IETF meeting at San Jose. The group consensus was
>to remove it mainly because it introduced another multilexing points. Steve
>and Mark might help to explain this again if this is not clear enough.


I will respect your judgement on that.  I am mostly concerned because
of the company that goofed up and implemented the first draft.  Perhaps
they will just have to fix their implementation.

(And I am also thinking about this because having a version number
would be one possible way to deal with the H.263+ issue.)

I'm not totally sure what you mean by saying it "introduced another
multiplexing point".  I guess I would like to hear the explanation.
Sorry to be so ill-informed.  I don't see how "in-band" signaling of a
packetization type differs from the "in-band" signaling of modes in
H.263, or why it is a problem (other than being a waste of bits).


>>
>>ITEM 8:
>>
>>The draft packetization document makes no mention of H.263+ or its
>>impending impact on the packetization plan.  At a minimum, it should
>>do two things:
>>
>>1) mention the existence of the planned enhancements, and
>>
>>2) describe some plan for later accommodating those enhancements
>>
>>This topic again brings up the issue of having a way of detecting
>>the packetization method.
>>
>>
>This was also discussed at IETF meeting in San Jose while version field was
>debated. The suggestion from the AVT working group was to separate H.263+
>new features from current H.263, and design a separate payload format.
>Considering that H.263+ effort is still ongoing, some of us at Intel already
>started along that path. We have a draft payload format that is being
>reviewed internally at Intel. I announced in Memphis that we welcome any
>constructive input to the new payload format draft for h.263+. 


You need to remember, however, that H.263+ and H.263 are *not* two
separate things.  They are one single standard.  "H.263+" is just a nickname
for some new optional enhancements that will be part of H.263 itself.  When
you get a copy of the H.263 standard a year from now, it will just say it
is H.263.  It will *not* say it is H.263+, although it will have many H.263+
features in it.  "H.263+" is just a nickname for a project aimed at
enhancing a living standard, it is not the name of the standard itself.

I still strongly reiterate the two things that I say should be
done as shown above.

I'm suggesting that you add a couple of sentences such as:

  "The packetization method described in this document applies
   to the 1996 version of H.263.  Although new enhancement features
   are scheduled for adoption into H.263 in 1998 or later, the
   packetization method for H.263 bitstreams which use those new
   optional features is beyond the scope of this specification.
   A different kind of packetization will probably be needed
   for bitstreams using any of the new features adopted after 1996."

If you don't even *mention* those enhancements, someone will someday
pick up your RFC and pick up the current version of H.263 and get
very confused, because the document says it can packetize H.263
but H.263 has a lot of stuff in it that is completely beyond the
scope of what the document's packetization can handle.

I know that you're well aware of H.263+ (after all, you helped
design it).  But this document indicates no awareness of it at all.

Again, I think all I am asking for here is for clarity.  The document
should clearly indicate its scope -- it applies only to the 1996
version of H.263 and does not apply to bitstreams that use the new
enhancement features being added to create the 1998 version of H.263.
It should say that.  Clearly.


I would love to see a copy of your drafted ideas for H.263+
packetization.  That is certain to be a very valuable contribution.
When do you think your draft will be distributed?



One more comment.  Chad, you left out my ITEM 6.  I will ask you
again directly:  Were there any technical changes made since
the January draft?  This is an important question.  A copy of my ITEM 6
is attached.

& ITEM 6:
& 
& The email message that was sent with version 4 of the proposed
& packetization specification says that the changes for this revision
& are "mostly editorial".  It is very important for us to know whether
& *any* of those changes affect the technical content, especially
& since the ITU just "determined" their packetization definition based
& on the third draft.


I am sure that we don't want the ITU to decide to use a different
packetization than the IETF.  In order to avoid that, the ITU
must be fully involved, fully aware, and fully in agreement with
what is happening in the IETF (and vice versa).  Personally, I might
like to see the two organizations using verbatim "common text" in
this case.

I don't understand the process of standardization in the IETF,
but I hope it can be coordinated in some way with the needs of
the ITU.  The ITU is planning to "decide" (i.e., specify a completely
final standard for) a packetization in January of 1998.

I would like to request that discussions about this topic be
copied to *both* the itu-adv-video@listserv.iterated.com and
the rem-conf@es.net email reflectors.  (The people on the
itu-sg16@mailbag.intel.com might be interested too, but I'm
not sure.)


and here's a new one:

ITEM 10:

Also, as pointed out by Miska Hannuksela, the document should
probably also discuss the difficult situation for large picture
formats (4CIF and 16CIF) which have multiple rows of macroblocks
per GOB.  This can create a packet-to-packet data dependency
when using Mode B or Mode C packetization.

Perhaps adding a few sentences like:

  "The use of large picture formats (4CIF and 16CIF) in H.263 is
   another situation which is problematic for the Mode B
   and Mode C packetization.  These large pictures have more
   than one row of macroblocks per GOB, and the lower rows
   of macroblocks in each GOB are predicted in a manner similar to
   that of GOBs sent without headers in the smaller format pictures.
   This can create a data dependency between a Mode B or Mode C packet
   and some other packet sent for the picture.  The use of Mode B or
   Mode C packet types is allowed for these large pictures, but
   designers of systems using such video should be aware of the
   packet-crossing dependency that this can create, and its possible
   impact on decoding quality when some packet is lost or received in
   error."


Best Wishes,
Gary Sullivan


From rem-conf-request@es.net Sat Apr 12 14:41:46 1997 
Received: from mailbag.jf.intel.com (actually 134.134.248.4) by osi-west.es.net 
          with ESnet SMTP (PP); Sat, 12 Apr 1997 11:41:39 -0700
Received: from ideal.jf.intel.com (ideal.jf.intel.com [134.134.130.5]) 
          by mailbag.jf.intel.com (8.8.5/8.7.3) with ESMTP id LAA11812;
          Sat, 12 Apr 1997 11:42:21 -0700 (PDT)
Received: from zoo (zoo.jf.intel.com [134.134.158.177]) 
          by ideal.jf.intel.com (8.8.5/8.8.4) with SMTP id LAA17898;
          Sat, 12 Apr 1997 11:37:20 -0700 (PDT)
Message-Id: <1.5.4.32.19970412184044.0098f1fc@ibeam.intel.com>
X-Sender: czhu@ibeam.intel.com
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 12 Apr 1997 11:40:44 -0700
To: rem-conf@es.net
From: "C. Zhu" <czhu@mailbox.jf.intel.com>
Subject: Re: RTP Payload Format for H.263 Stream
Cc: garys@pictel.com, itu-adv-video@listserv.iterated.com, casner@precept.com


Gary,

I would like to make it clear here that I welcome all the comments you and
Miska have made in last few messages. I appreciate your effort in providing
concrete examples of what you are looking for. I will make an effort to
incorporate *all* clarification suggestions on the technical content of the
draft in the next revision. While I am working on it, if you or others find
more similar need for clarifications, feel free to send it to me or *this*
mailing list. 

For Item 6, the answer is: "mostly editorial changes" should be "all
editorial changes" as you have mentioned.

As you have requested, I copied this message to
itu-adv-video@listserv.iterated.com,
even though I strongly suggest those who care about this topic should join
IETF mailing list. 

As to why version field was removed, I am not the best person to answer
that. You should ask Steve Casner or Mark Handley for the best answers.

If I miss something important, please let me know.

-- Chad


  

At 08:24 PM 4/11/97 -0400, you wrote:
>
>
>
>Some comments in response to Chad Zhu's response to my 9-item
>list of issues.  The following comments ask for further
>editorial clarification and further understanding, but
>*no* changes in technical content:
>


From rem-conf-request@tmpmail.es.net Sat Apr 12 15:06:32 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Sat, 12 Apr 1997 12:06:29 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wG7kD-0002e8-00; Sat, 12 Apr 1997 11:41:49 -0700
Message-Id: <1.5.4.32.19970412184044.0098f1fc@ibeam.intel.com>
X-Sender: czhu@ibeam.intel.com
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 12 Apr 1997 11:40:44 -0700
To: rem-conf@es.net
From: "C. Zhu" <czhu@mailbox.jf.intel.com>
Subject: Re: RTP Payload Format for H.263 Stream
Cc: garys@pictel.com, itu-adv-video@listserv.iterated.com, casner@precept.com
Resent-Message-ID: <"uE4Q-3.0._U2.iTzJp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Sat, 12 Apr 1997 11:41:49 -0700


Gary,

I would like to make it clear here that I welcome all the comments you and
Miska have made in last few messages. I appreciate your effort in providing
concrete examples of what you are looking for. I will make an effort to
incorporate *all* clarification suggestions on the technical content of the
draft in the next revision. While I am working on it, if you or others find
more similar need for clarifications, feel free to send it to me or *this*
mailing list. 

For Item 6, the answer is: "mostly editorial changes" should be "all
editorial changes" as you have mentioned.

As you have requested, I copied this message to
itu-adv-video@listserv.iterated.com,
even though I strongly suggest those who care about this topic should join
IETF mailing list. 

As to why version field was removed, I am not the best person to answer
that. You should ask Steve Casner or Mark Handley for the best answers.

If I miss something important, please let me know.

-- Chad


  

At 08:24 PM 4/11/97 -0400, you wrote:
>
>
>
>Some comments in response to Chad Zhu's response to my 9-item
>list of issues.  The following comments ask for further
>editorial clarification and further understanding, but
>*no* changes in technical content:
>



From rem-conf-request@es.net Sun Apr 13 02:01:32 1997 
Received: from relay0.jaring.my by osi-west.es.net with ESnet SMTP (PP);
          Sat, 12 Apr 1997 23:01:21 -0700
Received: from walsin.UUCP (root@localhost) by relay0.jaring.my (8.6.13/8.6.12) 
          with UUCP id NAA27389 for rem-conf@es.net;
          Sun, 13 Apr 1997 13:36:38 +0800
Received: by walsin.com.my (UUPC/extended 1.12p);
          Sun, 13 Apr 1997 13:29:40 +0200
Message-ID: <3350c3a4.walsin@walsin.com.my>
From: ShouJen <sjn@walsin.com.my>
To: rem-conf@es.net
Date: Sun, 13 Apr 1997 12:18:07 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: PostScript reader?
Reply-to: sjn@walsin.com.my
X-Confirm-Reading-To: sjn@walsin.com.my
X-pmrqc: 1
Priority: normal
X-mailer: Pegasus Mail for Win32 (v2.42a)

Hi,

Does anyone know where I can get a copy of the program for reading a 
postscript file in windows?

Thanks!

--------------------------------------------------------------
Shou-Jen Ng
Walsin Technology Corporation (M) Sdn. Bhd.
Voice: 603-9857800
Fax  : 603-9857011                    email : sjn@walsin.com.my
WWW  : http://www.walsintech.com


From rem-conf-request@tmpmail.es.net Sun Apr 13 02:15:23 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Sat, 12 Apr 1997 23:15:19 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wGIM2-0000f7-00; Sat, 12 Apr 1997 23:01:34 -0700
Message-ID: <3350c3a4.walsin@walsin.com.my>
From: ShouJen <sjn@walsin.com.my>
To: rem-conf@es.net
Date: Sun, 13 Apr 1997 12:18:07 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: PostScript reader?
Reply-to: sjn@walsin.com.my
X-Confirm-Reading-To: sjn@walsin.com.my
Priority: normal
X-mailer: Pegasus Mail for Win32 (v2.42a)
Resent-Message-ID: <"K8XDJ.0.qd.zQ7Kp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Sat, 12 Apr 1997 23:01:34 -0700

Hi,

Does anyone know where I can get a copy of the program for reading a 
postscript file in windows?

Thanks!

--------------------------------------------------------------
Shou-Jen Ng
Walsin Technology Corporation (M) Sdn. Bhd.
Voice: 603-9857800
Fax  : 603-9857011                    email : sjn@walsin.com.my
WWW  : http://www.walsintech.com



From rem-conf-request@es.net Sun Apr 13 14:33:47 1997 
Received: from mailbag.jf.intel.com by osi-west.es.net with ESnet SMTP (PP);
          Sun, 13 Apr 1997 11:33:42 -0700
Received: from ideal.jf.intel.com (ideal.jf.intel.com [134.134.130.5]) 
          by mailbag.jf.intel.com (8.8.5/8.7.3) with ESMTP id LAA08638 
          for <rem-conf@es.net>; Sun, 13 Apr 1997 11:35:58 -0700 (PDT)
Received: from ishark.jf.intel.com (ishark.jf.intel.com [134.134.210.2]) 
          by ideal.jf.intel.com (8.8.5/8.8.4) with SMTP id LAA09771 
          for rem-conf@es.net; Sun, 13 Apr 1997 11:30:55 -0700 (PDT)
Message-Id: <199704131830.LAA09771@ideal.jf.intel.com>
X-Authentication-Warning: ideal.jf.intel.com: ishark.jf.intel.com 
                          [134.134.210.2] didn't use HELO protocol
To: rem-conf@es.net
Subject: Re: RTP Payload Format for H.263 Stream
In-reply-to: Your message of Fri, 11 Apr 97 20:24:37 -0400. <9704120024.AA26305@python.pictel.com>
Date: Sun, 13 Apr 97 11:34:29 PDT
From: Linda Cline <lscline@mailbox.jf.intel.com>

If I may interject, this is what I recall of the discussion at San Jose.
Please note that the version was not present in the first draft, and thus
would not help differentiate that draft from the ones that followed.  Other
payload specifications do not have a verion field and when Chad put together
the first draft, we did not foresee that one might be useful.  We did have
a desire to accomodate H.263+ in this payload specification and that is one
reason why the version was added to the second draft, as well as to alleviate
any future problems with header changes.  However, it was brought up at San
Jose that current H.263 decoders would not be able to accomodate an H.263+
bitstream using the optional features and thus would better be identified as
a separate payload type.  Also, implementors were reluctant to add yet 
another control point at the profile level, when the payload type is 
available for this.  Without that justification, there was little else left
to support addition of a version field for a draft that is about to go to
last call.

There is definitely an issue for implementors who have implemented the first
draft of this payload spec.  There is not just one, but several companies
which have done this.  In the cases of which I'm aware, this is used within
an H.323 stack where the version can be indicated out of band, although I
don't believe this is yet being done.

Linda Cline

>>>ITEM 7:
>>>
>>>It has come to my attention that some company may have implemented
>>>the first-draft version of the packetization definition without
>>>indicating in any way that they have done a non-standard packetization.
>>>Is it possible to detect whether first draft or the current draft was used
>>>by looking at the bits in the headers?  Should it be?  This issue has
>>>caused a controversy in some recent ITU email discussions (on
>>>ITU-SG16@MAILBAG.INTEL.COM).
>>>
>>>It may be useful to have some form of "in-band" detection of the
>>>packetization method (just as H.263 has an "in-band" indication of which
>>>of its options are in use).  As I understand it, there used to be a
>>>version number in the packet header, but that was removed from the current
>>>draft.  Why?  (I understand that it was not meant to distinguish between
>>>draft versions of the standard, especially since draft 1 has expired, but
>>>that is one way to have a detectable in-band signal of the type of
>>>packetization.)
>>
>>We had discussed this in IETF meeting at San Jose. The group consensus was
>>to remove it mainly because it introduced another multilexing points. Steve
>>and Mark might help to explain this again if this is not clear enough.
>
>
>I will respect your judgement on that.  I am mostly concerned because
>of the company that goofed up and implemented the first draft.  Perhaps
>they will just have to fix their implementation.
>
>(And I am also thinking about this because having a version number
>would be one possible way to deal with the H.263+ issue.)
>
>I'm not totally sure what you mean by saying it "introduced another
>multiplexing point".  I guess I would like to hear the explanation.
>Sorry to be so ill-informed.  I don't see how "in-band" signaling of a
>packetization type differs from the "in-band" signaling of modes in
>H.263, or why it is a problem (other than being a waste of bits).

From rem-conf-request@tmpmail.es.net Sun Apr 13 14:49:32 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Sun, 13 Apr 1997 11:49:27 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wGU61-0007Vc-00; Sun, 13 Apr 1997 11:33:49 -0700
Message-Id: <199704131830.LAA09771@ideal.jf.intel.com>
X-Authentication-Warning: ideal.jf.intel.com: ishark.jf.intel.com 
                          [134.134.210.2] didn't use HELO protocol
To: rem-conf@es.net
Subject: Re: RTP Payload Format for H.263 Stream
In-reply-to: Your message of Fri, 11 Apr 97 20:24:37 -0400. <9704120024.AA26305@python.pictel.com>
Date: Sun, 13 Apr 97 11:34:29 PDT
From: Linda Cline <lscline@mailbox.jf.intel.com>
Resent-Message-ID: <"nKE852.0.337.DSIKp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Sun, 13 Apr 1997 11:33:49 -0700

If I may interject, this is what I recall of the discussion at San Jose.
Please note that the version was not present in the first draft, and thus
would not help differentiate that draft from the ones that followed.  Other
payload specifications do not have a verion field and when Chad put together
the first draft, we did not foresee that one might be useful.  We did have
a desire to accomodate H.263+ in this payload specification and that is one
reason why the version was added to the second draft, as well as to alleviate
any future problems with header changes.  However, it was brought up at San
Jose that current H.263 decoders would not be able to accomodate an H.263+
bitstream using the optional features and thus would better be identified as
a separate payload type.  Also, implementors were reluctant to add yet 
another control point at the profile level, when the payload type is 
available for this.  Without that justification, there was little else left
to support addition of a version field for a draft that is about to go to
last call.

There is definitely an issue for implementors who have implemented the first
draft of this payload spec.  There is not just one, but several companies
which have done this.  In the cases of which I'm aware, this is used within
an H.323 stack where the version can be indicated out of band, although I
don't believe this is yet being done.

Linda Cline

>>>ITEM 7:
>>>
>>>It has come to my attention that some company may have implemented
>>>the first-draft version of the packetization definition without
>>>indicating in any way that they have done a non-standard packetization.
>>>Is it possible to detect whether first draft or the current draft was used
>>>by looking at the bits in the headers?  Should it be?  This issue has
>>>caused a controversy in some recent ITU email discussions (on
>>>ITU-SG16@MAILBAG.INTEL.COM).
>>>
>>>It may be useful to have some form of "in-band" detection of the
>>>packetization method (just as H.263 has an "in-band" indication of which
>>>of its options are in use).  As I understand it, there used to be a
>>>version number in the packet header, but that was removed from the current
>>>draft.  Why?  (I understand that it was not meant to distinguish between
>>>draft versions of the standard, especially since draft 1 has expired, but
>>>that is one way to have a detectable in-band signal of the type of
>>>packetization.)
>>
>>We had discussed this in IETF meeting at San Jose. The group consensus was
>>to remove it mainly because it introduced another multilexing points. Steve
>>and Mark might help to explain this again if this is not clear enough.
>
>
>I will respect your judgement on that.  I am mostly concerned because
>of the company that goofed up and implemented the first draft.  Perhaps
>they will just have to fix their implementation.
>
>(And I am also thinking about this because having a version number
>would be one possible way to deal with the H.263+ issue.)
>
>I'm not totally sure what you mean by saying it "introduced another
>multiplexing point".  I guess I would like to hear the explanation.
>Sorry to be so ill-informed.  I don't see how "in-band" signaling of a
>packetization type differs from the "in-band" signaling of modes in
>H.263, or why it is a problem (other than being a waste of bits).


From rem-conf-request@es.net Sun Apr 13 15:51:39 1997 
Received: from noknic.nokia.com by osi-west.es.net with ESnet SMTP (PP);
          Sun, 13 Apr 1997 12:51:26 -0700
Received: from pepper.research.nokia.com (pepper.research.nokia.com [131.228.12.3]) 
          by noknic.nokia.com (8.6.9/8.6.9) with SMTP id WAA07272 
          for <rem-conf@es.net>; Sun, 13 Apr 1997 22:51:21 +0300
Received: (from smap@localhost) by pepper.research.nokia.com (8.6.13/8.6.13) 
          id WAA14477 for <rem-conf@es.net>; Sun, 13 Apr 1997 22:51:17 +0300
Received: from nrchub01he.research.nokia.com(131.228.10.247) 
          by pepper.research.nokia.com via smap (V1.3) id sma014470;
          Sun Apr 13 22:50:31 1997
Received: from Microsoft Mail (PU Serial #1751) 
          by nrchub01he.research.nokia.com (PostalUnion/SMTP(tm) v2.1.9c 
          for Windows NT(tm)) id AA-1997Apr13.214843.1751.631420;
          Sun, 13 Apr 1997 21:50:50 +0200
From: ali.turker@research.nokia.com (Turker Mustafa Ali NRC/Tre)
To: rem-conf@es.net (ietf)
Message-ID: <1997Apr13.214843.1751.631420@nrchub01he.research.nokia.com>
X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Date: Sun, 13 Apr 1997 21:50:50 +0200
Subject: subscribe





From rem-conf-request@es.net Sun Apr 13 17:48:06 1997 
Received: from baygate.bayarea.net by osi-west.es.net with ESnet SMTP (PP);
          Sun, 13 Apr 1997 14:48:01 -0700
Received: from lantron (randy_178.bayarea.net [205.219.91.178]) 
          by baygate.bayarea.net (8.8.5/8.8.5) with SMTP id OAA08583;
          Sun, 13 Apr 1997 14:45:50 -0700 (PDT)
Sender: randy@bayarea.net
Message-ID: <33515477.342E@BayArea.Net>
Date: Sun, 13 Apr 1997 14:47:35 -0700
From: Randy Miyazaki <Randy@bayarea.net>
X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5 sun4c)
MIME-Version: 1.0
To: sjn@walsin.com.my
CC: rem-conf@es.net
Subject: Re: PostScript reader?
References: <3350c3a4.walsin@walsin.com.my>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

ShouJen wrote:
> 
> Hi,
> 
> Does anyone know where I can get a copy of the program for reading a
> postscript file in windows?
> 
> Thanks!
> 
> --------------------------------------------------------------
> Shou-Jen Ng
> Walsin Technology Corporation (M) Sdn. Bhd.
> Voice: 603-9857800
> Fax  : 603-9857011                    email : sjn@walsin.com.my
> WWW  : http://www.walsintech.com

i know people who use the alladin ghostscript stuff for the pc
http://www.cs.wisc.edu/~ghost/aladdin/obtain.html. i 'm a sun
workstation person, so i haven't tried it myownself. good luck.

...randy

-- 
	Randy Miyazaki	+1 408 452 0788
	San Jose, CA	+1 408 452 1602 FAX
	USA		Randy@BayArea.Net

From rem-conf-request@tmpmail.es.net Sun Apr 13 18:01:59 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Sun, 13 Apr 1997 15:01:54 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wGX83-0002Hh-00; Sun, 13 Apr 1997 14:48:07 -0700
Sender: randy@bayarea.net
Message-ID: <33515477.342E@BayArea.Net>
Date: Sun, 13 Apr 1997 14:47:35 -0700
From: Randy Miyazaki <Randy@bayarea.net>
X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5 sun4c)
MIME-Version: 1.0
To: sjn@walsin.com.my
CC: rem-conf@es.net
Subject: Re: PostScript reader?
References: <3350c3a4.walsin@walsin.com.my>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"6tN-_1.0.G92.NILKp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Sun, 13 Apr 1997 14:48:07 -0700

ShouJen wrote:
> 
> Hi,
> 
> Does anyone know where I can get a copy of the program for reading a
> postscript file in windows?
> 
> Thanks!
> 
> --------------------------------------------------------------
> Shou-Jen Ng
> Walsin Technology Corporation (M) Sdn. Bhd.
> Voice: 603-9857800
> Fax  : 603-9857011                    email : sjn@walsin.com.my
> WWW  : http://www.walsintech.com

i know people who use the alladin ghostscript stuff for the pc
http://www.cs.wisc.edu/~ghost/aladdin/obtain.html. i 'm a sun
workstation person, so i haven't tried it myownself. good luck.

...randy

-- 
	Randy Miyazaki	+1 408 452 0788
	San Jose, CA	+1 408 452 1602 FAX
	USA		Randy@BayArea.Net


From rem-conf-request@es.net Mon Apr 14 02:52:25 1997 
Received: from POSTAL.CSELT.STET.IT (actually postal.cselt.it) 
          by osi-west.es.net with ESnet SMTP (PP);
          Sun, 13 Apr 1997 23:52:11 -0700
Return-receipt-to: Filippo.DellaBetta@CSELT.IT
Received: from xrr1.cselt.stet.it by POSTAL.CSELT.STET.IT (PMDF V4.2-15 #4385) 
          id <01IHOUC18HJ4002A0L@POSTAL.CSELT.STET.IT>;
          Mon, 14 Apr 1997 08:50:24 MET
Received: by xrr1.cselt.stet.it 
          with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) 
          id <01BC48B1.A3DD93B0@xrr1.cselt.stet.it>;
          Mon, 14 Apr 1997 08:55:45 +0200
Date: Mon, 14 Apr 1997 08:55:47 +0200
From: Della Betta Filippo <Filippo.DellaBetta@CSELT.IT>
Subject: FW: PostScript reader?
To: 'REM-CONF' <rem-conf@es.net>
Message-id: <c=IT%a=_%p=CSELT%l=XRR2-970414065547Z-28544@xrr1.cselt.stet.it>
X-Envelope-to: rem-conf@es.net
MIME-version: 1.0
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit



>----------
>From: 	Randy Miyazaki[SMTP:Randy@bayarea.net]
>Sent: 	domenica, aprile 13, 1997 23:47
>To: 	rem-conf-dist@tmpmail.es.net
>Cc: 	rem-conf@es.net
>Subject: 	Re: PostScript reader?
>
>Randy wrote:
>>> 
>>> Hi,
>>> 
>>> Does anyone know where I can get a copy of the program for reading a
>>> postscript file in windows?
>>> 
>>> Thanks!
>>> 
>>i know people who use the alladin ghostscript stuff for the pc
>>http://www.cs.wisc.edu/~ghost/aladdin/obtain.html. i 'm a sun
>>workstation person, so i haven't tried it myownself. good luck.

I did. It does work.
Bye
	Filippo


>
>

From rem-conf-request@tmpmail.es.net Mon Apr 14 03:24:22 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Mon, 14 Apr 1997 00:24:17 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wGfct-0006ux-00; Sun, 13 Apr 1997 23:52:31 -0700
Date: Mon, 14 Apr 1997 08:55:47 +0200
From: Della Betta Filippo <Filippo.DellaBetta@CSELT.IT>
Subject: FW: PostScript reader?
To: 'REM-CONF' <rem-conf@es.net>
Message-id: <c=IT%a=_%p=CSELT%l=XRR2-970414065547Z-28544@xrr1.cselt.stet.it>
Old-X-Envelope-to: rem-conf@es.net
MIME-version: 1.0
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Resent-Message-ID: <"Bsvya2.0.YV6.lGTKp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Sun, 13 Apr 1997 23:52:31 -0700



>----------
>From: 	Randy Miyazaki[SMTP:Randy@bayarea.net]
>Sent: 	domenica, aprile 13, 1997 23:47
>To: 	rem-conf-dist@tmpmail.es.net
>Cc: 	rem-conf@es.net
>Subject: 	Re: PostScript reader?
>
>Randy wrote:
>>> 
>>> Hi,
>>> 
>>> Does anyone know where I can get a copy of the program for reading a
>>> postscript file in windows?
>>> 
>>> Thanks!
>>> 
>>i know people who use the alladin ghostscript stuff for the pc
>>http://www.cs.wisc.edu/~ghost/aladdin/obtain.html. i 'm a sun
>>workstation person, so i haven't tried it myownself. good luck.

I did. It does work.
Bye
	Filippo


>
>


From rem-conf-request@es.net Mon Apr 14 13:26:15 1997 
Received: from nobozo.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP);
          Mon, 14 Apr 1997 10:26:10 -0700
Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) 
          by nobozo.CS.Berkeley.EDU (8.6.10/8.6.3) with SMTP id KAA23404 
          for <rem-conf@es.net>; Mon, 14 Apr 1997 10:26:09 -0700
Date: Mon, 14 Apr 1997 10:26:09 -0700
Message-Id: <199704141726.KAA23404@nobozo.CS.Berkeley.EDU>
X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU
X-Mailer: Windows Eudora Version 2.1.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: rem-conf@es.net
From: Jerrlyn Iwata <jerrlyn@postgres.Berkeley.EDU>
Subject: [Reminder] Berkeley Multimedia & Graphics Seminar

                Berkeley Multimedia and Graphics Seminar 
        (Wednesday April 16, 1997 12:30-2:00 PDT 405 Soda Hall) 

"Issues in Delivering Images and Text from Diverse Environments via University
    Information Systems: Lessons from the Museum Educational Site Licensing
                                    Project" 

                                 Howard Besser 
                                 SIMS and BMRC 
                                 UC Berkeley 

        MBONE BROADCAST BEGINS AT 12.40 PDT (GMT - 8 HOURS)


From rem-conf-request@tmpmail.es.net Mon Apr 14 13:45:12 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Mon, 14 Apr 1997 10:45:08 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wGpWF-0004Vr-00; Mon, 14 Apr 1997 10:26:19 -0700
Date: Mon, 14 Apr 1997 10:26:09 -0700
Message-Id: <199704141726.KAA23404@nobozo.CS.Berkeley.EDU>
X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU
X-Mailer: Windows Eudora Version 2.1.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: rem-conf@es.net
From: Jerrlyn Iwata <jerrlyn@postgres.Berkeley.EDU>
Subject: [Reminder] Berkeley Multimedia & Graphics Seminar
Resent-Message-ID: <"aozXE2.0.6F4.xYcKp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Mon, 14 Apr 1997 10:26:19 -0700

                Berkeley Multimedia and Graphics Seminar 
        (Wednesday April 16, 1997 12:30-2:00 PDT 405 Soda Hall) 

"Issues in Delivering Images and Text from Diverse Environments via University
    Information Systems: Lessons from the Museum Educational Site Licensing
                                    Project" 

                                 Howard Besser 
                                 SIMS and BMRC 
                                 UC Berkeley 

        MBONE BROADCAST BEGINS AT 12.40 PDT (GMT - 8 HOURS)



From rem-conf-request@es.net Mon Apr 14 14:28:09 1997 
Received: from venus.Sun.COM by osi-west.es.net with ESnet SMTP (PP);
          Mon, 14 Apr 1997 11:28:04 -0700
Received: from Eng.Sun.COM ([129.146.1.25]) 
          by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA27234 
          for <rem-conf@es.net>; Mon, 14 Apr 1997 11:28:01 -0700
Received: from valathar.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) 
          id LAA00072; Mon, 14 Apr 1997 11:27:59 -0700
Received: from valathar by valathar.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA08806;
          Mon, 14 Apr 1997 11:27:56 -0700
Date: Mon, 14 Apr 1997 11:27:56 -0700 (PDT)
From: "Michael F. Speer" <Michael.Speer@Eng.Sun.COM>
Reply-To: "Michael F. Speer" <Michael.Speer@Eng.Sun.COM>
Subject: test
To: rem-conf@es.net
Message-ID: <Roam.SIMC.2.0.6.861042476.20517.speer@valathar >
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII


Please delete


From rem-conf-request@tmpmail.es.net Mon Apr 14 14:41:52 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Mon, 14 Apr 1997 11:41:48 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wGqU7-0005BL-00; Mon, 14 Apr 1997 11:28:11 -0700
Date: Mon, 14 Apr 1997 11:27:56 -0700 (PDT)
From: "Michael F. Speer" <Michael.Speer@Eng.Sun.COM>
Reply-To: "Michael F. Speer" <Michael.Speer@Eng.Sun.COM>
Subject: test
To: rem-conf@es.net
Message-ID: <Roam.SIMC.2.0.6.861042476.20517.speer@valathar >
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Resent-Message-ID: <"y_ot-.0.It4.xSdKp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Mon, 14 Apr 1997 11:28:11 -0700


Please delete



From rem-conf-request@es.net Tue Apr 15 00:41:39 1997 
Received: from dworkin.wustl.edu by osi-west.es.net with ESnet SMTP (PP);
          Mon, 14 Apr 1997 21:41:33 -0700
Received: (from milind@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) 
          id XAA10439 for rem-conf@es.net; Mon, 14 Apr 1997 23:43:32 -0500
Date: Mon, 14 Apr 1997 23:43:32 -0500
From: "Milind M. Buddhikot" <milind@dworkin.wustl.edu>
Message-Id: <199704150443.XAA10439@dworkin.wustl.edu>
To: rem-conf@es.net
Subject: NOSSDAV97 registration open

                 The 7th International Workshop on
  Network and Operating System Support for Digital Audio and Video 

                          NOSSDAV'97

                    St. Louis, Missouri, USA

                         May 19-21, 1997


Registrations for NOSSDAV'97 are now being accepted.

The 7th International Workshop on Network and Operating Systems Support
for Digital Audio and Video (NOSSDAV 97) is the international workshop
concerned with state of the art technology in networking and operating
system support for multimedia systems.  For seven years, NOSSDAV has
proven to be an outstanding forum for researchers involved in building
innovative multimedia systems, networks and applications on both the
research and industrial front. Other topics that will be examined include
"middleware" for multimedia, media toolkits, mobile communications,
Virtual Reality (VR), real-time systems, software agents, digital libraries,
and other digital media besides audio and video.

A key aspect of the workshop is that it provides extensive discussion
periods during which attendees can informally discuss their current
work and future research directions.  Traditionally, NOSSDAV has
emphasized on high quality experimental research that prototypes
systems to explore innovative solutions to the problems in the diverse
areas of multimedia computing. NOSSDAV97 will continue this tradition.

A sample of the  sessions to be held at the workshop include:
	Multicast for Multimedia
	Networking: Packet Scheduling and Integrated Services
	Multimedia-on-Demand (MOD) Servers and Services
	Smoothing and Scaling on Endsystems
	Mobility and Wireless
	Operating System Optimizations
	Middleware for Multimedia

To maintain the atmosphere of a small intense workshop, attendance is
once again being limited to 80.

Spots at the workshop are being reserved for one author per paper and
Program Committee members until April 10th. All other registration requests
will be accepted on a first come first served basis. After April 10th any
other requests that previously could not be immediately accepted will be
confirmed if space is available.

Presenting Authors and PC Members should register as soon as possible!!

On line registration and workshop program information can be accessed
>from the NOSSDAV97 web page:
	http://www.arl.wustl.edu/arl/NOSSDAV97/

The workshop will be held at Innsbrook Estates. Located approximately 45
minutes from the St. Louis airport, Innsbrook Estates has everything you
would like in a resort: 18-hole golf course, 18-hole miniature
course, swimming pool, a 150 acre lake, sailing, fishing,
swimming, sand beaches, fitness center, lighted tennis courts,
volleyball courts, horse back riding, full conference facilities, etc.


Send inquiries to:

	NOSSDAV97@arl.wustl.edu


	ATTN: NOSSDAV97
	Department of Computer Science/ARL
	Campus Box 1045
	Washington University
	One Brookings Drive
	St. Louis MO 63130, USA

	Tele: 1 314 935 7534
	Fax: 1 314 935 7302



From rem-conf-request@tmpmail.es.net Tue Apr 15 00:56:48 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Mon, 14 Apr 1997 21:56:45 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wH03l-0001eG-00; Mon, 14 Apr 1997 21:41:37 -0700
Date: Mon, 14 Apr 1997 23:43:32 -0500
From: "Milind M. Buddhikot" <milind@dworkin.wustl.edu>
Message-Id: <199704150443.XAA10439@dworkin.wustl.edu>
To: rem-conf@es.net
Subject: NOSSDAV97 registration open
Resent-Message-ID: <"8ddau1.0.3Z1.1SmKp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Mon, 14 Apr 1997 21:41:37 -0700

                 The 7th International Workshop on
  Network and Operating System Support for Digital Audio and Video 

                          NOSSDAV'97

                    St. Louis, Missouri, USA

                         May 19-21, 1997


Registrations for NOSSDAV'97 are now being accepted.

The 7th International Workshop on Network and Operating Systems Support
for Digital Audio and Video (NOSSDAV 97) is the international workshop
concerned with state of the art technology in networking and operating
system support for multimedia systems.  For seven years, NOSSDAV has
proven to be an outstanding forum for researchers involved in building
innovative multimedia systems, networks and applications on both the
research and industrial front. Other topics that will be examined include
"middleware" for multimedia, media toolkits, mobile communications,
Virtual Reality (VR), real-time systems, software agents, digital libraries,
and other digital media besides audio and video.

A key aspect of the workshop is that it provides extensive discussion
periods during which attendees can informally discuss their current
work and future research directions.  Traditionally, NOSSDAV has
emphasized on high quality experimental research that prototypes
systems to explore innovative solutions to the problems in the diverse
areas of multimedia computing. NOSSDAV97 will continue this tradition.

A sample of the  sessions to be held at the workshop include:
	Multicast for Multimedia
	Networking: Packet Scheduling and Integrated Services
	Multimedia-on-Demand (MOD) Servers and Services
	Smoothing and Scaling on Endsystems
	Mobility and Wireless
	Operating System Optimizations
	Middleware for Multimedia

To maintain the atmosphere of a small intense workshop, attendance is
once again being limited to 80.

Spots at the workshop are being reserved for one author per paper and
Program Committee members until April 10th. All other registration requests
will be accepted on a first come first served basis. After April 10th any
other requests that previously could not be immediately accepted will be
confirmed if space is available.

Presenting Authors and PC Members should register as soon as possible!!

On line registration and workshop program information can be accessed
>from the NOSSDAV97 web page:
	http://www.arl.wustl.edu/arl/NOSSDAV97/

The workshop will be held at Innsbrook Estates. Located approximately 45
minutes from the St. Louis airport, Innsbrook Estates has everything you
would like in a resort: 18-hole golf course, 18-hole miniature
course, swimming pool, a 150 acre lake, sailing, fishing,
swimming, sand beaches, fitness center, lighted tennis courts,
volleyball courts, horse back riding, full conference facilities, etc.


Send inquiries to:

	NOSSDAV97@arl.wustl.edu


	ATTN: NOSSDAV97
	Department of Computer Science/ARL
	Campus Box 1045
	Washington University
	One Brookings Drive
	St. Louis MO 63130, USA

	Tele: 1 314 935 7534
	Fax: 1 314 935 7302




From rem-conf-request@es.net Tue Apr 15 04:54:08 1997 
Received: from viviane.dassault-elec.fr by osi-west.es.net with ESnet SMTP (PP);
          Tue, 15 Apr 1997 01:53:59 -0700
Received: from localhost (chambet@localhost) 
          by viviane.dassault-elec.fr (8.8.5/SMI-SVR4) with SMTP id KAA12277 
          for <rem-conf@es.net>; Tue, 15 Apr 1997 10:53:36 +0200 (MET DST)
Date: Tue, 15 Apr 1997 10:53:35 +0200 (MET DST)
From: Beatrice Chambet <Beatrice.Chambet@dassault-elec.fr>
To: REMCONF <rem-conf@es.net>
Subject: H323
Message-ID: <Pine.SOL.3.95.970415105107.12265A-100000@viviane.dassault-elec.fr>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


Hello,

Where can i find the T120 recommandations ? I'm interested by the
signalization protocol.  

Thanks,


From rem-conf-request@tmpmail.es.net Tue Apr 15 05:07:58 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Tue, 15 Apr 1997 02:07:47 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wH40A-0003TP-00; Tue, 15 Apr 1997 01:54:10 -0700
Date: Tue, 15 Apr 1997 10:53:35 +0200 (MET DST)
From: Beatrice Chambet <Beatrice.Chambet@dassault-elec.fr>
To: REMCONF <rem-conf@es.net>
Subject: H323
Message-ID: <Pine.SOL.3.95.970415105107.12265A-100000@viviane.dassault-elec.fr>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-ID: <"oCp3H.0.gG3.o8qKp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Tue, 15 Apr 1997 01:54:10 -0700


Hello,

Where can i find the T120 recommandations ? I'm interested by the
signalization protocol.  

Thanks,



From rem-conf-request@es.net Tue Apr 15 05:32:49 1997 
Received: from eagle.rvs.uni-hannover.de by osi-west.es.net 
          with ESnet SMTP (PP); Tue, 15 Apr 1997 02:32:39 -0700
Received: from kauai(really [130.75.5.162]) by eagle.rvs.uni-hannover.de 
          via sendmail with smtp 
          id <m0wH4au-0004nVC@eagle.rvs.uni-hannover.de> for <rem-conf@es.net>;
          Tue, 15 Apr 1997 11:32:08 +0200 (METDST) (Smail-3.2.0.92 1997-Feb-9 #3 built 1997-Apr-4)
Date: Tue, 15 Apr 1997 11:32:07 +0200 (MET DST)
From: "Lutz Grueneberg, RVS" <gruen@rvs.uni-hannover.de>
X-Sender: gruen@kauai
To: Beatrice Chambet <Beatrice.Chambet@dassault-elec.fr>
cc: REMCONF <rem-conf@es.net>, rem-conf@tmpmail.es.net, 
    rem-conf-dist@tmpmail.es.net
Subject: Re: H323
In-Reply-To: <Pine.SOL.3.95.970415105107.12265A-100000@viviane.dassault-elec.fr>
Message-ID: <Pine.GSO.3.95.970415112500.521E-100000@kauai>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hi,

On Tue, 15 Apr 1997, Beatrice Chambet wrote:

>=20
> Hello,
>=20
> Where can i find the T120 recommandations ? I'm interested by the
> signalization protocol. =20
>=20
> Thanks,
>=20

The OFFICIAL source is http://www.itu.ch/
But i didn't found H.323 in the Online-Shop. T.120
seems to be available. The ITU CD-ROM at our local
university library, updated in Jan 97, did not contain
T.120 and H.323.

Cheers,
 Lutz
--
// Lutz Gr=FCneberg                Lehrgebiet Rechnernetze und Verteilte Sy=
steme
//                               Universit=E4t Hannover
//                               Schlo=DFwender Str. 5
// gruen@rvs.uni-hannover.de     D-30159 Hannover, Germany
// Public PGP-Key available: http://www.rvs.uni-hannover.de/people/gruen.ht=
ml
//                           http://bs.mit.edu:8001/pks-toplev.html


From rem-conf-request@tmpmail.es.net Tue Apr 15 05:41:45 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Tue, 15 Apr 1997 02:41:40 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wH4bc-00040q-00; Tue, 15 Apr 1997 02:32:52 -0700
Date: Tue, 15 Apr 1997 11:32:07 +0200 (MET DST)
From: "Lutz Grueneberg, RVS" <gruen@rvs.uni-hannover.de>
X-Sender: gruen@kauai
To: Beatrice Chambet <Beatrice.Chambet@dassault-elec.fr>
cc: REMCONF <rem-conf@es.net>, rem-conf@tmpmail.es.net, 
    rem-conf-dist@tmpmail.es.net
Subject: Re: H323
In-Reply-To: <Pine.SOL.3.95.970415105107.12265A-100000@viviane.dassault-elec.fr>
Message-ID: <Pine.GSO.3.95.970415112500.521E-100000@kauai>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Resent-Message-ID: <"qau2g.0.3n3.4jqKp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Tue, 15 Apr 1997 02:32:52 -0700

Hi,

On Tue, 15 Apr 1997, Beatrice Chambet wrote:

>=20
> Hello,
>=20
> Where can i find the T120 recommandations ? I'm interested by the
> signalization protocol. =20
>=20
> Thanks,
>=20

The OFFICIAL source is http://www.itu.ch/
But i didn't found H.323 in the Online-Shop. T.120
seems to be available. The ITU CD-ROM at our local
university library, updated in Jan 97, did not contain
T.120 and H.323.

Cheers,
 Lutz
--
// Lutz Gr=FCneberg                Lehrgebiet Rechnernetze und Verteilte Sy=
steme
//                               Universit=E4t Hannover
//                               Schlo=DFwender Str. 5
// gruen@rvs.uni-hannover.de     D-30159 Hannover, Germany
// Public PGP-Key available: http://www.rvs.uni-hannover.de/people/gruen.ht=
ml
//                           http://bs.mit.edu:8001/pks-toplev.html



From rem-conf-request@es.net Tue Apr 15 05:46:56 1997 
Received: from alpes.eurecom.fr by osi-west.es.net with ESnet SMTP (PP);
          Tue, 15 Apr 1997 02:46:46 -0700
Received: from zanzibar.eurecom.fr (zanzibar.eurecom.fr [193.55.114.70]) 
          by alpes.eurecom.fr (8.7.4/8.7.3) with ESMTP id LAA28265;
          Tue, 15 Apr 1997 11:48:33 +0200 (MET DST)
Received: from zanzibar (localhost [127.0.0.1]) 
          by zanzibar.eurecom.fr (8.8.4/8.8.4) with SMTP id LAA24053;
          Tue, 15 Apr 1997 11:46:33 +0200 (MET DST)
Sender: hummes@eurecom.fr
Message-ID: <33534E78.1D5C@eurecom.fr>
Date: Tue, 15 Apr 1997 11:46:32 +0200
From: Jakob Hummes <hummes@eurecom.fr>
Organization: Eurecom
X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.5 sun4m)
MIME-Version: 1.0
To: Beatrice Chambet <Beatrice.Chambet@dassault-elec.fr>
CC: REMCONF <rem-conf@es.net>
Subject: Re: H323
References: <Pine.SOL.3.95.970415105107.12265A-100000@viviane.dassault-elec.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Beatrice Chambet wrote:
> 
> Hello,
> 
> Where can i find the T120 recommandations ? I'm interested by the
> signalization protocol.
> 
> Thanks,

You'll find a pointer to T120 and other stuff on my groupware page:
http://www.eurecom.fr/~hummes/groupware.html

Disclaimer: I haven't checked this oage for several months of
consistency; probably some links will point into Nirvana.  I hope to
reorganize that page soon...

Cheers,
- Jakob
-- 
WORK:                          
Jakob Hummes                   
EURECOM                        
2229, route des Cretes         
B.P. 193                       
06904 Sophia Antipolis Cedex
FRANCE
Tel: (+33) (0)4 93 00 26 70     WWW: http://www.eurecom.fr/~hummes
Fax: (+33) (0)4 93 00 26 27

From rem-conf-request@es.net Tue Apr 15 05:51:03 1997 
Received: from hermes.research.kpn.com by osi-west.es.net with ESnet SMTP (PP);
          Tue, 15 Apr 1997 02:50:46 -0700
Return-receipt-to: P.B.J.OudeVrielink@research.kpn.com
Received: from ntl11.research.kpn.com by research.kpn.com (PMDF V5.1-8 #18053) 
          with SMTP id <01IHQEWT5O0Y007YU9@research.kpn.com> 
          for rem-conf@es.net; Tue, 15 Apr 1997 11:50:38 +0200
Received: by ntl11.research.kpn.com 
          with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) 
          id <01BC4993.59AA1470@ntl11.research.kpn.com>;
          Tue, 15 Apr 1997 11:51:27 +0100
Date: Tue, 15 Apr 1997 11:51:13 +0100
From: "Oude Vrielink, P.B.J." <P.B.J.OudeVrielink@research.kpn.com>
Subject: RE: H323
To: "'rem-conf-dist@tmpmail.es.net'" <rem-conf-dist@tmpmail.es.net>, 
    "'Lutz Grueneberg, RVS'" <gruen@rvs.uni-hannover.de>
Cc: 'REMCONF' <rem-conf@es.net>, 
    "'rem-conf@tmpmail.es.net'" <rem-conf@tmpmail.es.net>, 
    "'rem-conf-dist@tmpmail.es.net'" <rem-conf-dist@tmpmail.es.net>
Message-id: <l=NTG3-970415105113Z-11216@ntl11.research.kpn.com>
MIME-version: 1.0
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit

>
>The OFFICIAL source is http://www.itu.ch/
>But i didn't found H.323 in the Online-Shop. T.120
>seems to be available. The ITU CD-ROM at our local
>university library, updated in Jan 97, did not contain
>T.120 and H.323.

Another source, containing all T.120 standards, is:
ftp://ftp.imtc-files.org/imtc-site/

Cheers, Paul
>
>Paul Oude Vrielink
>KPN Research Groningen
>Postbus 15000
>9700 CD Groningen
>The Netherlands
>email: p.b.j.oudevrielink@research.kpn.com
>tel: +31 50 5821109
>fax: +31 50 3122415
>

From rem-conf-request@tmpmail.es.net Tue Apr 15 05:55:12 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Tue, 15 Apr 1997 02:55:09 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wH4pH-0004ZS-00; Tue, 15 Apr 1997 02:46:59 -0700
Sender: hummes@eurecom.fr
Message-ID: <33534E78.1D5C@eurecom.fr>
Date: Tue, 15 Apr 1997 11:46:32 +0200
From: Jakob Hummes <hummes@eurecom.fr>
Organization: Eurecom
X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.5 sun4m)
MIME-Version: 1.0
To: Beatrice Chambet <Beatrice.Chambet@dassault-elec.fr>
CC: REMCONF <rem-conf@es.net>
Subject: Re: H323
References: <Pine.SOL.3.95.970415105107.12265A-100000@viviane.dassault-elec.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"PhzH52.0.bI4.JwqKp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Tue, 15 Apr 1997 02:46:59 -0700

Beatrice Chambet wrote:
> 
> Hello,
> 
> Where can i find the T120 recommandations ? I'm interested by the
> signalization protocol.
> 
> Thanks,

You'll find a pointer to T120 and other stuff on my groupware page:
http://www.eurecom.fr/~hummes/groupware.html

Disclaimer: I haven't checked this oage for several months of
consistency; probably some links will point into Nirvana.  I hope to
reorganize that page soon...

Cheers,
- Jakob
-- 
WORK:                          
Jakob Hummes                   
EURECOM                        
2229, route des Cretes         
B.P. 193                       
06904 Sophia Antipolis Cedex
FRANCE
Tel: (+33) (0)4 93 00 26 70     WWW: http://www.eurecom.fr/~hummes
Fax: (+33) (0)4 93 00 26 27


From rem-conf-request@tmpmail.es.net Tue Apr 15 05:56:14 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Tue, 15 Apr 1997 02:56:11 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wH4t9-0004gR-00; Tue, 15 Apr 1997 02:50:59 -0700
Date: Tue, 15 Apr 1997 11:51:13 +0100
From: "Oude Vrielink, P.B.J." <P.B.J.OudeVrielink@research.kpn.com>
Subject: RE: H323
To: "'rem-conf-dist@tmpmail.es.net'" <rem-conf-dist@tmpmail.es.net>, 
    "'Lutz Grueneberg, RVS'" <gruen@rvs.uni-hannover.de>
Cc: 'REMCONF' <rem-conf@es.net>, 
    "'rem-conf@tmpmail.es.net'" <rem-conf@tmpmail.es.net>, 
    "'rem-conf-dist@tmpmail.es.net'" <rem-conf-dist@tmpmail.es.net>
Message-id: <l=NTG3-970415105113Z-11216@ntl11.research.kpn.com>
MIME-version: 1.0
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Resent-Message-ID: <"Dyw3A2.0.MP4.3-qKp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Tue, 15 Apr 1997 02:50:59 -0700

>
>The OFFICIAL source is http://www.itu.ch/
>But i didn't found H.323 in the Online-Shop. T.120
>seems to be available. The ITU CD-ROM at our local
>university library, updated in Jan 97, did not contain
>T.120 and H.323.

Another source, containing all T.120 standards, is:
ftp://ftp.imtc-files.org/imtc-site/

Cheers, Paul
>
>Paul Oude Vrielink
>KPN Research Groningen
>Postbus 15000
>9700 CD Groningen
>The Netherlands
>email: p.b.j.oudevrielink@research.kpn.com
>tel: +31 50 5821109
>fax: +31 50 3122415
>


From rem-conf-request@es.net Tue Apr 15 16:56:18 1997 
Received: from msri.org by osi-west.es.net with ESnet SMTP (PP);
          Tue, 15 Apr 1997 13:56:09 -0700
Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id NAA04001 
          for <rem-conf@es.net>; Tue, 15 Apr 1997 13:56:08 -0700 (PDT)
X-Authentication-Warning: msri.org: smap set sender to <nobody@msri.org> using 
                          -f
Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) 
          id sma003991; Tue Apr 15 13:55:39 1997
Received: by hille.msri.org (8.7/MSRI) id NAA01970;
          Tue, 15 Apr 1997 13:55:38 -0700 (PDT)
Date: Tue, 15 Apr 1997 13:55:38 -0700 (PDT)
Message-Id: <199704152055.NAA01970@hille.msri.org>
To: rem-conf@es.net
From: m1 <m1@msri.org>
Reply-to: m1@msri.org
Subject: Persi Diaconis "Group Theoretic Generalizations of the records to 
         cycles bijection"

	MBone Broadcast Announcement
	----------------------------

Title:       
	Persi Diaconis "Group Theoretic Generalizations of the records to cycles bijection"
Date:        
	Apr 22, 1997

Time:        
	12:00 PST8PDT 1 hours

Contact:     
	m1@msri.org

URL:         
	http://www.msri.org/lecturenotes/97/diaconis/

Description:        
	Persi Diaconis's talk in the Representation Theory  and Symmetric Functions workshop. No abstract nor  slides available. 









mbone broadcast schedule http://www.msri.org/mbone

From rem-conf-request@es.net Tue Apr 15 16:57:41 1997 
Received: from msri.org by osi-west.es.net with ESnet SMTP (PP);
          Tue, 15 Apr 1997 13:57:10 -0700
Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id NAA04046 
          for <rem-conf@es.net>; Tue, 15 Apr 1997 13:57:09 -0700 (PDT)
X-Authentication-Warning: msri.org: smap set sender to <nobody@msri.org> using 
                          -f
Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) 
          id sma004036; Tue Apr 15 13:57:05 1997
Received: by hille.msri.org (8.7/MSRI) id NAA02004;
          Tue, 15 Apr 1997 13:57:05 -0700 (PDT)
Date: Tue, 15 Apr 1997 13:57:05 -0700 (PDT)
Message-Id: <199704152057.NAA02004@hille.msri.org>
To: rem-conf@es.net
From: m1 <m1@msri.org>
Reply-to: m1@msri.org
Subject: Andrei Zelevinsky "Littlewood-Richardson semigroups"

	MBone Broadcast Announcement
	----------------------------

Title:       
	Andrei Zelevinsky "Littlewood-Richardson semigroups"
Date:        
	Apr 23, 1997

Time:        
	12:00 PST8PDT 1 hours

Contact:     
	m1@msri.org

URL:         
	http://www.msri.org/lecturenotes/97/zelevinsky/

Description:        
	Andrei Zelevinsky's talk in the Representation Theory  and Symmetric Functions workshop. No abstract nor  slides available. 









mbone broadcast schedule http://www.msri.org/mbone

From rem-conf-request@es.net Tue Apr 15 16:59:15 1997 
Received: from msri.org by osi-west.es.net with ESnet SMTP (PP);
          Tue, 15 Apr 1997 13:59:10 -0700
Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id NAA04175 
          for <rem-conf@es.net>; Tue, 15 Apr 1997 13:59:09 -0700 (PDT)
X-Authentication-Warning: msri.org: smap set sender to <nobody@msri.org> using 
                          -f
Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) 
          id sma004116; Tue Apr 15 13:58:21 1997
Received: by hille.msri.org (8.7/MSRI) id NAA02076;
          Tue, 15 Apr 1997 13:58:21 -0700 (PDT)
Date: Tue, 15 Apr 1997 13:58:21 -0700 (PDT)
Message-Id: <199704152058.NAA02076@hille.msri.org>
To: rem-conf@es.net
From: m1 <m1@msri.org>
Reply-to: m1@msri.org
Subject: Ian Macdonald "G. Wilson's Formula for the Schur function"

	MBone Broadcast Announcement
	----------------------------

Title:       
	Ian Macdonald "G. Wilson's Formula for the Schur function"
Date:        
	Apr 24, 1997

Time:        
	12:00 PST8PDT 1 hours

Contact:     
	m1@msri.org

URL:         
	http://www.msri.org/lecturenotes/97/macdonald/

Description:        
	Ian Macdonald's talk in the Representation Theory  and Symmetric Functions workshop. No abstract nor  slides available.









mbone broadcast schedule http://www.msri.org/mbone

From rem-conf-request@es.net Tue Apr 15 17:03:44 1997 
Received: from cbgw1.lucent.com by osi-west.es.net with ESnet SMTP (PP);
          Tue, 15 Apr 1997 14:03:30 -0700
Received: from hoserve.ho.lucent.com 
          by cbig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id QAA16364;
          Tue, 15 Apr 1997 16:55:31 -0400
Received: by hoserve.ho.lucent.com (4.1/EMS-L SunOS) id AA29288;
          Tue, 15 Apr 97 16:38:12 EDT
From: sohraby@lucent.com
Received: from qc54.ho.lucent.com by hoserve.ho.lucent.com (4.1/EMS-L SunOS) 
          id AA29171; Tue, 15 Apr 97 16:36:35 EDT
Received: by qc54.ho.lucent.com (4.1/EMS-L sol2) id AA18680;
          Tue, 15 Apr 97 16:39:37 EDT
Date: Tue, 15 Apr 97 16:39:37 EDT
Original-From: kas1@hoserve.ho.lucent.com
Message-Id: <9704152039.AA18680@qc54.ho.lucent.com>
To: rem-conf@es.net
Subject: REMINDER: ACM/IEEE MOBICOM 97 CONFERENCE DEADLINE FOR PAPER SUBMISION 
         IS APRIL 21, 1997

       ========================= REMINDER =====================
       ========================= REMINDER =====================

                      Announcement and Call for Papers

                 THIRD ACM/IEEE INTERNATIONAL CONFERENCE ON
              MOBILE COMPUTING AND NETWORKING 1997 (MobiCom'97)

    Sponsored by ACM SIGMOBILE and SIGCOMM, IEEE Communications Society,
                   and the Hungarian Academy of Sciences

                           September 26-30, 1997
                             Budapest, Hungary


 The wireless communication revolution is bringing fundamental changes
 to telecommunication and computing.  Wide-area cellular systems and
 wireless LANs promise to make integrated networks a reality and provide
 fully distributed and ubiquitous mobile computing and communications,
 thus bringing an end to the tyranny of geography.  Furthermore, services
 for the mobile user are maturing and are poised to change the nature and
 scope of communication.  This conference, the third of an annual series,
 serves as the premier international forum addressing networks, systems,
 algorithms, and applications that support the symbiosis of mobile
 computers and wireless networks.

 PAPERS:

 Technical papers describing previously unpublished, original, completed
 research, not currently under review by another conference or journal,
 are solicited on topics at the link layer and above.  Possible topics
 include, but are not limited to:

    * Applications and computing services supporting mobile users
    * Network architectures, protocols or service algorithms to cope with
      mobility, limited bandwidth, or intermittent connectivity
    * Design and analysis of algorithms for mobile environments
    * Security, scalability and reliability for mobile/wireless systems
    * Performance of mobile/wireless networks and systems
    * Network management for mobile and wireless networks
    * Data management in mobile computing
    * Integration and interworking of wired and wireless networks
    * Influence of lower layers on the design and performance of
      higher layers
    * Mobile network protocols
    * Mobile computing
    * Mobile agents
    * Power management
    * Wireless multimedia systems
    * Satellite communication
    * Location-dependent applications
    * Distributed system aspects of mobile systems
    * Adaptive applications interfaces for mobile systems
    * Architectures of mobile/wireless networks and systems
    * Traffic integration for mobile applications

 All papers will be refereed by the program committee.  Accepted papers
 will be published in the conference proceedings.  Papers of particular
 merit will be selected for publication in the ACM/Baltzer journals
 Wireless Networks (WINET) and Mobile Networks and Applications (MONET).

 HOW TO SUBMIT:

 All paper submission will be handled electronically.  Authors
 should E-mail a PostScript version of their full paper to
 mobicom97@monarch.cs.cmu.edu.  This E-mail address will become
 operational on March 1, 1997.  In order to ensure that the PostScript
 versions of the papers can be printed, authors should be careful that
 their papers meet the following restrictions:

    * PostScript version 2 or later.
    * No longer than 15 pages.
    * Fits properly on "US Letter" size paper (8.5x11 inches).
    * Reference only Computer Modern or standard Adobe printer fonts
      (i.e., Courier, Times Roman, or Helvetica); other fonts may be
      used but must be included in the PostScript file.

 In addition, authors should separately E-mail the title, author
 names and full address, and abstract of their paper to the Program
 Chairs, David Johnson (dbj@cs.cmu.edu) and Christopher Rose
 (crose@ece.rutgers.edu).  All submitted papers will be judged based
 on their quality through double-blind reviewing, where the identities
 of the authors are withheld from the reviewers.  Authors' names should
 not appear on the paper or in the PostScript file.

 TUTORIALS:

 Proposals for tutorials are solicited.  Evaluation of proposals will
 be based on the expertise and experience of the instructors, and on the
 relevance of the subject matter.  Potential instructors are requested to
 submit a tutorial proposal of at most 5 pages, including a biographical
 sketch, to the Tutorial Chair, Wassim Matragi (wassim@lucent.com).

 PANELS:

 Panels are solicited that examine innovative, controversial, or
 otherwise provocative issues of interest.  Panel proposals should not
 exceed 3 pages, including biographical sketches of the panelists.
 Potential panel organizers should contact the Publicity Chair,
 Sirin Tekinay (stekinay@lucent.com).

 STUDENT PARTICIPATION:

 Papers with a student as a primary author will be considered for
 a cash award of $500 US Dollars for the best student paper.
 A cover letter must identify the paper as a candidate for the
 student paper competition.

 IMPORTANT DATES:

 Submissions due:                      April 21, 1997
 Notification of acceptance:           June 30, 1997
 Camera-ready version due:             August 15, 1997

 FOR MORE INFORMATION:

 Please contact either of the Program Co-Chairs: David Johnson,
 dbj@cs.cmu.edu, Tel: +1 412 268 7399, Fax: +1 412 268 5576; or
 Christopher Rose, crose@ece.rutgers.edu, Tel: +1 908 445 5250,
 Fax: +1 908 445 2820.

 This Call For Papers, as well as other MobiCom'97 information, is
 available on the Web at http://www.monarch.cs.cmu.edu/~mobicom97/ and
 on the ACM SIGMOBILE Home Page at http://www.acm.org/sigmobile/.

 CONFERENCE COMMITTEE:

 General Co-Chairs:                    Program Co-Chairs:

   Laszlo Pap                            David B. Johnson
   Technical Univ. of Budapest (HU)      Carnegie Mellon University (US)
   Department of Telecommunications      Computer Science Department
   pap@tsys.hit.bme.hu                   dbj@cs.cmu.edu

   Kazem Sohraby                         Christopher Rose
   Bell Laboratories (US)                Rutgers University (US)
   Lucent Technologies                   Department of ECE / WINLAB
   sohraby@lucent.com                    crose@ece.rutgers.edu

 General Vice Chair:                   Program Vice Chair:

   Parviz Kermani                        Maurizio Bonuccelli
   IBM T.J. Watson (US)                  University of Pisa (IT)
   kermani@watson.ibm.com                bonucce@di.unipi.it

 Tutorial Chair:                       Publicity Chair:

   Wassim Matragi                        Sirin Tekinay
   Lucent Technologies (US)              Lucent Technologies (US)
   wassim@lucent.com                     stekinay@lucent.com

 Local Chair:                          Treasurer:

   Andras Pataricza                      Svetislav Maric
   Technical Univ. of Budapest (HU)      University of Cambridge (UK)
   pataric@mmt.bme.hu                    svm@eng.cam.ac.uk

 Local Vice Chair:                     Steering Committee Chair:

   Gyorgy Pongor                         Imrich Chlamtac
   Technical Univ. of Budapest (HU)      Boston University (US)
   pongor@hit.bme.hu                     chlamtac@bcn.bu.edu

 Program Committee:

   Prathima Agrawal, AT&T Labs (US)      Zygmunt Haas, Cornell (US)
   Ian Akyildiz, Georgia Tech. (US)      Joachim Hagenauer, T.U. Munich (DE)
   Rafael Alonso, Sarnoff (US)           Pierre Humblet, Eurecom (FR)
   B.R. Badrinath, Rutgers (US)          Ravi Jain, Bellcore (US)
   Victor Bahl, DEC (US)                 Jay Kistler, DEC SRC (US)
   Mary Baker, Stanford (US)             Jason Yi-Bing Lin, NCTU (TW)
   Amotz Bar-Noy, Tel Aviv Univ. (IL)    Charles Perkins, IBM Watson (US)
   Ramon Caceres, AT&T Labs (US)         Ray Pickholtz, GWU (US)
   Ray Chaudhuri, NEC (US)               Stephen Pink, SICS (SE)
   Imrich Chlamtac, Boston Univ. (US)    Krishan Sabnani, Bell Labs (US)
   Gyula Csopaki, T.U. Budapest (HU)     Srinivasan Seshan, IBM Watson (US)
   Nigel Davies, Univ. Lancaster (UK)    Martha Steenstrup, BBN (US)
   Maurizio Decina, CEFRIEL (IT)         Marvin Theimer, Xerox PARC (US)
   J.J. Garcia-Luna, UCSC (US)           Roy Yates, Rutgers (US)
   Laszlo Gyorfi, T.U. Budapest (HU)     On-Ching Yue, Bell Labs (US)

---------------------------------------------------------------------------



From rem-conf-request@tmpmail.es.net Tue Apr 15 17:11:09 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Tue, 15 Apr 1997 14:11:05 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wHFI8-0001jW-00; Tue, 15 Apr 1997 13:57:28 -0700
X-Authentication-Warning: msri.org: smap set sender to <nobody@msri.org> using 
                          -f
Date: Tue, 15 Apr 1997 13:57:05 -0700 (PDT)
Message-Id: <199704152057.NAA02004@hille.msri.org>
To: rem-conf@es.net
From: m1 <m1@msri.org>
Reply-to: m1@msri.org
Subject: Andrei Zelevinsky "Littlewood-Richardson semigroups"
Resent-Message-ID: <"6iWY02.0.9e1.uk-Kp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Tue, 15 Apr 1997 13:57:28 -0700

	MBone Broadcast Announcement
	----------------------------

Title:       
	Andrei Zelevinsky "Littlewood-Richardson semigroups"
Date:        
	Apr 23, 1997

Time:        
	12:00 PST8PDT 1 hours

Contact:     
	m1@msri.org

URL:         
	http://www.msri.org/lecturenotes/97/zelevinsky/

Description:        
	Andrei Zelevinsky's talk in the Representation Theory  and Symmetric Functions workshop. No abstract nor  slides available. 









mbone broadcast schedule http://www.msri.org/mbone


From rem-conf-request@tmpmail.es.net Tue Apr 15 17:11:56 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Tue, 15 Apr 1997 14:11:44 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wHFJs-0001kD-00; Tue, 15 Apr 1997 13:59:16 -0700
X-Authentication-Warning: msri.org: smap set sender to <nobody@msri.org> using 
                          -f
Date: Tue, 15 Apr 1997 13:58:21 -0700 (PDT)
Message-Id: <199704152058.NAA02076@hille.msri.org>
To: rem-conf@es.net
From: m1 <m1@msri.org>
Reply-to: m1@msri.org
Subject: Ian Macdonald "G. Wilson's Formula for the Schur function"
Resent-Message-ID: <"9OPLK.0.qe1.am-Kp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Tue, 15 Apr 1997 13:59:16 -0700

	MBone Broadcast Announcement
	----------------------------

Title:       
	Ian Macdonald "G. Wilson's Formula for the Schur function"
Date:        
	Apr 24, 1997

Time:        
	12:00 PST8PDT 1 hours

Contact:     
	m1@msri.org

URL:         
	http://www.msri.org/lecturenotes/97/macdonald/

Description:        
	Ian Macdonald's talk in the Representation Theory  and Symmetric Functions workshop. No abstract nor  slides available.









mbone broadcast schedule http://www.msri.org/mbone


From rem-conf-request@tmpmail.es.net Tue Apr 15 17:12:15 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Tue, 15 Apr 1997 14:11:45 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wHFH2-0001iv-00; Tue, 15 Apr 1997 13:56:20 -0700
X-Authentication-Warning: msri.org: smap set sender to <nobody@msri.org> using 
                          -f
Date: Tue, 15 Apr 1997 13:55:38 -0700 (PDT)
Message-Id: <199704152055.NAA01970@hille.msri.org>
To: rem-conf@es.net
From: m1 <m1@msri.org>
Reply-to: m1@msri.org
Subject: Persi Diaconis "Group Theoretic Generalizations of the records to 
         cycles bijection"
Resent-Message-ID: <"4ZRui1.0.ad1.qj-Kp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Tue, 15 Apr 1997 13:56:20 -0700

	MBone Broadcast Announcement
	----------------------------

Title:       
	Persi Diaconis "Group Theoretic Generalizations of the records to cycles bijection"
Date:        
	Apr 22, 1997

Time:        
	12:00 PST8PDT 1 hours

Contact:     
	m1@msri.org

URL:         
	http://www.msri.org/lecturenotes/97/diaconis/

Description:        
	Persi Diaconis's talk in the Representation Theory  and Symmetric Functions workshop. No abstract nor  slides available. 









mbone broadcast schedule http://www.msri.org/mbone


From rem-conf-request@tmpmail.es.net Tue Apr 15 17:15:59 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Tue, 15 Apr 1997 14:15:48 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wHFOD-0001xc-00; Tue, 15 Apr 1997 14:03:45 -0700
From: sohraby@lucent.com
Date: Tue, 15 Apr 97 16:39:37 EDT
Original-From: kas1@hoserve.ho.lucent.com
Message-Id: <9704152039.AA18680@qc54.ho.lucent.com>
To: rem-conf@es.net
Subject: REMINDER: ACM/IEEE MOBICOM 97 CONFERENCE DEADLINE FOR PAPER SUBMISION 
         IS APRIL 21, 1997
Resent-Message-ID: <"WG3uk2.0.pr1.nq-Kp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Tue, 15 Apr 1997 14:03:45 -0700

       ========================= REMINDER =====================
       ========================= REMINDER =====================

                      Announcement and Call for Papers

                 THIRD ACM/IEEE INTERNATIONAL CONFERENCE ON
              MOBILE COMPUTING AND NETWORKING 1997 (MobiCom'97)

    Sponsored by ACM SIGMOBILE and SIGCOMM, IEEE Communications Society,
                   and the Hungarian Academy of Sciences

                           September 26-30, 1997
                             Budapest, Hungary


 The wireless communication revolution is bringing fundamental changes
 to telecommunication and computing.  Wide-area cellular systems and
 wireless LANs promise to make integrated networks a reality and provide
 fully distributed and ubiquitous mobile computing and communications,
 thus bringing an end to the tyranny of geography.  Furthermore, services
 for the mobile user are maturing and are poised to change the nature and
 scope of communication.  This conference, the third of an annual series,
 serves as the premier international forum addressing networks, systems,
 algorithms, and applications that support the symbiosis of mobile
 computers and wireless networks.

 PAPERS:

 Technical papers describing previously unpublished, original, completed
 research, not currently under review by another conference or journal,
 are solicited on topics at the link layer and above.  Possible topics
 include, but are not limited to:

    * Applications and computing services supporting mobile users
    * Network architectures, protocols or service algorithms to cope with
      mobility, limited bandwidth, or intermittent connectivity
    * Design and analysis of algorithms for mobile environments
    * Security, scalability and reliability for mobile/wireless systems
    * Performance of mobile/wireless networks and systems
    * Network management for mobile and wireless networks
    * Data management in mobile computing
    * Integration and interworking of wired and wireless networks
    * Influence of lower layers on the design and performance of
      higher layers
    * Mobile network protocols
    * Mobile computing
    * Mobile agents
    * Power management
    * Wireless multimedia systems
    * Satellite communication
    * Location-dependent applications
    * Distributed system aspects of mobile systems
    * Adaptive applications interfaces for mobile systems
    * Architectures of mobile/wireless networks and systems
    * Traffic integration for mobile applications

 All papers will be refereed by the program committee.  Accepted papers
 will be published in the conference proceedings.  Papers of particular
 merit will be selected for publication in the ACM/Baltzer journals
 Wireless Networks (WINET) and Mobile Networks and Applications (MONET).

 HOW TO SUBMIT:

 All paper submission will be handled electronically.  Authors
 should E-mail a PostScript version of their full paper to
 mobicom97@monarch.cs.cmu.edu.  This E-mail address will become
 operational on March 1, 1997.  In order to ensure that the PostScript
 versions of the papers can be printed, authors should be careful that
 their papers meet the following restrictions:

    * PostScript version 2 or later.
    * No longer than 15 pages.
    * Fits properly on "US Letter" size paper (8.5x11 inches).
    * Reference only Computer Modern or standard Adobe printer fonts
      (i.e., Courier, Times Roman, or Helvetica); other fonts may be
      used but must be included in the PostScript file.

 In addition, authors should separately E-mail the title, author
 names and full address, and abstract of their paper to the Program
 Chairs, David Johnson (dbj@cs.cmu.edu) and Christopher Rose
 (crose@ece.rutgers.edu).  All submitted papers will be judged based
 on their quality through double-blind reviewing, where the identities
 of the authors are withheld from the reviewers.  Authors' names should
 not appear on the paper or in the PostScript file.

 TUTORIALS:

 Proposals for tutorials are solicited.  Evaluation of proposals will
 be based on the expertise and experience of the instructors, and on the
 relevance of the subject matter.  Potential instructors are requested to
 submit a tutorial proposal of at most 5 pages, including a biographical
 sketch, to the Tutorial Chair, Wassim Matragi (wassim@lucent.com).

 PANELS:

 Panels are solicited that examine innovative, controversial, or
 otherwise provocative issues of interest.  Panel proposals should not
 exceed 3 pages, including biographical sketches of the panelists.
 Potential panel organizers should contact the Publicity Chair,
 Sirin Tekinay (stekinay@lucent.com).

 STUDENT PARTICIPATION:

 Papers with a student as a primary author will be considered for
 a cash award of $500 US Dollars for the best student paper.
 A cover letter must identify the paper as a candidate for the
 student paper competition.

 IMPORTANT DATES:

 Submissions due:                      April 21, 1997
 Notification of acceptance:           June 30, 1997
 Camera-ready version due:             August 15, 1997

 FOR MORE INFORMATION:

 Please contact either of the Program Co-Chairs: David Johnson,
 dbj@cs.cmu.edu, Tel: +1 412 268 7399, Fax: +1 412 268 5576; or
 Christopher Rose, crose@ece.rutgers.edu, Tel: +1 908 445 5250,
 Fax: +1 908 445 2820.

 This Call For Papers, as well as other MobiCom'97 information, is
 available on the Web at http://www.monarch.cs.cmu.edu/~mobicom97/ and
 on the ACM SIGMOBILE Home Page at http://www.acm.org/sigmobile/.

 CONFERENCE COMMITTEE:

 General Co-Chairs:                    Program Co-Chairs:

   Laszlo Pap                            David B. Johnson
   Technical Univ. of Budapest (HU)      Carnegie Mellon University (US)
   Department of Telecommunications      Computer Science Department
   pap@tsys.hit.bme.hu                   dbj@cs.cmu.edu

   Kazem Sohraby                         Christopher Rose
   Bell Laboratories (US)                Rutgers University (US)
   Lucent Technologies                   Department of ECE / WINLAB
   sohraby@lucent.com                    crose@ece.rutgers.edu

 General Vice Chair:                   Program Vice Chair:

   Parviz Kermani                        Maurizio Bonuccelli
   IBM T.J. Watson (US)                  University of Pisa (IT)
   kermani@watson.ibm.com                bonucce@di.unipi.it

 Tutorial Chair:                       Publicity Chair:

   Wassim Matragi                        Sirin Tekinay
   Lucent Technologies (US)              Lucent Technologies (US)
   wassim@lucent.com                     stekinay@lucent.com

 Local Chair:                          Treasurer:

   Andras Pataricza                      Svetislav Maric
   Technical Univ. of Budapest (HU)      University of Cambridge (UK)
   pataric@mmt.bme.hu                    svm@eng.cam.ac.uk

 Local Vice Chair:                     Steering Committee Chair:

   Gyorgy Pongor                         Imrich Chlamtac
   Technical Univ. of Budapest (HU)      Boston University (US)
   pongor@hit.bme.hu                     chlamtac@bcn.bu.edu

 Program Committee:

   Prathima Agrawal, AT&T Labs (US)      Zygmunt Haas, Cornell (US)
   Ian Akyildiz, Georgia Tech. (US)      Joachim Hagenauer, T.U. Munich (DE)
   Rafael Alonso, Sarnoff (US)           Pierre Humblet, Eurecom (FR)
   B.R. Badrinath, Rutgers (US)          Ravi Jain, Bellcore (US)
   Victor Bahl, DEC (US)                 Jay Kistler, DEC SRC (US)
   Mary Baker, Stanford (US)             Jason Yi-Bing Lin, NCTU (TW)
   Amotz Bar-Noy, Tel Aviv Univ. (IL)    Charles Perkins, IBM Watson (US)
   Ramon Caceres, AT&T Labs (US)         Ray Pickholtz, GWU (US)
   Ray Chaudhuri, NEC (US)               Stephen Pink, SICS (SE)
   Imrich Chlamtac, Boston Univ. (US)    Krishan Sabnani, Bell Labs (US)
   Gyula Csopaki, T.U. Budapest (HU)     Srinivasan Seshan, IBM Watson (US)
   Nigel Davies, Univ. Lancaster (UK)    Martha Steenstrup, BBN (US)
   Maurizio Decina, CEFRIEL (IT)         Marvin Theimer, Xerox PARC (US)
   J.J. Garcia-Luna, UCSC (US)           Roy Yates, Rutgers (US)
   Laszlo Gyorfi, T.U. Budapest (HU)     On-Ching Yue, Bell Labs (US)

---------------------------------------------------------------------------




From rem-conf-request@es.net Wed Apr 16 08:13:05 1997 
Received: from csc.com (actually explorer.csc.com) by osi-west.es.net 
          with ESnet SMTP (PP); Wed, 16 Apr 1997 05:12:58 -0700
Message-Id: <m0wHTa1-001B9FC@csc.com>
Comments: Authenticated sender is <ftroy@explorer.csc.com>
From: Frank Troy <ftroy@explorer.csc.com>
To: rem-conf@es.net
Date: Wed, 16 Apr 1997 08:08:34 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: sdr
Reply-to: ftroy@csc.com
Priority: normal
X-mailer: Pegasus Mail for Win32 (v2.42)

To All:

I'm running sdr on Sun Solaris 2.5.1.  When I have more than 
three users/video sessions in the vic window, vic tends to crash when 
I select any of the users in the window.  Is there some adjustments
I can make to vic so this doen't happen?

Thanks
Frank

-----------------------------------------------------------------------
Frank P. Troy                              E-mail: ftroy@csc.com
AT&T DISC Service Development               Phone: (703) 471-3694
3001 Centreville Road                      Fax:   (703) 471-1575    
Herndon, VA  20171                         Page:  (888) 808-0593

From rem-conf-request@tmpmail.es.net Wed Apr 16 08:50:18 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Wed, 16 Apr 1997 05:50:15 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wHTaB-0007ZF-00; Wed, 16 Apr 1997 05:13:03 -0700
Message-Id: <m0wHTa1-001B9FC@csc.com>
Comments: Authenticated sender is <ftroy@explorer.csc.com>
From: Frank Troy <ftroy@explorer.csc.com>
To: rem-conf@es.net
Date: Wed, 16 Apr 1997 08:08:34 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: sdr
Reply-to: ftroy@csc.com
Priority: normal
X-mailer: Pegasus Mail for Win32 (v2.42)
Resent-Message-ID: <"w52DD1.0.a67.F9CLp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Wed, 16 Apr 1997 05:13:03 -0700

To All:

I'm running sdr on Sun Solaris 2.5.1.  When I have more than 
three users/video sessions in the vic window, vic tends to crash when 
I select any of the users in the window.  Is there some adjustments
I can make to vic so this doen't happen?

Thanks
Frank

-----------------------------------------------------------------------
Frank P. Troy                              E-mail: ftroy@csc.com
AT&T DISC Service Development               Phone: (703) 471-3694
3001 Centreville Road                      Fax:   (703) 471-1575    
Herndon, VA  20171                         Page:  (888) 808-0593


From rem-conf-request@es.net Wed Apr 16 10:57:41 1997 
Received: from buttle.lcs.mit.edu by osi-west.es.net with ESnet SMTP (PP);
          Wed, 16 Apr 1997 07:57:36 -0700
Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu (SMI-8.6/SMI-SVR4) 
          id KAA07951; Wed, 16 Apr 1997 10:55:14 -0400
From: Mark Handley <mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: ftroy@csc.com
cc: rem-conf@es.net
Subject: Re: sdr
In-reply-to: Your message of "Wed, 16 Apr 1997 08:08:34 -0000." <m0wHTa1-001B9FC@csc.com>
Date: Wed, 16 Apr 1997 10:55:14 -0400
Message-ID: <7949.861202514@buttle.lcs.mit.edu>
Sender: mjh@buttle.lcs.mit.edu


>I'm running sdr on Sun Solaris 2.5.1.  When I have more than 
>three users/video sessions in the vic window, vic tends to crash when 
>I select any of the users in the window.  Is there some adjustments
>I can make to vic so this doen't happen?

Why do people always tend to blame vic problems on sdr? :-)

The problem is the small default limit on shared memory segments on
Solaris.  Add the following to /etc/system and reboot:

        set shmsys:shminfo_shmseg=20
        set shmsys:shminfo_shmmax=2097152

Mark

From rem-conf-request@es.net Wed Apr 16 10:58:37 1997 
Received: from bicudo.remav.telebrasilia.gov.br by osi-west.es.net 
          with ESnet SMTP (PP); Wed, 16 Apr 1997 07:58:30 -0700
Received: from backup.rema.telebrasilia.gov.br ([200.18.27.180]) 
          by bicudo.remav.telebrasilia.gov.br (8.8.4/8.6.12) with SMTP 
          id MAA03324 for <rem-conf@es.net>;
          Wed, 16 Apr 1997 12:02:12 -0300 (EST)
Date: Wed, 16 Apr 1997 12:02:12 -0300 (EST)
Message-Id: <199704161502.MAA03324@bicudo.remav.telebrasilia.gov.br>
X-Sender: ildeu@remav.telebrasilia.gov.br
X-Mailer: Windows Eudora Light Version 1.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: rem-conf@es.net
From: "=?iso-8859-1?Q?=22Ildeu_R._Borges_J=FAnior=22?=" 
      <ildeu@remav.telebrasilia.gov.br> 
Subject: Help on Prime View II drivers...

 

       Does somebody haves the Windows 95 drivers for the FutureTel's
PrimeView II ? 


From rem-conf-request@tmpmail.es.net Wed Apr 16 11:10:39 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Wed, 16 Apr 1997 08:10:35 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wHW9X-00014s-00; Wed, 16 Apr 1997 07:57:43 -0700
From: Mark Handley <mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: ftroy@csc.com
cc: rem-conf@es.net
Subject: Re: sdr
In-reply-to: Your message of "Wed, 16 Apr 1997 08:08:34 -0000." <m0wHTa1-001B9FC@csc.com>
Date: Wed, 16 Apr 1997 10:55:14 -0400
Message-ID: <7949.861202514@buttle.lcs.mit.edu>
Sender: mjh@buttle.lcs.mit.edu
Resent-Message-ID: <"H2rkj3.0.n01.dZELp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Wed, 16 Apr 1997 07:57:43 -0700


>I'm running sdr on Sun Solaris 2.5.1.  When I have more than 
>three users/video sessions in the vic window, vic tends to crash when 
>I select any of the users in the window.  Is there some adjustments
>I can make to vic so this doen't happen?

Why do people always tend to blame vic problems on sdr? :-)

The problem is the small default limit on shared memory segments on
Solaris.  Add the following to /etc/system and reboot:

        set shmsys:shminfo_shmseg=20
        set shmsys:shminfo_shmmax=2097152

Mark


From rem-conf-request@tmpmail.es.net Wed Apr 16 11:10:57 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Wed, 16 Apr 1997 08:10:38 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wHWAQ-00015C-00; Wed, 16 Apr 1997 07:58:38 -0700
Date: Wed, 16 Apr 1997 12:02:12 -0300 (EST)
Message-Id: <199704161502.MAA03324@bicudo.remav.telebrasilia.gov.br>
X-Sender: ildeu@remav.telebrasilia.gov.br
X-Mailer: Windows Eudora Light Version 1.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: rem-conf@es.net
From: "=?iso-8859-1?Q?=22Ildeu_R._Borges_J=FAnior=22?=" 
      <ildeu@remav.telebrasilia.gov.br> 
Subject: Help on Prime View II drivers...
Resent-Message-ID: <"u7_LK1.0.511.UaELp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Wed, 16 Apr 1997 07:58:38 -0700

 

       Does somebody haves the Windows 95 drivers for the FutureTel's
PrimeView II ? 



From rem-conf-request@es.net Wed Apr 16 12:26:13 1997 
Received: from hplms26.hpl.hp.com by osi-west.es.net with ESnet SMTP (PP);
          Wed, 16 Apr 1997 09:26:08 -0700
Received: from hplabsz.hpl.hp.com by hplms26.hpl.hp.com 
          with ESMTP (1.37.109.16/15.5+ECS 3.3+HPL1.1S) id AA172627959;
          Wed, 16 Apr 1997 09:25:59 -0700
Received: by hplabsz.hpl.hp.com (1.37.109.20/15.5+ECS 3.3+HPL1.1) 
          id AA160597956; Wed, 16 Apr 1997 09:25:56 -0700
From: deleon@hplabsz.hpl.hp.com (Laura de Leon)
Message-Id: <9704160925.ZM16057@hplabsz.hpl.hp.com>
Date: Wed, 16 Apr 1997 09:25:56 -0700
X-Mailer: Z-Mail (3.0.0 15dec93)
To: baylisa@baylisa.org, rem-conf@es.net, sage-members@usenix.org
Subject: BayLISA: Maureen Dorney on Legal Issues In System Administration
Cc: deleon@hplabsz.hpl.hp.com
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0

The BayLISA group meets monthly to discuss topics of interest to systems
and network administrators.  The meetings are free and open to the public.

BayLISA holds monthly meetings on the third Thursday of each month at
7:30 PM PST.  We meet at Cisco building J in San Jose, on Tasman Drive near
First street. See www.baylisa.org for more information.  The meetings are also
broadcast via MBONE.

Schedule
--------


April 17: Maureen Dorney on  Legal Issues In System Administration

[Schedule subject to change]

For further information on BayLISA, check out our web site:
http://www.baylisa.org/

To get further information on the meeting location, you can also ftp it from

	ftp.baylisa.org:/location

For any other information, please send email to:

	info@baylisa.org

If you have any questions, please contact me or the info alias listed above.



From rem-conf-request@tmpmail.es.net Wed Apr 16 12:37:57 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Wed, 16 Apr 1997 09:37:36 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wHXXC-0002V2-00; Wed, 16 Apr 1997 09:26:14 -0700
From: deleon@hplabsz.hpl.hp.com (Laura de Leon)
Message-Id: <9704160925.ZM16057@hplabsz.hpl.hp.com>
Date: Wed, 16 Apr 1997 09:25:56 -0700
X-Mailer: Z-Mail (3.0.0 15dec93)
To: baylisa@baylisa.org, rem-conf@es.net, sage-members@usenix.org
Subject: BayLISA: Maureen Dorney on Legal Issues In System Administration
Cc: deleon@hplabsz.hpl.hp.com
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0
Resent-Message-ID: <"8Jl3C2.0.BM2.csFLp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Wed, 16 Apr 1997 09:26:14 -0700

The BayLISA group meets monthly to discuss topics of interest to systems
and network administrators.  The meetings are free and open to the public.

BayLISA holds monthly meetings on the third Thursday of each month at
7:30 PM PST.  We meet at Cisco building J in San Jose, on Tasman Drive near
First street. See www.baylisa.org for more information.  The meetings are also
broadcast via MBONE.

Schedule
--------


April 17: Maureen Dorney on  Legal Issues In System Administration

[Schedule subject to change]

For further information on BayLISA, check out our web site:
http://www.baylisa.org/

To get further information on the meeting location, you can also ftp it from

	ftp.baylisa.org:/location

For any other information, please send email to:

	info@baylisa.org

If you have any questions, please contact me or the info alias listed above.




From rem-conf-request@es.net Wed Apr 16 18:45:11 1997 
Received: from precept.com (actually hydra.precept.com) by osi-west.es.net 
          with ESnet SMTP (PP); Wed, 16 Apr 1997 15:44:54 -0700
Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4) id PAA00856;
          Wed, 16 Apr 1997 15:12:09 -0700
Date: Wed, 16 Apr 1997 15:12:57 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Gary Sullivan <garys@pictel.com>, "C. Zhu" <czhu@mailbox.jf.intel.com>, Mailing 
    list for parties associated with ITU-T Study Group 16 
    <ITU-SG16@MAILBAG.INTEL.COM> , Linda Cline <lscline@mailbox.jf.intel.com>
cc: itu-adv-video@listserv.iterated.com, rem-conf@es.net, 
    jtoga@ibeam.jf.intel.com
Subject: Re: RTP Payload Format for H.263 Stream
In-Reply-To: <199704131830.LAA09771@ideal.jf.intel.com>
Message-ID: <Pine.WNT.3.95.970416140553.-106589E-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Sorry for the delayed response.  Gary Sullivan asked about the version
field that was in an earlier version of the H.263 RTP payload format
but was removed.  Linda Cline's response was right: if we allowed
multiple versions of H.263 packetization to all use the same RTP
static payload type, then a receiver would not be able to tell by
looking at a session description (e.g., in SDP format) whether it
would be able to decode that session.

Linda also noted that in addition, as a more general design principle,
we want to push multiplexing to the lowest feasible point.  Rather
than having to dispatch once on the payload type, and then dispatch
again on an H.263 version number, it is more efficient to control
which version of H.263 is in use by the payload type field itself and
dispatch only once.

> >Sorry to be so ill-informed.  I don't see how "in-band" signaling of a
> >packetization type differs from the "in-band" signaling of modes in
> >H.263, or why it is a problem (other than being a waste of bits).

You are right that these things are similar.  The key difference is
that an older implementation will understand all three modes because
they are part of the payload format spec, but won't know about
additions in a new format spec.  We could have defined separate
payload types for the different modes as well, to eliminate a control
or multiplexing point, but I think payload formats as usually
considered to be independent.  When you switch from one to another,
you may be invoking a different module, etc., that might not share
state with the previous one.  In H.263, the modes are dependent in
that they share a frame store that is incrementally updated.

Now, since H.263+ is on the horizon and H.263++ is likely sometime
later, we could run out of static RTP payload types if we assigned one
to each version.  That is why I am pushing for more widespread use of
dynamic payload types.  I believe that H.245 does have the capability
to define a mapping from an object identifier to an RTP dynamic
payload type.  I propose that this mechanism be used for H.263+.

Regarding the related message thread about deployment of H.323 version
1 systems using draft 01 of the H.263 RTP payload format, perhaps our
mistake was in assigning a static payload type too early.  With
dynamic payload types, there's plenty of space to specify exactly
which draft format is being used so long as we are careful to assign
distinct names to the formats in each draft.  For example, in the SDP
format, we could have used

a=rtpmap:96 H263-01/90000

to indicate the first draft.  In the case of H.245, I guess that means
assigning an object id to any draft that will actually be used.  When
the proposed payload format gets to a sufficient standard status, then
we might assign a static payload type.  On the other hand, there might
be no need.

I agree that it makes sense for this H.263 payload format spec to be
clear to which version of H.263 it refers.

Regarding Gary's other comments requesting clarifications in the H.263
payload format text, my understanding from Chad Zhu is that those
clarifications will be incorporated into the text.  We will add Gary's
comments with any others that may be received during the IETF Last
Call (for comments) period to update the draft before publication as
an RFC.
							-- Steve


From rem-conf-request@tmpmail.es.net Wed Apr 16 19:08:11 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Wed, 16 Apr 1997 16:08:01 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wHdRw-0005s6-00; Wed, 16 Apr 1997 15:45:12 -0700
Date: Wed, 16 Apr 1997 15:12:57 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Gary Sullivan <garys@pictel.com>, "C. Zhu" <czhu@mailbox.jf.intel.com>, Mailing 
    list for parties associated with ITU-T Study Group 16 
    <ITU-SG16@MAILBAG.INTEL.COM> , Linda Cline <lscline@mailbox.jf.intel.com>
cc: itu-adv-video@listserv.iterated.com, rem-conf@es.net, 
    jtoga@ibeam.jf.intel.com
Subject: Re: RTP Payload Format for H.263 Stream
In-Reply-To: <199704131830.LAA09771@ideal.jf.intel.com>
Message-ID: <Pine.WNT.3.95.970416140553.-106589E-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-ID: <"RFIyI.0.jW5.uPLLp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Wed, 16 Apr 1997 15:45:12 -0700

Sorry for the delayed response.  Gary Sullivan asked about the version
field that was in an earlier version of the H.263 RTP payload format
but was removed.  Linda Cline's response was right: if we allowed
multiple versions of H.263 packetization to all use the same RTP
static payload type, then a receiver would not be able to tell by
looking at a session description (e.g., in SDP format) whether it
would be able to decode that session.

Linda also noted that in addition, as a more general design principle,
we want to push multiplexing to the lowest feasible point.  Rather
than having to dispatch once on the payload type, and then dispatch
again on an H.263 version number, it is more efficient to control
which version of H.263 is in use by the payload type field itself and
dispatch only once.

> >Sorry to be so ill-informed.  I don't see how "in-band" signaling of a
> >packetization type differs from the "in-band" signaling of modes in
> >H.263, or why it is a problem (other than being a waste of bits).

You are right that these things are similar.  The key difference is
that an older implementation will understand all three modes because
they are part of the payload format spec, but won't know about
additions in a new format spec.  We could have defined separate
payload types for the different modes as well, to eliminate a control
or multiplexing point, but I think payload formats as usually
considered to be independent.  When you switch from one to another,
you may be invoking a different module, etc., that might not share
state with the previous one.  In H.263, the modes are dependent in
that they share a frame store that is incrementally updated.

Now, since H.263+ is on the horizon and H.263++ is likely sometime
later, we could run out of static RTP payload types if we assigned one
to each version.  That is why I am pushing for more widespread use of
dynamic payload types.  I believe that H.245 does have the capability
to define a mapping from an object identifier to an RTP dynamic
payload type.  I propose that this mechanism be used for H.263+.

Regarding the related message thread about deployment of H.323 version
1 systems using draft 01 of the H.263 RTP payload format, perhaps our
mistake was in assigning a static payload type too early.  With
dynamic payload types, there's plenty of space to specify exactly
which draft format is being used so long as we are careful to assign
distinct names to the formats in each draft.  For example, in the SDP
format, we could have used

a=rtpmap:96 H263-01/90000

to indicate the first draft.  In the case of H.245, I guess that means
assigning an object id to any draft that will actually be used.  When
the proposed payload format gets to a sufficient standard status, then
we might assign a static payload type.  On the other hand, there might
be no need.

I agree that it makes sense for this H.263 payload format spec to be
clear to which version of H.263 it refers.

Regarding Gary's other comments requesting clarifications in the H.263
payload format text, my understanding from Chad Zhu is that those
clarifications will be incorporated into the text.  We will add Gary's
comments with any others that may be received during the IETF Last
Call (for comments) period to update the draft before publication as
an RFC.
							-- Steve



From rem-conf-request@es.net Thu Apr 17 09:25:13 1997 
Received: from cs.columbia.edu by osi-west.es.net with ESnet SMTP (PP);
          Thu, 17 Apr 1997 06:25:08 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) 
          by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id JAA27607;
          Thu, 17 Apr 1997 09:25:06 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) 
          by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id JAA04407;
          Thu, 17 Apr 1997 09:25:01 -0400 (EDT)
Sender: hgs@cs.columbia.edu
Message-ID: <335624AC.4682@cs.columbia.edu>
Date: Thu, 17 Apr 1997 09:25:00 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: "Michael E. Knappe" <mknappe@cisco.com>
CC: voip-tech@vocaltec.com, rem-conf@es.net
Subject: Comfort noise payload types for RTP profile, VoIP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Having looked at the different comfort noise codings, I'm not optimistic
that we can find a 'grand unified theory of CN'. The G.729 and G.723.1
CN codings use a small set (3 or so) of filter parameters directly
derived from the codec itself. For the waveform/sample codecs (DVI,
PCM*, G.726, etc.), it would be difficult to arrive at these parameters
without duplicating large parts of either G.729 or G.723.1. Given the
prohibitive licensing conditions, this is not an option for
non-commercial products (leaving issues of complexity aside). 

Thus, I believe the best realistic solution is to have codec-specific CN
for G.723.1 and G.729 and use a simple white-noise energy indication (as
for frame relay, measured in dBrn0, not the current/G.764 discretized
version) for all other codecs.

This does not prevent people from combining their favorite high-quality
voice codec with, say, the G.729 CNG, as this would likely result in
better representation of background noise compared to volume-scaled
white noise. But this is no different from normal codec switching as far
as RTP is concerned.

Since I'm trying to make progress on getting the profile in shape for
the next 'last call' round, I'd appreciate comments so that closure can
be reached on this issue.

Henning

From rem-conf-request@tmpmail.es.net Thu Apr 17 09:45:47 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Thu, 17 Apr 1997 06:45:44 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wHrBc-000305-00; Thu, 17 Apr 1997 06:25:16 -0700
Sender: hgs@cs.columbia.edu
Message-ID: <335624AC.4682@cs.columbia.edu>
Date: Thu, 17 Apr 1997 09:25:00 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: "Michael E. Knappe" <mknappe@cisco.com>
CC: voip-tech@vocaltec.com, rem-conf@es.net
Subject: Comfort noise payload types for RTP profile, VoIP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"KROqa3.0.Gq2.xIYLp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Thu, 17 Apr 1997 06:25:16 -0700

Having looked at the different comfort noise codings, I'm not optimistic
that we can find a 'grand unified theory of CN'. The G.729 and G.723.1
CN codings use a small set (3 or so) of filter parameters directly
derived from the codec itself. For the waveform/sample codecs (DVI,
PCM*, G.726, etc.), it would be difficult to arrive at these parameters
without duplicating large parts of either G.729 or G.723.1. Given the
prohibitive licensing conditions, this is not an option for
non-commercial products (leaving issues of complexity aside). 

Thus, I believe the best realistic solution is to have codec-specific CN
for G.723.1 and G.729 and use a simple white-noise energy indication (as
for frame relay, measured in dBrn0, not the current/G.764 discretized
version) for all other codecs.

This does not prevent people from combining their favorite high-quality
voice codec with, say, the G.729 CNG, as this would likely result in
better representation of background noise compared to volume-scaled
white noise. But this is no different from normal codec switching as far
as RTP is concerned.

Since I'm trying to make progress on getting the profile in shape for
the next 'last call' round, I'd appreciate comments so that closure can
be reached on this issue.

Henning


From rem-conf-request@es.net Thu Apr 17 10:26:51 1997 
Received: from brittany.cisco.com by osi-west.es.net with ESnet SMTP (PP);
          Thu, 17 Apr 1997 07:26:46 -0700
Received: from mknappe-pc.cisco.com (sj-dial-2-43.cisco.com [171.68.179.172]) 
          by brittany.cisco.com (8.6.12/8.6.5) with SMTP id HAA04619;
          Thu, 17 Apr 1997 07:26:07 -0700
Message-Id: <2.2.32.19970417141713.00d84c90@brittany.cisco.com>
X-Sender: mknappe@brittany.cisco.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 17 Apr 1997 07:17:13 -0700
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
From: "Michael E. Knappe" <mknappe@cisco.com>
Subject: Re: Comfort noise payload types for RTP profile, VoIP
Cc: voip-tech@vocaltec.com, rem-conf@es.net

Henning,

I agree that it is difficult to unify them - having a codec independent
silence indicator was the original intent. I picked G.764 because it came
>from an established ITU spec, but the use of the FRF syntax has merit as
well - it's the indication of silence that is most important. I will look at
the FRF.11 agreement and put out an e-mail comparing both, and see if we can
get some e-mail straw poll concensus about which is preferred.

Mike

At 09:25 AM 4/17/97 -0400, you wrote:
>Having looked at the different comfort noise codings, I'm not optimistic
>that we can find a 'grand unified theory of CN'. The G.729 and G.723.1
>CN codings use a small set (3 or so) of filter parameters directly
>derived from the codec itself. For the waveform/sample codecs (DVI,
>PCM*, G.726, etc.), it would be difficult to arrive at these parameters
>without duplicating large parts of either G.729 or G.723.1. Given the
>prohibitive licensing conditions, this is not an option for
>non-commercial products (leaving issues of complexity aside). 
>
>Thus, I believe the best realistic solution is to have codec-specific CN
>for G.723.1 and G.729 and use a simple white-noise energy indication (as
>for frame relay, measured in dBrn0, not the current/G.764 discretized
>version) for all other codecs.
>
>This does not prevent people from combining their favorite high-quality
>voice codec with, say, the G.729 CNG, as this would likely result in
>better representation of background noise compared to volume-scaled
>white noise. But this is no different from normal codec switching as far
>as RTP is concerned.
>
>Since I'm trying to make progress on getting the profile in shape for
>the next 'last call' round, I'd appreciate comments so that closure can
>be reached on this issue.
>
>Henning
>
>
____________________________________________________________________________

Michael Knappe                ||        ||                     cisco Systems
Partners Engineering         .||.      .||.                       Building E
                            .||||.    .||||.           170 West Tasman Drive
408-527-3849            ...||||||||..||||||||...         San Jose, CA  95134
408-526-4287  (fax)      c i s c o S y s t e m s           mknappe@cisco.com
____________________________________________________________________________



From rem-conf-request@tmpmail.es.net Thu Apr 17 10:38:39 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Thu, 17 Apr 1997 07:38:35 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wHs9F-0003Zd-00; Thu, 17 Apr 1997 07:26:53 -0700
Message-Id: <2.2.32.19970417141713.00d84c90@brittany.cisco.com>
X-Sender: mknappe@brittany.cisco.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 17 Apr 1997 07:17:13 -0700
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
From: "Michael E. Knappe" <mknappe@cisco.com>
Subject: Re: Comfort noise payload types for RTP profile, VoIP
Cc: voip-tech@vocaltec.com, rem-conf@es.net
Resent-Message-ID: <"KsOWq.0.iM3.jCZLp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Thu, 17 Apr 1997 07:26:53 -0700

Henning,

I agree that it is difficult to unify them - having a codec independent
silence indicator was the original intent. I picked G.764 because it came
>from an established ITU spec, but the use of the FRF syntax has merit as
well - it's the indication of silence that is most important. I will look at
the FRF.11 agreement and put out an e-mail comparing both, and see if we can
get some e-mail straw poll concensus about which is preferred.

Mike

At 09:25 AM 4/17/97 -0400, you wrote:
>Having looked at the different comfort noise codings, I'm not optimistic
>that we can find a 'grand unified theory of CN'. The G.729 and G.723.1
>CN codings use a small set (3 or so) of filter parameters directly
>derived from the codec itself. For the waveform/sample codecs (DVI,
>PCM*, G.726, etc.), it would be difficult to arrive at these parameters
>without duplicating large parts of either G.729 or G.723.1. Given the
>prohibitive licensing conditions, this is not an option for
>non-commercial products (leaving issues of complexity aside). 
>
>Thus, I believe the best realistic solution is to have codec-specific CN
>for G.723.1 and G.729 and use a simple white-noise energy indication (as
>for frame relay, measured in dBrn0, not the current/G.764 discretized
>version) for all other codecs.
>
>This does not prevent people from combining their favorite high-quality
>voice codec with, say, the G.729 CNG, as this would likely result in
>better representation of background noise compared to volume-scaled
>white noise. But this is no different from normal codec switching as far
>as RTP is concerned.
>
>Since I'm trying to make progress on getting the profile in shape for
>the next 'last call' round, I'd appreciate comments so that closure can
>be reached on this issue.
>
>Henning
>
>
____________________________________________________________________________

Michael Knappe                ||        ||                     cisco Systems
Partners Engineering         .||.      .||.                       Building E
                            .||||.    .||||.           170 West Tasman Drive
408-527-3849            ...||||||||..||||||||...         San Jose, CA  95134
408-526-4287  (fax)      c i s c o S y s t e m s           mknappe@cisco.com
____________________________________________________________________________




From rem-conf-request@es.net Thu Apr 17 10:49:34 1997 
Received: from gateway-gw.pictel.com by osi-west.es.net with ESnet SMTP (PP);
          Thu, 17 Apr 1997 07:49:22 -0700
Received: from roadrunner.pictel.com 
          by gateway-gw.pictel.com (4.1/cf.gw.940128.1740) id AA18416;
          Thu, 17 Apr 97 10:47:52 EDT
Received: from python.pictel.com by roadrunner.pictel.com (4.1/runner.910925.1) 
          id AA29182; Thu, 17 Apr 97 10:47:45 EDT
Received: by python.pictel.com (5.x/SMI-SVR4) id AA29881;
          Thu, 17 Apr 1997 10:45:54 -0400
Date: Thu, 17 Apr 1997 10:45:54 -0400
From: garys@pictel.com (Gary Sullivan)
Message-Id: <9704171445.AA29881@python.pictel.com>
To: ITU-SG16@MAILBAG.INTEL.COM, casner@precept.com, czhu@mailbox.jf.intel.com, 
    garys@es.net, lscline@mailbox.jf.intel.com
Subject: Re: RTP Payload Format for H.263 Stream
Cc: itu-adv-video@listserv.iterated.com, jtoga@ibeam.jf.intel.com, 
    rem-conf@es.net



Steve, Linda, Chad, et al,

Thanks for your explanations.  I think I understand your reasoning.

I was surprised to hear from Linda Cline that the first draft didn't
have a version number, so that keeping the version number might not
help fix the problem of people implementing H.323 systems based on that
old draft.  We'll just have to deal with that some other way (a couple
of ways to deal with it for H.323 seem to have already surfaced).

Thanks again for being so responsive to my comments and questions.

Best Wishes,
Gary Sullivan

--Gary Sullivan  Tel: +1 508-623-4324 Fax: 749-2804 <garys@pictel.com>
  PictureTel Corp. M/S 635, 100 Minuteman Road, Andover MA 01810  USA

From rem-conf-request@tmpmail.es.net Thu Apr 17 11:00:43 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Thu, 17 Apr 1997 08:00:32 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wHsVD-0003xK-00; Thu, 17 Apr 1997 07:49:35 -0700
Date: Thu, 17 Apr 1997 10:45:54 -0400
From: garys@pictel.com (Gary Sullivan)
Message-Id: <9704171445.AA29881@python.pictel.com>
To: ITU-SG16@MAILBAG.INTEL.COM, casner@precept.com, czhu@mailbox.jf.intel.com, 
    garys@es.net, lscline@mailbox.jf.intel.com
Subject: Re: RTP Payload Format for H.263 Stream
Cc: itu-adv-video@listserv.iterated.com, jtoga@ibeam.jf.intel.com, 
    rem-conf@es.net
Resent-Message-ID: <"paecd.0.fj3._XZLp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Thu, 17 Apr 1997 07:49:35 -0700



Steve, Linda, Chad, et al,

Thanks for your explanations.  I think I understand your reasoning.

I was surprised to hear from Linda Cline that the first draft didn't
have a version number, so that keeping the version number might not
help fix the problem of people implementing H.323 systems based on that
old draft.  We'll just have to deal with that some other way (a couple
of ways to deal with it for H.323 seem to have already surfaced).

Thanks again for being so responsive to my comments and questions.

Best Wishes,
Gary Sullivan

--Gary Sullivan  Tel: +1 508-623-4324 Fax: 749-2804 <garys@pictel.com>
  PictureTel Corp. M/S 635, 100 Minuteman Road, Andover MA 01810  USA


From rem-conf-request@es.net Thu Apr 17 12:28:04 1997 
Received: from igw3.watson.ibm.com by osi-west.es.net with ESnet SMTP (PP);
          Thu, 17 Apr 1997 09:27:54 -0700
Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) 
          by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id MAA03330 
          for <rem-conf@es.net>; Thu, 17 Apr 1997 12:18:05 -0400
From: BISDIK@watson.ibm.com
Received: from yktvmv.watson.ibm.com (yktvmv.watson.ibm.com [9.117.33.29]) 
          by mailhub1.watson.ibm.com (8.8.2/01-15-97) with SMTP id MAA24468 
          for <rem-conf%es.net@watson.ibm.com>; Thu, 17 Apr 1997 12:27:50 -0400
Message-Id: <199704171627.MAA24468@mailhub1.watson.ibm.com>
Received: from YKTVMV by yktvmv.watson.ibm.com (IBM VM SMTP V2R4) with BSMTP 
          id 1624; Thu, 17 Apr 97 12:27:48 EDT
Date: Thu, 17 Apr 97 12:27:25 EDT
To: rem-conf@es.net
Subject: IEEE HPCS'97 Workshop / Registration Information

*** This note may arrive to you from several not-intended to be used
*** sources.  If this happens, please accept my apologies and disregard
*** any additional copies of the note.


Dear colleagues,
    This is to notify that registration to the

*******************************************************************
***                                                             ***
*** Fourth IEEE Workshop on the Architecture and Implementation ***
***     of High Performance Communication Systems (HPCS'97)     ***
***                                                             ***
*******************************************************************

to be held in Sani Beach, Chalkidiki, Greece, June 23-25, 1997, has
started. A preliminary workshop program has been attached below.

Please, visit the HPCS'97 Web page at

           http://emperor.arl.wustl.edu/arl/workshops/hpcs/

for further information and on-line registration.

Note: The workshop is to take place during high tourist period.
      The Sani Beach resort has set aside a number of rooms at a special
      HPCS'97 price.  To be guaranteed the special price, reserve rooms
      with the hotel by APRIL 23, 1997.  See, our Web pages under
      "Accommodations" for further hotel reservation details.

Best Regards,
Chatschik Bisdikian
Financial Chair
IEEE HPCS'97


============((( PRELIMINARY WORKSHOP PROGRAM )))======================

IEEE HPCS'97
Sani Beach, Chalkidiki, Greece
June 23-25, 1997

----------------------------------------------------------------
Welcome and introductory remarks
----------------------------------------------------------------
Keynote Session I
----------------------------------------------------------------

Morning Break

----------------------------------------------------------------
Session I: Internetworking
----------------------------------------------------------------

Efficient Routing Table Lookup for IPv6

	M. Zitterbart,
	T. Harbaum,
	D. Broekelmann
	Institute of Operating Systems and Computer Networks
	TU Braunschweig, Germany
	zit@ibr.cs.tu-bs.de
	phone: ++40 531 391 3288
	fax: ++49 531 391 5936


An Experimental Implementation of Traffic Control for IP Networks

	Martin May and Christophe Diot
	INRIA
	BP 93
	06902 Sophia-Antipolis Cedex
        France
	mmay,cdiot@sophia.inria.fr


Towards Managed Real-time Communications in the Internet Environment

	Randa El-Marakby, David Hutchison
	Computing Department,
	Lancaster University,
	Lancaster LA1 4YR, U.K.
	Tel.: (+44)-1524-65201 Ext. 4538
	E-mail: <randa,dh>@comp.lancs.ac.uk


A  Hybrid Error Recovery Structure Protocol for Internetworks
	Lifan Gu
	lgu@cse.ucsc.edu
        Tel: 408-459-5290 ( Office )
             408-457-2218 ( Home )


----------------------------------------------------------------
Panel Session I:
Session Organizer: Christophe Diot
----------------------------------------------------------------

Afternoon Break


----------------------------------------------------------------
Session II: Multimedia
----------------------------------------------------------------

End System Support for Networking with Quality of Service Guarantees

	David K.Y. Yau,Simon S. Lam
	yau@cs.utexas.edu
	512-471-9599
	Simon S. Lam
	lam@cs.utexas.edu
	512-471-9531


Modelling, Design and Performance Evaluation of Interactive
Distributed Video-On-Demand Systems

	Prof. M. Paterakis and C. Vassilakis
	Constantinos Vassilakis and Michael Paterakis *
	Laboratories of Telecommunications and Information & Computer Networks
	Department of Electronics & Computer Engineering
	Technical University of Crete
	731-00 Chania, GREECE
	Phone : +30-821-37225, 37218, 37260
	Email : {cv,pateraki }@telecom.tuc.gr


MultiMedia Digital Community: A web-enabled multimedia collaboration system

	Chatschik Bisdikian, Stephen Brady, Yurdaer N. Doganata
        Davis Foulger, Franco Marconcini, Magda Mourad
        Howard L. Operowsky, Giovanni Pacifici, and Asser N. Tantawi
	IBM Research Division
        T. J. Watson Research Center
        30 Saw Mill River Road
        Hawthorne, NY 10532, USA

Implementing a CSCW Framework using CORBA

	Dong Ho Song, Dong Hae Chi*, Keung Hae Lee
	 Dept. Of Computer Engineering, Hangkong University
        Hwajun Dong, 200-1, Koyang City, Kyunggi Do, 411-791, S.Korea
        dhsong@hanul.hangkong.ac.kr
        +82-2-300-0186(tel)
        +82-2-3158-6748(fax)
        *Parallel Programming Section
        ETRI
        Yusong P.O.Box 106, Taejon, S.Korea
        +82-42-860-6615(tel)



----------------------------------------------------------------
Dinner Banquet

Dinner Keynote Session: Professor Emmanuel Protonotarios
        National Technical University of Athens

----------------------------------------------------------------

END OF THE FIRST DAY


----------------------------------------------------------------
Keynote Session II:
----------------------------------------------------------------

Morning Break

----------------------------------------------------------------
Session III: Wireless and Mobility
----------------------------------------------------------------

Supporting Multimedia Traffic Over Cellular Networks

	Z. Zhang
	I. Habib
	T. Saadawi
	Department of Electrical Engineering,
	City University of New York,
	City College,
	New York, NY,10031,
	{zzhang,eeiwh,eetns}@eemail.engr.ccny.cuny.edu

An Efficient Polling MAC for Wireless LANs

	Oran Sharon
	Dept. of Computer Science
        University of Haifa
        Haifa, 31905
        Israel
	Email: oran@mathcs11.haifa.ac.il
	Tel: 972-4-8240167
             972-4-9831867


Voice/Data Integrated Wireless Channel Access in Third Generation
Digital Cellular Networks : the Performance of Bursty Data Generated
by Interactive Applications

	I.Rombogiannakis, and M.Paterakis
	Electronic and Computer Engrg. Dept.
	Technical Univ. of Crete
	731-00 Chania, GREECE
	{rombo, pateraki}@telecom.tuc.gr


Achievable QoS in a Shared Wireless Channel

	Jeffrey Capone and Ioannis Stavrakakis
	Ioannis Stavrakakis
	ECE Dept. - 409 Dana Bldg.
	Northeastern University, Boston, MA 02115, USA
	Phone: (617) 373-3053
	Fax: (617) 373-8970
	E-mail: {ioannis,capone}.cdsp.neu.edu

----------------------------------------------------------------
Invited/Panel Session II: Kurt Maly
----------------------------------------------------------------

Afternoon Break

----------------------------------------------------------------
Session IV: Multicast
----------------------------------------------------------------


An Architecture for Networked Multimedia Applications supporting
Group Communications

	George Branis, Nikolas Mitrou, John Soldatos, Evaghelos
	Vayias, John Zissopoulos
	National Technical University of Athens
        Department of Electrical and Computer Engineering
        Telecommunications Laboratory
        7, Iroon Polytechneiou, St.
        Zografou Campus
        Athens, GREECE
	Phone:  +30 1 772 15 13
                +30 1 772 16 39
	FAX:    +30 1 772 25 34
	e-mail: gbranis@telecom.ntua.gr
                mitrou@softlab.ntua.gr
                jsoldat@telecom.ntua.gr
                evayias@telecom.ntua.gr
                zissop@softlab.ntua.gr


A Reliable Multicast data Distribution Protocol based on software FEC
techniques

	Luigi Rizzo and Lorenzo Vicisano
	Dip. di Ingegneria dell'Informazione, Univ. di Pisa
	via Diotisalvi 2, 56126 Pisa (Italy)
	email: l.rizzo@iet.unipi.it
	phone: +39-50-568533   fax: +39-50-568522
	
	Lorenzo Vicisano
	Department of Computer Science, University College London
	Gower Street, London WC1E 6BT, UK
	email: l.vicisano@cs.ucl.ac.uk
	phone: +44-171-4193670


Multicast Routing with Heterogeneous Quality

	Michalis Faloutsos,   Rajesh Pankaj , Kenneth C. Sevcik
	elm: mfalou@cs.toronto.edu
	Grad. Office,
	Dept. of Computer Science,
	Univ. of Toronto
	Toronto, Ontario,
	M5S 3G4, CANADA
	Phone: work (416)- 978-5182
         FAX (416)- 978-1931


Issues on Fast Network Simulation by Use of Effective and Decoupling
Bandwidths

	Matthias Falkner, Michael Devetsikiotis, Ioannis Lambadaris
	Michael Devetsikiotis
	Department of Systems and Computer Engineering
	Carleton University
	Ottawa, Ontario K1S 5B6, CANADA
	tel: (613) 520-5730
	fax: (613) 520-5727
	email: mike@sce.carleton.ca

----------------------------------------------------------------

END OF THE SECOND DAY

----------------------------------------------------------------
Session VII: Traffic Engineering
----------------------------------------------------------------

Behavior of Various Switch Mechanisms for the ABR Service in the Presence of Persistent and Dynamic Traffic

	Dorgham Sisalem
	GMD-Fokus
        Hardenberg Platz 2
        10623 Berlin, Germany
        sisalem@fokus.gmd.de


On Defining, Computing and Guaranteeing Transient Loss in
High-Performance Packet Networks

	Li Guangliang
	Institute of Computing Technology
        Academia Sinica, P. O. Box 2704--25
        Beijing 100080, P. R. China
        gli@metal.chpc.ict.ac.cn

ATLAS I: Building Block for ATM Networks with Credit-based Flow Control

	D.N. Serpanos, M.G.H. Katevenis and E. Spyridakis
	Institute of Computer Science
	Foundation for Research and Technology - Hellas
	P.O. Box 1385, GR-71110 Heraklion, Crete, Greece
	Contact e-mail: {serpanos,katevenis}@ics.forth.gr
	Telephone: +30 (81) 39 16 63   Fax: +30 (81) 39 16 61

Buffer Requirements of Credit-Based Flow Control when a Minimum
Draining Rate is Guaranteed

	Manolis Katevenis
	Institute of Computer Science (ICS)
	Foundation for Research and Technology \- Hellas (FORTH)
	Science and Technology Park of Crete, Vassilika Vouton,
	P.O.Box 1385, Heraklion, Crete, GR 711 10  Greece
	E-mail: katevenis@ics.forth.gr
	Tel.: +30 (81) 391664   Fax: +30 (81) 391661

MORNING BREAK

----------------------------------------------------------------
Session VII: Misc.
----------------------------------------------------------------

Techniques and Architectures in Secure Facsimile Communications

	George Troullinos
	INTRACOM S.A.
	19.5 Km PEANIA - MARKOPOULO Ave.
	P.O. BOX 68, 190 02 PEANIA - ATTIKA - GREECE
	Tel:  (30-1) 6860698 - Fax: (30-1) 6645103
	Email: gtrou@Intranet.gr
	Digital Signal Processing

An Encryption Scheme for High Speed Passive Optical Networks

	D. Polemi, J. Koulouris, J. Angelopoulos
	John Angelopoulos
	National Technical University of Athens
	Electrical and Computer Science Dptm.
	GR15773 Polytechniopolis Zographou, Greece
	Fax: (+301) 772 2534
	e-mail: jangel@cs.ntua.gr, polemi@cs.ntua.gr


Broadband multimedia services design and implementation exploiting IN
features

	G. N. Prezerakos, C. D. Anagnostakis, I. S. Venieris
	National Technical University of Athens
	Department of Electrical Engineering and Computer Science
	Corresponding Author : Prof. I. S. Venieris
	Email: venieris@cs.ntua.gr
	Fax: +30 1 772 2534
	Phone: +30 1 772 2551
	Postal Address:
	Nationala Technical University of Athens
	Zografou Campus
	Electrical Engineering Building
	Heroon Polytechneiou 9
	Zografou, 15773
	Athens, GREECE

Error Correction Strategies for Wireless ATM

	Christian Schuler
	GMD FOKUS, Berlin, Germany
        email: schuler@fokus.gmd.de
        Phone: ++49 / (0)30 / 254 99 - 295
   	Fax: ++49 / (0)30 / 254 99 - 202
	Email: schuler@fokus.gmd.de
	Homepage: http://www.fokus.gmd.de/usr/schuler


----------------------------------------------------------------

----------------------------------------------------------------
Invited/Panel Session III: Global High Speed Communications - Ante Portas?
Panel Chair: Stefan Covaci
----------------------------------------------------------------

WORKSHOP ENDS

From rem-conf-request@tmpmail.es.net Thu Apr 17 12:42:39 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Thu, 17 Apr 1997 09:42:23 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wHu2Y-0004qV-00; Thu, 17 Apr 1997 09:28:06 -0700
From: BISDIK@watson.ibm.com
Message-Id: <199704171627.MAA24468@mailhub1.watson.ibm.com>
Date: Thu, 17 Apr 97 12:27:25 EDT
To: rem-conf@es.net
Subject: IEEE HPCS'97 Workshop / Registration Information
Resent-Message-ID: <"FNKuq3.0.6Z4.M-aLp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Thu, 17 Apr 1997 09:28:06 -0700

*** This note may arrive to you from several not-intended to be used
*** sources.  If this happens, please accept my apologies and disregard
*** any additional copies of the note.


Dear colleagues,
    This is to notify that registration to the

*******************************************************************
***                                                             ***
*** Fourth IEEE Workshop on the Architecture and Implementation ***
***     of High Performance Communication Systems (HPCS'97)     ***
***                                                             ***
*******************************************************************

to be held in Sani Beach, Chalkidiki, Greece, June 23-25, 1997, has
started. A preliminary workshop program has been attached below.

Please, visit the HPCS'97 Web page at

           http://emperor.arl.wustl.edu/arl/workshops/hpcs/

for further information and on-line registration.

Note: The workshop is to take place during high tourist period.
      The Sani Beach resort has set aside a number of rooms at a special
      HPCS'97 price.  To be guaranteed the special price, reserve rooms
      with the hotel by APRIL 23, 1997.  See, our Web pages under
      "Accommodations" for further hotel reservation details.

Best Regards,
Chatschik Bisdikian
Financial Chair
IEEE HPCS'97


============((( PRELIMINARY WORKSHOP PROGRAM )))======================

IEEE HPCS'97
Sani Beach, Chalkidiki, Greece
June 23-25, 1997

----------------------------------------------------------------
Welcome and introductory remarks
----------------------------------------------------------------
Keynote Session I
----------------------------------------------------------------

Morning Break

----------------------------------------------------------------
Session I: Internetworking
----------------------------------------------------------------

Efficient Routing Table Lookup for IPv6

	M. Zitterbart,
	T. Harbaum,
	D. Broekelmann
	Institute of Operating Systems and Computer Networks
	TU Braunschweig, Germany
	zit@ibr.cs.tu-bs.de
	phone: ++40 531 391 3288
	fax: ++49 531 391 5936


An Experimental Implementation of Traffic Control for IP Networks

	Martin May and Christophe Diot
	INRIA
	BP 93
	06902 Sophia-Antipolis Cedex
        France
	mmay,cdiot@sophia.inria.fr


Towards Managed Real-time Communications in the Internet Environment

	Randa El-Marakby, David Hutchison
	Computing Department,
	Lancaster University,
	Lancaster LA1 4YR, U.K.
	Tel.: (+44)-1524-65201 Ext. 4538
	E-mail: <randa,dh>@comp.lancs.ac.uk


A  Hybrid Error Recovery Structure Protocol for Internetworks
	Lifan Gu
	lgu@cse.ucsc.edu
        Tel: 408-459-5290 ( Office )
             408-457-2218 ( Home )


----------------------------------------------------------------
Panel Session I:
Session Organizer: Christophe Diot
----------------------------------------------------------------

Afternoon Break


----------------------------------------------------------------
Session II: Multimedia
----------------------------------------------------------------

End System Support for Networking with Quality of Service Guarantees

	David K.Y. Yau,Simon S. Lam
	yau@cs.utexas.edu
	512-471-9599
	Simon S. Lam
	lam@cs.utexas.edu
	512-471-9531


Modelling, Design and Performance Evaluation of Interactive
Distributed Video-On-Demand Systems

	Prof. M. Paterakis and C. Vassilakis
	Constantinos Vassilakis and Michael Paterakis *
	Laboratories of Telecommunications and Information & Computer Networks
	Department of Electronics & Computer Engineering
	Technical University of Crete
	731-00 Chania, GREECE
	Phone : +30-821-37225, 37218, 37260
	Email : {cv,pateraki }@telecom.tuc.gr


MultiMedia Digital Community: A web-enabled multimedia collaboration system

	Chatschik Bisdikian, Stephen Brady, Yurdaer N. Doganata
        Davis Foulger, Franco Marconcini, Magda Mourad
        Howard L. Operowsky, Giovanni Pacifici, and Asser N. Tantawi
	IBM Research Division
        T. J. Watson Research Center
        30 Saw Mill River Road
        Hawthorne, NY 10532, USA

Implementing a CSCW Framework using CORBA

	Dong Ho Song, Dong Hae Chi*, Keung Hae Lee
	 Dept. Of Computer Engineering, Hangkong University
        Hwajun Dong, 200-1, Koyang City, Kyunggi Do, 411-791, S.Korea
        dhsong@hanul.hangkong.ac.kr
        +82-2-300-0186(tel)
        +82-2-3158-6748(fax)
        *Parallel Programming Section
        ETRI
        Yusong P.O.Box 106, Taejon, S.Korea
        +82-42-860-6615(tel)



----------------------------------------------------------------
Dinner Banquet

Dinner Keynote Session: Professor Emmanuel Protonotarios
        National Technical University of Athens

----------------------------------------------------------------

END OF THE FIRST DAY


----------------------------------------------------------------
Keynote Session II:
----------------------------------------------------------------

Morning Break

----------------------------------------------------------------
Session III: Wireless and Mobility
----------------------------------------------------------------

Supporting Multimedia Traffic Over Cellular Networks

	Z. Zhang
	I. Habib
	T. Saadawi
	Department of Electrical Engineering,
	City University of New York,
	City College,
	New York, NY,10031,
	{zzhang,eeiwh,eetns}@eemail.engr.ccny.cuny.edu

An Efficient Polling MAC for Wireless LANs

	Oran Sharon
	Dept. of Computer Science
        University of Haifa
        Haifa, 31905
        Israel
	Email: oran@mathcs11.haifa.ac.il
	Tel: 972-4-8240167
             972-4-9831867


Voice/Data Integrated Wireless Channel Access in Third Generation
Digital Cellular Networks : the Performance of Bursty Data Generated
by Interactive Applications

	I.Rombogiannakis, and M.Paterakis
	Electronic and Computer Engrg. Dept.
	Technical Univ. of Crete
	731-00 Chania, GREECE
	{rombo, pateraki}@telecom.tuc.gr


Achievable QoS in a Shared Wireless Channel

	Jeffrey Capone and Ioannis Stavrakakis
	Ioannis Stavrakakis
	ECE Dept. - 409 Dana Bldg.
	Northeastern University, Boston, MA 02115, USA
	Phone: (617) 373-3053
	Fax: (617) 373-8970
	E-mail: {ioannis,capone}.cdsp.neu.edu

----------------------------------------------------------------
Invited/Panel Session II: Kurt Maly
----------------------------------------------------------------

Afternoon Break

----------------------------------------------------------------
Session IV: Multicast
----------------------------------------------------------------


An Architecture for Networked Multimedia Applications supporting
Group Communications

	George Branis, Nikolas Mitrou, John Soldatos, Evaghelos
	Vayias, John Zissopoulos
	National Technical University of Athens
        Department of Electrical and Computer Engineering
        Telecommunications Laboratory
        7, Iroon Polytechneiou, St.
        Zografou Campus
        Athens, GREECE
	Phone:  +30 1 772 15 13
                +30 1 772 16 39
	FAX:    +30 1 772 25 34
	e-mail: gbranis@telecom.ntua.gr
                mitrou@softlab.ntua.gr
                jsoldat@telecom.ntua.gr
                evayias@telecom.ntua.gr
                zissop@softlab.ntua.gr


A Reliable Multicast data Distribution Protocol based on software FEC
techniques

	Luigi Rizzo and Lorenzo Vicisano
	Dip. di Ingegneria dell'Informazione, Univ. di Pisa
	via Diotisalvi 2, 56126 Pisa (Italy)
	email: l.rizzo@iet.unipi.it
	phone: +39-50-568533   fax: +39-50-568522
	
	Lorenzo Vicisano
	Department of Computer Science, University College London
	Gower Street, London WC1E 6BT, UK
	email: l.vicisano@cs.ucl.ac.uk
	phone: +44-171-4193670


Multicast Routing with Heterogeneous Quality

	Michalis Faloutsos,   Rajesh Pankaj , Kenneth C. Sevcik
	elm: mfalou@cs.toronto.edu
	Grad. Office,
	Dept. of Computer Science,
	Univ. of Toronto
	Toronto, Ontario,
	M5S 3G4, CANADA
	Phone: work (416)- 978-5182
         FAX (416)- 978-1931


Issues on Fast Network Simulation by Use of Effective and Decoupling
Bandwidths

	Matthias Falkner, Michael Devetsikiotis, Ioannis Lambadaris
	Michael Devetsikiotis
	Department of Systems and Computer Engineering
	Carleton University
	Ottawa, Ontario K1S 5B6, CANADA
	tel: (613) 520-5730
	fax: (613) 520-5727
	email: mike@sce.carleton.ca

----------------------------------------------------------------

END OF THE SECOND DAY

----------------------------------------------------------------
Session VII: Traffic Engineering
----------------------------------------------------------------

Behavior of Various Switch Mechanisms for the ABR Service in the Presence of Persistent and Dynamic Traffic

	Dorgham Sisalem
	GMD-Fokus
        Hardenberg Platz 2
        10623 Berlin, Germany
        sisalem@fokus.gmd.de


On Defining, Computing and Guaranteeing Transient Loss in
High-Performance Packet Networks

	Li Guangliang
	Institute of Computing Technology
        Academia Sinica, P. O. Box 2704--25
        Beijing 100080, P. R. China
        gli@metal.chpc.ict.ac.cn

ATLAS I: Building Block for ATM Networks with Credit-based Flow Control

	D.N. Serpanos, M.G.H. Katevenis and E. Spyridakis
	Institute of Computer Science
	Foundation for Research and Technology - Hellas
	P.O. Box 1385, GR-71110 Heraklion, Crete, Greece
	Contact e-mail: {serpanos,katevenis}@ics.forth.gr
	Telephone: +30 (81) 39 16 63   Fax: +30 (81) 39 16 61

Buffer Requirements of Credit-Based Flow Control when a Minimum
Draining Rate is Guaranteed

	Manolis Katevenis
	Institute of Computer Science (ICS)
	Foundation for Research and Technology \- Hellas (FORTH)
	Science and Technology Park of Crete, Vassilika Vouton,
	P.O.Box 1385, Heraklion, Crete, GR 711 10  Greece
	E-mail: katevenis@ics.forth.gr
	Tel.: +30 (81) 391664   Fax: +30 (81) 391661

MORNING BREAK

----------------------------------------------------------------
Session VII: Misc.
----------------------------------------------------------------

Techniques and Architectures in Secure Facsimile Communications

	George Troullinos
	INTRACOM S.A.
	19.5 Km PEANIA - MARKOPOULO Ave.
	P.O. BOX 68, 190 02 PEANIA - ATTIKA - GREECE
	Tel:  (30-1) 6860698 - Fax: (30-1) 6645103
	Email: gtrou@Intranet.gr
	Digital Signal Processing

An Encryption Scheme for High Speed Passive Optical Networks

	D. Polemi, J. Koulouris, J. Angelopoulos
	John Angelopoulos
	National Technical University of Athens
	Electrical and Computer Science Dptm.
	GR15773 Polytechniopolis Zographou, Greece
	Fax: (+301) 772 2534
	e-mail: jangel@cs.ntua.gr, polemi@cs.ntua.gr


Broadband multimedia services design and implementation exploiting IN
features

	G. N. Prezerakos, C. D. Anagnostakis, I. S. Venieris
	National Technical University of Athens
	Department of Electrical Engineering and Computer Science
	Corresponding Author : Prof. I. S. Venieris
	Email: venieris@cs.ntua.gr
	Fax: +30 1 772 2534
	Phone: +30 1 772 2551
	Postal Address:
	Nationala Technical University of Athens
	Zografou Campus
	Electrical Engineering Building
	Heroon Polytechneiou 9
	Zografou, 15773
	Athens, GREECE

Error Correction Strategies for Wireless ATM

	Christian Schuler
	GMD FOKUS, Berlin, Germany
        email: schuler@fokus.gmd.de
        Phone: ++49 / (0)30 / 254 99 - 295
   	Fax: ++49 / (0)30 / 254 99 - 202
	Email: schuler@fokus.gmd.de
	Homepage: http://www.fokus.gmd.de/usr/schuler


----------------------------------------------------------------

----------------------------------------------------------------
Invited/Panel Session III: Global High Speed Communications - Ante Portas?
Panel Chair: Stefan Covaci
----------------------------------------------------------------

WORKSHOP ENDS


From rem-conf-request@es.net Thu Apr 17 13:21:16 1997 
Received: from precept.com (actually hydra.precept.com) by osi-west.es.net 
          with ESnet SMTP (PP); Thu, 17 Apr 1997 10:21:09 -0700
Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4) id JAA03154;
          Thu, 17 Apr 1997 09:55:09 -0700
Date: Thu, 17 Apr 1997 09:55:58 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
cc: "Michael E. Knappe" <mknappe@cisco.com>, voip-tech@vocaltec.com, 
    rem-conf@es.net
Subject: Re: Comfort noise payload types for RTP profile, VoIP
In-Reply-To: <335624AC.4682@cs.columbia.edu>
Message-ID: <Pine.WNT.3.95.970417095038.-183557A-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Henning,

> Thus, I believe the best realistic solution is to have codec-specific CN
> for G.723.1 and G.729 and use a simple white-noise energy indication (as
> for frame relay, measured in dBrn0, not the current/G.764 discretized
> version) for all other codecs.

This is fine with me.  Any codec may introduce its own codec-specific
CN technique so long as the indication is in-band.  My concern is just
that we achieve enough unification that only one codec-independent CN
"encoding" (and RTP payload type) need be defined.  My guess is that
the parties that need to concur are mostly on the VoIP and ITU
committees.
							-- Steve


From rem-conf-request@tmpmail.es.net Thu Apr 17 13:31:59 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Thu, 17 Apr 1997 10:31:56 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wHus1-0005VB-00; Thu, 17 Apr 1997 10:21:17 -0700
Date: Thu, 17 Apr 1997 09:55:58 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
cc: "Michael E. Knappe" <mknappe@cisco.com>, voip-tech@vocaltec.com, 
    rem-conf@es.net
Subject: Re: Comfort noise payload types for RTP profile, VoIP
In-Reply-To: <335624AC.4682@cs.columbia.edu>
Message-ID: <Pine.WNT.3.95.970417095038.-183557A-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-ID: <"LhTyC.0.WA5.DmbLp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Thu, 17 Apr 1997 10:21:17 -0700

Henning,

> Thus, I believe the best realistic solution is to have codec-specific CN
> for G.723.1 and G.729 and use a simple white-noise energy indication (as
> for frame relay, measured in dBrn0, not the current/G.764 discretized
> version) for all other codecs.

This is fine with me.  Any codec may introduce its own codec-specific
CN technique so long as the indication is in-band.  My concern is just
that we achieve enough unification that only one codec-independent CN
"encoding" (and RTP payload type) need be defined.  My guess is that
the parties that need to concur are mostly on the VoIP and ITU
committees.
							-- Steve



From rem-conf-request@es.net Thu Apr 17 16:29:29 1997 
Received: from seawind.bellcore.com by osi-west.es.net with ESnet SMTP (PP);
          Thu, 17 Apr 1997 13:29:23 -0700
Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) 
          id QAA27680; Thu, 17 Apr 1997 16:28:37 -0400
Date: Thu, 17 Apr 1997 16:28:37 -0400
From: huitema@bellcore.com (Christian Huitema)
Message-Id: <9704171628.ZM27678@seawind.bellcore.com>
In-Reply-To: Stephen Casner <casner@precept.com> "Re: Comfort noise payload types for RTP profile, VoIP" (Apr 17, 10:21am)
References: <Pine.WNT.3.95.970417095038.-183557A-100000@oak.precept.com>
X-Mailer: Z-Mail (3.2.1 10oct95)
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>, 
    Stephen Casner <casner@precept.com>
Subject: Re: Comfort noise payload types for RTP profile, VoIP
Cc: "Michael E. Knappe" <mknappe@cisco.com>, rem-conf@es.net, 
    voip-tech@vocaltec.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Steve,

Comfort noise is trivially achieved in PCM codecs by simply sending the
noise on line..  We can indeed do better but we have to take a close look
at what we exactly want, which can be either minimize the size of the
packets, minimizing the number of packets, or providing options at the
receiver.

In the first case, you want to send a "compressed noise" payload instead
of the regular payload.  No need to be very fancy, I am sure that this
group can easily produce a flexible specification of the encoding of
energy, pinkness, hurst factor and whatever else you want.  The only
problem is that we have to break the semi-accepted rule that says that one
session only uses one payload type, and that we also have to account for
the usage of different clock-rates by different payload.  But even that is
not difficult to solve -- we can for example define the noise payload to
contain an indication of the primary payload.

In the second case, you want to minimize the number of packets, which
means that you want to "install some state" in the receivers.  Again, a
noise payload type could achieve that.  We could for example make the rule
that if you dont received further packets after receiving a CN payload,
then it should gradually diminish the CN level.

The third case is important for devices that sum-up several voice signals,
e.g. conference bridges.  If you are summing up a voice signal and twenty
CN levels, you may want to somehow amplify the signal and reduce the
noise...  A specific payload for Cn would allow that.

Finally, a last advantage of an "additional" payload is that it would
provide a neat solution for other kinds of noises that you may well want
to carry in band.  DTMF comes to mind...

-- 
Christian Huitema

From rem-conf-request@tmpmail.es.net Thu Apr 17 16:43:27 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Thu, 17 Apr 1997 13:43:15 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wHxoB-00079w-00; Thu, 17 Apr 1997 13:29:31 -0700
Date: Thu, 17 Apr 1997 16:28:37 -0400
From: huitema@bellcore.com (Christian Huitema)
Message-Id: <9704171628.ZM27678@seawind.bellcore.com>
In-Reply-To: Stephen Casner <casner@precept.com> "Re: Comfort noise payload types for RTP profile, VoIP" (Apr 17, 10:21am)
References: <Pine.WNT.3.95.970417095038.-183557A-100000@oak.precept.com>
X-Mailer: Z-Mail (3.2.1 10oct95)
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>, 
    Stephen Casner <casner@precept.com>
Subject: Re: Comfort noise payload types for RTP profile, VoIP
Cc: "Michael E. Knappe" <mknappe@cisco.com>, rem-conf@es.net, 
    voip-tech@vocaltec.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Resent-Message-ID: <"eThaL3.0.3k6.hWeLp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Thu, 17 Apr 1997 13:29:31 -0700

Steve,

Comfort noise is trivially achieved in PCM codecs by simply sending the
noise on line..  We can indeed do better but we have to take a close look
at what we exactly want, which can be either minimize the size of the
packets, minimizing the number of packets, or providing options at the
receiver.

In the first case, you want to send a "compressed noise" payload instead
of the regular payload.  No need to be very fancy, I am sure that this
group can easily produce a flexible specification of the encoding of
energy, pinkness, hurst factor and whatever else you want.  The only
problem is that we have to break the semi-accepted rule that says that one
session only uses one payload type, and that we also have to account for
the usage of different clock-rates by different payload.  But even that is
not difficult to solve -- we can for example define the noise payload to
contain an indication of the primary payload.

In the second case, you want to minimize the number of packets, which
means that you want to "install some state" in the receivers.  Again, a
noise payload type could achieve that.  We could for example make the rule
that if you dont received further packets after receiving a CN payload,
then it should gradually diminish the CN level.

The third case is important for devices that sum-up several voice signals,
e.g. conference bridges.  If you are summing up a voice signal and twenty
CN levels, you may want to somehow amplify the signal and reduce the
noise...  A specific payload for Cn would allow that.

Finally, a last advantage of an "additional" payload is that it would
provide a neat solution for other kinds of noises that you may well want
to carry in band.  DTMF comes to mind...

-- 
Christian Huitema


From rem-conf-request@es.net Thu Apr 17 17:47:34 1997 
Received: from precept.com (actually hydra.precept.com) by osi-west.es.net 
          with ESnet SMTP (PP); Thu, 17 Apr 1997 14:47:28 -0700
Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4) id OAA04071;
          Thu, 17 Apr 1997 14:24:51 -0700
Date: Thu, 17 Apr 1997 14:25:38 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Christian Huitema <huitema@bellcore.com>
cc: Henning Schulzrinne <schulzrinne@cs.columbia.edu>, 
    "Michael E. Knappe" <mknappe@cisco.com>, rem-conf@es.net, 
    voip-tech@vocaltec.com
Subject: Re: Comfort noise payload types for RTP profile, VoIP
In-Reply-To: <9704171628.ZM27678@seawind.bellcore.com>
Message-ID: <Pine.WNT.3.95.970417134026.-183557D-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Christian,

> In the first case, you want to send a "compressed noise" payload instead
> of the regular payload.  No need to be very fancy, I am sure that this
> group can easily produce a flexible specification of the encoding of
> energy, pinkness, hurst factor and whatever else you want.

A couple of simple specifications have been made already.  I was not
necessarily asking that a new one be created, just to settle on one.

>  The only
> problem is that we have to break the semi-accepted rule that says that one
> session only uses one payload type, and that we also have to account for
> the usage of different clock-rates by different payload.

That extended discussion of rules a while back showed evidence of some
confusion and may have created more itself.  There's nothing wrong
with using more than one payload type in a session, e.g., to switch
among several audio encodings.  The argument was against multiplexing
audio and video in one session by switching payload types.

Changing clock rates may be a problem for the receiver.  But the
sample rate could be anything for a comfort noise encoding that simply
specified the noise amplitude.  Since many of the audio encodings use
an 8 kHz sampling clock, then perhaps defining a static payload type
for comfort noise at 8 kHz makes sense, but other encodings could use
a dynamic payload type to specify CN at the same clock rate as the
primary encoding, e.g., "CN/11025".

>  But even that is
> not difficult to solve -- we can for example define the noise payload to
> contain an indication of the primary payload.

I'm not sure about this idea.

> In the second case, you want to minimize the number of packets, which
> means that you want to "install some state" in the receivers.  Again, a
> noise payload type could achieve that.  We could for example make the rule
> that if you dont received further packets after receiving a CN payload,
> then it should gradually diminish the CN level.

That is the way I would expect CN to be used most often, although
perhaps leaving the level constant rather than diminishing it.

> Finally, a last advantage of an "additional" payload is that it would
> provide a neat solution for other kinds of noises that you may well want
> to carry in band.  DTMF comes to mind...

This has been specified in the VoIP document, too.
							-- Steve


From rem-conf-request@es.net Thu Apr 17 17:55:58 1997 
Received: from seawind.bellcore.com by osi-west.es.net with ESnet SMTP (PP);
          Thu, 17 Apr 1997 14:55:39 -0700
Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) 
          id RAA27725; Thu, 17 Apr 1997 17:55:09 -0400
Date: Thu, 17 Apr 1997 17:55:09 -0400
From: huitema@bellcore.com (Christian Huitema)
Message-Id: <9704171755.ZM27723@seawind.bellcore.com>
In-Reply-To: Stephen Casner <casner@precept.com> "Re: Comfort noise payload types for RTP profile, VoIP" (Apr 17, 2:25pm)
References: <Pine.WNT.3.95.970417134026.-183557D-100000@oak.precept.com>
X-Mailer: Z-Mail (3.2.1 10oct95)
To: Stephen Casner <casner@precept.com>, 
    Christian Huitema <huitema@bellcore.com>
Subject: Re: Comfort noise payload types for RTP profile, VoIP
Cc: Henning Schulzrinne <schulzrinne@cs.columbia.edu>, 
    "Michael E. Knappe" <mknappe@cisco.com>, rem-conf@es.net, 
    voip-tech@vocaltec.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

> This has been specified in the VoIP document, too.

Is the Voip document available for discussion ?  If we define payloads, it
should be in an open IETF environment...

-- 
Christian Huitema

From rem-conf-request@tmpmail.es.net Thu Apr 17 17:58:53 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Thu, 17 Apr 1997 14:58:42 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wHz1j-0000Dl-00; Thu, 17 Apr 1997 14:47:35 -0700
Date: Thu, 17 Apr 1997 14:25:38 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Christian Huitema <huitema@bellcore.com>
cc: Henning Schulzrinne <schulzrinne@cs.columbia.edu>, 
    "Michael E. Knappe" <mknappe@cisco.com>, rem-conf@es.net, 
    voip-tech@vocaltec.com
Subject: Re: Comfort noise payload types for RTP profile, VoIP
In-Reply-To: <9704171628.ZM27678@seawind.bellcore.com>
Message-ID: <Pine.WNT.3.95.970417134026.-183557D-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-ID: <"1orUG1.0.KD.tffLp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Thu, 17 Apr 1997 14:47:35 -0700

Christian,

> In the first case, you want to send a "compressed noise" payload instead
> of the regular payload.  No need to be very fancy, I am sure that this
> group can easily produce a flexible specification of the encoding of
> energy, pinkness, hurst factor and whatever else you want.

A couple of simple specifications have been made already.  I was not
necessarily asking that a new one be created, just to settle on one.

>  The only
> problem is that we have to break the semi-accepted rule that says that one
> session only uses one payload type, and that we also have to account for
> the usage of different clock-rates by different payload.

That extended discussion of rules a while back showed evidence of some
confusion and may have created more itself.  There's nothing wrong
with using more than one payload type in a session, e.g., to switch
among several audio encodings.  The argument was against multiplexing
audio and video in one session by switching payload types.

Changing clock rates may be a problem for the receiver.  But the
sample rate could be anything for a comfort noise encoding that simply
specified the noise amplitude.  Since many of the audio encodings use
an 8 kHz sampling clock, then perhaps defining a static payload type
for comfort noise at 8 kHz makes sense, but other encodings could use
a dynamic payload type to specify CN at the same clock rate as the
primary encoding, e.g., "CN/11025".

>  But even that is
> not difficult to solve -- we can for example define the noise payload to
> contain an indication of the primary payload.

I'm not sure about this idea.

> In the second case, you want to minimize the number of packets, which
> means that you want to "install some state" in the receivers.  Again, a
> noise payload type could achieve that.  We could for example make the rule
> that if you dont received further packets after receiving a CN payload,
> then it should gradually diminish the CN level.

That is the way I would expect CN to be used most often, although
perhaps leaving the level constant rather than diminishing it.

> Finally, a last advantage of an "additional" payload is that it would
> provide a neat solution for other kinds of noises that you may well want
> to carry in band.  DTMF comes to mind...

This has been specified in the VoIP document, too.
							-- Steve



From rem-conf-request@tmpmail.es.net Thu Apr 17 18:07:53 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Thu, 17 Apr 1997 15:07:49 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wHz9t-0000Vh-00; Thu, 17 Apr 1997 14:56:01 -0700
Date: Thu, 17 Apr 1997 17:55:09 -0400
From: huitema@bellcore.com (Christian Huitema)
Message-Id: <9704171755.ZM27723@seawind.bellcore.com>
In-Reply-To: Stephen Casner <casner@precept.com> "Re: Comfort noise payload types for RTP profile, VoIP" (Apr 17, 2:25pm)
References: <Pine.WNT.3.95.970417134026.-183557D-100000@oak.precept.com>
X-Mailer: Z-Mail (3.2.1 10oct95)
To: Stephen Casner <casner@precept.com>, 
    Christian Huitema <huitema@bellcore.com>
Subject: Re: Comfort noise payload types for RTP profile, VoIP
Cc: Henning Schulzrinne <schulzrinne@cs.columbia.edu>, 
    "Michael E. Knappe" <mknappe@cisco.com>, rem-conf@es.net, 
    voip-tech@vocaltec.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Resent-Message-ID: <"iluG81.0.iU.nnfLp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Thu, 17 Apr 1997 14:56:01 -0700

> This has been specified in the VoIP document, too.

Is the Voip document available for discussion ?  If we define payloads, it
should be in an open IETF environment...

-- 
Christian Huitema


From rem-conf-request@es.net Thu Apr 17 19:10:25 1997 
Received: from cs.columbia.edu by osi-west.es.net with ESnet SMTP (PP);
          Thu, 17 Apr 1997 16:10:18 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) 
          by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id TAA23038;
          Thu, 17 Apr 1997 19:10:13 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) 
          by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id TAA05435;
          Thu, 17 Apr 1997 19:10:08 -0400 (EDT)
Sender: hgs@cs.columbia.edu
Message-ID: <3356ADD0.3C77@cs.columbia.edu>
Date: Thu, 17 Apr 1997 19:10:08 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Christian Huitema <huitema@bellcore.com>
CC: Stephen Casner <casner@precept.com>, 
    Henning Schulzrinne <schulzrinne@opus.cs.columbia.edu>, 
    "Michael E. Knappe" <mknappe@cisco.com>, rem-conf@es.net, 
    voip-tech@vocaltec.com
Subject: Re: Comfort noise payload types for RTP profile, VoIP
References: <Pine.WNT.3.95.970417134026.-183557D-100000@oak.precept.com> <9704171755.ZM27723@seawind.bellcore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Christian Huitema wrote:
> 
> > This has been specified in the VoIP document, too.
> 
> Is the Voip document available for discussion ?  If we define payloads, it
> should be in an open IETF environment...

Yes, it's available from an ftp server. I took the version and converted
it to HTML for the Word-challenged like myself. It's on the RTP page.

> 
> --
> Christian Huitema

From rem-conf-request@tmpmail.es.net Thu Apr 17 19:24:42 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Thu, 17 Apr 1997 16:24:39 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wI0Jv-0001Rn-00; Thu, 17 Apr 1997 16:10:27 -0700
Sender: hgs@cs.columbia.edu
Message-ID: <3356ADD0.3C77@cs.columbia.edu>
Date: Thu, 17 Apr 1997 19:10:08 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Christian Huitema <huitema@bellcore.com>
CC: Stephen Casner <casner@precept.com>, 
    Henning Schulzrinne <schulzrinne@opus.cs.columbia.edu>, 
    "Michael E. Knappe" <mknappe@cisco.com>, rem-conf@es.net, 
    voip-tech@vocaltec.com
Subject: Re: Comfort noise payload types for RTP profile, VoIP
References: <Pine.WNT.3.95.970417134026.-183557D-100000@oak.precept.com> <9704171755.ZM27723@seawind.bellcore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"f7TTK3.0.-M1.ZtgLp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Thu, 17 Apr 1997 16:10:27 -0700

Christian Huitema wrote:
> 
> > This has been specified in the VoIP document, too.
> 
> Is the Voip document available for discussion ?  If we define payloads, it
> should be in an open IETF environment...

Yes, it's available from an ftp server. I took the version and converted
it to HTML for the Word-challenged like myself. It's on the RTP page.

> 
> --
> Christian Huitema


From rem-conf-request@es.net Thu Apr 17 19:43:59 1997 
Received: from cs.columbia.edu by osi-west.es.net with ESnet SMTP (PP);
          Thu, 17 Apr 1997 16:43:54 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) 
          by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id TAA24188;
          Thu, 17 Apr 1997 19:43:50 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) 
          by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id TAA05457;
          Thu, 17 Apr 1997 19:43:49 -0400 (EDT)
Sender: hgs@cs.columbia.edu
Message-ID: <3356B5B5.194C@cs.columbia.edu>
Date: Thu, 17 Apr 1997 19:43:49 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Stephen Casner <casner@precept.com>
CC: Christian Huitema <huitema@bellcore.com>, rem-conf@es.net, 
    voip-tech@vocaltec.com
Subject: Re: Comfort noise payload types for RTP profile, VoIP
References: <Pine.WNT.3.95.970417134026.-183557D-100000@oak.precept.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Casner wrote:
> 

> among several audio encodings.  The argument was against multiplexing
> audio and video in one session by switching payload types.

To amplify: it may be a bad idea (particularly for CN) to have the same
time instant be "covered" by two different RTP packets with different
encodings.

> 
> Changing clock rates may be a problem for the receiver.  But the
> sample rate could be anything for a comfort noise encoding that simply
> specified the noise amplitude.  Since many of the audio encodings use
> an 8 kHz sampling clock, then perhaps defining a static payload type
> for comfort noise at 8 kHz makes sense, but other encodings could use
> a dynamic payload type to specify CN at the same clock rate as the
> primary encoding, e.g., "CN/11025".

The current CN spec simply says that the receiver is to interpret
timestamps at the rate of the last non-CN codec. I don't think anything
else is necessary.

> 
> >  But even that is
> > not difficult to solve -- we can for example define the noise payload to
> > contain an indication of the primary payload.
> 
> I'm not sure about this idea.

I don't think this is necesssary.

> 
> > In the second case, you want to minimize the number of packets, which
> > means that you want to "install some state" in the receivers.  Again, a
> > noise payload type could achieve that.  We could for example make the rule
> > that if you dont received further packets after receiving a CN payload,
> > then it should gradually diminish the CN level.
> 
> That is the way I would expect CN to be used most often, although
> perhaps leaving the level constant rather than diminishing it.

If you diminish it, you have to indicate the 'duration' of the CN
covered by a packet if you want to avoid breathing of the background
noise. Indeed, one of the reasons for using CN rather than simply
repeating the last 'almost noise' packet at the receiver is that the
latter tends to introduce artifacts that 'hum' at packet rate. However,
in many cases, the receiver can and should simply measure the energy in
the last packet, determine that it looks noisy (the tricky part) and use
its energy for CN.

As I mentioned before, I don't think we need to develop a new spec for
more precise CN. If one were to transmit using, say, a high-quality
codec (better than G.729), one could presumably still use G.729 CN
during the pauses [using the regular G.729 PT], which would reflect the
noise characteristics better than just random white noise. This remains
to be proven (possible transition problems).

Henning

From rem-conf-request@tmpmail.es.net Thu Apr 17 19:52:55 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Thu, 17 Apr 1997 16:52:35 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wI0qO-0001wn-00; Thu, 17 Apr 1997 16:44:00 -0700
Sender: hgs@cs.columbia.edu
Message-ID: <3356B5B5.194C@cs.columbia.edu>
Date: Thu, 17 Apr 1997 19:43:49 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Stephen Casner <casner@precept.com>
CC: Christian Huitema <huitema@bellcore.com>, rem-conf@es.net, 
    voip-tech@vocaltec.com
Subject: Re: Comfort noise payload types for RTP profile, VoIP
References: <Pine.WNT.3.95.970417134026.-183557D-100000@oak.precept.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"gNw-J1.0.0r1.0NhLp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Thu, 17 Apr 1997 16:44:00 -0700

Stephen Casner wrote:
> 

> among several audio encodings.  The argument was against multiplexing
> audio and video in one session by switching payload types.

To amplify: it may be a bad idea (particularly for CN) to have the same
time instant be "covered" by two different RTP packets with different
encodings.

> 
> Changing clock rates may be a problem for the receiver.  But the
> sample rate could be anything for a comfort noise encoding that simply
> specified the noise amplitude.  Since many of the audio encodings use
> an 8 kHz sampling clock, then perhaps defining a static payload type
> for comfort noise at 8 kHz makes sense, but other encodings could use
> a dynamic payload type to specify CN at the same clock rate as the
> primary encoding, e.g., "CN/11025".

The current CN spec simply says that the receiver is to interpret
timestamps at the rate of the last non-CN codec. I don't think anything
else is necessary.

> 
> >  But even that is
> > not difficult to solve -- we can for example define the noise payload to
> > contain an indication of the primary payload.
> 
> I'm not sure about this idea.

I don't think this is necesssary.

> 
> > In the second case, you want to minimize the number of packets, which
> > means that you want to "install some state" in the receivers.  Again, a
> > noise payload type could achieve that.  We could for example make the rule
> > that if you dont received further packets after receiving a CN payload,
> > then it should gradually diminish the CN level.
> 
> That is the way I would expect CN to be used most often, although
> perhaps leaving the level constant rather than diminishing it.

If you diminish it, you have to indicate the 'duration' of the CN
covered by a packet if you want to avoid breathing of the background
noise. Indeed, one of the reasons for using CN rather than simply
repeating the last 'almost noise' packet at the receiver is that the
latter tends to introduce artifacts that 'hum' at packet rate. However,
in many cases, the receiver can and should simply measure the energy in
the last packet, determine that it looks noisy (the tricky part) and use
its energy for CN.

As I mentioned before, I don't think we need to develop a new spec for
more precise CN. If one were to transmit using, say, a high-quality
codec (better than G.729), one could presumably still use G.729 CN
during the pauses [using the regular G.729 PT], which would reflect the
noise characteristics better than just random white noise. This remains
to be proven (possible transition problems).

Henning


From rem-conf-request@es.net Thu Apr 17 22:12:47 1997 
Received: from precept.com (actually hydra.precept.com) by osi-west.es.net 
          with ESnet SMTP (PP); Thu, 17 Apr 1997 19:12:40 -0700
Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4) id SAA04799;
          Thu, 17 Apr 1997 18:41:13 -0700
Date: Thu, 17 Apr 1997 18:42:03 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
cc: Christian Huitema <huitema@bellcore.com>, rem-conf@es.net, 
    voip-tech@vocaltec.com
Subject: Re: Comfort noise payload types for RTP profile, VoIP
In-Reply-To: <3356B5B5.194C@cs.columbia.edu>
Message-ID: <Pine.WNT.3.95.970417183424.-113355D-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 17 Apr 1997, Henning Schulzrinne wrote:

> The current CN spec simply says that the receiver is to interpret
> timestamps at the rate of the last non-CN codec. I don't think anything
> else is necessary.

While that seems logical enough, it has been the case so far that a
given payload type implies a fixed RTP timestamp tick rate.  Making
the tick rate dependent on the previously active payload type is an
extension of the semantics of the payload format table, which is
likely to have an impact on implementations.  People should think
about this.
							-- Steve


From rem-conf-request@tmpmail.es.net Thu Apr 17 22:22:25 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Thu, 17 Apr 1997 19:22:21 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wI3AP-0003Kj-00; Thu, 17 Apr 1997 19:12:49 -0700
Date: Thu, 17 Apr 1997 18:42:03 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
cc: Christian Huitema <huitema@bellcore.com>, rem-conf@es.net, 
    voip-tech@vocaltec.com
Subject: Re: Comfort noise payload types for RTP profile, VoIP
In-Reply-To: <3356B5B5.194C@cs.columbia.edu>
Message-ID: <Pine.WNT.3.95.970417183424.-113355D-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-ID: <"fVn5W1.0.G83.XYjLp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Thu, 17 Apr 1997 19:12:49 -0700

On Thu, 17 Apr 1997, Henning Schulzrinne wrote:

> The current CN spec simply says that the receiver is to interpret
> timestamps at the rate of the last non-CN codec. I don't think anything
> else is necessary.

While that seems logical enough, it has been the case so far that a
given payload type implies a fixed RTP timestamp tick rate.  Making
the tick rate dependent on the previously active payload type is an
extension of the semantics of the payload format table, which is
likely to have an impact on implementations.  People should think
about this.
							-- Steve



From rem-conf-request@es.net Fri Apr 18 00:15:37 1997 
Received: from engr.orst.edu by osi-west.es.net with ESnet SMTP (PP);
          Thu, 17 Apr 1997 21:15:31 -0700
Received: from eel (eel.ENGR.ORST.EDU [128.193.55.69]) 
          by engr.orst.edu (8.8.5/8.8.5) with SMTP id VAA19763 
          for <rem-conf@es.net>; Thu, 17 Apr 1997 21:15:29 -0700 (PDT)
Received: from localhost by eel (SMI-8.6/ENGR-Client) id VAA27965;
          Thu, 17 Apr 1997 21:14:58 -0700
Date: Thu, 17 Apr 1997 21:14:58 -0700 (PDT)
From: Stephane Chatre <chatre@ENGR.ORST.EDU>
To: rem-conf@es.net
Subject: About RTP Timestamps
Message-ID: <Pine.SOL.3.95.970417211050.27531A-100000@eel.ENGR.ORST.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Something from RFC 1889 isn't too clear for me about RTP's timestamps.
RFC 1889 says that the beginning value is random. Now suppose a user on
one machine sends audio and video. Is the random origin going to be the
same for both audio and video streams, or is it going to be picked
separately?
That is: for the same user, will all of his streams bear synchronized
timestamps or not?

Thanks,

Stephane.

========================
Stephane Chatre                   Email: chatre@cs.orst.edu          
Department of Computer Science    Phone: (541) 737-5583  (office)     
Oregon State University			 (541) 757-3376   (home)      
                            
Life is what happens to you while you're busy making other plans.
                                        - John Lennon            


From rem-conf-request@tmpmail.es.net Fri Apr 18 00:21:40 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Thu, 17 Apr 1997 21:21:36 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wI55I-0004dv-00; Thu, 17 Apr 1997 21:15:40 -0700
Date: Thu, 17 Apr 1997 21:14:58 -0700 (PDT)
From: Stephane Chatre <chatre@ENGR.ORST.EDU>
To: rem-conf@es.net
Subject: About RTP Timestamps
Message-ID: <Pine.SOL.3.95.970417211050.27531A-100000@eel.ENGR.ORST.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-ID: <"Fnffp1.0.wM4.iLlLp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Thu, 17 Apr 1997 21:15:40 -0700

Something from RFC 1889 isn't too clear for me about RTP's timestamps.
RFC 1889 says that the beginning value is random. Now suppose a user on
one machine sends audio and video. Is the random origin going to be the
same for both audio and video streams, or is it going to be picked
separately?
That is: for the same user, will all of his streams bear synchronized
timestamps or not?

Thanks,

Stephane.

========================
Stephane Chatre                   Email: chatre@cs.orst.edu          
Department of Computer Science    Phone: (541) 737-5583  (office)     
Oregon State University			 (541) 757-3376   (home)      
                            
Life is what happens to you while you're busy making other plans.
                                        - John Lennon            



From rem-conf-request@es.net Fri Apr 18 02:54:14 1997 
Received: from nautilus.inmarsat.org by osi-west.es.net with ESnet SMTP (PP);
          Thu, 17 Apr 1997 23:53:48 -0700
Received: from mimesweeper.inmarsat.org 
          by nautilus.inmarsat.org (ElectricMail-MESSAGE-2.0) id HAA14421;
          Fri, 18 Apr 1997 07:53:41 +0100
From: Vicente_Delgado-Lopez@inmarsat.org
Received: from ima.inmarsat.org (161.30.207.26) 
          by mimesweeper.inmarsat.org (Integralis SMTPRS 1.51) with SMTP 
          id <B0000212804@mimesweeper.inmarsat.org>;
          Fri, 18 Apr 1997 07:31:58 +0100
Received: from ccMail by ima.inmarsat.org (IMA Internet Exchange 1.04b) 
          id 3571a5f0; Fri, 18 Apr 97 07:53:19 +0100
MIME-Version: 1.0
Date: Thu, 17 Apr 1997 19:14:34 +0100
Message-Id: <3571a5f0@inmarsat.org>
Subject: subscribe
To: rem-conf@es.net
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

     subscribe

From rem-conf-request@es.net Fri Apr 18 10:36:24 1997 
Received: from eken (actually eken.hv.se) by osi-west.es.net 
          with ESnet SMTP (PP); Fri, 18 Apr 1997 07:36:18 -0700
Received: from itn13.hv.se (itn13.hv.se [194.47.81.22]) by eken (8.6.9/8.6.9) 
          with SMTP id QAA21779 for <rem-conf@es.net>;
          Fri, 18 Apr 1997 16:33:37 +0200
Message-Id: <199704181433.QAA21779@eken>
X-Sender: heria92@mail.tufvan.hv.se
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 18 Apr 1997 16:35:23 +0000
To: rem-conf@es.net
From: heria92@tufvan.hv.se (hanna ericson)
Subject: multicastgroups
X-Mailer: <PC Eudora Version 1.4>


Hello,

We're working on a PIM project and have a few questions.
We're using win95 PCs and cisco routers on a labnetwork. The routers are 
configured to support PIM (we think).

1. Is there any available test PIM program that runs under win95? Where  
  can we find it?

2. How do we create a multicastgroup? And how do we join one?
   Shall we define the multicastgroups we'd like to create and join in an 
   access-list somewhere?

3. Can we just pick a class D address and use it as we please, or how    
   does it work?

4. Finally we'd like to know how larger multicast groups are created     
  and how to find them and join them.
   
 Thanks for your help!

/Hanna & Marie


From rem-conf-request@tmpmail.es.net Fri Apr 18 10:56:53 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Fri, 18 Apr 1997 07:56:49 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wIEm3-0002d4-00; Fri, 18 Apr 1997 07:36:27 -0700
Message-Id: <199704181433.QAA21779@eken>
X-Sender: heria92@mail.tufvan.hv.se
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 18 Apr 1997 16:35:23 +0000
To: rem-conf@es.net
From: heria92@tufvan.hv.se (hanna ericson)
Subject: multicastgroups
X-Mailer: <PC Eudora Version 1.4>
Resent-Message-ID: <"PLFku.0.zT2.hRuLp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Fri, 18 Apr 1997 07:36:27 -0700


Hello,

We're working on a PIM project and have a few questions.
We're using win95 PCs and cisco routers on a labnetwork. The routers are 
configured to support PIM (we think).

1. Is there any available test PIM program that runs under win95? Where  
  can we find it?

2. How do we create a multicastgroup? And how do we join one?
   Shall we define the multicastgroups we'd like to create and join in an 
   access-list somewhere?

3. Can we just pick a class D address and use it as we please, or how    
   does it work?

4. Finally we'd like to know how larger multicast groups are created     
  and how to find them and join them.
   
 Thanks for your help!

/Hanna & Marie



From rem-conf-request@es.net Fri Apr 18 11:00:50 1997 
Received: from brittany.cisco.com by osi-west.es.net with ESnet SMTP (PP);
          Fri, 18 Apr 1997 08:00:33 -0700
Received: from mknappe-pc.cisco.com (sj-dial-2-8.cisco.com [171.68.179.137]) 
          by brittany.cisco.com (8.6.12/8.6.5) with SMTP id HAA16488;
          Fri, 18 Apr 1997 07:59:20 -0700
Message-Id: <2.2.32.19970418145022.00dee030@brittany.cisco.com>
X-Sender: mknappe@brittany.cisco.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 18 Apr 1997 07:50:22 -0700
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
From: "Michael E. Knappe" <mknappe@cisco.com>
Subject: Re: Comfort noise payload types for RTP profile, VoIP
Cc: Stephen Casner <casner@precept.com>, 
    Christian Huitema <huitema@bellcore.com>, rem-conf@es.net, 
    voip-tech@vocaltec.com

At 07:43 PM 4/17/97 -0400, you wrote:
>Stephen Casner wrote:
>> 
>
>> among several audio encodings.  The argument was against multiplexing
>> audio and video in one session by switching payload types.
>
>To amplify: it may be a bad idea (particularly for CN) to have the same
>time instant be "covered" by two different RTP packets with different
>encodings.
>
>> 
>> Changing clock rates may be a problem for the receiver.  But the
>> sample rate could be anything for a comfort noise encoding that simply
>> specified the noise amplitude.  Since many of the audio encodings use
>> an 8 kHz sampling clock, then perhaps defining a static payload type
>> for comfort noise at 8 kHz makes sense, but other encodings could use
>> a dynamic payload type to specify CN at the same clock rate as the
>> primary encoding, e.g., "CN/11025".
>
>The current CN spec simply says that the receiver is to interpret
>timestamps at the rate of the last non-CN codec. I don't think anything
>else is necessary.
>
>> 
>> >  But even that is
>> > not difficult to solve -- we can for example define the noise payload to
>> > contain an indication of the primary payload.
>> 
>> I'm not sure about this idea.
>
>I don't think this is necesssary.
>
>> 
>> > In the second case, you want to minimize the number of packets, which
>> > means that you want to "install some state" in the receivers.  Again, a
>> > noise payload type could achieve that.  We could for example make the rule
>> > that if you dont received further packets after receiving a CN payload,
>> > then it should gradually diminish the CN level.
>> 
>> That is the way I would expect CN to be used most often, although
>> perhaps leaving the level constant rather than diminishing it.
>
>If you diminish it, you have to indicate the 'duration' of the CN
>covered by a packet if you want to avoid breathing of the background
>noise. Indeed, one of the reasons for using CN rather than simply
>repeating the last 'almost noise' packet at the receiver is that the
>latter tends to introduce artifacts that 'hum' at packet rate. However,
>in many cases, the receiver can and should simply measure the energy in
>the last packet, determine that it looks noisy (the tricky part) and use
>its energy for CN.
>
>As I mentioned before, I don't think we need to develop a new spec for
>more precise CN. If one were to transmit using, say, a high-quality
>codec (better than G.729), one could presumably still use G.729 CN
>during the pauses [using the regular G.729 PT], which would reflect the
>noise characteristics better than just random white noise. This remains
>to be proven (possible transition problems).


If a codec like G.729 or G.723.1 with its own silence detection and comfort
noise mechanism is already in known use on a call, either the transmitter
should elect not to use the CN payload type indicator, or it should be
interpreted at the receiver end as a codec-independent silence indicator to
be used as it sees fit (statistics?). The receiver should not have a problem
NOT using the CN payload type in the audio stream when other codec-specific
mechanisms are in use.

Mike

>
>Henning
>
>
____________________________________________________________________________

Michael Knappe                ||        ||                     cisco Systems
Partners Engineering         .||.      .||.                       Building E
                            .||||.    .||||.           170 West Tasman Drive
408-527-3849            ...||||||||..||||||||...         San Jose, CA  95134
408-526-4287  (fax)      c i s c o S y s t e m s           mknappe@cisco.com
____________________________________________________________________________



From rem-conf-request@tmpmail.es.net Fri Apr 18 11:14:03 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Fri, 18 Apr 1997 08:13:46 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wIF9t-00036R-00; Fri, 18 Apr 1997 08:01:05 -0700
Message-Id: <2.2.32.19970418145022.00dee030@brittany.cisco.com>
X-Sender: mknappe@brittany.cisco.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 18 Apr 1997 07:50:22 -0700
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
From: "Michael E. Knappe" <mknappe@cisco.com>
Subject: Re: Comfort noise payload types for RTP profile, VoIP
Cc: Stephen Casner <casner@precept.com>, 
    Christian Huitema <huitema@bellcore.com>, rem-conf@es.net, 
    voip-tech@vocaltec.com
Resent-Message-ID: <"rB9Kn.0.Qw2.nouLp"@mail1>
Resent-From: rem-conf@tmpmail.es.net
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list
Resent-Sender: rem-conf-request@tmpmail.es.net
Resent-To: rem-conf-dist@tmpmail.es.net
Resent-Date: Fri, 18 Apr 1997 08:01:05 -0700

At 07:43 PM 4/17/97 -0400, you wrote:
>Stephen Casner wrote:
>> 
>
>> among several audio encodings.  The argument was against multiplexing
>> audio and video in one session by switching payload types.
>
>To amplify: it may be a bad idea (particularly for CN) to have the same
>time instant be "covered" by two different RTP packets with different
>encodings.
>
>> 
>> Changing clock rates may be a problem for the receiver.  But the
>> sample rate could be anything for a comfort noise encoding that simply
>> specified the noise amplitude.  Since many of the audio encodings use
>> an 8 kHz sampling clock, then perhaps defining a static payload type
>> for comfort noise at 8 kHz makes sense, but other encodings could use
>> a dynamic payload type to specify CN at the same clock rate as the
>> primary encoding, e.g., "CN/11025".
>
>The current CN spec simply says that the receiver is to interpret
>timestamps at the rate of the last non-CN codec. I don't think anything
>else is necessary.
>
>> 
>> >  But even that is
>> > not difficult to solve -- we can for example define the noise payload to
>> > contain an indication of the primary payload.
>> 
>> I'm not sure about this idea.
>
>I don't think this is necesssary.
>
>> 
>> > In the second case, you want to minimize the number of packets, which
>> > means that you want to "install some state" in the receivers.  Again, a
>> > noise payload type could achieve that.  We could for example make the rule
>> > that if you dont received further packets after receiving a CN payload,
>> > then it should gradually diminish the CN level.
>> 
>> That is the way I would expect CN to be used most often, although
>> perhaps leaving the level constant rather than diminishing it.
>
>If you diminish it, you have to indicate the 'duration' of the CN
>covered by a packet if you want to avoid breathing of the background
>noise. Indeed, one of the reasons for using CN rather than simply
>repeating the last 'almost noise' packet at the receiver is that the
>latter tends to introduce artifacts that 'hum' at packet rate. However,
>in many cases, the receiver can and should simply measure the energy in
>the last packet, determine that it looks noisy (the tricky part) and use
>its energy for CN.
>
>As I mentioned before, I don't think we need to develop a new spec for
>more precise CN. If one were to transmit using, say, a high-quality
>codec (better than G.729), one could presumably still use G.729 CN
>during the pauses [using the regular G.729 PT], which would reflect the
>noise characteristics better than just random white noise. This remains
>to be proven (possible transition problems).


If a codec like G.729 or G.723.1 with its own silence detection and comfort
noise mechanism is already in known use on a call, either the transmitter
should elect not to use the CN payload type indicator, or it should be
interpreted at the receiver end as a codec-independent silence indicator to
be used as it sees fit (statistics?). The receiver should not have a problem
NOT using the CN payload type in the audio stream when other codec-specific
mechanisms are in use.

Mike

>
>Henning
>
>
____________________________________________________________________________

Michael Knappe                ||        ||                     cisco Systems
Partners Engineering         .||.      .||.                       Building E
                            .||||.    .||||.           170 West Tasman Drive
408-527-3849            ...||||||||..||||||||...         San Jose, CA  95134
408-526-4287  (fax)      c i s c o S y s t e m s           mknappe@cisco.com
____________________________________________________________________________




From rem-conf-request@es.net Fri Apr 18 13:25:35 1997 
Received: from zephyr.isi.edu by osi-west.es.net with ESnet SMTP (PP);
          Fri, 18 Apr 1997 10:25:29 -0700
Received: from fra-e.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) 
          id <AA18635>; Fri, 18 Apr 1997 10:25:14 -0700
Message-Id: <199704181725.AA18635@zephyr.isi.edu>
X-Mailer: exmh version 1.6.7 5/3/96
To: heria92@www.tufvan.hv.se (hanna ericson)
Cc: rem-conf@es.net
Subject: Re: multicastgroups
In-Reply-To: Your message of "Fri, 18 Apr 1997 16:35:23 GMT." <199704181433.QAA21779@eken>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 18 Apr 97 10:26:27 PST
From: Daniel Zappala <daniel@ISI.EDU>


Try looking at

	http://www.research.microsoft.com/research/BARC/mbone/

Daniel Zappala
daniel@isi.edu

> 
> Hello,
> 
> We're working on a PIM project and have a few questions.
> We're using win95 PCs and cisco routers on a labnetwork. The routers are 
> configured to support PIM (we think).
> 
> 1. Is there any available test PIM program that runs under win95? Where  
>   can we find it?
> 
> 2. How do we create a multicastgroup? And how do we join one?
>    Shall we define the multicastgroups we'd like to create and join in an 
>    access-list somewhere?
> 
> 3. Can we just pick a class D address and use it as we please, or how    
>    does it work?
> 
> 4. Finally we'd like to know how larger multicast groups are created     
>   and how to find them and join them.
>    
>  Thanks for your help!
> 
> /Hanna & Marie
> 
> 



From rem-conf-request@tmpmail.es.net Fri Apr 18 13:36:44 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Fri, 18 Apr 1997 10:36:20 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wIHPk-0004j4-00; Fri, 18 Apr 1997 10:25:36 -0700
Message-Id: <199704181725.AA18635@zephyr.isi.edu>
X-Mailer: exmh version 1.6.7 5/3/96
To: heria92@www.tufvan.hv.se (hanna ericson)
Cc: rem-conf@es.net
Subject: Re: multicastgroups
In-Reply-To: Your message of "Fri, 18 Apr 1997 16:35:23 GMT." <199704181433.QAA21779@eken>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 18 Apr 97 10:26:27 PST
From: Daniel Zappala <daniel@ISI.EDU>
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


Try looking at

	http://www.research.microsoft.com/research/BARC/mbone/

Daniel Zappala
daniel@isi.edu

> 
> Hello,
> 
> We're working on a PIM project and have a few questions.
> We're using win95 PCs and cisco routers on a labnetwork. The routers are 
> configured to support PIM (we think).
> 
> 1. Is there any available test PIM program that runs under win95? Where  
>   can we find it?
> 
> 2. How do we create a multicastgroup? And how do we join one?
>    Shall we define the multicastgroups we'd like to create and join in an 
>    access-list somewhere?
> 
> 3. Can we just pick a class D address and use it as we please, or how    
>    does it work?
> 
> 4. Finally we'd like to know how larger multicast groups are created     
>   and how to find them and join them.
>    
>  Thanks for your help!
> 
> /Hanna & Marie
> 
> 




From rem-conf-request@es.net Fri Apr 18 13:41:53 1997 
Received: from zephyr.isi.edu by osi-west.es.net with ESnet SMTP (PP);
          Fri, 18 Apr 1997 10:41:47 -0700
Received: from fra-e.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) 
          id <AA19932>; Fri, 18 Apr 1997 10:41:46 -0700
Message-Id: <199704181741.AA19932@zephyr.isi.edu>
X-Mailer: exmh version 1.6.7 5/3/96
To: rem-conf@es.net
Subject: Re: multicastgroups
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 18 Apr 97 10:43:00 PST
From: Daniel Zappala <daniel@ISI.EDU>


For Windows '95 versions of MBONE tools, try looking at

	http://www.research.microsoft.com/research/BARC/mbone/

This page also includes pointers to other multicast information
to answer some basic questions you have.

Daniel Zappala
daniel@isi.edu

> 
> Hello,
> 
> We're working on a PIM project and have a few questions...

[Rest of article deleted]



From rem-conf-request@tmpmail.es.net Fri Apr 18 13:47:03 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Fri, 18 Apr 1997 10:46:59 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wIHfW-00059Z-00; Fri, 18 Apr 1997 10:41:54 -0700
Message-Id: <199704181741.AA19932@zephyr.isi.edu>
X-Mailer: exmh version 1.6.7 5/3/96
To: rem-conf@es.net
Subject: Re: multicastgroups
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 18 Apr 97 10:43:00 PST
From: Daniel Zappala <daniel@ISI.EDU>
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


For Windows '95 versions of MBONE tools, try looking at

	http://www.research.microsoft.com/research/BARC/mbone/

This page also includes pointers to other multicast information
to answer some basic questions you have.

Daniel Zappala
daniel@isi.edu

> 
> Hello,
> 
> We're working on a PIM project and have a few questions...

[Rest of article deleted]




From rem-conf-request@es.net Fri Apr 18 18:42:10 1997 
Received: from precept.com (actually hydra.precept.com) by osi-west.es.net 
          with ESnet SMTP (PP); Fri, 18 Apr 1997 15:41:58 -0700
Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4) id PAA07178;
          Fri, 18 Apr 1997 15:39:09 -0700
Date: Thu, 17 Apr 1997 15:38:07 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Stephane Chatre <chatre@ENGR.ORST.EDU>
cc: rem-conf@es.net
Subject: Re: About RTP Timestamps
In-Reply-To: <Pine.SOL.3.95.970417211050.27531A-100000@eel.ENGR.ORST.EDU>
Message-ID: <Pine.WNT.3.95.970417153519.-110795E-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

> Something from RFC 1889 isn't too clear for me about RTP's timestamps.
> RFC 1889 says that the beginning value is random. Now suppose a user on
> one machine sends audio and video. Is the random origin going to be the
> same for both audio and video streams, or is it going to be picked
> separately?
> That is: for the same user, will all of his streams bear synchronized
> timestamps or not?

Generally not.  The streams may have timestamps ticking at different
rates, so starting them at the same value is not all that helpful.

Synchronization of the streams may be achieved through the
relationship of RTP timestamps to a common reference clock in RTCP
sender reports for each stream.
							-- Steve


From rem-conf-request@tmpmail.es.net Fri Apr 18 18:51:19 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Fri, 18 Apr 1997 15:50:57 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wIMM9-0000Cz-00; Fri, 18 Apr 1997 15:42:13 -0700
Date: Thu, 17 Apr 1997 15:38:07 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Stephane Chatre <chatre@ENGR.ORST.EDU>
cc: rem-conf@es.net
Subject: Re: About RTP Timestamps
In-Reply-To: <Pine.SOL.3.95.970417211050.27531A-100000@eel.ENGR.ORST.EDU>
Message-ID: <Pine.WNT.3.95.970417153519.-110795E-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

> Something from RFC 1889 isn't too clear for me about RTP's timestamps.
> RFC 1889 says that the beginning value is random. Now suppose a user on
> one machine sends audio and video. Is the random origin going to be the
> same for both audio and video streams, or is it going to be picked
> separately?
> That is: for the same user, will all of his streams bear synchronized
> timestamps or not?

Generally not.  The streams may have timestamps ticking at different
rates, so starting them at the same value is not all that helpful.

Synchronization of the streams may be achieved through the
relationship of RTP timestamps to a common reference clock in RTCP
sender reports for each stream.
							-- Steve



From rem-conf-request@es.net Fri Apr 18 19:51:40 1997 
Received: from nobozo.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP);
          Fri, 18 Apr 1997 16:51:26 -0700
Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) 
          by nobozo.CS.Berkeley.EDU (8.6.10/8.6.3) with SMTP id QAA30120;
          Fri, 18 Apr 1997 16:51:21 -0700
Date: Fri, 18 Apr 1997 16:51:21 -0700
Message-Id: <199704182351.QAA30120@nobozo.CS.Berkeley.EDU>
X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU
X-Mailer: Windows Eudora Version 2.1.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: 298-list@bmrc.Berkeley.EDU, rem-conf@es.net
From: Jerrlyn Iwata <jerrlyn@postgres.Berkeley.EDU>
Subject: Berkeley Multimedia & Graphics Seminar

                Berkeley Multimedia and Graphics Seminar 
        (Wednesday April 23, 1997 12:30-2:00 PDT 405 Soda Hall) 

        "Network Architecture Revisited: the case for datagrams" 

                             Lixia Zhang 
                  UCLA Computer Science Department 

Over the last several years the explosive growth of the Internet shows that
the Internet architecture, a design that uses datagrams as the basic
building blocks, has achieved an unprecedented success--is it coincidental
or consequential? Many people envision that the Internet would grow to the
ubiquitous telecommunication infrastructure of the next century; yet many
others believe that the current datagram architecture would gradually be
replaced by the virtual-circuit based ATM technology in order to support
realtime and
multimedia applications. In this talk I'll review historical motivations for
packet-switching, and revisit some basic issues of what is datagrams and why
datagrams, as an input to drawing the blueprint of the future. 

Acknowledgment: Thanks to Steve Deering for contributing the title of this talk.
--------------------------------------------------------------------------------
This seminar will be broadcast on the Internet MBONE. The broadcast will
begin at 12:40 PDT (GMT - 8 hrs). See sdr or http://bmrc.berkeley.edu/298
for instructions on setting up, connecting to, and operating the MBONE tools.

Please direct all technical questions to davesimp@cs.berkeley.edu



From rem-conf-request@es.net Fri Apr 18 20:03:16 1997 
Received: from piraya.electrum.kth.se by osi-west.es.net with ESnet SMTP (PP);
          Fri, 18 Apr 1997 17:03:09 -0700
Received: from drum.it.kth.se (drum.it.kth.se [130.237.213.23]) 
          by piraya.electrum.kth.se (8.7.3/8.7.3) with ESMTP id CAA20252;
          Sat, 19 Apr 1997 02:02:55 +0200 (MET DST)
Message-Id: <199704190002.CAA20252@piraya.electrum.kth.se>
To: casner@precept.com
Cc: chatre@ENGR.ORST.EDU, rem-conf@es.net
From: Magnus Danielson <magda@it.kth.se>
Subject: Re: About RTP Timestamps
In-Reply-To: Your message of "Thu, 17 Apr 1997 15:38:07 -0700 ()"
References: <Pine.WNT.3.95.970417153519.-110795E-100000@oak.precept.com>
X-Mailer: Mew version 1.06 on Emacs 19.34.1
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Date: Sat, 19 Apr 1997 02:02:37 +0200
Sender: e93_mda@drum.it.kth.se

>>>>> "SC" == Stephen Casner <casner@precept.com> writes:

 >> Something from RFC 1889 isn't too clear for me about RTP's timestamps.
 >> RFC 1889 says that the beginning value is random. Now suppose a user on
 >> one machine sends audio and video. Is the random origin going to be the
 >> same for both audio and video streams, or is it going to be picked
 >> separately?
 >> That is: for the same user, will all of his streams bear synchronized
 >> timestamps or not?

 SC> Generally not.  The streams may have timestamps ticking at different
 SC> rates, so starting them at the same value is not all that helpful.

 SC> Synchronization of the streams may be achieved through the
 SC> relationship of RTP timestamps to a common reference clock in RTCP
 SC> sender reports for each stream.
 SC> 							-- Steve

The resynchronisation machinery necessary in order to get multiple
streams to apear in sync is not well stated in RFC 1889, it's just
assumed to be there and this fact makes it up a lack of reference to
those approaching the topic as beginners compared to those allready
knows the full context. It would be good if an document existed that
does more clearly explain the machinery and also explains what RTP
provides as a tool in this machinery.

Also, to my knowledge is there no standard way to resynchronise
between diffrent streams on both single and multiple machines, this is
as far as I know only done in propritary solutions. A standard
resynchronisation method would allow us to resync picture and sound
(and whatever) with the users choise of sound tool and video tool,
they do not _need_ to be the same software package. But then, one can
allways dream.

As allways, I migth be wrong, so please feel free to correct me and
put my attention on material stating otherwise.

Respectfully,
Magnus



From rem-conf-request@tmpmail.es.net Fri Apr 18 20:04:13 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Fri, 18 Apr 1997 17:03:57 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wINRQ-0001Cm-00; Fri, 18 Apr 1997 16:51:44 -0700
Date: Fri, 18 Apr 1997 16:51:21 -0700
Message-Id: <199704182351.QAA30120@nobozo.CS.Berkeley.EDU>
X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU
X-Mailer: Windows Eudora Version 2.1.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: 298-list@bmrc.Berkeley.EDU, rem-conf@es.net
From: Jerrlyn Iwata <jerrlyn@postgres.Berkeley.EDU>
Subject: Berkeley Multimedia & Graphics Seminar
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

                Berkeley Multimedia and Graphics Seminar 
        (Wednesday April 23, 1997 12:30-2:00 PDT 405 Soda Hall) 

        "Network Architecture Revisited: the case for datagrams" 

                             Lixia Zhang 
                  UCLA Computer Science Department 

Over the last several years the explosive growth of the Internet shows that
the Internet architecture, a design that uses datagrams as the basic
building blocks, has achieved an unprecedented success--is it coincidental
or consequential? Many people envision that the Internet would grow to the
ubiquitous telecommunication infrastructure of the next century; yet many
others believe that the current datagram architecture would gradually be
replaced by the virtual-circuit based ATM technology in order to support
realtime and
multimedia applications. In this talk I'll review historical motivations for
packet-switching, and revisit some basic issues of what is datagrams and why
datagrams, as an input to drawing the blueprint of the future. 

Acknowledgment: Thanks to Steve Deering for contributing the title of this talk.
--------------------------------------------------------------------------------
This seminar will be broadcast on the Internet MBONE. The broadcast will
begin at 12:40 PDT (GMT - 8 hrs). See sdr or http://bmrc.berkeley.edu/298
for instructions on setting up, connecting to, and operating the MBONE tools.

Please direct all technical questions to davesimp@cs.berkeley.edu




From rem-conf-request@tmpmail.es.net Fri Apr 18 20:05:39 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Fri, 18 Apr 1997 17:05:36 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wINco-0001KW-00; Fri, 18 Apr 1997 17:03:30 -0700
Message-Id: <199704190002.CAA20252@piraya.electrum.kth.se>
To: casner@precept.com
Cc: chatre@ENGR.ORST.EDU, rem-conf@es.net
From: Magnus Danielson <magda@it.kth.se>
Subject: Re: About RTP Timestamps
In-Reply-To: Your message of "Thu, 17 Apr 1997 15:38:07 -0700 ()"
References: <Pine.WNT.3.95.970417153519.-110795E-100000@oak.precept.com>
X-Mailer: Mew version 1.06 on Emacs 19.34.1
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Date: Sat, 19 Apr 1997 02:02:37 +0200
Sender: e93_mda@drum.it.kth.se
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

>>>>> "SC" == Stephen Casner <casner@precept.com> writes:

 >> Something from RFC 1889 isn't too clear for me about RTP's timestamps.
 >> RFC 1889 says that the beginning value is random. Now suppose a user on
 >> one machine sends audio and video. Is the random origin going to be the
 >> same for both audio and video streams, or is it going to be picked
 >> separately?
 >> That is: for the same user, will all of his streams bear synchronized
 >> timestamps or not?

 SC> Generally not.  The streams may have timestamps ticking at different
 SC> rates, so starting them at the same value is not all that helpful.

 SC> Synchronization of the streams may be achieved through the
 SC> relationship of RTP timestamps to a common reference clock in RTCP
 SC> sender reports for each stream.
 SC> 							-- Steve

The resynchronisation machinery necessary in order to get multiple
streams to apear in sync is not well stated in RFC 1889, it's just
assumed to be there and this fact makes it up a lack of reference to
those approaching the topic as beginners compared to those allready
knows the full context. It would be good if an document existed that
does more clearly explain the machinery and also explains what RTP
provides as a tool in this machinery.

Also, to my knowledge is there no standard way to resynchronise
between diffrent streams on both single and multiple machines, this is
as far as I know only done in propritary solutions. A standard
resynchronisation method would allow us to resync picture and sound
(and whatever) with the users choise of sound tool and video tool,
they do not _need_ to be the same software package. But then, one can
allways dream.

As allways, I migth be wrong, so please feel free to correct me and
put my attention on material stating otherwise.

Respectfully,
Magnus




From rem-conf-request@es.net Sun Apr 20 16:00:30 1997 
Received: from dworkin.wustl.edu by osi-west.es.net with ESnet SMTP (PP);
          Sun, 20 Apr 1997 13:00:18 -0700
Received: (from milind@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) 
          id PAA27364 for rem-conf@es.net; Sun, 20 Apr 1997 15:02:44 -0500
Date: Sun, 20 Apr 1997 15:02:44 -0500
From: "Milind M. Buddhikot" <milind@dworkin.wustl.edu>
Message-Id: <199704202002.PAA27364@dworkin.wustl.edu>
To: rem-conf@es.net
Subject: NOSSDAV97 Advance Program + Registration Announcement


                 The 7th International Workshop on
  Network and Operating System Support for Digital Audio and Video 

                          NOSSDAV'97

                    St. Louis, Missouri, USA

                         May 19-21, 1997


Registrations for NOSSDAV'97 are now being accepted.

The 7th International Workshop on Network and Operating Systems Support
for Digital Audio and Video (NOSSDAV 97) is the international workshop
concerned with state of the art technology in networking and operating
system support for multimedia systems.  For seven years, NOSSDAV has
proven to be an outstanding forum for researchers involved in building
innovative multimedia systems, networks and applications on both the
research and industrial front. Other topics that will be examined include
"middleware" for multimedia, media toolkits, mobile communications,
Virtual Reality (VR), real-time systems, software agents, digital libraries,
and other digital media besides audio and video.

A key aspect of the workshop is that it provides extensive discussion
periods during which attendees can informally discuss their current
work and future research directions.  Traditionally, NOSSDAV has
emphasized on high quality experimental research that prototypes
systems to explore innovative solutions to the problems in the diverse
areas of multimedia computing. NOSSDAV97 will continue this tradition.

A sample of the  sessions to be held at the workshop include:
	Multicast for Multimedia
	Networking: Packet Scheduling and Integrated Services
	Multimedia-on-Demand (MOD) Servers and Services
	Smoothing and Scaling on Endsystems
	Mobility and Wireless
	Operating System Optimizations
	Middleware for Multimedia

To maintain the atmosphere of a small intense workshop, attendance is
once again being limited to 80.

Spots at the workshop are being reserved for one author per paper and
Program Committee members until April 10th. All other registration requests
will be accepted on a first come first served basis. After April 10th any
other requests that previously could not be immediately accepted will be
confirmed if space is available.

Presenting Authors and PC Members should register as soon as possible!!

On line registration and workshop program information can be accessed
>from the NOSSDAV97 web page:
	http://www.arl.wustl.edu/arl/NOSSDAV97/

The workshop will be held at Innsbrook Estates. Located approximately 45
minutes from the St. Louis airport, Innsbrook Estates has everything you
would like in a resort: 18-hole golf course, 18-hole miniature
course, swimming pool, a 150 acre lake, sailing, fishing,
swimming, sand beaches, fitness center, lighted tennis courts,
volleyball courts, horse back riding, full conference facilities, etc.


Send inquiries to:

	NOSSDAV97@arl.wustl.edu


	ATTN: NOSSDAV97
	Department of Computer Science/ARL
	Campus Box 1045
	Washington University
	One Brookings Drive
	St. Louis MO 63130, USA

	Tele: 1 314 935 7534
	Fax: 1 314 935 7302



                                 NOSSDAV '97
                                  Schedule

 Sunday, May 18, 1997

 16:00-19:00 Conference Registration
 19:00-21:30 Informal Dinner ???

 Monday, May 19, 1997

 7:30-8:30   Breakfast Buffet
 8:30-9:00   Introductions and Welcome

                  Christopher I. Byrnes
                       Dean of the School of Engineering and Applied
                       Science
                       Washington University

                  Workshop Chairs
                       Guru Parulkar
                       John DeHart

 9:00-10:30  Session I "Multimedia-on-Demand (MOD) Servers and Services"
                  Session Chair: Derek McAuley, Univ of Glasgow, UK

                * Design and Implementation of Video Server for Mixed-rate
                  Streams
                       J. Nishikawa, I. Okabayashi, Y. Mori, S. Sasaki, M.
                       Migita, Y. Obayashi, S. Furuya and K. Kaneko.
                       Matsushita Electric Industrial Co.
                * Random RAIDs with Selective Exploitation of Redundancy
                  for High Performance Video Servers
                       Y. Birk. Technion - Israel Inst. of Technology.
                * Efficient Striping Techniques for Multimedia File Servers
                       P. Shenoy, and H. Vin. University of Texas.

 10:30-11:00 Break
 11:00-12:30 Session II "Middleware for Multimedia Applications"
                  Session Chair: Steve McCanne

		* Toward a Common Infrastructure for
		  Multimedia-Networking Middleware  
			S. McCanne et al, 
			University of California,Berkeley 

                * An Extensible Framework for RTP-based Multimedia
		  Applications
			John Du, Dave Putzolu, Intel Corporation

                * Network Filters for Active Movie
			Mike Clark, Thomas Pfenning, Microsoft

 12:30-13:30 Lunch
 13:30-15:00 Session III "Networking"
                  Session Chair: KK Ramakrishnan, AT&T Research

                * A Comprehensive Multimedia Control Architecture for the
                  Internet
                       H. Schulzrinne. Columbia University.
                * Environments for Active Networks
                       R. Sharma, S. Keshav, M. Wu and L. Wu. Cornell
                       Univeristy.
                * WANDS: Wide-Area Network Delay Simulator
                       M. Borella & A. Sears. DePaul University.

SHORT PAPER:
                * A Virtual Network Service for Integrated-Services
                  Internetworks
                       L. Delgrossi and Domenico Ferrari. Unversita
                       Cattolica.

 15:00-15:30 Break
 15:30-17:00 Session IV "Operating System Optimizations"
                  Session Chair: Hide Tokuda, Keio Univ, Japan

                * Evaluation of Data Passing and Scheduling Avoidance
                       J. Brustoloni and P. Steenkiste. Carnegie Mellon
                       University.
                * User-Safe Devices for True End-to-End QoS
                       I. Pratt. University of Cambridge.
                * A Fresh Approach to File System Quality of Service
                       P. Barham. University of Cambridge.

 17:00-18:00 Break
 18:00-20:00 Banquet
 20:00-21:00 PC/Planning Meeting

 Tuesday, May 20, 1997

 7:30-8:30   Breakfast Buffet
 8:30-10:00  Session V "Mobility and Wireless"
                  Session Chair: Doug Shepherd, University of Lancaster, UK

                * Mobile Filters: Delivering Scaled Media to Mobile Devices
                       A. Balachandran and A. Campbell
                * System Support for Mobile Multimedia Applications
                       Inouye, Cen, Walpole
                * On Quality of Service in Mobile Wireless Networks
                       M. Srivastava, P. Mishra

 10:00-10:30 Break
 10:30-12:00 Session VI "Multicast"
                  Session Chair: Dan Swinehart, Xerox PARC

                * Layered Video Multicast with Retransmission (LVRM):
                  Evaluation of Error Recovery Schemes
                       X. Li and M. Ammar. Georgia Institute of Technology.
                       S. Paul and P. Pancha. Bell Laboratories.
                * Thin Streams: An Architecture for Multicasting Layered
                  Video
                       L. Wu, R. Sharma and B. Smith. Cornell University.
                * Resilient Multicast Support for Continuous Media
                  Applications
                       R. Xu, A. Myers, H. Zhang, R. Yavatkar. Carnegie
                       Mellon University and Intel.

 12:00-13:00 Lunch
 13:00-15:00 Session VII "Short Papers and A Lang Panel Session:
		          Traffic Management"

                  Session Chair: Domenico Ferrari, Universita` Cattolica, Italy 
                * Service Aggregation Through Rate Adaptation Using a
                  Single Storage Format
                       Krishnan and Little
                * Practical Experience with a Smoothing Algorithm for Video
                  Streaming
                       F. Miller, X. Mei, T. Lam, K. Zhang, and S.
                       Tripathi. University of Maryland.
                * Randomized Token Buckets: Reducing the Buffers Required
                  in Multiplexors
                       J. A. Fingerhut and G. Varghese. Washington
                       University.

 15:00-16:30 Break
 16:30-23:59 Excursion (To Cardinals Baseball Game)

 Wednesday, May 21, 1997

 8:00-9:00   Breakfast Buffet
 9:00-10:30  Session VIII "Smoothing, Scaling, etc on Endsystems"
                  Session Chair: TBD

                * The Performance of Two Dimensional Media Scaling for
                  Internet Videoconferencing: Experiments with ProShare(TM)
                  on the Internet
                       P. Nee, K. Jeffay and G. Danneels. University of
                       North Carolina.
                * Online Smoothing of Live, Variable-Bit-Rate Video
                       J. Rexford. AT&T Research Laboratories.
                       S. Sen, K. Dey, J. Kurose, J. Stankovic, D. Towsley.
                       University of Massachusetts.
                       W. Feng. Ohio State University.
                * Adaptive Middleware for Mobile Multimedia Applications
                       G. Blair, G. Coulson, N. Davies, P. Robin and T.
                       Fitzpatrick.Lancaster University.

 10:30-11:00 Break
 11:00-12:30 Session IX "Networking: Packet Scheduling, Integrated Service"
                  Session Chair: Hui Zhang, CMU

                * Fair Airport Scheduling Algorithms
                       P. Goyal and H. Vin. University of Texas.
                * Hierarchical Relative Error Scheduler: An Efficient
                  Traffic Shaper for Packet Switching Networks
                       A. Charny. Digital Electric Company.
                * Understanding TCP Dynamics in an Integrated Services
                  Internet
                       W. Feng, D. Kandlur, D. Saha and K. Shin. IBM.

 12:30-13:30 Lunch
             Workshop ends

----------------------------------------------------------------------------
nossdav97@arl.wustl.edu


From rem-conf-request@tmpmail.es.net Sun Apr 20 16:11:48 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Sun, 20 Apr 1997 13:11:32 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wJ2me-0004mN-00; Sun, 20 Apr 1997 13:00:24 -0700
Date: Sun, 20 Apr 1997 15:02:44 -0500
From: "Milind M. Buddhikot" <milind@dworkin.wustl.edu>
Message-Id: <199704202002.PAA27364@dworkin.wustl.edu>
To: rem-conf@es.net
Subject: NOSSDAV97 Advance Program + Registration Announcement
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


                 The 7th International Workshop on
  Network and Operating System Support for Digital Audio and Video 

                          NOSSDAV'97

                    St. Louis, Missouri, USA

                         May 19-21, 1997


Registrations for NOSSDAV'97 are now being accepted.

The 7th International Workshop on Network and Operating Systems Support
for Digital Audio and Video (NOSSDAV 97) is the international workshop
concerned with state of the art technology in networking and operating
system support for multimedia systems.  For seven years, NOSSDAV has
proven to be an outstanding forum for researchers involved in building
innovative multimedia systems, networks and applications on both the
research and industrial front. Other topics that will be examined include
"middleware" for multimedia, media toolkits, mobile communications,
Virtual Reality (VR), real-time systems, software agents, digital libraries,
and other digital media besides audio and video.

A key aspect of the workshop is that it provides extensive discussion
periods during which attendees can informally discuss their current
work and future research directions.  Traditionally, NOSSDAV has
emphasized on high quality experimental research that prototypes
systems to explore innovative solutions to the problems in the diverse
areas of multimedia computing. NOSSDAV97 will continue this tradition.

A sample of the  sessions to be held at the workshop include:
	Multicast for Multimedia
	Networking: Packet Scheduling and Integrated Services
	Multimedia-on-Demand (MOD) Servers and Services
	Smoothing and Scaling on Endsystems
	Mobility and Wireless
	Operating System Optimizations
	Middleware for Multimedia

To maintain the atmosphere of a small intense workshop, attendance is
once again being limited to 80.

Spots at the workshop are being reserved for one author per paper and
Program Committee members until April 10th. All other registration requests
will be accepted on a first come first served basis. After April 10th any
other requests that previously could not be immediately accepted will be
confirmed if space is available.

Presenting Authors and PC Members should register as soon as possible!!

On line registration and workshop program information can be accessed
>from the NOSSDAV97 web page:
	http://www.arl.wustl.edu/arl/NOSSDAV97/

The workshop will be held at Innsbrook Estates. Located approximately 45
minutes from the St. Louis airport, Innsbrook Estates has everything you
would like in a resort: 18-hole golf course, 18-hole miniature
course, swimming pool, a 150 acre lake, sailing, fishing,
swimming, sand beaches, fitness center, lighted tennis courts,
volleyball courts, horse back riding, full conference facilities, etc.


Send inquiries to:

	NOSSDAV97@arl.wustl.edu


	ATTN: NOSSDAV97
	Department of Computer Science/ARL
	Campus Box 1045
	Washington University
	One Brookings Drive
	St. Louis MO 63130, USA

	Tele: 1 314 935 7534
	Fax: 1 314 935 7302



                                 NOSSDAV '97
                                  Schedule

 Sunday, May 18, 1997

 16:00-19:00 Conference Registration
 19:00-21:30 Informal Dinner ???

 Monday, May 19, 1997

 7:30-8:30   Breakfast Buffet
 8:30-9:00   Introductions and Welcome

                  Christopher I. Byrnes
                       Dean of the School of Engineering and Applied
                       Science
                       Washington University

                  Workshop Chairs
                       Guru Parulkar
                       John DeHart

 9:00-10:30  Session I "Multimedia-on-Demand (MOD) Servers and Services"
                  Session Chair: Derek McAuley, Univ of Glasgow, UK

                * Design and Implementation of Video Server for Mixed-rate
                  Streams
                       J. Nishikawa, I. Okabayashi, Y. Mori, S. Sasaki, M.
                       Migita, Y. Obayashi, S. Furuya and K. Kaneko.
                       Matsushita Electric Industrial Co.
                * Random RAIDs with Selective Exploitation of Redundancy
                  for High Performance Video Servers
                       Y. Birk. Technion - Israel Inst. of Technology.
                * Efficient Striping Techniques for Multimedia File Servers
                       P. Shenoy, and H. Vin. University of Texas.

 10:30-11:00 Break
 11:00-12:30 Session II "Middleware for Multimedia Applications"
                  Session Chair: Steve McCanne

		* Toward a Common Infrastructure for
		  Multimedia-Networking Middleware  
			S. McCanne et al, 
			University of California,Berkeley 

                * An Extensible Framework for RTP-based Multimedia
		  Applications
			John Du, Dave Putzolu, Intel Corporation

                * Network Filters for Active Movie
			Mike Clark, Thomas Pfenning, Microsoft

 12:30-13:30 Lunch
 13:30-15:00 Session III "Networking"
                  Session Chair: KK Ramakrishnan, AT&T Research

                * A Comprehensive Multimedia Control Architecture for the
                  Internet
                       H. Schulzrinne. Columbia University.
                * Environments for Active Networks
                       R. Sharma, S. Keshav, M. Wu and L. Wu. Cornell
                       Univeristy.
                * WANDS: Wide-Area Network Delay Simulator
                       M. Borella & A. Sears. DePaul University.

SHORT PAPER:
                * A Virtual Network Service for Integrated-Services
                  Internetworks
                       L. Delgrossi and Domenico Ferrari. Unversita
                       Cattolica.

 15:00-15:30 Break
 15:30-17:00 Session IV "Operating System Optimizations"
                  Session Chair: Hide Tokuda, Keio Univ, Japan

                * Evaluation of Data Passing and Scheduling Avoidance
                       J. Brustoloni and P. Steenkiste. Carnegie Mellon
                       University.
                * User-Safe Devices for True End-to-End QoS
                       I. Pratt. University of Cambridge.
                * A Fresh Approach to File System Quality of Service
                       P. Barham. University of Cambridge.

 17:00-18:00 Break
 18:00-20:00 Banquet
 20:00-21:00 PC/Planning Meeting

 Tuesday, May 20, 1997

 7:30-8:30   Breakfast Buffet
 8:30-10:00  Session V "Mobility and Wireless"
                  Session Chair: Doug Shepherd, University of Lancaster, UK

                * Mobile Filters: Delivering Scaled Media to Mobile Devices
                       A. Balachandran and A. Campbell
                * System Support for Mobile Multimedia Applications
                       Inouye, Cen, Walpole
                * On Quality of Service in Mobile Wireless Networks
                       M. Srivastava, P. Mishra

 10:00-10:30 Break
 10:30-12:00 Session VI "Multicast"
                  Session Chair: Dan Swinehart, Xerox PARC

                * Layered Video Multicast with Retransmission (LVRM):
                  Evaluation of Error Recovery Schemes
                       X. Li and M. Ammar. Georgia Institute of Technology.
                       S. Paul and P. Pancha. Bell Laboratories.
                * Thin Streams: An Architecture for Multicasting Layered
                  Video
                       L. Wu, R. Sharma and B. Smith. Cornell University.
                * Resilient Multicast Support for Continuous Media
                  Applications
                       R. Xu, A. Myers, H. Zhang, R. Yavatkar. Carnegie
                       Mellon University and Intel.

 12:00-13:00 Lunch
 13:00-15:00 Session VII "Short Papers and A Lang Panel Session:
		          Traffic Management"

                  Session Chair: Domenico Ferrari, Universita` Cattolica, Italy 
                * Service Aggregation Through Rate Adaptation Using a
                  Single Storage Format
                       Krishnan and Little
                * Practical Experience with a Smoothing Algorithm for Video
                  Streaming
                       F. Miller, X. Mei, T. Lam, K. Zhang, and S.
                       Tripathi. University of Maryland.
                * Randomized Token Buckets: Reducing the Buffers Required
                  in Multiplexors
                       J. A. Fingerhut and G. Varghese. Washington
                       University.

 15:00-16:30 Break
 16:30-23:59 Excursion (To Cardinals Baseball Game)

 Wednesday, May 21, 1997

 8:00-9:00   Breakfast Buffet
 9:00-10:30  Session VIII "Smoothing, Scaling, etc on Endsystems"
                  Session Chair: TBD

                * The Performance of Two Dimensional Media Scaling for
                  Internet Videoconferencing: Experiments with ProShare(TM)
                  on the Internet
                       P. Nee, K. Jeffay and G. Danneels. University of
                       North Carolina.
                * Online Smoothing of Live, Variable-Bit-Rate Video
                       J. Rexford. AT&T Research Laboratories.
                       S. Sen, K. Dey, J. Kurose, J. Stankovic, D. Towsley.
                       University of Massachusetts.
                       W. Feng. Ohio State University.
                * Adaptive Middleware for Mobile Multimedia Applications
                       G. Blair, G. Coulson, N. Davies, P. Robin and T.
                       Fitzpatrick.Lancaster University.

 10:30-11:00 Break
 11:00-12:30 Session IX "Networking: Packet Scheduling, Integrated Service"
                  Session Chair: Hui Zhang, CMU

                * Fair Airport Scheduling Algorithms
                       P. Goyal and H. Vin. University of Texas.
                * Hierarchical Relative Error Scheduler: An Efficient
                  Traffic Shaper for Packet Switching Networks
                       A. Charny. Digital Electric Company.
                * Understanding TCP Dynamics in an Integrated Services
                  Internet
                       W. Feng, D. Kandlur, D. Saha and K. Shin. IBM.

 12:30-13:30 Lunch
             Workshop ends

----------------------------------------------------------------------------
nossdav97@arl.wustl.edu



From rem-conf-request@es.net Mon Apr 21 09:15:54 1997 
Received: from rx7.ee.lbl.gov by osi-west.es.net with ESnet SMTP (PP);
          Mon, 21 Apr 1997 06:15:45 -0700
Received: by rx7.ee.lbl.gov (8.8.2/1.43r) id GAA17356;
          Mon, 21 Apr 1997 06:19:17 -0700 (PDT)
Message-Id: <199704211319.GAA17356@rx7.ee.lbl.gov>
To: ietf@ietf.org
cc: rem-conf@es.net
Subject: pathchar - a new tool for characterizing Internet paths
Date: Mon, 21 Apr 97 06:19:16 PDT
From: Van Jacobson <van@ee.lbl.gov>

For the past 6 years, I've been working on a tool to figure out
more about an Internet path that just what routers you go through.
I've developed a tool called `pathchar' (for `path characteristics')
that tells you the bandwidth, distance from previous hop, average
queue, and drop rate for every hop on the path (*not* just the
bottleneck hop).  This is a typical output:

    % pathchar ka9q.ampr.org
     mtu limitted to 1500 bytes at local host
     doing 32 probes at each of 64 to 1500 by 32
     0 localhost
     |   8.7 Mb/s,   292 us (1.97 ms)
     1 ir40gw.lbl.gov (131.243.1.1)
     |    29 Mb/s,   132 us (2.64 ms)
     2 er1gw.lbl.gov (131.243.128.11)
     |    91 Mb/s,   189 us (3.15 ms)
     3 lbl-lc1-1.es.net (198.128.16.11)
     |    25 Mb/s,   6.92 ms (17.5 ms)
     4 gac-atms.es.net (134.55.24.6)
     |    11 Mb/s,   424 us (19.4 ms)
     5 CERFNETGWY.GAT.COM (192.73.7.163)
     |   7.0 Mb/s,   1.20 ms (23.5 ms)
     6 sdsc-ga.cerf.net (134.24.20.15)
     |   ?? b/s,   -263 us (22.8 ms)
     7 mobydick-fddi.cerf.net (134.24.252.3)
     |    46 Mb/s,   -51 us (22.9 ms)
     8 qualcomm-sdsc-ds3.cerf.net (134.24.47.200)
     |   9.0 Mb/s,   17 us (24.3 ms)
     9 krypton-e2.qualcomm.com (192.35.156.2)
     |   5.5 Mb/s,   1.04 ms (28.6 ms)
    10 ascend-max.qualcomm.com (129.46.54.31)
     |   56.7 Kb/s,   6.19 ms (253 ms)
    11 karnp50.qualcomm.com (129.46.90.33)
     |    10 Mb/s,   -50 us (253 ms),  +q 3.32 ms (6.58 KB) *2
    12 unix.ka9q.ampr.org (129.46.90.35)
    rtt 32 ms (253 ms), bottleneck 56.7 Kb/s, pipe 4706 bytes

The lines starting with `|' are the characteristics of the link
between the hops listed above & below.  The first number is the
link bandwidth, the 2nd is the one-way prop time (i.e., for a
zero length packet) & the number in parens is the round trip
time you would get if there were no queues and you sent a
path-mtu sized packet from the source to this hop (i.e., the
unloaded data rtt).  If there's a queue larger than 1 packet,
its size in both time & bytes is printed.  If the drop rate is
more than 1%, it's printed.

Note that it successfully found the LBL FDDI dmz (hops 2-3) &
SDSC-Qualcomm T3 (hops 7-8) even though I was running it behind
a 10Mb/s ethernet.  And that the long hop from San Francisco to
San Diego is clearly visible (3-4).  (Also note that I was
running this at 1am this morning so the normal cerfnet queues
were missing & only Phil's P50 ISDN box showed a queue.)

We're hoping to release pathchar sometime in the next two weeks.
I'm giving a talk on it today at 4pm PDT for MSRI Math Awareness
Week and the talk should be mboned.  I've put the viewgraphs
>from the talk (which are the only existing documentation) at

  ftp://ftp.ee.lbl.gov/pathchar/msri-talk.ps.gz

If you really deperately want to play with a very flakey, alpha
version of pathchar, there are binaries for freebsd, linux and
solaris in the same directory (but you are totally on your own
when running this -- we'll answer questions once the beta release
goes out but right now we're putting all our energy into getting
it out).

Cheers.

 - Van

From rem-conf-request@tmpmail.es.net Mon Apr 21 09:25:39 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Mon, 21 Apr 1997 06:25:24 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wJIwn-0001Tq-00; Mon, 21 Apr 1997 06:15:57 -0700
Message-Id: <199704211319.GAA17356@rx7.ee.lbl.gov>
To: ietf@ietf.org
cc: rem-conf@es.net
Subject: pathchar - a new tool for characterizing Internet paths
Date: Mon, 21 Apr 97 06:19:16 PDT
From: Van Jacobson <van@ee.lbl.gov>
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

For the past 6 years, I've been working on a tool to figure out
more about an Internet path that just what routers you go through.
I've developed a tool called `pathchar' (for `path characteristics')
that tells you the bandwidth, distance from previous hop, average
queue, and drop rate for every hop on the path (*not* just the
bottleneck hop).  This is a typical output:

    % pathchar ka9q.ampr.org
     mtu limitted to 1500 bytes at local host
     doing 32 probes at each of 64 to 1500 by 32
     0 localhost
     |   8.7 Mb/s,   292 us (1.97 ms)
     1 ir40gw.lbl.gov (131.243.1.1)
     |    29 Mb/s,   132 us (2.64 ms)
     2 er1gw.lbl.gov (131.243.128.11)
     |    91 Mb/s,   189 us (3.15 ms)
     3 lbl-lc1-1.es.net (198.128.16.11)
     |    25 Mb/s,   6.92 ms (17.5 ms)
     4 gac-atms.es.net (134.55.24.6)
     |    11 Mb/s,   424 us (19.4 ms)
     5 CERFNETGWY.GAT.COM (192.73.7.163)
     |   7.0 Mb/s,   1.20 ms (23.5 ms)
     6 sdsc-ga.cerf.net (134.24.20.15)
     |   ?? b/s,   -263 us (22.8 ms)
     7 mobydick-fddi.cerf.net (134.24.252.3)
     |    46 Mb/s,   -51 us (22.9 ms)
     8 qualcomm-sdsc-ds3.cerf.net (134.24.47.200)
     |   9.0 Mb/s,   17 us (24.3 ms)
     9 krypton-e2.qualcomm.com (192.35.156.2)
     |   5.5 Mb/s,   1.04 ms (28.6 ms)
    10 ascend-max.qualcomm.com (129.46.54.31)
     |   56.7 Kb/s,   6.19 ms (253 ms)
    11 karnp50.qualcomm.com (129.46.90.33)
     |    10 Mb/s,   -50 us (253 ms),  +q 3.32 ms (6.58 KB) *2
    12 unix.ka9q.ampr.org (129.46.90.35)
    rtt 32 ms (253 ms), bottleneck 56.7 Kb/s, pipe 4706 bytes

The lines starting with `|' are the characteristics of the link
between the hops listed above & below.  The first number is the
link bandwidth, the 2nd is the one-way prop time (i.e., for a
zero length packet) & the number in parens is the round trip
time you would get if there were no queues and you sent a
path-mtu sized packet from the source to this hop (i.e., the
unloaded data rtt).  If there's a queue larger than 1 packet,
its size in both time & bytes is printed.  If the drop rate is
more than 1%, it's printed.

Note that it successfully found the LBL FDDI dmz (hops 2-3) &
SDSC-Qualcomm T3 (hops 7-8) even though I was running it behind
a 10Mb/s ethernet.  And that the long hop from San Francisco to
San Diego is clearly visible (3-4).  (Also note that I was
running this at 1am this morning so the normal cerfnet queues
were missing & only Phil's P50 ISDN box showed a queue.)

We're hoping to release pathchar sometime in the next two weeks.
I'm giving a talk on it today at 4pm PDT for MSRI Math Awareness
Week and the talk should be mboned.  I've put the viewgraphs
>from the talk (which are the only existing documentation) at

  ftp://ftp.ee.lbl.gov/pathchar/msri-talk.ps.gz

If you really deperately want to play with a very flakey, alpha
version of pathchar, there are binaries for freebsd, linux and
solaris in the same directory (but you are totally on your own
when running this -- we'll answer questions once the beta release
goes out but right now we're putting all our energy into getting
it out).

Cheers.

 - Van


From rem-conf-request@es.net Mon Apr 21 14:27:10 1997 
Received: from nobozo.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP);
          Mon, 21 Apr 1997 11:27:04 -0700
Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) 
          by nobozo.CS.Berkeley.EDU (8.6.10/8.6.3) with SMTP id LAA02761 
          for <rem-conf@es.net>; Mon, 21 Apr 1997 11:27:02 -0700
Date: Mon, 21 Apr 1997 11:27:02 -0700
Message-Id: <199704211827.LAA02761@nobozo.CS.Berkeley.EDU>
X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU
X-Mailer: Windows Eudora Version 2.1.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: rem-conf@es.net
From: Jerrlyn Iwata <jerrlyn@postgres.Berkeley.EDU>
Subject: [Reminder] Berkeley Multimedia & Graphics Seminar

                Berkeley Multimedia and Graphics Seminar 
        Wednesday April 23, 1997 12:30-2:00 PDT 405 Soda Hall

       "Network Architecture Revisited: the case for datagrams" 

                               Lixia Zhang 
                   UCLA Computer Science Department 

          MBONE BROADCAST BEGINS AT 12.40 PDT (GMT - 8 HOURS)


From rem-conf-request@tmpmail.es.net Mon Apr 21 14:37:35 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Mon, 21 Apr 1997 11:37:29 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wJNo2-0003Np-00; Mon, 21 Apr 1997 11:27:14 -0700
Date: Mon, 21 Apr 1997 11:27:02 -0700
Message-Id: <199704211827.LAA02761@nobozo.CS.Berkeley.EDU>
X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU
X-Mailer: Windows Eudora Version 2.1.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: rem-conf@es.net
From: Jerrlyn Iwata <jerrlyn@postgres.Berkeley.EDU>
Subject: [Reminder] Berkeley Multimedia & Graphics Seminar
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

                Berkeley Multimedia and Graphics Seminar 
        Wednesday April 23, 1997 12:30-2:00 PDT 405 Soda Hall

       "Network Architecture Revisited: the case for datagrams" 

                               Lixia Zhang 
                   UCLA Computer Science Department 

          MBONE BROADCAST BEGINS AT 12.40 PDT (GMT - 8 HOURS)



From rem-conf-request@es.net Tue Apr 22 11:33:58 1997 
Received: from pi4.informatik.uni-mannheim.de by osi-west.es.net 
          with ESnet SMTP (PP); Tue, 22 Apr 1997 08:33:42 -0700
Received: from sophokles.informatik.uni-mannheim.de (sophokles [134.155.48.104]) 
          by pi4.informatik.uni-mannheim.de (8.8.5/8.8.5) with ESMTP 
          id RAA16450; Tue, 22 Apr 1997 17:33:36 +0200
Received: from localhost (whd@localhost) 
          by sophokles.informatik.uni-mannheim.de (8.8.5/8.8.5) with SMTP 
          id RAA01919; Tue, 22 Apr 1997 17:33:34 +0200 (MET DST)
X-Authentication-Warning: sophokles.informatik.uni-mannheim.de: whd owned 
                          process doing -bs
Date: Tue, 22 Apr 1997 17:33:33 +0200 (MET DST)
From: Wieland Holfelder <whd@pi4.informatik.uni-mannheim.de>
X-Sender: whd@sophokles
Reply-To: Wieland Holfelder <whd@pi4.informatik.uni-mannheim.de>
To: Multicast Backbone <mbone@isi.edu>, Remote Conferencing <rem-conf@es.net>
cc: "Prof. Dr. Wolfgang Effelsberg" <effels@pi4.informatik.uni-mannheim.de>, 
    J.Crowcroft@cs.ucl.ac.uk, cjk@pi4.informatik.uni-mannheim.de
Subject: The Future of Multicast, RSVP and Integrated Services
Message-ID: <Pine.GSO.3.95.970422162712.1101I-100000@sophokles>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

-----------------------------------------------------------------
----- I N V I T A T I O N   A N D   A N N O U N C E M E N T -----
-----------------------------------------------------------------

On Friday, April 25th 1997 16:00 CET - 19:00 CET we will have

                    Prof. Dr. Jon Crowcroft 
                   University College London 

in our lecture series "COST237 Euroseminar" talking about:

    "The Future of Multicast, RSVP and Integrated Services"

This talk will be multicasted over the MBone using vat, vic and wb.
Since we already received a couple of request from people out of
continent that are interested, will use a ttl of 127. The session
is announced in sdr as "COST237 Euroseminar".

The COST237 Euroseminars are a series of talks on TeleTeaching and
Distance Learnung projects in Europe. They are organized by COST 
Action 237 of the European Union and will be multicasted over the 
MBone. If you are interested in receiving announcements for other 
talks in this lecture series, we have an automated mailing list 
where you can subscribe. To do so, please send an email to:
  cost237euroseminars-l-request@pi4.informatik.uni-mannheim.de
with the word "subscribe" in the body.

Please feel free to distributed this information to other people
that might be interested. Thanks.

-- Wieland
---------------------------------------------------------------------
Wieland Holfelder                              University of Mannheim
Praktische Informatik IV                      Phone: +49-621-292-5679
L 15,16                                       Fax  : +49-621-292-5745
68131 Mannheim                     whd@pi4.informatik.uni-mannheim.de
Germany                    http://www.informatik.uni-mannheim.de/~whd
---------------------------------------------------------------------





From rem-conf-request@tmpmail.es.net Tue Apr 22 11:56:29 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Tue, 22 Apr 1997 08:56:24 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wJha7-0006l5-00; Tue, 22 Apr 1997 08:34:11 -0700
X-Authentication-Warning: sophokles.informatik.uni-mannheim.de: whd owned 
                          process doing -bs
Date: Tue, 22 Apr 1997 17:33:33 +0200 (MET DST)
From: Wieland Holfelder <whd@pi4.informatik.uni-mannheim.de>
X-Sender: whd@sophokles
Reply-To: Wieland Holfelder <whd@pi4.informatik.uni-mannheim.de>
To: Multicast Backbone <mbone@isi.edu>, Remote Conferencing <rem-conf@es.net>
cc: "Prof. Dr. Wolfgang Effelsberg" <effels@pi4.informatik.uni-mannheim.de>, 
    J.Crowcroft@cs.ucl.ac.uk, cjk@pi4.informatik.uni-mannheim.de
Subject: The Future of Multicast, RSVP and Integrated Services
Message-ID: <Pine.GSO.3.95.970422162712.1101I-100000@sophokles>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

-----------------------------------------------------------------
----- I N V I T A T I O N   A N D   A N N O U N C E M E N T -----
-----------------------------------------------------------------

On Friday, April 25th 1997 16:00 CET - 19:00 CET we will have

                    Prof. Dr. Jon Crowcroft 
                   University College London 

in our lecture series "COST237 Euroseminar" talking about:

    "The Future of Multicast, RSVP and Integrated Services"

This talk will be multicasted over the MBone using vat, vic and wb.
Since we already received a couple of request from people out of
continent that are interested, will use a ttl of 127. The session
is announced in sdr as "COST237 Euroseminar".

The COST237 Euroseminars are a series of talks on TeleTeaching and
Distance Learnung projects in Europe. They are organized by COST 
Action 237 of the European Union and will be multicasted over the 
MBone. If you are interested in receiving announcements for other 
talks in this lecture series, we have an automated mailing list 
where you can subscribe. To do so, please send an email to:
  cost237euroseminars-l-request@pi4.informatik.uni-mannheim.de
with the word "subscribe" in the body.

Please feel free to distributed this information to other people
that might be interested. Thanks.

-- Wieland
---------------------------------------------------------------------
Wieland Holfelder                              University of Mannheim
Praktische Informatik IV                      Phone: +49-621-292-5679
L 15,16                                       Fax  : +49-621-292-5745
68131 Mannheim                     whd@pi4.informatik.uni-mannheim.de
Germany                    http://www.informatik.uni-mannheim.de/~whd
---------------------------------------------------------------------






From rem-conf-request@es.net Tue Apr 22 14:24:16 1997 
Received: from msri.org by osi-west.es.net with ESnet SMTP (PP);
          Tue, 22 Apr 1997 11:24:10 -0700
Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id LAA07495 
          for <rem-conf@es.net>; Tue, 22 Apr 1997 11:24:09 -0700 (PDT)
X-Authentication-Warning: msri.org: smap set sender to <nobody@msri.org> using 
                          -f
Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) 
          id sma007480; Tue Apr 22 11:23:49 1997
Received: by hille.msri.org (8.7/MSRI) id LAA07137;
          Tue, 22 Apr 1997 11:23:48 -0700 (PDT)
Date: Tue, 22 Apr 1997 11:23:48 -0700 (PDT)
Message-Id: <199704221823.LAA07137@hille.msri.org>
To: rem-conf@es.net
From: m1 <m1@msri.org>
Reply-to: m1@msri.org
Subject: Van Jacobson "Pathchar - How to infer the characteristics of Internet 
         paths"

	MBone Broadcast Announcement
	----------------------------

Title:       
	Van Jacobson "Pathchar - How to infer the characteristics of Internet  paths"
Date:        
	Apr 29, 1997

Time:        
	12:00 PST8PDT 1 hours

Contact:     
	m1@msri.org

URL:         
	http://www.msri.org/sched/empennage/jacobson.html

Description:        
	The Internet has no central control or administration. In terms of ability to grow and scale this  is a great strength. But in terms of ability to diagnose and fix problems it has been a serious  weakness -- packets usually cross many administrative boundaries on their way from a source  to a destination and often the only point of agreement between those separate administrations  is that all problems are the other guy's fault.     Ten years ago the Internet was plagued with routing problems and I developed a tool called  `traceroute' that allowed any user, anywhere on the Internet, to trace the path packets take and  isolate routing loops and black holes. Today the Internet appears to be experiencing severe  congestion problems. I've developed a new tool, `pathchar', that allows any user to find the  bandwidth, delay, average queue and loss rate of every hop between any source & destination  on the Internet. A surprisingly large amount of mathematics is required to do live a!
!
nalysis of a  busy (and often broken) network path. I'll talk about how pathchar works and what it's capable  of telling you. Since writing diagnostics is often a good way to figure out how things work, I may  also explain a bit about how the packet forwarding part of the Internet works. 









mbone broadcast schedule http://www.msri.org/mbone

From rem-conf-request@es.net Tue Apr 22 14:26:18 1997 
Received: from msri.org by osi-west.es.net with ESnet SMTP (PP);
          Tue, 22 Apr 1997 11:26:13 -0700
Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id LAA07717 
          for <rem-conf@es.net>; Tue, 22 Apr 1997 11:26:11 -0700 (PDT)
X-Authentication-Warning: msri.org: smap set sender to <nobody@msri.org> using 
                          -f
Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) 
          id sma007643; Tue Apr 22 11:25:33 1997
Received: by hille.msri.org (8.7/MSRI) id LAA07171;
          Tue, 22 Apr 1997 11:25:32 -0700 (PDT)
Date: Tue, 22 Apr 1997 11:25:32 -0700 (PDT)
Message-Id: <199704221825.LAA07171@hille.msri.org>
To: rem-conf@es.net
From: m1 <m1@msri.org>
Reply-to: m1@msri.org
Subject: Xavier Viennot "The Mathematical Beauty of Trees"

	MBone Broadcast Announcement
	----------------------------

Title:       
	Xavier Viennot "The Mathematical Beauty of Trees"
Date:        
	May 01, 1997

Time:        
	12:00 PST8PDT 1 hours

Contact:     
	m1@msri.org

URL:         
	http://www.msri.org/lecturenotes/97/viennot/

Description:        
	Starting with the Horton-Strahler analysis of  binary trees, we embark for a trip in the beautiful  garden of various sciences involving "trees" or  "branching structures". We will visit combinatorics,  hydrogenology, theoretical computer science,  number theory, computer graphics, fractal physics,  dynamical systems, and molecular biology.









mbone broadcast schedule http://www.msri.org/mbone

From rem-conf-request@es.net Tue Apr 22 14:28:31 1997 
Received: from msri.org by osi-west.es.net with ESnet SMTP (PP);
          Tue, 22 Apr 1997 11:28:13 -0700
Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id LAA07912 
          for <rem-conf@es.net>; Tue, 22 Apr 1997 11:28:12 -0700 (PDT)
X-Authentication-Warning: msri.org: smap set sender to <nobody@msri.org> using 
                          -f
Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) 
          id sma007858; Tue Apr 22 11:27:26 1997
Received: by hille.msri.org (8.7/MSRI) id LAA07208;
          Tue, 22 Apr 1997 11:27:26 -0700 (PDT)
Date: Tue, 22 Apr 1997 11:27:26 -0700 (PDT)
Message-Id: <199704221827.LAA07208@hille.msri.org>
To: rem-conf@es.net
From: m1 <m1@msri.org>
Reply-to: m1@msri.org
Subject: Georgia Benkart "Towards a Representation Theory of Lie Algebras 
         Graded by Finite Root Systems"

	MBone Broadcast Announcement
	----------------------------

Title:       
	Georgia Benkart "Towards a Representation Theory of Lie  Algebras Graded by Finite Root Systems"
Date:        
	Apr 30, 1997

Time:        
	12:00 PST8PDT 1 hours

Contact:     
	m1@msri.org

URL:         
	http://www.msri.org/lecturenotes/97/benkart/

Description:        
	The Lie algebras graded by finite root systems  include many important examples such as finite-  dimensional complex simple Lie algebras, affine Lie  algebras, extended affine Lie algebras and many,  many others. In this talk we will survey some steps  towards developing a representation theory and  character theory for this class of Lie algebras.









mbone broadcast schedule http://www.msri.org/mbone

From rem-conf-request@tmpmail.es.net Tue Apr 22 14:28:50 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Tue, 22 Apr 1997 11:28:33 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wJkGh-0007UC-00; Tue, 22 Apr 1997 11:26:19 -0700
X-Authentication-Warning: msri.org: smap set sender to <nobody@msri.org> using 
                          -f
Date: Tue, 22 Apr 1997 11:25:32 -0700 (PDT)
Message-Id: <199704221825.LAA07171@hille.msri.org>
To: rem-conf@es.net
From: m1 <m1@msri.org>
Reply-to: m1@msri.org
Subject: Xavier Viennot "The Mathematical Beauty of Trees"
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

	MBone Broadcast Announcement
	----------------------------

Title:       
	Xavier Viennot "The Mathematical Beauty of Trees"
Date:        
	May 01, 1997

Time:        
	12:00 PST8PDT 1 hours

Contact:     
	m1@msri.org

URL:         
	http://www.msri.org/lecturenotes/97/viennot/

Description:        
	Starting with the Horton-Strahler analysis of  binary trees, we embark for a trip in the beautiful  garden of various sciences involving "trees" or  "branching structures". We will visit combinatorics,  hydrogenology, theoretical computer science,  number theory, computer graphics, fractal physics,  dynamical systems, and molecular biology.









mbone broadcast schedule http://www.msri.org/mbone


From rem-conf-request@tmpmail.es.net Tue Apr 22 14:28:53 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Tue, 22 Apr 1997 11:28:38 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wJkEj-0007TY-00; Tue, 22 Apr 1997 11:24:17 -0700
X-Authentication-Warning: msri.org: smap set sender to <nobody@msri.org> using 
                          -f
Date: Tue, 22 Apr 1997 11:23:48 -0700 (PDT)
Message-Id: <199704221823.LAA07137@hille.msri.org>
To: rem-conf@es.net
From: m1 <m1@msri.org>
Reply-to: m1@msri.org
Subject: Van Jacobson "Pathchar - How to infer the characteristics of Internet 
         paths"
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

	MBone Broadcast Announcement
	----------------------------

Title:       
	Van Jacobson "Pathchar - How to infer the characteristics of Internet  paths"
Date:        
	Apr 29, 1997

Time:        
	12:00 PST8PDT 1 hours

Contact:     
	m1@msri.org

URL:         
	http://www.msri.org/sched/empennage/jacobson.html

Description:        
	The Internet has no central control or administration. In terms of ability to grow and scale this  is a great strength. But in terms of ability to diagnose and fix problems it has been a serious  weakness -- packets usually cross many administrative boundaries on their way from a source  to a destination and often the only point of agreement between those separate administrations  is that all problems are the other guy's fault.     Ten years ago the Internet was plagued with routing problems and I developed a tool called  `traceroute' that allowed any user, anywhere on the Internet, to trace the path packets take and  isolate routing loops and black holes. Today the Internet appears to be experiencing severe  congestion problems. I've developed a new tool, `pathchar', that allows any user to find the  bandwidth, delay, average queue and loss rate of every hop between any source & destination  on the Internet. A surprisingly large amount of mathematics is required to do live a!
!
nalysis of a  busy (and often broken) network path. I'll talk about how pathchar works and what it's capable  of telling you. Since writing diagnostics is often a good way to figure out how things work, I may  also explain a bit about how the packet forwarding part of the Internet works. 









mbone broadcast schedule http://www.msri.org/mbone


From rem-conf-request@tmpmail.es.net Tue Apr 22 14:29:59 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Tue, 22 Apr 1997 11:29:56 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wJkIr-0007fC-00; Tue, 22 Apr 1997 11:28:33 -0700
X-Authentication-Warning: msri.org: smap set sender to <nobody@msri.org> using 
                          -f
Date: Tue, 22 Apr 1997 11:27:26 -0700 (PDT)
Message-Id: <199704221827.LAA07208@hille.msri.org>
To: rem-conf@es.net
From: m1 <m1@msri.org>
Reply-to: m1@msri.org
Subject: Georgia Benkart "Towards a Representation Theory of Lie Algebras 
         Graded by Finite Root Systems"
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

	MBone Broadcast Announcement
	----------------------------

Title:       
	Georgia Benkart "Towards a Representation Theory of Lie  Algebras Graded by Finite Root Systems"
Date:        
	Apr 30, 1997

Time:        
	12:00 PST8PDT 1 hours

Contact:     
	m1@msri.org

URL:         
	http://www.msri.org/lecturenotes/97/benkart/

Description:        
	The Lie algebras graded by finite root systems  include many important examples such as finite-  dimensional complex simple Lie algebras, affine Lie  algebras, extended affine Lie algebras and many,  many others. In this talk we will survey some steps  towards developing a representation theory and  character theory for this class of Lie algebras.









mbone broadcast schedule http://www.msri.org/mbone


From rem-conf-request@es.net Tue Apr 22 18:27:06 1997 
Received: from woodstock.cs.berkeley.edu by osi-west.es.net 
          with ESnet SMTP (PP); Tue, 22 Apr 1997 15:26:51 -0700
Received: (from radhika@localhost) by woodstock.cs.berkeley.edu (8.8.4/8.8.2) 
          id PAA04796; Tue, 22 Apr 1997 15:27:04 -0700 (PDT)
From: Radhika Malpani <radhika@CS.Berkeley.EDU>
Message-Id: <199704222227.PAA04796@woodstock.cs.berkeley.edu>
Subject: qb - a new floor ctrl tool for asking qs
To: rem-conf@es.net
Date: Tue, 22 Apr 1997 15:27:03 -0700 (PDT)
Cc: radhika@woodstock.cs.berkeley.edu (Radhika Malpani)
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit


Hi everyone,

I work for Larry Rowe in the Berkeley Multimedia Research Center.
We have developed qb which is a floor control tool for MBone seminars. Qb 
allows MBone participants to ask questions and enables a moderator to do
floor control. Participants can indicate a desire to ask a question by
typing in a few keywords (or the actual question if they do not have a
microphone connected). The moderator can then either read the question and
verbally respond, or can grant the floor to the participant allowing him to
ask his question by talking into his microphone. Qb works in conjunction
with vic & vat.

We will be using qb tomorrow in the UC Berkeley Multimedia & Graphics
seminar for Lixia Zhang's talk. The tool is still very much in the alpha phase  so we are not currently doing a general release. However, we will release
the tool to anyone interested in being alpha testers and using it to ask
questions in tomorrow's talk. The title of the talk is "Network Architecture
Revisited: the case for datagrams".

Please send email to radhika@cs.berkeley.edu with information about your os if 
you would like to use qb tomorrow.

Thanks,
Radhika

------------------------------------------------------------------------
Radhika Malpani				radhika@CS.Berkeley.EDU
Berkeley Multimedia Research Center	http://www.cs.berkeley.edu/~radhika

From rem-conf-request@tmpmail.es.net Tue Apr 22 18:31:43 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Tue, 22 Apr 1997 15:31:39 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wJo1k-0001PH-00; Tue, 22 Apr 1997 15:27:08 -0700
From: Radhika Malpani <radhika@CS.Berkeley.EDU>
Message-Id: <199704222227.PAA04796@woodstock.cs.berkeley.edu>
Subject: qb - a new floor ctrl tool for asking qs
To: rem-conf@es.net
Date: Tue, 22 Apr 1997 15:27:03 -0700 (PDT)
Cc: radhika@woodstock.cs.berkeley.edu (Radhika Malpani)
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


Hi everyone,

I work for Larry Rowe in the Berkeley Multimedia Research Center.
We have developed qb which is a floor control tool for MBone seminars. Qb 
allows MBone participants to ask questions and enables a moderator to do
floor control. Participants can indicate a desire to ask a question by
typing in a few keywords (or the actual question if they do not have a
microphone connected). The moderator can then either read the question and
verbally respond, or can grant the floor to the participant allowing him to
ask his question by talking into his microphone. Qb works in conjunction
with vic & vat.

We will be using qb tomorrow in the UC Berkeley Multimedia & Graphics
seminar for Lixia Zhang's talk. The tool is still very much in the alpha phase  so we are not currently doing a general release. However, we will release
the tool to anyone interested in being alpha testers and using it to ask
questions in tomorrow's talk. The title of the talk is "Network Architecture
Revisited: the case for datagrams".

Please send email to radhika@cs.berkeley.edu with information about your os if 
you would like to use qb tomorrow.

Thanks,
Radhika

------------------------------------------------------------------------
Radhika Malpani				radhika@CS.Berkeley.EDU
Berkeley Multimedia Research Center	http://www.cs.berkeley.edu/~radhika


From rem-conf-request@es.net Tue Apr 22 20:18:56 1997 
Received: from precept.com (actually hydra.precept.com) by osi-west.es.net 
          with ESnet SMTP (PP); Tue, 22 Apr 1997 17:18:50 -0700
Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4) id RAA15781;
          Tue, 22 Apr 1997 17:07:24 -0700
Date: Tue, 22 Apr 1997 17:06:23 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Magnus Danielson <magda@it.kth.se>
cc: rem-conf@es.net
Subject: Re: About RTP Timestamps
In-Reply-To: <199704190002.CAA20252@piraya.electrum.kth.se>
Message-ID: <Pine.WNT.3.95.970422165113.-132577R-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sat, 19 Apr 1997, Magnus Danielson wrote:

> The resynchronisation machinery necessary in order to get multiple
> streams to apear in sync is not well stated in RFC 1889, it's just
> assumed to be there and this fact makes it up a lack of reference to
> those approaching the topic as beginners compared to those allready
> knows the full context. It would be good if an document existed that
> does more clearly explain the machinery and also explains what RTP
> provides as a tool in this machinery.

You are right.  The concept is there, but there are some details that
require careful thought.  I have some synchronization code that would
probably be useful to include in an appendix, but I expect my employer
would be reluctant to share it.

> Also, to my knowledge is there no standard way to resynchronise
> between diffrent streams on both single and multiple machines, this is
> as far as I know only done in propritary solutions.

Julio Escobar, et. al. at BBN defined a synchronization protocol that
could be used to implement a whole range of synchronization goals.
Examples include having a stream from one source play at the same time
at multiple destinations, or having streams from multiple hosts
sharing a common reference clock (e.g. via NTP) be played in sync at
one destination.  A nice demo of geographically distributed multi-part
live music performance using this protocol was given at ACM Multimedia
'94.  This has been discussed in AVT some time ago, but not taken up
as a standards effort.

> A standard
> resynchronisation method would allow us to resync picture and sound
> (and whatever) with the users choise of sound tool and video tool,
> they do not _need_ to be the same software package. But then, one can
> allways dream.

Some host internal mechanisms have been implemented.  RAT and vic can
synchronize, for example.
							-- Steve


From rem-conf-request@tmpmail.es.net Tue Apr 22 20:24:08 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Tue, 22 Apr 1997 17:24:03 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wJply-00029f-00; Tue, 22 Apr 1997 17:18:58 -0700
Date: Tue, 22 Apr 1997 17:06:23 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Magnus Danielson <magda@it.kth.se>
cc: rem-conf@es.net
Subject: Re: About RTP Timestamps
In-Reply-To: <199704190002.CAA20252@piraya.electrum.kth.se>
Message-ID: <Pine.WNT.3.95.970422165113.-132577R-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

On Sat, 19 Apr 1997, Magnus Danielson wrote:

> The resynchronisation machinery necessary in order to get multiple
> streams to apear in sync is not well stated in RFC 1889, it's just
> assumed to be there and this fact makes it up a lack of reference to
> those approaching the topic as beginners compared to those allready
> knows the full context. It would be good if an document existed that
> does more clearly explain the machinery and also explains what RTP
> provides as a tool in this machinery.

You are right.  The concept is there, but there are some details that
require careful thought.  I have some synchronization code that would
probably be useful to include in an appendix, but I expect my employer
would be reluctant to share it.

> Also, to my knowledge is there no standard way to resynchronise
> between diffrent streams on both single and multiple machines, this is
> as far as I know only done in propritary solutions.

Julio Escobar, et. al. at BBN defined a synchronization protocol that
could be used to implement a whole range of synchronization goals.
Examples include having a stream from one source play at the same time
at multiple destinations, or having streams from multiple hosts
sharing a common reference clock (e.g. via NTP) be played in sync at
one destination.  A nice demo of geographically distributed multi-part
live music performance using this protocol was given at ACM Multimedia
'94.  This has been discussed in AVT some time ago, but not taken up
as a standards effort.

> A standard
> resynchronisation method would allow us to resync picture and sound
> (and whatever) with the users choise of sound tool and video tool,
> they do not _need_ to be the same software package. But then, one can
> allways dream.

Some host internal mechanisms have been implemented.  RAT and vic can
synchronize, for example.
							-- Steve



From rem-conf-request@es.net Wed Apr 23 03:26:24 1997 
Received: from netra (actually netra.nju.edu.cn) by osi-west.es.net 
          with ESnet SMTP (PP); Wed, 23 Apr 1997 00:25:18 -0700
Received: from graphics.nju.edu.cn by netra (5.x/SMI-SVR4) id AB01296;
          Wed, 23 Apr 1997 15:20:04 -0800
Message-Id: <335DB8E9.476F@graphics.nju.edu.cn>
Date: Wed, 23 Apr 1997 15:23:21 +0800
From: WANG Jian <wangjian@graphics.nju.edu.cn>
Reply-To: wangjian@doctor4u.com
Organization: NJU
X-Mailer: Mozilla 2.0 (Macintosh; I; PPC)
Mime-Version: 1.0
To: rem-conf@es.net
Subject: help
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

hi,

I am making plans for a project on real-time collaberative system.

I want to know
1, the prices of QuickTime Conferencing products, and
2, the products of mac-based shared editor or collaberative writer and
their prices.

If you response I appreciate it.

Thanks,
WANG Jian

From rem-conf-request@es.net Wed Apr 23 20:50:44 1997 
Received: from hosim.kwangju.ac.kr (actually 202.30.35.43) by osi-west.es.net 
          with ESnet SMTP (PP); Wed, 23 Apr 1997 17:50:38 -0700
Received: from vclab2.kwangju.ac.kr ([203.230.110.213]) 
          by hosim.kwangju.ac.kr (8.7.1H1/8.7.1) with SMTP id KAA08625 
          for <rem-conf@es.net>; Thu, 24 Apr 1997 10:50:26 -0700 (PDT)
Message-ID: <335EADE8.45F@cosmos.kwangju.ac.kr>
Date: Thu, 24 Apr 1997 09:48:40 +0900
From: Jeongmin Cho <com4122@cosmos.kwangju.ac.kr>
Reply-To: com4122@cosmos.kwangju.ac.kr
Organization: Dept. of computer science, Kwangju University
X-Mailer: Mozilla 3.0 (Win95; I)
MIME-Version: 1.0
To: rem-conf@es.net
Subject: subscribe
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

subscribe
-- 

---------------------------------------------------------
 _/     _/  _/_/ _/     Video Communication Laboratory,
  _/   _/ _/     _/     Kwangju University
   _/ _/  _/     _/     mailto:com4122@cosmos.kwangju.ac.kr 
    _/     _/_/  _/_/_/ 502-703 Jeongmin Cho
                        592-1 Jinwol-dong Namgu, 
                        Kwangju in Korea. 
   Tel: 062-670-2564    Dept. of Computer science
   Fax: 062-670-2187
---------------------------------------------------------

From rem-conf-request@es.net Thu Apr 24 15:11:00 1997 
Received: from nobozo.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP);
          Thu, 24 Apr 1997 12:10:44 -0700
Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) 
          by nobozo.CS.Berkeley.EDU (8.6.10/8.6.3) with SMTP id MAA24278;
          Thu, 24 Apr 1997 12:10:42 -0700
Date: Thu, 24 Apr 1997 12:10:42 -0700
Message-Id: <199704241910.MAA24278@nobozo.CS.Berkeley.EDU>
X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU
X-Mailer: Windows Eudora Version 2.1.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: 298-list@bmrc.Berkeley.EDU, rem-conf@es.net
From: Jerrlyn Iwata <jerrlyn@postgres.Berkeley.EDU>
Subject: Berkeley Multimedia & Graphics seminar

                Berkeley Multimedia and Graphics Seminar 
        (Wednesday April 30, 1997 12:30-2:00 PDT 405 Soda Hall) 

               "Video Streaming: A View from the Trenches" 

                                Hank Magnuski 
                        Internet Video Services, Inc. 

This last year has witnessed an explosion of video streaming technologies
available on the Internet. Starting with the initial products by companies
such as VDO-Net and Xing, there has been a parade of new entrants including
Vivo,
Progressive Networks, WebTV, Iterated, Motorola, VXtreme, Vosaic, Microsoft,
Precept, Oracle and others.

Millions are being spent in a battle for ownership of the Internet's video
viewing audience.

This talk will take a close look at this marketplace and will review some of
the issues related to making these products ready for "prime time".
--------------------------------------------------------------------------------

This seminar will be broadcast on the Internet MBONE. The broadcast will
begin at 12:40 PDT (GMT - 8 hrs). See sdr or http://bmrc.berkeley.edu/298
for instructions on setting up, connecting to, and operating the MBONE tools.

Please direct all technical questions to davesimp@cs.berkeley.edu



From rem-conf-request@tmpmail.es.net Thu Apr 24 15:41:50 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Thu, 24 Apr 1997 12:41:46 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wKTvJ-0000yw-00; Thu, 24 Apr 1997 12:11:17 -0700
Date: Thu, 24 Apr 1997 12:10:42 -0700
Message-Id: <199704241910.MAA24278@nobozo.CS.Berkeley.EDU>
X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU
X-Mailer: Windows Eudora Version 2.1.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: 298-list@bmrc.Berkeley.EDU, rem-conf@es.net
From: Jerrlyn Iwata <jerrlyn@postgres.Berkeley.EDU>
Subject: Berkeley Multimedia & Graphics seminar
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

                Berkeley Multimedia and Graphics Seminar 
        (Wednesday April 30, 1997 12:30-2:00 PDT 405 Soda Hall) 

               "Video Streaming: A View from the Trenches" 

                                Hank Magnuski 
                        Internet Video Services, Inc. 

This last year has witnessed an explosion of video streaming technologies
available on the Internet. Starting with the initial products by companies
such as VDO-Net and Xing, there has been a parade of new entrants including
Vivo,
Progressive Networks, WebTV, Iterated, Motorola, VXtreme, Vosaic, Microsoft,
Precept, Oracle and others.

Millions are being spent in a battle for ownership of the Internet's video
viewing audience.

This talk will take a close look at this marketplace and will review some of
the issues related to making these products ready for "prime time".
--------------------------------------------------------------------------------

This seminar will be broadcast on the Internet MBONE. The broadcast will
begin at 12:40 PDT (GMT - 8 hrs). See sdr or http://bmrc.berkeley.edu/298
for instructions on setting up, connecting to, and operating the MBONE tools.

Please direct all technical questions to davesimp@cs.berkeley.edu




From rem-conf-request@es.net Thu Apr 24 18:20:59 1997 
Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP);
          Thu, 24 Apr 1997 15:20:53 -0700
Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) 
          by rah.star-gate.com (8.8.5/8.7.3) with ESMTP id PAA03778 
          for <rem-conf@es.net>; Thu, 24 Apr 1997 15:20:53 -0700 (PDT)
Message-Id: <199704242220.PAA03778@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: rem-conf@es.net
Subject: Video capture driver for Bt848 based cards
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 24 Apr 1997 15:20:53 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>



Latest Bt848 driver available from :
http://freebsd.org/~fsmp/HomeAuto/Bt848.html
ftp://rah.star-gate.com/bt848-clip.tar.gz. 

The Bt848 driver has been incorporated to  FreeBSD 3.0-current. 

Tested boards are:
	  Hauppage's Wincast TV 
          The STB TV PCI Television Tuner 
          Miro PC TV in theory ONLY, never actually tried yet 
          Intel's Smart Video Recorder III 

The Bt848's dma controller is controlled by "Risc Instructions" which
can instruct the dma  controller to write to memory x number of bytes, skip
pixels, wait for a frame, jump to a location, etc... Additionally,
the Bt848 is a bus master device .

The latest driver  supports PAL, hardware clipping, and swapping the pixel
order RGB vs BGR. The last two features are useful when the Bt848 transfers
video directly to a video display's frame buffer. An alpha application
which demonstrates the PCI to PCI transfer is fxtv 
http://multiverse.com/~rhh/fxtv/. It does not support hardware clipping
nor pixel order swapping,yet.

vic's meteor driver module should work with the bt848 driver .
While vic is running  with xtvremote you can control the tuner .
By enlarge the Bt848 is fully compatible with the FreeBSD Matrox Meteor;however,
the Bt848's ioctl was augmented to exploit features found in the chipset
plus tuner support capability.

As to the quality of the video is pretty good . Side by side comparison
with my TV shows that the quality to be rather nice in fact with
some images my monitor looks better 8) You will need a good monitor
to approach TV quality. For instance, my Nano F550i is rather dull;however,
with my Sony Triton 15sx TV viewing is very nice. With apps such as fxtv
using the PCI to PCI transfer the driver supports 640x480 32bits at 
frames/sec . 


The driver is cleanly structured so it should not be too hard to port
to different OSes . For instance, I ported an earlier version of the
driver to win95 mostly because I needed to support a real time
stereoscopic application.

Last but not least , Bt848 based cards are cheap or dirt cheap. I have
read about a  WinCast TV,tuner + dbx stereo selling for $110.
Do a net search to locate a dealer near you ..

As it stands today, the Bt848 is now a group effort out of the 
FreeBSD multimedia group and I made sure that the appropiate individuals 
are credited with each commit to the driver.

	Enjoy,
	Amancio



From rem-conf-request@tmpmail.es.net Thu Apr 24 18:27:09 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Thu, 24 Apr 1997 15:27:05 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wKWsv-0001g1-00; Thu, 24 Apr 1997 15:21:01 -0700
Message-Id: <199704242220.PAA03778@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: rem-conf@es.net
Subject: Video capture driver for Bt848 based cards
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 24 Apr 1997 15:20:53 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list



Latest Bt848 driver available from :
http://freebsd.org/~fsmp/HomeAuto/Bt848.html
ftp://rah.star-gate.com/bt848-clip.tar.gz. 

The Bt848 driver has been incorporated to  FreeBSD 3.0-current. 

Tested boards are:
	  Hauppage's Wincast TV 
          The STB TV PCI Television Tuner 
          Miro PC TV in theory ONLY, never actually tried yet 
          Intel's Smart Video Recorder III 

The Bt848's dma controller is controlled by "Risc Instructions" which
can instruct the dma  controller to write to memory x number of bytes, skip
pixels, wait for a frame, jump to a location, etc... Additionally,
the Bt848 is a bus master device .

The latest driver  supports PAL, hardware clipping, and swapping the pixel
order RGB vs BGR. The last two features are useful when the Bt848 transfers
video directly to a video display's frame buffer. An alpha application
which demonstrates the PCI to PCI transfer is fxtv 
http://multiverse.com/~rhh/fxtv/. It does not support hardware clipping
nor pixel order swapping,yet.

vic's meteor driver module should work with the bt848 driver .
While vic is running  with xtvremote you can control the tuner .
By enlarge the Bt848 is fully compatible with the FreeBSD Matrox Meteor;however,
the Bt848's ioctl was augmented to exploit features found in the chipset
plus tuner support capability.

As to the quality of the video is pretty good . Side by side comparison
with my TV shows that the quality to be rather nice in fact with
some images my monitor looks better 8) You will need a good monitor
to approach TV quality. For instance, my Nano F550i is rather dull;however,
with my Sony Triton 15sx TV viewing is very nice. With apps such as fxtv
using the PCI to PCI transfer the driver supports 640x480 32bits at 
frames/sec . 


The driver is cleanly structured so it should not be too hard to port
to different OSes . For instance, I ported an earlier version of the
driver to win95 mostly because I needed to support a real time
stereoscopic application.

Last but not least , Bt848 based cards are cheap or dirt cheap. I have
read about a  WinCast TV,tuner + dbx stereo selling for $110.
Do a net search to locate a dealer near you ..

As it stands today, the Bt848 is now a group effort out of the 
FreeBSD multimedia group and I made sure that the appropiate individuals 
are credited with each commit to the driver.

	Enjoy,
	Amancio




From rem-conf-request@es.net Thu Apr 24 20:17:23 1997 
Received: from condor.CC.UMontreal.CA by osi-west.es.net with ESnet SMTP (PP);
          Thu, 24 Apr 1997 17:17:06 -0700
Received: from eole.ERE.UMontreal.CA (eole.ERE.UMontreal.CA [132.204.2.70]) 
          by condor.CC.UMontreal.CA with ESMTP id UAA04340 (8.6.11/IDA-1.6);
          Thu, 24 Apr 1997 20:11:36 -0400
Received: from mistral.ERE.UMontreal.CA 
          by eole.ERE.UMontreal.CA (951211.SGI.8.6.12.PATCH1042/5.17) 
          id UAA24697; Thu, 24 Apr 1997 20:16:19 -0400
Received: from [142.62.1.234] 
          by mistral.ERE.UMontreal.CA (951211.SGI.8.6.12.PATCH1042/5.17) 
          id MAA02362; Thu, 24 Apr 1997 12:28:40 -0400
X-Sender: muzardj@mistral.ere.umontreal.ca
Message-Id: <v0153051caf8532eaa35a@[142.62.1.234]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 24 Apr 1997 12:30:43 -0400
To: wangjian@doctor4u.com, confctrl@isi.edu
From: muzardj@ERE.UMontreal.CA (Joel Muzard)
Subject: Re: help
Cc: cscw-sig@mailbase.ac.uk, rem-conf@es.net, vidconf@pulver.com, 
    videophone@es.net, VIDNET-L@uga.cc.uga.edu

At 12:12 23/04/97, WANG Jian wrote:
>hi,
>
>I am making plans for a project on real-time collaberative system.
>
>I want to know
>1, the prices of QuickTime Conferencing products, and
>2, the products of mac-based shared editor or collaberative writer and
>their prices.

I invite you to have a look at http://ideaprocessor.citi.doc.ca
If you have questions, then contact me.

Joel



--------------*

Dr. Joel Muzard
President
Atelier d'informatique appliquee (AiA) Inc.
(514) 973-5769
(514) 973-5757 Fax-telecopieur
WWW:
http://IdeaProcessor.citi.doc.ca/



From rem-conf-request@tmpmail.es.net Thu Apr 24 20:20:45 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Thu, 24 Apr 1997 17:20:41 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wKYhV-0002K9-00; Thu, 24 Apr 1997 17:17:21 -0700
X-Sender: muzardj@mistral.ere.umontreal.ca
Message-Id: <v0153051caf8532eaa35a@[142.62.1.234]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 24 Apr 1997 12:30:43 -0400
To: wangjian@doctor4u.com, confctrl@isi.edu
From: muzardj@ERE.UMontreal.CA (Joel Muzard)
Subject: Re: help
Cc: cscw-sig@mailbase.ac.uk, rem-conf@es.net, vidconf@pulver.com, 
    videophone@es.net, VIDNET-L@uga.cc.uga.edu
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

At 12:12 23/04/97, WANG Jian wrote:
>hi,
>
>I am making plans for a project on real-time collaberative system.
>
>I want to know
>1, the prices of QuickTime Conferencing products, and
>2, the products of mac-based shared editor or collaberative writer and
>their prices.

I invite you to have a look at http://ideaprocessor.citi.doc.ca
If you have questions, then contact me.

Joel



--------------*

Dr. Joel Muzard
President
Atelier d'informatique appliquee (AiA) Inc.
(514) 973-5769
(514) 973-5757 Fax-telecopieur
WWW:
http://IdeaProcessor.citi.doc.ca/




From rem-conf-request@es.net Fri Apr 25 10:24:10 1997 
Received: from dirty.research.bell-labs.com by osi-west.es.net 
          with ESnet SMTP (PP); Fri, 25 Apr 1997 07:24:04 -0700
Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty;
          Fri Apr 25 10:22:46 EDT 1997
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by research;
          Fri Apr 25 10:22:45 EDT 1997
Received: from arrakis (arrakis [135.180.130.41]) 
          by zubin.dnrc.bell-labs.com (8.7.5/8.7.3) with SMTP id KAA27658 
          for <rem-conf@es.net>; Fri, 25 Apr 1997 10:22:51 -0400 (EDT)
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Message-Id: <970425102238.ZM10854@arrakis>
Date: Fri, 25 Apr 1997 10:22:37 -0700
X-Mailer: Z-Mail 4.0.1 (4.0.1 Apr 9 1996)
To: rem-conf@es.net
Subject: Reconsideration and the plateau effect
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii


Henning and I have discussed the comments raised during the IETF meeting 
concerning the "plateau effect" in the RTCP timer reconsideration 
algorithm [for those that missed it, the plateau effect is a halt in 
transmission of RTCP reports following a brief period of congestion 
after a number of users simultaneously join an RTP multicast group]. It 
is our belief that this is simply not a problem, and that pursuing 
alternate algorithms at this late stage may lead to overly complex 
solutions, or, even worse, solutions whose behavior is not well 
understood.

The plateau effect is purely an artifact of the step join abstraction. 
As the join process becomes more sloped, or even jagged, both the height 
of the initial spike and the duration of this plateau (they are linearly 
related) disappear. As soon as the slope of the join reaches N divided 
by the network delays (N is the number who join), the spike and plateau 
are roughly halfed compared to a step join. In fact, our simulations 
have shown that when the join rate is around 500 users per second, the 
plateau is about 1 second in duration. As the slope decreases, the 
plateau decreases with it. (See our Columbia University Technical 
Report, "Scaling Feedback to Very Large Groups"; an I-D is coming soon 
with the same content).

We believe we have a good understanding of unconditional 
reconsideration; we have looked at fairness, synchronization, steady 
state behavior, etc. Our simulations and analysis have led us to believe 
that there will be no "surprises"; that the behavior seems stable and 
social. Certainly, alternate algorithms which avoid this plateau will be 
more complex, making it more likely that behavior may be even worse in 
some unexpected situations. More complex algorithms also lead to the 
possibility of incorrect implementations.

There is also the practical issue of time; given the speed with which we 
want to move to draft standard, the time required to develop, simulate, 
implement, and test new algorithms doesn't fit into the schedule.

So, given that we feel the plateau effect is not likely to show up in 
real systems, and that other algorithms which do not exhibit it are more 
complex and potentially antisocial, and our time constraints, we feel 
that unconditional reconsideration remains the best solution.

-- 
Jonathan Rosenberg			Lucent Technologies
Member of Technical Staff		Bell Laboratories
High Speed Networks Research		101 Crawfords Corner Rd.
PHONE: (908) 949-6418			Holmdel, NJ 07733
FAX:   (908) 834-5379			Rm. 4D-534B
EMAIL: jdrosen@bell-labs.com

From rem-conf-request@tmpmail.es.net Fri Apr 25 10:36:05 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Fri, 25 Apr 1997 07:36:02 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wKlv4-0004AO-00; Fri, 25 Apr 1997 07:24:14 -0700
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Message-Id: <970425102238.ZM10854@arrakis>
Date: Fri, 25 Apr 1997 10:22:37 -0700
X-Mailer: Z-Mail 4.0.1 (4.0.1 Apr 9 1996)
To: rem-conf@es.net
Subject: Reconsideration and the plateau effect
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


Henning and I have discussed the comments raised during the IETF meeting 
concerning the "plateau effect" in the RTCP timer reconsideration 
algorithm [for those that missed it, the plateau effect is a halt in 
transmission of RTCP reports following a brief period of congestion 
after a number of users simultaneously join an RTP multicast group]. It 
is our belief that this is simply not a problem, and that pursuing 
alternate algorithms at this late stage may lead to overly complex 
solutions, or, even worse, solutions whose behavior is not well 
understood.

The plateau effect is purely an artifact of the step join abstraction. 
As the join process becomes more sloped, or even jagged, both the height 
of the initial spike and the duration of this plateau (they are linearly 
related) disappear. As soon as the slope of the join reaches N divided 
by the network delays (N is the number who join), the spike and plateau 
are roughly halfed compared to a step join. In fact, our simulations 
have shown that when the join rate is around 500 users per second, the 
plateau is about 1 second in duration. As the slope decreases, the 
plateau decreases with it. (See our Columbia University Technical 
Report, "Scaling Feedback to Very Large Groups"; an I-D is coming soon 
with the same content).

We believe we have a good understanding of unconditional 
reconsideration; we have looked at fairness, synchronization, steady 
state behavior, etc. Our simulations and analysis have led us to believe 
that there will be no "surprises"; that the behavior seems stable and 
social. Certainly, alternate algorithms which avoid this plateau will be 
more complex, making it more likely that behavior may be even worse in 
some unexpected situations. More complex algorithms also lead to the 
possibility of incorrect implementations.

There is also the practical issue of time; given the speed with which we 
want to move to draft standard, the time required to develop, simulate, 
implement, and test new algorithms doesn't fit into the schedule.

So, given that we feel the plateau effect is not likely to show up in 
real systems, and that other algorithms which do not exhibit it are more 
complex and potentially antisocial, and our time constraints, we feel 
that unconditional reconsideration remains the best solution.

-- 
Jonathan Rosenberg			Lucent Technologies
Member of Technical Staff		Bell Laboratories
High Speed Networks Research		101 Crawfords Corner Rd.
PHONE: (908) 949-6418			Holmdel, NJ 07733
FAX:   (908) 834-5379			Rm. 4D-534B
EMAIL: jdrosen@bell-labs.com


From rem-conf-request@es.net Fri Apr 25 11:07:00 1997 
Received: from basil.cdt.luth.se by osi-west.es.net with ESnet SMTP (PP);
          Fri, 25 Apr 1997 08:06:51 -0700
Received: from ganymede.cdt.luth.se (ganymede.cdt.luth.se [130.240.64.41]) 
          by basil.cdt.luth.se (8.7.5/8.7.3) with ESMTP id RAA05177;
          Fri, 25 Apr 1997 17:04:04 +0200 (MET DST)
Received: from ganymede.cdt.luth.se (localhost [127.0.0.1]) 
          by ganymede.cdt.luth.se (8.6.12/8.6.12) with ESMTP id RAA20152;
          Fri, 25 Apr 1997 17:06:20 +0200
Message-Id: <199704251506.RAA20152@ganymede.cdt.luth.se>
X-Mailer: exmh version 1.6.7 5/3/96
To: Amancio Hasty <hasty@rah.star-gate.com>
cc: rem-conf@es.net
Subject: Re: Video capture driver for Bt848 based cards
In-reply-to: Your message of "Thu, 24 Apr 1997 15:20:53 PDT." <199704242220.PAA03778@rah.star-gate.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Date: Fri, 25 Apr 1997 17:06:19 +0200
From: Hakan Lennestal <hakanl@cdt.luth.se>
Content-Transfer-Encoding: quoted-printable

In message <199704242220.PAA03778@rah.star-gate.com>, Amancio Hasty write=
s:
>=20
>=20
> Latest Bt848 driver available from :
> http://freebsd.org/~fsmp/HomeAuto/Bt848.html
> ftp://rah.star-gate.com/bt848-clip.tar.gz.=20
>=20
> The Bt848 driver has been incorporated to  FreeBSD 3.0-current.=20

Hi !

Do you know if there is any work going on to port this to Linux ?

Regards.

/H=E5kan


From rem-conf-request@tmpmail.es.net Fri Apr 25 11:16:30 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Fri, 25 Apr 1997 08:16:26 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wKmaT-0004Wu-00; Fri, 25 Apr 1997 08:07:01 -0700
Message-Id: <199704251506.RAA20152@ganymede.cdt.luth.se>
X-Mailer: exmh version 1.6.7 5/3/96
To: Amancio Hasty <hasty@rah.star-gate.com>
cc: rem-conf@es.net
Subject: Re: Video capture driver for Bt848 based cards
In-reply-to: Your message of "Thu, 24 Apr 1997 15:20:53 PDT." <199704242220.PAA03778@rah.star-gate.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Date: Fri, 25 Apr 1997 17:06:19 +0200
From: Hakan Lennestal <hakanl@cdt.luth.se>
Content-Transfer-Encoding: quoted-printable
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

In message <199704242220.PAA03778@rah.star-gate.com>, Amancio Hasty write=
s:
>=20
>=20
> Latest Bt848 driver available from :
> http://freebsd.org/~fsmp/HomeAuto/Bt848.html
> ftp://rah.star-gate.com/bt848-clip.tar.gz.=20
>=20
> The Bt848 driver has been incorporated to  FreeBSD 3.0-current.=20

Hi !

Do you know if there is any work going on to port this to Linux ?

Regards.

/H=E5kan



From rem-conf-request@es.net Fri Apr 25 13:02:06 1997 
Received: from xn1-gw.atlas.fr (actually xn1-b.atlas.fr) by osi-west.es.net 
          with ESnet SMTP (PP); Fri, 25 Apr 1997 10:01:54 -0700
X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed;
               Fri, 25 Apr 1997 19:02:35 +0200
X400-Received: by mta xn1-gw.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/;
               Relayed; Fri, 25 Apr 1997 19:02:35 +0200
X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Fri, 25 Apr 1997 18:35:34 +0200
X400-Received: by /PRMD=cnet/ADMD=atlas/C=FR/; Relayed;
               Fri, 25 Apr 1997 19:51:22 +0200
Date: Fri, 25 Apr 1997 19:51:22 +0200
X400-Originator: haignere@issy.cnet.fr
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/PRMD=cnet/ADMD=atlas/C=FR/;861979898@x400.issy.cnet.fr]
X400-Content-Type: P2-1984 (2)
Content-Identifier: g723 payloads
Alternate-Recipient: Allowed
From: Isabelle HAIGNERE <haignere@issy.cnet.fr>
Message-ID: <9704251451.AA01082@haddock>
To: rem-conf@es.net, casner@precept.com, isabelle.haignere@issy.cnet.fr
Subject: g723 payloads
Content-Length: 1088

*-------------------------------------------------------*
|       From :  Isabelle Haignere                       |
|               CNET - PAB/STC/SGV                      |
|               38-40 rue du General Leclerc            |
|               F-92 131 Issy les Moulineaux            |
|               FRANCE                                  |
|                                                       |
|               Tel.   : + 33 1 45 29 40 08             |
|               Fax.   : + 33 1 45 29 52 94             |
|                                                       |
|               E-mail : isabelle.haignere@issy.cnet.fr |
*-------------------------------------------------------*

Hello,

In the profile of RTP-RFC1890, the G723 payload has been defined and
moreover I have received the G723 RTP payload from Ken Mills from Intel
through the rem-conf mailing-list, what about the precise status of this
document and the G723 payload ? Is this version the last version of the
G723 rtp payload ?

I thank you very much for your response.

Best regards.


Isabelle HAIGNERE 

From rem-conf-request@tmpmail.es.net Fri Apr 25 13:17:42 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Fri, 25 Apr 1997 10:17:33 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wKoNt-0005CX-00; Fri, 25 Apr 1997 10:02:09 -0700
X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed;
               Fri, 25 Apr 1997 19:02:35 +0200
X400-Received: by mta xn1-gw.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/;
               Relayed; Fri, 25 Apr 1997 19:02:35 +0200
X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Fri, 25 Apr 1997 18:35:34 +0200
X400-Received: by /PRMD=cnet/ADMD=atlas/C=FR/; Relayed;
               Fri, 25 Apr 1997 19:51:22 +0200
Date: Fri, 25 Apr 1997 19:51:22 +0200
X400-Originator: haignere@issy.cnet.fr
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/PRMD=cnet/ADMD=atlas/C=FR/;861979898@x400.issy.cnet.fr]
X400-Content-Type: P2-1984 (2)
Content-Identifier: g723 payloads
Alternate-Recipient: Allowed
From: Isabelle HAIGNERE <haignere@issy.cnet.fr>
Message-ID: <9704251451.AA01082@haddock>
To: rem-conf@es.net, casner@precept.com, isabelle.haignere@issy.cnet.fr
Subject: g723 payloads
Content-Length: 1088
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

*-------------------------------------------------------*
|       From :  Isabelle Haignere                       |
|               CNET - PAB/STC/SGV                      |
|               38-40 rue du General Leclerc            |
|               F-92 131 Issy les Moulineaux            |
|               FRANCE                                  |
|                                                       |
|               Tel.   : + 33 1 45 29 40 08             |
|               Fax.   : + 33 1 45 29 52 94             |
|                                                       |
|               E-mail : isabelle.haignere@issy.cnet.fr |
*-------------------------------------------------------*

Hello,

In the profile of RTP-RFC1890, the G723 payload has been defined and
moreover I have received the G723 RTP payload from Ken Mills from Intel
through the rem-conf mailing-list, what about the precise status of this
document and the G723 payload ? Is this version the last version of the
G723 rtp payload ?

I thank you very much for your response.

Best regards.


Isabelle HAIGNERE 


From rem-conf-request@es.net Fri Apr 25 14:17:51 1997 
Received: from ruby.cisco.com by osi-west.es.net with ESnet SMTP (PP);
          Fri, 25 Apr 1997 11:17:31 -0700
Received: (mahesh@localhost) by ruby.cisco.com (8.6.12/8.6.5) id LAA00542 
          for rem-conf@es.net; Fri, 25 Apr 1997 11:17:31 -0700
Date: Fri, 25 Apr 1997 11:17:31 -0700
From: Mahesh Jethanandani <mahesh@cisco.com>
Message-Id: <199704251817.LAA00542@ruby.cisco.com>
To: rem-conf@es.net
Subject: Sources for wb
X-Sun-Charset: US-ASCII

I am looking for sources for wb to compile for Solaris x86. Any pointers
to sources or binaries would be helpful.

Thanks

Mahesh Jethanandani

|\/\/\/|                              |      mahesh@cisco.com
|  \  /|   LIFE'S COMPLEX - IT HAS    |      Cisco Systems Inc.
| (o)(o)   REAL & IMAGINARY PARTS     |      170 West Tasman Drive
C      _)                             |      San Jose, CA 95134
| \___|                               |	     (408) 527-8230
 |   /   All Std. Disclaimers apply.  |      (408) 527-8254(fax)


From rem-conf-request@tmpmail.es.net Fri Apr 25 14:29:22 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Fri, 25 Apr 1997 11:29:18 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wKpZA-0005mD-00; Fri, 25 Apr 1997 11:17:52 -0700
Date: Fri, 25 Apr 1997 11:17:31 -0700
From: Mahesh Jethanandani <mahesh@cisco.com>
Message-Id: <199704251817.LAA00542@ruby.cisco.com>
To: rem-conf@es.net
Subject: Sources for wb
X-Sun-Charset: US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

I am looking for sources for wb to compile for Solaris x86. Any pointers
to sources or binaries would be helpful.

Thanks

Mahesh Jethanandani

|\/\/\/|                              |      mahesh@cisco.com
|  \  /|   LIFE'S COMPLEX - IT HAS    |      Cisco Systems Inc.
| (o)(o)   REAL & IMAGINARY PARTS     |      170 West Tasman Drive
C      _)                             |      San Jose, CA 95134
| \___|                               |	     (408) 527-8230
 |   /   All Std. Disclaimers apply.  |      (408) 527-8254(fax)



From rem-conf-request@es.net Fri Apr 25 16:12:32 1997 
Received: from nobozo.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP);
          Fri, 25 Apr 1997 13:12:26 -0700
Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) 
          by nobozo.CS.Berkeley.EDU (8.6.10/8.6.3) with SMTP id NAA32318;
          Fri, 25 Apr 1997 13:12:23 -0700
Date: Fri, 25 Apr 1997 13:12:23 -0700
Message-Id: <199704252012.NAA32318@nobozo.CS.Berkeley.EDU>
X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU
X-Mailer: Windows Eudora Version 2.1.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: 298-list@bmrc.Berkeley.EDU, rem-conf@es.net
From: Jerrlyn Iwata <jerrlyn@postgres.Berkeley.EDU>
Subject: Berkeley Multimedia & Graphics Seminar

                Berkeley Multimedia and Graphics Seminar 
        (Wednesday April 30, 1997 12:30-2:00 PDT 405 Soda Hall) 

               "Video Streaming: A View from the Trenches" 

                                Hank Magnuski 
                        Internet Video Services, Inc. 

This last year has witnessed an explosion of video streaming technologies
available on the Internet. Starting with the initial products by companies
such as VDO-Net and Xing, there has been a parade of new entrants including
Vivo,
Progressive Networks, WebTV, Iterated, Motorola, VXtreme, Vosaic, Microsoft,
Precept, Oracle and others.

Millions are being spent in a battle for ownership of the Internet's video
viewing audience.

This talk will take a close look at this marketplace and will review some of
the issues related to making these products ready for "prime time".
--------------------------------------------------------------------------------

This seminar will be broadcast on the Internet MBONE. The broadcast will
begin at 12:40 PDT (GMT - 8 hrs). See sdr or http://bmrc.berkeley.edu/298
for instructions on setting up, connecting to, and operating the MBONE tools.

Please direct all technical questions to davesimp@cs.berkeley.edu



From rem-conf-request@tmpmail.es.net Fri Apr 25 16:27:30 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Fri, 25 Apr 1997 13:27:21 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wKrMA-0006Wr-00; Fri, 25 Apr 1997 13:12:34 -0700
Date: Fri, 25 Apr 1997 13:12:23 -0700
Message-Id: <199704252012.NAA32318@nobozo.CS.Berkeley.EDU>
X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU
X-Mailer: Windows Eudora Version 2.1.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: 298-list@bmrc.Berkeley.EDU, rem-conf@es.net
From: Jerrlyn Iwata <jerrlyn@postgres.Berkeley.EDU>
Subject: Berkeley Multimedia & Graphics Seminar
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

                Berkeley Multimedia and Graphics Seminar 
        (Wednesday April 30, 1997 12:30-2:00 PDT 405 Soda Hall) 

               "Video Streaming: A View from the Trenches" 

                                Hank Magnuski 
                        Internet Video Services, Inc. 

This last year has witnessed an explosion of video streaming technologies
available on the Internet. Starting with the initial products by companies
such as VDO-Net and Xing, there has been a parade of new entrants including
Vivo,
Progressive Networks, WebTV, Iterated, Motorola, VXtreme, Vosaic, Microsoft,
Precept, Oracle and others.

Millions are being spent in a battle for ownership of the Internet's video
viewing audience.

This talk will take a close look at this marketplace and will review some of
the issues related to making these products ready for "prime time".
--------------------------------------------------------------------------------

This seminar will be broadcast on the Internet MBONE. The broadcast will
begin at 12:40 PDT (GMT - 8 hrs). See sdr or http://bmrc.berkeley.edu/298
for instructions on setting up, connecting to, and operating the MBONE tools.

Please direct all technical questions to davesimp@cs.berkeley.edu




From rem-conf-request@es.net Fri Apr 25 19:28:57 1997 
Received: from nwau.nw.mt.np.els-gms.att.net by osi-west.es.net 
          with ESnet SMTP (PP); Fri, 25 Apr 1997 16:28:50 -0700
Date: Fri, 25 Apr 1997 19:27:44 -0500
From: cdvorak@attmail.com (Charles A Dvorak)
Received: from cdvorak by attmail; Fri Apr 25 23:27:30 GMT 1997
Subject: Internet telephony performance
To: rem-conf@es.net, voip-tech@vocaltec.com
Cc: caomj@online.sh.cn, paulcov@nortel.ca, simao@ctd.comsat.com, 
    judith.katona@itu.int, petrack@vocaltec.com
Mime-Version: 1.0
Content-Type: application/octet-stream
Content-Transfer-Encoding: quoted-printable
Message-ID: <winATT-3.01-cdvorak-2299>

Mailing lists of the IETF and the IMTC VOIP group:=0D
=0D
Below is an =22informal communication=22 which ITU-T Study Group 12,=0D
whose mandate is end-to-end transmission quality, agreed to=0D
send to the IETF and the IMTC VOIP Activity Group. SG 12 wants=0D
to share our information with the international community=0D
working in Internet telephony, and we're happy to collaborate.=0D
=0D
I have been instructed that the most effective way to disseminate=0D
this note is in ASCII via the e-mail lists to which I have sent it.=0D
(Apologies in advance if this in not correct.)=0D
=0D
Thanks,=0D
=0D
Chuck Dvorak, SG12 Vice Chairman on behalf of SG12=0D
=0D
=0C=0D
ITU - Telecommun. Standardization Sector=09=09Temp. Doc 014-E (PL12) =0D
=0D
STUDY GROUP 12=0D
______________________________ =0D
=0D
Geneva, 7 - 18 April 1997 =0D
Questions: 16/12, 18/12, 19/12, 21/12=0D
=0D
SOURCE:=09Study Group 12=0D
=0D
Subject:=09Speech Quality Aspects of Internet Telephony=0D
=0D
To:=09=09ITU-T SG 16 (for action)=0D
=09=09ITU-T SGs 2, 13, 15 (for information)=0D
=09=09IETF, IMTC VoIP Activity Group (for information)=0D
=0D
Approval:=09ITU-T SG 12=0D
=0D
Deadline for Reply:=0930 days after next meeting of  Q.13/16=0D
=0D
Contacts:=09Paul Coverdale, Chairman WP 2/12=0D
=09=09Tel / Fax: +1.613.763.4277 / 1.613.763.9029=0D
=09=09E-mail: paulcov=40nortel.ca=0D
=0D
=09=09Charles Dvorak, Chairman WP 3/12=0D
=09=09Tel / Fax: +1.908.580.6418 / 1.908.580.6881=0D
=09=09E-mail: cdvorak=40attmail.com=0D
=0D
SG 12 thanks SG16 for its invitation to collaborate on Internet =0D
telephony. SG 12 welcomes this collaboration because of our =0D
expertise on multimedia subjective and objective assessment (WP =0D
2/12), and on transmission performance and planning (WP 3/12). =0D
These areas are likely to be critical to the success of Internet =0D
telephony, and we gladly offer the benefits of our experience. =0D
=0D
To contribute immediately to the collaboration on Internet =0D
telephony, SG 12 offers information that it hopes will be useful, =0D
given the SG 16 activities described in the liaison we received.=0D
=0D
SG 12 is very concerned about the potential selection of a default =0D
speech codec for H.323v2 in the apparent absence of adequate =0D
consideration of the transmission performance implications of any =0D
such selection. In our opinion there are many aspects of end-to-end =0D
quality, but two major considerations in this case are the ability =0D
of a codec to interwork with other elements of the overall =0D
connection, and the delay inserted into the connection by the =0D
codec. These factors can have a serious negative impact on the =0D
user=92s judgment of service quality.=0D
=0D
Regarding the effect of speech coding on transmission quality, the =0D
G.729 Annex A (G.729A) codec has been tested thoroughly by SG12 =0D
experts to assure that it satisfied the very stringent terms-of-=0D
reference required of a low bit-rate codec intended for multiple =0D
applications. These requirements included an ability to be tandemed =0D
with other types of codecs, so that no serious degradation of =0D
quality resulted. SG12 is unaware of any similar, comprehensive =0D
testing of the G.723.1 codec, which we understand was developed for =0D
videophone application. Thus, it is unclear how well G.723.1 will =0D
perform when interconnection to the PSTN is attempted.=0D
=0D
Regarding the effect of delay on the suitability of a connection =0D
for speech communications, it is our understanding that, due to =0D
processing delay and the way in which frames are arranged, a one-=0D
way delay of approximately 100 ms occurs with G.723.1, whereas =0D
G.729A introduces about a third of this amount. A value of 100 ms =0D
exceeds by 100% the signal processing delay allocation guidelines =0D
of G.114, which SG 12 revised recently to draw attention to the =0D
negative quality impact of such large processing delays. Thus, =0D
while the incremental transmission delay caused by G.723.1 may not =0D
be problematic for regional point-to-point applications over =0D
terrestrial facilities, such incremental delays will have a serious =0D
negative impact if added to transoceanic connections over which =0D
multipoint applications are used. This problem is not avoided by =0D
merely saying that G.723.1 should be used for multimedia applications.=0D=

=0D
Study Group 12 emphasizes that echo control is also likely to be a =0D
major issue with Internet telephony, and Recommendation G.131=0D
provides guidance in this area.=0D
=0D
In conclusion, SG12 recognizes the urgency for new Recommendations =0D
on Internet telephony, given the market pressures on the deployment=0D
of such applications. Accordingly, SG 12 applauds SG16 for=0D
aggressively tackling standards work on this important topic.=0D
However, as per the guidance we have provided in this document,=0D
pertinent information already exists that can be used by the ITU=0D
to make codec selections so that user applications are supported=0D
with acceptable quality.=0D
=09=09=09=09*****************=0D

From rem-conf-request@tmpmail.es.net Fri Apr 25 19:34:26 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Fri, 25 Apr 1997 16:34:22 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wKuQF-0007SX-00; Fri, 25 Apr 1997 16:28:59 -0700
Date: Fri, 25 Apr 1997 19:27:44 -0500
From: cdvorak@attmail.com (Charles A Dvorak)
Subject: Internet telephony performance
To: rem-conf@es.net, voip-tech@vocaltec.com
Cc: caomj@online.sh.cn, paulcov@nortel.ca, simao@ctd.comsat.com, 
    judith.katona@itu.int, petrack@vocaltec.com
Mime-Version: 1.0
Content-Type: application/octet-stream
Content-Transfer-Encoding: quoted-printable
Message-ID: <winATT-3.01-cdvorak-2299>
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Mailing lists of the IETF and the IMTC VOIP group:=0D
=0D
Below is an =22informal communication=22 which ITU-T Study Group 12,=0D
whose mandate is end-to-end transmission quality, agreed to=0D
send to the IETF and the IMTC VOIP Activity Group. SG 12 wants=0D
to share our information with the international community=0D
working in Internet telephony, and we're happy to collaborate.=0D
=0D
I have been instructed that the most effective way to disseminate=0D
this note is in ASCII via the e-mail lists to which I have sent it.=0D
(Apologies in advance if this in not correct.)=0D
=0D
Thanks,=0D
=0D
Chuck Dvorak, SG12 Vice Chairman on behalf of SG12=0D
=0D
=0C=0D
ITU - Telecommun. Standardization Sector=09=09Temp. Doc 014-E (PL12) =0D
=0D
STUDY GROUP 12=0D
______________________________ =0D
=0D
Geneva, 7 - 18 April 1997 =0D
Questions: 16/12, 18/12, 19/12, 21/12=0D
=0D
SOURCE:=09Study Group 12=0D
=0D
Subject:=09Speech Quality Aspects of Internet Telephony=0D
=0D
To:=09=09ITU-T SG 16 (for action)=0D
=09=09ITU-T SGs 2, 13, 15 (for information)=0D
=09=09IETF, IMTC VoIP Activity Group (for information)=0D
=0D
Approval:=09ITU-T SG 12=0D
=0D
Deadline for Reply:=0930 days after next meeting of  Q.13/16=0D
=0D
Contacts:=09Paul Coverdale, Chairman WP 2/12=0D
=09=09Tel / Fax: +1.613.763.4277 / 1.613.763.9029=0D
=09=09E-mail: paulcov=40nortel.ca=0D
=0D
=09=09Charles Dvorak, Chairman WP 3/12=0D
=09=09Tel / Fax: +1.908.580.6418 / 1.908.580.6881=0D
=09=09E-mail: cdvorak=40attmail.com=0D
=0D
SG 12 thanks SG16 for its invitation to collaborate on Internet =0D
telephony. SG 12 welcomes this collaboration because of our =0D
expertise on multimedia subjective and objective assessment (WP =0D
2/12), and on transmission performance and planning (WP 3/12). =0D
These areas are likely to be critical to the success of Internet =0D
telephony, and we gladly offer the benefits of our experience. =0D
=0D
To contribute immediately to the collaboration on Internet =0D
telephony, SG 12 offers information that it hopes will be useful, =0D
given the SG 16 activities described in the liaison we received.=0D
=0D
SG 12 is very concerned about the potential selection of a default =0D
speech codec for H.323v2 in the apparent absence of adequate =0D
consideration of the transmission performance implications of any =0D
such selection. In our opinion there are many aspects of end-to-end =0D
quality, but two major considerations in this case are the ability =0D
of a codec to interwork with other elements of the overall =0D
connection, and the delay inserted into the connection by the =0D
codec. These factors can have a serious negative impact on the =0D
user=92s judgment of service quality.=0D
=0D
Regarding the effect of speech coding on transmission quality, the =0D
G.729 Annex A (G.729A) codec has been tested thoroughly by SG12 =0D
experts to assure that it satisfied the very stringent terms-of-=0D
reference required of a low bit-rate codec intended for multiple =0D
applications. These requirements included an ability to be tandemed =0D
with other types of codecs, so that no serious degradation of =0D
quality resulted. SG12 is unaware of any similar, comprehensive =0D
testing of the G.723.1 codec, which we understand was developed for =0D
videophone application. Thus, it is unclear how well G.723.1 will =0D
perform when interconnection to the PSTN is attempted.=0D
=0D
Regarding the effect of delay on the suitability of a connection =0D
for speech communications, it is our understanding that, due to =0D
processing delay and the way in which frames are arranged, a one-=0D
way delay of approximately 100 ms occurs with G.723.1, whereas =0D
G.729A introduces about a third of this amount. A value of 100 ms =0D
exceeds by 100% the signal processing delay allocation guidelines =0D
of G.114, which SG 12 revised recently to draw attention to the =0D
negative quality impact of such large processing delays. Thus, =0D
while the incremental transmission delay caused by G.723.1 may not =0D
be problematic for regional point-to-point applications over =0D
terrestrial facilities, such incremental delays will have a serious =0D
negative impact if added to transoceanic connections over which =0D
multipoint applications are used. This problem is not avoided by =0D
merely saying that G.723.1 should be used for multimedia applications.=0D=

=0D
Study Group 12 emphasizes that echo control is also likely to be a =0D
major issue with Internet telephony, and Recommendation G.131=0D
provides guidance in this area.=0D
=0D
In conclusion, SG12 recognizes the urgency for new Recommendations =0D
on Internet telephony, given the market pressures on the deployment=0D
of such applications. Accordingly, SG 12 applauds SG16 for=0D
aggressively tackling standards work on this important topic.=0D
However, as per the guidance we have provided in this document,=0D
pertinent information already exists that can be used by the ITU=0D
to make codec selections so that user applications are supported=0D
with acceptable quality.=0D
=09=09=09=09*****************=0D


From rem-conf-request@es.net Fri Apr 25 19:45:23 1997 
Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP);
          Fri, 25 Apr 1997 16:45:13 -0700
Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) 
          by rah.star-gate.com (8.8.5/8.7.3) with ESMTP id QAA10466;
          Fri, 25 Apr 1997 16:45:11 -0700 (PDT)
Message-Id: <199704252345.QAA10466@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Hakan Lennestal <hakanl@cdt.luth.se>
cc: rem-conf@es.net
Subject: Re: Video capture driver for Bt848 based cards
In-reply-to: Your message of "Fri, 25 Apr 1997 17:06:19 +0200." <199704251506.RAA20152@ganymede.cdt.luth.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 25 Apr 1997 16:45:11 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by rah.star-gate.com id 
                      QAA10466

Hi,

Not that I am aware of.

	Regards,
	Amancio

>From The Desk Of Hakan Lennestal :
> In message <199704242220.PAA03778@rah.star-gate.com>, Amancio Hasty wri=
tes:
> >=20
> >=20
> > Latest Bt848 driver available from :
> > http://freebsd.org/~fsmp/HomeAuto/Bt848.html
> > ftp://rah.star-gate.com/bt848-clip.tar.gz.=20
> >=20
> > The Bt848 driver has been incorporated to  FreeBSD 3.0-current.=20
>=20
> Hi !
>=20
> Do you know if there is any work going on to port this to Linux ?
>=20
> Regards.
>=20
> /H=E5kan
>=20



From rem-conf-request@tmpmail.es.net Fri Apr 25 19:47:33 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Fri, 25 Apr 1997 16:47:29 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wKugK-0007mK-00; Fri, 25 Apr 1997 16:45:36 -0700
Message-Id: <199704252345.QAA10466@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Hakan Lennestal <hakanl@cdt.luth.se>
cc: rem-conf@es.net
Subject: Re: Video capture driver for Bt848 based cards
In-reply-to: Your message of "Fri, 25 Apr 1997 17:06:19 +0200." <199704251506.RAA20152@ganymede.cdt.luth.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 25 Apr 1997 16:45:11 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by rah.star-gate.com id 
                      QAA10466
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Hi,

Not that I am aware of.

	Regards,
	Amancio

>From The Desk Of Hakan Lennestal :
> In message <199704242220.PAA03778@rah.star-gate.com>, Amancio Hasty wri=
tes:
> >=20
> >=20
> > Latest Bt848 driver available from :
> > http://freebsd.org/~fsmp/HomeAuto/Bt848.html
> > ftp://rah.star-gate.com/bt848-clip.tar.gz.=20
> >=20
> > The Bt848 driver has been incorporated to  FreeBSD 3.0-current.=20
>=20
> Hi !
>=20
> Do you know if there is any work going on to port this to Linux ?
>=20
> Regards.
>=20
> /H=E5kan
>=20




From rem-conf-request@es.net Fri Apr 25 21:22:36 1997 
Received: from nettrix.mediatrix.com by osi-west.es.net with ESnet SMTP (PP);
          Fri, 25 Apr 1997 18:22:25 -0700
Received: from NYQUIST by nettrix.mediatrix.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) 
          id J4C9MGPV; Fri, 25 Apr 1997 21:22:16 -0400
Message-Id: <3.0.1.32.19970425212127.02591888@nettrix.mediatrix.com>
X-Sender: francois@nettrix.mediatrix.com
Disposition-Notification-To: <men@mediatrix.com>
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
X-Priority: 2 (High)
Date: Fri, 25 Apr 1997 21:21:27 -0400
To: rem-conf@es.net
From: "Francois D. Menard" <men@mediatrix.com>
Subject: Re. Internet telephony performance
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

I Reposted Mr. Dvorak's email in ASCII for the benefit of 
everyone. It is appended to the bottom of this post.

Hopefully, you will all allow me to throw in a personal comment
in relation to to Mr. Dvorak's request for action to SG-16.

I am seriously voicing my opinion against the VoIP decision to 
choose the G.723.1 codec as a baseline codec.  However, I am
also voicing my opinion against having to become dependent on ITU 
recommendations in order for see Internet Telephony become
standardized.

Considering that G.723.1 has:

o A much too high delay
o Disputable Quality
o Too many IPR issues that are still unsolved (NTT, 
  new! Siemens, others ..., maybe even more ??? ...)
o Unclear and relatively expensive price schedule

Considering that G.729 has:

o Delays ensuring that the objectives mentioned in the G.114 spec 
  will be well within reach on well designed IP networks
o Toll Quality recognized by everyone
o Much, much clearer IPR issues
o Interesting Price Schedule (According to the VOIP97032.DOC 
  on the VOIP FTP site submitted by Laurent Amar of SiproLab)
o And that if Microsoft puts an implementation of G.729a in 
  Netmeeting,  there will still be 60 millions ports of G.729a 
  on the field (therefore ending once and for all the argument 
  that G.723.1 has more ports on the field than G.729a)

My call to action to all VoIP members (the company that I work 
is not yet a VoIP member due mainly to this reason) is to backtrack 
on the decision of the VoIP and to advise VoIP members to use a 
little bit of common sense, be responsible, recognize their error 
and vote for G.729.

For Internet Telephony to succeed, we all need something like the
"CMA" concept from Vocaltec. Everyone knows that this is the
heart of the VoIP specification and the only reason on why there
should be a VoIP Forum.  I am one of the people the beleive that 
the IETF and the ITU represent two extremes that are not yet
adequate to carry Internet Telephony standardization efforts.

All VoIP members will probably agree with my statement that 
the press currently recognizes VoIP as the industry forum where real
Internet Telephony initial standardization efforts are happening.  

By not correcting this mistake and by forcing SG-16 to vote on
this call to action from SG-12,  VoIP might loose a good amount
of credibility in front of the press and the industry.  The press 
will be quick to pick on the issue of a fight between ITU and VoIP 
on Internet Telephony, which is decisively more entertaining than 
the latest report on the O.J. case ...

Further, the shadow of ITU regulation (... with comes with a long 
history of efficient regulation ... ) might be just what is needed 
to kill VoIP CMA and definitely kill the potential for 
standardization in the area of "Internet Telephony to PSTN 
interoperability" across vendors. And the VoIP people will surely 
not want this to happen.

***************************************************************
To put the gutz of my email into a fully reduced inequation:

(IETF SIP/SAP/LDAP + ITU H.32x/Gatekeepers/Gateway) ==
(ITU H.323 + ITU G.729 + VoIP CMA + IETF LDAP)

It is only under the auspices of such an inequation getting solved
that I see Internet Telephony industry moving forward and I appeal 
to all concerned parties to re-activate discussions on the choice 
of a baseline codec.
***************************************************************

I invite everyone to re-read a recent issue of DATA Communications
raising the points of "if standards bodies should have more legal
responsabilities and if a method to see end-users have a right
to veto on the ballot vote before any recommendation is sanctioned.

Everyone's priority at this early stage in the Internet Telephony 
market should be to grow the pie as fastly as possible, and this 
will not happen if VoIP and the ITU are caught in a fight on the 
apparently "benine" issue of choosing a  "baseline codec" for 
Internet Telephony.

If I remember correctly, the VoIP was never started to become a 
standards organisation. It will not survive by demonstrating that it
is in conflict with the "mother of all standards organisation" in 
telecommunications.

-=Francois=-

Francois D. Menard
Mediatrix Peripherals Inc.
fmenard@mediatrix.com

BTW. I'm 23 years old.  So I guess that my analysis of the 
situation isn't so bad for someone that is relatively new
in the area of telecom regulations ...

"Bow down to the one you serve, you'll only get what you deserve"
 - Trent Reznor, Nine Inch Nails. 
 Most appropriate .sig considering the subject of this post.

========================
TEXT OF Mr. Dvorak
========================

Below is an "informal communication" which ITU-T Study Group 12,
whose mandate is end-to-end transmission quality, agreed to
send to the IETF and the IMTC VOIP Activity Group. SG 12 wants
to share our information with the international community
working in Internet telephony, and we're happy to collaborate.

I have been instructed that the most effective way to disseminate
this note is in ASCII via the e-mail lists to which I have sent it.
(Apologies in advance if this in not correct.)

Thanks,

Chuck Dvorak, SG12 Vice Chairman on behalf of SG12

ITU - Telecommun. Standardization Sector   Temp. Doc 014-E (PL12)

STUDY GROUP 12

Geneva, 7 - 18 April 1997
Questions: 16/12, 18/12, 19/12, 21/12

SOURCE:	Study Group 12

Subject:	Speech Quality Aspects of Internet Telephony

To:		ITU-T SG 16 (for action)
		ITU-T SGs 2, 13, 15 (for information)
		IETF, IMTC VoIP Activity Group (for information)

Approval:	ITU-T SG 12

Deadline for Reply:	30 days after next meeting of  Q.13/16

Contacts:	Paul Coverdale, Chairman WP 2/12
		Tel / Fax: +1.613.763.4277 / 1.613.763.9029
		E-mail: paulcov@nortel.ca

		Charles Dvorak, Chairman WP 3/12
		Tel / Fax: +1.908.580.6418 / 1.908.580.6881
		E-mail: cdvorak@attmail.com

SG 12 thanks SG16 for its invitation to collaborate on Internet
telephony. SG 12 welcomes this collaboration because of our
expertise on multimedia subjective and objective assessment (WP
2/12), and on transmission performance and planning (WP 3/12).
These areas are likely to be critical to the success of Internet
telephony, and we gladly offer the benefits of our experience.

To contribute immediately to the collaboration on Internet
telephony, SG 12 offers information that it hopes will be useful,
given the SG 16 activities described in the liaison we received.

SG 12 is very concerned about the potential selection of a default
speech codec for H.323v2 in the apparent absence of adequate
consideration of the transmission performance implications of any
such selection. In our opinion there are many aspects of end-to-end
quality, but two major considerations in this case are the ability
of a codec to interwork with other elements of the overall
connection, and the delay inserted into the connection by the
codec. These factors can have a serious negative impact on the
user's judgment of service quality.

Regarding the effect of speech coding on transmission quality, the
G.729 Annex A (G.729A) codec has been tested thoroughly by SG12
experts to assure that it satisfied the very stringent terms-of-
reference required of a low bit-rate codec intended for multiple
applications. These requirements included an ability to be tandemed
with other types of codecs, so that no serious degradation of
quality resulted. SG12 is unaware of any similar, comprehensive
testing of the G.723.1 codec, which we understand was developed for
videophone application. Thus, it is unclear how well G.723.1 will
perform when interconnection to the PSTN is attempted.

Regarding the effect of delay on the suitability of a connection
for speech communications, it is our understanding that, due to
processing delay and the way in which frames are arranged, a one-
way delay of approximately 100 ms occurs with G.723.1, whereas
G.729A introduces about a third of this amount. A value of 100 ms
exceeds by 100% the signal processing delay allocation guidelines
of G.114, which SG 12 revised recently to draw attention to the
negative quality impact of such large processing delays. Thus,
while the incremental transmission delay caused by G.723.1 may not
be problematic for regional point-to-point applications over
terrestrial facilities, such incremental delays will have a serious
negative impact if added to transoceanic connections over which
multipoint applications are used. This problem is not avoided by
merely saying that G.723.1 should be used for multimedia
pplications.

Study Group 12 emphasizes that echo control is also likely to be a
major issue with Internet telephony, and Recommendation G.131
provides guidance in this area.

In conclusion, SG12 recognizes the urgency for new Recommendations
on Internet telephony, given the market pressures on the deployment
of such applications. Accordingly, SG 12 applauds SG16 for
aggressively tackling standards work on this important topic.
However, as per the guidance we have provided in this document,
pertinent information already exists that can be used by the ITU
to make codec selections so that user applications are supported
with acceptable quality.
***************

---
#*# -- Francois D. Menard -- Mediatrix Inc. -- fmenard@mediatrix.com 
Product Specialist  / New Product Development /  Strategic Marketing
Visit our WWW site: http://www.mediatrix.com - Awesome new products!
(other e-mail addresses)  francois_menard@msn.com  or  men@login.net
PGP Key fingerprint E2 9D F6 73 2D F4 18 49  C9 3E F0 6D 0C BD B4 FF


From rem-conf-request@tmpmail.es.net Fri Apr 25 21:27:59 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Fri, 25 Apr 1997 18:27:54 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wKwCN-0000gV-00; Fri, 25 Apr 1997 18:22:47 -0700
Message-Id: <3.0.1.32.19970425212127.02591888@nettrix.mediatrix.com>
X-Sender: francois@nettrix.mediatrix.com
Disposition-Notification-To: <men@mediatrix.com>
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
X-Priority: 2 (High)
Date: Fri, 25 Apr 1997 21:21:27 -0400
To: rem-conf@es.net
From: "Francois D. Menard" <men@mediatrix.com>
Subject: Re. Internet telephony performance
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

I Reposted Mr. Dvorak's email in ASCII for the benefit of 
everyone. It is appended to the bottom of this post.

Hopefully, you will all allow me to throw in a personal comment
in relation to to Mr. Dvorak's request for action to SG-16.

I am seriously voicing my opinion against the VoIP decision to 
choose the G.723.1 codec as a baseline codec.  However, I am
also voicing my opinion against having to become dependent on ITU 
recommendations in order for see Internet Telephony become
standardized.

Considering that G.723.1 has:

o A much too high delay
o Disputable Quality
o Too many IPR issues that are still unsolved (NTT, 
  new! Siemens, others ..., maybe even more ??? ...)
o Unclear and relatively expensive price schedule

Considering that G.729 has:

o Delays ensuring that the objectives mentioned in the G.114 spec 
  will be well within reach on well designed IP networks
o Toll Quality recognized by everyone
o Much, much clearer IPR issues
o Interesting Price Schedule (According to the VOIP97032.DOC 
  on the VOIP FTP site submitted by Laurent Amar of SiproLab)
o And that if Microsoft puts an implementation of G.729a in 
  Netmeeting,  there will still be 60 millions ports of G.729a 
  on the field (therefore ending once and for all the argument 
  that G.723.1 has more ports on the field than G.729a)

My call to action to all VoIP members (the company that I work 
is not yet a VoIP member due mainly to this reason) is to backtrack 
on the decision of the VoIP and to advise VoIP members to use a 
little bit of common sense, be responsible, recognize their error 
and vote for G.729.

For Internet Telephony to succeed, we all need something like the
"CMA" concept from Vocaltec. Everyone knows that this is the
heart of the VoIP specification and the only reason on why there
should be a VoIP Forum.  I am one of the people the beleive that 
the IETF and the ITU represent two extremes that are not yet
adequate to carry Internet Telephony standardization efforts.

All VoIP members will probably agree with my statement that 
the press currently recognizes VoIP as the industry forum where real
Internet Telephony initial standardization efforts are happening.  

By not correcting this mistake and by forcing SG-16 to vote on
this call to action from SG-12,  VoIP might loose a good amount
of credibility in front of the press and the industry.  The press 
will be quick to pick on the issue of a fight between ITU and VoIP 
on Internet Telephony, which is decisively more entertaining than 
the latest report on the O.J. case ...

Further, the shadow of ITU regulation (... with comes with a long 
history of efficient regulation ... ) might be just what is needed 
to kill VoIP CMA and definitely kill the potential for 
standardization in the area of "Internet Telephony to PSTN 
interoperability" across vendors. And the VoIP people will surely 
not want this to happen.

***************************************************************
To put the gutz of my email into a fully reduced inequation:

(IETF SIP/SAP/LDAP + ITU H.32x/Gatekeepers/Gateway) ==
(ITU H.323 + ITU G.729 + VoIP CMA + IETF LDAP)

It is only under the auspices of such an inequation getting solved
that I see Internet Telephony industry moving forward and I appeal 
to all concerned parties to re-activate discussions on the choice 
of a baseline codec.
***************************************************************

I invite everyone to re-read a recent issue of DATA Communications
raising the points of "if standards bodies should have more legal
responsabilities and if a method to see end-users have a right
to veto on the ballot vote before any recommendation is sanctioned.

Everyone's priority at this early stage in the Internet Telephony 
market should be to grow the pie as fastly as possible, and this 
will not happen if VoIP and the ITU are caught in a fight on the 
apparently "benine" issue of choosing a  "baseline codec" for 
Internet Telephony.

If I remember correctly, the VoIP was never started to become a 
standards organisation. It will not survive by demonstrating that it
is in conflict with the "mother of all standards organisation" in 
telecommunications.

-=Francois=-

Francois D. Menard
Mediatrix Peripherals Inc.
fmenard@mediatrix.com

BTW. I'm 23 years old.  So I guess that my analysis of the 
situation isn't so bad for someone that is relatively new
in the area of telecom regulations ...

"Bow down to the one you serve, you'll only get what you deserve"
 - Trent Reznor, Nine Inch Nails. 
 Most appropriate .sig considering the subject of this post.

========================
TEXT OF Mr. Dvorak
========================

Below is an "informal communication" which ITU-T Study Group 12,
whose mandate is end-to-end transmission quality, agreed to
send to the IETF and the IMTC VOIP Activity Group. SG 12 wants
to share our information with the international community
working in Internet telephony, and we're happy to collaborate.

I have been instructed that the most effective way to disseminate
this note is in ASCII via the e-mail lists to which I have sent it.
(Apologies in advance if this in not correct.)

Thanks,

Chuck Dvorak, SG12 Vice Chairman on behalf of SG12

ITU - Telecommun. Standardization Sector   Temp. Doc 014-E (PL12)

STUDY GROUP 12

Geneva, 7 - 18 April 1997
Questions: 16/12, 18/12, 19/12, 21/12

SOURCE:	Study Group 12

Subject:	Speech Quality Aspects of Internet Telephony

To:		ITU-T SG 16 (for action)
		ITU-T SGs 2, 13, 15 (for information)
		IETF, IMTC VoIP Activity Group (for information)

Approval:	ITU-T SG 12

Deadline for Reply:	30 days after next meeting of  Q.13/16

Contacts:	Paul Coverdale, Chairman WP 2/12
		Tel / Fax: +1.613.763.4277 / 1.613.763.9029
		E-mail: paulcov@nortel.ca

		Charles Dvorak, Chairman WP 3/12
		Tel / Fax: +1.908.580.6418 / 1.908.580.6881
		E-mail: cdvorak@attmail.com

SG 12 thanks SG16 for its invitation to collaborate on Internet
telephony. SG 12 welcomes this collaboration because of our
expertise on multimedia subjective and objective assessment (WP
2/12), and on transmission performance and planning (WP 3/12).
These areas are likely to be critical to the success of Internet
telephony, and we gladly offer the benefits of our experience.

To contribute immediately to the collaboration on Internet
telephony, SG 12 offers information that it hopes will be useful,
given the SG 16 activities described in the liaison we received.

SG 12 is very concerned about the potential selection of a default
speech codec for H.323v2 in the apparent absence of adequate
consideration of the transmission performance implications of any
such selection. In our opinion there are many aspects of end-to-end
quality, but two major considerations in this case are the ability
of a codec to interwork with other elements of the overall
connection, and the delay inserted into the connection by the
codec. These factors can have a serious negative impact on the
user's judgment of service quality.

Regarding the effect of speech coding on transmission quality, the
G.729 Annex A (G.729A) codec has been tested thoroughly by SG12
experts to assure that it satisfied the very stringent terms-of-
reference required of a low bit-rate codec intended for multiple
applications. These requirements included an ability to be tandemed
with other types of codecs, so that no serious degradation of
quality resulted. SG12 is unaware of any similar, comprehensive
testing of the G.723.1 codec, which we understand was developed for
videophone application. Thus, it is unclear how well G.723.1 will
perform when interconnection to the PSTN is attempted.

Regarding the effect of delay on the suitability of a connection
for speech communications, it is our understanding that, due to
processing delay and the way in which frames are arranged, a one-
way delay of approximately 100 ms occurs with G.723.1, whereas
G.729A introduces about a third of this amount. A value of 100 ms
exceeds by 100% the signal processing delay allocation guidelines
of G.114, which SG 12 revised recently to draw attention to the
negative quality impact of such large processing delays. Thus,
while the incremental transmission delay caused by G.723.1 may not
be problematic for regional point-to-point applications over
terrestrial facilities, such incremental delays will have a serious
negative impact if added to transoceanic connections over which
multipoint applications are used. This problem is not avoided by
merely saying that G.723.1 should be used for multimedia
pplications.

Study Group 12 emphasizes that echo control is also likely to be a
major issue with Internet telephony, and Recommendation G.131
provides guidance in this area.

In conclusion, SG12 recognizes the urgency for new Recommendations
on Internet telephony, given the market pressures on the deployment
of such applications. Accordingly, SG 12 applauds SG16 for
aggressively tackling standards work on this important topic.
However, as per the guidance we have provided in this document,
pertinent information already exists that can be used by the ITU
to make codec selections so that user applications are supported
with acceptable quality.
***************

---
#*# -- Francois D. Menard -- Mediatrix Inc. -- fmenard@mediatrix.com 
Product Specialist  / New Product Development /  Strategic Marketing
Visit our WWW site: http://www.mediatrix.com - Awesome new products!
(other e-mail addresses)  francois_menard@msn.com  or  men@login.net
PGP Key fingerprint E2 9D F6 73 2D F4 18 49  C9 3E F0 6D 0C BD B4 FF



From rem-conf-request@es.net Fri Apr 25 22:11:56 1997 
Received: from precept.com (actually hydra.precept.com) by osi-west.es.net 
          with ESnet SMTP (PP); Fri, 25 Apr 1997 19:11:51 -0700
Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4) id SAA27011;
          Fri, 25 Apr 1997 18:50:15 -0700
Date: Fri, 25 Apr 1997 18:49:13 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Isabelle HAIGNERE <haignere@issy.cnet.fr>
cc: rem-conf@es.net
Subject: Re: g723 payloads
In-Reply-To: <9704251451.AA01082@haddock>
Message-ID: <Pine.WNT.3.95.970425184621.-131667T-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 25 Apr 1997, Isabelle HAIGNERE wrote:

> In the profile of RTP-RFC1890, the G723 payload has been defined and
> moreover I have received the G723 RTP payload from Ken Mills from Intel
> through the rem-conf mailing-list, what about the precise status of this
> document and the G723 payload ? Is this version the last version of the
> G723 rtp payload ?

See draft-ietf-avt-profile-new-00.ps or .txt which gives more details
about the G723 RTP payload format.  This document is working towards
publication of a revised RFC as part of the process of advancing to
Draft Standard status.
							-- Steve


From rem-conf-request@tmpmail.es.net Fri Apr 25 22:15:52 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Fri, 25 Apr 1997 19:15:48 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wKwxy-0001A0-00; Fri, 25 Apr 1997 19:11:58 -0700
Date: Fri, 25 Apr 1997 18:49:13 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Isabelle HAIGNERE <haignere@issy.cnet.fr>
cc: rem-conf@es.net
Subject: Re: g723 payloads
In-Reply-To: <9704251451.AA01082@haddock>
Message-ID: <Pine.WNT.3.95.970425184621.-131667T-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

On Fri, 25 Apr 1997, Isabelle HAIGNERE wrote:

> In the profile of RTP-RFC1890, the G723 payload has been defined and
> moreover I have received the G723 RTP payload from Ken Mills from Intel
> through the rem-conf mailing-list, what about the precise status of this
> document and the G723 payload ? Is this version the last version of the
> G723 rtp payload ?

See draft-ietf-avt-profile-new-00.ps or .txt which gives more details
about the G723 RTP payload format.  This document is working towards
publication of a revised RFC as part of the process of advancing to
Draft Standard status.
							-- Steve



From rem-conf-request@es.net Sat Apr 26 23:55:40 1997 
Received: from netra (actually netra.nju.edu.cn) by osi-west.es.net 
          with ESnet SMTP (PP); Sat, 26 Apr 1997 20:55:05 -0700
Received: from 202.119.32.6 (graphics.nju.edu.cn) by netra (5.x/SMI-SVR4) 
          id AA08941; Sun, 27 Apr 1997 11:48:23 -0800
Message-Id: <3362CD51.6A5A@graphics.nju.edu.cn>
Date: Sun, 27 Apr 1997 11:51:45 +0800
From: WANG Jian <wangjian@graphics.nju.edu.cn>
Reply-To: wangjian@doctor4u.com
Organization: NJU
X-Mailer: Mozilla 2.0 (Macintosh; I; PPC)
Mime-Version: 1.0
To: cscw-sig@mailbase.ac.uk
Cc: CU-SEEME-L@cornell.edu, confctrl@isi.edu, telework@mailbase.ac.uk, 
    mbone-na@isi.edu, rem-conf@es.net, vidconf@pulver.com, videophone@es.net, 
    VIDNET-L@UGA.CC.UGA.EDU, www-multicast@w3.org
Subject: help
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

hi,

I am making plans for a project on real-time collaberative system.

I want to know
1, the prices of QuickTime Conferencing products, and
2, the products of mac-based shared editor or collaberative writer and
their prices.

I appreciate your any respones!

WANG Jian

From rem-conf-request@es.net Sun Apr 27 01:23:31 1997 
Received: from netra (actually netra.nju.edu.cn) by osi-west.es.net 
          with ESnet SMTP (PP); Sat, 26 Apr 1997 22:23:09 -0700
Received: from 202.119.32.6 (graphics.nju.edu.cn) by netra (5.x/SMI-SVR4) 
          id AA09364; Sun, 27 Apr 1997 13:18:22 -0800
Message-Id: <3362E0C9.27EE@graphics.nju.edu.cn>
Date: Sun, 27 Apr 1997 13:14:49 +0800
From: WANG Jian <wangjian@graphics.nju.edu.cn>
Reply-To: wangjian@doctor4u.com
Organization: NJU
X-Mailer: Mozilla 2.0 (Macintosh; I; PPC)
Mime-Version: 1.0
To: cscw-sig@mailbase.ac.uk
Cc: CU-SEEME-L@cornell.edu, confctrl@isi.edu, telework@mailbase.ac.uk, 
    mbone-na@isi.edu, rem-conf@es.net, vidconf@pulver.com, videophone@es.net, 
    VIDNET-L@UGA.CC.UGA.EDU, www-multicast@w3.org
Subject: help
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

hi,

I am making plans for a project on real-time collaberative system.

I want to know
1, the prices of QuickTime Conferencing products, and
2, the products of mac-based shared editor or collaberative writer and
their prices.

I appreciate your any respones!

WANG Jian

From rem-conf-request@es.net Sun Apr 27 15:59:59 1997 
Received: from snmpmgr.state.tn.us by osi-west.es.net with ESnet SMTP (PP);
          Sun, 27 Apr 1997 12:59:48 -0700
Received: from langate.tnet.state.tn.us by snmpmgr.state.tn.us with SMTP 
          id AA15299 (5.67b/IDA-1.5 for <rem-conf@es.net>);
          Sun, 27 Apr 1997 14:59:46 -0500
Received: from tn01-Message_Server by langate.tnet.state.tn.us 
          with Novell_GroupWise; Sun, 27 Apr 1997 15:04:00 -0500
Message-Id: <s3636ae0.053@langate.tnet.state.tn.us>
X-Mailer: Novell GroupWise 4.1
Date: Sun, 27 Apr 1997 15:03:32 -0500
From: Eric Hauch <ehauch@mail.state.tn.us>
To: t1a15@t1.org
Cc: rem-conf@es.net
Subject: T1A1.5 Postings
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline

Hi Gang!

I have just uploaded to T1BBS the following documents:

7a150030.doc:  Report from our Jan/97 Orlando meeting.

7a155040.doc:  Copies of the overheads from a presentation I
made to the IETF AVT WG on Apr 9 in Memphis.

More to come,

Eric

P.S. (for the IETF AVT members):  These docs can be found
in the T1A1.5 file space at www.t1.org (or more directly, goto
http://www.t1.org/t1a1/_a1-grid.htm).



From rem-conf-request@tmpmail.es.net Sun Apr 27 16:14:01 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Sun, 27 Apr 1997 13:13:39 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wLa78-0002BZ-00; Sun, 27 Apr 1997 13:00:02 -0700
Message-Id: <s3636ae0.053@langate.tnet.state.tn.us>
X-Mailer: Novell GroupWise 4.1
Date: Sun, 27 Apr 1997 15:03:32 -0500
From: Eric Hauch <ehauch@mail.state.tn.us>
To: t1a15@t1.org
Cc: rem-conf@es.net
Subject: T1A1.5 Postings
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Hi Gang!

I have just uploaded to T1BBS the following documents:

7a150030.doc:  Report from our Jan/97 Orlando meeting.

7a155040.doc:  Copies of the overheads from a presentation I
made to the IETF AVT WG on Apr 9 in Memphis.

More to come,

Eric

P.S. (for the IETF AVT members):  These docs can be found
in the T1A1.5 file space at www.t1.org (or more directly, goto
http://www.t1.org/t1a1/_a1-grid.htm).




From rem-conf-request@es.net Sun Apr 27 17:24:06 1997 
Received: from snmpmgr.state.tn.us by osi-west.es.net with ESnet SMTP (PP);
          Sun, 27 Apr 1997 14:23:56 -0700
Received: from langate.tnet.state.tn.us by snmpmgr.state.tn.us with SMTP 
          id AA15740 (5.67b/IDA-1.5 for <rem-conf@es.net>);
          Sun, 27 Apr 1997 16:23:54 -0500
Received: from tn01-Message_Server by langate.tnet.state.tn.us 
          with Novell_GroupWise; Sun, 27 Apr 1997 16:28:13 -0500
Message-Id: <s3637e9d.064@langate.tnet.state.tn.us>
X-Mailer: Novell GroupWise 4.1
Date: Sun, 27 Apr 1997 16:27:49 -0500
From: Eric Hauch <ehauch@mail.state.tn.us>
To: rem-conf@es.net
Cc: t1a15@t1.org
Subject: T1A1.5 Multimedia Performance Standards on the Internet
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline

To Members of the IETF AVT WG,

This is a quick reminder of the upcoming meeting of T1A1.5
WG on Multimedia Performance and Coding (Boulder May
6-8/97).

Anyone who is able to attend can find the meeting specifics
at http://www.t1.org/t1a1/t1a1.htm.  I can deal with the IETF
liaison item (and the work of establishing multimedia client
performance requirements on the Internet) either May 6
(afternoon) or May 7.  If anyone has a time or date
preference, please let me know.

Thanks,

Eric G. Hauch
T1A1.5 Chair
ehauch@mail.state.tn.us
615-532-2365



From rem-conf-request@tmpmail.es.net Sun Apr 27 17:26:38 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Sun, 27 Apr 1997 14:26:34 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wLbQV-0002jL-00; Sun, 27 Apr 1997 14:24:07 -0700
Message-Id: <s3637e9d.064@langate.tnet.state.tn.us>
X-Mailer: Novell GroupWise 4.1
Date: Sun, 27 Apr 1997 16:27:49 -0500
From: Eric Hauch <ehauch@mail.state.tn.us>
To: rem-conf@es.net
Cc: t1a15@t1.org
Subject: T1A1.5 Multimedia Performance Standards on the Internet
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

To Members of the IETF AVT WG,

This is a quick reminder of the upcoming meeting of T1A1.5
WG on Multimedia Performance and Coding (Boulder May
6-8/97).

Anyone who is able to attend can find the meeting specifics
at http://www.t1.org/t1a1/t1a1.htm.  I can deal with the IETF
liaison item (and the work of establishing multimedia client
performance requirements on the Internet) either May 6
(afternoon) or May 7.  If anyone has a time or date
preference, please let me know.

Thanks,

Eric G. Hauch
T1A1.5 Chair
ehauch@mail.state.tn.us
615-532-2365




From rem-conf-request@es.net Sun Apr 27 21:18:34 1997 
Received: from hanla.snu.ac.kr by osi-west.es.net with ESnet SMTP (PP);
          Sun, 27 Apr 1997 18:18:21 -0700
Received: from tsptsp2.snu.ac.kr ([147.46.116.118]) 
          by hanla.snu.ac.kr (8.6.12H1/8.6.12) with SMTP id KAA07194 
          for <rem-conf@es.net>; Mon, 28 Apr 1997 10:14:35 +0900
Message-ID: <33484B02.7833@chollian.net>
Date: Mon, 07 Apr 1997 10:16:50 +0900
From: Roh Jeong-Hun <ohnohoya@chollian.net>
Organization: Seoul National University
X-Mailer: Mozilla 3.0Gold (Win95; I)
MIME-Version: 1.0
To: rem-conf@es.net
Subject: about 'cumulative neumber of packets lost' of RTP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I'm a beginner in this RTP field.This is a kind of simple question.
i don't understand why 'cumulative neumber of packets lost' which 
is one of the fields in the RR(report reception) of RTCP packet.
RFC1889 says that this value is defined to be the number of packets
exepected less the number of packets actually received, where the
number of packets received includes any which are late or duplicates.
I don't get the reason why we don't distinguish late or dupliacated
packets from well received packets. 

Thanx a lot for reading this. I hope you to let me know what I 
don't know...

From rem-conf-request@es.net Sun Apr 27 21:19:58 1997 
Received: from hanla.snu.ac.kr by osi-west.es.net with ESnet SMTP (PP);
          Sun, 27 Apr 1997 18:19:49 -0700
Received: from tsptsp2.snu.ac.kr ([147.46.116.118]) 
          by hanla.snu.ac.kr (8.6.12H1/8.6.12) with SMTP id KAA07198 
          for <rem-conf@es.net>; Mon, 28 Apr 1997 10:16:04 +0900
Message-ID: <33484B5B.3F7D@chollian.net>
Date: Mon, 07 Apr 1997 10:18:19 +0900
From: Roh Jeong-Hun <ohnohoya@chollian.net>
Organization: Seoul National University
X-Mailer: Mozilla 3.0Gold (Win95; I)
MIME-Version: 1.0
To: rem-conf@es.net
Subject: 'information about receivers' in RR of RTCP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I have a question reading RFC1889 which is the spec of RTP. 
In the section of 6.3.3 Extending the sender and receiver reports,
it says 'If information about receivers is to be included,that 
data may be structured as an array of blocks parallel to the exist-
ing array of reception report blocks;that is,the number of blocks
would be indicated by the RC field.'
What's 'information about receivers'? What kind of information
would it be? 
What does an array of blocks parallel to the existing array of 
reception report blocks look like? Somebody could describe it
in detail? I tried to imagine the structure,but failed...


Thank you very much for reading these questions.

From rem-conf-request@es.net Sun Apr 27 21:21:19 1997 
Received: from hanla.snu.ac.kr by osi-west.es.net with ESnet SMTP (PP);
          Sun, 27 Apr 1997 18:21:12 -0700
Received: from tsptsp2.snu.ac.kr ([147.46.116.118]) 
          by hanla.snu.ac.kr (8.6.12H1/8.6.12) with SMTP id KAA07214 
          for <rem-conf@es.net>; Mon, 28 Apr 1997 10:17:27 +0900
Message-ID: <33484BAE.54E9@chollian.net>
Date: Mon, 07 Apr 1997 10:19:42 +0900
From: Roh Jeong-Hun <ohnohoya@chollian.net>
Organization: Seoul National University
X-Mailer: Mozilla 3.0Gold (Win95; I)
MIME-Version: 1.0
To: rem-conf@es.net
Subject: about 'Translators' of RTP.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This is about 'Translators' of RTP.
In RFC1889-page 40-, it says 'translator forwards RTP packets with
their SSRC identifier intact;this makes it possible for receivers
to identify individual sources even though packets from all the
sources pass through the same translator and carry the translator's
network source address'.
Why does it carry 'its network source address'? I guess it may
cause looping problems.. I don't know why it should change
the source address with its own.

If you know the answer or the reference that I can get the answer
from, please tell me.

Thanks.

From rem-conf-request@tmpmail.es.net Sun Apr 27 21:25:52 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Sun, 27 Apr 1997 18:25:46 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wLf6l-0003yo-00; Sun, 27 Apr 1997 18:19:59 -0700
Message-ID: <33484B5B.3F7D@chollian.net>
Date: Mon, 07 Apr 1997 10:18:19 +0900
From: Roh Jeong-Hun <ohnohoya@chollian.net>
Organization: Seoul National University
X-Mailer: Mozilla 3.0Gold (Win95; I)
MIME-Version: 1.0
To: rem-conf@es.net
Subject: 'information about receivers' in RR of RTCP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

I have a question reading RFC1889 which is the spec of RTP. 
In the section of 6.3.3 Extending the sender and receiver reports,
it says 'If information about receivers is to be included,that 
data may be structured as an array of blocks parallel to the exist-
ing array of reception report blocks;that is,the number of blocks
would be indicated by the RC field.'
What's 'information about receivers'? What kind of information
would it be? 
What does an array of blocks parallel to the existing array of 
reception report blocks look like? Somebody could describe it
in detail? I tried to imagine the structure,but failed...


Thank you very much for reading these questions.


From rem-conf-request@tmpmail.es.net Sun Apr 27 21:26:12 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Sun, 27 Apr 1997 18:25:53 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wLf84-0003zg-00; Sun, 27 Apr 1997 18:21:20 -0700
Message-ID: <33484BAE.54E9@chollian.net>
Date: Mon, 07 Apr 1997 10:19:42 +0900
From: Roh Jeong-Hun <ohnohoya@chollian.net>
Organization: Seoul National University
X-Mailer: Mozilla 3.0Gold (Win95; I)
MIME-Version: 1.0
To: rem-conf@es.net
Subject: about 'Translators' of RTP.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

This is about 'Translators' of RTP.
In RFC1889-page 40-, it says 'translator forwards RTP packets with
their SSRC identifier intact;this makes it possible for receivers
to identify individual sources even though packets from all the
sources pass through the same translator and carry the translator's
network source address'.
Why does it carry 'its network source address'? I guess it may
cause looping problems.. I don't know why it should change
the source address with its own.

If you know the answer or the reference that I can get the answer
from, please tell me.

Thanks.


From rem-conf-request@tmpmail.es.net Sun Apr 27 21:26:14 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Sun, 27 Apr 1997 18:25:47 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wLf5R-0003xj-00; Sun, 27 Apr 1997 18:18:37 -0700
Message-ID: <33484B02.7833@chollian.net>
Date: Mon, 07 Apr 1997 10:16:50 +0900
From: Roh Jeong-Hun <ohnohoya@chollian.net>
Organization: Seoul National University
X-Mailer: Mozilla 3.0Gold (Win95; I)
MIME-Version: 1.0
To: rem-conf@es.net
Subject: about 'cumulative neumber of packets lost' of RTP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

I'm a beginner in this RTP field.This is a kind of simple question.
i don't understand why 'cumulative neumber of packets lost' which 
is one of the fields in the RR(report reception) of RTCP packet.
RFC1889 says that this value is defined to be the number of packets
exepected less the number of packets actually received, where the
number of packets received includes any which are late or duplicates.
I don't get the reason why we don't distinguish late or dupliacated
packets from well received packets. 

Thanx a lot for reading this. I hope you to let me know what I 
don't know...


From rem-conf-request@es.net Mon Apr 28 06:08:43 1997 
Received: from ns.sbs.de by osi-west.es.net with ESnet SMTP (PP);
          Mon, 28 Apr 1997 03:08:31 -0700
Received: (from uucp@localhost) by ns.sbs.de (8.8.3/8.8.2) id MAA20701;
          Mon, 28 Apr 1997 12:08:10 +0200 (MDT)
Received: from marina.fth.sbs.de(192.129.41.2) by ns via smap (v3.0.1) 
          id sma020561; Mon, 28 Apr 97 12:07:11 +0200
Received: from sun0.mch2.scn.de (sun0.mch2.scn.de [139.1.1.10]) 
          by marina.fth.sbs.de (8.8.5/8.8.2) with SMTP id MAA25939;
          Mon, 28 Apr 1997 12:05:33 +0200 (MET DST)
Received: from pnsta1.zfe.siemens.de (pnsta1.mch2.scn.de) 
          by sun0.mch2.scn.de (4.1/sun0-008) id AA16884;
          Mon, 28 Apr 97 12:01:53 +0200
Received: from 62000866 (sta14_seb) by pnsta1.zfe.siemens.de (4.1/SMI-4.1) 
          id AA28456; Mon, 28 Apr 97 12:01:32 +0200
Date: Mon, 28 Apr 97 12:01:32 +0200
Message-Id: <9704281001.AA28456@pnsta1.zfe.siemens.de>
X-Sender: sebes@sta12_mue
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: "Francois D. Menard" <men@mediatrix.com>
From: Istvan Sebestyen <istvan.sebestyen@mch.pn.siemens.de>
Subject: Re: Re. Internet telephony performance
Cc: rem-conf@es.net, voip-tech@vocaltec.com, taylor@nortel.ca, 
    matumoto@tom.comm.waseda.ac.jp

At 21:16 25.04.1997 -0400, Francois D. Menard wrote:
Dear Colleagues,
out of the much longer e-amil message of Mr. Menard - I entirely disagree with -
I would like to reflect on two issues only. Thus, the explanations of the
excepts
of his message presented bellow:
....
I am
>also voicing my opinion against having to become dependent on ITU 
>recommendations in order for see Internet Telephony become
>standardized.
>
>Considering that G.723.1 has:
>
>o A much too high delay
>o Disputable Quality
>o Too many IPR issues that are still unsolved (NTT, 
>  new! Siemens, others ..., maybe even more ??? ...)
>o Unclear and relatively expensive price schedule
>
...
 I am one of the people the beleive that 
>the IETF and the ITU represent two extremes that are not yet
>adequate to carry Internet Telephony standardization efforts.
>

...
 The press 
>will be quick to pick on the issue of a fight between ITU and VoIP 
>on Internet Telephony, which is decisively more entertaining than 
>the latest report on the O.J. case ...
>
>Further, the shadow of ITU regulation (... with comes with a long 
>history of efficient regulation ... ) might be just what is needed 
>to kill VoIP CMA and definitely kill the potential for 
>standardization in the area of "Internet Telephony to PSTN 
>interoperability" across vendors. 
....

>Everyone's priority at this early stage in the Internet Telephony 
>market should be to grow the pie as fastly as possible, and this 
>will not happen if VoIP and the ITU are caught in a fight on the 
>apparently "benine" issue of choosing a  "baseline codec" for 
>Internet Telephony.
>
>If I remember correctly, the VoIP was never started to become a 
>standards organisation. It will not survive by demonstrating that it
>is in conflict with the "mother of all standards organisation" in 
>telecommunications.
>
>- - -=Francois=-
>
>Francois D. Menard
>Mediatrix Peripherals Inc.
>fmenard@mediatrix.com
>
My comments as Siemens Representative at IMTC:

1       The Siemens AG declared at the Newark meeting of VoIP (VoIP97-029)
- according to the requirements of
"IMTC Intellectual Property Code of Condact" that all IMTC members
have to follow - that it believes it has essential patents both on the
optional G.723.1 Annex A
and G.729 Annex B. Thus, there is no difference in that respect between
the two standards, that were put for voting in front of VoIP. This information
was earlier officially also communicated to the ITU TSB.

My comments as ITU-T SG 16 Ass. Rapporteur Q.16,17 (the Lead ITU-T Study
Group resonsible 
for all ITU-T Coordination on Multimedia both internally and externally the
ITU),
and as one of the official ITU-T SG16 Liaisons between ITU and IMTC 
(the other one is Neil Starkey, President of IMTC):

2       IMTC and ITU-T are succesfully working together on a number of projects.
Activities of both organizations are supplementary to eachother and not
competitive.

In that spirit, the ITU-T is specifying, approving and maintaining in close
cooperation with IMTC - among others the
relevant H, G, and T.Series of ITU-T Recommendations - while IMTC is
carrying out
extremely valuable complementary work (including excellent PR activities
on ITU-T standards, Interoparability Tests of Systems. built on standards,
etc...many other useful tasks). Up to now the cooperation between ITU-T and IMTC
has been excellent, and I see no reason why this should not continue.
In that spirit I am fully confident that ITU-T and IMTC (including its VoIP
Forum)
will continue their fruitful cooperation. 

Kind regards,

Istvan Sebestyen    
------------------------------------------------------------------
Istvan Sebestyen                    Siemens AG 
PN M PE                             Mch H/Pe16 03/807
Tel:      +49-89-722 47230          Hofmannstr. 51
Fax:      +49-89-722 47713          D-81359 Munich, GERMANY
Internet: istvan.sebestyen@mch.pn.siemens.de (preferred)
	  sebes@pnsta1.zfe.siemens.de (will be discont. Dec. 97)
          istvan.sebestyen@pn.siemens.de (Fall back only)
          dead address: istvan.sebestyen@zfe.siemens.de
X.400:    c=de;a=dbp;p=scn;o=siemens;ou1=mch;ou2=PN-msmail;
	  s=Sebestyen;g=Istvan

Note: Unfortunately e-mails sent to me can get lost or stay
unread for a long time, thus I regard e-mail only as additional, 
and not "official" form of communication to me.
For very important communication pls. send a fax. 
------------------------------------------------------------------



From rem-conf-request@tmpmail.es.net Mon Apr 28 06:15:29 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Mon, 28 Apr 1997 03:15:26 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wLnMU-0007ZK-00; Mon, 28 Apr 1997 03:08:46 -0700
Date: Mon, 28 Apr 97 12:01:32 +0200
Message-Id: <9704281001.AA28456@pnsta1.zfe.siemens.de>
X-Sender: sebes@sta12_mue
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: "Francois D. Menard" <men@mediatrix.com>
From: Istvan Sebestyen <istvan.sebestyen@mch.pn.siemens.de>
Subject: Re: Re. Internet telephony performance
Cc: rem-conf@es.net, voip-tech@vocaltec.com, taylor@nortel.ca, 
    matumoto@tom.comm.waseda.ac.jp
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

At 21:16 25.04.1997 -0400, Francois D. Menard wrote:
Dear Colleagues,
out of the much longer e-amil message of Mr. Menard - I entirely disagree with -
I would like to reflect on two issues only. Thus, the explanations of the
excepts
of his message presented bellow:
....
I am
>also voicing my opinion against having to become dependent on ITU 
>recommendations in order for see Internet Telephony become
>standardized.
>
>Considering that G.723.1 has:
>
>o A much too high delay
>o Disputable Quality
>o Too many IPR issues that are still unsolved (NTT, 
>  new! Siemens, others ..., maybe even more ??? ...)
>o Unclear and relatively expensive price schedule
>
...
 I am one of the people the beleive that 
>the IETF and the ITU represent two extremes that are not yet
>adequate to carry Internet Telephony standardization efforts.
>

...
 The press 
>will be quick to pick on the issue of a fight between ITU and VoIP 
>on Internet Telephony, which is decisively more entertaining than 
>the latest report on the O.J. case ...
>
>Further, the shadow of ITU regulation (... with comes with a long 
>history of efficient regulation ... ) might be just what is needed 
>to kill VoIP CMA and definitely kill the potential for 
>standardization in the area of "Internet Telephony to PSTN 
>interoperability" across vendors. 
....

>Everyone's priority at this early stage in the Internet Telephony 
>market should be to grow the pie as fastly as possible, and this 
>will not happen if VoIP and the ITU are caught in a fight on the 
>apparently "benine" issue of choosing a  "baseline codec" for 
>Internet Telephony.
>
>If I remember correctly, the VoIP was never started to become a 
>standards organisation. It will not survive by demonstrating that it
>is in conflict with the "mother of all standards organisation" in 
>telecommunications.
>
>- - -=Francois=-
>
>Francois D. Menard
>Mediatrix Peripherals Inc.
>fmenard@mediatrix.com
>
My comments as Siemens Representative at IMTC:

1       The Siemens AG declared at the Newark meeting of VoIP (VoIP97-029)
- according to the requirements of
"IMTC Intellectual Property Code of Condact" that all IMTC members
have to follow - that it believes it has essential patents both on the
optional G.723.1 Annex A
and G.729 Annex B. Thus, there is no difference in that respect between
the two standards, that were put for voting in front of VoIP. This information
was earlier officially also communicated to the ITU TSB.

My comments as ITU-T SG 16 Ass. Rapporteur Q.16,17 (the Lead ITU-T Study
Group resonsible 
for all ITU-T Coordination on Multimedia both internally and externally the
ITU),
and as one of the official ITU-T SG16 Liaisons between ITU and IMTC 
(the other one is Neil Starkey, President of IMTC):

2       IMTC and ITU-T are succesfully working together on a number of projects.
Activities of both organizations are supplementary to eachother and not
competitive.

In that spirit, the ITU-T is specifying, approving and maintaining in close
cooperation with IMTC - among others the
relevant H, G, and T.Series of ITU-T Recommendations - while IMTC is
carrying out
extremely valuable complementary work (including excellent PR activities
on ITU-T standards, Interoparability Tests of Systems. built on standards,
etc...many other useful tasks). Up to now the cooperation between ITU-T and IMTC
has been excellent, and I see no reason why this should not continue.
In that spirit I am fully confident that ITU-T and IMTC (including its VoIP
Forum)
will continue their fruitful cooperation. 

Kind regards,

Istvan Sebestyen    
------------------------------------------------------------------
Istvan Sebestyen                    Siemens AG 
PN M PE                             Mch H/Pe16 03/807
Tel:      +49-89-722 47230          Hofmannstr. 51
Fax:      +49-89-722 47713          D-81359 Munich, GERMANY
Internet: istvan.sebestyen@mch.pn.siemens.de (preferred)
	  sebes@pnsta1.zfe.siemens.de (will be discont. Dec. 97)
          istvan.sebestyen@pn.siemens.de (Fall back only)
          dead address: istvan.sebestyen@zfe.siemens.de
X.400:    c=de;a=dbp;p=scn;o=siemens;ou1=mch;ou2=PN-msmail;
	  s=Sebestyen;g=Istvan

Note: Unfortunately e-mails sent to me can get lost or stay
unread for a long time, thus I regard e-mail only as additional, 
and not "official" form of communication to me.
For very important communication pls. send a fax. 
------------------------------------------------------------------




From rem-conf-request@es.net Mon Apr 28 07:21:35 1997 
Received: from POP3.tu-dresden.de (actually RKS3f.urz.tu-dresden.de) 
          by osi-west.es.net with ESnet SMTP (PP);
          Mon, 28 Apr 1997 04:21:18 -0700
Received: from rmail.urz.tu-dresden.de (actually Rks4.urz.tu-dresden.de) 
          by rks3 with SMTP (PP); Mon, 28 Apr 1997 13:20:48 +0200
Received: from rnws02.urz.tu-dresden.de by rmail with SMTP (PP);
          Mon, 28 Apr 1997 13:13:03 +0200
Received: by rnws02.urz.tu-dresden.de (SMI-8.6/SMI-SVR4) id NAA10371;
          Mon, 28 Apr 1997 13:20:43 +0200
From: Reinhard.Foerster@Inf.TU-Dresden.DE (Reinhard Foerster)
Message-Id: <199704281120.NAA10371@rnws02.urz.tu-dresden.de>
Subject: Re: Video capture driver for Bt848 based cards
In-Reply-To: <199704251506.RAA20152@ganymede.cdt.luth.se> from Hakan Lennestal at "Apr 25, 97 05:06:19 pm"
To: hakanl@cdt.luth.se (Hakan Lennestal)
Date: Mon, 28 Apr 1997 13:20:43 +0200 (MET DST)
Cc: rem-conf@es.net
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

> In message <199704242220.PAA03778@rah.star-gate.com>, Amancio Hasty write=
s:

A linux driver for bt848 based grabber cards you can find at

  http://www.thp.uni-koeln.de/~rjkm/

Reinhard

> > Latest Bt848 driver available from :
> > http://freebsd.org/~fsmp/HomeAuto/Bt848.html
> > ftp://rah.star-gate.com/bt848-clip.tar.gz.=20
> >=20
> > The Bt848 driver has been incorporated to  FreeBSD 3.0-current.=20
>=20
> Hi !
>=20
> Do you know if there is any work going on to port this to Linux ?
>=20
> Regards.
>=20
> /H=E5kan
>=20

From rem-conf-request@tmpmail.es.net Mon Apr 28 07:25:23 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Mon, 28 Apr 1997 04:24:58 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wLoUz-0000SY-00; Mon, 28 Apr 1997 04:21:37 -0700
From: Reinhard.Foerster@Inf.TU-Dresden.DE (Reinhard Foerster)
Message-Id: <199704281120.NAA10371@rnws02.urz.tu-dresden.de>
Subject: Re: Video capture driver for Bt848 based cards
In-Reply-To: <199704251506.RAA20152@ganymede.cdt.luth.se> from Hakan Lennestal at "Apr 25, 97 05:06:19 pm"
To: hakanl@cdt.luth.se (Hakan Lennestal)
Date: Mon, 28 Apr 1997 13:20:43 +0200 (MET DST)
Cc: rem-conf@es.net
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

> In message <199704242220.PAA03778@rah.star-gate.com>, Amancio Hasty write=
s:

A linux driver for bt848 based grabber cards you can find at

  http://www.thp.uni-koeln.de/~rjkm/

Reinhard

> > Latest Bt848 driver available from :
> > http://freebsd.org/~fsmp/HomeAuto/Bt848.html
> > ftp://rah.star-gate.com/bt848-clip.tar.gz.=20
> >=20
> > The Bt848 driver has been incorporated to  FreeBSD 3.0-current.=20
>=20
> Hi !
>=20
> Do you know if there is any work going on to port this to Linux ?
>=20
> Regards.
>=20
> /H=E5kan
>=20


From rem-conf-request@es.net Mon Apr 28 07:25:46 1997 
Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP);
          Mon, 28 Apr 1997 04:25:23 -0700
Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) 
          by rah.star-gate.com (8.8.5/8.7.3) with ESMTP id EAA00364;
          Mon, 28 Apr 1997 04:21:08 -0700 (PDT)
Message-Id: <199704281121.EAA00364@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Istvan Sebestyen <istvan.sebestyen@mch.pn.siemens.de>
cc: "Francois D. Menard" <men@mediatrix.com>, rem-conf@es.net, 
    voip-tech@vocaltec.com, taylor@nortel.ca, matumoto@tom.comm.waseda.ac.jp
Subject: Re: Re. Internet telephony performance
In-reply-to: Your message of "Mon, 28 Apr 1997 12:01:32 +0200." <9704281001.AA28456@pnsta1.zfe.siemens.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 28 Apr 1997 04:21:07 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>

I am little concern here about some of the patent issues with respect
to G.723 and H.263 and the lack of publicly available tools in fact
it will not surprise me to see a split between commercial tools and
publicly available tools. The time is right given that
most publicly available  mbone tools don't use H.263 or G.723.

	Regards,
	Amancio
	


>From The Desk Of Istvan Sebestyen :
> At 21:16 25.04.1997 -0400, Francois D. Menard wrote:
> Dear Colleagues,
> out of the much longer e-amil message of Mr. Menard - I entirely disagree wit
h -
> I would like to reflect on two issues only. Thus, the explanations of the
> excepts
> of his message presented bellow:
> ....
> I am
> >also voicing my opinion against having to become dependent on ITU 
> >recommendations in order for see Internet Telephony become
> >standardized.
> >
> >Considering that G.723.1 has:
> >
> >o A much too high delay
> >o Disputable Quality
> >o Too many IPR issues that are still unsolved (NTT, 
> >  new! Siemens, others ..., maybe even more ??? ...)
> >o Unclear and relatively expensive price schedule
> >
> ...
>  I am one of the people the beleive that 
> >the IETF and the ITU represent two extremes that are not yet
> >adequate to carry Internet Telephony standardization efforts.
> >
> 
> ...
>  The press 
> >will be quick to pick on the issue of a fight between ITU and VoIP 
> >on Internet Telephony, which is decisively more entertaining than 
> >the latest report on the O.J. case ...
> >
> >Further, the shadow of ITU regulation (... with comes with a long 
> >history of efficient regulation ... ) might be just what is needed 
> >to kill VoIP CMA and definitely kill the potential for 
> >standardization in the area of "Internet Telephony to PSTN 
> >interoperability" across vendors. 
> ....
> 
> >Everyone's priority at this early stage in the Internet Telephony 
> >market should be to grow the pie as fastly as possible, and this 
> >will not happen if VoIP and the ITU are caught in a fight on the 
> >apparently "benine" issue of choosing a  "baseline codec" for 
> >Internet Telephony.
> >
> >If I remember correctly, the VoIP was never started to become a 
> >standards organisation. It will not survive by demonstrating that it
> >is in conflict with the "mother of all standards organisation" in 
> >telecommunications.
> >
> >- - -=Francois=-
> >
> >Francois D. Menard
> >Mediatrix Peripherals Inc.
> >fmenard@mediatrix.com
> >
> My comments as Siemens Representative at IMTC:
> 
> 1       The Siemens AG declared at the Newark meeting of VoIP (VoIP97-029)
> - according to the requirements of
> "IMTC Intellectual Property Code of Condact" that all IMTC members
> have to follow - that it believes it has essential patents both on the
> optional G.723.1 Annex A
> and G.729 Annex B. Thus, there is no difference in that respect between
> the two standards, that were put for voting in front of VoIP. This informatio
n
> was earlier officially also communicated to the ITU TSB.
> 
> My comments as ITU-T SG 16 Ass. Rapporteur Q.16,17 (the Lead ITU-T Study
> Group resonsible 
> for all ITU-T Coordination on Multimedia both internally and externally the
> ITU),
> and as one of the official ITU-T SG16 Liaisons between ITU and IMTC 
> (the other one is Neil Starkey, President of IMTC):
> 
> 2       IMTC and ITU-T are succesfully working together on a number of projec
ts.
> Activities of both organizations are supplementary to eachother and not
> competitive.
> 
> In that spirit, the ITU-T is specifying, approving and maintaining in close
> cooperation with IMTC - among others the
> relevant H, G, and T.Series of ITU-T Recommendations - while IMTC is
> carrying out
> extremely valuable complementary work (including excellent PR activities
> on ITU-T standards, Interoparability Tests of Systems. built on standards,
> etc...many other useful tasks). Up to now the cooperation between ITU-T and I
MTC
> has been excellent, and I see no reason why this should not continue.
> In that spirit I am fully confident that ITU-T and IMTC (including its VoIP
> Forum)
> will continue their fruitful cooperation. 
> 
> Kind regards,
> 
> Istvan Sebestyen    
> ------------------------------------------------------------------
> Istvan Sebestyen                    Siemens AG 
> PN M PE                             Mch H/Pe16 03/807
> Tel:      +49-89-722 47230          Hofmannstr. 51
> Fax:      +49-89-722 47713          D-81359 Munich, GERMANY
> Internet: istvan.sebestyen@mch.pn.siemens.de (preferred)
> 	  sebes@pnsta1.zfe.siemens.de (will be discont. Dec. 97)
>           istvan.sebestyen@pn.siemens.de (Fall back only)
>           dead address: istvan.sebestyen@zfe.siemens.de
> X.400:    c=de;a=dbp;p=scn;o=siemens;ou1=mch;ou2=PN-msmail;
> 	  s=Sebestyen;g=Istvan
> 
> Note: Unfortunately e-mails sent to me can get lost or stay
> unread for a long time, thus I regard e-mail only as additional, 
> and not "official" form of communication to me.
> For very important communication pls. send a fax. 
> ------------------------------------------------------------------
> 
> 
> 



From rem-conf-request@es.net Mon Apr 28 07:28:39 1997 
Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP);
          Mon, 28 Apr 1997 04:28:18 -0700
Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) 
          by rah.star-gate.com (8.8.5/8.7.3) with ESMTP id EAA00425;
          Mon, 28 Apr 1997 04:28:02 -0700 (PDT)
Message-Id: <199704281128.EAA00425@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Reinhard.Foerster@Inf.TU-Dresden.DE (Reinhard Foerster)
cc: hakanl@cdt.luth.se (Hakan Lennestal), rem-conf@es.net
Subject: Re: Video capture driver for Bt848 based cards
In-reply-to: Your message of "Mon, 28 Apr 1997 13:20:43 +0200." <199704281120.NAA10371@rnws02.urz.tu-dresden.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 28 Apr 1997 04:28:02 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>

Great! does it support vic?

	Cheers,
	Amancio
>From The Desk Of Reinhard Foerster :
> > In message <199704242220.PAA03778@rah.star-gate.com>, Amancio Hasty write=
> s:
> 
> A linux driver for bt848 based grabber cards you can find at
> 
>   http://www.thp.uni-koeln.de/~rjkm/
> 
> Reinhard
> 
> > > Latest Bt848 driver available from :
> > > http://freebsd.org/~fsmp/HomeAuto/Bt848.html
> > > ftp://rah.star-gate.com/bt848-clip.tar.gz.=20
> > >=20
> > > The Bt848 driver has been incorporated to  FreeBSD 3.0-current.=20
> >=20
> > Hi !
> >=20
> > Do you know if there is any work going on to port this to Linux ?
> >=20
> > Regards.
> >=20
> > /H=E5kan
> >=20
> 



From rem-conf-request@tmpmail.es.net Mon Apr 28 07:29:57 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Mon, 28 Apr 1997 04:29:46 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wLobr-0000lQ-00; Mon, 28 Apr 1997 04:28:43 -0700
Message-Id: <199704281128.EAA00425@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Reinhard.Foerster@Inf.TU-Dresden.DE (Reinhard Foerster)
cc: hakanl@cdt.luth.se (Hakan Lennestal), rem-conf@es.net
Subject: Re: Video capture driver for Bt848 based cards
In-reply-to: Your message of "Mon, 28 Apr 1997 13:20:43 +0200." <199704281120.NAA10371@rnws02.urz.tu-dresden.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 28 Apr 1997 04:28:02 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Great! does it support vic?

	Cheers,
	Amancio
>From The Desk Of Reinhard Foerster :
> > In message <199704242220.PAA03778@rah.star-gate.com>, Amancio Hasty write=
> s:
> 
> A linux driver for bt848 based grabber cards you can find at
> 
>   http://www.thp.uni-koeln.de/~rjkm/
> 
> Reinhard
> 
> > > Latest Bt848 driver available from :
> > > http://freebsd.org/~fsmp/HomeAuto/Bt848.html
> > > ftp://rah.star-gate.com/bt848-clip.tar.gz.=20
> > >=20
> > > The Bt848 driver has been incorporated to  FreeBSD 3.0-current.=20
> >=20
> > Hi !
> >=20
> > Do you know if there is any work going on to port this to Linux ?
> >=20
> > Regards.
> >=20
> > /H=E5kan
> >=20
> 




From rem-conf-request@tmpmail.es.net Mon Apr 28 07:31:52 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Mon, 28 Apr 1997 04:31:07 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wLoZ9-0000f3-00; Mon, 28 Apr 1997 04:25:55 -0700
Message-Id: <199704281121.EAA00364@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Istvan Sebestyen <istvan.sebestyen@mch.pn.siemens.de>
cc: "Francois D. Menard" <men@mediatrix.com>, rem-conf@es.net, 
    voip-tech@vocaltec.com, taylor@nortel.ca, matumoto@tom.comm.waseda.ac.jp
Subject: Re: Re. Internet telephony performance
In-reply-to: Your message of "Mon, 28 Apr 1997 12:01:32 +0200." <9704281001.AA28456@pnsta1.zfe.siemens.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 28 Apr 1997 04:21:07 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

I am little concern here about some of the patent issues with respect
to G.723 and H.263 and the lack of publicly available tools in fact
it will not surprise me to see a split between commercial tools and
publicly available tools. The time is right given that
most publicly available  mbone tools don't use H.263 or G.723.

	Regards,
	Amancio
	


>From The Desk Of Istvan Sebestyen :
> At 21:16 25.04.1997 -0400, Francois D. Menard wrote:
> Dear Colleagues,
> out of the much longer e-amil message of Mr. Menard - I entirely disagree wit
h -
> I would like to reflect on two issues only. Thus, the explanations of the
> excepts
> of his message presented bellow:
> ....
> I am
> >also voicing my opinion against having to become dependent on ITU 
> >recommendations in order for see Internet Telephony become
> >standardized.
> >
> >Considering that G.723.1 has:
> >
> >o A much too high delay
> >o Disputable Quality
> >o Too many IPR issues that are still unsolved (NTT, 
> >  new! Siemens, others ..., maybe even more ??? ...)
> >o Unclear and relatively expensive price schedule
> >
> ...
>  I am one of the people the beleive that 
> >the IETF and the ITU represent two extremes that are not yet
> >adequate to carry Internet Telephony standardization efforts.
> >
> 
> ...
>  The press 
> >will be quick to pick on the issue of a fight between ITU and VoIP 
> >on Internet Telephony, which is decisively more entertaining than 
> >the latest report on the O.J. case ...
> >
> >Further, the shadow of ITU regulation (... with comes with a long 
> >history of efficient regulation ... ) might be just what is needed 
> >to kill VoIP CMA and definitely kill the potential for 
> >standardization in the area of "Internet Telephony to PSTN 
> >interoperability" across vendors. 
> ....
> 
> >Everyone's priority at this early stage in the Internet Telephony 
> >market should be to grow the pie as fastly as possible, and this 
> >will not happen if VoIP and the ITU are caught in a fight on the 
> >apparently "benine" issue of choosing a  "baseline codec" for 
> >Internet Telephony.
> >
> >If I remember correctly, the VoIP was never started to become a 
> >standards organisation. It will not survive by demonstrating that it
> >is in conflict with the "mother of all standards organisation" in 
> >telecommunications.
> >
> >- - -=Francois=-
> >
> >Francois D. Menard
> >Mediatrix Peripherals Inc.
> >fmenard@mediatrix.com
> >
> My comments as Siemens Representative at IMTC:
> 
> 1       The Siemens AG declared at the Newark meeting of VoIP (VoIP97-029)
> - according to the requirements of
> "IMTC Intellectual Property Code of Condact" that all IMTC members
> have to follow - that it believes it has essential patents both on the
> optional G.723.1 Annex A
> and G.729 Annex B. Thus, there is no difference in that respect between
> the two standards, that were put for voting in front of VoIP. This informatio
n
> was earlier officially also communicated to the ITU TSB.
> 
> My comments as ITU-T SG 16 Ass. Rapporteur Q.16,17 (the Lead ITU-T Study
> Group resonsible 
> for all ITU-T Coordination on Multimedia both internally and externally the
> ITU),
> and as one of the official ITU-T SG16 Liaisons between ITU and IMTC 
> (the other one is Neil Starkey, President of IMTC):
> 
> 2       IMTC and ITU-T are succesfully working together on a number of projec
ts.
> Activities of both organizations are supplementary to eachother and not
> competitive.
> 
> In that spirit, the ITU-T is specifying, approving and maintaining in close
> cooperation with IMTC - among others the
> relevant H, G, and T.Series of ITU-T Recommendations - while IMTC is
> carrying out
> extremely valuable complementary work (including excellent PR activities
> on ITU-T standards, Interoparability Tests of Systems. built on standards,
> etc...many other useful tasks). Up to now the cooperation between ITU-T and I
MTC
> has been excellent, and I see no reason why this should not continue.
> In that spirit I am fully confident that ITU-T and IMTC (including its VoIP
> Forum)
> will continue their fruitful cooperation. 
> 
> Kind regards,
> 
> Istvan Sebestyen    
> ------------------------------------------------------------------
> Istvan Sebestyen                    Siemens AG 
> PN M PE                             Mch H/Pe16 03/807
> Tel:      +49-89-722 47230          Hofmannstr. 51
> Fax:      +49-89-722 47713          D-81359 Munich, GERMANY
> Internet: istvan.sebestyen@mch.pn.siemens.de (preferred)
> 	  sebes@pnsta1.zfe.siemens.de (will be discont. Dec. 97)
>           istvan.sebestyen@pn.siemens.de (Fall back only)
>           dead address: istvan.sebestyen@zfe.siemens.de
> X.400:    c=de;a=dbp;p=scn;o=siemens;ou1=mch;ou2=PN-msmail;
> 	  s=Sebestyen;g=Istvan
> 
> Note: Unfortunately e-mails sent to me can get lost or stay
> unread for a long time, thus I regard e-mail only as additional, 
> and not "official" form of communication to me.
> For very important communication pls. send a fax. 
> ------------------------------------------------------------------
> 
> 
> 




From rem-conf-request@es.net Mon Apr 28 07:48:52 1997 
Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP);
          Mon, 28 Apr 1997 04:48:27 -0700
Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) 
          by rah.star-gate.com (8.8.5/8.7.3) with ESMTP id EAA00653;
          Mon, 28 Apr 1997 04:48:03 -0700 (PDT)
Message-Id: <199704281148.EAA00653@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Reinhard.Foerster@Inf.TU-Dresden.DE (Reinhard Foerster)
cc: hakanl@cdt.luth.se (Hakan Lennestal), rem-conf@es.net
Subject: Re: Video capture driver for Bt848 based cards
In-reply-to: Your message of "Mon, 28 Apr 1997 13:20:43 +0200." <199704281120.NAA10371@rnws02.urz.tu-dresden.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 28 Apr 1997 04:48:03 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>

The FreeBSD is mostly compatible with the FreeBSD Matrox Meteor Driver which
means that tools like vic don't need to be modified. In the case of FreeBSD 
all what needs to be done is to symlink /dev/meteor0 to /dev/bktr0. 
Makes life a little easier from an  application support perspective.

Also, minor point is that the  FreeBSD driver does not require the programmer
to be familiar with the Bt848 Risc instruction set. In the case of the
Linux driver the last time I look at it, the  program has to build the
Risc program to pass it on the the driver which is no big deal if 
a relevant library is provided with the driver.

The  video capture process in the Bt848 is controlled by a Risc Program
which resides in the host memory. Instructions consist of 
write X number of pixels, skip pixels , wait for a frame, etc...

	Cheers,
	Amancio
>From The Desk Of Reinhard Foerster :
> > In message <199704242220.PAA03778@rah.star-gate.com>, Amancio Hasty write=
> s:
> 
> A linux driver for bt848 based grabber cards you can find at

	


From rem-conf-request@tmpmail.es.net Mon Apr 28 07:51:40 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Mon, 28 Apr 1997 04:51:14 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wLovU-0001Xk-00; Mon, 28 Apr 1997 04:49:00 -0700
Message-Id: <199704281148.EAA00653@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Reinhard.Foerster@Inf.TU-Dresden.DE (Reinhard Foerster)
cc: hakanl@cdt.luth.se (Hakan Lennestal), rem-conf@es.net
Subject: Re: Video capture driver for Bt848 based cards
In-reply-to: Your message of "Mon, 28 Apr 1997 13:20:43 +0200." <199704281120.NAA10371@rnws02.urz.tu-dresden.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 28 Apr 1997 04:48:03 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

The FreeBSD is mostly compatible with the FreeBSD Matrox Meteor Driver which
means that tools like vic don't need to be modified. In the case of FreeBSD 
all what needs to be done is to symlink /dev/meteor0 to /dev/bktr0. 
Makes life a little easier from an  application support perspective.

Also, minor point is that the  FreeBSD driver does not require the programmer
to be familiar with the Bt848 Risc instruction set. In the case of the
Linux driver the last time I look at it, the  program has to build the
Risc program to pass it on the the driver which is no big deal if 
a relevant library is provided with the driver.

The  video capture process in the Bt848 is controlled by a Risc Program
which resides in the host memory. Instructions consist of 
write X number of pixels, skip pixels , wait for a frame, etc...

	Cheers,
	Amancio
>From The Desk Of Reinhard Foerster :
> > In message <199704242220.PAA03778@rah.star-gate.com>, Amancio Hasty write=
> s:
> 
> A linux driver for bt848 based grabber cards you can find at

	



From rem-conf-request@es.net Mon Apr 28 08:34:09 1997 
Received: from cs.columbia.edu by osi-west.es.net with ESnet SMTP (PP);
          Mon, 28 Apr 1997 05:33:58 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) 
          by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id IAA20956;
          Mon, 28 Apr 1997 08:33:54 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) 
          by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id IAA03577;
          Mon, 28 Apr 1997 08:33:52 -0400 (EDT)
Sender: hgs@cs.columbia.edu
Message-ID: <33649930.5E58@cs.columbia.edu>
Date: Mon, 28 Apr 1997 08:33:52 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Amancio Hasty <hasty@rah.star-gate.com>
CC: rem-conf@es.net, voip-tech@vocaltec.com
Subject: Re: Re. Internet telephony performance
References: <199704281121.EAA00364@rah.star-gate.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Given the currently specified costs for G.729 and G.723 licenses, their
implementation in freely available non-commercial software seems
unlikely:

- G.723.1: $100k for DSP implementation, including licenses (97-20.doc)
- G.729A and G.729: $220k (VIP97032.doc) or $1.40 per unit, $40k
initial, $10k minimum per year

This is somewhat simplified, but shows, I think, the magnitude of the
problem.

It was pointed out that the GSM codec is also subject to IPR and
licenses (by Phillips), but obviously, there has been no attempt to
enforce this for the free tools.
-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

From rem-conf-request@tmpmail.es.net Mon Apr 28 08:38:00 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Mon, 28 Apr 1997 05:37:39 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wLpdC-00028y-00; Mon, 28 Apr 1997 05:34:10 -0700
Sender: hgs@cs.columbia.edu
Message-ID: <33649930.5E58@cs.columbia.edu>
Date: Mon, 28 Apr 1997 08:33:52 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Amancio Hasty <hasty@rah.star-gate.com>
CC: rem-conf@es.net, voip-tech@vocaltec.com
Subject: Re: Re. Internet telephony performance
References: <199704281121.EAA00364@rah.star-gate.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Given the currently specified costs for G.729 and G.723 licenses, their
implementation in freely available non-commercial software seems
unlikely:

- G.723.1: $100k for DSP implementation, including licenses (97-20.doc)
- G.729A and G.729: $220k (VIP97032.doc) or $1.40 per unit, $40k
initial, $10k minimum per year

This is somewhat simplified, but shows, I think, the magnitude of the
problem.

It was pointed out that the GSM codec is also subject to IPR and
licenses (by Phillips), but obviously, there has been no attempt to
enforce this for the free tools.
-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs


From rem-conf-request@es.net Mon Apr 28 08:57:58 1997 
Received: from faui40.informatik.uni-erlangen.de by osi-west.es.net 
          with ESnet SMTP (PP); Mon, 28 Apr 1997 05:57:49 -0700
Received: from faui45r.informatik.uni-erlangen.de (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) 
          by faui40.informatik.uni-erlangen.de (8.8.5/8.0.5-FAU) with ESMTP 
          id OAA13718; Mon, 28 Apr 1997 14:57:44 +0200 (MET DST)
From: Toerless Eckert <Toerless.Eckert@Informatik.Uni-Erlangen.de>
Message-Id: <199704281257.OAA13718@faui40.informatik.uni-erlangen.de>
Subject: Re: Re. Internet telephony performance
To: schulzrinne@cs.columbia.edu (Henning Schulzrinne)
Date: Mon, 28 Apr 1997 14:57:42 +0200 (MET DST)
Cc: hasty@rah.star-gate.com, rem-conf@es.net, voip-tech@vocaltec.com
In-Reply-To: <33649930.5E58@cs.columbia.edu> from "Henning Schulzrinne" at Apr 28, 97 08:33:52 am
Organisation: CSD IMMD IV, University of Erlangen, Germany
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

> Given the currently specified costs for G.729 and G.723 licenses, their
> implementation in freely available non-commercial software seems
> unlikely:
> 
> - G.723.1: $100k for DSP implementation, including licenses (97-20.doc)
> - G.729A and G.729: $220k (VIP97032.doc) or $1.40 per unit, $40k
> initial, $10k minimum per year
> 
> This is somewhat simplified, but shows, I think, the magnitude of the
> problem.
> 
> It was pointed out that the GSM codec is also subject to IPR and
> licenses (by Phillips), but obviously, there has been no attempt to
> enforce this for the free tools.

Are those licenses applicable to free software anyway (europe/usa ?)

From rem-conf-request@tmpmail.es.net Mon Apr 28 09:00:32 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Mon, 28 Apr 1997 06:00:21 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wLq0F-0002ft-00; Mon, 28 Apr 1997 05:57:59 -0700
From: Toerless Eckert <Toerless.Eckert@Informatik.Uni-Erlangen.de>
Message-Id: <199704281257.OAA13718@faui40.informatik.uni-erlangen.de>
Subject: Re: Re. Internet telephony performance
To: schulzrinne@cs.columbia.edu (Henning Schulzrinne)
Date: Mon, 28 Apr 1997 14:57:42 +0200 (MET DST)
Cc: hasty@rah.star-gate.com, rem-conf@es.net, voip-tech@vocaltec.com
In-Reply-To: <33649930.5E58@cs.columbia.edu> from "Henning Schulzrinne" at Apr 28, 97 08:33:52 am
Organisation: CSD IMMD IV, University of Erlangen, Germany
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

> Given the currently specified costs for G.729 and G.723 licenses, their
> implementation in freely available non-commercial software seems
> unlikely:
> 
> - G.723.1: $100k for DSP implementation, including licenses (97-20.doc)
> - G.729A and G.729: $220k (VIP97032.doc) or $1.40 per unit, $40k
> initial, $10k minimum per year
> 
> This is somewhat simplified, but shows, I think, the magnitude of the
> problem.
> 
> It was pointed out that the GSM codec is also subject to IPR and
> licenses (by Phillips), but obviously, there has been no attempt to
> enforce this for the free tools.

Are those licenses applicable to free software anyway (europe/usa ?)


From rem-conf-request@es.net Mon Apr 28 09:09:08 1997 
Received: from cs.columbia.edu by osi-west.es.net with ESnet SMTP (PP);
          Mon, 28 Apr 1997 06:09:02 -0700
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) 
          by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id JAA21743;
          Mon, 28 Apr 1997 09:08:58 -0400 (EDT)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) 
          by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id JAA03613;
          Mon, 28 Apr 1997 09:08:58 -0400 (EDT)
Sender: hgs@cs.columbia.edu
Message-ID: <3364A169.68BE@cs.columbia.edu>
Date: Mon, 28 Apr 1997 09:08:57 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Toerless Eckert <Toerless.Eckert@Informatik.Uni-Erlangen.de>
CC: rem-conf@es.net, voip-tech@vocaltec.com
Subject: Re: Re. Internet telephony performance
References: <199704281257.OAA13718@faui40.informatik.uni-erlangen.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Toerless Eckert wrote:
> 
> > Given the currently specified costs for G.729 and G.723 licenses, their
> > implementation in freely available non-commercial software seems
> > unlikely:
> >
> > - G.723.1: $100k for DSP implementation, including licenses (97-20.doc)
> > - G.729A and G.729: $220k (VIP97032.doc) or $1.40 per unit, $40k
> > initial, $10k minimum per year
> >
> > This is somewhat simplified, but shows, I think, the magnitude of the
> > problem.
> >
> > It was pointed out that the GSM codec is also subject to IPR and
> > licenses (by Phillips), but obviously, there has been no attempt to
> > enforce this for the free tools.
> 
> Are those licenses applicable to free software anyway (europe/usa ?)

Since many of the IPR owners are non-US (France Telecom and a British
company as well as Siemens of Germany, I think, among others), it
appears likely that these apply everywhere of interest. Note that
(unlike cryptography), import of patented technology into the US (or the
use thereof) without paying the proper royalties will get you into deep
legal trouble quickly. Just ask Mr. Zimmermann of PGP fame (in that
case, however, the RSA patents are indeed only US patents, so the
situation is slightly different).

From rem-conf-request@tmpmail.es.net Mon Apr 28 09:11:46 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Mon, 28 Apr 1997 06:11:26 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wLqB3-00030g-00; Mon, 28 Apr 1997 06:09:09 -0700
Sender: hgs@cs.columbia.edu
Message-ID: <3364A169.68BE@cs.columbia.edu>
Date: Mon, 28 Apr 1997 09:08:57 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Toerless Eckert <Toerless.Eckert@Informatik.Uni-Erlangen.de>
CC: rem-conf@es.net, voip-tech@vocaltec.com
Subject: Re: Re. Internet telephony performance
References: <199704281257.OAA13718@faui40.informatik.uni-erlangen.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Toerless Eckert wrote:
> 
> > Given the currently specified costs for G.729 and G.723 licenses, their
> > implementation in freely available non-commercial software seems
> > unlikely:
> >
> > - G.723.1: $100k for DSP implementation, including licenses (97-20.doc)
> > - G.729A and G.729: $220k (VIP97032.doc) or $1.40 per unit, $40k
> > initial, $10k minimum per year
> >
> > This is somewhat simplified, but shows, I think, the magnitude of the
> > problem.
> >
> > It was pointed out that the GSM codec is also subject to IPR and
> > licenses (by Phillips), but obviously, there has been no attempt to
> > enforce this for the free tools.
> 
> Are those licenses applicable to free software anyway (europe/usa ?)

Since many of the IPR owners are non-US (France Telecom and a British
company as well as Siemens of Germany, I think, among others), it
appears likely that these apply everywhere of interest. Note that
(unlike cryptography), import of patented technology into the US (or the
use thereof) without paying the proper royalties will get you into deep
legal trouble quickly. Just ask Mr. Zimmermann of PGP fame (in that
case, however, the RSA patents are indeed only US patents, so the
situation is slightly different).


From rem-conf-request@es.net Mon Apr 28 16:19:42 1997 
Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP);
          Mon, 28 Apr 1997 13:19:22 -0700
Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) 
          by rah.star-gate.com (8.8.5/8.7.3) with ESMTP id NAA00335;
          Mon, 28 Apr 1997 13:19:02 -0700 (PDT)
Message-Id: <199704282019.NAA00335@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
cc: Toerless Eckert <Toerless.Eckert@Informatik.Uni-Erlangen.de>, 
    rem-conf@es.net, voip-tech@vocaltec.com
Subject: Re: Re. Internet telephony performance
In-reply-to: Your message of "Mon, 28 Apr 1997 09:08:57 EDT." <3364A169.68BE@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 28 Apr 1997 13:19:02 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>

Well, the recent fiasco with GIF worries me a little .

We need a clear legal document stating that G.729, G.723, H.263, and
H.323 is okay to use for publicly available tools and a decent implementation.
Or new codecs for audio and video which perform at least as good as the 
above mentioned ones.

	Cheers,
	Amancio
	




From rem-conf-request@tmpmail.es.net Mon Apr 28 16:42:55 1997 
Received: from mail1.es.net by osi-west.es.net with ESnet SMTP (PP);
          Mon, 28 Apr 1997 13:42:36 -0700
Received: from list by mail1.es.net with local (Exim 1.61 #3) 
          id 0wLwtt-00068f-00; Mon, 28 Apr 1997 13:19:53 -0700
Message-Id: <199704282019.NAA00335@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
cc: Toerless Eckert <Toerless.Eckert@Informatik.Uni-Erlangen.de>, 
    rem-conf@es.net, voip-tech@vocaltec.com
Subject: Re: Re. Internet telephony performance
In-reply-to: Your message of "Mon, 28 Apr 1997 09:08:57 EDT." <3364A169.68BE@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 28 Apr 1997 13:19:02 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>
X-Mailing-List: <rem-conf@tmpmail.es.net>
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Well, the recent fiasco with GIF worries me a little .

We need a clear legal document stating that G.729, G.723, H.263, and
H.323 is okay to use for publicly available tools and a decent implementation.
Or new codecs for audio and video which perform at least as good as the 
above mentioned ones.

	Cheers,
	Amancio
	





From rem-conf Mon Apr 28 14:08:09 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 14:08:08 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wLwtt-00068f-00; Mon, 28 Apr 1997 13:19:53 -0700
Message-Id: <199704282019.NAA00335@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
cc: Toerless Eckert <Toerless.Eckert@Informatik.Uni-Erlangen.de>, 
    rem-conf@es.net, voip-tech@vocaltec.com
Subject: Re: Re. Internet telephony performance
In-reply-to: Your message of "Mon, 28 Apr 1997 09:08:57 EDT." <3364A169.68BE@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 28 Apr 1997 13:19:02 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Well, the recent fiasco with GIF worries me a little .

We need a clear legal document stating that G.729, G.723, H.263, and
H.323 is okay to use for publicly available tools and a decent implementation.
Or new codecs for audio and video which perform at least as good as the 
above mentioned ones.

	Cheers,
	Amancio
	






From rem-conf Mon Apr 28 14:08:11 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 14:08:11 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wLqB3-00030g-00; Mon, 28 Apr 1997 06:09:09 -0700
Sender: hgs@cs.columbia.edu
Message-ID: <3364A169.68BE@cs.columbia.edu>
Date: Mon, 28 Apr 1997 09:08:57 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Toerless Eckert <Toerless.Eckert@Informatik.Uni-Erlangen.de>
CC: rem-conf@es.net, voip-tech@vocaltec.com
Subject: Re: Re. Internet telephony performance
References: <199704281257.OAA13718@faui40.informatik.uni-erlangen.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Toerless Eckert wrote:
> 
> > Given the currently specified costs for G.729 and G.723 licenses, their
> > implementation in freely available non-commercial software seems
> > unlikely:
> >
> > - G.723.1: $100k for DSP implementation, including licenses (97-20.doc)
> > - G.729A and G.729: $220k (VIP97032.doc) or $1.40 per unit, $40k
> > initial, $10k minimum per year
> >
> > This is somewhat simplified, but shows, I think, the magnitude of the
> > problem.
> >
> > It was pointed out that the GSM codec is also subject to IPR and
> > licenses (by Phillips), but obviously, there has been no attempt to
> > enforce this for the free tools.
> 
> Are those licenses applicable to free software anyway (europe/usa ?)

Since many of the IPR owners are non-US (France Telecom and a British
company as well as Siemens of Germany, I think, among others), it
appears likely that these apply everywhere of interest. Note that
(unlike cryptography), import of patented technology into the US (or the
use thereof) without paying the proper royalties will get you into deep
legal trouble quickly. Just ask Mr. Zimmermann of PGP fame (in that
case, however, the RSA patents are indeed only US patents, so the
situation is slightly different).



From rem-conf Mon Apr 28 14:08:13 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 14:08:12 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wLq0F-0002ft-00; Mon, 28 Apr 1997 05:57:59 -0700
From: Toerless Eckert <Toerless.Eckert@Informatik.Uni-Erlangen.de>
Message-Id: <199704281257.OAA13718@faui40.informatik.uni-erlangen.de>
Subject: Re: Re. Internet telephony performance
To: schulzrinne@cs.columbia.edu (Henning Schulzrinne)
Date: Mon, 28 Apr 1997 14:57:42 +0200 (MET DST)
Cc: hasty@rah.star-gate.com, rem-conf@es.net, voip-tech@vocaltec.com
In-Reply-To: <33649930.5E58@cs.columbia.edu> from "Henning Schulzrinne" at Apr 28, 97 08:33:52 am
Organisation: CSD IMMD IV, University of Erlangen, Germany
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

> Given the currently specified costs for G.729 and G.723 licenses, their
> implementation in freely available non-commercial software seems
> unlikely:
> 
> - G.723.1: $100k for DSP implementation, including licenses (97-20.doc)
> - G.729A and G.729: $220k (VIP97032.doc) or $1.40 per unit, $40k
> initial, $10k minimum per year
> 
> This is somewhat simplified, but shows, I think, the magnitude of the
> problem.
> 
> It was pointed out that the GSM codec is also subject to IPR and
> licenses (by Phillips), but obviously, there has been no attempt to
> enforce this for the free tools.

Are those licenses applicable to free software anyway (europe/usa ?)



From rem-conf Mon Apr 28 14:08:15 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 14:08:14 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wLoZ9-0000f3-00; Mon, 28 Apr 1997 04:25:55 -0700
Message-Id: <199704281121.EAA00364@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Istvan Sebestyen <istvan.sebestyen@mch.pn.siemens.de>
cc: "Francois D. Menard" <men@mediatrix.com>, rem-conf@es.net, 
    voip-tech@vocaltec.com, taylor@nortel.ca, matumoto@tom.comm.waseda.ac.jp
Subject: Re: Re. Internet telephony performance
In-reply-to: Your message of "Mon, 28 Apr 1997 12:01:32 +0200." <9704281001.AA28456@pnsta1.zfe.siemens.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 28 Apr 1997 04:21:07 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

I am little concern here about some of the patent issues with respect
to G.723 and H.263 and the lack of publicly available tools in fact
it will not surprise me to see a split between commercial tools and
publicly available tools. The time is right given that
most publicly available  mbone tools don't use H.263 or G.723.

	Regards,
	Amancio
	


>From The Desk Of Istvan Sebestyen :
> At 21:16 25.04.1997 -0400, Francois D. Menard wrote:
> Dear Colleagues,
> out of the much longer e-amil message of Mr. Menard - I entirely disagree wit
h -
> I would like to reflect on two issues only. Thus, the explanations of the
> excepts
> of his message presented bellow:
> ....
> I am
> >also voicing my opinion against having to become dependent on ITU 
> >recommendations in order for see Internet Telephony become
> >standardized.
> >
> >Considering that G.723.1 has:
> >
> >o A much too high delay
> >o Disputable Quality
> >o Too many IPR issues that are still unsolved (NTT, 
> >  new! Siemens, others ..., maybe even more ??? ...)
> >o Unclear and relatively expensive price schedule
> >
> ...
>  I am one of the people the beleive that 
> >the IETF and the ITU represent two extremes that are not yet
> >adequate to carry Internet Telephony standardization efforts.
> >
> 
> ...
>  The press 
> >will be quick to pick on the issue of a fight between ITU and VoIP 
> >on Internet Telephony, which is decisively more entertaining than 
> >the latest report on the O.J. case ...
> >
> >Further, the shadow of ITU regulation (... with comes with a long 
> >history of efficient regulation ... ) might be just what is needed 
> >to kill VoIP CMA and definitely kill the potential for 
> >standardization in the area of "Internet Telephony to PSTN 
> >interoperability" across vendors. 
> ....
> 
> >Everyone's priority at this early stage in the Internet Telephony 
> >market should be to grow the pie as fastly as possible, and this 
> >will not happen if VoIP and the ITU are caught in a fight on the 
> >apparently "benine" issue of choosing a  "baseline codec" for 
> >Internet Telephony.
> >
> >If I remember correctly, the VoIP was never started to become a 
> >standards organisation. It will not survive by demonstrating that it
> >is in conflict with the "mother of all standards organisation" in 
> >telecommunications.
> >
> >- - -=Francois=-
> >
> >Francois D. Menard
> >Mediatrix Peripherals Inc.
> >fmenard@mediatrix.com
> >
> My comments as Siemens Representative at IMTC:
> 
> 1       The Siemens AG declared at the Newark meeting of VoIP (VoIP97-029)
> - according to the requirements of
> "IMTC Intellectual Property Code of Condact" that all IMTC members
> have to follow - that it believes it has essential patents both on the
> optional G.723.1 Annex A
> and G.729 Annex B. Thus, there is no difference in that respect between
> the two standards, that were put for voting in front of VoIP. This informatio
n
> was earlier officially also communicated to the ITU TSB.
> 
> My comments as ITU-T SG 16 Ass. Rapporteur Q.16,17 (the Lead ITU-T Study
> Group resonsible 
> for all ITU-T Coordination on Multimedia both internally and externally the
> ITU),
> and as one of the official ITU-T SG16 Liaisons between ITU and IMTC 
> (the other one is Neil Starkey, President of IMTC):
> 
> 2       IMTC and ITU-T are succesfully working together on a number of projec
ts.
> Activities of both organizations are supplementary to eachother and not
> competitive.
> 
> In that spirit, the ITU-T is specifying, approving and maintaining in close
> cooperation with IMTC - among others the
> relevant H, G, and T.Series of ITU-T Recommendations - while IMTC is
> carrying out
> extremely valuable complementary work (including excellent PR activities
> on ITU-T standards, Interoparability Tests of Systems. built on standards,
> etc...many other useful tasks). Up to now the cooperation between ITU-T and I
MTC
> has been excellent, and I see no reason why this should not continue.
> In that spirit I am fully confident that ITU-T and IMTC (including its VoIP
> Forum)
> will continue their fruitful cooperation. 
> 
> Kind regards,
> 
> Istvan Sebestyen    
> ------------------------------------------------------------------
> Istvan Sebestyen                    Siemens AG 
> PN M PE                             Mch H/Pe16 03/807
> Tel:      +49-89-722 47230          Hofmannstr. 51
> Fax:      +49-89-722 47713          D-81359 Munich, GERMANY
> Internet: istvan.sebestyen@mch.pn.siemens.de (preferred)
> 	  sebes@pnsta1.zfe.siemens.de (will be discont. Dec. 97)
>           istvan.sebestyen@pn.siemens.de (Fall back only)
>           dead address: istvan.sebestyen@zfe.siemens.de
> X.400:    c=de;a=dbp;p=scn;o=siemens;ou1=mch;ou2=PN-msmail;
> 	  s=Sebestyen;g=Istvan
> 
> Note: Unfortunately e-mails sent to me can get lost or stay
> unread for a long time, thus I regard e-mail only as additional, 
> and not "official" form of communication to me.
> For very important communication pls. send a fax. 
> ------------------------------------------------------------------
> 
> 
> 





From rem-conf Mon Apr 28 14:09:23 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 14:09:23 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wLobr-0000lQ-00; Mon, 28 Apr 1997 04:28:43 -0700
Message-Id: <199704281128.EAA00425@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Reinhard.Foerster@Inf.TU-Dresden.DE (Reinhard Foerster)
cc: hakanl@cdt.luth.se (Hakan Lennestal), rem-conf@es.net
Subject: Re: Video capture driver for Bt848 based cards
In-reply-to: Your message of "Mon, 28 Apr 1997 13:20:43 +0200." <199704281120.NAA10371@rnws02.urz.tu-dresden.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 28 Apr 1997 04:28:02 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Great! does it support vic?

	Cheers,
	Amancio
>From The Desk Of Reinhard Foerster :
> > In message <199704242220.PAA03778@rah.star-gate.com>, Amancio Hasty write=
> s:
> 
> A linux driver for bt848 based grabber cards you can find at
> 
>   http://www.thp.uni-koeln.de/~rjkm/
> 
> Reinhard
> 
> > > Latest Bt848 driver available from :
> > > http://freebsd.org/~fsmp/HomeAuto/Bt848.html
> > > ftp://rah.star-gate.com/bt848-clip.tar.gz.=20
> > >=20
> > > The Bt848 driver has been incorporated to  FreeBSD 3.0-current.=20
> >=20
> > Hi !
> >=20
> > Do you know if there is any work going on to port this to Linux ?
> >=20
> > Regards.
> >=20
> > /H=E5kan
> >=20
> 





From rem-conf Mon Apr 28 14:09:25 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 14:09:24 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wLnMU-0007ZK-00; Mon, 28 Apr 1997 03:08:46 -0700
Date: Mon, 28 Apr 97 12:01:32 +0200
Message-Id: <9704281001.AA28456@pnsta1.zfe.siemens.de>
X-Sender: sebes@sta12_mue
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: "Francois D. Menard" <men@mediatrix.com>
From: Istvan Sebestyen <istvan.sebestyen@mch.pn.siemens.de>
Subject: Re: Re. Internet telephony performance
Cc: rem-conf@es.net, voip-tech@vocaltec.com, taylor@nortel.ca, 
    matumoto@tom.comm.waseda.ac.jp
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

At 21:16 25.04.1997 -0400, Francois D. Menard wrote:
Dear Colleagues,
out of the much longer e-amil message of Mr. Menard - I entirely disagree with -
I would like to reflect on two issues only. Thus, the explanations of the
excepts
of his message presented bellow:
....
I am
>also voicing my opinion against having to become dependent on ITU 
>recommendations in order for see Internet Telephony become
>standardized.
>
>Considering that G.723.1 has:
>
>o A much too high delay
>o Disputable Quality
>o Too many IPR issues that are still unsolved (NTT, 
>  new! Siemens, others ..., maybe even more ??? ...)
>o Unclear and relatively expensive price schedule
>
...
 I am one of the people the beleive that 
>the IETF and the ITU represent two extremes that are not yet
>adequate to carry Internet Telephony standardization efforts.
>

...
 The press 
>will be quick to pick on the issue of a fight between ITU and VoIP 
>on Internet Telephony, which is decisively more entertaining than 
>the latest report on the O.J. case ...
>
>Further, the shadow of ITU regulation (... with comes with a long 
>history of efficient regulation ... ) might be just what is needed 
>to kill VoIP CMA and definitely kill the potential for 
>standardization in the area of "Internet Telephony to PSTN 
>interoperability" across vendors. 
....

>Everyone's priority at this early stage in the Internet Telephony 
>market should be to grow the pie as fastly as possible, and this 
>will not happen if VoIP and the ITU are caught in a fight on the 
>apparently "benine" issue of choosing a  "baseline codec" for 
>Internet Telephony.
>
>If I remember correctly, the VoIP was never started to become a 
>standards organisation. It will not survive by demonstrating that it
>is in conflict with the "mother of all standards organisation" in 
>telecommunications.
>
>- - -=Francois=-
>
>Francois D. Menard
>Mediatrix Peripherals Inc.
>fmenard@mediatrix.com
>
My comments as Siemens Representative at IMTC:

1       The Siemens AG declared at the Newark meeting of VoIP (VoIP97-029)
- according to the requirements of
"IMTC Intellectual Property Code of Condact" that all IMTC members
have to follow - that it believes it has essential patents both on the
optional G.723.1 Annex A
and G.729 Annex B. Thus, there is no difference in that respect between
the two standards, that were put for voting in front of VoIP. This information
was earlier officially also communicated to the ITU TSB.

My comments as ITU-T SG 16 Ass. Rapporteur Q.16,17 (the Lead ITU-T Study
Group resonsible 
for all ITU-T Coordination on Multimedia both internally and externally the
ITU),
and as one of the official ITU-T SG16 Liaisons between ITU and IMTC 
(the other one is Neil Starkey, President of IMTC):

2       IMTC and ITU-T are succesfully working together on a number of projects.
Activities of both organizations are supplementary to eachother and not
competitive.

In that spirit, the ITU-T is specifying, approving and maintaining in close
cooperation with IMTC - among others the
relevant H, G, and T.Series of ITU-T Recommendations - while IMTC is
carrying out
extremely valuable complementary work (including excellent PR activities
on ITU-T standards, Interoparability Tests of Systems. built on standards,
etc...many other useful tasks). Up to now the cooperation between ITU-T and IMTC
has been excellent, and I see no reason why this should not continue.
In that spirit I am fully confident that ITU-T and IMTC (including its VoIP
Forum)
will continue their fruitful cooperation. 

Kind regards,

Istvan Sebestyen    
------------------------------------------------------------------
Istvan Sebestyen                    Siemens AG 
PN M PE                             Mch H/Pe16 03/807
Tel:      +49-89-722 47230          Hofmannstr. 51
Fax:      +49-89-722 47713          D-81359 Munich, GERMANY
Internet: istvan.sebestyen@mch.pn.siemens.de (preferred)
	  sebes@pnsta1.zfe.siemens.de (will be discont. Dec. 97)
          istvan.sebestyen@pn.siemens.de (Fall back only)
          dead address: istvan.sebestyen@zfe.siemens.de
X.400:    c=de;a=dbp;p=scn;o=siemens;ou1=mch;ou2=PN-msmail;
	  s=Sebestyen;g=Istvan

Note: Unfortunately e-mails sent to me can get lost or stay
unread for a long time, thus I regard e-mail only as additional, 
and not "official" form of communication to me.
For very important communication pls. send a fax. 
------------------------------------------------------------------





From rem-conf Mon Apr 28 14:09:26 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 14:09:26 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wLf84-0003zg-00; Sun, 27 Apr 1997 18:21:20 -0700
Message-ID: <33484BAE.54E9@chollian.net>
Date: Mon, 07 Apr 1997 10:19:42 +0900
From: Roh Jeong-Hun <ohnohoya@chollian.net>
Organization: Seoul National University
X-Mailer: Mozilla 3.0Gold (Win95; I)
MIME-Version: 1.0
To: rem-conf@es.net
Subject: about 'Translators' of RTP.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

This is about 'Translators' of RTP.
In RFC1889-page 40-, it says 'translator forwards RTP packets with
their SSRC identifier intact;this makes it possible for receivers
to identify individual sources even though packets from all the
sources pass through the same translator and carry the translator's
network source address'.
Why does it carry 'its network source address'? I guess it may
cause looping problems.. I don't know why it should change
the source address with its own.

If you know the answer or the reference that I can get the answer
from, please tell me.

Thanks.



From rem-conf Mon Apr 28 14:09:27 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 14:09:27 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wLf5R-0003xj-00; Sun, 27 Apr 1997 18:18:37 -0700
Message-ID: <33484B02.7833@chollian.net>
Date: Mon, 07 Apr 1997 10:16:50 +0900
From: Roh Jeong-Hun <ohnohoya@chollian.net>
Organization: Seoul National University
X-Mailer: Mozilla 3.0Gold (Win95; I)
MIME-Version: 1.0
To: rem-conf@es.net
Subject: about 'cumulative neumber of packets lost' of RTP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

I'm a beginner in this RTP field.This is a kind of simple question.
i don't understand why 'cumulative neumber of packets lost' which 
is one of the fields in the RR(report reception) of RTCP packet.
RFC1889 says that this value is defined to be the number of packets
exepected less the number of packets actually received, where the
number of packets received includes any which are late or duplicates.
I don't get the reason why we don't distinguish late or dupliacated
packets from well received packets. 

Thanx a lot for reading this. I hope you to let me know what I 
don't know...



From rem-conf Mon Apr 28 14:09:29 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 14:09:28 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wKwxy-0001A0-00; Fri, 25 Apr 1997 19:11:58 -0700
Date: Fri, 25 Apr 1997 18:49:13 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Isabelle HAIGNERE <haignere@issy.cnet.fr>
cc: rem-conf@es.net
Subject: Re: g723 payloads
In-Reply-To: <9704251451.AA01082@haddock>
Message-ID: <Pine.WNT.3.95.970425184621.-131667T-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

On Fri, 25 Apr 1997, Isabelle HAIGNERE wrote:

> In the profile of RTP-RFC1890, the G723 payload has been defined and
> moreover I have received the G723 RTP payload from Ken Mills from Intel
> through the rem-conf mailing-list, what about the precise status of this
> document and the G723 payload ? Is this version the last version of the
> G723 rtp payload ?

See draft-ietf-avt-profile-new-00.ps or .txt which gives more details
about the G723 RTP payload format.  This document is working towards
publication of a revised RFC as part of the process of advancing to
Draft Standard status.
							-- Steve




From rem-conf Mon Apr 28 14:09:30 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 14:09:29 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wLa78-0002BZ-00; Sun, 27 Apr 1997 13:00:02 -0700
Message-Id: <s3636ae0.053@langate.tnet.state.tn.us>
X-Mailer: Novell GroupWise 4.1
Date: Sun, 27 Apr 1997 15:03:32 -0500
From: Eric Hauch <ehauch@mail.state.tn.us>
To: t1a15@t1.org
Cc: rem-conf@es.net
Subject: T1A1.5 Postings
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Hi Gang!

I have just uploaded to T1BBS the following documents:

7a150030.doc:  Report from our Jan/97 Orlando meeting.

7a155040.doc:  Copies of the overheads from a presentation I
made to the IETF AVT WG on Apr 9 in Memphis.

More to come,

Eric

P.S. (for the IETF AVT members):  These docs can be found
in the T1A1.5 file space at www.t1.org (or more directly, goto
http://www.t1.org/t1a1/_a1-grid.htm).





From rem-conf Mon Apr 28 14:09:32 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 14:09:31 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wKYhV-0002K9-00; Thu, 24 Apr 1997 17:17:21 -0700
X-Sender: muzardj@mistral.ere.umontreal.ca
Message-Id: <v0153051caf8532eaa35a@[142.62.1.234]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 24 Apr 1997 12:30:43 -0400
To: wangjian@doctor4u.com, confctrl@isi.edu
From: muzardj@ERE.UMontreal.CA (Joel Muzard)
Subject: Re: help
Cc: cscw-sig@mailbase.ac.uk, rem-conf@es.net, vidconf@pulver.com, 
    videophone@es.net, VIDNET-L@uga.cc.uga.edu
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

At 12:12 23/04/97, WANG Jian wrote:
>hi,
>
>I am making plans for a project on real-time collaberative system.
>
>I want to know
>1, the prices of QuickTime Conferencing products, and
>2, the products of mac-based shared editor or collaberative writer and
>their prices.

I invite you to have a look at http://ideaprocessor.citi.doc.ca
If you have questions, then contact me.

Joel



--------------*

Dr. Joel Muzard
President
Atelier d'informatique appliquee (AiA) Inc.
(514) 973-5769
(514) 973-5757 Fax-telecopieur
WWW:
http://IdeaProcessor.citi.doc.ca/





From rem-conf Mon Apr 28 14:09:33 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 14:09:33 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wKwCN-0000gV-00; Fri, 25 Apr 1997 18:22:47 -0700
Message-Id: <3.0.1.32.19970425212127.02591888@nettrix.mediatrix.com>
X-Sender: francois@nettrix.mediatrix.com
Disposition-Notification-To: <men@mediatrix.com>
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
X-Priority: 2 (High)
Date: Fri, 25 Apr 1997 21:21:27 -0400
To: rem-conf@es.net
From: "Francois D. Menard" <men@mediatrix.com>
Subject: Re. Internet telephony performance
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

I Reposted Mr. Dvorak's email in ASCII for the benefit of 
everyone. It is appended to the bottom of this post.

Hopefully, you will all allow me to throw in a personal comment
in relation to to Mr. Dvorak's request for action to SG-16.

I am seriously voicing my opinion against the VoIP decision to 
choose the G.723.1 codec as a baseline codec.  However, I am
also voicing my opinion against having to become dependent on ITU 
recommendations in order for see Internet Telephony become
standardized.

Considering that G.723.1 has:

o A much too high delay
o Disputable Quality
o Too many IPR issues that are still unsolved (NTT, 
  new! Siemens, others ..., maybe even more ??? ...)
o Unclear and relatively expensive price schedule

Considering that G.729 has:

o Delays ensuring that the objectives mentioned in the G.114 spec 
  will be well within reach on well designed IP networks
o Toll Quality recognized by everyone
o Much, much clearer IPR issues
o Interesting Price Schedule (According to the VOIP97032.DOC 
  on the VOIP FTP site submitted by Laurent Amar of SiproLab)
o And that if Microsoft puts an implementation of G.729a in 
  Netmeeting,  there will still be 60 millions ports of G.729a 
  on the field (therefore ending once and for all the argument 
  that G.723.1 has more ports on the field than G.729a)

My call to action to all VoIP members (the company that I work 
is not yet a VoIP member due mainly to this reason) is to backtrack 
on the decision of the VoIP and to advise VoIP members to use a 
little bit of common sense, be responsible, recognize their error 
and vote for G.729.

For Internet Telephony to succeed, we all need something like the
"CMA" concept from Vocaltec. Everyone knows that this is the
heart of the VoIP specification and the only reason on why there
should be a VoIP Forum.  I am one of the people the beleive that 
the IETF and the ITU represent two extremes that are not yet
adequate to carry Internet Telephony standardization efforts.

All VoIP members will probably agree with my statement that 
the press currently recognizes VoIP as the industry forum where real
Internet Telephony initial standardization efforts are happening.  

By not correcting this mistake and by forcing SG-16 to vote on
this call to action from SG-12,  VoIP might loose a good amount
of credibility in front of the press and the industry.  The press 
will be quick to pick on the issue of a fight between ITU and VoIP 
on Internet Telephony, which is decisively more entertaining than 
the latest report on the O.J. case ...

Further, the shadow of ITU regulation (... with comes with a long 
history of efficient regulation ... ) might be just what is needed 
to kill VoIP CMA and definitely kill the potential for 
standardization in the area of "Internet Telephony to PSTN 
interoperability" across vendors. And the VoIP people will surely 
not want this to happen.

***************************************************************
To put the gutz of my email into a fully reduced inequation:

(IETF SIP/SAP/LDAP + ITU H.32x/Gatekeepers/Gateway) ==
(ITU H.323 + ITU G.729 + VoIP CMA + IETF LDAP)

It is only under the auspices of such an inequation getting solved
that I see Internet Telephony industry moving forward and I appeal 
to all concerned parties to re-activate discussions on the choice 
of a baseline codec.
***************************************************************

I invite everyone to re-read a recent issue of DATA Communications
raising the points of "if standards bodies should have more legal
responsabilities and if a method to see end-users have a right
to veto on the ballot vote before any recommendation is sanctioned.

Everyone's priority at this early stage in the Internet Telephony 
market should be to grow the pie as fastly as possible, and this 
will not happen if VoIP and the ITU are caught in a fight on the 
apparently "benine" issue of choosing a  "baseline codec" for 
Internet Telephony.

If I remember correctly, the VoIP was never started to become a 
standards organisation. It will not survive by demonstrating that it
is in conflict with the "mother of all standards organisation" in 
telecommunications.

-=Francois=-

Francois D. Menard
Mediatrix Peripherals Inc.
fmenard@mediatrix.com

BTW. I'm 23 years old.  So I guess that my analysis of the 
situation isn't so bad for someone that is relatively new
in the area of telecom regulations ...

"Bow down to the one you serve, you'll only get what you deserve"
 - Trent Reznor, Nine Inch Nails. 
 Most appropriate .sig considering the subject of this post.

========================
TEXT OF Mr. Dvorak
========================

Below is an "informal communication" which ITU-T Study Group 12,
whose mandate is end-to-end transmission quality, agreed to
send to the IETF and the IMTC VOIP Activity Group. SG 12 wants
to share our information with the international community
working in Internet telephony, and we're happy to collaborate.

I have been instructed that the most effective way to disseminate
this note is in ASCII via the e-mail lists to which I have sent it.
(Apologies in advance if this in not correct.)

Thanks,

Chuck Dvorak, SG12 Vice Chairman on behalf of SG12

ITU - Telecommun. Standardization Sector   Temp. Doc 014-E (PL12)

STUDY GROUP 12

Geneva, 7 - 18 April 1997
Questions: 16/12, 18/12, 19/12, 21/12

SOURCE:	Study Group 12

Subject:	Speech Quality Aspects of Internet Telephony

To:		ITU-T SG 16 (for action)
		ITU-T SGs 2, 13, 15 (for information)
		IETF, IMTC VoIP Activity Group (for information)

Approval:	ITU-T SG 12

Deadline for Reply:	30 days after next meeting of  Q.13/16

Contacts:	Paul Coverdale, Chairman WP 2/12
		Tel / Fax: +1.613.763.4277 / 1.613.763.9029
		E-mail: paulcov@nortel.ca

		Charles Dvorak, Chairman WP 3/12
		Tel / Fax: +1.908.580.6418 / 1.908.580.6881
		E-mail: cdvorak@attmail.com

SG 12 thanks SG16 for its invitation to collaborate on Internet
telephony. SG 12 welcomes this collaboration because of our
expertise on multimedia subjective and objective assessment (WP
2/12), and on transmission performance and planning (WP 3/12).
These areas are likely to be critical to the success of Internet
telephony, and we gladly offer the benefits of our experience.

To contribute immediately to the collaboration on Internet
telephony, SG 12 offers information that it hopes will be useful,
given the SG 16 activities described in the liaison we received.

SG 12 is very concerned about the potential selection of a default
speech codec for H.323v2 in the apparent absence of adequate
consideration of the transmission performance implications of any
such selection. In our opinion there are many aspects of end-to-end
quality, but two major considerations in this case are the ability
of a codec to interwork with other elements of the overall
connection, and the delay inserted into the connection by the
codec. These factors can have a serious negative impact on the
user's judgment of service quality.

Regarding the effect of speech coding on transmission quality, the
G.729 Annex A (G.729A) codec has been tested thoroughly by SG12
experts to assure that it satisfied the very stringent terms-of-
reference required of a low bit-rate codec intended for multiple
applications. These requirements included an ability to be tandemed
with other types of codecs, so that no serious degradation of
quality resulted. SG12 is unaware of any similar, comprehensive
testing of the G.723.1 codec, which we understand was developed for
videophone application. Thus, it is unclear how well G.723.1 will
perform when interconnection to the PSTN is attempted.

Regarding the effect of delay on the suitability of a connection
for speech communications, it is our understanding that, due to
processing delay and the way in which frames are arranged, a one-
way delay of approximately 100 ms occurs with G.723.1, whereas
G.729A introduces about a third of this amount. A value of 100 ms
exceeds by 100% the signal processing delay allocation guidelines
of G.114, which SG 12 revised recently to draw attention to the
negative quality impact of such large processing delays. Thus,
while the incremental transmission delay caused by G.723.1 may not
be problematic for regional point-to-point applications over
terrestrial facilities, such incremental delays will have a serious
negative impact if added to transoceanic connections over which
multipoint applications are used. This problem is not avoided by
merely saying that G.723.1 should be used for multimedia
pplications.

Study Group 12 emphasizes that echo control is also likely to be a
major issue with Internet telephony, and Recommendation G.131
provides guidance in this area.

In conclusion, SG12 recognizes the urgency for new Recommendations
on Internet telephony, given the market pressures on the deployment
of such applications. Accordingly, SG 12 applauds SG16 for
aggressively tackling standards work on this important topic.
However, as per the guidance we have provided in this document,
pertinent information already exists that can be used by the ITU
to make codec selections so that user applications are supported
with acceptable quality.
***************

---
#*# -- Francois D. Menard -- Mediatrix Inc. -- fmenard@mediatrix.com 
Product Specialist  / New Product Development /  Strategic Marketing
Visit our WWW site: http://www.mediatrix.com - Awesome new products!
(other e-mail addresses)  francois_menard@msn.com  or  men@login.net
PGP Key fingerprint E2 9D F6 73 2D F4 18 49  C9 3E F0 6D 0C BD B4 FF




From rem-conf Mon Apr 28 14:09:34 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 14:09:34 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wKuQF-0007SX-00; Fri, 25 Apr 1997 16:28:59 -0700
Date: Fri, 25 Apr 1997 19:27:44 -0500
From: cdvorak@attmail.com (Charles A Dvorak)
Subject: Internet telephony performance
To: rem-conf@es.net, voip-tech@vocaltec.com
Cc: caomj@online.sh.cn, paulcov@nortel.ca, simao@ctd.comsat.com, 
    judith.katona@itu.int, petrack@vocaltec.com
Mime-Version: 1.0
Content-Type: application/octet-stream
Content-Transfer-Encoding: quoted-printable
Message-ID: <winATT-3.01-cdvorak-2299>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Mailing lists of the IETF and the IMTC VOIP group:=0D
=0D
Below is an =22informal communication=22 which ITU-T Study Group 12,=0D
whose mandate is end-to-end transmission quality, agreed to=0D
send to the IETF and the IMTC VOIP Activity Group. SG 12 wants=0D
to share our information with the international community=0D
working in Internet telephony, and we're happy to collaborate.=0D
=0D
I have been instructed that the most effective way to disseminate=0D
this note is in ASCII via the e-mail lists to which I have sent it.=0D
(Apologies in advance if this in not correct.)=0D
=0D
Thanks,=0D
=0D
Chuck Dvorak, SG12 Vice Chairman on behalf of SG12=0D
=0D
=0C=0D
ITU - Telecommun. Standardization Sector=09=09Temp. Doc 014-E (PL12) =0D
=0D
STUDY GROUP 12=0D
______________________________ =0D
=0D
Geneva, 7 - 18 April 1997 =0D
Questions: 16/12, 18/12, 19/12, 21/12=0D
=0D
SOURCE:=09Study Group 12=0D
=0D
Subject:=09Speech Quality Aspects of Internet Telephony=0D
=0D
To:=09=09ITU-T SG 16 (for action)=0D
=09=09ITU-T SGs 2, 13, 15 (for information)=0D
=09=09IETF, IMTC VoIP Activity Group (for information)=0D
=0D
Approval:=09ITU-T SG 12=0D
=0D
Deadline for Reply:=0930 days after next meeting of  Q.13/16=0D
=0D
Contacts:=09Paul Coverdale, Chairman WP 2/12=0D
=09=09Tel / Fax: +1.613.763.4277 / 1.613.763.9029=0D
=09=09E-mail: paulcov=40nortel.ca=0D
=0D
=09=09Charles Dvorak, Chairman WP 3/12=0D
=09=09Tel / Fax: +1.908.580.6418 / 1.908.580.6881=0D
=09=09E-mail: cdvorak=40attmail.com=0D
=0D
SG 12 thanks SG16 for its invitation to collaborate on Internet =0D
telephony. SG 12 welcomes this collaboration because of our =0D
expertise on multimedia subjective and objective assessment (WP =0D
2/12), and on transmission performance and planning (WP 3/12). =0D
These areas are likely to be critical to the success of Internet =0D
telephony, and we gladly offer the benefits of our experience. =0D
=0D
To contribute immediately to the collaboration on Internet =0D
telephony, SG 12 offers information that it hopes will be useful, =0D
given the SG 16 activities described in the liaison we received.=0D
=0D
SG 12 is very concerned about the potential selection of a default =0D
speech codec for H.323v2 in the apparent absence of adequate =0D
consideration of the transmission performance implications of any =0D
such selection. In our opinion there are many aspects of end-to-end =0D
quality, but two major considerations in this case are the ability =0D
of a codec to interwork with other elements of the overall =0D
connection, and the delay inserted into the connection by the =0D
codec. These factors can have a serious negative impact on the =0D
user=92s judgment of service quality.=0D
=0D
Regarding the effect of speech coding on transmission quality, the =0D
G.729 Annex A (G.729A) codec has been tested thoroughly by SG12 =0D
experts to assure that it satisfied the very stringent terms-of-=0D
reference required of a low bit-rate codec intended for multiple =0D
applications. These requirements included an ability to be tandemed =0D
with other types of codecs, so that no serious degradation of =0D
quality resulted. SG12 is unaware of any similar, comprehensive =0D
testing of the G.723.1 codec, which we understand was developed for =0D
videophone application. Thus, it is unclear how well G.723.1 will =0D
perform when interconnection to the PSTN is attempted.=0D
=0D
Regarding the effect of delay on the suitability of a connection =0D
for speech communications, it is our understanding that, due to =0D
processing delay and the way in which frames are arranged, a one-=0D
way delay of approximately 100 ms occurs with G.723.1, whereas =0D
G.729A introduces about a third of this amount. A value of 100 ms =0D
exceeds by 100% the signal processing delay allocation guidelines =0D
of G.114, which SG 12 revised recently to draw attention to the =0D
negative quality impact of such large processing delays. Thus, =0D
while the incremental transmission delay caused by G.723.1 may not =0D
be problematic for regional point-to-point applications over =0D
terrestrial facilities, such incremental delays will have a serious =0D
negative impact if added to transoceanic connections over which =0D
multipoint applications are used. This problem is not avoided by =0D
merely saying that G.723.1 should be used for multimedia applications.=0D=

=0D
Study Group 12 emphasizes that echo control is also likely to be a =0D
major issue with Internet telephony, and Recommendation G.131=0D
provides guidance in this area.=0D
=0D
In conclusion, SG12 recognizes the urgency for new Recommendations =0D
on Internet telephony, given the market pressures on the deployment=0D
of such applications. Accordingly, SG 12 applauds SG16 for=0D
aggressively tackling standards work on this important topic.=0D
However, as per the guidance we have provided in this document,=0D
pertinent information already exists that can be used by the ITU=0D
to make codec selections so that user applications are supported=0D
with acceptable quality.=0D
=09=09=09=09*****************=0D



From rem-conf Mon Apr 28 14:09:36 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 14:09:35 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wKpZA-0005mD-00; Fri, 25 Apr 1997 11:17:52 -0700
Date: Fri, 25 Apr 1997 11:17:31 -0700
From: Mahesh Jethanandani <mahesh@cisco.com>
Message-Id: <199704251817.LAA00542@ruby.cisco.com>
To: rem-conf@es.net
Subject: Sources for wb
X-Sun-Charset: US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

I am looking for sources for wb to compile for Solaris x86. Any pointers
to sources or binaries would be helpful.

Thanks

Mahesh Jethanandani

|\/\/\/|                              |      mahesh@cisco.com
|  \  /|   LIFE'S COMPLEX - IT HAS    |      Cisco Systems Inc.
| (o)(o)   REAL & IMAGINARY PARTS     |      170 West Tasman Drive
C      _)                             |      San Jose, CA 95134
| \___|                               |	     (408) 527-8230
 |   /   All Std. Disclaimers apply.  |      (408) 527-8254(fax)




From rem-conf Mon Apr 28 14:09:37 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 14:09:37 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wKoNt-0005CX-00; Fri, 25 Apr 1997 10:02:09 -0700
X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed;
               Fri, 25 Apr 1997 19:02:35 +0200
X400-Received: by mta xn1-gw.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/;
               Relayed; Fri, 25 Apr 1997 19:02:35 +0200
X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Fri, 25 Apr 1997 18:35:34 +0200
X400-Received: by /PRMD=cnet/ADMD=atlas/C=FR/; Relayed;
               Fri, 25 Apr 1997 19:51:22 +0200
Date: Fri, 25 Apr 1997 19:51:22 +0200
X400-Originator: haignere@issy.cnet.fr
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/PRMD=cnet/ADMD=atlas/C=FR/;861979898@x400.issy.cnet.fr]
X400-Content-Type: P2-1984 (2)
Content-Identifier: g723 payloads
Alternate-Recipient: Allowed
From: Isabelle HAIGNERE <haignere@issy.cnet.fr>
Message-ID: <9704251451.AA01082@haddock>
To: rem-conf@es.net, casner@precept.com, isabelle.haignere@issy.cnet.fr
Subject: g723 payloads
Content-Length: 1088
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

*-------------------------------------------------------*
|       From :  Isabelle Haignere                       |
|               CNET - PAB/STC/SGV                      |
|               38-40 rue du General Leclerc            |
|               F-92 131 Issy les Moulineaux            |
|               FRANCE                                  |
|                                                       |
|               Tel.   : + 33 1 45 29 40 08             |
|               Fax.   : + 33 1 45 29 52 94             |
|                                                       |
|               E-mail : isabelle.haignere@issy.cnet.fr |
*-------------------------------------------------------*

Hello,

In the profile of RTP-RFC1890, the G723 payload has been defined and
moreover I have received the G723 RTP payload from Ken Mills from Intel
through the rem-conf mailing-list, what about the precise status of this
document and the G723 payload ? Is this version the last version of the
G723 rtp payload ?

I thank you very much for your response.

Best regards.


Isabelle HAIGNERE 



From rem-conf Mon Apr 28 14:09:38 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 14:09:38 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wKlv4-0004AO-00; Fri, 25 Apr 1997 07:24:14 -0700
From: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Message-Id: <970425102238.ZM10854@arrakis>
Date: Fri, 25 Apr 1997 10:22:37 -0700
X-Mailer: Z-Mail 4.0.1 (4.0.1 Apr 9 1996)
To: rem-conf@es.net
Subject: Reconsideration and the plateau effect
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


Henning and I have discussed the comments raised during the IETF meeting 
concerning the "plateau effect" in the RTCP timer reconsideration 
algorithm [for those that missed it, the plateau effect is a halt in 
transmission of RTCP reports following a brief period of congestion 
after a number of users simultaneously join an RTP multicast group]. It 
is our belief that this is simply not a problem, and that pursuing 
alternate algorithms at this late stage may lead to overly complex 
solutions, or, even worse, solutions whose behavior is not well 
understood.

The plateau effect is purely an artifact of the step join abstraction. 
As the join process becomes more sloped, or even jagged, both the height 
of the initial spike and the duration of this plateau (they are linearly 
related) disappear. As soon as the slope of the join reaches N divided 
by the network delays (N is the number who join), the spike and plateau 
are roughly halfed compared to a step join. In fact, our simulations 
have shown that when the join rate is around 500 users per second, the 
plateau is about 1 second in duration. As the slope decreases, the 
plateau decreases with it. (See our Columbia University Technical 
Report, "Scaling Feedback to Very Large Groups"; an I-D is coming soon 
with the same content).

We believe we have a good understanding of unconditional 
reconsideration; we have looked at fairness, synchronization, steady 
state behavior, etc. Our simulations and analysis have led us to believe 
that there will be no "surprises"; that the behavior seems stable and 
social. Certainly, alternate algorithms which avoid this plateau will be 
more complex, making it more likely that behavior may be even worse in 
some unexpected situations. More complex algorithms also lead to the 
possibility of incorrect implementations.

There is also the practical issue of time; given the speed with which we 
want to move to draft standard, the time required to develop, simulate, 
implement, and test new algorithms doesn't fit into the schedule.

So, given that we feel the plateau effect is not likely to show up in 
real systems, and that other algorithms which do not exhibit it are more 
complex and potentially antisocial, and our time constraints, we feel 
that unconditional reconsideration remains the best solution.

-- 
Jonathan Rosenberg			Lucent Technologies
Member of Technical Staff		Bell Laboratories
High Speed Networks Research		101 Crawfords Corner Rd.
PHONE: (908) 949-6418			Holmdel, NJ 07733
FAX:   (908) 834-5379			Rm. 4D-534B
EMAIL: jdrosen@bell-labs.com



From rem-conf Mon Apr 28 14:09:40 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 14:09:39 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wKTvJ-0000yw-00; Thu, 24 Apr 1997 12:11:17 -0700
Date: Thu, 24 Apr 1997 12:10:42 -0700
Message-Id: <199704241910.MAA24278@nobozo.CS.Berkeley.EDU>
X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU
X-Mailer: Windows Eudora Version 2.1.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: 298-list@bmrc.Berkeley.EDU, rem-conf@es.net
From: Jerrlyn Iwata <jerrlyn@postgres.Berkeley.EDU>
Subject: Berkeley Multimedia & Graphics seminar
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

                Berkeley Multimedia and Graphics Seminar 
        (Wednesday April 30, 1997 12:30-2:00 PDT 405 Soda Hall) 

               "Video Streaming: A View from the Trenches" 

                                Hank Magnuski 
                        Internet Video Services, Inc. 

This last year has witnessed an explosion of video streaming technologies
available on the Internet. Starting with the initial products by companies
such as VDO-Net and Xing, there has been a parade of new entrants including
Vivo,
Progressive Networks, WebTV, Iterated, Motorola, VXtreme, Vosaic, Microsoft,
Precept, Oracle and others.

Millions are being spent in a battle for ownership of the Internet's video
viewing audience.

This talk will take a close look at this marketplace and will review some of
the issues related to making these products ready for "prime time".
--------------------------------------------------------------------------------

This seminar will be broadcast on the Internet MBONE. The broadcast will
begin at 12:40 PDT (GMT - 8 hrs). See sdr or http://bmrc.berkeley.edu/298
for instructions on setting up, connecting to, and operating the MBONE tools.

Please direct all technical questions to davesimp@cs.berkeley.edu





From rem-conf Mon Apr 28 14:09:41 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 14:09:40 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wKmaT-0004Wu-00; Fri, 25 Apr 1997 08:07:01 -0700
Message-Id: <199704251506.RAA20152@ganymede.cdt.luth.se>
X-Mailer: exmh version 1.6.7 5/3/96
To: Amancio Hasty <hasty@rah.star-gate.com>
cc: rem-conf@es.net
Subject: Re: Video capture driver for Bt848 based cards
In-reply-to: Your message of "Thu, 24 Apr 1997 15:20:53 PDT." <199704242220.PAA03778@rah.star-gate.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Date: Fri, 25 Apr 1997 17:06:19 +0200
From: Hakan Lennestal <hakanl@cdt.luth.se>
Content-Transfer-Encoding: quoted-printable
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

In message <199704242220.PAA03778@rah.star-gate.com>, Amancio Hasty write=
s:
>=20
>=20
> Latest Bt848 driver available from :
> http://freebsd.org/~fsmp/HomeAuto/Bt848.html
> ftp://rah.star-gate.com/bt848-clip.tar.gz.=20
>=20
> The Bt848 driver has been incorporated to  FreeBSD 3.0-current.=20

Hi !

Do you know if there is any work going on to port this to Linux ?

Regards.

/H=E5kan




From rem-conf Mon Apr 28 14:09:42 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 14:09:42 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wKrMA-0006Wr-00; Fri, 25 Apr 1997 13:12:34 -0700
Date: Fri, 25 Apr 1997 13:12:23 -0700
Message-Id: <199704252012.NAA32318@nobozo.CS.Berkeley.EDU>
X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU
X-Mailer: Windows Eudora Version 2.1.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: 298-list@bmrc.Berkeley.EDU, rem-conf@es.net
From: Jerrlyn Iwata <jerrlyn@postgres.Berkeley.EDU>
Subject: Berkeley Multimedia & Graphics Seminar
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

                Berkeley Multimedia and Graphics Seminar 
        (Wednesday April 30, 1997 12:30-2:00 PDT 405 Soda Hall) 

               "Video Streaming: A View from the Trenches" 

                                Hank Magnuski 
                        Internet Video Services, Inc. 

This last year has witnessed an explosion of video streaming technologies
available on the Internet. Starting with the initial products by companies
such as VDO-Net and Xing, there has been a parade of new entrants including
Vivo,
Progressive Networks, WebTV, Iterated, Motorola, VXtreme, Vosaic, Microsoft,
Precept, Oracle and others.

Millions are being spent in a battle for ownership of the Internet's video
viewing audience.

This talk will take a close look at this marketplace and will review some of
the issues related to making these products ready for "prime time".
--------------------------------------------------------------------------------

This seminar will be broadcast on the Internet MBONE. The broadcast will
begin at 12:40 PDT (GMT - 8 hrs). See sdr or http://bmrc.berkeley.edu/298
for instructions on setting up, connecting to, and operating the MBONE tools.

Please direct all technical questions to davesimp@cs.berkeley.edu





From rem-conf Mon Apr 28 14:09:43 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 14:09:43 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wKugK-0007mK-00; Fri, 25 Apr 1997 16:45:36 -0700
Message-Id: <199704252345.QAA10466@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Hakan Lennestal <hakanl@cdt.luth.se>
cc: rem-conf@es.net
Subject: Re: Video capture driver for Bt848 based cards
In-reply-to: Your message of "Fri, 25 Apr 1997 17:06:19 +0200." <199704251506.RAA20152@ganymede.cdt.luth.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 25 Apr 1997 16:45:11 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by rah.star-gate.com id 
                      QAA10466
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Hi,

Not that I am aware of.

	Regards,
	Amancio

>From The Desk Of Hakan Lennestal :
> In message <199704242220.PAA03778@rah.star-gate.com>, Amancio Hasty wri=
tes:
> >=20
> >=20
> > Latest Bt848 driver available from :
> > http://freebsd.org/~fsmp/HomeAuto/Bt848.html
> > ftp://rah.star-gate.com/bt848-clip.tar.gz.=20
> >=20
> > The Bt848 driver has been incorporated to  FreeBSD 3.0-current.=20
>=20
> Hi !
>=20
> Do you know if there is any work going on to port this to Linux ?
>=20
> Regards.
>=20
> /H=E5kan
>=20





From rem-conf Mon Apr 28 14:09:45 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 14:09:45 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wKWsv-0001g1-00; Thu, 24 Apr 1997 15:21:01 -0700
Message-Id: <199704242220.PAA03778@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: rem-conf@es.net
Subject: Video capture driver for Bt848 based cards
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 24 Apr 1997 15:20:53 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list



Latest Bt848 driver available from :
http://freebsd.org/~fsmp/HomeAuto/Bt848.html
ftp://rah.star-gate.com/bt848-clip.tar.gz. 

The Bt848 driver has been incorporated to  FreeBSD 3.0-current. 

Tested boards are:
	  Hauppage's Wincast TV 
          The STB TV PCI Television Tuner 
          Miro PC TV in theory ONLY, never actually tried yet 
          Intel's Smart Video Recorder III 

The Bt848's dma controller is controlled by "Risc Instructions" which
can instruct the dma  controller to write to memory x number of bytes, skip
pixels, wait for a frame, jump to a location, etc... Additionally,
the Bt848 is a bus master device .

The latest driver  supports PAL, hardware clipping, and swapping the pixel
order RGB vs BGR. The last two features are useful when the Bt848 transfers
video directly to a video display's frame buffer. An alpha application
which demonstrates the PCI to PCI transfer is fxtv 
http://multiverse.com/~rhh/fxtv/. It does not support hardware clipping
nor pixel order swapping,yet.

vic's meteor driver module should work with the bt848 driver .
While vic is running  with xtvremote you can control the tuner .
By enlarge the Bt848 is fully compatible with the FreeBSD Matrox Meteor;however,
the Bt848's ioctl was augmented to exploit features found in the chipset
plus tuner support capability.

As to the quality of the video is pretty good . Side by side comparison
with my TV shows that the quality to be rather nice in fact with
some images my monitor looks better 8) You will need a good monitor
to approach TV quality. For instance, my Nano F550i is rather dull;however,
with my Sony Triton 15sx TV viewing is very nice. With apps such as fxtv
using the PCI to PCI transfer the driver supports 640x480 32bits at 
frames/sec . 


The driver is cleanly structured so it should not be too hard to port
to different OSes . For instance, I ported an earlier version of the
driver to win95 mostly because I needed to support a real time
stereoscopic application.

Last but not least , Bt848 based cards are cheap or dirt cheap. I have
read about a  WinCast TV,tuner + dbx stereo selling for $110.
Do a net search to locate a dealer near you ..

As it stands today, the Bt848 is now a group effort out of the 
FreeBSD multimedia group and I made sure that the appropiate individuals 
are credited with each commit to the driver.

	Enjoy,
	Amancio





From rem-conf Mon Apr 28 14:09:46 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 14:09:46 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wLbQV-0002jL-00; Sun, 27 Apr 1997 14:24:07 -0700
Message-Id: <s3637e9d.064@langate.tnet.state.tn.us>
X-Mailer: Novell GroupWise 4.1
Date: Sun, 27 Apr 1997 16:27:49 -0500
From: Eric Hauch <ehauch@mail.state.tn.us>
To: rem-conf@es.net
Cc: t1a15@t1.org
Subject: T1A1.5 Multimedia Performance Standards on the Internet
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

To Members of the IETF AVT WG,

This is a quick reminder of the upcoming meeting of T1A1.5
WG on Multimedia Performance and Coding (Boulder May
6-8/97).

Anyone who is able to attend can find the meeting specifics
at http://www.t1.org/t1a1/t1a1.htm.  I can deal with the IETF
liaison item (and the work of establishing multimedia client
performance requirements on the Internet) either May 6
(afternoon) or May 7.  If anyone has a time or date
preference, please let me know.

Thanks,

Eric G. Hauch
T1A1.5 Chair
ehauch@mail.state.tn.us
615-532-2365





From rem-conf Mon Apr 28 14:09:48 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 14:09:47 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wLf6l-0003yo-00; Sun, 27 Apr 1997 18:19:59 -0700
Message-ID: <33484B5B.3F7D@chollian.net>
Date: Mon, 07 Apr 1997 10:18:19 +0900
From: Roh Jeong-Hun <ohnohoya@chollian.net>
Organization: Seoul National University
X-Mailer: Mozilla 3.0Gold (Win95; I)
MIME-Version: 1.0
To: rem-conf@es.net
Subject: 'information about receivers' in RR of RTCP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

I have a question reading RFC1889 which is the spec of RTP. 
In the section of 6.3.3 Extending the sender and receiver reports,
it says 'If information about receivers is to be included,that 
data may be structured as an array of blocks parallel to the exist-
ing array of reception report blocks;that is,the number of blocks
would be indicated by the RC field.'
What's 'information about receivers'? What kind of information
would it be? 
What does an array of blocks parallel to the existing array of 
reception report blocks look like? Somebody could describe it
in detail? I tried to imagine the structure,but failed...


Thank you very much for reading these questions.



From rem-conf Mon Apr 28 14:09:49 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 14:09:49 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wLoUz-0000SY-00; Mon, 28 Apr 1997 04:21:37 -0700
From: Reinhard.Foerster@Inf.TU-Dresden.DE (Reinhard Foerster)
Message-Id: <199704281120.NAA10371@rnws02.urz.tu-dresden.de>
Subject: Re: Video capture driver for Bt848 based cards
In-Reply-To: <199704251506.RAA20152@ganymede.cdt.luth.se> from Hakan Lennestal at "Apr 25, 97 05:06:19 pm"
To: hakanl@cdt.luth.se (Hakan Lennestal)
Date: Mon, 28 Apr 1997 13:20:43 +0200 (MET DST)
Cc: rem-conf@es.net
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

> In message <199704242220.PAA03778@rah.star-gate.com>, Amancio Hasty write=
s:

A linux driver for bt848 based grabber cards you can find at

  http://www.thp.uni-koeln.de/~rjkm/

Reinhard

> > Latest Bt848 driver available from :
> > http://freebsd.org/~fsmp/HomeAuto/Bt848.html
> > ftp://rah.star-gate.com/bt848-clip.tar.gz.=20
> >=20
> > The Bt848 driver has been incorporated to  FreeBSD 3.0-current.=20
>=20
> Hi !
>=20
> Do you know if there is any work going on to port this to Linux ?
>=20
> Regards.
>=20
> /H=E5kan
>=20



From rem-conf Mon Apr 28 14:09:50 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 14:09:50 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wLovU-0001Xk-00; Mon, 28 Apr 1997 04:49:00 -0700
Message-Id: <199704281148.EAA00653@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Reinhard.Foerster@Inf.TU-Dresden.DE (Reinhard Foerster)
cc: hakanl@cdt.luth.se (Hakan Lennestal), rem-conf@es.net
Subject: Re: Video capture driver for Bt848 based cards
In-reply-to: Your message of "Mon, 28 Apr 1997 13:20:43 +0200." <199704281120.NAA10371@rnws02.urz.tu-dresden.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 28 Apr 1997 04:48:03 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

The FreeBSD is mostly compatible with the FreeBSD Matrox Meteor Driver which
means that tools like vic don't need to be modified. In the case of FreeBSD 
all what needs to be done is to symlink /dev/meteor0 to /dev/bktr0. 
Makes life a little easier from an  application support perspective.

Also, minor point is that the  FreeBSD driver does not require the programmer
to be familiar with the Bt848 Risc instruction set. In the case of the
Linux driver the last time I look at it, the  program has to build the
Risc program to pass it on the the driver which is no big deal if 
a relevant library is provided with the driver.

The  video capture process in the Bt848 is controlled by a Risc Program
which resides in the host memory. Instructions consist of 
write X number of pixels, skip pixels , wait for a frame, etc...

	Cheers,
	Amancio
>From The Desk Of Reinhard Foerster :
> > In message <199704242220.PAA03778@rah.star-gate.com>, Amancio Hasty write=
> s:
> 
> A linux driver for bt848 based grabber cards you can find at

	




From rem-conf Mon Apr 28 14:09:51 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 14:09:51 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wLpdC-00028y-00; Mon, 28 Apr 1997 05:34:10 -0700
Sender: hgs@cs.columbia.edu
Message-ID: <33649930.5E58@cs.columbia.edu>
Date: Mon, 28 Apr 1997 08:33:52 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Amancio Hasty <hasty@rah.star-gate.com>
CC: rem-conf@es.net, voip-tech@vocaltec.com
Subject: Re: Re. Internet telephony performance
References: <199704281121.EAA00364@rah.star-gate.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Given the currently specified costs for G.729 and G.723 licenses, their
implementation in freely available non-commercial software seems
unlikely:

- G.723.1: $100k for DSP implementation, including licenses (97-20.doc)
- G.729A and G.729: $220k (VIP97032.doc) or $1.40 per unit, $40k
initial, $10k minimum per year

This is somewhat simplified, but shows, I think, the magnitude of the
problem.

It was pointed out that the GSM codec is also subject to IPR and
licenses (by Phillips), but obviously, there has been no attempt to
enforce this for the free tools.
-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs



From rem-conf Mon Apr 28 15:16:02 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 15:16:00 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wLyGb-0006pA-00; Mon, 28 Apr 1997 14:47:25 -0700
To: IETF-Announce:;
cc: rem-conf@es.net
From: The IESG <iesg-secretary@ietf.org>
Subject: Last Call: RTP Payload Format for H.263 Video Streams to Proposed 
         Standard
Reply-to: iesg@ietf.org
Date: Mon, 28 Apr 1997 17:45:40 -0400
Sender: scoya@ietf.org
Message-ID: <9704281745.aa29707@ietf.org>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


 The IESG has received a request from the Audio/Video Transport Working
 Group to consider the following Internet-Drafts "for the status of Proposed
 Standard.

 1. RTP Payload Format for H.263 Video Streams
	<draft-ietf-avt-rtp-payload-03.txt>

 2. RTP Payload for Redundant Audio Data
	<draft-perkins-rtp-redundancy-03.txt>


 The IESG plans to make a decision in the next few weeks, and solicits
 final comments on this action.  Please send any comments to the
 iesg@ietf.org or ietf@ietf.org mailing lists by May 12, 1997


Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>




From rem-conf Mon Apr 28 16:16:40 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 16:16:40 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wLzUt-0007Og-00; Mon, 28 Apr 1997 16:06:15 -0700
Message-Id: <199704282305.QAA00652@rah.star-gate.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: iesg@ietf.org
cc: rem-conf@es.net
Subject: Re: Last Call: RTP Payload Format for H.263 Video Streams to Proposed 
         Standard
In-reply-to: Your message of "Mon, 28 Apr 1997 17:45:40 EDT." <9704281745.aa29707@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 28 Apr 1997 16:05:48 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


Is there a working model of the proposed H.263 Payload?

If not I then I think is a bit premature to elevate it to Standard Status

	Tnks,
	Amancio
	





From rem-conf Mon Apr 28 19:46:58 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 19:46:55 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wM2sR-0000fN-00; Mon, 28 Apr 1997 19:42:47 -0700
Date: Mon, 28 Apr 1997 19:31:26 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Amancio Hasty <hasty@rah.star-gate.com>
cc: iesg@ietf.org, rem-conf@es.net
Subject: Re: Last Call: RTP Payload Format for H.263 Video Streams to Proposed 
         Standard
In-Reply-To: <199704282305.QAA00652@rah.star-gate.com>
Message-ID: <Pine.WNT.3.95.970428192737.-131667T-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

On Mon, 28 Apr 1997, Amancio Hasty wrote:

> Is there a working model of the proposed H.263 Payload?
> If not I then I think is a bit premature to elevate it to Standard Status

Chad Zhu reported that an interop test had been done with 3 or 4
implementations.

The draft is being Last Called for Proposed Standard, not Standard.
No implementations are required for Proposed.  Multiple independent
implementations are required to advance to the second step, Draft
Standard.
							-- Steve




From rem-conf Mon Apr 28 20:14:22 1997 
From rem-conf-request@tmpmail.es.net Mon Apr 28 20:14:21 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wM3LE-00011v-00; Mon, 28 Apr 1997 20:12:32 -0700
Date: Mon, 28 Apr 1997 19:52:41 -0700 ()
From: Stephen Casner <casner@precept.com>
To: Roh Jeong-Hun <ohnohoya@chollian.net>
cc: rem-conf@es.net
Subject: Re: several questions about RTP
In-Reply-To: <33484B02.7833@chollian.net>
Message-ID: <Pine.WNT.3.95.970428193327.-131667U-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

On Mon, 7 Apr 1997, Roh Jeong-Hun wrote:

[Why are these messages just showing up now?]

> I don't get the reason why we don't distinguish late or dupliacated
> packets from well received packets. 

Because the only way to do that perfectly is to keep track of all
packets that have been received.  This may not be feasible.

> In the section of 6.3.3 Extending the sender and receiver reports,
> it says 'If information about receivers is to be included,that 
> data may be structured as an array of blocks parallel to the exist-
> ing array of reception report blocks;that is,the number of blocks
> would be indicated by the RC field.'
> What's 'information about receivers'? What kind of information
> would it be? 

That is not known at this point.  The extension would be defined by
someone who has identified some extra information that needs to be
sent.

> What does an array of blocks parallel to the existing array of 
> reception report blocks look like? Somebody could describe it
> in detail? I tried to imagine the structure,but failed...

The structure of the already defined part of the reception report
would not change.  The one-dimensional array of blocks is just a
sequence of data structures (32-bit aligned).  There is one such data
structure for each receiver for which a reception report block is
included, i.e., the number indicated by the RC field.  (That's what
was meant by "parallel").

> In RFC1889-page 40-, it says 'translator forwards RTP packets with
> their SSRC identifier intact;this makes it possible for receivers
> to identify individual sources even though packets from all the
> sources pass through the same translator and carry the translator's
> network source address'.
> Why does it carry 'its network source address'?

Because the translator is an application-level forwarder, not a
network-level router, it can't set the network source address.  The
translators own address is applied by the networking software.  A
translator may be chosen instead of a router precisely because the
network addresses on one side may not be valid on the other, so it
doesn't make sense to pass them through.  An example is going from a
network with unregistered (non-unique) IP addresses to the globally
routed Internet where IP addresses must be unique.

> I guess it may cause looping problems..

Yes, loops can occur when translators or mixers are used.  That's why
the RTP spec gives guidelines for their construction and use.  It is
also why RTP has an SSRC loop and collision detection algorithm.  Read
sections 7 and 8 of RFC 1889 carefully.
							-- Steve




From rem-conf Tue Apr 29 00:27:15 1997 
From rem-conf-request@tmpmail.es.net Tue Apr 29 00:27:15 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wM7CI-0002CF-00; Tue, 29 Apr 1997 00:19:34 -0700
Message-ID: <3365A0DE.4111@cnam.fr>
Date: Tue, 29 Apr 1997 09:18:54 +0200
From: Michel BOURDONCLE <Michel.Bourdoncle@cnam.fr>
Organization: Cnam
X-Mailer: Mozilla 3.0Gold (Win95; I)
MIME-Version: 1.0
To: Rem-conf@es.net
Subject: mbone
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by fermi.cnam.fr id JAA12043
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

--Je cherche a faire de visioconf via internet sur pc Win95, j'ai le
tunnel  des experiences similaires avec resultats m'interesse.
Merci=20
Bourdoncle Michel
Conservatoire national des arts et m=E9tiers
Service EAD
292 rue Saint-Martin
74141 Paris Cedex 03
E.mail Bourdonc@cnam.fr
tel : 01 40 27 20 78
fax : 01 40 27 25 01



From rem-conf Tue Apr 29 01:13:54 1997 
From rem-conf-request@tmpmail.es.net Tue Apr 29 01:13:53 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wM7yA-0002cX-00; Tue, 29 Apr 1997 01:09:02 -0700
To: Michel BOURDONCLE <Michel.Bourdoncle@cnam.fr>
cc: Rem-conf@es.net
Subject: Re: mbone
In-reply-to: Your message of "Tue, 29 Apr 1997 09:18:54 +0200." <3365A0DE.4111@cnam.fr>
Date: Tue, 29 Apr 1997 09:08:13 +0100
Message-ID: <1173.862301293@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list



 >--Je cherche a faire de visioconf via internet sur pc Win95, j'ai le
 >tunnel  des experiences similaires avec resultats m'interesse.

 Michel

je crois que vous povez trouver quelque chose interessant a l'URL
http://www.cs.ucl.ac.uk/staff/i.kouvelas/vic/
par example....

des autres possibilities:
http://131.107.1.182:80/research/BARC/JGemmell/
en particulier, 
http://131.107.1.182:80/research/BARC/mbone/

il y a des gens a INRIA a sophia antipolus qui peux vous aider mieux
que moi (et ils parles francais moins comme une vache espagnol....:-)

a bientot......

 jon




From rem-conf Tue Apr 29 01:49:07 1997 
From rem-conf-request@tmpmail.es.net Tue Apr 29 01:49:06 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wM8Xl-00030O-00; Tue, 29 Apr 1997 01:45:49 -0700
Message-Id: <199704290844.KAA27547@bordeaux.nijenrode.nl>
X-Mailer: exmh version 1.6.5 12/11/95
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
cc: Michel BOURDONCLE <Michel.Bourdoncle@cnam.fr>, Rem-conf@es.net
Subject: Re: mbone
In-reply-to: Your message of "Tue, 29 Apr 1997 09:08:13 BST." <1173.862301293@cs.ucl.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 29 Apr 1997 10:44:06 +0200
From: Michel <michel@nijenrode.nl>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

There must be something wrong with my universal translator here...
*thump thump* is this on ?


-- 
 Michel van der Laan	-	michel@nijenrode.nl
				http://www.nijenrode.nl/~michel
In your mail from 29-4-1997 you write:
> 
> 
>  >--Je cherche a faire de visioconf via internet sur pc Win95, j'ai le
>  >tunnel  des experiences similaires avec resultats m'interesse.
> 
>  Michel
> 
> je crois que vous povez trouver quelque chose interessant a l'URL
> http://www.cs.ucl.ac.uk/staff/i.kouvelas/vic/
> par example....
> 
> des autres possibilities:
> http://131.107.1.182:80/research/BARC/JGemmell/
> en particulier, 
> http://131.107.1.182:80/research/BARC/mbone/
> 
> il y a des gens a INRIA a sophia antipolus qui peux vous aider mieux
> que moi (et ils parles francais moins comme une vache espagnol....:-)
> 
> a bientot......
> 
>  jon
> 




From rem-conf Tue Apr 29 02:07:32 1997 
From rem-conf-request@tmpmail.es.net Tue Apr 29 02:07:31 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wM8lS-0003Ht-00; Tue, 29 Apr 1997 01:59:58 -0700
Date: Tue, 29 Apr 1997 01:58:18 -0700 (PDT)
Message-Id: <1.5.4.16.19970429014019.55c7aff0@pop.best.com>
X-Sender: rsf@pop.best.com
X-Mailer: Windows Eudora Light Version 1.5.4 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: rem-conf@es.net
From: Ross Finlayson <finlayson@lvn.com>
Subject: Multicast coverage of the Kasparov-Deep Blue rematch?
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

I've heard that people at IBM Research have been planning (or at least
considering) using the MBone in some way to convey the progress of the
upcoming Kasparov-Deep Blue chess matches (in addition to the regular WWW
coverage on www.chess.ibm.com).  Is this true?  If so, I (& I'm sure many
others on this list) would be interested in learning more about this.

Last time around, it was almost impossible to follow the games on the web -
the web site was extremely overloaded.  Multicast would be a much more
efficient way to disseminate the progress of the matches.

        Ross.




From rem-conf Tue Apr 29 05:42:32 1997 
From rem-conf-request@tmpmail.es.net Tue Apr 29 05:42:31 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wMC6x-0004WP-00; Tue, 29 Apr 1997 05:34:23 -0700
Date: Tue, 29 Apr 1997 14:34:18 +0200 (MST)
From: Andrey Bobyshev <bobyshev@x4u2.desy.de>
To: rem-conf@es.net
Subject: CHEP97 netcast
Message-ID: <Pine.SGI.3.91.970429143209.363B-100000@x4u2>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list



Hello,

 The first files with MBONE of CHEP97 are become 
available. Please take a look the URL 
http://mbone.desy.de/MBone/chep97_mbone.html .
This archive are making (as it's not completed yet)
>from original VHS tapes of CHEP97. For those who are 
not informated, we could not make on-line MBONE trasmissions, because 
in the new localtion the CHEP97 had to move a network bandwidth was very 
limited. The files from this archive can be downloaded and playback by wrtp 
tool locally. If there are any problems to do it locally, please send us a 
message to mbone@desy.de and we will arrange a time to playback it into MBONE from 
DESY. As a coping of the archive may take a lot of computer power and
network bandwidth, anonymous access is enabled and the real downloading 
is available since 5:00 p.m. till 9:00 a.m. MET.


			Regards,
				Andrey Bobyshev,
				ZDV, DESY.




From rem-conf Tue Apr 29 10:22:10 1997 
From rem-conf-request@tmpmail.es.net Tue Apr 29 10:22:09 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wMGMF-0005xg-00; Tue, 29 Apr 1997 10:06:27 -0700
From: Dave Wright <dave@msri.org>
Message-Id: <199704291706.KAA11131@msri.org>
X-Authentication-Warning: msri.org: smap set sender to <dave> using -f
Subject: Van Jacobson "Pathchar"
To: rem-conf@es.net
Date: Tue, 29 Apr 1997 10:05:42 -0700 (PDT)
Content-Type: text
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

rebroadcast reminder

Title:
Van Jacobson "Pathchar - How to infer the characteristics of Internet paths" 


Time:
12:00 PST8PDT


URL:
http://www.msri.org/sched/empennage/jacobson.html


audio PCM  224.2.233.22/30794 ttl 127
video H261 224.2.184.79/64852 ttl 127 



	Mbone Broadcast Schedule http://www.msri.org/mbone

 ________  o      Dave Wright 
 _______ _/\_>    dave@msri.org
 _______O=>// O   91CBR600F2 AFM# 316
 --------------   Mathematical Sciences Research Institute




From rem-conf Tue Apr 29 11:50:52 1997 
From rem-conf-request@tmpmail.es.net Tue Apr 29 11:50:52 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wMHtF-0006aY-00; Tue, 29 Apr 1997 11:44:37 -0700
Message-Id: <9704291843.AA16212@sdi.sharpwa.com>
From: savoj@sdismtp.sharpwa.com (savoj)
Date: Tue, 29 Apr 1997 11:22 PST
To: rem-conf@es.net
Subject: RTP/RTCP library
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

To whom it may concern:
I am new with RTP/RTCP concept.  I understand that development of these 
protocols is very much application dependent.  However, is there any source 
code available that I can look at to get a better sense of these concepts.

Regards,
Marzieh Savoj
savoj@sdismtp.sharpwa.com




From rem-conf Tue Apr 29 13:11:21 1997 
From rem-conf-request@tmpmail.es.net Tue Apr 29 13:11:20 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wMJ9M-00078I-00; Tue, 29 Apr 1997 13:05:20 -0700
Sender: hgs@cs.columbia.edu
Message-ID: <3366547B.5ED6@cs.columbia.edu>
Date: Tue, 29 Apr 1997 16:05:15 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: savoj <savoj@sdismtp.sharpwa.com>
CC: rem-conf@es.net
Subject: Re: RTP/RTCP library
References: <9704291843.AA16212@sdi.sharpwa.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

savoj wrote:
> 
> To whom it may concern:
> I am new with RTP/RTCP concept.  I understand that development of these
> protocols is very much application dependent.  However, is there any source
> code available that I can look at to get a better sense of these concepts.

The RTP web page at http://www.cs.columbia.edu/~hgs/rtp contains
pointers to applications using RTP and their availability (source,
binary, etc.). Some of these applications are available as source (vat,
vic, nevot, rtpdump and kin, among others). You have probably already
noticed that the RTP spec contains source code as well...

> 
> Regards,
> Marzieh Savoj
> savoj@sdismtp.sharpwa.com



From rem-conf Tue Apr 29 15:42:51 1997 
From rem-conf-request@tmpmail.es.net Tue Apr 29 15:42:51 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wMLUt-0000Wt-00; Tue, 29 Apr 1997 15:35:43 -0700
Date: Tue, 29 Apr 1997 15:35:03 -0700 (PDT)
From: Stephane Chatre <chatre@ENGR.ORST.EDU>
Reply-To: Stephane Chatre <chatre@ENGR.ORST.EDU>
To: rem-conf@es.net
Subject: record with sdr
Message-ID: <Pine.SOL.3.95.970429150702.9601a-100000@eel.ENGR.ORST.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Hi!
In order to use the command "record now" from sdr, one has to write a
"record_session" script, that will be called by sdr with the proper
arguments.

Now, for the "record when session starts" option, does anyone know which
script sdr is looking for ? (i.e. the name of the script).

Thanks,
Stephane. 
========================
Stephane Chatre                   Email: chatre@cs.orst.edu          
Department of Computer Science    Phone: (541) 737-5583  (office)     
Oregon State University			 (541) 757-3376   (home)      
                            
Life is what happens to you while you're busy making other plans.
                                        - John Lennon            






From rem-conf Tue Apr 29 16:25:19 1997 
From rem-conf-request@tmpmail.es.net Tue Apr 29 16:25:19 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wMMCk-0000vD-00; Tue, 29 Apr 1997 16:21:02 -0700
Date: Wed, 30 Apr 1997 01:20:52 +0200
Message-Id: <199704292320.BAA03021@minerva.link.no>
From: Petter Reinholdtsen <pere@td.org.uit.no>
To: rem-conf@es.net
Subject: Re: record with sdr
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


[Stephane Chatre]
> Now, for the "record when session starts" option, does anyone know
> which script sdr is looking for ? (i.e. the name of the script).

It is looking for a script called 'record_session' (Suprise :-), and
it could look like this:
==================== recort_session =====================
#!/store/bin/perl
#
# record_session
#
# An interface between sdr and the MBone VCR.
# sdr launches this script with an SDP session description as input.
# This script creates an MBone VCR .vcr file out of the session description,
# and creates a .cmd file that starts recording immediately, and starts
# the MBone VCR with the .cmd file on the command line.
#
# Bill Fenner <fenner@parc.xerox.com> 22 Apr 1996
#
#
# Set the next line to the MBone VCR executable location
$vcr = "mbone_vcr";

# You should not need to change anything below this line.
require 'ctime.pl';

$ver = "0.9";

$fn = $ARGV[0];
$fn =~ s/\.vcr$//;

$vcrfn = $fn . ".vcr";
$cmdfn = $fn . ".cmd";

open(VCR,">$vcrfn") || die "$vcrfn: $!\n";
print VCR "<MBONE_VCR 1.0>\n";
print VCR "# This file was generated by record_session v$ver\n";
print VCR "session_date=", &ctime(time);
$medianum = 1;

# I don't know if MBone VCR requires any particular ordering of its file.
# Given the SDP fields in the order that sdr outputs them, this loop should
# create the .vcr file in the same order as MBone VCR does.

while (<STDIN>) {
        chop;
        ($key,$data) = split(/=/,$_,2);
        if ($key eq "s") {
                print VCR "session_name=$data\n";
        } elsif ($key eq "i") {
                print VCR "session_desc=$data\n";
        } elsif ($key eq "c") {
                if ($medianame) {
                        ($mediaip,$mediattl) = ($data =~ m|([0-9.]+)/(\d+)$|);
                } else {
                        ($ip,$ttl) = ($data =~ m|([0-9.]+)/(\d+)$|);
                        if ($ttl) {
                                print VCR "session_max_ttl=$ttl\n";
                        } else {
                                print VCR "session_max_ttl=0\n";        # XXX
                        }
                }
        } elsif ($key eq "m") {
                if ($medianame) {
                        print VCR "${medianum}=media_port=$mediaport\n";
                        print VCR "${medianum}=media_ip=$mediaip\n";
                        print VCR "${medianum}=media_name=$medianame\n";
                        print VCR "${medianum}=media_type=$mediatype\n";
                        print VCR "${medianum}=media_mute=0\n";
                        print VCR "${medianum}=media_desc=$medianame\n";
                        print VCR "${medianum}=media_cmd=$mediacmd\n";
                        print VCR "${medianum}=media_cid=$mediacid\n";
                        print VCR "${medianum}=media_ttl=$mediattl\n";
                        $medianum++;
                        undef $medianame;
                }
                ($medianame, $mediaport, $type, $fmt) = split(/\s+/, $data);
                $mediacid = 0;
                undef $mediatype;
                undef $mediacmd;
                undef $mediattl;
                $mediaip = $ip;
                if ($type eq "vat") {
                        $mediatype = 2;
                } elsif ($type =~ /^rtp$/io || $type =~ m|^rtp/avp$|io ) {
                        $mediatype = 1;
                } else {
                        print STDERR "Warning: don't know about media type $type
 so ";
                        print STDERR "can't record $medianame media...\n";
                        undef $medianame;
                        next;
                }
                if ($medianame eq "audio") {
                        $mediacmd = "vat";
                } elsif ($medianame eq "video") {
                        $mediacmd = "vic";
                } else {
                        $mediacmd = "unknown";
                }
        } elsif ($key eq "a") {
                if ($medianame && $data =~ /id:(\d+)/) {
                        $mediacid = $1;
                }
        }
}
if ($medianame) {
        print VCR "${medianum}=media_port=$mediaport\n";
        print VCR "${medianum}=media_ip=$mediaip\n";
        print VCR "${medianum}=media_name=$medianame\n";
        print VCR "${medianum}=media_type=$mediatype\n";
        print VCR "${medianum}=media_mute=0\n";
        print VCR "${medianum}=media_desc=$medianame\n";
        print VCR "${medianum}=media_cmd=$mediacmd\n";
        print VCR "${medianum}=media_cid=$mediacid\n";
        print VCR "${medianum}=media_ttl=$mediattl\n";
}
close(VCR);

open(CMD,">$cmdfn") || die "$cmdfn: $!\n";
print CMD "# Load the session description file\n";
print CMD "load $vcrfn\n";
print CMD "# Just in case we're being asked to add to an existing file\n";
print CMD "goto end\n";
print CMD "# Allow recording\n";
print CMD "rec_enabled on\n";
print CMD "# and start recording immediately!\n";
print CMD "rec\n";
close(CMD);

exec "$vcr -c $cmdfn &";
=========================================================
-- 
##>  Petter Reinholdtsen  <##  |  pere@td.org.uit.no



From rem-conf Tue Apr 29 16:25:20 1997 
From rem-conf-request@tmpmail.es.net Tue Apr 29 16:25:19 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wMMBT-0000uw-00; Tue, 29 Apr 1997 16:19:43 -0700
From: Mark Handley <mjh@isi.edu>
X-Organisation: Information Sciences Institute, USC
X-Phone: +1 617 253 6011
To: Stephane Chatre <chatre@ENGR.ORST.EDU>
cc: rem-conf@es.net
Subject: Re: record with sdr
In-reply-to: Your message of "Tue, 29 Apr 1997 15:35:03 PDT." <Pine.SOL.3.95.970429150702.9601a-100000@eel.ENGR.ORST.EDU>
Date: Tue, 29 Apr 1997 19:17:18 -0400
Message-ID: <13662.862355838@buttle.lcs.mit.edu>
Sender: mjh@buttle.lcs.mit.edu
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list


>Hi!
>In order to use the command "record now" from sdr, one has to write a
>"record_session" script, that will be called by sdr with the proper
>arguments.
>
>Now, for the "record when session starts" option, does anyone know which
>script sdr is looking for ? (i.e. the name of the script).

The feature is not implemented in current versions of sdr, because the
recording functionality was added primarily for a server at UCL which
wasn't finished by the time I left.

I can easily add the functionality - there are two simple options - to
run "record_session" at the correct time, or to run "record_session"
immediately and pass it the time at which to start recording.

The former requires no modification to the record_session script, but
you'd only find out if the script had a problem when it's too late and
you'd need to leave sdr running.  The latter requires someone to write
an appropriate script.  Any preferences?

Mark



From rem-conf Tue Apr 29 16:34:30 1997 
From rem-conf-request@tmpmail.es.net Tue Apr 29 16:34:30 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wMMPJ-0001S4-00; Tue, 29 Apr 1997 16:34:01 -0700
Date: Tue, 29 Apr 1997 16:33:28 -0700 (PDT)
From: Stephane Chatre <chatre@ENGR.ORST.EDU>
To: Petter Reinholdtsen <pere@td.org.uit.no>
cc: rem-conf@es.net
Subject: Re: record with sdr
In-Reply-To: <199704292320.BAA03021@minerva.link.no>
Message-ID: <Pine.SOL.3.95.970429162933.9601k-100000@eel.ENGR.ORST.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

On Wed, 30 Apr 1997, Petter Reinholdtsen wrote:

> 
> [Stephane Chatre]
> > Now, for the "record when session starts" option, does anyone know
> > which script sdr is looking for ? (i.e. the name of the script).
> 
> It is looking for a script called 'record_session' (Suprise :-), and
> it could look like this:
...

What I am talking about is the ability of sdr to record when the session
actually gets started. 

It seems, acording to Mark Handley's answer that the record_session
script, as for now, is only called when the command "start recording" is
issued.

Stephane.
 ========================
Stephane Chatre                   Email: chatre@cs.orst.edu          
Department of Computer Science    Phone: (541) 737-5583  (office)     
Oregon State University			 (541) 757-3376   (home)      
                            
Life is what happens to you while you're busy making other plans.
                                        - John Lennon            




From rem-conf Tue Apr 29 16:48:37 1997 
From rem-conf-request@tmpmail.es.net Tue Apr 29 16:48:37 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wMMab-0001ia-00; Tue, 29 Apr 1997 16:45:41 -0700
Date: Tue, 29 Apr 1997 16:44:28 -0700 (PDT)
From: Stephane Chatre <chatre@ENGR.ORST.EDU>
Reply-To: Stephane Chatre <chatre@ENGR.ORST.EDU>
To: Mark Handley <mjh@isi.edu>
cc: rem-conf@es.net
Subject: Re: record with sdr
In-Reply-To: <13662.862355838@buttle.lcs.mit.edu>
Message-ID: <Pine.SOL.3.95.970429163340.9601l-100000@eel.ENGR.ORST.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

On Tue, 29 Apr 1997, Mark Handley wrote:

> 
> The feature is not implemented in current versions of sdr, because the
> recording functionality was added primarily for a server at UCL which
> wasn't finished by the time I left.

OK. Thanks for making it clear!

> I can easily add the functionality - there are two simple options - to
> run "record_session" at the correct time, or to run "record_session"
> immediately and pass it the time at which to start recording.

I would prefer the second solution for the reason you mentionned and also
because the script can be modified for example to launch a "deamon" that
would effectively start recording when the first packets arrive. In this
case the time can be ignored. The deamon can also be scheduled to start
let's say 10 min in advance and then only wait for the first pakets, to
keep group membership low.

Thanks !
Stephane
 ========================
Stephane Chatre                   Email: chatre@cs.orst.edu          
Department of Computer Science    Phone: (541) 737-5583  (office)     
Oregon State University			 (541) 757-3376   (home)      
                            
Life is what happens to you while you're busy making other plans.
                                        - John Lennon            







From rem-conf Wed Apr 30 02:16:38 1997 
From rem-conf-request@tmpmail.es.net Wed Apr 30 02:16:38 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wMVOK-0004S7-00; Wed, 30 Apr 1997 02:09:36 -0700
Message-Id: <199704300901.SAA03905@cosmos.kaist.ac.kr>
From: Kyungran Kang <krkang@cosmos.kaist.ac.kr>
To: mbone <mbone@isi.edu>, rem-conf <rem-conf@es.net>
Subject: the highest quality audio in mbone
Date: Wed, 30 Apr 1997 18:05:08 +0900
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-2022-kr
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Hello everyone!!

I'd like to know what is the highest quality audio in mbone.
In case of vat, I think pcm shows the best quality.

Have you ever tested any other format such as mpeg audio 
in mbone?

We tried to add mpeg audio support on vat but it seems to need
a lot of additional works. Have you ever tried? Did you make it?

Thanks for your reply in advance.

Kyungran Kang




From rem-conf Wed Apr 30 03:07:36 1997 
From rem-conf-request@tmpmail.es.net Wed Apr 30 03:07:35 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wMWEh-0004oI-00; Wed, 30 Apr 1997 03:03:43 -0700
Date: Wed, 30 Apr 1997 13:00:57 +0300 (EEST)
Message-Id: <199704301000.NAA05731@silver.sms.fi>
From: Petri Helenius <pete@sms.fi>
To: Kyungran Kang <krkang@cosmos.kaist.ac.kr>
Cc: mbone <mbone@isi.edu>, rem-conf <rem-conf@es.net>
Subject: the highest quality audio in mbone
In-Reply-To: <199704300901.SAA03905@cosmos.kaist.ac.kr>
References: <199704300901.SAA03905@cosmos.kaist.ac.kr>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Kyungran Kang writes:
 > Hello everyone!!
 > 
 > I'd like to know what is the highest quality audio in mbone.
 > In case of vat, I think pcm shows the best quality.
 > 
 > Have you ever tested any other format such as mpeg audio 
 > in mbone?
 > 
 > We tried to add mpeg audio support on vat but it seems to need
 > a lot of additional works. Have you ever tried? Did you make it?
 > 
The MBone itself does not include a limitation for audio quality but
I haven't yet seen an application that would support beyond two
channel MPEG audio.

Pete



From rem-conf Wed Apr 30 05:20:05 1997 
From rem-conf-request@tmpmail.es.net Wed Apr 30 05:20:05 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wMYJq-0005GR-00; Wed, 30 Apr 1997 05:17:10 -0700
Sender: hgs@cs.columbia.edu
Message-ID: <33673770.208F@cs.columbia.edu>
Date: Wed, 30 Apr 1997 08:13:36 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: voip-tech@vocaltec.com, rem-conf@es.net
Subject: G.723.1 and G.729 licensing
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

A few people have pointed out that, basically, G.723.1 and G.729 have
similar licensing costs (see sample explanation from Fred Burg, below).
However, whether it's a 100k or 220k (or a total of $450k for both
codecs), this puts it way out of reach of most any academic research
organization that wants to distribute their applications for free.

Fred Burg writes:

Although I don't have the documents here, to get G.723.1 requires 2
things:
 - the $100K gets you licenses from 4 of the 8 IPR holders;
 - to get licenses from the other 4, you can:
    - negotiate separately with each of them (not sure of who they all
are
      but includes ATT and Lucent); or
    - you can buy software from Lucent for $120K and they will also
      indemnify you against any claims brought by the other 3 of this
      group
   this was stated in a separate paper presented at the VOIP meeting.
   So with this path, you also need to spend $220K.

Feel free to send this email to whomever you think appropriate.


Fred Burg  fred.burg@att.com  908-576-4322  FAX:908-576-4317
-- 
Henning Schulzrinne         email: schulzrinne@cs.columbia.edu
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs



From rem-conf Wed Apr 30 07:59:40 1997 
From rem-conf-request@tmpmail.es.net Wed Apr 30 07:59:39 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wMajC-0005my-00; Wed, 30 Apr 1997 07:51:30 -0700
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce@ietf.org
cc: rem-conf@es.net
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-avt-mpeg-new-00.txt
Date: Wed, 30 Apr 1997 10:19:54 -0400
Sender: cclark@ietf.org
Message-ID: <9704301019.aa11809@ietf.org>
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

--NextPart

 A New Internet-Draft is available from the on-line Internet-Drafts 
 directories. This draft is a work item of the Audio/Video Transport 
 Working Group of the IETF.                                                

       Title     : RTP Payload Format for MPEG1/MPEG2 Video                
       Author(s) : D. Hoffman, G. Fernando, V. Goyal, R. Civanlar
       Filename  : draft-ietf-avt-mpeg-new-00.txt
       Pages     : 15
       Date      : 04/29/1997

This memo describes a packetization scheme for MPEG video and audio 
streams.  The scheme proposed can be used to transport such a video or 
audio flow over the transport protocols supported by RTP.  Two approaches 
are described. The first is designed to support maximum interoperability 
with MPEG System environments.  The second is designed to provide maximum 
compatibility with other RTP-encapsulated media streams and future 
conference control work of the IETF.     
                                  
This memo is a revision of RFC 2038, an Internet standards track protocol, 
prepared for publication as a revised RFC.  In this revision, the packet 
loss resiliance mechanisms in Section 3.4 were extended to include 
additional picture header information required for MPEG2.                  

Internet-Drafts are 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-avt-mpeg-new-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-avt-mpeg-new-00.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  ftp.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  mailserv@ds.internic.net. In the body type: 
     "FILE /internet-drafts/draft-ietf-avt-mpeg-new-00.txt".
							
NOTE: The mail server at ds.internic.net 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@ds.internic.net"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-avt-mpeg-new-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-avt-mpeg-new-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

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

--OtherAccess--

--NextPart--



From rem-conf Wed Apr 30 09:14:23 1997 
From rem-conf-request@tmpmail.es.net Wed Apr 30 09:14:23 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wMbsa-0006DB-00; Wed, 30 Apr 1997 09:05:16 -0700
Message-ID: <26F5763901560C00@mail.madge.com>
In-Reply-To: <22F5763901560C00@mail.madge.com>
Date: Wed, 30 Apr 1997 16:12:36 +0100
From: Andrew Chittenden WAVE-SP <achitten@madge.com>
Sender: Andrew Chittenden WAVE-SP <achitten@madge.com>
Organization: Madge Networks
To: rem-conf@es.net, voip-tech@vocaltec.com, 
    schulzrinne@cs.columbia.edu (Henning Schulzrinne)
Subject: Re: G.723.1 and G.729 licensing
Importance: Normal
X-Mailer: Connect2-SMTP 4.30A MHS/SMF to SMTP Gateway
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Perhaps we ought to rename this group Voice over Intellectual Property!

What's the position with completely independently developed code that can 
interwork with G.723.1 and G.729? Is that allowed to given away free? Or do 
the intellectual property holders have a right to monies anyway?

Rgds, Andy Chittenden

Email:	achitten@madge.com	Fax:	+44 1753 661011
Multimedia Development, Madge Networks Ltd
Sefton Park, Bells Hill, Stoke Poges, Slough SL2 4JS, England




From rem-conf Wed Apr 30 09:22:54 1997 
From rem-conf-request@tmpmail.es.net Wed Apr 30 09:22:53 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wMc5X-0006Vm-00; Wed, 30 Apr 1997 09:18:39 -0700
Sender: hgs@cs.columbia.edu
Message-ID: <336770B5.7147@cs.columbia.edu>
Date: Wed, 30 Apr 1997 12:17:57 -0400
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Andrew Chittenden WAVE-SP <achitten@madge.com>
CC: rem-conf@es.net, voip-tech@vocaltec.com
Subject: Re: G.723.1 and G.729 licensing
References: <26F5763901560C00@mail.madge.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Andrew Chittenden WAVE-SP wrote:
> 
> Perhaps we ought to rename this group Voice over Intellectual Property!

Except that we don't have a voice over intellectual property...

> 
> What's the position with completely independently developed code that can
> interwork with G.723.1 and G.729? Is that allowed to given away free? Or do
> the intellectual property holders have a right to monies anyway?

The short answer: a distinct 'no'. This is not copyright (expression)
[although the code is obviously copyrighted], but patents (ideas). You
do have an option: you can wait 17 or so years for the patents to
expire... Building stuff outside the US won't help either, in case you
are wondering.

Also, the likelihood of developing new codecs similar in performance to
G.723.1 or G.729 that do not infringe on at least one of their patents
(or some other patent) is highly unlikely. Cryptography and audio/video
coding are probably two of the most patent-riddled areas relevant to
communication protocols.

People have complained a lot about the cryptography (RSA, D-H, etc.)
patents. At least they applied only to the US and one could get a
reference library (RSAREF) free for noncommercial use. Same with DES and
IDEA. PGP wouldn't exist without this.


> 
> Rgds, Andy Chittenden
> 
> Email:  achitten@madge.com      Fax:    +44 1753 661011
> Multimedia Development, Madge Networks Ltd
> Sefton Park, Bells Hill, Stoke Poges, Slough SL2 4JS, England



From rem-conf Wed Apr 30 12:29:26 1997 
From rem-conf-request@tmpmail.es.net Wed Apr 30 12:29:25 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wMetn-0007DB-00; Wed, 30 Apr 1997 12:18:43 -0700
X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed;
               Wed, 30 Apr 1997 20:41:19 +0200
X400-Received: by mta xr3.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed;
               Wed, 30 Apr 1997 20:41:19 +0200
X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Wed, 30 Apr 1997 20:41:09 +0200
X400-Received: by /PRMD=cnet/ADMD=atlas/C=FR/; Relayed;
               Wed, 30 Apr 1997 21:22:56 +0200
Date: Wed, 30 Apr 1997 21:22:56 +0200
X400-Originator: haignere@issy.cnet.fr
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/PRMD=cnet/ADMD=atlas/C=FR/;862417389@x400.issy.cnet.fr]
X400-Content-Type: P2-1984 (2)
Content-Identifier: H263 payloads.
Alternate-Recipient: Allowed
From: Isabelle HAIGNERE <haignere@issy.cnet.fr>
Message-ID: <9704301622.AA01720@haddock>
To: rem-conf@es.net, garys@pictel.com, casner@precept.com, 
    czhu@mailbox.jf.intel.com, isabelle.haignere@issy.cnet.fr
Subject: H263 payloads.
Content-Length: 2281
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

*-------------------------------------------------------*
|       From :  Isabelle Haignere                       |
|               FT/BD/CNET - DSE/SGV                    |
|               38-40 rue du General Leclerc            |
|               F-92 131 Issy les Moulineaux            |
|               FRANCE                                  |
|                                                       |
|               Tel.   : + 33 1 45 29 40 08             |
|               Fax.   : + 33 1 45 29 52 94             |
|                                                       |
|               E-mail : isabelle.haignere@issy.cnet.fr |
*-------------------------------------------------------*

Hello,

The following problem is an important item.
With the mode A, the GOB number is not introduced in the payload header
and it seems that can cause some trouble. The final objective of the
payload is to help the decoding of parts of the picture (we assume that
the packets arrive at the input of the decoder in the same temporal
order than they have been created : this is performed by the rtp
function), if we receive a packet at the output of the payload and if
some previous packets have been lossed, the packet can be decoded by the
decoder but cannot be located at the right location because one does not
know the GOB number.In this case what
is the gain of the payload ? The answer is nothing.
A solution can be the introduction of GOB headers on the H263 bitstream
level by the coder but there are still some problem. The cost of the
GOB header is high, we can propose to introduce only some GOB headers
that is to say not on every row of macro-blocks but on some rows (at the
beginning of the packet for example), in
this case the coder AND NOT the payload module chooses the boundarys of the packet,
and are we sure that the packet size will be abiden ? It is not
sure. A proposal could be then the management of GOB headers by the PL itself
but it is not possible because the use or not use of GOB headers has
major consequences on coding and cannot be chosen a posteriori but a
priori.

A proposal should be to add an additional byte which should contain the
GOB number. I think that it is an important parameter that we have to
add in the mode A.


Isabelle HAIGNERE




From rem-conf Wed Apr 30 13:46:34 1997 
From rem-conf-request@tmpmail.es.net Wed Apr 30 13:46:34 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wMgCO-0007cS-00; Wed, 30 Apr 1997 13:42:00 -0700
Message-Id: <199704302041.NAA09449@denali.perf.com>
From: Robert McKenzie <robert@perf.COM>
To: rem-conf <rem-conf@es.net>
Subject: Re: H263 payloads.
Date: Wed, 30 Apr 1997 13:39:49 -0700
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

Simply including GOB numbers in the payload header is insufficient to
enable recovery from missing packets.  

Without gob headers, motion vector predictors are dependent on motion
vectors from the prior gob.  Thus in order to recover things, you would
need to include the motion vector predictors for ALL macroblocks in the
packet which do not have the macroblock immediately above them also in the
packet.

However, when gob headers are used, you have not only the gob number in the
bitstream, but also all motion vector predictors only depend on the
macroblock immediately to the left.  This solves both problems at once (at
the cost of 29 or more bits per gob header).

Robert McKenzie
<bmckenzi@smithmicro.com>

----------
> From: Isabelle HAIGNERE <haignere@issy.cnet.fr>
> To: rem-conf@es.net; garys@pictel.com; casner@precept.com;
czhu@ideal.jf.intel.com; isabelle.haignere@issy.cnet.fr
> Subject: H263 payloads.
> Date: Wednesday, April 30, 1997 12:22 PM
> 
> *-------------------------------------------------------*
> |       From :  Isabelle Haignere                       |
> |               FT/BD/CNET - DSE/SGV                    |
> |               38-40 rue du General Leclerc            |
> |               F-92 131 Issy les Moulineaux            |
> |               FRANCE                                  |
> |                                                       |
> |               Tel.   : + 33 1 45 29 40 08             |
> |               Fax.   : + 33 1 45 29 52 94             |
> |                                                       |
> |               E-mail : isabelle.haignere@issy.cnet.fr |
> *-------------------------------------------------------*
> 
> Hello,
> 
> The following problem is an important item.
> With the mode A, the GOB number is not introduced in the payload header
> and it seems that can cause some trouble. The final objective of the
> payload is to help the decoding of parts of the picture (we assume that
> the packets arrive at the input of the decoder in the same temporal
> order than they have been created : this is performed by the rtp
> function), if we receive a packet at the output of the payload and if
> some previous packets have been lossed, the packet can be decoded by the
> decoder but cannot be located at the right location because one does not
> know the GOB number.In this case what
> is the gain of the payload ? The answer is nothing.
> A solution can be the introduction of GOB headers on the H263 bitstream
> level by the coder but there are still some problem. The cost of the
> GOB header is high, we can propose to introduce only some GOB headers
> that is to say not on every row of macro-blocks but on some rows (at the
> beginning of the packet for example), in
> this case the coder AND NOT the payload module chooses the boundarys of
the packet,
> and are we sure that the packet size will be abiden ? It is not
> sure. A proposal could be then the management of GOB headers by the PL
itself
> but it is not possible because the use or not use of GOB headers has
> major consequences on coding and cannot be chosen a posteriori but a
> priori.
> 
> A proposal should be to add an additional byte which should contain the
> GOB number. I think that it is an important parameter that we have to
> add in the mode A.
> 
> 
> Isabelle HAIGNERE
> 
> 



From rem-conf Wed Apr 30 19:22:57 1997 
From rem-conf-request@tmpmail.es.net Wed Apr 30 19:22:54 1997
Received: from list by mail1.es.net with local (Exim 1.61 #3)
	id 0wMlO6-0000ku-00; Wed, 30 Apr 1997 19:14:26 -0700
Date: Wed, 30 Apr 1997 18:52:59 -0700 ()
From: Stephen Casner <casner@precept.com>
To: ietf-ppp@merit.edu
cc: issll@mercury.lcs.mit.edu, ipng@sunroof.eng.sun.com, rem-conf@es.net
Subject: Request PPPEXT review of draft-engan-ip-compress-00.txt
In-Reply-To: <Pine.SOL.3.95.970409003421.153A-100000@little-bear.precept.com>
Message-ID: <Pine.WNT.3.95.970430184200.-112471J-100000@oak.precept.com>
X-X-Sender: casner@little-bear.precept.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: <rem-conf@tmpmail.es.net> 
X-Loop: rem-conf@tmpmail.es.net
Precedence: list

During IETF in Memphis, I sent a message to the PPPEXT working group
that included a draft updated the night before on extending PPP to
include the IPv6 and RTP header compression schemes.  After further
discussions during IETF, that draft has been revised and was just
posted:
		    draft-engan-ip-compress-00.txt

This draft poses two questions that we need the PPPEXT WG to answer:

1.  The current IPCP spec (RFC 1332) does not provide a means to
    enable more than one header compression protocol at a time, e.g.,
    for both TCP and RTP.  This new draft proposes three options for
    extending the compression option to accommodate the additional
    compression schemes.  We need to know which should be chosen.

2.  PPP protocol identifiers need to be assigned for the uncompressed
    and compressed packet formats used in these compression schemes.
    Four of these should be 8-bit identifiers so as not to impose a
    significant overhead on the compressed headers; considering that
    these header compression schemes cover multiple protocols, we
    think this is a fair allocation.  We need to get PPPEXT
    concurrence so IANA can make those assignments.

Those of us working on these compression schemes hope to get these
questions answered as soon as possible so that the draft can be
published as an RFC and waiting implementations can be deployed.
Therefore your prompt consideration of this draft would be most
heartily appreciated.

These compression schemes are the result of efforts in the IPNG, ISSLL
and AVT working groups.

       -- Steve Casner for Mathias Engan and Carsten Bormann