From rem-conf Tue Sep 01 07:55:32 1998 From rem-conf-request@es.net Tue Sep 01 07:55:30 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zDrfN-00006S-00; Tue, 1 Sep 1998 07:44:17 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zDrfL-000063-00; Tue, 1 Sep 1998 07:44:16 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA23263; Tue, 1 Sep 1998 10:43:12 -0400 (EDT) Message-Id: <199809011443.KAA23263@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-mux-rtp-00.txt Date: Tue, 01 Sep 1998 10:43:11 -0400 Sender: cclark@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@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 : User Multiplexing in RTP payload between IP Telephony Gateways Author(s) : B. Subbiah, S. Sengodan Filename : draft-ietf-avt-mux-rtp-00.txt Pages : 17 Date : 31-Aug-98 This draft proposes a method to multiplex a number of low bit rate audio streams (upto 256) into a single RTP/UDP/IP connection between IP telephony gateways. Audio samples from different users are assem- bled into an RTP payload thus reducing the overhead of RTP/UDP/IP headers. To identify users sharing a single RTP/UDP/IP connection, a 2 byte MINI-Header is proposed. A channel negotiation procedure to assign and release channels on a single UDP connection between gateways is described. 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-mux-rtp-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-mux-rtp-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-mux-rtp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980831113920.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-mux-rtp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-mux-rtp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980831113920.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Wed Sep 02 06:28:11 1998 From rem-conf-request@es.net Wed Sep 02 06:28:10 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zECq2-0001Tr-00; Wed, 2 Sep 1998 06:20:42 -0700 Received: from glory.kaist.ac.kr [143.248.174.200] by mail1.es.net with smtp (Exim 1.81 #2) id 0zECq1-0001Tg-00; Wed, 2 Sep 1998 06:20:41 -0700 Received: from Default by glory.kaist.ac.kr (8.6.12H1/8.6.4) id VAA17453 Date: Wed, 2 Sep 1998 21:46:10 +0900 To: noi3@mail.k.mcs.de From: noi3@mail.k.mcs.de (gotvel) Comments: Authenticated sender is Subject: 1998 AirFare Outlook...Lower Fares than Airlines! Message-Id: <19980902383EAA24886@treiumpant.kaist.ac.kr> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list -------------------------------- Remove Instructions at the bottom -------------------------------- TravelNews keeps on-line travellers updated on Fare Wars, cruise and vacation specials, and other travel-related news. To enroll in this FREE Email service, please see end of message. Dear Client, Special Preferred AirFares now available by phone.....Airfare outlook for the rest of 1998..... Our Preferred Fares are now available by phone. These special AirFares are lower than the Airlines themselves and lower than travel agencies. We currently offer Preferred Fares with Delta, Northwest, Continental, United, and American (Caribbean only). Call us for the best rates for travel in the US, Canada, the Caribbean, Europe, Central and South America, and more !! 800-672-1672 (9am-6pm EST) ** Fully Bonded Airline Ticket supplier, serving clients worldwide since 1991. ** (rates are discounts off lowest published fare by above carriers, must be purchased at least 7 days in advance and include a Saturday night stay, subject to availability) You'll never pay regular rates again!! 800-672-1672 (9am-6pm EST) Airfare Outlook for 1998......Most airlines continue to report record booking levels which will continue the trend of higher fares that we predicted at the beginning of this year. Even though many carriers did offer sporadic "sales fares", the discounts were generally smaller and the "fare wars" fewer. It is even more important to monitor fares closely during the 2nd half of 1998 and especially important to BUY EARLY !! Remember that low fares for Holiday travel (Labor Day, Thanksgiving, Christmas) are currently available but will no doubt be selling out much sooner this year because demand will be higher. If you wait too long to buy tickets, you could pay up to 50% more. ** Did you know that we have lower fares than on-line booking !! ** ** Most transactions on-line take up to 40 minutes, ours take only 5-10 minutes!! ** 800-672-1672 (9am-6pm EST) TravelNews keeps on-line consumers updated on AirFares, Fare Wars, travel bargains, and other travel-related news. If you would like a subscription to this FREE news service, (no cost involved, all addresses kept confidential, can cancel at anytime, will receive approximately 2-3 brief messages per month) call 919-383-0388 ext 11 - - - - - - - - - - - - - - - - - - - - - - - - - This Mailing List was filtered against the Global Remove List at: www.remove-list.com Remove-List is a free public service offering to help the public get removed from email lists, and did not sent this message. To add your name to their list and not receive email from us or any other ethical bulk emailer go to www.remove-list.com 7824f87r6-66g9df From rem-conf Sat Sep 05 16:05:22 1998 From rem-conf-request@es.net Sat Sep 05 16:05:21 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zFR84-0003bw-00; Sat, 5 Sep 1998 15:48:24 -0700 Received: from (eurosat.com) [207.159.154.2] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zFR83-0003bk-00; Sat, 5 Sep 1998 15:48:23 -0700 Received: from i-q4xnihl (ip159.belair.md.pub-ip.psi.net [38.14.57.159]) by eurosat.com (8.8.5/8.8.5) with SMTP id XAA28405; Sat, 5 Sep 1998 23:44:48 GMT Date: Sat, 5 Sep 1998 23:44:48 GMT From: XXXPassword@webmail.bellsouth.net Message-Id: <199809052344.XAA28405@eurosat.com> To: suzy@webmail.bellsouth.net Subject: 1 password.....15000 adult sites X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Click Here to obtain a password that will give you access to over 15,000 adult web sites for 1 low price. Also, check out the hot phone sex numbers and free pics From rem-conf Sat Sep 05 17:05:21 1998 From rem-conf-request@es.net Sat Sep 05 17:05:20 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zFSEI-0004df-00; Sat, 5 Sep 1998 16:58:54 -0700 Received: from (eurosat.com) [207.159.154.2] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zFSEG-0004dV-00; Sat, 5 Sep 1998 16:58:52 -0700 Received: from i-q4xnihl (ip238.belair.md.pub-ip.psi.net [38.14.57.238]) by eurosat.com (8.8.5/8.8.5) with SMTP id AAA00513; Sun, 6 Sep 1998 00:50:08 GMT Date: Sun, 6 Sep 1998 00:50:08 GMT From: Hot-Pink-Muff@webmail.bellsouth.net Message-Id: <199809060050.AAA00513@eurosat.com> To: suzy@webmail.bellsouth.net Subject: Young Fresh Teens X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Cyber-Pink, the name says it all.  This site features a dynamite selection of hardcore video feeds and streaming movies along with a huge collection of XXX pix.  This site offers a free one week demo..  Click here to enter From rem-conf Tue Sep 08 05:26:26 1998 From rem-conf-request@es.net Tue Sep 08 05:26:25 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zGM4s-0001Sg-00; Tue, 8 Sep 1998 04:36:54 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0zGM4k-0001ST-00; Tue, 8 Sep 1998 04:36:47 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 8 Sep 1998 12:36:39 +0100 To: rem-conf@es.net Subject: Draft AVT minutes Date: Tue, 08 Sep 1998 12:36:38 +0100 Message-ID: <1184.905254598@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I enclose a draft of the minutes for the Chicago AVT meeting. In order to meet the submission deadline, I'd be grateful if you could send comments or corrections to me by Thursday evening. Colin =============================================================================== Minutes of the Audio/Video Transport Working Group Reported by Colin Perkins The Audio/Video Transport working group met twice at the 42nd IETF in Chicago. The major items of discussion were the revision of RTP and the Audio/Video profile for advancement to draft standard, multiplexing of RTP streams and transport of MPEG4 streams using RTP. The meeting opened with a review of the status of the working group documents. The RTP header compression scheme and the payload format documents for JPEG, BT656 and H.263+ video are now either awaiting IESG approval or are in last call. The payload format for bundled MPEG streams has been published as RFC2343 (experimental). The Options for Repair of Streaming Media document has been published as RFC2354 (informational). The draft giving guidelines for writers of RTP payload format documents (draft-ietf-avt-rtp-format-guidelines-00.txt) is still awaiting revision. Comments and suggestions are encouraged in order that this document can effectively capture the knowledge of the group as an aid to the designers of future payload formats. The RTP payload format for PureVoice audio (draft-mckay-qcelp-01.txt) was discussed briefly with a view to conducting last call for proposed standard soon. Some concerns were raised regarding the means for signalling encryption of the media data only (not the RTP headers) by means of a bit in the payload sub-header, since out-of-band signalling, for example using an SDP attribute, may be more appropriate. Clarification of this issue is needed before the draft can go forward, but the document is otherwise complete. The generic RTP payload format was not discussed this time. The authors of the proposals presented at the last meeting were to produce a combined proposal, but this is not yet complete. It is expected that further discussion of this subject will take place during the next meeting. The RTP MIB (draft-ietf-avt-rtp-mib-02.txt) was presented by Mark Baugher (Intel). The changes since the previous draft are the elimination of separate tables for hosts and monitors, with an rtpSessionMonitor variable being added to distinguish the two modes. The rtpFracLost variable was removed since it was found not to be useful. The definition of a session was clarified. The RTP MIB will be referenced by the H-series MIBs which are being defined, but the RTP MIB itself will remain an AVT work item (since RTP experience is in this group). The H-series MIB developers will review the RTP MIB to ensure that it meets their needs. The main area of concern with this current version of the RTP MIB is the complexity of the compliances definitions resulting from the merger of the tables. It is expected that the MIB will be ready for last call after a further round of revisions, probably by the time of the next meeting. A reference implementation of the MIB is now available. The major topic of discussion on the first day was multiplexing multiple streams into a single RTP stream. This discussion started with an introduction by Stephen Casner (Cisco) who raised a number of issues for consideration in the following discussion: - Why are we multiplexing: because common handling is needed or to reduce overhead? - When should we multiplex: what should be separate and what should be bundled? - Where should we multiplex? At which protocol level? Can we keep all multiplexing at one protocol level? - How should we multiplex: an application specific solution or a general purpose one? A pointer was also given to Jonathan Rosenberg's internet-draft on this subject from December 1996, which discusses these issues. Copies of this may be obtained from http://www.cs.columbia.edu/~jdrosen/aggregate/rtpdoc.htm and a revised and updated version of this will be re-posted. Following the introduction, a number of proposals were presented: Jonathan Rosenberg (Lucent) and Barani Subbiah (Nokia) presented somewhat similar proposals applicable for the efficient connection of PSTN gateways using RTP. Tohru Hoshi (Hitachi) and Mark Handley (ISI) presented more general proposals. The first presentation was of draft-ietf-avt-aggregation-00.txt by Jonathan Rosenberg. This proposal deals with the interconnection of telephony gateways only - it is not a general purpose multiplexing protocol. Some of the main features of this proposal are: - Users are identified by a single 7 bit identifier. The mapping from SSRC to this identifier is done by non-RTP means (eg: SIP/H.323 signalling). If more than 127 streams are being transported between two gateways multiple multiplexed RTP sessions must be used. - All multiplexed streams must share a common clock and generate packets at integer multiples of a common frame duration. They do not need to use a common codec. - Payload type information is transported for each multiplexed user. In many cases the payload type specifies the length of the packet so there is no need for a separate length indication field (although one can optionally be provided if necessary). - User payloads are not word aligned. Aligning them would reduce the bandwidth efficiency significantly. It was noted that statistical multiplexing of multiple streams using silence suppression can cause problems: there is a limit to how many streams can be packed into a single multiplexed packet before exceeding the network MTU. To avoid this two multiplexed packets must be generated, but this will cause the receiver to see non-contiguous sequence numbers per user giving the appearance of loss. The solution is to limit the statistical multiplexing of streams so that this does not occur, this reduces the efficiency somewhat. It was also noted that the loss of a single packet from the multiplexed stream will affect all users multiplexed into the stream. It is not expected that this will be a problem (in fact the use of multiplexing may reduce loss rates, since it reduces the both the data and packet rates compared to non-multiplexed streams). Barani Subbiah (Nokia) presented draft-ietf-avt-mux-rtp-00.txt. This proposal is designed to solve a similar problem to that of Rosenberg and is unsurprisingly somewhat similar to that proposal. The main difference seems to be that this protocol uses an explicit length indication for each multiplexed packet (6 bits rather than 16 bits in Rosenberg's proposal) and that the payload type for each user is signalled out-of-band rather than carried in the payload (disallowing changing payload types on the fly). Neither of these two proposals carry the timestamp of the multiplexed packets explicitly: the timestamp of the enclosing RTP packet must be used. This may introduce some small additional amount of jitter, although it is not thought that this will be a problem. A more generic proposal (draft-tanigawa-rtp-multiplex-00.txt) was presented by Tohru Hoshi (Hitachi). In this proposal RTP streams are multiplexed, rather than voice streams, by concatenating multiple RTP packets into one. This allows for the multiplexing of any sort of data, rather than just voice data, at the expense of additional overheads. Once again, out of band signalling is required to indicate that this is a multiplexed stream. It was noted that it may be possible to generalise this as a generic IP multiplexing protocol, rather than an RTP multiplexer. These proposals discuss out-of-band signalling which is required for correct operation of these protocols. It is noted that, whilst signalling is required in these cases and should be simple to implement using either SIP or H.323, it is outside the scope of the AVT group's charter. It was noted that the presence of multiple multiplexing solutions is not necessarily desirable, since this hinders interoperability. It would be desirable to combine these proposals into one if at all possible. However, it was further noted that the drafts from Rosenberg and Subbiah are essentially solving the same problem, whilst the proposal presented by Hoshi is doing something different. The tradeoffs are different and we may need two protocols: the issues are sufficiently different for the two scenarios. None of the three proposals presented so far have solved the generic multiplexing problem: the first two are clearly very application specific, the third requires out of band signalling to operate. The second session started with a brief presentation by Mark Handley (ISI) describing an idea which resulted from the earlier discussion of multiplexing. This proposal, MuRGE, uses the techniques of RTP header compression within a single packet as a generic multiplexing method (all state is reinitialised within each packet). That is, each packet contains a standard RTP header followed by a number of payloads each with their own payload header. The payload headers are coded as differences from the previous header. Clearly the bandwidth efficiency of this proposal depends on the similarity between the headers of the multiplexed payloads. If used between cooperating gateways where SSRC values can be allocated consecutively and the codecs, timestamps and sequence numbers are synchronised, this proposal can produce a single byte header for each multiplexed packet. If there is no cooperation between multiplexing points the full RTP header has to be sent for each multiplexed stream. If signalling is employed between multiplexing points (eg: for SSRC mapping) then some gain can be made even in the most generic case. This proposal is at a very early stage of development, but introduces some interesting ideas. Further work is clearly needed. The discussion of multiplexing concluded with agreement that the development of a multiplexing proposal is of interest and should become a work item of the group. The next item for discussion was transport of MPEG4 streams using RTP draft-ietf-avt-rtp-mpeg4-00.txt and the role of DMIF signalling draft-ietf-avt-mpeg4-dmif-01.txt which was presented by Vahe Balabanian (Nortel). After outlining the proposals discussion focused on a number of open issues: - Should MPEG4 elementary streams be transported directly over RTP or should they be encapsulated using FlexMux first? There is some concern that the use of FlexMux does not cleanly fit into the RTP model in particular the interaction with RTP mixers is unclear. - The mapping of MPEG4 scene and object descriptor streams to RTP is unclear. It may be that these need special transport and protocols other than RTP may be better suited to their needs: in particular the initial session description should not be carried in RTP. The transport of dynamic updates to this is an area which needs further study: an RTP stream may be appropriate or alternatively a separate signalling stream (eg: RTSP using ANNOUNCE) may work better. - The mapping of MPEG4 decoder timestamps to RTP is unclear, since RTP includes only a send timestamp and applications are expected to derive their own decode time based on the observed network timing jitter. The next IETF meeting coincides with the MPEG4 decision meeting, so it is therefore urgent that these issues are resolved. The last chance to make changes to MPEG4 version 1 will be at the MPEG meeting on 12-16 October. Since it is clear that only limited progress can be made in the short time period available it was decided to continue with the development of the payload format for MPEG4 elementary streams and to resolve the issues discussed. Once this is done and further experience has been gained with actual implementations the group will revisit these issues. The major discussion item for the second day was the advancement of RTP and the Audio/Video profile from proposed- to draft-standard status. A summary of the changes in draft-ietf-avt-rtp-new-01.txt was made by Stephen Casner (Cisco). These include - Added fudge factor in timer reconsideration - Added fix for underestimate when using SSRC sampling if the group size decreases rapidly - RTCP sender and receiver bandwidth may be specified as a parameter (rather than the default 5%) - RTCP minimum interval may scale smaller for high bandwidth sessions and zero initial delay for unicast sessions - Specified padding for RTCP only on the last packet - Specified relative NTP uses the "best" platform clock - Formal reference to IPsec for security (this concerns some people since RTP may be used in scenarios where the presence of IPsec cannot be guaranteed...) - Partial conversion to SHOULD, MUST, MAY, etc In addition it has been decided not to make a number of the changes which have previously been suggested: - Ignore group size dropping to zero with reverse reconsideration. - No scaling of the RTCP interval larger since this could cause time-outs - No changes to the jitter algorithm for multi-packet video frames - No additional SDES items were defined (these can be registered with the IANA separately) - No change to the definition of the RTCP RR loss fraction - Nothing was added about translators adding random timestamp offsets The issue of conditional vs unconditional reconsideration was discussed and it was noted that there is little to choose between these two algorithms in practise, and that unconditional reconsideration is simplest to implement. The next revision will therefore only include unconditional reconsideration. A number of problems which have been discovered in the SSRC sampling algorithm were presented by Jonathan Rosenberg (Lucent). The problems with reconsideration and over-weighting of senders have been corrected in the current RTP draft. A problem remains when the group size decreases rapidly which results in members using SSRC sampling producing very inaccurate estimates of the group size. A solution using a "binning" algorithm is proposed in draft-ietf-avt-rtpsample-00.txt but this algorithm may be patented by Lucent (who are willing to license on "fair, reasonable and non-discriminatory terms"). Much discussion occurred on this topic since it is considered undesirable to have patented technology as part of the main specification. The cleanest solution appears to be to move the SSRC sampling algorithms out of the main specification into a separate document. The main RTP specification would note that SSRC sampling may be desirable in certain cases and point to this new document for implementation advice and sample algorithms. The changes to the Audio/Video profile (draft-ietf-avt-profile-new-03.txt) are less extensive: the PureVoice codec has been added and assigned payload type 12. As discussed at the previous meeting this is the last static assignment which will be made - this policy is now stated explicitly in the draft. The static assignment of payload type 77 to redundant audio has been removed since all known implementations use a dynamic payload type. References to MPEG1 system streams and MPEG2 program streams (RFC2250) using dynamic payload types have been added and a number of other RFC references have been updated. The new policy regarding static payloads needs to be better described in the next revision of the draft. The SDP modifiers to explicitly denote the RTCP fraction (if the default of 5% is not being used) have yet to be written, but it is felt that these should not be added to the A/V profile (since that should not be tied to SDP) rather a new document should define them. The MIME registration of payload formats has yet to be done. There are many open issues here regarding how this should occur, what information is bound to the names, who MIME is extended for types which cannot be represented in email, etc. An update on the RTP payload for redundant audio was presented by Colin Perkins (UCL). This document (draft-ietf-avt-rtp-redundancy-revised-00.txt) updates RFC2198 in the light of additional usage experience. The change is to specify that all packets in a redundant stream should be sent using the redundancy format, rather than sending the first packet(s) in a talkspurt using the payload format of the primary codec. This allows for explicit advertisement of the buffering requirements of a stream which simplifies implementations and removes the need for an out-of-band parameter to convey this information. An update on the RTP payload for generic forward error correction (draft-ietf-avt-fec-03.txt) was presented by Jonathan Rosenberg (Lucent). Changes since the previous draft include the addition of code fragments illustrating the decoding stage, support for FEC using Reed-Solomon codes, extension of the timestamp recovery to 56 bits and removal of the reference to the expired draft by Budge. A number of issues with the current draft were discussed including the required mask size: 24 bits is believed sufficient so the optional extension to 56 bits will be removed from the draft. It was also decided that parity FEC and Reed-Solomon codes are sufficiently different that this draft should be split into two. The resulting parity FEC payload format document is expected to be ready for last call after one further revision; the Reed-Solomon payload format document will need further work over the coming months. The meeting concluded with a reminder that a revised working group charter has been posted. Comments and discussion of the proposed new charter and milestones should be directed to the mailing list. =============================================================================== From rem-conf Wed Sep 09 04:47:07 1998 From rem-conf-request@es.net Wed Sep 09 04:47:06 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zGiYP-0006G2-00; Wed, 9 Sep 1998 04:36:53 -0700 Received: from upimssmtpsys11.email.msn.com (UPIMSSMTPSYS11) [207.68.143.175] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zGiYO-0006Em-00; Wed, 9 Sep 1998 04:36:52 -0700 Received: from UPIMSSMTPUSR04 - 207.68.143.160 by email.msn.com with Microsoft SMTPSVC; Wed, 9 Sep 1998 04:36:26 -0700 Received: from a - 208.255.165.121 by email.msn.com with Microsoft SMTPSVC; Wed, 9 Sep 1998 04:34:56 -0700 To: Web@Placement Bcc: liz@ervose.mv.com, heather_fox@es.adp.com, james_kinder@es.adp.com, thomasgf@es.dupont.com, dcewg@es.net, rem-conf@es.net From: Subject: DRAMATICALLY increase your website placement in as little as 72 hours!!!! content-length: 5488 Message-ID: <0fb465634110998UPIMSSMTPUSR04@email.msn.com> Date: 9 Sep 1998 04:35:15 -0700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Increase Your Website Traffic Within 72 Hours! We'll put YOUR website at the top of the search engines - FAST! If your site isn't getting the traffic it should, chances are it's because it's not ranked well on the major Internet search engines. According to recent studies on Internet commerce, over 90% of consumers find the websites they visit by using "The Big Eight" search engines. If your website isn't located in the top 20 pages of those engines, chances are your site will never be seen. What's the point of having an "invisible" website? The SINGLE most important thing you can do increase your website traffic is increase your search engine rank. That's what we do. HUGE RESULTS... NO EFFORT... You can spend hours marketing your site using every technique around, but they will all pale in comparison to getting your site properly ranked. By getting to the top of the search engines, you can have HUGE amounts of visitors at your site in as little as 72 HOURS! HOW THE SEARCH ENGINES RANK YOUR SITE... When you submit your website to a search engine to be indexed in its database, it sends a "robot" out to scan your page. Then, using complex algorithms to rank your page for keyword relevance, the "robot" determines whether you'll be ranked # 1 or 1,000,000 when potential visitors conduct a search looking for sites like yours. Because the search engines are constantly changing their algorithms to help provide users the best possible search results, there's only one true solution to high search engine placement. Us. WIN THE SEARCH ENGINE WARS! We understand these algorithms and will use them to get your website on top. Now you can experience the on-line success you originally built your website for. If you're not happy with your website's performance, let The Search Engine Performance Group put YOU on top. IT WILL BE THE BEST THING YOU EVER DO TO IMPROVE YOUR ON-LINE SUCCESS. HERE'S WHAT WE DO... In order to counter the ever changing search engine algorithms, we create an entire series of "entry pages" for each search engine, for EVERY keyword you give us! Each entry page is optimized to do well for a different set of algorithm variables. So instead of having one page struggling to do well for many keywords on many engines, we simply create separate entry pages for each keyword & each engine! It's through this unique approach that we're able to help YOU conquer the search engines. The "entry pages" act as a welcome screen for your website. They will say a few introductory things about your site and then ask the visitor to "Click Here To Enter," taking them directly to your current homepage. In creating these entry pages we DO NOT make any changes to the existing structure, content, or functionality of your current site. All pages we construct will link directly into your existing site. As a result, you can rest assured that your current website will remain exactly the same. HOW WELL DOES THE SERVICE WORK? We'll send you a detailed report of your current search engine ranking on The Big Eight engines before we begin. Then, once your new entry pages have been indexed, we'll send you a second report showing how they've done. You'll be able to confirm the results yourself. Here's a sampling of some results we've gotten for previous clients. These examples are for COMPETITVE keywords - not obscure words that nobody's looking for... <> 6 top 10 rankings on Infoseek for DIFFERENT relevant keywords <> 18 top 10 rankings across the major search engines <> 3 top 10 rankings on Alta Vista for ONE keyword <> 16 total #1 rankings (and an astounding 40 top 30 rankings across the different engines!!) <> 1-2 hits per week exploded to 500 per day <> 45,000 hits per month grew to 108,000... (and it's still growing!) CLIENT COMMENTS: "INCREDIBLE!! Our site is now receiving more hits in a day than we used to get in an entire month. [My boss] is still eating his words!" -Bob W. "I knew the search engines were an incredible marketing tool, but my company simply didn't have the time to devote to search engine placement. It has proven to be the best money we've ever spent on marketing. We'll be sending you some referrals for sure! Thanks." -Shelley H. "I worked for weeks to get good search engine placement, but I could never crack the top 80...my site was deserted. Within a month [after using our service], I'd had more hits than I'd had in the last year. I wouldn't believe it if it hadn't happened to me. Please don't mention a word to the competition." -Chris L. WHAT'S THE COST? Our services are just $385. This includes: <> Construction of optimized entry pages for up to 20 keywords <> Submission to the major search engines (AltaVista, HotBot, Infoseek, Excite, Lycos, Northern Light & WebCrawler) <> A complete report of your search engine rankings before we begin <> A complete report of your search engine rankings AFTER we've finished WHAT DO I NEED TO DO TO GET STARTED? <> Call Us - we'll answer any questions. <> Give us your keywords / keyword phrases (up to 20) <> Pay us $385 <> Sit back and enjoy the show! Your confidentiality is assured; we NEVER release any information about our clients. --Search Engine Success Group-- 410-783-8269 ----------------------- If you're not interested in any potential future offers, just click reply. Thank you. From rem-conf Wed Sep 09 06:39:35 1998 From rem-conf-request@es.net Wed Sep 09 06:39:34 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zGk2K-000013-00; Wed, 9 Sep 1998 06:11:52 -0700 Received: from netman.iscs.nus.sg [137.132.87.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zGk2I-00000i-00; Wed, 9 Sep 1998 06:11:50 -0700 Received: from sun450.iscs.nus.edu.sg (andykurn@sun450-m.iscs.nus.edu.sg [137.132.21.116]) by netman.iscs.nus.sg (8.8.5/8.8.5) with ESMTP id VAA02821 for ; Wed, 9 Sep 1998 21:10:32 +0800 (GMT+0800) Received: from localhost (parveenk@localhost) by sun450.iscs.nus.edu.sg (8.8.5/8.8.5) with SMTP id SAA18371 for ; Wed, 9 Sep 1998 18:11:00 +0800 (GMT-8) X-Authentication-Warning: sun450.iscs.nus.edu.sg: parveenk owned process doing -bs Date: Wed, 9 Sep 1998 18:10:59 +0800 (GMT-8) From: Parveen Kumar X-Sender: parveenk@sun450.iscs.nus.edu.sg To: rem-conf@es.net Subject: Hi Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Are there applications(reasonably stable) which uses RTP multiplexing/demultiplexing? Or most of the applications just use use one rtp session for each session? Sorry for my ignorance but I have a limited knowledge in this area. Could anyone of you give me pointers to such working applications. Thanx... Parveen Kumar MS, NUS singapore From rem-conf Wed Sep 09 07:13:39 1998 From rem-conf-request@es.net Wed Sep 09 07:13:38 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zGknr-0001Au-00; Wed, 9 Sep 1998 07:00:59 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0zGknq-0001Ak-00; Wed, 9 Sep 1998 07:00:58 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 9 Sep 1998 15:00:21 +0100 To: Parveen Kumar cc: rem-conf@es.net Subject: Re: Hi In-reply-to: Your message of "Wed, 09 Sep 1998 18:10:59 +0800." Date: Wed, 09 Sep 1998 15:00:20 +0100 Message-ID: <4918.905349620@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Parveen Kumar writes: >Are there applications(reasonably stable) which uses RTP >multiplexing/demultiplexing? If you mean applications which act as an RTP mixer, then rat-3.0 will do that. See http://www-mice.cs.ucl.ac.uk/multimedia/software/ for details. Colin From rem-conf Wed Sep 09 07:56:37 1998 From rem-conf-request@es.net Wed Sep 09 07:56:36 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zGlC4-0001z8-00; Wed, 9 Sep 1998 07:26:00 -0700 Received: from north.lcs.mit.edu [18.26.0.4] by mail1.es.net with smtp (Exim 1.81 #2) id 0zGlC3-0001yx-00; Wed, 9 Sep 1998 07:25:59 -0700 Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4) id KAA10499; Wed, 9 Sep 1998 10:25:43 -0400 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Parveen Kumar cc: rem-conf@es.net Subject: Re: Hi In-reply-to: Your message of "Wed, 09 Sep 1998 18:10:59 +0800." Date: Wed, 09 Sep 1998 10:25:43 -0400 Message-ID: <10497.905351143@north.lcs.mit.edu> Sender: mjh@north.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >Hi, > >Are there applications(reasonably stable) which uses RTP >multiplexing/demultiplexing? > >Or most of the applications just use use one rtp session >for each session? > >Sorry for my ignorance but I have a limited knowledge in this area. >Could anyone of you give me pointers to such working applications. To my knowledge, there aren't any publically available. In general RTP-level multiplexing of different media or sessions is a bad idea. It introduces an additional unnecessary level of multiplexing above the UDP port level, and makes it impossible to tailor QoS to the different streams. However I can also see that there are some cases (typically IP telephony between large PSTN gateways) where the bandwidth savings will be significant and different QoS is never required, so this is going to happen anyway. It's not clear to me though that the makers of such gateways are likely to make their code available. Also we now have four different proposals for how to do this, so its not clear that having code would help you right now. Cheers, Mark From rem-conf Wed Sep 09 08:15:54 1998 From rem-conf-request@es.net Wed Sep 09 08:15:54 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zGlVi-0002RD-00; Wed, 9 Sep 1998 07:46:18 -0700 Received: from usr6-dialup42.mix2.atlanta.mci.net (gdmwacf.mci.net) [166.55.52.106] by mail1.es.net with smtp (Exim 1.81 #2) id 0zGlUi-0002Od-00; Wed, 9 Sep 1998 07:45:21 -0700 To: rem-conf@es.net Subject: rem-conf Let Us Promote Your Site -gnwpvtwk Message-ID: DATE: Tue, 01 Sep 1998 22:45:24 -0500 From: roger@opusnet.com MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list -------------------------------------------------------------------

rem-conf Removal Instructions can be found at the bottom of this page !

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

Hello rem-conf

I found your name on this website if you are not the contact for it please foward this to the proper party.

Your Site Lost in Cyberspace?

Let our team of Experts Professionally Submit your Web Page for you to as many as 900 Sites. As low as .02 per search engine submission.

  • 1: GET MAXIMUM EXPOSURE
  • 2: MAKE MONEY
  • 3: YOUR TIME IS VALUABLE
  • 4: MISTAKES CAN BE COSTLY
  • How quickly can you do it? We'll start immediately. Submissions are usually completed within 5 working days (Monday to Friday) of receiving your confirmation.
  • When will my listings appear? Some sites post additions immediately, others may take up to several weeks to process submissions.
  • How will I know that the submissions were done? Within days of completion we will provide you with a report detailing exactly where your listing was submitted. If you want to, you can easily go to the sites and check for yourself. Although we can not guarantee that all sites will accept your listing (content may not be appropriate) Also, we have carefully selected sites that are likely to accept all submissions.
  • What's it going to Cost me? Submit to 900 sites Only $25.00 One time Special from this e-mail

    8: YES! Submit my Web page for me!

    Don't delay a minute longer! If you are serious about doing business on the Internet, this is the most essential step you need to take after getting your pages on-line. Simply fill out our order form fax it in to us and Start building your traffic today!

    ------------------------------CUT HERE-------------------------------------

    SECTION 1: Personal Information

    Your Full Name:__________________________

    Your eMail Address:_________________________

    Your Phone#:_________________________

    Your Fax#:___________________________

    SECTION 3: Submission Information

    Save Time and Delays by following our guidelines closely. If a length limit is exceeded (for example) we will have to ask you to shorten your information - thus delaying the process. Please do not type in ALL CAPS.

    NOTE: Each submission site has different submission forms. We will complete all available fields, however, all of the following information may not be listed at all sites.

    Company or Business name to include in submissions:

    ___________________________________________

    Enter Your Web Page Title:_______________________________

    NOTES: Your title should be no more than 40 CHARACTERS and include good keywords that describe the content of your Web page. Also, if you want it to appear near the top of alphabetically arranged lists and directories try and have the first letter of the title be an "A", "B", or "C" etc. Whatever you do, it should look like it belongs there or it may get chopped of by a site administrator. It doesn't necessarily have to match your actual Web Page title. In our opinion, it is redundant to include words such as "home page", "corporation" or other redundant words that are unlikely to be searched for, or that that unlikely to entice the viewer to click on YOUR title. You have only a few seconds to get a web surfers attention!

    Enter the URL for your Web Page:___________________________________

    NOTE: If you wish to have us submit more than one web page please fill out and submit this form for each individual page (simply fill out the form, submit it, make any necessary changes and submit it again). We can submit any page that has a unique URL.

    Suggest a possible category to place your listings in:

    __________________________________

    Enter a DESCRIPTION of the nature of your Web page (it MUST be 25 WORDS or less). Use good words in your description so that when a directory is searched your listing will be returned. Make sure you include your most important KEYWORDS as only a few sites have a field that allow us to submit KEYWORDS as a separate item. Don't overlook the obvious (computers, software, travel, book, gifts, etc.)!:

    ______________________

    Enter an alternate Short DESCRIPTION of the nature of your Web page (8 WORDS or less). We will use the long description wherever possible:

    ________________________

    Enter up to 20 single KEYWORDS (separated by spaces) that best describe the content of your Web page:

    __________________

    Person's name to include in submissions:

    __________________________

    eMail address to include in submissions:

    __________________________

    Phone number with area code to include in submissions:

    _____________________

    Fax number with area code to include in submissions (RECOMMENDED):

    ________________

    Toll Free 0800 number to include in submissions (if available):

    ____________________________

    Mailing Address to include in submissions:

    _____________________________

    SECTION 3: Payment Information

    Under no circumstances will any work commence

    until a valid form of payment is received!

    NOTE: you can call us in person at our voice or Fax number, OR you may fill out this form, print it out and Fax it to us.

    Lucid Technologies Inc

    5646 Wellesly Pk. Dr.

    Boca Raton, FL 33433

    Our voice number is: 561-347-7304, our Fax number is: 561-347-7304

    Also if you would like your site or product promoted by mass email or wish to buy mass e-mail products please call 561-347-7304

    Method of Payment: We Accept Check by Fax or Credit cards

    If paying by Credit Card we will need the following information

    We accept Visa, Mastercard, Diners Club

    Card Holders Name: _______________________________

    Mailing Address For Credit Card bill:

    Street: _______________________

    ____________________________

    City:_______ State:___________ ZIP:____________

    Card Number_______________________________________________

    EXP DATE________________________

    Signature of card holder

    _______________________________

    To Pay By Check

    Please Print Out this Form Take a blank check write void on it and tape it to this form and fax it back to us and enter your drivers licence number or state id here

    ___________________________________

    Tape Check here

    Fax this form to 561-347-7304

    ------------------------------------------CUT HERE-------------------------------------

    The Sender Of this E-mail is a Member of the Internet responsible marketers (I.R.M.A) Association #12995

    The Mailing List that you are being mailed from was filtered against

    the Global Remove List at: http://remove-list.com

    Remove-List is a free public service offering to help the general public

    get removed from bulk mailings lists and has not sent this message. If

    you want their help please add your name to their list and we you will

    not receive a bulk email from us or any other ethical bulk emailer.

    Also if you wish to have your product or service promoted by Bulk mail please call 561-347-7304

    DED):

    ________________ From rem-conf Wed Sep 09 17:33:29 1998 From rem-conf-request@es.net Wed Sep 09 17:33:28 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zGuZM-0001Xu-00; Wed, 9 Sep 1998 17:26:40 -0700 Received: from mail-01.cdsnet.net [206.107.16.35] by mail1.es.net with smtp (Exim 1.81 #2) id 0zGuZK-0001Xj-00; Wed, 9 Sep 1998 17:26:38 -0700 Received: (qmail 10882 invoked from network); 10 Sep 1998 00:22:28 -0000 Received: from mail.comdoc.com (199.254.228.248) by mail.cdsnet.net with SMTP; 10 Sep 1998 00:22:28 -0000 Received: from alfredo4.ina.com (cybercafe4.ina.com [206.111.170.4]) by mail.comdoc.com (8.8.4/8.7.3) with SMTP id RAA13858 for rem-conf@es.net; Wed, 9 Sep 1998 17:22:27 -0700 (PDT) Date: Wed, 9 Sep 1998 17:22:27 -0700 (PDT) From: iso-9000@mailexcite.com Received: from login_0246.whynot.net (mx.whynot.net[206.212.231.88]) by whynot.net (8.8.5/8.7.3) with SMTP id XAA05463 for ; Wed, 9 September 1998 17:21:58 -0700 (EDT) To: Subject: Is your company ISO-9000 registered? Reply-To: iso-9000@mailexcite.com X-PMFLAGS: 10322341.10 X-UIDL: 10293287_192832.222 Comments: Authenticated Sender is Message-Id: <45807876_32237956> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Our unique Turnkey Solution for ISO-9000 gives you everything you need to get ISO-9000 registered in 90-120 days. We offer an integrated approach that includes: Training GAP Analysis Quality Manual/Procedure Preparation Document Control Software Pre-assessement Audit Registration Audit ISO-9000 Certificate For more information, Call 561-367-9880 ext. 222 From rem-conf Wed Sep 09 19:13:03 1998 From rem-conf-request@es.net Wed Sep 09 19:13:02 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zGwBZ-0002xx-00; Wed, 9 Sep 1998 19:10:13 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zGwBY-0002xn-00; Wed, 9 Sep 1998 19:10:12 -0700 Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id WAA13910 for ; Wed, 9 Sep 1998 22:10:11 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id WAA21902 for ; Wed, 9 Sep 1998 22:10:10 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <35F73502.32DFB54B@cs.columbia.edu> Date: Wed, 09 Sep 1998 22:10:10 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5b1 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: MPEG/RTP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Is anybody aware of implementations that stream MPEG over RTP or (better yet) can receive such? If so, which mode (elementary, system or transport stream)? I seem to remember Precept having such a thing, but I can't find it at the moment. Thanks. -- Henning Schulzrinne schulzrinne@cs.columbia.edu Dept. of Comp. Sci. ph +1 212 939-7042 Columbia University fax +1 212 666-0140 New York, NY 10027 http://www.cs.columbia.edu/~hgs From rem-conf Wed Sep 09 23:46:42 1998 From rem-conf-request@es.net Wed Sep 09 23:46:41 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zH0QI-00058y-00; Wed, 9 Sep 1998 23:41:42 -0700 Received: from mmlab.snu.ac.kr [147.46.114.112] by mail1.es.net with smtp (Exim 1.81 #2) id 0zH0Q6-00058o-00; Wed, 9 Sep 1998 23:41:30 -0700 Received: from sapphire (sapphire.snu.ac.kr [147.46.15.208]) by mmlab.snu.ac.kr (8.6.12h2/8.6.12) with SMTP id PAA02941 for ; Thu, 10 Sep 1998 15:39:26 +1000 Message-ID: <007401bddc84$d9f5cb80$d00f2e93@sapphire.snu.ac.kr> From: "Yung Yi" To: Subject: RTP source code Date: Thu, 10 Sep 1998 15:32:50 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0071_01BDDCD0.44C34C80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0071_01BDDCD0.44C34C80 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 SGkuDQoNCklzIHRoZXJlIGFueSBSVFAgc291cmNlcyB0aGF0IEkgY2FuIGZyZWVseSB1c2U/DQpJ IGtub3cgdGhhdCBtYW55IE1Cb25lIHRvb2xzIGhhdmUgdGhlIHJ0cCBjb2RlcywgaG93ZXZlciwg SSB3YW50IHRvIFJUUCBzb3VyY2UgY29kZSBleGNsdWRpbmcgb3RoZXIgY29kZXMuDQoNCkFzIHlv dSBrbm93LCBMdWNlbnQgVGVjaCBoYXMgUlRQIGxpYnJhcnkgdGhhdCBjYW4gbm90IGJlIGZyZWVs eSBkaXN0cmlidXRhYmxlLg0KDQpUaGFua3MuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiBZdW5nIFlpDQogTXVsdGltZWRpYSAmIENvbXB1 dGVyIENvbW11bmljYXRpb24gTGFiLg0KIERlcHQuIG9mIENvbXB1dGVyIEVuZ2luZWVyaW5nLCBT ZW91bCBOYXRpb25hbCBVbml2Lg0KIA0KIFRlbCA6ICs4Mi0yLTg3Ni03MTcwDQogRmF4IDogKzgy LTItODc2LTcxNzENCiBFbWFpbCA6IHlpeXVuZ0BtbWxhYi5zbnUuYWMua3INCiBVUkwgOiBodHRw Oi8vbW1sYWIuc251LmFjLmtyL355aXl1bmcNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K ------=_NextPart_000_0071_01BDDCD0.44C34C80 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBXMyBIVE1MLy9FTiI+DQo8SFRNTD4N CjxIRUFEPg0KDQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9a3NfY181NjAxLTE5 ODciIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0nIk1TSFRNTCA0Ljcy LjMxMTAuNyInIG5hbWU9R0VORVJBVE9SPg0KPC9IRUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZm Pg0KPERJVj48Rk9OVCBzaXplPTI+SGkuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SXMgdGhlcmUgYW55IFJUUCBz b3VyY2VzIHRoYXQgSSBjYW4gZnJlZWx5IHVzZT88L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNp emU9Mj5JIGtub3cgdGhhdCBtYW55IE1Cb25lIHRvb2xzIGhhdmUgdGhlIHJ0cCBjb2RlcywgaG93 ZXZlciwgSSANCndhbnQgdG8gUlRQIHNvdXJjZSBjb2RlIGV4Y2x1ZGluZyBvdGhlciBjb2Rlcy48 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIHNpemU9Mj5BcyB5b3Uga25vdywgTHVjZW50IFRlY2ggaGFzIFJUUCBsaWJyYXJ5IHRo YXQgY2FuIG5vdCBiZSANCmZyZWVseSBkaXN0cmlidXRhYmxlLjwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlRoYW5r cy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwMDAgDQpzaXplPTI+LS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPEJSPiZuYnNw O1l1bmcgDQpZaTxCUj4mbmJzcDtNdWx0aW1lZGlhICZhbXA7IENvbXB1dGVyIENvbW11bmljYXRp b24gTGFiLjxCUj4mbmJzcDtEZXB0LiBvZiANCkNvbXB1dGVyIEVuZ2luZWVyaW5nLCBTZW91bCBO YXRpb25hbCBVbml2LjxCUj4mbmJzcDs8QlI+Jm5ic3A7VGVsIDogDQorODItMi04NzYtNzE3MDxC Uj4mbmJzcDtGYXggOiArODItMi04NzYtNzE3MTxCUj4mbmJzcDtFbWFpbCA6IDxBIA0KaHJlZj0i bWFpbHRvOnlpeXVuZ0BtbWxhYi5zbnUuYWMua3IiPnlpeXVuZ0BtbWxhYi5zbnUuYWMua3I8L0E+ PEJSPiZuYnNwO1VSTCA6IA0KPEEgDQpocmVmPSJodHRwOi8vbW1sYWIuc251LmFjLmtyL355aXl1 bmciPmh0dHA6Ly9tbWxhYi5zbnUuYWMua3IvfnlpeXVuZzwvQT48QlI+LS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9GT05UPjwvRElWPjwvQk9E WT48L0hUTUw+DQo= ------=_NextPart_000_0071_01BDDCD0.44C34C80-- From rem-conf Thu Sep 10 01:58:41 1998 From rem-conf-request@es.net Thu Sep 10 01:58:39 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zH2VH-0006rr-00; Thu, 10 Sep 1998 01:54:59 -0700 Received: from mailer.berkom.de [141.39.13.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zH2VE-0006rg-00; Thu, 10 Sep 1998 01:54:56 -0700 Received: from berkom.de (kira.berkom.de [141.39.12.155]) by mailer.berkom.de (8.8.8/8.8.8) with ESMTP id KAA20913; Thu, 10 Sep 1998 10:00:05 +0200 (MET DST) Message-ID: <35F79388.95F47C4D@berkom.de> Date: Thu, 10 Sep 1998 10:53:28 +0200 From: Nicolai Leymann Organization: Deutsche Telekom Berkom GmbH X-Mailer: Mozilla 4.5b1 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: rem-conf@es.net Subject: Re: MPEG/RTP References: <35F73502.32DFB54B@cs.columbia.edu> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Precept (now Cisco) has a tool called IP/TV which supports MPEG (as well as other formats) and RTP. More information can be found under the following URL: http://www.precept.com/datasheets/html/ipdatasheet.htm Nic Henning Schulzrinne wrote: > Is anybody aware of implementations that stream MPEG over RTP or (better > yet) can receive such? If so, which mode (elementary, system or > transport stream)? I seem to remember Precept having such a thing, but I > can't find it at the moment. > > Thanks. > -- > Henning Schulzrinne schulzrinne@cs.columbia.edu > Dept. of Comp. Sci. ph +1 212 939-7042 > Columbia University fax +1 212 666-0140 > New York, NY 10027 http://www.cs.columbia.edu/~hgs > -- Nicolai Leymann email: leymann@berkom.de Deutsch Telekom Berkom GmbH phone: ++49-30-34973570 Goslarer Ufer 35, 10589 Berlin fax: ++49-30-34973571 From rem-conf Thu Sep 10 06:01:42 1998 From rem-conf-request@es.net Thu Sep 10 06:01:42 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zH6El-00015A-00; Thu, 10 Sep 1998 05:54:11 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0zH6Ej-00014z-00; Thu, 10 Sep 1998 05:54:09 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 10 Sep 1998 13:53:45 +0100 To: rem-conf@es.net Subject: Slides from Chicago meeting available Date: Thu, 10 Sep 1998 13:53:44 +0100 Message-ID: <3714.905432024@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Copies of slides presented at the AVT meeting in Chicago are now available >from http://www-mice.cs.ucl.ac.uk/multimedia/misc/avt/ along with draft minutes of the meeting. Colin From rem-conf Thu Sep 10 06:02:00 1998 From rem-conf-request@es.net Thu Sep 10 06:02:00 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zH6KK-00017H-00; Thu, 10 Sep 1998 05:59:56 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zH6KI-000177-00; Thu, 10 Sep 1998 05:59:54 -0700 Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id IAA11908; Thu, 10 Sep 1998 08:59:52 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id IAA23638; Thu, 10 Sep 1998 08:59:46 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <35F7CD41.573DD333@cs.columbia.edu> Date: Thu, 10 Sep 1998 08:59:45 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5b1 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Yung Yi CC: rem-conf@es.net Subject: Re: RTP source code References: <007401bddc84$d9f5cb80$d00f2e93@sapphire.snu.ac.kr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list All RTP implementations, including libraries, are listed at http://www.cs.columbia.edu/~hgs/rtp If you know of anything else, let me know. A very basic RTP implementation, without codecs, is part of the rtptools. From rem-conf Thu Sep 10 06:22:36 1998 From rem-conf-request@es.net Thu Sep 10 06:22:36 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zH6bl-000299-00; Thu, 10 Sep 1998 06:17:57 -0700 Received: from uni-paderborn.de [131.234.22.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zH6bk-00028u-00; Thu, 10 Sep 1998 06:17:56 -0700 Received: from alme.uni-paderborn.de ([131.234.16.16]:47438 "EHLO sai_sun4m.uni-paderborn.de" ident: "IDENT-NONSENSE") by mail.uni-paderborn.de with ESMTP id <21034-8466>; Thu, 10 Sep 1998 15:17:18 +0200 Received: (from cortes@localhost) by sai_sun4m.uni-paderborn.de (8.7.3/8.7.3) id PAA09631; Thu, 10 Sep 1998 15:17:16 +0200 (MET DST) From: Message-Id: <199809101317.PAA09631@sai_sun4m.uni-paderborn.de> Subject: Re: MPEG/RTP In-Reply-To: <35F73502.32DFB54B@cs.columbia.edu> from Henning Schulzrinne at "Sep 9, 98 10:10:10 pm" To: schulzrinne@cs.columbia.edu (Henning Schulzrinne) Date: Thu, 10 Sep 1998 15:17:15 +0200 (MET DST) Cc: rem-conf@es.net X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > Is anybody aware of implementations that stream MPEG over RTP or (better > yet) can receive such? If so, which mode (elementary, system or > transport stream)? I seem to remember Precept having such a thing, but I > can't find it at the moment. I don't know if you are asking for a commercial implementation or just any one. If it's the second case, we have developed such a solution within the SICMA ACTS project. The University of Paderborn has developed a multimedia server on a parallel computer which streams MPEG-1 System streams using RTP (RTSP for control), and a client that plays them (written in C++ and using Active Movie for the decoding, implemented as a Netscape Plug-in). Apart from them, we are aware of implementation from other companies that work with us in other projects. The german company "Axcent" has also developed an RTSP/RTP server for PC platforms and the corresponding client. I don't know about the commercial status of the product though. People from Siemens ZT in Munich are also working on the adaptation from a media server and client (Java applet, JMF based) to work with RTP and RTSP, and as far as I know have already a working version, but I doubt that it is an open product. If you have interest I could put you in touch with people in each group. As far as RTP is concerned, all the implementations use only MPEG-1 System streams, and a straightforward packetizing. ------------------------------------------------------------------- Francisco Cortes office: F2.315 University of Paderborn Tel.: +49 5251 60 6693 Dept. of Math. & Comp. Sci. Fax.: +49 5251 60 6697 Fuerstenallee 11 email: cortes@uni-paderborn.de D-33102 Paderborn, Germany http://www.uni-paderborn.de/fachbereich/AG/monien/PERSONAL/CORTES/ === PGP fingerprint 69 B9 77 98 D7 6A 8F CF 32 78 43 85 4E 7C E0 96 ------------------------------------------------------------------- From rem-conf Thu Sep 10 06:37:09 1998 From rem-conf-request@es.net Thu Sep 10 06:37:09 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zH6qP-0002xk-00; Thu, 10 Sep 1998 06:33:05 -0700 Received: from ([200.3.94.68]) [200.3.94.68] by mail1.es.net with smtp (Exim 1.81 #2) id 0zH6qK-0002rz-00; Thu, 10 Sep 1998 06:33:04 -0700 Received: from kabuki.telecom.com.ar by [200.3.94.68] via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 10 Sep 1997 13:36:30 UT Received: from ta.telecom.com.ar (ta.telecom.com.ar [200.3.93.100]) by kabuki.telecom.com.ar (8.6.8.1/SCA-6.6) with SMTP id QAA10669; Thu, 10 Sep 1998 16:33:36 +0300 From: rgarcia@ta.telecom.com.ar Received: by ta.telecom.com.ar(Lotus SMTP MTA v1.2 (600.1 3-26-1998)) id 0325667B.0049B203 ; Thu, 10 Sep 1998 10:24:56 -0300 X-Lotus-FromDomain: TELECOM@SMTP To: Henning Schulzrinne cc: rem-conf@es.net Message-ID: <0325667B.004A6E18.00@ta.telecom.com.ar> Date: Thu, 10 Sep 1998 10:34:07 -0300 Subject: Resp. a: MPEG/RTP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Cisco has an IP/TV server. Anyway, you can try ICAST viewer (http://www.icast.com), or NetShow from Microsoft. RAMIRO From rem-conf Thu Sep 10 08:38:34 1998 From rem-conf-request@es.net Thu Sep 10 08:38:32 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zH8iy-0005Bo-00; Thu, 10 Sep 1998 08:33:32 -0700 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zH8iw-0005Be-00; Thu, 10 Sep 1998 08:33:30 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id IAA02366 for ; Thu, 10 Sep 1998 08:33:29 -0700 (PDT) Message-Id: <3.0.3.32.19980910083328.00a68400@gumby.cs.berkeley.edu> X-Sender: cwilliams@gumby.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 10 Sep 1998 08:33:28 -0700 To: rem-conf@es.net From: Chris Williams Subject: Sept. 16 Berkeley, Multimedia, Interfaces, and Graphics Seminar Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list

    ICEBERG: From POTS to PANS Wednesday September 16, 1998 12:30-2:00 PDT 405 Soda Hall
    Anthony Joseph Computer Science Division - EECS University of California, Berkeley
    Technological progress is yielding a convergence of network access and backbone infrastructure: wide-area wireless networking, digital cellular telephony, wired and wireless IP networks, and public switched telephone networks. However, the process is far from over and many significant design challenges remain. The UC Berkeley's Iceberg project is exploring these challenges, including how to merge the different design philosophies and requirements that are associated with each of the access and backbone technologies. We are in the process of building a large-scale testbed, based upon an IP core network, that will incorporate current and prototype networking technology. Once it is deployed, our testbed will provide significant additional functionality beyond that which is available from the individual components, including the ability to handoff services from one network to another (e.g., transferring a call from a cell phone to wireless IP connected laptop). In addition, the infrastructure will offer ubiquitous access to information, anywhere, anyplace, anytime, and using any I/O device. This talk will discuss the design of the Iceberg architecture and our progress is deploying the testbed. The seminar is broadcast on the Internet Mbone. The addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202. ____________________________________________ Chris Williams Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: cwilliams@bmrc.berkeley.edu From rem-conf Thu Sep 10 09:15:03 1998 From rem-conf-request@es.net Thu Sep 10 09:15:02 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zH9Ke-0006HG-00; Thu, 10 Sep 1998 09:12:28 -0700 Received: from caipfs.rutgers.edu [128.6.91.100] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zH9Kd-0006H6-00; Thu, 10 Sep 1998 09:12:27 -0700 Received: from biko.rutgers.edu (biko.rutgers.edu [128.6.37.98]) by caipfs.rutgers.edu (8.9.1a/8.9.1) with ESMTP id MAA03018 for ; Thu, 10 Sep 1998 12:12:24 -0400 (EDT) Received: from localhost (sukeshgg@localhost) by biko.rutgers.edu (8.9.1a/8.9.1) with SMTP id MAA01867 for ; Thu, 10 Sep 1998 12:12:22 -0400 (EDT) X-Authentication-Warning: biko.rutgers.edu: sukeshgg owned process doing -bs Date: Thu, 10 Sep 1998 12:12:22 -0400 (EDT) From: Sukesh Garg To: rem-conf@es.net Subject: Video and Java Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I am working on a project that involves sending real-time data over the n/w using Java. I have built an application and found the my application to be very slow. Is there any implementation available that is fast.... or any pointers as to increase the speed...(using java) Thanks Sukesh From rem-conf Thu Sep 10 10:35:22 1998 From rem-conf-request@es.net Thu Sep 10 10:35:21 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zHAaK-0007f2-00; Thu, 10 Sep 1998 10:32:44 -0700 Received: from redale.cisco.com [171.69.95.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zHAaJ-0007eN-00; Thu, 10 Sep 1998 10:32:43 -0700 Received: from cisco.com (dhcp-vm11-86-234.cisco.com [171.69.86.234]) by redale.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id KAA13003; Thu, 10 Sep 1998 10:31:05 -0700 (PDT) Message-ID: <35F80C21.CE44A298@cisco.com> Date: Thu, 10 Sep 1998 10:28:02 -0700 From: Anup Rao Reply-To: anrao@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: Sukesh Garg CC: rem-conf@es.net Subject: Re: Video and Java References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Sukesh Garg wrote: > > Hi, > I am working on a project that involves sending real-time data over the > n/w using Java. > I have built an application and found the my application to be very slow. > > Is there any implementation available that is fast.... > or any pointers as to increase the speed...(using java) > > Thanks > > Sukesh Make sure you are using a JIT. A lot depends on your threading model. Checkout http://developer.java.sun.com - it usually has some good performance tips. -Anup. From rem-conf Thu Sep 10 11:41:07 1998 From rem-conf-request@es.net Thu Sep 10 11:41:06 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zHBba-00011Z-00; Thu, 10 Sep 1998 11:38:06 -0700 Received: from habanero.marratech.com [195.196.47.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zHBbZ-00011O-00; Thu, 10 Sep 1998 11:38:05 -0700 Received: from marratech.com (prefect.marratech.com [195.196.47.38]) by habanero.marratech.com (8.8.8/8.8.8) with ESMTP id UAA11375; Thu, 10 Sep 1998 20:36:43 +0200 (CEST) (envelope-from serge@marratech.com) Message-ID: <35F81CF1.F9B6981B@marratech.com> Date: Thu, 10 Sep 1998 20:39:45 +0200 From: Serge Lachapelle Organization: Marratech AB (http://www.marratech.com) X-Mailer: Mozilla 4.5b1 [en] (WinNT; I) X-Accept-Language: fr-CA MIME-Version: 1.0 To: Sukesh Garg CC: rem-conf@es.net Subject: Re: Video and Java References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, The High performance native compiler from IBM could also help you. http://www.alphaWorks.ibm.com/ /Serge Lachapelle From rem-conf Thu Sep 10 12:08:55 1998 From rem-conf-request@es.net Thu Sep 10 12:08:54 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zHC2t-0001mc-00; Thu, 10 Sep 1998 12:06:19 -0700 Received: from rah.star-gate.com [209.133.7.234] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zHC2s-0001mS-00; Thu, 10 Sep 1998 12:06:18 -0700 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id MAA02365; Thu, 10 Sep 1998 12:05:55 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199809101905.MAA02365@rah.star-gate.com> To: Serge Lachapelle cc: Sukesh Garg , rem-conf@es.net, hasty@rah.star-gate.com Subject: Re: Video and Java In-reply-to: Your message of "Thu, 10 Sep 1998 20:39:45 +0200." <35F81CF1.F9B6981B@marratech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2362.905454355.1@rah.star-gate.com> Date: Thu, 10 Sep 1998 12:05:55 -0700 From: Amancio Hasty X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >http://www.alphaWorks.ibm.com/ jikes only speeds up compilation of java files . amancio From rem-conf Thu Sep 10 12:19:10 1998 From rem-conf-request@es.net Thu Sep 10 12:19:10 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zHCD4-0002NG-00; Thu, 10 Sep 1998 12:16:50 -0700 Received: from habanero.marratech.com [195.196.47.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zHCD3-0002My-00; Thu, 10 Sep 1998 12:16:49 -0700 Received: from marratech.com (prefect.marratech.com [195.196.47.38]) by habanero.marratech.com (8.8.8/8.8.8) with ESMTP id VAA11495; Thu, 10 Sep 1998 21:15:51 +0200 (CEST) (envelope-from serge@marratech.com) Message-ID: <35F8261D.BFC707B2@marratech.com> Date: Thu, 10 Sep 1998 21:18:53 +0200 From: Serge Lachapelle Organization: Marratech AB (http://www.marratech.com) X-Mailer: Mozilla 4.5b1 [en] (WinNT; I) X-Accept-Language: fr-CA MIME-Version: 1.0 To: Amancio Hasty CC: Sukesh Garg , rem-conf@es.net Subject: Re: Video and Java References: <199809101905.MAA02365@rah.star-gate.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Amancio Hasty wrote: > >http://www.alphaWorks.ibm.com/ > jikes only speeds up compilation of java files . > > amancio > Not Jikes, but the High Performance Compiler. Compiles Java bytecode (or sourcecode) into optimized, platform-specific native code Platform(s): AIX, OS/2, Windows 95, Windows NT High Performance Compiler for Java compiles Java bytecode into optimized platform-specific native (object) code. The resulting code is (generally) significantly faster than the bytecode executed in a JVM (Java Virtual Machine)/JIT (Just In Time) environment. The degree of performance improvement depends upon the application. /Serge Lachapelle From rem-conf Thu Sep 10 14:53:19 1998 From rem-conf-request@es.net Thu Sep 10 14:53:17 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zHEZP-0004Cm-00; Thu, 10 Sep 1998 14:48:03 -0700 Received: from pi4.informatik.uni-mannheim.de [134.155.48.125] (-2146555104) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zHEZN-0004Cc-00; Thu, 10 Sep 1998 14:48:01 -0700 Received: from localhost (cjk@localhost) by pi4.informatik.uni-mannheim.de (8.8.8/8.8.8) with SMTP id XAA01146; Thu, 10 Sep 1998 23:47:56 +0200 (MET DST) Date: Thu, 10 Sep 1998 23:47:56 +0200 (MET DST) From: Christoph Kuhmuench X-Sender: cjk@pi4 To: Henning Schulzrinne cc: rem-conf@es.net Subject: Re: MPEG/RTP In-Reply-To: <35F73502.32DFB54B@cs.columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Wed, 9 Sep 1998, Henning Schulzrinne wrote: > Is anybody aware of implementations that stream MPEG over RTP or (better > yet) can receive such? If so, which mode (elementary, system or > transport stream)? I seem to remember Precept having such a thing, but I > can't find it at the moment. I can offer an experimental implementation of the RTP payload for MPEG. We implemented the payload (video only) and integrated it into vic-2.8. Together with the MPEG-2 reference decoder version 1.2 of the MPEG Software Simulation Group which we also integrated into vic it is possible to stream MPEG-1 or MPEG-2 videos and display them. The name of the MPEG file can be entered in vic's Menu window. More info can be found at http://www.informatik.uni-mannheim.de/~cjk/ihl/rtp/ Regards, Chris ------------------------------------------------------------------------------ Christoph Kuhmuench email:cjk@pi4.informatik.uni-mannheim.de Praktische Informatik IV http://www.informatik.uni-mannheim.de/~cjk Universitaet Mannheim Tel: ++49 621 292 1554 L15,16 Fax: ++49 621 292 5745 68131 Mannheim, Germany ------------------------------------------------------------------------------ From rem-conf Thu Sep 10 14:56:32 1998 From rem-conf-request@es.net Thu Sep 10 14:56:32 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zHEhJ-0004M1-00; Thu, 10 Sep 1998 14:56:13 -0700 Received: from mail-out2.apple.com [17.254.0.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zHEhI-0004Lr-00; Thu, 10 Sep 1998 14:56:12 -0700 Received: from mailgate.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id OAA02814 for ; Thu, 10 Sep 1998 14:54:23 -0700 Received: from scv3.apple.com (scv3.apple.com [17.128.100.121]) by mailgate.apple.com (mailgate.apple.com2.0.15) with ESMTP id for ; Thu, 10 Sep 1998 14:52:19 -0700 Received: from [17.255.20.102] (dsinger2.apple.com [17.255.20.102]) by scv3.apple.com (8.8.5/8.8.5) with ESMTP id OAA10648 for ; Thu, 10 Sep 1998 14:52:12 -0700 X-Sender: singer@mail.apple.com Message-Id: MIME-Version: 1.0 Date: Thu, 10 Sep 1998 14:48:22 -0700 To: rem-conf@es.net From: Dave Singer Subject: RTP payload type names Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Is it legal to use a dynamic payload type for payloads which have a static payload ID? If it is, is there a table which gives the official RTPmap names for the existing static types? On a related topic, what is the RTPmap name for H.263+? Thank you! David Singer Apple Computer/QuickTime 408-974-3162 From rem-conf Thu Sep 10 15:27:29 1998 From rem-conf-request@es.net Thu Sep 10 15:27:28 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zHFAI-0005jC-00; Thu, 10 Sep 1998 15:26:10 -0700 Received: from north.lcs.mit.edu [18.26.0.4] by mail1.es.net with smtp (Exim 1.81 #2) id 0zHFAG-0005j1-00; Thu, 10 Sep 1998 15:26:08 -0700 Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4) id SAA17612; Thu, 10 Sep 1998 18:26:05 -0400 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Dave Singer cc: rem-conf@es.net Subject: Re: RTP payload type names In-reply-to: Your message of "Thu, 10 Sep 1998 14:48:22 PDT." Date: Thu, 10 Sep 1998 18:26:05 -0400 Message-ID: <17610.905466365@north.lcs.mit.edu> Sender: mjh@north.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >Is it legal to use a dynamic payload type for payloads which have a static >payload ID? If it is, is there a table which gives the official RTPmap >names for the existing static types? I seem to remember that this was the consensus when we talked about it a couple of IETFs ago. >On a related topic, what is the RTPmap name for H.263+? On the assumption that the H.263 payload format goes to historic, probably "H263". Whatever it is, this either needs to be defined in the AV profile document itself, or in the H.263+ payload format document, or separately registered in the MIME-types registry. We still are missing the formal rules for how the MIME-types registry is used for RTP names. Any progress on these Steve, Colin? Cheers, Mark From rem-conf Thu Sep 10 17:22:47 1998 From rem-conf-request@es.net Thu Sep 10 17:22:45 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zHGvq-00071f-00; Thu, 10 Sep 1998 17:19:22 -0700 Received: from acsys.anu.edu.au [150.203.20.41] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zHGvo-00071V-00; Thu, 10 Sep 1998 17:19:21 -0700 Received: from accordion (accordion [150.203.20.58]) by acsys.anu.edu.au (8.9.1/8.9.1) with SMTP id KAA17657; Fri, 11 Sep 1998 10:19:11 +1000 (EST) Message-Id: <3.0.32.19980911101810.00936820@acsys.anu.edu.au> X-Sender: markus@acsys.anu.edu.au X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 11 Sep 1998 10:18:10 +1000 To: Chris Williams , rem-conf@es.net From: Markus Buchhorn Subject: Re: Sept. 16 Berkeley, Multimedia, Interfaces, and Graphics Seminar Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 08:33 10/09/98 -0700, Chris Williams wrote:
    ICEBERG: From POTS to PANS Wednesday September 16, 1998 12:30-2:00 PDT 405 Soda Hall
    <<<<<<<< [...] >>>>
    The seminar is broadcast on the Internet Mbone. The addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202.     <<<<<<<< I would be very keen to see/hear this talk, but there is currently no organised MBONE infrastructure in Australia (although I'm working on that) and no quality international feed (and I'm working on that too ;-)). Would somebody (hopefully close to the source) be able to record (rtpdump) the audio and video and make it available for me to ftp? Thanks for any help ! Much appreciated ! Cheers, Markus Markus Buchhorn, Advanced Computational Systems CRC | Ph: +61 2 62798810 email: markus@acsys.anu.edu.au, snail: ACSys, RSISE Bldg,|Fax: +61 2 62798602 Australian National University, Canberra 0200, Australia |Mobile: 0417 281429 From rem-conf Fri Sep 11 05:23:27 1998 From rem-conf-request@es.net Fri Sep 11 05:23:25 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zHS7F-0004GQ-00; Fri, 11 Sep 1998 05:15:53 -0700 Received: from azure.stl.nps.navy.mil [131.120.64.4] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zHS7E-0004G4-00; Fri, 11 Sep 1998 05:15:52 -0700 Received: from nps.navy.mil (vis140.inria.fr [193.51.208.140]) by azure.stl.nps.navy.mil (8.7.3/8.7.3) with ESMTP id FAA14326 for ; Fri, 11 Sep 1998 05:15:50 -0700 (PDT) Message-ID: <35F8B37F.410EE581@nps.navy.mil> Date: Fri, 11 Sep 1998 07:22:07 +0200 From: Don Brutzman Organization: Naval Postgraduate School X-Mailer: Mozilla 4.06 [en] (WinNT; I) MIME-Version: 1.0 To: AVT working group Subject: [Fwd: ANNOUNCE: Advanced Interactive Content Initiative] Content-Type: multipart/mixed; boundary="------------E4F624251EDF61903C55FE57" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------E4F624251EDF61903C55FE57 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit of possible interest, given recent examination of RTP-MPEG4 interoperablity. regards, Don --------------E4F624251EDF61903C55FE57 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from cs.nps.navy.mil (cs.nps.navy.mil [131.120.1.13]) by azure.stl.nps.navy.mil (8.7.3/8.7.3) with SMTP id AAA07844 for ; Thu, 10 Sep 1998 00:24:03 -0700 (PDT) Received: from mail.nps.navy.mil by cs.nps.navy.mil (4.1/SMI-4.1) id AA22157; Thu, 10 Sep 98 00:23:33 PDT Received: from vrml.org (dev.vrml.org [209.66.78.242]) by mail.nps.navy.mil (8.8.8/8.8.8) with ESMTP id AAA27333 for ; Thu, 10 Sep 1998 00:22:01 -0700 (PDT) Received: (from majordom@localhost) by vrml.org (8.8.8/8.8.5) id AAA15190 for vrml-mpeg4-outgoing; Thu, 10 Sep 1998 00:24:09 -0700 (PDT) Received: from proxy4.ba.best.com (root@proxy4.ba.best.com [206.184.139.15]) by vrml.org (8.8.8/8.8.5) with ESMTP id AAA15169; Thu, 10 Sep 1998 00:23:38 -0700 (PDT) Received: from default (quadramx.vip.best.com [204.156.152.76]) by proxy4.ba.best.com (8.9.0/8.9.0/best.out) with SMTP id AAA23684; Thu, 10 Sep 1998 00:14:01 -0700 (PDT) X-Authentication-Warning: vrml.org: majordom set sender to vrml-mpeg4-approval@vrml.org using -f Message-Id: <000001bddc8a$6043de20$4c989ccc@default> From: "Rob Glidden" To: Cc: , , Subject: ANNOUNCE: Advanced Interactive Content Initiative Date: Thu, 10 Sep 1998 00:08:47 -0700 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: vrml-mpeg4-approval@vrml.org Precedence: list Reply-To: "Rob Glidden" Content-Type: text/plain; charset="iso-8859-1" Please note the formation of the 'Advanced Interactive Content Initiative', or 'AIC Initiative'. Experts from several different communities feel the time and technology are ripe for TV (set top) platforms to offer a range of basic through advanced interactive applications using 3D as well as 2D content, in stored and streamed fashion. Key technologies to be used are Broadcast HTML (BHTML), VRML and MPEG-4. The goal of the initiative is to develop syntax and techniques for integration of BHTML and VRML/BIFS content, and for the use of MPEG-4 for streaming of object-based and BHTML content. Content may be delivered using MPEG-2 or IP transport protocols. The objective is to produce a common specification which undergoes technical review and formal approval by multiple organizations. A charter, requirements document, FAQ, and details are available at: http://toocan.philabs.research.philips.com/misc/aici/ Specifications should be frozen by 20 December 1998. A validation of the specifications in a working software implementation should be completed by 20 March 1999. A mailing list has been established. To join, email to: aici-request@toocan.philabs.research.philips.com In the message body: subscribe aici We look for to your participation in what we hope will be an exciting and important endeavor. Rob --------------E4F624251EDF61903C55FE57-- From rem-conf Fri Sep 11 11:23:47 1998 From rem-conf-request@es.net Fri Sep 11 11:23:46 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zHXe5-0000ZG-00; Fri, 11 Sep 1998 11:10:09 -0700 Received: from humble.net.nih.gov (packet.net.nih.gov) [165.112.130.12] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zHXe4-0000Z4-00; Fri, 11 Sep 1998 11:10:08 -0700 Received: from pearl.dcrt.nih.gov (pearl.dcrt.nih.gov [128.231.200.90]) by packet.net.nih.gov (8.8.5/8.8.5) with SMTP id OAA26404 for ; Fri, 11 Sep 1998 14:09:34 -0400 (EDT) From: Ken Wong Reply-To: kenwong@nih.gov To: rem-conf@es.net Subject: NIH Mbone Lectures Message-ID: Date: Fri, 11 Sep 1998 14:11:36 -0400 (EDT) Priority: NORMAL X-Mailer: Simeon for Solaris Motif Version 4.1.5 Build (43) X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The National Institutes of Health (NIH) will be multicasting live to the Internet Mbone the NIH Wednesday Afternoon Lecture Series (WALS). The WALS features weekly lectures of top medical reseachers and scientists covering a variety of medical related topics. Each lecture is scheduled for Wednesday at 3pm EST. The first scheduled lecture will be on September 16th. Please consult http://www1.od.nih.gov/wals/index.html for the list of scheduled speakers. Please note schedule deviations and bye weeks. Please tune into the session "NIH WALS Lecture." __________________________________________________ "I believe I am the most fortunate sentient in this sector of the galaxy." - Data Ken Wong National Institutes of Health kenwong@nih.gov From rem-conf Fri Sep 11 12:11:52 1998 From rem-conf-request@es.net Fri Sep 11 12:11:52 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zHYZA-0001iE-00; Fri, 11 Sep 1998 12:09:08 -0700 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zHYZ9-0001i4-00; Fri, 11 Sep 1998 12:09:07 -0700 Received: from mailgate.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id MAA43286 for ; Fri, 11 Sep 1998 12:02:44 -0700 Received: from scv3.apple.com (scv3.apple.com) by mailgate.apple.com (mailgate.apple.com - SMTPRS 2.0.15) with ESMTP id ; Fri, 11 Sep 1998 12:02:40 -0700 Received: from [17.255.20.102] (dsinger2.apple.com [17.255.20.102]) by scv3.apple.com (8.8.5/8.8.5) with ESMTP id MAA21768; Fri, 11 Sep 1998 12:02:35 -0700 X-Sender: singer@mail.apple.com Message-Id: In-Reply-To: <17610.905466365@north.lcs.mit.edu> References: "Your message of Thu, 10 Sep 1998 14:48:22 PDT." MIME-Version: 1.0 Date: Fri, 11 Sep 1998 12:00:45 -0700 To: Mark Handley From: Dave Singer Subject: Re: RTP payload type names Cc: rem-conf@es.net Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 6:26 PM -0400 9/10/98, Mark Handley wrote: >>Is it legal to use a dynamic payload type for payloads which have a static >>payload ID? If it is, is there a table which gives the official RTPmap >>names for the existing static types? > >I seem to remember that this was the consensus when we talked about it >a couple of IETFs ago. > >>On a related topic, what is the RTPmap name for H.263+? > >On the assumption that the H.263 payload format goes to historic, >probably "H263". Whatever it is, this either needs to be defined in >the AV profile document itself, or in the H.263+ payload format >document, or separately registered in the MIME-types registry. > The new I-D for H.263+ is not a superset of the old RFC (2190?) and thus we need distinct payload types and/or names for the two. Currently the RFC has the type 34 and the name H263. Seems to me that the new ID had better have no static type and the name H263+. Or am I missing something? David Singer Apple Computer/QuickTime 408-974-3162 From rem-conf Fri Sep 11 12:44:56 1998 From rem-conf-request@es.net Fri Sep 11 12:44:55 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zHZ3n-0002dP-00; Fri, 11 Sep 1998 12:40:47 -0700 Received: from hydra.precept.com [204.162.119.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zHZ3m-0002cR-00; Fri, 11 Sep 1998 12:40:46 -0700 Received: from oak.precept.com (oak.precept.com [204.162.116.21]) by hydra.precept.com (8.8.6/8.8.6) with SMTP id MAA16205; Fri, 11 Sep 1998 12:39:10 -0700 (PDT) Date: Fri, 11 Sep 1998 12:40:12 -0700 (Pacific Daylight Time) From: Stephen Casner To: Dave Singer cc: Mark Handley , rem-conf@es.net Subject: Re: RTP payload type names In-Reply-To: Message-ID: X-X-Sender: casner@big-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Fri, 11 Sep 1998, Dave Singer wrote: > The new I-D for H.263+ is not a superset of the old RFC (2190?) and thus we > need distinct payload types and/or names for the two. Correct. > Currently the RFC has the type 34 and the name H263. Seems to me that the > new ID had better have no static type and the name H263+. Or am I missing > something? Yes, the new ID (and I hope soon it will get through the process to become an RFC) is intended to have no static type assigned. For the name, I suspect something like H263-1998 would be appropriate. Or more specifically, a name that references this particular payload format specification in some way. I say that because trouble arose for the earlier H263 payload format when some implementations of early I-D revisions using the static PT 34 were shipped as products and then later the I-D was updated before publication as an RFC. At the draft stage, if a dynamic payload type is used and is bound to the particular revision of the draft, this problem can be avoided. -- Steve From rem-conf Fri Sep 11 13:53:09 1998 From rem-conf-request@es.net Fri Sep 11 13:53:07 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zHa8t-0003t5-00; Fri, 11 Sep 1998 13:50:07 -0700 Received: from enuxsa.eas.asu.edu [129.219.30.12] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zHa8r-0003sv-00; Fri, 11 Sep 1998 13:50:05 -0700 Received: (from seckin@localhost) by enuxsa.eas.asu.edu (8.8.8/8.8.8) id OAA14532; Fri, 11 Sep 1998 14:00:40 -0700 (MST) Date: Fri, 11 Sep 1998 14:00:39 -0700 (MST) From: gamze To: rem-conf@es.net Subject: Close Caption In-Reply-To: <35F80C21.CE44A298@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Sorry if this topic is already discussed in this list, but I need information on how an additional media can be added to MPEG-2 transport stream (if possible at all). More specifically, how is close captioning handled with MPEG-2 streams ? Thank you, Gamze ---------------------------------------------------------- "Change is inevitable; Progress is optional." K. McMilan Gamze Seckin Department of Computer Science and Engineering College of Engineering and Applied Sciences Arizona State University Box 875406 Phone : (602) 965-1207 Fax : (602) 965-2751 E-mail : gamze@asu.edu From rem-conf Fri Sep 11 17:13:45 1998 From rem-conf-request@es.net Fri Sep 11 17:13:44 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zHdCy-0005sJ-00; Fri, 11 Sep 1998 17:06:32 -0700 Received: from hercules.cs.ucsb.edu [128.111.41.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zHdCw-0005s8-00; Fri, 11 Sep 1998 17:06:30 -0700 Received: from jackson.cs.ucsb.edu (almeroth@jackson [128.111.52.10]) by hercules.cs.ucsb.edu (8.8.6/8.8.6) with ESMTP id RAA07162; Fri, 11 Sep 1998 17:06:29 -0700 (PDT) Received: by jackson.cs.ucsb.edu (8.8.8+Sun/SMI-SVR4) id RAA25723 for ; Fri, 11 Sep 1998 17:06:25 -0700 (PDT) Date: Fri, 11 Sep 1998 17:06:25 -0700 (PDT) From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <199809120006.RAA25723@jackson.cs.ucsb.edu> To: rem-conf@es.net Subject: Exodus doing MBone? Cc: kps@cs.ucsb.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Does anyone know if exodus.net is doing MBone? I sent them an email about multicast support (since UCnet's is now going through them first) but any inside info would probably get me further. On a related note... this change in service provider makes our MBone tunnel pretty inefficient which is why anyone out there looking at the 42nd IETF IMJ content is seeing reasonably poor performance. A new tunnel endpoint will hopefully solve this problem. -Kevin From rem-conf Sat Sep 12 09:42:33 1998 From rem-conf-request@es.net Sat Sep 12 09:42:33 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zHsdw-0004cU-00; Sat, 12 Sep 1998 09:35:24 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0zHsdv-0004cK-00; Sat, 12 Sep 1998 09:35:23 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 12 Sep 1998 17:35:00 +0100 To: Stephen Casner cc: Dave Singer , Mark Handley , rem-conf@es.net Subject: Re: RTP payload type names In-reply-to: Your message of "Fri, 11 Sep 1998 12:40:12 PDT." Date: Sat, 12 Sep 1998 17:34:59 +0100 Message-ID: <3027.905618099@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Stephen Casner writes: >On Fri, 11 Sep 1998, Dave Singer wrote: >> Currently the RFC has the type 34 and the name H263. Seems to me that the >> new ID had better have no static type and the name H263+. Or am I missing >> something? > >Yes, the new ID (and I hope soon it will get through the process to >become an RFC) is intended to have no static type assigned. For the >name, I suspect something like H263-1998 would be appropriate. > >Or more specifically, a name that references this particular payload >format specification in some way. I say that because trouble arose >for the earlier H263 payload format when some implementations of early >I-D revisions using the static PT 34 were shipped as products and then >later the I-D was updated before publication as an RFC. At the draft >stage, if a dynamic payload type is used and is bound to the >particular revision of the draft, this problem can be avoided. H263-RFCxxxx maybe? Or could we use a version parameter when the names are registered as MIME types? "video/h263; version=RFCxxxx"? Colin From rem-conf Sun Sep 13 05:57:26 1998 From rem-conf-request@es.net Sun Sep 13 05:57:24 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zIBY0-0004Yq-00; Sun, 13 Sep 1998 05:46:32 -0700 Received: from mmlab.snu.ac.kr [147.46.114.112] by mail1.es.net with smtp (Exim 1.81 #2) id 0zIBXy-0004Yg-00; Sun, 13 Sep 1998 05:46:30 -0700 Received: from sapphire (sapphire.snu.ac.kr [147.46.15.208]) by mmlab.snu.ac.kr (8.6.12h2/8.6.12) with SMTP id VAA09270 for ; Sun, 13 Sep 1998 21:44:48 +1000 Message-ID: <006201bddf13$5e8b44c0$d00f2e93@sapphire.snu.ac.kr> From: "Yung Yi" To: Subject: Papers about Receiver buffering Date: Sun, 13 Sep 1998 21:38:10 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005F_01BDDF5E.CDBA4B20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_005F_01BDDF5E.CDBA4B20 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 SGkuDQpBcyB5b3Uga25vdywgcmVjZWl2ZXIgYnVmZmVyaW5nIGlzIG5lZWRlZCB0byByZWR1Y2Ug aml0dGVyIGFuZCBjb250aW51ZSBuYXR1cmFsIHBsYXliYWNrIGF0IGF1ZGlvIGFuZCB2aWRlbyBk YXRhIHRyYW5zbWlzc2lvbi4NCkNvdWxkIHlvdSBwbGVhc2UgZ2l2ZSBtZSB0aGUgcG9pbnRlcih3 ZWIgc2l0ZSBvciBwYXBlcnMpIG9uIHRoYXQgaWYgeW91IGtub3c/DQoNCkknbGwgYmUgdmVyeSBn cmF0ZWZ1bCBpZiB5b3UgZG8uDQoNClRoYW5rcy4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogWXVuZyBZaQ0KIE11bHRpbWVkaWEgJiBD b21wdXRlciBDb21tdW5pY2F0aW9uIExhYi4NCiBEZXB0LiBvZiBDb21wdXRlciBFbmdpbmVlcmlu ZywgU2VvdWwgTmF0aW9uYWwgVW5pdi4NCiANCiBUZWwgOiArODItMi04NzYtNzE3MA0KIEZheCA6 ICs4Mi0yLTg3Ni03MTcxDQogRW1haWwgOiB5aXl1bmdAbW1sYWIuc251LmFjLmtyDQogVVJMIDog aHR0cDovL21tbGFiLnNudS5hYy5rci9+eWl5dW5nDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== ------=_NextPart_000_005F_01BDDF5E.CDBA4B20 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBXMyBIVE1MLy9FTiI+DQo8SFRNTD4N CjxIRUFEPg0KDQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9a3NfY181NjAxLTE5 ODciIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0nIk1TSFRNTCA0Ljcy LjMxMTAuNyInIG5hbWU9R0VORVJBVE9SPg0KPC9IRUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZm Pg0KPERJVj48Rk9OVCBzaXplPTI+SGkuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ QXMgeW91IGtub3csIHJlY2VpdmVyIGJ1ZmZlcmluZyBpcyBuZWVkZWQgdG8gcmVkdWNlIGppdHRl ciBhbmQgDQpjb250aW51ZSBuYXR1cmFsIHBsYXliYWNrIGF0IGF1ZGlvIGFuZCB2aWRlbyBkYXRh IHRyYW5zbWlzc2lvbi48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5Db3VsZCB5b3Ug cGxlYXNlIGdpdmUgbWUgdGhlIHBvaW50ZXIod2ViIHNpdGUgb3IgcGFwZXJzKSBvbiANCnRoYXQg aWYgeW91IGtub3c/PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNw OzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SSdsbCBiZSB2ZXJ5IGdyYXRlZnVsIGlmIHlvdSBk by48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9Mj5UaGFua3MuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDAwIA0Kc2l6ZT0yPi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj4m bmJzcDtZdW5nIA0KWWk8QlI+Jm5ic3A7TXVsdGltZWRpYSAmYW1wOyBDb21wdXRlciBDb21tdW5p Y2F0aW9uIExhYi48QlI+Jm5ic3A7RGVwdC4gb2YgDQpDb21wdXRlciBFbmdpbmVlcmluZywgU2Vv dWwgTmF0aW9uYWwgVW5pdi48QlI+Jm5ic3A7PEJSPiZuYnNwO1RlbCA6IA0KKzgyLTItODc2LTcx NzA8QlI+Jm5ic3A7RmF4IDogKzgyLTItODc2LTcxNzE8QlI+Jm5ic3A7RW1haWwgOiA8QSANCmhy ZWY9Im1haWx0bzp5aXl1bmdAbW1sYWIuc251LmFjLmtyIj55aXl1bmdAbW1sYWIuc251LmFjLmty PC9BPjxCUj4mbmJzcDtVUkwgOiANCjxBIA0KaHJlZj0iaHR0cDovL21tbGFiLnNudS5hYy5rci9+ eWl5dW5nIj5odHRwOi8vbW1sYWIuc251LmFjLmtyL355aXl1bmc8L0E+PEJSPi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvRk9OVD48L0RJVj48 L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_005F_01BDDF5E.CDBA4B20-- From rem-conf Sun Sep 13 08:29:09 1998 From rem-conf-request@es.net Sun Sep 13 08:29:08 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zIE0X-0006Xy-00; Sun, 13 Sep 1998 08:24:09 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zIE0W-0006Xo-00; Sun, 13 Sep 1998 08:24:08 -0700 Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA15105; Sun, 13 Sep 1998 11:24:02 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA05792; Sun, 13 Sep 1998 11:24:02 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <35FBE391.5FB83687@cs.columbia.edu> Date: Sun, 13 Sep 1998 11:24:01 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.5b1 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Yung Yi CC: rem-conf@es.net Subject: Re: Papers about Receiver buffering References: <006201bddf13$5e8b44c0$d00f2e93@sapphire.snu.ac.kr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > Yung Yi wrote: > > Hi. > As you know, receiver buffering is needed to reduce jitter and > continue natural playback at audio and video data transmission. > Could you please give me the pointer(web site or papers) on that if > you know? > > I'll be very grateful if you do. Search http://www.cs.columbia.edu/~hgs/netbib for "playout delay" or "playout". From rem-conf Mon Sep 14 04:59:10 1998 From rem-conf-request@es.net Mon Sep 14 04:59:08 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zIX9a-0006rN-00; Mon, 14 Sep 1998 04:50:46 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zIX9Y-0006r3-00; Mon, 14 Sep 1998 04:50:44 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA18508; Mon, 14 Sep 1998 07:49:41 -0400 (EDT) Message-Id: <199809141149.HAA18508@ietf.org> To: IETF-Announce: ; Cc: rem-conf@es.net From: The IESG SUBJECT: Last Call: RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+) to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 14 Sep 1998 07:49:41 -0400 Sender: scoya@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The IESG has received a request from the Audio/Video Transport Working Group to consider RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+) as a Proposed Standard. 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 September 28, 1998. Files can be obtained via ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-rtp-h263-video-02.txt From rem-conf Mon Sep 14 11:55:04 1998 From rem-conf-request@es.net Mon Sep 14 11:55:03 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zIdTV-0003r5-00; Mon, 14 Sep 1998 11:35:45 -0700 Received: from deliverator.sgi.com [204.94.214.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zIdTT-0003qv-00; Mon, 14 Sep 1998 11:35:44 -0700 Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id LAA11127 for <@deliverator.sgi.com:rem-conf@es.net>; Mon, 14 Sep 1998 11:34:04 -0700 (PDT) mail_from (kordale@relic.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) for <@relay.sgi.com:rem-conf@es.net> id LAA01043; Mon, 14 Sep 1998 11:35:36 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA07592 for <@sgi.engr.sgi.com:rem-conf@es.net>; Mon, 14 Sep 1998 11:35:35 -0700 (PDT) mail_from (kordale@relic.engr.sgi.com) Received: from relic.engr.sgi.com (relic.engr.sgi.com [198.29.115.71]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id LAA08635 for <@cthulhu.engr.sgi.com:rem-conf@es.net>; Mon, 14 Sep 1998 11:35:35 -0700 (PDT) mail_from (kordale@relic.engr.sgi.com) Received: (from kordale@localhost) by relic.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA03184; Mon, 14 Sep 1998 11:35:34 -0700 From: "Ram Kordale" Message-Id: <9809141135.ZM3182@relic.engr.sgi.com> Date: Mon, 14 Sep 1998 11:35:33 -0700 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: rem-conf@es.net Subject: Error resilience thru control (RTSP/SDP) not data channel? Cc: kordale@relic.engr.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > From: "M. Reha Civanlar" > To: > Subject: A new I-D: AT&T's Error Resilient Video Transmission Technique > Date: Wed, 29 Jul 1998 15:14:14 -0400 > > A new I-D: "AT&T's Error Resilient Video Transmission Technique" > is now available at: > http://www.ietf.org/internet-drafts/draft-civanlar-hplp-00.txt > > Comments and questions are encouraged. > I was wondering if there was any advantage to sending high priority information (mentioned in the I-D) using the data channel. In our product, we have been sending such high priority information using the control channel when clients open multimedia assets. Thus, before data is streamed through the data channel (using RTP), the client has the necessary data to handle lost packets. Given that DESCRIBE messages in RTSP are designed to provide media specific information, servers could return such high priority information in a response to a DESCRIBE message. Does SDP need to be extended to do this? It appears that one place to return this information in the SDP header is to use the "a=fmtp: attribute. Does this proposal fit the intended usage? Is there another way in SDP to specify this? Thanks. Ram -- Ram Kordale From rem-conf Mon Sep 14 15:28:54 1998 From rem-conf-request@es.net Mon Sep 14 15:28:53 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zIgyQ-0001xv-00; Mon, 14 Sep 1998 15:19:54 -0700 Received: from usr47-dialup42.mix2.atlanta.mci.net ([166.55.62.170] helo=lmlfiq.mci.net) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 0zIgyB-00011V-00; Mon, 14 Sep 1998 15:19:41 -0700 Subject: rem-conf Let Us Pormote Your Site -gdvtutoi From: roger@opusnet.com To: rem-conf@es.net Message-ID: DATE: Fri, 14 Aug 1998 06:19:18 -0500 MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list _____________________________________________________

    rem-conf Removal Instructions can be found at the bottom of this page !

    ______________________________________________________

    Hello rem-conf

    I found your name on this website if you are not the contact for it please foward this to the proper party.

    Your Site Lost in Cyberspace?

    Let our team of Experts Professionally Submit your Web Page for you to as many as 900 Search Engines and Sites. As low as .02 per search engine submission, and have people find you easier than ever on the net so you can do more business.

    .

  • YOUR SITE FOUND BY PEOPLE IN NEED OF YOUR PRODUCT
  • MAKE MORE PROFIT FROM YOUR SITE
  • MORE PEOPLE FINDING YOUR SITE MAKES YOU $$$
  • MISTAKES CAN BE COSTLY. How quickly can you do it?

    We'll start immediately. Submissions are usually completed within 5 working days (Monday to Friday) of receiving your confirmation.

    When will my listings appear?

    Some sites post additions immediately, others may take up to several weeks to process submissions.

    How will I know that the submissions were done?

    Within days of completion we will provide you with a report detailing exactly where your listing was submitted. If you want to, you can easily go to the sites and check for yourself. Although we can not guarantee that all sites will accept your listing (content may not be appropriate) Also, we have carefully selected sites that are likely to accept all submissions.

    What's it going to Cost me?

    Submit to 900 sites Only $25.00 One time Special from this e-mail

    YES! Submit my Web page for me!

    Don't delay a minute longer! If you are serious about doing business on the Internet, this is the most essential step you need to take after getting your pages on-line. Simply fill out our order form fax it in to us and Start building your traffic today!

    ------------------------------CUT HERE-------------------------------------

    SECTION 1: Personal Information

    Your Full Name:__________________________

    Your eMail Address:_________________________

    Your Phone#:_________________________

    Your Fax#:___________________________

    SECTION 3: Submission Information

    Save Time and Delays by following our guidelines closely. If a length limit is exceeded (for example) we will have to ask you to shorten your information - thus delaying the process. Please do not type in ALL CAPS.

    NOTE: Each submission site has different submission forms. We will complete all available fields, however, all of the following information may not be listed at all sites.

    Company or Business name to include in submissions:

    ___________________________________________

    Enter Your Web Page Title:_______________________________

    NOTES: Your title should be no more than 40 CHARACTERS and include good keywords that describe the content of your Web page. Also, if you want it to appear near the top of alphabetically arranged lists and directories try and have the first letter of the title be an "A", "B", or "C" etc. Whatever you do, it should look like it belongs there or it may get chopped of by a site administrator. It doesn't necessarily have to match your actual Web Page title. In our opinion, it is redundant to include words such as "home page", "corporation" or other redundant words that are unlikely to be searched for, or that that unlikely to entice the viewer to click on YOUR title. You have only a few seconds to get a web surfers attention!

    Enter the URL for your Web Page:___________________________________

    NOTE: If you wish to have us submit more than one web page please fill out and submit this form for each individual page (simply fill out the form, submit it, make any necessary changes and submit it again). We can submit any page that has a unique URL.

    Suggest a possible category to place your listings in:

    __________________________________

    Enter a DESCRIPTION of the nature of your Web page (it MUST be 25 WORDS or less). Use good words in your description so that when a directory is searched your listing will be returned. Make sure you include your most important KEYWORDS as only a few sites have a field that allow us to submit KEYWORDS as a separate item. Don't overlook the obvious (computers, software, travel, book, gifts, etc.)!:

    ______________________

    Enter an alternate Short DESCRIPTION of the nature of your Web page (8 WORDS or less). We will use the long description wherever possible:

    ________________________

    Enter up to 20 single KEYWORDS (separated by spaces) that best describe the content of your Web page:

    __________________

    Person's name to include in submissions:

    __________________________

    eMail address to include in submissions:

    __________________________

    Phone number with area code to include in submissions:

    _____________________

    Fax number with area code to include in submissions (RECOMMENDED):

    ________________

    Toll Free 0800 number to include in submissions (if available):

    ____________________________

    Mailing Address to include in submissions:

    _____________________________

    SECTION 3: Payment Information

    Under no circumstances will any work commence

    until a valid form of payment is received!

    NOTE: you can call us in person at our voice or Fax number, OR you may fill out this form, print it out and Fax it to us.

    Lucid Technologies Inc

    5646 Wellesly Pk. Dr.

    Boca Raton, FL 33433

    Our voice number is: 561-347-7304, our Fax number is: 561-347-7304

    Also if you would like your site or product promoted by mass email or wish to buy mass e-mail products please call 561-347-7304

    Method of Payment: We Accept Check by Fax or Credit cards

    If paying by Credit Card we will need the following information

    We accept Visa, Mastercard, Diners Club

    Card Holders Name: _______________________________

    Mailing Address For Credit Card bill:

    Street: _______________________

    ____________________________

    City:_______ State:___________ ZIP:____________

    Card Number_______________________________________________

    EXP DATE________________________

    Signature of card holder

    _______________________________

    To Pay By Check

    Please Print Out this Form Take a blank check write void on it and tape it to this form and fax it back to us and enter your drivers licence number or state id here

    ___________________________________

    Tape Check here

    Fax this form to 561-347-7304

    ------------------------------------------CUT HERE-----------------------

    The Sender Of this E-mail is a Member of the Internet responsible marketers (I.R.M.A) Association #12995

    The Mailing List that you are being mailed from was filtered against

    the Global Remove List at $global

    Remove-List is a free public service offering to help the general public

    get removed from bulk mailings lists and has not sent this message.

    If you want their help please add your name to their list and we you will

    not receive a bulk email from us or any other ethical bulk emailer.

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

    Also if you wish to have your product or service promoted by Bulk mail please call 561-347-7304

    DED):

    ________________ From rem-conf Mon Sep 14 15:28:54 1998 From rem-conf-request@es.net Mon Sep 14 15:28:53 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zIgw4-00002v-00; Mon, 14 Sep 1998 15:17:28 -0700 Received: from chi-dn01-013.il.compuserve.net ([206.175.120.13] helo=hiredhits.com) by mail2.es.net with smtp (Exim 1.92 #1) id 0zIgvz-0007jm-00; Mon, 14 Sep 1998 15:17:24 -0700 DATE: Mon, 14 Sep 1998 17:26:48 -0600 Message-ID: Subject: Independent Price Survey of 175 Life Insurance Companies From: hire@hiredhits.com To: Intelligent_Consumer@es.net MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Visit http://www.hiredhits.com/insurance/ to see the results of a recent independent survey of over 175 life insurance companies. Here is a sample: GUARANTEED MONTHLY PREMIUM FOR $250,000 FOR 10 YEAR TERM: Age Sex Preferred Health Standard Health 25 M $14.14 $17.18 25 F $11.96 $14.36 35 M $14.14 $17.18 35 F $11.96 $14.36 45 M $30.01 $36.68 45 F $20.47 $25.20 55 M $59.72 $77.85 55 F $44.41 $52.88 WE ARE NOT AFFILIATED WITH THE INSURANCE INDUSTRY... .so these are not quotes. We are computer specialists, and we publish information. So take advantage of months of research and development. DON'T TALK TO AN AGENT UNTIL YOU GET THE FACTS http://www.hiredhits.com/insurance/ ************ This message complies with the proposed United States Federal requirements for commercial email bill, Section 301. For additional info see: http://www.senate.gov/murkowski/commercialemail/EMailAmendText.html Required Sender Information: Budget-Term P.O. Box 700832 Plymouth, MI 48170 (734) 207-1873 Mass Email Service Provided by: MasterPromote 120 Broadview Village Square Suite 315 Broadview, IL 60153 773-271-8484 Per Section 301, Paragraph (a)(2)(C) of S. 1618, Further transmissions to you by the sender of this email may be stopped at no cost to you by visiting: http://www.hiredhits.com/ and typing your name in the "remove me!" box on the left of your screen. ************ From rem-conf Mon Sep 14 23:14:46 1998 From rem-conf-request@es.net Mon Sep 14 23:14:45 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zIoIG-0002gv-00; Mon, 14 Sep 1998 23:08:52 -0700 Received: from hydra.precept.com [204.162.119.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zIoIE-0002gd-00; Mon, 14 Sep 1998 23:08:50 -0700 Received: from revelstoke.precept.com (sj-dial-1-1.cisco.com [171.68.180.2]) by hydra.precept.com (8.8.6/8.8.6) with SMTP id XAA02642; Mon, 14 Sep 1998 23:07:47 -0700 (PDT) Date: Mon, 14 Sep 1998 23:13:07 -0700 (PDT) From: Stephen Casner To: rem-conf@es.net cc: "Eric C. Rosen" Subject: AVT WG last call and question on draft-mckay-qcelp-01.txt Message-ID: X-X-Sender: casner@big-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To the AVT working group: At the AVT meeting in Chicago, I said that I would issue a last call for comments within the working group on the RTP payload format for PureVoice audio (draft-mckay-qcelp-01.txt), which I would like to do by this message. The -00 and -01 versions of that document have been out for a while, but haven't received any comments. In the discussion of this draft during the meeting, an issue was raised that I would like to identify in particular. The draft specifies a method for encrypting the voice payload and a bit in the payload header to indicate when the payload is encrypted. In the meeting, we discussed why one might want sometimes to encrypt only the RTP payload and not the headers, so I think the motivation for providing a means to do that was established. However, there was a question raised whether it is appropriate to have a payload-format specific way of indicating encryption when the RTP spec already describes a payload-format-independent mechanism, namely to define a (dynamic) payload type to indicate an encrypted payload format. We did not really resolve that question in the meeting, so I pose it now. Enclosed below is an edited sequence of messages that were exchanged in a side conversation that I repeat here to start the discussion. -- Steve Date: Fri, 11 Sep 1998 16:44:16 +0100 From: Colin Perkins My opinion on the technical issue is that signalling this out-of-band (as an SDP parameter) is more appropriate, since this is a generic solution rather than being specific to this payload format. Of course, this requires us to define an appropriate SDP parameter but that should be a simple addition (and can possibly be done in the A/V profile?). Colin Date: Fri, 11 Sep 1998 09:37:26 -0700 From: "Eric C. Rosen" Colin and Steve, Although I agree that, in general, an out-of-band indication of the encryption algorithm is appropriate, there are some good arguments to consider for allowing a bit to label the media itself as encrypted. There are some applications where distributing a formal SDP session announcement is not practical, but RTP is still preferred for streaming the media. In such cases, it is useful for the endpoints to be able to quickly determine whether the media is encrypted and take application specific action accordingly. Key exchange and encryption algorithm definition would still take place a priori and out-of-band. Certain telephonic switching services may need to treat (i.e. route) encrypted streams differently than clear streams. In this case, listening for and caching session announcements to support high-speed switching of RTP formatted media is impractical, or at least, inconvenient. --Eric Date: Fri, 11 Sep 1998 17:21:18 -0700 (Pacific Daylight Time) From: Stephen Casner Eric, > There are some applications where distributing a formal SDP session > announcement is not practical, but RTP is still preferred for streaming > the media. ... In this case, listening > for and caching session announcements to support high-speed switching of > RTP formatted media is impractical, or at least, inconvenient. When Colin mentioned signaling the use of encryption out-of-band as an SDP parameter, SDP was only stated as an example of out-of-band signaling. Use of RTP does not imply use of SDP, and use of SDP does not imply use of SAP (the announcement protocol). > In such cases, it is useful for the endpoints to be able > to quickly determine whether the media is encrypted and take application > specific action accordingly. Key exchange and encryption algorithm > definition would still take place a priori and out-of-band. Exactly. Some out-of-band signaling mechanism is needed. That signaling also needs to establish the selection of encodings and payload formats to be used, and in the case of dynamic payload types, to establish the binding between payload types and payload formats. This signaling can establish one or more dynamic payload types to indicate the encrypted payload formats. As I mentioned during the AVT meeting, the RTP spec already includes a description of this alternative method of encryption: As an alternative to encryption at the RTP level as described above, profiles may define additional payload types for encrypted encodings. Those encodings must specify how padding and other aspects of the encryption should be handled. This method allows encrypting only the data while leaving the headers in the clear for applications where that is desired. It may be particularly useful for hardware devices that will handle both decryption and decoding. > Certain telephonic switching services may need to treat (i.e. route) > encrypted streams differently than clear streams. It certainly doesn't seem like you'd want those routing decisions to be based on the setting of a bit in the payload-type-specific header. If some other encoding were used, the routing system would need to look for some other indication. The only "advantage" I see in having a bit in the payload header to indicate encryption is that you could easily turn encryption on and off on a packet-by-packet basis. However, this is probably a bad idea anyway, and is contrary to your statement above about special routing. Besides, if you want to have the flexibility to turn the encryption on and off per packet, it was our intention that you'd simply define one (dynamic) payload type to indicate the unencrypted format and another to indicate the encrypted format. RTP allows the payload type to change on the fly (though H.323 may not in all circumstances, and if not, it should be fixed). -- Steve Date: Fri, 11 Sep 1998 17:40:20 -0700 From: "Eric C. Rosen" Steve, Let me bring up one additional point. The RTP payload definition for PureVoice defines extra fields when encryption is active. The bit tells us that the vocoder data is encrypted and that the payload structure has changed to allow for the possible inclusion of cryptosync and crytocheck fields, which are not needed otherwise. Without the 'E' bit accompanying the media, an application receiving RTP encapsulated PureVoice must rely on out-of-band information to determine how to parse the payload. We see this as a potential source for problems. --Eric Date: Sat, 12 Sep 1998 17:30:02 +0100 From: Colin Perkins I'm not sure I understand... Any system which wishes to parse the encrypted data must know the encryption key. When it is told the key for a stream, it will know that the stream has a different format, surely? Colin Date: Sat, 12 Sep 1998 21:37:43 -0700 (PDT) From: Eric Rosen But it may not know a priori that the session is encrypted. Without the bit, the receiver *must* rely on session announcements or something similar. Otherwise, when packets arrive, the receiver won't know how to decode them. Similarly, if the receiver does not know the key or is not expecting encrypted traffic, it should still be able to detect the fact that encrypted traffic is arriving in order to not attempt to treat the packets as clear traffic. --Eric From rem-conf Tue Sep 15 00:28:09 1998 From rem-conf-request@es.net Tue Sep 15 00:28:08 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zIpUk-0003sH-00; Tue, 15 Sep 1998 00:25:50 -0700 Received: from hydra.precept.com [204.162.119.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zIpUi-0003s1-00; Tue, 15 Sep 1998 00:25:48 -0700 Received: from revelstoke.precept.com (sj-dial-1-1.cisco.com [171.68.180.2]) by hydra.precept.com (8.8.6/8.8.6) with SMTP id AAA04031; Tue, 15 Sep 1998 00:24:26 -0700 (PDT) Date: Tue, 15 Sep 1998 00:30:04 -0700 (PDT) From: Stephen Casner To: "Eric C. Rosen" cc: rem-conf@es.net Subject: draft-mckay-qcelp-01.txt question In-Reply-To: <199809130437.VAA02144@nala.qualcomm.com> Message-ID: X-X-Sender: casner@big-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Eric, > The RTP payload definition for PureVoice defines extra fields > when encryption is active. The bit tells us that the vocoder > data is encrypted and that the payload structure has changed > to allow for the possible inclusion of cryptosync and crytocheck > fields, which are not needed otherwise. If the payload structure is different, then using different payload type values for the unencrypted and encrypted cases seems all the more appropriate. > Without the 'E' bit accompanying the media, an application > receiving RTP encapsulated PureVoice must rely on out-of-band > information to determine how to parse the payload. We see this > as a potential source for problems. Indeed it would be a problem, except that the different payload type values would provide the same indication. > But it may not know a priori that the session is encrypted. Without the > bit, the receiver *must* rely on session announcements or something similar. > Otherwise, when packets arrive, the receiver won't know how to decode them. For the encrypted case, you need some a priori communication to supply the key. At the same time, the application is informed what dynamic payload type value will be used to indicate that the data is in the encrypted format. As agreed at the AVT meeting in Los Angeles, a static payload type has been assigned for the unencrypted format, but a dynamic payload type would have worked for that case as well. > Similarly, if the receiver does not know the key or is not expecting > encrypted traffic, it should still be able to detect the fact that > encrypted traffic is arriving in order to not attempt to treat the > packets as clear traffic. Yes. Of course, if the sender uses the wrong payload type value, the receiver is likely to get mighty confused, but the same is true if you send ADPCM data and claim that it is PCM. For the primary RTP encryption scheme in which the entire packet is encrypted, there's enough information tracked by the RTP packet validation procedures to determine whether the (decrypted) packets are valid RTP or not. However, the information in a payload header or in the payload data may not have enough structure to validate it by itself. -- Steve From rem-conf Tue Sep 15 00:58:39 1998 From rem-conf-request@es.net Tue Sep 15 00:58:38 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zIpzC-0004nN-00; Tue, 15 Sep 1998 00:57:18 -0700 Received: from dxmint.cern.ch [137.138.26.76] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zIpz8-0004md-00; Tue, 15 Sep 1998 00:57:14 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch (8.8.8/8.8.8) with SMTP id JAA24709; Tue, 15 Sep 1998 09:52:23 +0200 (MET DST) Received: from localhost by dxcoms.cern.ch (5.65v4.0/1.1.10.5/15Nov97-1020AM) id AA05418; Tue, 15 Sep 1998 09:52:22 +0200 Date: Tue, 15 Sep 1998 09:52:22 +0200 (MET DST) From: Martin Fluckiger To: rem-conf@es.net, hepnet-l@slacvm.slac.stanford.edu, HRC@in2p3.fr, htasc@listbox.cern.ch, net-teleconferencing@listbox.cern.ch, atlas-gen@atlas-lb.cern.ch Subject: MBone broadcast of the CERN ATLAS plenaries (16-18.9.98) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list CERN is pleased to announce the MBONE broadcast of the ATLAS Plenary Meetings ---------------------- from the CERN Auditorium *** Times are UTC+2 *** Wednesday 16 September 1998 --------------------------- 9:00 Introduction and Status - general CERN and LHC matters - MoU - LHCC - goals of this overview week 9:30 The LHC Machine - Short general status - Critical technical issues 10:15 Status of the experimental area 10:45 --- coffee break --- 11:15 Main Issues Entering the Construction Phase - master schedule - milestones, and their follow-up - quality controls - project follow-up 12:00 Electronics Co-ordination 12:45 --- lunch break --- 14:00 Technical Integration of the Overall Detector 15:00 Computing Status I 15:45 --- tea break --- 16:15 Computing Status II 16:45 Trigger, DAQ and DCS Global Overview 17:15 Trigger, DAQ and DCS Status Reports 18:45 End Thursday 17 September 1998 -------------------------- 9:00 Toroid Magnet System - status of B0 - construction schedules - test station and common cryogenics 9:45 Muon Spectrometer Global Overview 10:15 Muon Spectrometer Status Reports 10:45 --- coffee break --- 11:15 Muon spectrometer Status Reports 12:15 --- lunch break --- 14:00 Tile Calorimeter Global Overview 14:30 Tile Calorimeter Status Reports 15:30 --- tea break --- 16:00 LAr cryostats and cryogenics 16:30 LAr System Global Overview 17:00 LAr System Status Reports 18:30 End Friday 18 September 1998 ------------------------ 9:00 Inner Detector Global Overview 9:30 Inner Detector Status Reports 10:30 --- coffee break --- 11:00 Inner Detector Status Reports 11:30 Solenoid 12:00 Conclusions 12:30 End The broadcast is announced via sdr as "CERN ATLAS". vat and vic applications will be used with a ttl of 127. In case of questions or problems please contact: multicast@noc.cern.ch This message is sent to distribution lists, sorry if you receive multiple copies of it. Best regards, -------------------------------------------------------------------- Martin Fluckiger & Christian Isnard CERN - CN/CS/EN multicast@noc.cern.ch European Laboratory for Particle Physics Computers and Networks division CH-1211 Geneva 23 - Switzerland From rem-conf Tue Sep 15 01:46:47 1998 From rem-conf-request@es.net Tue Sep 15 01:46:46 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zIqiE-0005nU-00; Tue, 15 Sep 1998 01:43:50 -0700 Received: from varis.cs.tut.fi (cs.tut.fi) [130.230.4.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zIqiC-0005nJ-00; Tue, 15 Sep 1998 01:43:48 -0700 Received: from harakka.cs.tut.fi (petkos@harakka.cs.tut.fi [130.230.5.4]) by cs.tut.fi (8.8.8/8.8.8) with ESMTP id LAA15259 for ; Tue, 15 Sep 1998 11:43:33 +0300 (EET DST) From: Koskelainen Petri Received: (from petkos@localhost) by harakka.cs.tut.fi (8.8.5/8.8.4) id LAA13514 for rem-conf@es.net; Tue, 15 Sep 1998 11:43:01 +0300 (EET DST) Message-Id: <199809150843.LAA13514@harakka.cs.tut.fi> Subject: Re: Error resilience thru control (RTSP/SDP) not data channel To: rem-conf@es.net Date: Tue, 15 Sep 1998 11:43:00 +0300 (EET DST) X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >Given that DESCRIBE messages in RTSP are designed to provide media >specific information, servers could return such high priority >information in a response to a DESCRIBE message. Does SDP need to be >extended to do this? It appears that one place to return this information >in the SDP header is to use the >"a=fmtp: attribute. > >Does this proposal fit the intended usage? Is there another way in SDP to >specify this? At least it is possible to request some important media-information, e.g. GOP update in H.263. (See "SDP syntax for H.263" draft) Example: a=fmtp 34 GOP-UPDATE=1,3 -- Petri From rem-conf Tue Sep 15 01:46:47 1998 From rem-conf-request@es.net Tue Sep 15 01:46:46 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zIqhp-0005nF-00; Tue, 15 Sep 1998 01:43:25 -0700 Received: from oak.fernuni-hagen.de [132.176.114.41] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zIqho-0005n5-00; Tue, 15 Sep 1998 01:43:24 -0700 Received: from mail.ftk.de (actually ftk1.ftk.de) by oak.fernuni-hagen.de via local-channel with ESMTP; Tue, 15 Sep 1998 10:42:38 +0200 Received: from FTK1/SpoolDir by mail.ftk.de (Mercury 1.21); 15 Sep 98 10:44:06 +0100 Received: from SpoolDir by FTK1 (Mercury 1.21); 15 Sep 98 10:43:37 +0100 Received: from zvi by mail.ftk.de (Mercury 1.21); 15 Sep 98 10:43:30 +0100 Received: by localhost with Microsoft MAPI; Tue, 15 Sep 1998 10:41:43 +0200 Message-ID: <01BDE095.6DF71460.michael.stepping@fernuni-hagen.de> From: "Stepping, Michael" To: 'MPEG-4 Reflector Dmif' , "'MPEG4 Franceschini, Guido'" , 'MPEG4 Zvi Lifshitz' Cc: "rem-conf@es.net" Subject: DAI Callbacks Date: Tue, 15 Sep 1998 10:41:42 +0200 Organization: FTK X-Mailer: Microsoft Internet E-Mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear DMIFers, is it correct, that DMIF is a symmetric delivery mechanism and the DMIF application interface - so called DAI - is also symmetric? If it is, have I correct detected, that there are local DAI-calls and remote DAI-calls (so called CALLBACK) which have different parameters? This indicates a non symmetric DAI - interface. Is this correct? Is it feasable to remove the DAI-CALLBACKs? What will happen, if a remote Application Server tries to add a channel? If I have detected correct, this direction is not implemented in IM1-core code? Michael Stepping ------------------------------------------------------------------------------- Dipl.-Ing. Michael Stepping an der FernUniversitaet-Hagen Lehrgebiet fuer Kommunikationssysteme, Herr Prof. Dr. Kaderali Feithstrasse 142 im TGZ in 58084 Hagen Tel. (0 23 31) 9 87 - 41 04, Fax: - 3 97 EMail: Michael.Stepping@Fernuni-hagen.de Homepage: http://www-kommsys.fernuni-hagen.de/~stepping ------------------------------------------------------------------------------- FTK Research Institute for Telecommunications Image Processing & Multimedia Technology Martin-Schmeisser-Weg 4, D-44227 Dortmund Phone: (02 31) 97 50 56 - 36, Fax: - 10 From rem-conf Tue Sep 15 06:08:14 1998 From rem-conf-request@es.net Tue Sep 15 06:08:13 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zIufN-0000yg-00; Tue, 15 Sep 1998 05:57:09 -0700 Received: from ss3000e.cselt.it [163.162.4.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zIufK-0000xw-00; Tue, 15 Sep 1998 05:57:06 -0700 Received: from rabadan.cselt.stet.it by ss3000e.cselt.stet.it (PMDF V5.1-12 #29348) with ESMTP id <0EZB00GE5T0GFK@ss3000e.cselt.stet.it> for rem-conf@es.net; Tue, 15 Sep 1998 14:50:41 +0200 (MET DST) Received: by rabadan.cselt.stet.it with Internet Mail Service (5.5.1960.3) id ; Tue, 15 Sep 1998 14:52:16 +0200 Content-return: allowed Date: Tue, 15 Sep 1998 14:52:53 +0200 From: Franceschini Guido Subject: RE: DAI Callbacks To: 'MPEG-4 Reflector Dmif' , "'MPEG4 Franceschini, Guido'" , 'MPEG4 Zvi Lifshitz' , "'Stepping, Michael'" Cc: rem-conf@es.net Message-id: <7FC1C9AF63BAD111ADEA0008C728A50F222BA1@xnole.cselt.stet.it> Old-X-Envelope-to: rem-conf@es.net MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Michael, > ---------- > From: Stepping, > Michael[SMTP:michael.stepping@FernUni-Hagen.de] > Sent: Tuesday, September 15, 1998 10:41 AM > To: 'MPEG-4 Reflector Dmif'; 'MPEG4 Franceschini, Guido'; 'MPEG4 Zvi > Lifshitz' > Cc: rem-conf@es.net > Subject: DAI Callbacks > > Dear DMIFers, > > is it correct, that DMIF is a symmetric delivery mechanism and the > DMIF application interface - so called DAI - is also symmetric? quite correct > If it is, have I correct detected, that there are local DAI-calls > and remote DAI-calls (so called CALLBACK) which have different > parameters? > This indicates a non symmetric DAI - interface. Is this correct? No. Symmetry applies to sender/receiver functionalities, not to Delivery Layer/Application Layer functionalities. The terminology adopted indicates with CALLBACK the calls directed from Delivery Layer to Application Layer > Is it feasable to remove the DAI-CALLBACKs? No > What will happen, if a remote Application Server tries to add a > channel? > If I have detected correct, this direction is not implemented in > IM1-core code? Yes. IM1 is not yet a complete implementation of DMIF. > Michael Stepping > > ---------------------------------------------------------------------- > --------- > Dipl.-Ing. Michael Stepping an der FernUniversitaet-Hagen > Lehrgebiet fuer Kommunikationssysteme, Herr Prof. Dr. Kaderali > Feithstrasse 142 im TGZ in 58084 Hagen > Tel. (0 23 31) 9 87 - 41 04, Fax: - 3 97 > EMail: Michael.Stepping@Fernuni-hagen.de > Homepage: http://www-kommsys.fernuni-hagen.de/~stepping > ---------------------------------------------------------------------- > --------- > FTK Research Institute for Telecommunications > Image Processing & Multimedia Technology > Martin-Schmeisser-Weg 4, D-44227 Dortmund > Phone: (02 31) 97 50 56 - 36, Fax: - 10 > > Guido Franceschini > > ------------------------------- > CSELT, Via Reiss Romoli 274 , I-10148 Torino - Italy > Tel + 39 011 228 6137 > Fax + 39 011 228 6190 > Email guido.franceschini@cselt.it From rem-conf Tue Sep 15 10:42:40 1998 From rem-conf-request@es.net Tue Sep 15 10:42:40 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zIz2N-0004UO-00; Tue, 15 Sep 1998 10:37:11 -0700 Received: from pi4.informatik.uni-mannheim.de [134.155.48.125] (-2146555104) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zIz2L-0004UD-00; Tue, 15 Sep 1998 10:37:09 -0700 Received: from localhost (cjk@localhost) by pi4.informatik.uni-mannheim.de (8.8.8/8.8.8) with SMTP id TAA00229; Tue, 15 Sep 1998 19:37:05 +0200 (MET DST) Date: Tue, 15 Sep 1998 19:37:05 +0200 (MET DST) From: Christoph Kuhmuench X-Sender: cjk@pi4 To: rem-conf@es.net, mjh@east.isi.edu cc: Volker Hilt , Martin Mauve Subject: Guidelines for RTP Payload Format specifications? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, We are currently looking into the development of an RTP profile for "interactive media". This profile specifies a foundation for payloads like animations in VRML or Java simulations. In preparation we read the guidelines for writers of RTP payload format specifications (draft-ietf-avt-rtp-format-guidelines-00). The Guideline identifies the following two requirements: o A payload format should be devised so that in the presence of loss, the payload can still be decoded. o Ideally all the contents of every packet should be possible to be decoded and played out irrespective of whether preceding packets have been lost or arrive late. We believe that these two requirements restrict the usage of RTP to audio and video streams. However for "interactive media" we need the functionalities of RTP (e.g. time stamps, sender/ receiver reports, SSRC...). Unfortunatly the nature of interactive media does not permit the complete fulfilment of both requirements. Consider an example application were a VRML world is shared between a number of users. In this scenario the initial state of the world must be transmitted to all participants and following user interaction (events) must be broadcasted. Since events cannot be decoded without having received the world and/or previous events this scenario violates both requirements. It would be very convenient to transmit the inital world and user interaction (events) via reliable multicast beneath RTP. This leads to the following two quetstions: Is it acceptable to specify an RTP payload that does not completely fulfil both requirements? Is it acceptable to specify an RTP payload that requires reliable multicast beneath RTP? Christoph Kuhmuench, Volker Hilt, Martin Mauve From rem-conf Tue Sep 15 11:11:42 1998 From rem-conf-request@es.net Tue Sep 15 11:11:42 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zIzXD-0005KH-00; Tue, 15 Sep 1998 11:09:03 -0700 Received: from north.lcs.mit.edu [18.26.0.4] by mail1.es.net with smtp (Exim 1.81 #2) id 0zIzXC-0005K5-00; Tue, 15 Sep 1998 11:09:02 -0700 Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4) id OAA06063; Tue, 15 Sep 1998 14:08:00 -0400 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Christoph Kuhmuench cc: rem-conf@es.net, Volker Hilt , Martin Mauve Subject: Re: Guidelines for RTP Payload Format specifications? In-reply-to: Your message of "Tue, 15 Sep 1998 19:37:05 +0200." Date: Tue, 15 Sep 1998 14:08:00 -0400 Message-ID: <6061.905882880@north.lcs.mit.edu> Sender: mjh@north.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >The Guideline identifies the following two requirements: > > o A payload format should be devised so that in the presence of > loss, the payload can still be decoded. > > o Ideally all the contents of every packet should be possible to > be decoded and played out irrespective of whether preceding > packets have been lost or arrive late. ... >This leads to the following two quetstions: > >Is it acceptable to specify an RTP payload that does not completely fulfil >both requirements? > >Is it acceptable to specify an RTP payload that requires reliable >multicast beneath RTP? Firstly I should say that the draft in question attempts to provide guidelines but they're not absolute rules. In the case of VRML, it seems you have one protocol for disseminating the world model, and that needs to be reliable. Then you have another protocol for disseminating moving objects (events). This doesn't strictly need to be reliable - if a packet is lost and a subsequent packet contains information that supercedes the first packet, then you don't need reliability as part of the transport protocol. An example is a moving bullet in a wargame, where it's position is sent repeatedly. You don't need every position because if you miss one packet you'll get the new position soon enough, and any retransmitted old positions will arrive too late for playout anyway. The first (world dissemination) protocol doesn't seem to have any benefit from using RTP, whereas the second (real-time update) protocol seems like a good use for RTP. Now the complication comes if you have a reliable-multicast-like protocol for ensuring resynchronization after packet losses when the final packet(s) got lost (like where that bullet finally ended up). Such a protocol has more in common with the world-dissemination protocol than the real-time update protocol. It's also not strictly reliable, because again later events may render earlier information obsolete before reliable transmission to everyone has succeeded. So back to your second question: >Is it acceptable to specify an RTP payload that requires reliable >multicast beneath RTP? It's not clear to me what you mean by "beneath" RTP. It seems what you might have is an RM protocol that runs _over_ RTP. Peter Parnes did some work on SRM over RTP a few years back - you might look at his work. Another possibility is to define a new RTP profile for semi-reliable delivery that defines RTCP packet types for NACK, etc. It seems this might also be usable by a number of people for streaming audio and video from servers, where there is sufficient playout delay for retransmission to take place. Hope this helps, Mark From rem-conf Tue Sep 15 13:24:51 1998 From rem-conf-request@es.net Tue Sep 15 13:24:50 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zJ1XU-0007Eq-00; Tue, 15 Sep 1998 13:17:28 -0700 Received: from humble.net.nih.gov (packet.net.nih.gov) [165.112.130.12] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zJ1XT-0007Eg-00; Tue, 15 Sep 1998 13:17:27 -0700 Received: from pearl.dcrt.nih.gov (pearl.dcrt.nih.gov [128.231.200.90]) by packet.net.nih.gov (8.8.5/8.8.5) with SMTP id QAA16080 for ; Tue, 15 Sep 1998 16:16:53 -0400 (EDT) From: Ken Wong Reply-To: kenwong@nih.gov To: rem-conf@es.net Subject: ORWH Women's Health Seminar on Eating Disorders Message-ID: Date: Tue, 15 Sep 1998 16:18:56 -0400 (EDT) Priority: NORMAL X-Mailer: Simeon for Solaris Motif Version 4.1.5 Build (43) X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This program will be multicasted live onto the Internet Mbone on Wed, Sept 16, from noon-2pm EST. Please tune into the session "NIH ORWH Seminar." Apologies for the late program addition and notice. >Approved-By: nih-staff-moderators@LIST.NIH.GOV >Date: Tue, 8 Sep 1998 10:21:19 -0400 >Reply-To: "ORWH HOME PAGE (OD)" >Sender: Announcements to all NIH Staff >From: "ORWH HOME PAGE (OD)" >Subject: ORWH Women's Health Seminar on Eating Disorders >To: NIH-STAFF@LIST.NIH.GOV > >The NIH Office of Research on Women's Health >Women's Health Seminar Series > >EATING DISORDERS: FADS AND FACTS > >September 16, 1998 > >Noon - 2 p.m. > >Masur Auditorium, Building 10 > > >Overview >Harold Goldstein, Ph.D., NIMH > >The Neurobiology of Eating Disorders >Sarah Leibowitz, Ph.D., Rockefeller University > >The Psychology of Risk Factors: >A Developmental Approach to What Causes Eating Disorders >Ruth H. Striegel-Moore, Ph.D., Wesleyan University > >Overview of Effective Treatments for Eating Disorders >W. Stewart Agras, M.D., Stanford University > >Discussion and Questions > >Presentations are open to the general public. Reservations are not required. >Sign language interpretation will be provided. > > > __________________________________________________ "I believe I am the most fortunate sentient in this sector of the galaxy." - Data Ken Wong National Institutes of Health kenwong@nih.gov From rem-conf Tue Sep 15 16:37:18 1998 From rem-conf-request@es.net Tue Sep 15 16:37:16 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zJ4aA-0001hp-00; Tue, 15 Sep 1998 16:32:26 -0700 Received: from deliverator.sgi.com [204.94.214.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zJ4a9-0001hf-00; Tue, 15 Sep 1998 16:32:25 -0700 Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id QAA09160; Tue, 15 Sep 1998 16:30:48 -0700 (PDT) mail_from (kordale@relic.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id QAA10166; Tue, 15 Sep 1998 16:32:20 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA05493; Tue, 15 Sep 1998 16:32:19 -0700 (PDT) mail_from (kordale@relic.engr.sgi.com) Received: from relic.engr.sgi.com (relic.engr.sgi.com [198.29.115.71]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id QAA02865; Tue, 15 Sep 1998 16:32:18 -0700 (PDT) mail_from (kordale@relic.engr.sgi.com) Received: (from kordale@localhost) by relic.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA04796; Tue, 15 Sep 1998 16:32:17 -0700 From: "Ram Kordale" Message-Id: <9809151632.ZM4794@relic.engr.sgi.com> Date: Tue, 15 Sep 1998 16:32:17 -0700 In-Reply-To: Koskelainen Petri "Re: Error resilience thru control (RTSP/SDP) not data channel" (Sep 15, 11:43am) References: <199809150843.LAA13514@harakka.cs.tut.fi> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Koskelainen Petri , rem-conf@es.net Subject: Re: Error resilience thru control (RTSP/SDP) not data channel Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Sep 15, 11:43am, Koskelainen Petri wrote: > Subject: Re: Error resilience thru control (RTSP/SDP) not data channel > > >Given that DESCRIBE messages in RTSP are designed to provide media > >specific information, servers could return such high priority > >information in a response to a DESCRIBE message. Does SDP need to be > >extended to do this? It appears that one place to return this information > >in the SDP header is to use the > >"a=fmtp: attribute. > > > >Does this proposal fit the intended usage? Is there another way in SDP to > >specify this? > > At least it is possible to request some important media-information, > e.g. GOP update in H.263. (See "SDP syntax for H.263" draft) > ^^^^^^^^^^^^^^^^^^^^^^^^^ Where is such description available. Is this a separate draft? Is there one such draft for MPEG-1 and MPEG-2 format data? Thanks. Ram -- Ram Kordale From rem-conf Wed Sep 16 00:11:51 1998 From rem-conf-request@es.net Wed Sep 16 00:11:50 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zJBeY-0004wv-00; Wed, 16 Sep 1998 00:05:26 -0700 Received: from varis.cs.tut.fi (cs.tut.fi) [130.230.4.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zJBeW-0004wl-00; Wed, 16 Sep 1998 00:05:25 -0700 Received: from harakka.cs.tut.fi (petkos@harakka.cs.tut.fi [130.230.5.4]) by cs.tut.fi (8.8.8/8.8.8) with ESMTP id KAA05277 for ; Wed, 16 Sep 1998 10:05:22 +0300 (EET DST) From: Koskelainen Petri Received: (from petkos@localhost) by harakka.cs.tut.fi (8.8.5/8.8.4) id KAA23847 for rem-conf@es.net; Wed, 16 Sep 1998 10:04:51 +0300 (EET DST) Message-Id: <199809160704.KAA23847@harakka.cs.tut.fi> Subject: Re: RTP payload type names To: rem-conf@es.net Date: Wed, 16 Sep 1998 10:04:50 +0300 (EET DST) X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >Is it legal to use a dynamic payload type for payloads which have a static >payload ID? If it is, is there a table which gives the official RTPmap >names for the existing static types? > >On a related topic, what is the RTPmap name for H.263+? > Another related point, it makes no sense to announce only H.263(+) without any knowledge about the codec options or parameters. In draft http://search.ietf.org/internet-drafts/draft-koskelainen-sdp263-02.txt we have suggested such format for H.263+ SDP syntax using a=fmtp attribute. It seems that static payload type 34 must be changed to dynamic one. So, is the correct form now as follows ? m=video 8888 RTP/AVP 96 a=rtpmap:96 H263-1998 a=fmtp 96 CIF=4 QCIF=2/MaxBR=1000/E F (assuming H263-1998 is the RTPmap name) Thanks, Petri From rem-conf Wed Sep 16 00:11:53 1998 From rem-conf-request@es.net Wed Sep 16 00:11:52 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zJBgJ-0004yg-00; Wed, 16 Sep 1998 00:07:15 -0700 Received: from hydra.precept.com [204.162.119.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zJBgH-0004yE-00; Wed, 16 Sep 1998 00:07:13 -0700 Received: from little-bear.precept.com (little-bear.precept.com [204.162.119.40]) by hydra.precept.com (8.8.6/8.8.6) with SMTP id AAA05429; Wed, 16 Sep 1998 00:04:14 -0700 (PDT) Date: Wed, 16 Sep 1998 00:04:13 -0700 (PDT) From: Stephen Casner X-Sender: casner@little-bear.precept.com To: Mark Handley cc: Christoph Kuhmuench , rem-conf@es.net, Volker Hilt , Martin Mauve Subject: Re: Guidelines for RTP Payload Format specifications? In-Reply-To: <6061.905882880@north.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Tue, 15 Sep 1998, Mark Handley wrote: > It's not clear to me what you mean by "beneath" RTP. It seems what > you might have is an RM protocol that runs _over_ RTP. Peter Parnes did > some work on SRM over RTP a few years back - you might look at his > work. > > Another possibility is to define a new RTP profile for semi-reliable > delivery that defines RTCP packet types for NACK, etc. It seems this > might also be usable by a number of people for streaming audio and > video from servers, where there is sufficient playout delay for > retransmission to take place. For some time, I've thought that adding "variable reliability" to RTP would be a useful enhancement for several applications. We have not undertaken that in AVT because of concerns that reliable multicast protocols should not be undertaken in IETF until the IRTF RM Research Group has made some progress on this topic. -- Steve From rem-conf Wed Sep 16 00:11:53 1998 From rem-conf-request@es.net Wed Sep 16 00:11:53 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zJBkC-0004zG-00; Wed, 16 Sep 1998 00:11:16 -0700 Received: from hydra.precept.com [204.162.119.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zJBkA-0004z5-00; Wed, 16 Sep 1998 00:11:15 -0700 Received: from little-bear.precept.com (little-bear.precept.com [204.162.119.40]) by hydra.precept.com (8.8.6/8.8.6) with SMTP id AAA05520; Wed, 16 Sep 1998 00:10:03 -0700 (PDT) Date: Wed, 16 Sep 1998 00:10:03 -0700 (PDT) From: Stephen Casner X-Sender: casner@little-bear.precept.com To: Ram Kordale cc: rem-conf@es.net Subject: Re: Error resilience thru control (RTSP/SDP) not data channel? In-Reply-To: <9809141135.ZM3182@relic.engr.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Mon, 14 Sep 1998, Ram Kordale wrote: > Given that DESCRIBE messages in RTSP are designed to provide media > specific information, servers could return such high priority > information in a response to a DESCRIBE message. Does SDP need to be > extended to do this? It appears that one place to return this information > in the SDP header is to use the "a=fmtp: > attribute. I believe this fits within the intended usage of fmtp. In the discussions of generic payload formats at AVT meetings in DC and LA, we've talked about putting similar information there. The format has not been nailed down, though. -- Steve From rem-conf Wed Sep 16 00:37:35 1998 From rem-conf-request@es.net Wed Sep 16 00:37:35 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zJC8N-0006qj-00; Wed, 16 Sep 1998 00:36:15 -0700 Received: from stpn.soft.net [204.143.127.2] by mail1.es.net with smtp (Exim 1.81 #2) id 0zJC8K-0006mN-00; Wed, 16 Sep 1998 00:36:14 -0700 Received: from ficon-tech.com (204.143.114.170) by stpn.soft.net (EMWAC SMTPRS 0.80) with SMTP id ; Wed, 16 Sep 1998 13:12:41 +0530 Received: from vikas-bansal.himalaya.com (csipl.csipl.stpn.soft.net [204.143.114.162]) by ficon-tech.com (8.8.7/8.8.7) with SMTP id NAA25717 for ; Wed, 16 Sep 1998 13:08:41 +0530 (IST) (envelope-from vikasb@ficon-tech.com) Message-ID: <008201bde144$6356caa0$bb012d87@vikas-bansal.himalaya.com> From: "Vikas Bansal" To: Subject: Date: Wed, 16 Sep 1998 13:04:01 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list From rem-conf Wed Sep 16 08:47:17 1998 From rem-conf-request@es.net Wed Sep 16 08:47:16 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zJJgt-0004Lp-00; Wed, 16 Sep 1998 08:40:23 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0zJJgN-0004LS-00; Wed, 16 Sep 1998 08:40:22 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 16 Sep 1998 16:39:19 +0100 To: Christoph Kuhmuench cc: rem-conf@es.net, mjh@east.isi.edu, Volker Hilt , Martin Mauve Subject: Re: Guidelines for RTP Payload Format specifications? In-reply-to: Your message of "Tue, 15 Sep 1998 19:37:05 +0200." Date: Wed, 16 Sep 1998 16:39:17 +0100 Message-ID: <1717.905960357@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Christoph Kuhmuench writes: >We are currently looking into the development of an RTP profile for >"interactive media". This profile specifies a foundation for payloads >like animations in VRML or Java simulations. In preparation we read the >guidelines for writers of RTP payload format specifications >(draft-ietf-avt-rtp-format-guidelines-00). [...] This seems like a good opportunity to remind people that we're soliciting feedback from the AVT community to ensure that the "guidelines for writers of RTP payload format specifications" draft accurately reflects real-world experience. I'd encourage everyone to read and comment on this document... Colin From rem-conf Wed Sep 16 13:53:12 1998 From rem-conf-request@es.net Wed Sep 16 13:53:11 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zJOLL-00005p-00; Wed, 16 Sep 1998 13:38:27 -0700 Received: from axl01it.ntc.nokia.com [131.228.118.232] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zJOLH-00005f-00; Wed, 16 Sep 1998 13:38:24 -0700 Received: from miller.americas.nokia.com (miller.americas.nokia.com [172.18.180.20]) by axl01it.ntc.nokia.com (8.8.5/8.6.9) with ESMTP id XAA29163 for ; Wed, 16 Sep 1998 23:35:50 +0300 (EET DST) Received: from rhino.ntc.nokia.com (rhino.americas.nokia.com) by miller.americas.nokia.com with ESMTP (1.39.111.2/16.2) id AA134857987; Wed, 16 Sep 1998 16:33:07 -0400 Received: from Microsoft Mail (PU Serial #1991) by rhino.ntc.nokia.com (PostalUnion/SMTP(tm) v2.1.9c for Windows NT(tm)) id AA-1998Sep16.163000.1991.326207; Wed, 16 Sep 1998 16:33:09 -0400 From: subbiah@NASBPD01BS.ntc.nokia.com (Subbiah Baranitharan NRC/Bos) To: rem-conf@es.net ('rem-conf') Message-Id: <1998Sep16.163000.1991.326207@rhino.ntc.nokia.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Organization: Nokia Telecommunications Date: Wed, 16 Sep 1998 16:33:09 -0400 Subject: Multiplexing in RTP payload X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello all, This is regarding the user multiplexing in RTP payload, which was discussed= = during the last Chicago IETF meeting. To understand this problem more, I = thought the following message could be a starting point. Based on the four proposals presented at the Chicago meeting, it seems to m= e = that there are two different problems need to be solved. 1. Transporting non RTP sources between gateways through multiplexing ( = Lucent and Nokia proposals). 2. Transporting RTP sources through multiplexing (Hitachi and ISI/USC) Is the above assumption acceptable within the working group? Barani Subbiah Nokia Research Center From rem-conf Wed Sep 16 14:32:15 1998 From rem-conf-request@es.net Wed Sep 16 14:32:14 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zJP9L-0001Gv-00; Wed, 16 Sep 1998 14:30:07 -0700 Received: from smtpott1.nortel.ca [192.58.194.78] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zJP9K-0001Gc-00; Wed, 16 Sep 1998 14:30:06 -0700 Received: from zcars00t by smtpott1; Wed, 16 Sep 1998 17:29:07 -0400 Received: from ca.nortel.com by zcars00t.ca.nortel.com id <21386-0@zcars00t.ca.nortel.com>; Wed, 16 Sep 1998 17:19:22 -0400 Date: 16 Sep 1998 17:19 EDT Sender: "Vahe Balabanian" To: subbiah@NASBPD01BS.ntc.nokia.com Cc: rem-conf@es.net From: "Vahe Balabanian" Subject: re:Multiplexing in RTP payload Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In message "Multiplexing in RTP payload", subbiah@NASBPD01BS.ntc.nokia.com writes: > >Hello all, > > >This is regarding the user multiplexing in RTP payload, which was discussed= > = >during the last Chicago IETF meeting. To understand this problem more, I = >thought the following message could be a starting point. > >Based on the four proposals presented at the Chicago meeting, it seems to = >= >me that there are two different problems need to be solved. > >1. Transporting non RTP sources between gateways through multiplexing = > (Lucent and Nokia proposals). > >2. Transporting RTP sources through multiplexing (Hitachi and ISI/USC) > >Is the above assumption acceptable within the working group? > My reading was that the 2nd solution was going to be effectively encompassing the first. Only one solution would be required for interoperability reasons. Vahe Nortel From rem-conf Wed Sep 16 14:32:15 1998 From rem-conf-request@es.net Wed Sep 16 14:32:14 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zJP9J-0001Gi-00; Wed, 16 Sep 1998 14:30:05 -0700 Received: from north.lcs.mit.edu [18.26.0.4] by mail1.es.net with smtp (Exim 1.81 #2) id 0zJP9I-0001GX-00; Wed, 16 Sep 1998 14:30:04 -0700 Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4) id RAA08828; Wed, 16 Sep 1998 17:24:07 -0400 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: subbiah@NASBPD01BS.ntc.nokia.com (Subbiah Baranitharan NRC/Bos) cc: rem-conf@es.net ('rem-conf') Subject: Re: Multiplexing in RTP payload In-reply-to: Your message of "Wed, 16 Sep 1998 16:33:09 EDT." <1998Sep16.163000.1991.326207@rhino.ntc.nokia.com> Date: Wed, 16 Sep 1998 17:24:07 -0400 Message-ID: <8826.905981047@north.lcs.mit.edu> Sender: mjh@north.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >Based on the four proposals presented at the Chicago meeting, it seems to me >that there are two different problems need to be solved. > >1. Transporting non RTP sources between gateways through multiplexing ( >Lucent and Nokia proposals). > >2. Transporting RTP sources through multiplexing (Hitachi and ISI/USC) > >Is the above assumption acceptable within the working group? In the short term, you might view them as different. In the longer term though, they're the same problem. Some of the sources in 1. might eventually become RTP sources, or some of the sinks might become RTP sinks. Also a type-1 gateway might end up talking to a type-2 gateway. So I view them as really different aspects of the same problem. Cheers, Mark From rem-conf Thu Sep 17 00:29:15 1998 From rem-conf-request@es.net Thu Sep 17 00:29:13 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zJYOg-0007bz-00; Thu, 17 Sep 1998 00:22:34 -0700 Received: from mmlab.snu.ac.kr [147.46.114.112] by mail1.es.net with smtp (Exim 1.81 #2) id 0zJYOd-0007bp-00; Thu, 17 Sep 1998 00:22:31 -0700 Received: from s4 ([147.46.15.31]) by mmlab.snu.ac.kr (8.6.12h2/8.6.12) with SMTP id QAA16607 for ; Thu, 17 Sep 1998 16:20:45 +1000 Message-ID: <004f01bde20c$0cb1b660$1f0f2e93@s4.snu.ac.kr> From: "Youngseok Lee" To: Subject: Collecting Audio & Video packets ? Date: Thu, 17 Sep 1998 16:23:20 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004C_01BDE257.7BE24360" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_004C_01BDE257.7BE24360 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 SGVsbG8uDQpJIGhhdmUgYSBxdWVzdGlvbiBhYm91dCBmaW5kaW5nIG91dCBhdWRpbyBhbmQgdmlk ZW8gcGFja2V0cyBmcm9tIG90aGVycy4NCldlIGFyZSBkb2luZyB0cmFmZmljIG1lYXN1cmVtZW50 IHVzaW5nIENpc2NvIHJvdXRlciwgTmV0RmxvdyBhbmQgYW5hbHl6aW5nIHRoZW0uDQpBbW9uZyBh bGwgdGhlIHRyYWZmaWMgd2UgYXJlIGVzcGVjaWFsbHkgaW50ZXJlc3RlZCBpbiBhdWRpbyBhbmQg dmlkZW8gdHJhZmZpYy4NCkJ1dCBpdCBzZWVtcyB0aGF0IHRoZXJlIGFyZSBub3QgYW55IHN5c3Rl bWF0aWMgbWV0aG9kLg0KRm9yIGV4YW1wbGUgd2UgdXNlZCB0aGUgcG9ydCBpbmZvcm1hdGlvbiB0 byB0ZWxsIHRoZSBhdWRpbyBvciB2aWRlbyB0cmFmZmljIGZyb20gb3RoZXJzLg0KOyB0aGUgUmVh bEF1ZGlvIGFwcGxpY2F0aW9uIHVzZXMgYSBVRFAgcG9ydCBiZXR3ZWVuIDYxNzAgLTcxNzAuDQpJ ZiBJIHNob3VsZCB1c2UgdGhlIHBvcnRzIGluZm9ybWF0aW9uIHRvIGNvbGxlY3QgYWxsIHRoZSBh dWRpbyBvciB2aWRlbyB0cmFmZmljLCBhbnlvbmUgY2FuIHRlbGwgdGhlIHBvcnRzIGluZm9ybWF0 aW9uIGZvciB0aGVzZSBtdWx0aW1lZGlhIGFwcGxpY2F0aW9uID8NCkFueSBjb21tZW50LCBwbGVh c2UuDQpUaGFua3MgaW4gYWR2YW5jZS4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCllvdW5nc2VvayBMZWUNCg0KMTUxLTc0Mg0KTXVsdGlt ZWRpYSBDb21tdW5jYXRpb24gTGFiLiANCkRlcHQuIG9mIENvbXB1dGVyIEVuZy4gU2VvdWwgTmF0 aW9uYWwgVW5pdi4sIEtvcmVhDQoNCm1haWx0bzp5c2xlZUBtbWxhYi5zbnUuYWMua3INCmh0dHA6 Ly9tbWxhYi5zbnUuYWMua3IvfnlzbGVlDQpQaG9uZSArODItMi04NzYtNzE3MA0KRmF4ICs4Mi0y LTg3Ni03MTcNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo= ------=_NextPart_000_004C_01BDE257.7BE24360 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBXMyBIVE1MLy9FTiI+DQo8SFRNTD4N CjxIRUFEPg0KDQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9a3NfY181NjAxLTE5 ODciIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0nIk1TSFRNTCA0Ljcy LjMxMTAuNyInIG5hbWU9R0VORVJBVE9SPg0KPC9IRUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZm Pg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mj5IZWxsby48L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9Mj5JIGhhdmUgYSBxdWVzdGlvbiBhYm91dCBmaW5kaW5nIG91dCBhdWRp byBhbmQgdmlkZW8gcGFja2V0cyANCmZyb20gb3RoZXJzLjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPldlIGFyZSBkb2luZyB0cmFmZmljIG1lYXN1cmVtZW50IHVzaW5nIENpc2NvIHJv dXRlciwgTmV0RmxvdyANCmFuZCBhbmFseXppbmcgdGhlbS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIHNpemU9Mj5BbW9uZyBhbGwgdGhlIHRyYWZmaWMgd2UgYXJlIGVzcGVjaWFsbHkgaW50ZXJl c3RlZCBpbiBhdWRpbyANCmFuZCB2aWRlbyB0cmFmZmljLjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPkJ1dCBpdCBzZWVtcyB0aGF0IHRoZXJlIGFyZSBub3QgYW55IHN5c3RlbWF0aWMg DQptZXRob2QuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Rm9yIGV4YW1wbGUgd2Ug dXNlZCB0aGUgcG9ydCBpbmZvcm1hdGlvbiB0byB0ZWxsIHRoZSBhdWRpbyBvciANCnZpZGVvIHRy YWZmaWMgZnJvbSBvdGhlcnMuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+OyB0aGUg UmVhbEF1ZGlvIGFwcGxpY2F0aW9uIHVzZXMgYSBVRFAgcG9ydCBiZXR3ZWVuIDYxNzAgDQotNzE3 MC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5JZiBJIHNob3VsZCB1c2UgdGhlIHBv cnRzIGluZm9ybWF0aW9uIHRvIGNvbGxlY3QgYWxsIHRoZSBhdWRpbyANCm9yIHZpZGVvIHRyYWZm aWMsIGFueW9uZSBjYW4gdGVsbCB0aGUgcG9ydHMgaW5mb3JtYXRpb24gZm9yIHRoZXNlIG11bHRp bWVkaWEgDQphcHBsaWNhdGlvbiA/PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+QW55 IGNvbW1lbnQsIHBsZWFzZS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5UaGFua3Mg aW4gYWR2YW5jZS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+PEZPTlQgY29sb3I9IzAwMDAwMCANCnNp emU9Mj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LTxCUj5Zb3VuZ3Nlb2sgDQpMZWU8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAw MDAgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDAwMCBz aXplPTI+MTUxLTc0MjxCUj5NdWx0aW1lZGlhIENvbW11bmNhdGlvbiBMYWIuIA0KPEJSPkRlcHQu IG9mIENvbXB1dGVyIEVuZy4gU2VvdWwgTmF0aW9uYWwgVW5pdi4sIEtvcmVhPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0yPjxBIA0KaHJlZj0ibWFpbHRvOnlzbGVlQG1t bGFiLnNudS5hYy5rciI+bWFpbHRvOnlzbGVlQG1tbGFiLnNudS5hYy5rcjwvQT48QlI+PEEgDQpo cmVmPSJodHRwOi8vbW1sYWIuc251LmFjLmtyL355c2xlZSI+aHR0cDovL21tbGFiLnNudS5hYy5r ci9+eXNsZWU8L0E+PEJSPlBob25lIA0KKzgyLTItODc2LTcxNzA8QlI+RmF4IA0KKzgyLTItODc2 LTcxNzxCUj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLTwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_004C_01BDE257.7BE24360-- From rem-conf Thu Sep 17 02:09:23 1998 From rem-conf-request@es.net Thu Sep 17 02:09:21 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zJZx3-00019d-00; Thu, 17 Sep 1998 02:02:09 -0700 Received: from tuminfo2.informatik.tu-muenchen.de [131.159.0.81] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zJZx2-00019T-00; Thu, 17 Sep 1998 02:02:08 -0700 Received: from hpschlichter8.informatik.tu-muenchen.de ([131.159.24.23] EHLO hpschlichter8.informatik.tu-muenchen.de ident: root [port 1114]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <110122-215>; Thu, 17 Sep 1998 11:01:58 +0000 Received: from sgijhs3.informatik.tu-muenchen.de ([131.159.24.35]) by hpschlichter8.informatik.tu-muenchen.de with SMTP id <102627-387>; Thu, 17 Sep 1998 11:01:40 +0100 Date: Thu, 17 Sep 1998 11:01:30 +0200 (MESZ) From: Daniel Koehler To: rem-conf@es.net Subject: Anybody tried vic with SGI Octane and Personal Video? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, hope i got the right list :-) Did anyone already try wether vic 2.8 works with SGI Octane and Personal Video option ??? Thanks, Daniel From rem-conf Thu Sep 17 06:32:29 1998 From rem-conf-request@es.net Thu Sep 17 06:32:27 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zJe0a-0003hC-00; Thu, 17 Sep 1998 06:22:04 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0zJe0Y-0003h2-00; Thu, 17 Sep 1998 06:22:02 -0700 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Sep 17 09:20:13 EDT 1998 Received: from dnrc.bell-labs.com (jdrosen.lra.lucent.com [135.17.251.232]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id JAA21202; Thu, 17 Sep 1998 09:20:29 -0400 (EDT) Message-ID: <36010D30.9D99B9D8@dnrc.bell-labs.com> Date: Thu, 17 Sep 1998 09:22:56 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Subbiah Baranitharan NRC/Bos CC: "'rem-conf'" Subject: Re: Multiplexing in RTP payload References: <1998Sep16.163000.1991.326207@rhino.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Subbiah Baranitharan NRC/Bos wrote: > > Hello all, > > This is regarding the user multiplexing in RTP payload, which was discussed during the last Chicago IETF meeting. To understand this problem more, I thought the following message could be a starting point. > > Based on the four proposals presented at the Chicago meeting, it seems to me that there are two different problems need to be solved. > > 1. Transporting non RTP sources between gateways through multiplexing ( Lucent and Nokia proposals). > > 2. Transporting RTP sources through multiplexing (Hitachi and ISI/USC) > > Is the above assumption acceptable within the working group? I think there was consensus that there were these two problems, but not really consensus that there should be one or two solutions. Mark's proposal was to do something that solves both, though, not just #2. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Thu Sep 17 06:44:53 1998 From rem-conf-request@es.net Thu Sep 17 06:44:52 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zJeEy-00041O-00; Thu, 17 Sep 1998 06:36:56 -0700 Received: from axl01it.ntc.nokia.com [131.228.118.232] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zJeEx-00041B-00; Thu, 17 Sep 1998 06:36:55 -0700 Received: from miller.americas.nokia.com (miller.americas.nokia.com [172.18.180.20]) by axl01it.ntc.nokia.com (8.8.5/8.6.9) with ESMTP id QAA00392 for ; Thu, 17 Sep 1998 16:36:27 +0300 (EET DST) Received: from rhino.ntc.nokia.com (rhino.americas.nokia.com) by miller.americas.nokia.com with ESMTP (1.39.111.2/16.2) id AA152499221; Thu, 17 Sep 1998 09:33:41 -0400 Received: from Microsoft Mail (PU Serial #1991) by rhino.ntc.nokia.com (PostalUnion/SMTP(tm) v2.1.9c for Windows NT(tm)) id AA-1998Sep17.092900.1991.326967; Thu, 17 Sep 1998 09:33:43 -0400 From: subbiah@NASBPD01BS.ntc.nokia.com (Subbiah Baranitharan NRC/Bos) To: rem-conf@es.net ('rem-conf') Message-Id: <1998Sep17.092900.1991.326967@rhino.ntc.nokia.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Organization: Nokia Telecommunications Date: Thu, 17 Sep 1998 09:33:43 -0400 Subject: FW: re:Multiplexing in RTP payload X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ------------ From: Vahe Balabanian To: Subbiah Baranitharan (NRC/Bos) Cc: rem-conf Subject: re:Multiplexing in RTP payload Date: Wednesday, September 16, 1998 5:19PM In message "Multiplexing in RTP payload", subbiah@NASBPD01BS.ntc.nokia.com writes: > >Hello all, > > >This is regarding the user multiplexing in RTP payload, which was = discussed=3D > =3D >during the last Chicago IETF meeting. To understand this problem more, I = =3D >thought the following message could be a starting point. > >Based on the four proposals presented at the Chicago meeting, it seems to = =3D >=3D >me that there are two different problems need to be solved. > >1. Transporting non RTP sources between gateways through multiplexing =3D > (Lucent and Nokia proposals). > >2. Transporting RTP sources through multiplexing (Hitachi and ISI/USC) > >Is the above assumption acceptable within the working group? > My reading was that the 2nd solution was going to be effectively encompassing the first. Only one solution would be required for interoperability reasons. Vahe Nortel ---------------------------------------- Thanks for the comments. For various reasons I think the second solution is not suitable for the = first one. To start with: 1. Why we need to convert a non RTP source speech packet into a RTP packet = = and then multiplex when the source and destination does not use the header = info. 2. In my view the bottleneck is in the access links. If a RTP source is abl= e = send a packet without any problem in the access link then I don't see why we= = need to multiplex them. I rather use the RTP/UDP/IP header compression from = = the source so that there is no complex multiplexing to save bandwidth = between gateways. 3. The efficiency proposed in the second method is equal or better only whe= n = gateway co-operates. But preliminary studies have indicated that this is not= = the case. We need to use atleast 5 bytes when there is multiple codecs = between multiplexing end points. I am referring to Mark Handly's proposal ( = = CID=3D8, SN, PT are needed and rest can be compressed). 4. In a mobile environment there are multiple codecs and as the trend = continues, majority of the calls will be between mobile users. I am not sure= = if it is advantages to use RTP over the air interface for speech only calls.= = Even if the remote is a RTP source these things can be taken care at some = gateway. 5. There is a need for intermediate switching (multiplexing and = demultiplexing) so that overhead can be kept low on the entire transport. If= = compression is applied then it adds further processing overhead and delays. I understand the need for a single solution. However, my proposal would be 1. For RTP sources --- use RTP/UDP/IP header compression from the source 2. For non RTP sources - Multiplex between gateways as much as possible. Your comments are welcome. Best regards, Barani Subbiah From rem-conf Thu Sep 17 08:59:23 1998 From rem-conf-request@es.net Thu Sep 17 08:59:22 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zJgKB-0006YM-00; Thu, 17 Sep 1998 08:50:27 -0700 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zJgKA-0006YC-00; Thu, 17 Sep 1998 08:50:26 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id IAA29618; Thu, 17 Sep 1998 08:50:26 -0700 (PDT) Message-Id: <3.0.3.32.19980917085024.00a6b9b0@gumby.cs.berkeley.edu> X-Sender: cwilliams@gumby.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 17 Sep 1998 08:50:24 -0700 To: (Recipient list suppressed) From: Chris Williams Subject: 9/23 Berkeley, Multimedia, Interfaces, and Graphics Seminar Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list

    Electronic Notebooks for Scientific Collaborative Work
    Sonia Sachs Lawrence Berkeley Laboratories Wednesday September 23, 1998 12:30-2:00 PDT 405 Soda Hall
    Paper notebooks are regularly used by scientists, engineers, and technicians to keep records of their observations, analysis and conclusions. As researchers remotely collaborate in performing experiments, controlling instruments of on-line facilities, designing large-scale systems, or in a variety of laboratory and scientific discovery processes, they face the management of large amounts of data, personal paper notebooks, electronic mail, phone conferencing discussions, and collections of documents and multimedia files. In addition, collaborating researchers may use collected data to produce images and plots that are shared with colleagues in discussions of obtained results. Electronic notebooks are used to capture, store, and manage a variety of data obtained through data acquisition and data analysis processes. In collaborative work, electronic notebooks offer remote collaborators the capability of sharing data and of creating annotations on the shared data, both synchronously and asynchronously. Electronic notebooks are also important in collaborative work because they are used to manage the persistent historical record of group discussions, meetings, decisions, and conclusions reached by project team members. Moreover, electronic notebooks enhance science and engineering inquiry processes by providing powerful searching capabilities of diverse database information related to a collaborative project. In this talk we will summarize the main ideas regarding electronic notebooks for collaborative work, review related work, and then focus on the development of an experimental electronic notebook for the Spectro-Microscopy Collaboratory at the Advanced Light Source (ALS) in LBNL. We will discuss the architecture of the electronic notebook system, its current implementation, lessons learned, and future directions. The slides for this seminar are available for viewing at http://www-itg.lbl.gov/~ssachs/TALKS.dir/UCB.dir/ppframe.htm. The MBone addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202. ____________________________________________ Chris Williams Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: cwilliams@bmrc.berkeley.edu From rem-conf Thu Sep 17 21:08:47 1998 From rem-conf-request@es.net Thu Sep 17 21:08:46 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zJrhv-0005Em-00; Thu, 17 Sep 1998 20:59:43 -0700 Received: from sirius.ctr.columbia.edu [128.59.64.60] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zJrht-0005Ec-00; Thu, 17 Sep 1998 20:59:41 -0700 Received: from comet.columbia.edu (sweetpea.comet.columbia.edu [128.59.68.61]) by sirius.ctr.columbia.edu (8.9.1/8.6.4.287) with ESMTP id XAA29259; Thu, 17 Sep 1998 23:59:33 -0400 (EDT) Message-ID: <360206A6.8B86820F@comet.columbia.edu> Date: Fri, 18 Sep 1998 00:07:18 -0700 From: Andrew Campbell Reply-To: campbell@comet.columbia.edu Organization: Center for Telecommunications Research X-Mailer: Mozilla 4.5b1 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: testnet@canarie.ca, multicomm@Research.Panasonic.COM, hipparch@sophia.inria.fr, rem-conf@es.net Subject: HOT OPENSIG'98 PROGRAM Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list OPENSIG '98 Workshop Open Signaling for ATM, Internet and Mobile Networks October 5-6 1998, University of Toronto, Toronto, Ontario http://www.comet.columbia.edu/opensig/activities/opensig98.html ------------------------------------------ P R O G R A M A T A G L A N C E ------------------------------------------ KEYNOTE on Geoplex PANEL on Industry's View of Open Signaling SIX SESSIONS: -Views of Differentiated Services -Enabling Virtual Networking -Active Network Interfaces -Programmable Network Management -OPEN Session -Mobile Agents and Open Signaling ---------------------------------------------------- F U L L P R O G R A M A T A G L A N C E ---------------------------------------------------- Program: First Day, October 5th, 1998 Welcoming Remarks Irene Katzela, University of Toronto Session 1 - Enabling Virtual Networking Organizer and Chair: Andrew T. Campbell, Columbia University 1. Paul Ferguson, Cisco, What is a VPN ? 2. John Vincente, Intel and Columbia University, Towards Programmable Virtual Networking 3. Ken Calvert, University of Kentucky, Composing Services in CANES 4. Jens-Peter Redlich, NEC, How Virtual Networks can support QoS-sensitive Internet Applications 5. Anindo Banarjea, ISI, The XBONE: Building Overlay Networks Session 2 - Active Network Interfaces Organizer and Chair: Ken Calvert, University of Kentucky 1. Bob Braden, ISI , Active Reservation Protocol 2. Dan Nessett, 3Com, Experience with Java on a Router 3. Andy Bavier, Princeton University, The Scout/Jout Active Network Node Session 3 - Programmable Network Management Organizer and Chair: Gisli Hjalmtysson, AT&T Research 1. Pawan Goyal, AT&T - Research, PRONTO: A Platform for Programmable Networking 2. Yuval Shavitt, Lucent Bell Labs, An Active Network Approach to Efficient Network Management 3. Dan Ionescu, University of Ottawa, A Corba Environment for Network Management Session 4 - OPEN Session Chair: Nikos Anerousis, AT&T Labs Want a 15 minute slots to voice an opinion? Then contact Nikos for on-demand reservation at nikos@research.att.com 1. Andrew T. Campbell, Columbia University, "Open" Wireless Plaforms: Why Bother? 2. Jit Biswas, Kentridge Labs, Secretary, IEEE P1520 Working Group, IEEE Programming Interfaces for Networks (to be confirmed) 3. Radhakrishna Pillai, Kentridge Labs, Mobile Binding Interface Base OPENSIG Reception - Faculty House Program: Second Day, October 6th, 1998 Keynote Address Session Chair: Aurel A. Lazar, Columbia University and Xbind Inc. Nelu Mihai, AT&T West Labs, On Geoplex Session 5 - Views of Differentiated Services Organizer and Chair: Kathleen Nichols, Cisco *to be on mbone* 1. John Wroclawski, MIT, Diff Services: Magic Bullet or Cure for Cancer ? 2. Yoram Bennet, Microsoft, No title (to be confirmed) 3. Fran Reichmeyer, Bay Networks, Two-Tier Resource Management 4. Scott Bradner, Harvard University, No Title Yet (to be confirmed) 5. Kathleen Nichols, Cisco, Using Differentiated Services Session 6 - Industry's View of Open Signaling Organizer and Chair: Al. Leon-Garcia, University of Toronto Panelists: SBC, ATT, Nortel, Newbridge Session 7 - Mobile Agents and Open Signaling Organizer and Chair: Roger Imprey, NRC 1. Hermann de Meer, U. of Hamburg and Columbia Univeristy, Tunnel Agents for QoS Enhancement in the Internet Other Speakers to be confirmed 17:30 Closing Remarks and OPENSIG'99 Announcement For further information please send email to opensig@comm.utoronto.edu ------------------------------------------------- Organizing Committee: ------------------------------------------------- Irene Katzela, Chair, (University of Toronto) Anindo Banerjea (ISI) Andrew Campbell (Columbia University) Kitty Chan, Local Arrangements, (University of Toronto) Raymond Liao, Webmaster, (Columbia University) ------------------------------------------------- Program Committee: ------------------------------------------------- Anindo Banerjea (ISI), Andrew T. Campbell (Columbia University) Simon Crosby (University of Cambridge and CPlane Inc.) Irene Katzela (University of Toronto) Aurel A. Lazar (Columbia University) and Xbind Inc.) Ian Leslie (University of Cambridge and CPlane Inc.) ------------------------------------------------- -- Andrew T. Campbell http://comet.columbia.edu/~campbell From rem-conf Fri Sep 18 06:38:07 1998 From rem-conf-request@es.net Fri Sep 18 06:38:06 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zK0bh-0002P9-00; Fri, 18 Sep 1998 06:29:53 -0700 Received: from mail.jlu.edu.cn [202.198.16.5] by mail1.es.net with smtp (Exim 1.81 #2) id 0zK0bN-0002Oz-00; Fri, 18 Sep 1998 06:29:44 -0700 Received: from dcs.jlu.edu.cn by mail.jlu.edu.cn (SMI-8.6/SMI-SVR4) id VAA10153; Fri, 18 Sep 1998 21:38:34 -0800 Message-ID: <3602609C.3092A1F4@dcs.jlu.edu.cn> Date: Fri, 18 Sep 1998 21:31:08 +0800 From: zhangke Reply-To: zk@dcs.jlu.edu.cn Organization: DCS of JiLin University X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: (no subject) Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list help From rem-conf Fri Sep 18 09:57:18 1998 From rem-conf-request@es.net Fri Sep 18 09:57:17 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zK3bT-0004aO-00; Fri, 18 Sep 1998 09:41:51 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0zK3bR-0004aE-00; Fri, 18 Sep 1998 09:41:49 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 18 Sep 1998 17:41:40 +0100 To: Koskelainen Petri cc: rem-conf@es.net Subject: Re: RTP payload type names In-reply-to: Your message of "Wed, 16 Sep 1998 10:04:50 +0300." <199809160704.KAA23847@harakka.cs.tut.fi> Date: Fri, 18 Sep 1998 17:41:39 +0100 Message-ID: <11105.906136899@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Koskelainen Petri writes: >Another related point, it makes no sense to announce only H.263(+) >without any knowledge about the codec options or parameters. >In draft >http://search.ietf.org/internet-drafts/draft-koskelainen-sdp263-02.txt >we have suggested such format for H.263+ SDP syntax using a=fmtp attribute. > >It seems that static payload type 34 must be changed to dynamic one. >So, is the correct form now as follows ? > >m=video 8888 RTP/AVP 96 >a=rtpmap:96 H263-1998 >a=fmtp 96 CIF=4 QCIF=2/MaxBR=1000/E F > >(assuming H263-1998 is the RTPmap name) I don't know enough about H.263 to comment on the parameters you're passing on the a=fmtp line, but the basic idea is correct for H.263+ streams If using H.263 with the old packetisation scheme, you would announce m=video 8888 RTP/AVP 34 a=fmtp 34 ... to give parameters for the codec. No dynamic payload type is needed in this case. Colin From rem-conf Fri Sep 18 10:37:46 1998 From rem-conf-request@es.net Fri Sep 18 10:37:45 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zK4O3-0005er-00; Fri, 18 Sep 1998 10:32:03 -0700 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zK4O2-0005ed-00; Fri, 18 Sep 1998 10:32:02 -0700 Received: from mailgate.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id KAA23778 for ; Fri, 18 Sep 1998 10:20:49 -0700 Received: from scv3.apple.com (scv3.apple.com) by mailgate.apple.com (mailgate.apple.com - SMTPRS 2.0.15) with ESMTP id ; Fri, 18 Sep 1998 10:20:16 -0700 Received: from [17.255.20.102] (dsinger2.apple.com [17.255.20.102]) by scv3.apple.com (8.8.5/8.8.5) with ESMTP id KAA14670; Fri, 18 Sep 1998 10:20:09 -0700 X-Sender: singer@mail.apple.com Message-Id: In-Reply-To: <11105.906136899@cs.ucl.ac.uk> References: "Your message of Wed, 16 Sep 1998 10:04:50 +0300." <199809160704.KAA23847@harakka.cs.tut.fi> MIME-Version: 1.0 Date: Fri, 18 Sep 1998 10:18:20 -0700 To: rem-conf@es.net From: Dave Singer Subject: Re: RTP payload type names Cc: Koskelainen Petri Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >--> Koskelainen Petri writes: >>Another related point, it makes no sense to announce only H.263(+) >>without any knowledge about the codec options or parameters. >>In draft >>http://search.ietf.org/internet-drafts/draft-koskelainen-sdp263-02.txt >>we have suggested such format for H.263+ SDP syntax using a=fmtp attribute. >> >>It seems that static payload type 34 must be changed to dynamic one. >>So, is the correct form now as follows ? >> >>m=video 8888 RTP/AVP 96 >>a=rtpmap:96 H263-1998 >>a=fmtp 96 CIF=4 QCIF=2/MaxBR=1000/E F >> >>(assuming H263-1998 is the RTPmap name) > I believe the H263 and H263+ bitstreams are self-describing. Why is it thought necessary to give receivers more format information in the sdp info? Or is it merely desirable (I'd still like to know why)? David Singer Apple Computer/QuickTime 408-974-3162 From rem-conf Fri Sep 18 10:57:22 1998 From rem-conf-request@es.net Fri Sep 18 10:57:22 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zK4kS-0006Wa-00; Fri, 18 Sep 1998 10:55:12 -0700 Received: from varis.cs.tut.fi (cs.tut.fi) [130.230.4.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zK4kM-0006WG-00; Fri, 18 Sep 1998 10:55:06 -0700 Received: from kaarne.cs.tut.fi (petkos@kaarne.cs.tut.fi [130.230.3.2]) by cs.tut.fi (8.8.8/8.8.8) with ESMTP id UAA23971; Fri, 18 Sep 1998 20:55:04 +0300 (EET DST) From: Koskelainen Petri Received: (from petkos@localhost) by kaarne.cs.tut.fi (8.8.5/8.8.4) id UAA21297; Fri, 18 Sep 1998 20:54:53 +0300 (EET DST) Message-Id: <199809181754.UAA21297@kaarne.cs.tut.fi> Subject: Re: RTP payload type names In-Reply-To: from Dave Singer at "Sep 18, 98 10:18:20 am" To: singer@apple.com (Dave Singer) Date: Fri, 18 Sep 1998 20:54:53 +0300 (EET DST) Cc: rem-conf@es.net, petkos@cs.tut.fi X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > >>Another related point, it makes no sense to announce only H.263(+) > >>without any knowledge about the codec options or parameters. > > I believe the H263 and H263+ bitstreams are self-describing. Why is it > thought necessary to give receivers more format information in the sdp > info? Or is it merely desirable (I'd still like to know why)? Because H.263 standard includes optional features which are not supported by the basic implementations. Some of the decoders support only very basic features while some are advanced decoders which are capable of decoding optional features (like arbitrary picture sizes, arithmetic coding, scalability etc). These basic (simple) decoders are unable to decode advanced H.263 features. Therefore it makes no sense to send (even standard compliant) H.263 stream which includes non-decodeable options. H.263 stream which includes advanced options are usually useless to receiver. So, the capability set must be agreed somehow beforehand. This kind of scheme is useful (necessity) at least in SIP. -- Petri Koskelainen Nokia Research Center From rem-conf Fri Sep 18 11:22:25 1998 From rem-conf-request@es.net Fri Sep 18 11:22:25 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zK56g-0007No-00; Fri, 18 Sep 1998 11:18:10 -0700 Received: from lhc.nlm.nih.gov [130.14.35.128] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zK56f-0007Nd-00; Fri, 18 Sep 1998 11:18:09 -0700 Received: from billings.csb (billings [130.14.35.141]) by lhc.nlm.nih.gov (8.8.8+Sun/8.8.7) with SMTP id OAA03318; Fri, 18 Sep 1998 14:18:01 -0400 (EDT) Received: by billings.csb (SMI-8.6/SMI-SVR4) id OAA01051; Fri, 18 Sep 1998 14:18:53 -0400 Date: Fri, 18 Sep 1998 14:18:53 -0400 From: rodgers@nlm.nih.gov (R. P. Channing Rodgers, M.D.) Message-Id: <199809181818.OAA01051@billings.csb> To: mbone@isi.edu, rem-conf@es.net Subject: Version of vic to support new PCI-based SunVideo card? X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Colleagues, I'm in the midst of upgrading my UltraSPARC 2 to a 60, which is a PCI-based machine. The version of vic that I have (2.8, which appears to be the latest) does not appear to recognize this new board. Is there a version in the offing for the near future that will support the SunVideo 2 card? Thanks and Best Regards, Rick Rodgers From rem-conf Fri Sep 18 11:22:37 1998 From rem-conf-request@es.net Fri Sep 18 11:22:36 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zK57z-0007O8-00; Fri, 18 Sep 1998 11:19:31 -0700 Received: from axl01it.ntc.nokia.com [131.228.118.232] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zK57y-0007Nx-00; Fri, 18 Sep 1998 11:19:30 -0700 Received: from miller.americas.nokia.com (miller.americas.nokia.com [172.18.180.20]) by axl01it.ntc.nokia.com (8.8.5/8.6.9) with ESMTP id VAA00249; Fri, 18 Sep 1998 21:19:00 +0300 (EET DST) Received: from rhino.ntc.nokia.com (rhino.americas.nokia.com) by miller.americas.nokia.com with ESMTP (1.39.111.2/16.2) id AA257212576; Fri, 18 Sep 1998 14:16:16 -0400 Received: from Microsoft Mail (PU Serial #1991) by rhino.ntc.nokia.com (PostalUnion/SMTP(tm) v2.1.9c for Windows NT(tm)) id AA-1998Sep18.141200.1991.328752; Fri, 18 Sep 1998 14:16:22 -0400 From: subbiah@NASBPD01BS.ntc.nokia.com (Subbiah Baranitharan NRC/Bos) To: balabani@nortel.ca (Vahe Balabanian), rem-conf@es.net ('rem-conf') Message-Id: <1998Sep18.141200.1991.328752@rhino.ntc.nokia.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Organization: Nokia Telecommunications Date: Fri, 18 Sep 1998 14:16:22 -0400 Subject: re:Multiplexing in RTP payload X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Re-distributing this mail with reply due to some local mail problem. Please= = ignore this if you have received earlier. Barani Subbiah ------------ From: Vahe Balabanian To: Subbiah Baranitharan (NRC/Bos) Cc: rem-conf Subject: re:Multiplexing in RTP payload Date: Wednesday, September 16, 1998 5:19PM In message "Multiplexing in RTP payload", subbiah@NASBPD01BS.ntc.nokia.com writes: > >Hello all, > > >This is regarding the user multiplexing in RTP payload, which was = discussed=3D > =3D >during the last Chicago IETF meeting. To understand this problem more, I = =3D >thought the following message could be a starting point. > >Based on the four proposals presented at the Chicago meeting, it seems to = =3D >=3D >me that there are two different problems need to be solved. > >1. Transporting non RTP sources between gateways through multiplexing =3D > (Lucent and Nokia proposals). > >2. Transporting RTP sources through multiplexing (Hitachi and ISI/USC) > >Is the above assumption acceptable within the working group? > >>My reading was that the 2nd solution was going to be effectively >>encompassing the first. Only one solution would be required for >>interoperability reasons. >>Vahe >>Nortel ---------------------------------------- Thanks for the comments. For various reasons I think the second solution is not suitable for the = first one. To start with: 1. Why we need to convert a non RTP source speech packet into a RTP packet = = and then multiplex when the source and destination does not use the header info= . 2. In my view the bottleneck is in the access links. If a RTP source is abl= e send a packet without any problem in the access link then I don't see why we nee= d to multiplex them. I rather use the RTP/UDP/IP header compression from the = source so that there is no complex multiplexing to save bandwidth between gateways= . 3. The efficiency proposed in the second method is equal or better only whe= n gateway co-operates. But preliminary studies have indicated that this is not the = case. We need to use atleast 5 bytes when there is multiple codecs between multiplexing end points. I am referring to Mark Handly's proposal ( CID=3D8= , = SN, PT are needed and rest can be compressed). 4. In a mobile environment there are multiple codecs and as the trend continues, majority of the calls will be between mobile users. I am not sure if it is advantages to use RTP over the air interface for speech only calls. Even if= the remote is a RTP source these things can be taken care at some gateway. 5. There is a need for intermediate switching (multiplexing and demultiplexing) so that overhead can be kept low on the entire transport. If compression is= applied then it adds further processing overhead and delays. I understand the need for a single solution. However, my proposal would be 1. For RTP sources --- use RTP/UDP/IP header compression from the source 2. For non RTP sources - Multiplex between gateways as much as possible. Your comments are welcome. Best regards, Barani Subbiah From rem-conf Sun Sep 20 15:21:22 1998 From rem-conf-request@es.net Sun Sep 20 15:21:21 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zKreN-000543-00; Sun, 20 Sep 1998 15:08:11 -0700 Received: from menus.atlanta.com [155.229.97.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zKreI-00053Q-00; Sun, 20 Sep 1998 15:08:06 -0700 Received: from 155.229.97.1 (1Cust169.tnt5.lax1.da.uu.net [208.251.118.169]) by menus.atlanta.com (8.8.8/8.8.4) with SMTP id SAA24581; Sun, 20 Sep 1998 18:04:53 -0400 (EDT) From: 71288840@24841.com Date: Mon, 31 Aug 98 15:10:34 EST To: niomi@hisbe.com Subject: Market Timing Message-ID: Reply-To: niomi745@hisbe.com X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MT is delivered to our subscribers via an automated list service; unsubscribing instructions are at the end of this letter. September 20, 1998 Table of Contents - Market Timing - Sept 20 edition 1. MT Interviews NuOncology Management 2. Market Commentary 3. MT in Europe 4. Departments 1. MT Interviews NuOncology Management NuOncology Labs Inc. Symbol: NLAB - OTC Bulletin Board We apologize for not getting this letter out a few days ago but there is a lot going on with this company - for instance, only Tuesday of this week MT received a request to be kept updated about NuOncology's progress, from an Asian based pharmaceutical concern. MT met with the Senior Management of NuOncology Labs Inc. on September 10, 1998, at the offices of their investment relations firm in Washington, D.C. MT met with Mr. Robert S. Thomas, Chairman and President, Mr. Philip F. Enlow, Executive Vice President and Mr. Joe Kane, a financial consultant to NuOncology Labs Inc. As you can appreciate in a meeting such as this, there are legal and regulatory restrictions on what information can be shared with MT and our readers, but from the information we did receive there is no doubt this company is making significant progress. We received confirmation that the doctors at the Baker-Sanger Laboratory in Houston, Texas are in the final phases of testing and validating Arglabin and determining its method of action. We also learned that one of the original doctors from Kazakstan is in Houston and assisting in this process. The completion of these tests will be followed by the publishing of a paper, in a recognized medical journal, discussing the findings of NuOncology's research team. This paper will be co-authored by at least four physicians with extensive experience and credentials in oncological research, including Dr. R. Michael Williams, NuOncology's Medical Director and Chief Scientific Officer. Our impression was that this paper would be completed very soon and if the demeanor of the people we met with is any indication, the results are what NuOncology and their shareholders want to see - our feeling is that Arglabin is an FTI. SN will immediately publish a synopsis of the paper when it is available. We also gained an appreciation of how far ahead of other biopharmaceutical companies NuOncology is at the present time. To the best of MT's knowledge no one has published information on clinical (human) trials of FTI's. NuOncology Labs Inc, on the other hand, has all of the clinical results from the Institute of Phytochemistry, in Kazakstan, for the treatment of over 200 patients with various types of cancers. In addition, on a visit to take place between October 19-29, 1998, further results will be available from clinical trials involving 40 liver cancer and 60 breast cancer patients. These tests have been conducted so as to conform to the international protocols for medical research and should help to add credence to the effectiveness of Arglabin. For this reason alone, NuOncology Labs Inc could be 1-2 years ahead of their many industry competitors who are trying to develop FTI's. (There are at least 8 major pharmaceutical companies conducting research in this area.) We were also pleased to confirm that the patents for the lead compound, Arglabin, and the broader patents for its related and derivative compounds are held in the United States and controlled by NuOncology Labs Inc. One of the key questions to our readers is "What is all this worth?" The best answer MT could come up with was by making an analogy to another cancer treatment, Taxol, that seems to work in a similar way to Arglabin. Taxol is a $1 billion a year drug today. It has one serious problem in that it is highly toxic. Arglabin, conversely, has minimal toxic side effects and in clinical trials appears to work as well and in some cases better than Taxol, depending on the type of cancer being treated. Assuming that the clinical trials continue to confirm Arglabin's efficacy as a cancer treatment, one way of looking at the valuation of Arglabin would be as a less toxic Taxol. This could easily lead to Arglabin becoming the treatment of choice and thereby giving it a value at least equal to Taxol. In our next letter we will discuss a number of other developments underway in the predictive and chemosensitivity testing areas of NuOncology's business. MT wishes to thank the management of NuOncology Labs Inc. for taking the time for this meeting and providing ourselves and our readers with these insights into their company and their business. MT continues to feel very bullish about this company and encourage our readers to closely follow this rapidly developing situation. We believe the shares of NuOncology Labs Inc. (NLAB) to be very attractive at prices up to $10. 2. Market Commentary If the market rally can be credited to the strong hints of an interest rate cut late last week and Monday, and the slide in the market in the middle of last week can be blamed on Mr. Clinton's personal problems then this market is not in bad shape and is likely to move higher. We believe that Mr. Greenspan's guidance of the economy is key to how the U.S. economic future will unfold. In fact, the future of a number of large Asian and South American economies are dependent on his guidance. The "doom and gloom" crowd project the present set of trends and parameters into the future and get a self fulfilling prophecy of economic disaster. This is where we differ from those that are predicting a more negative outlook - we do not assume the monetary authorities of the major economic powers are going to do nothing. MT believes that the position that is now being taken by the Fed in the U.S. is that America will have to try and ward off a global recession by initially lowering interest rates and thereby encouraging domestic growth. They will also lend enough money, through the IMF, to reflate many of the world's troubled economies. This scenario is only possible because the US economy is strong, unemployment is low, interest rates are at historic lows (and probably heading lower), there is no apparent inflationary pressures, and there is no external threat to the U.S.. Mr. Clinton is less than 2 months away from what most pundits will soon be referring to as the "lame duck" period of his Presidency. Although we do not think it likely that he will be impeached, if it does occur, we do not think it will be a factor in the economic equation. The bottom line is that the U.S. will need to be the engine to keep many of the world's economies afloat and resuming the type of growth they have shown in the past. For this reason MT believes that the future for the U.S. economy and stock market is positive and there will continue to be opportunities to profit for the savvy investor. 3. MT in Europe MT is expanding its readership in certain 'key' economic centers in Europe. For the convenience of our readers, MT will now be available in German. For those subscribers who would like to receive their issues of MT in German simply type "German" in the subject and send an e-mail to : Wetpapiere@USA.net There is no need to write a letter as you will automatically be sent future issues of MT in German. 4. Departments A. Stock Quotes B. MT Privacy Policy C. Disclaimer D. How to Unsubscribe A. Stock Quotes To get a stock quote please go to: http://www.StockGuide.com B. MT Privacy Policy At MT we respect your privacy and will NEVER release your e-mail address to a third party for any reason. C. Disclaimer Please read our disclaimer at: http://206.132.163.167/krichx/mtdis.htm D. How to Unsubscribe To unsubscribe to MT simply put 'unsubscribe' in the subject and return to: UnsubscribeMT@USA.net You will be unsubscribed instantly. From rem-conf Mon Sep 21 01:22:04 1998 From rem-conf-request@es.net Mon Sep 21 01:22:01 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zL10g-00017k-00; Mon, 21 Sep 1998 01:07:50 -0700 Received: from mailex.rz.fh-ulm.de [141.59.42.12] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zL10e-00017Y-00; Mon, 21 Sep 1998 01:07:48 -0700 Received: from hugo.rz.fh-ulm.de (Hugo.rz.fh-ulm.de [141.59.43.36]) by mailex.rz.fh-ulm.de (8.9.1/8.8.8) with ESMTP id KAA29635 for ; Mon, 21 Sep 1998 10:07:54 +0200 Received: from HUGO/SpoolDir by hugo.rz.fh-ulm.de (Mercury 1.43); 21 Sep 98 10:07:48 +0100 Received: from SpoolDir by HUGO (Mercury 1.43); 21 Sep 98 10:07:35 +0100 From: "RZ Dietmar Rahlfs" Organization: Fachhochschule Ulm To: rem-conf@es.net Date: Mon, 21 Sep 1998 10:06:49 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: VIC 2.7 under Linux: Create Session Problem X-Confirm-Reading-To: "RZ Dietmar Rahlfs" Priority: normal X-mailer: Pegasus Mail v3.31 Message-ID: <13ABE2A2DAD@hugo.rz.fh-ulm.de> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, I am trying to make a video session under Linux with vic 2.7a38 and the Matrox Meteor. I can receive sessions from the M-Bone, and when I am doing the same under Solaris (SunOS 5.5) I am successful. Here's what I've done: sdr & New / Create advertised session Now the session is in the sdr list. I join my new session, vic starts up, I choose Menu, click on "Transmit", and a uniformly green image appears where in other sessions I can see a professor saying something or another scene. The Linux kernel version is 2.0.33. Some more info from VIC: After clicking on Menu/Transmission: Rate Control: about 8 f/s, 5 kb/s Menu/Encoder: Device: Matrox Meteor 1 (which is /dev/mmetfgrab[0]) Port: RCA (correct: "phone connector" in the Matrox Meteor manual) Options: - h261 normal Menu/Display: Options: - Tile: single Ordered info... RTP Statistics: all zero but Kilobytes 5000 Frames 6600 Packets 6600 (at some moment) Decoder Stats: all zero. I can distribute this uniform green image to another Linux PC, and that PC reacts on Protocol change (h261->nv and so on). Is Linux with the meteor well supported at all nowadays? Thank you for answering Dietmar Rahlfs From rem-conf Mon Sep 21 02:02:56 1998 From rem-conf-request@es.net Mon Sep 21 02:02:46 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zL1q6-0002Kh-00; Mon, 21 Sep 1998 02:00:58 -0700 Received: from clarinet.u-strasbg.fr [130.79.75.86] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zL1q4-0002KT-00; Mon, 21 Sep 1998 02:00:57 -0700 Received: from dpt-info.u-strasbg.fr (videonet.u-strasbg.fr [130.79.75.80]) by clarinet.u-strasbg.fr (8.9.0/8.9.0) with ESMTP id LAA26521; Mon, 21 Sep 1998 11:00:47 +0200 (MET DST) Message-ID: <360615BE.8B6D4205@dpt-info.u-strasbg.fr> Date: Mon, 21 Sep 1998 11:00:46 +0200 From: David PATE Organization: ULP - Strasbourg X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: RZ Dietmar Rahlfs CC: rem-conf@es.net Subject: Re: VIC 2.7 under Linux: Create Session Problem References: <13ABE2A2DAD@hugo.rz.fh-ulm.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list RZ Dietmar Rahlfs wrote: > Hello, > > I am trying to make a video session under Linux with > vic 2.7a38 and the Matrox Meteor. I can receive > sessions from the M-Bone, and when I am doing the > same under Solaris (SunOS 5.5) I am successful. > > Here's what I've done: > > sdr & > New / Create advertised session > > Now the session is in the sdr list. > > I join my new session, vic starts up, I choose Menu, click > on "Transmit", and a uniformly green image appears where > in other sessions I can see a professor saying something or > another scene. > > The Linux kernel version is 2.0.33. > > Some more info from VIC: > > After clicking on Menu/Transmission: > Rate Control: about 8 f/s, 5 kb/s > > Menu/Encoder: > Device: Matrox Meteor 1 (which is /dev/mmetfgrab[0]) > Port: RCA (correct: "phone connector" in > the Matrox Meteor manual) > Options: - > h261 > normal > > Menu/Display: > Options: - > Tile: single > Ordered > > info... > RTP Statistics: all zero but > Kilobytes 5000 > Frames 6600 > Packets 6600 > (at some moment) > Decoder Stats: all zero. > > I can distribute this uniform green image to another Linux PC, > and that PC reacts on Protocol change (h261->nv and so on). > > Is Linux with the meteor well supported at all nowadays? > I don't know why you've got a green image, but I just can say that the meteor is well supported. Perhaps, you have to switch to vic 2.8 that is the last "official" release. -- DAVID ----- ---------------------------------------------------------------------- David PATE' ==>> http://dpt-info.u-strasbg.fr/~pate From rem-conf Mon Sep 21 15:21:40 1998 From rem-conf-request@es.net Mon Sep 21 15:21:39 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zLE8W-0002Pm-00; Mon, 21 Sep 1998 15:08:48 -0700 Received: from humble.net.nih.gov (packet.net.nih.gov) [165.112.130.12] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zLE8V-0002Pc-00; Mon, 21 Sep 1998 15:08:47 -0700 Received: from pearl.dcrt.nih.gov (pearl.dcrt.nih.gov [128.231.200.90]) by packet.net.nih.gov (8.8.5/8.8.5) with SMTP id SAA00487 for ; Mon, 21 Sep 1998 18:08:12 -0400 (EDT) From: Ken Wong Reply-To: kenwong@nih.gov To: rem-conf@es.net Subject: NIH Public Participation Message-ID: Date: Mon, 21 Sep 1998 18:10:17 -0400 (EDT) Priority: NORMAL X-Mailer: Simeon for Solaris Motif Version 4.1.5 Build (43) X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The NIH will be multicasting this event. Please join the session "NIH Public Paricipation" on Wed, Sept 23 from 9am-3:30pm EST. --- Begin Forwarded Message --- From: Vazquez, Laura (OD) Sent: Monday, September 21, 1998 4:42 PM To: Wong, Ken (CIT) Subject: multicasting Sept. 23 meeting On Wednesday, September 23, Dr. Harold Varmus, NIH Director, will hold a special meeting on enhancing public participation in NIH activities. This meeting is open to the public and will run from 9 a.m. until 3:30 p.m. on the NIH campus. At the meeting, individual public participants invited by the NIH will discuss future activities and responsibilities of the proposed NIH Director's Council of Public Representatives and the NIH Offices of Public Liaison, initiatives recommended in the National Academy of Sciences' Institute of Medicine (IOM) report, "Scientific Opportunities and Public Needs: Improving Priority Setting and Public Input at the National Institutes of Health," released July 8, 1998. --- End Forwarded Message --- __________________________________________________ "I believe I am the most fortunate sentient in this sector of the galaxy." - Data Ken Wong National Institutes of Health kenwong@nih.gov From rem-conf Tue Sep 22 05:56:51 1998 From rem-conf-request@es.net Tue Sep 22 05:56:49 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zLRr1-0000Wp-00; Tue, 22 Sep 1998 05:47:39 -0700 Received: from sasi.com (samar.sasi.com) [164.164.56.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zLRqw-0000WM-00; Tue, 22 Sep 1998 05:47:36 -0700 Received: from lnxc34.sasi.com (lnxc34.sasi.com [10.0.32.34]) by samar.sasi.com (8.8.7/8.8.7) with ESMTP id SAA05608 for ; Tue, 22 Sep 1998 18:19:29 +0530 Received: from lnxc34.sasi.com (anoop@localhost [127.0.0.1]) by lnxc34.sasi.com (8.8.7/8.8.8) with ESMTP id SAA04151 for ; Tue, 22 Sep 1998 18:19:28 +0530 Message-Id: <199809221249.SAA04151@lnxc34.sasi.com> To: rem-conf@es.net Reply-To: anoop@sasi.com Subject: Query.. Date: Tue, 22 Sep 1998 18:19:27 +0530 From: Anoop Kulkarni X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Are there any standardising bodies working on fields such as 'TCP over wireless media', 'mobile IP on wireless media'? If so, which are they? Am sorry if this is not the right place to ask these questions. Thanks in advance, Regards, Anoop -- ----------------------------+--------------------------------------------- Home : Anoop Kulkarni, PhD | Office: Anoop Kulkarni, Silicon Automation Flat A2, Pioneer Residency, | Systems (I) Pvt Ltd., 3008, 12th B Main, 8th HAL III Stage, Bangalore 75 | Cross, Indiranagar, Bangalore - 560008 INDIA Phone: +091-080-528 5749 | Fax : +091-080-528 4396 Email: anoop@sasi.com | Phone : +091-080-528 1461 ext 4205 ----------------------------+--------------------------------------------- From rem-conf Tue Sep 22 07:48:25 1998 From rem-conf-request@es.net Tue Sep 22 07:48:23 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zLTfL-0002LB-00; Tue, 22 Sep 1998 07:43:43 -0700 Received: from el-postino.s-vision.com [207.108.173.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zLTfK-0002L1-00; Tue, 22 Sep 1998 07:43:42 -0700 Received: by el-postino.s-vision.com with Internet Mail Service (5.5.2232.9) id ; Tue, 22 Sep 1998 08:43:44 -0600 Message-ID: <00D7B108BAFFD011B66D00A0C903629C359189@el-postino.s-vision.com> From: Forrest Blair To: potsag@imtc.org, h323implementors@imtc.org, sg16.lbc@research.kpn.com, rem-conf@es.net Subject: H.263 Picture Type Bits Date: Tue, 22 Sep 1998 08:43:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please excuse the multiple copies for those on multiple lists. I'm looking for more detailed information about H.263 picture type bits 3 and 4. Bit 3 is defined as "Split screen indicator" and bit 4 as "Document camera indicator". The standard does not clearly define the purpose of these bits and how they should be handled by the decoder if they are turned on. Any information you have would be most helpful. Also, I'm curious to know if any encoders are actively using these features. Thanks in advance. Forrest Blair Sorenson Vision, Inc. From rem-conf Tue Sep 22 07:51:02 1998 From rem-conf-request@es.net Tue Sep 22 07:51:01 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zLTkk-0002Pi-00; Tue, 22 Sep 1998 07:49:18 -0700 Received: from atol.icm.edu.pl [148.81.209.1] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zLTkh-0002PN-00; Tue, 22 Sep 1998 07:49:16 -0700 Received: from galera.icm.edu.pl ([148.81.208.198]:32937 "EHLO galera.icm.edu.pl" ident: "rzm") by atol.icm.edu.pl with ESMTP id <211249-13107>; Tue, 22 Sep 1998 16:48:52 +0200 Received: (from rzm@localhost) by galera.icm.edu.pl (8.8.5/8.8.5) id QAA27385 for rem-conf@es.net; Tue, 22 Sep 1998 16:52:01 +0200 (MET DST) Message-ID: <19980922165201.B17913@icm.edu.pl> Date: Tue, 22 Sep 1998 16:52:01 +0200 From: Rafal Maszkowski To: rem-conf@es.net Subject: Warsaw Autumn Internet Concert transmission Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list September 24th 18 GMT (20 MET) RAT GSM+LPC Warsaw Autumn is a modern music festival - more: http://www.warsaw-autumn.art.pl/ - the festival http://www.warsaw-autumn.art.pl/WHO-HOW/ - Internet concert Sorry for annoucing very late, we have a lot of technical problems with MBONE and MBONE tools. Whe may have big packet losses too. Is the secondary RAT encoding a problem for anybody who would like to listen? R. From rem-conf Tue Sep 22 08:19:26 1998 From rem-conf-request@es.net Tue Sep 22 08:19:26 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zLUAe-00044e-00; Tue, 22 Sep 1998 08:16:04 -0700 Received: from mail-gw.8x8.com [192.84.19.131] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zLUAd-00044U-00; Tue, 22 Sep 1998 08:16:03 -0700 Received: from mail.8x8.COM (mail.8x8.com [192.84.19.130]) by mail-gw.8x8.COM (8.9.1a/8.9.1) with ESMTP id IAA05635; Tue, 22 Sep 1998 08:15:45 -0700 (PDT) Received: from santafe.iitengr (santafe [192.84.17.149]) by mail.8x8.COM (8.8.8/8.8.8) with SMTP id IAA29439; Tue, 22 Sep 1998 08:15:44 -0700 (PDT) Received: by santafe.iitengr (SMI-8.6/SMI-SVR4) id IAA08685; Tue, 22 Sep 1998 08:15:43 -0700 Date: Tue, 22 Sep 1998 08:15:43 -0700 From: spike@8x8.COM (Daniel Helman) Message-Id: <199809221515.IAA08685@santafe.iitengr> To: potsag@imtc.org, h323implementors@imtc.org, sg16.lbc@research.kpn.com, rem-conf@es.net, fblair@s-vision.com Subject: Re: H.263 Picture Type Bits X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The document camera bit is just that; it is on when the image is coming from a second camera pointed at a document. We use a 1->0 transition on this bit to indicate that the previous image should be stored for later viewing. If you have this storage capability your user interface can switch between live video and stored documents. We don't use the split screen bit. Dan Helman spike@8x8.com > Date: Tue, 22 Sep 1998 08:43:37 -0600 > From: Forrest Blair > > I'm looking for more detailed information about H.263 picture type bits 3 > and 4. Bit 3 is defined as "Split screen indicator" and bit 4 as "Document > camera indicator". > > The standard does not clearly define the purpose of these bits and how they > should be handled by the decoder if they are turned on. Any information you > have would be most helpful. > > Also, I'm curious to know if any encoders are actively using these features. > > Thanks in advance. > > Forrest Blair > Sorenson Vision, Inc. > From rem-conf Tue Sep 22 10:48:50 1998 From rem-conf-request@es.net Tue Sep 22 10:48:48 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zLWR7-00067e-00; Tue, 22 Sep 1998 10:41:13 -0700 Received: from smtpott1.nortel.ca [192.58.194.78] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zLWR6-00067U-00; Tue, 22 Sep 1998 10:41:12 -0700 Received: from zcars00t by smtpott1; Tue, 22 Sep 1998 13:40:46 -0400 Received: from ca.nortel.com by zcars00t.ca.nortel.com id <07903-0@zcars00t.ca.nortel.com>; Tue, 22 Sep 1998 13:38:00 -0400 Date: 22 Sep 1998 13:37 EDT Sender: "Vahe Balabanian" To: C.Perkins@cs.ucl.ac.uk Cc: rem-conf@es.net From: "Vahe Balabanian" Subject: re:Draft AVT minutes Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Colin, I know I missed the deadline you specified, but I think one word is missing: In message "Draft AVT minutes", C.Perkins@cs.ucl.ac.uk writes: >I enclose a draft of the minutes for the Chicago AVT meeting. In order to >meet the submission deadline, I'd be grateful if you could send comments >or corrections to me by Thursday evening. > >Colin > > >=============================================================================== >Minutes of the Audio/Video Transport Working Group > ............... >The next IETF meeting coincides with the MPEG4 decision meeting, so it is >therefore urgent that these issues are resolved. The last chance to make >changes to MPEG4 version 1 will be at the MPEG meeting on 12-16 October. >Since it is clear that only limited progress can be made in the short time >period available it was decided to continue with the development of the >payload format for MPEG4 elementary streams and to resolve the issues ^single >discussed. Once this is done and further experience has been gained with >actual implementations the group will revisit these issues. > .... Vahe From rem-conf Wed Sep 23 07:10:49 1998 From rem-conf-request@es.net Wed Sep 23 07:10:47 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zLpKp-0000B2-00; Wed, 23 Sep 1998 06:51:59 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0zLpKn-0000As-00; Wed, 23 Sep 1998 06:51:57 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 23 Sep 1998 14:51:46 +0100 To: Vahe Balabanian cc: rem-conf@es.net Subject: Re: Draft AVT minutes In-reply-to: Your message of "22 Sep 1998 13:37:00 EDT." Date: Wed, 23 Sep 1998 14:51:44 +0100 Message-ID: <6359.906558704@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Vahe Balabanian writes: >Colin, I know I missed the deadline you specified, but I think >one word is missing: ... >>Minutes of the Audio/Video Transport Working Group >............... >>The next IETF meeting coincides with the MPEG4 decision meeting, so it is >>therefore urgent that these issues are resolved. The last chance to make >>changes to MPEG4 version 1 will be at the MPEG meeting on 12-16 October. >>Since it is clear that only limited progress can be made in the short time >>period available it was decided to continue with the development of the >>payload format for MPEG4 elementary streams and to resolve the issues > ^single >>discussed. Once this is done and further experience has been gained with >>actual implementations the group will revisit these issues. Vahe, That's a useful clarification. Once we understand how to efficiently carry a single MPEG4 elementary stream in RTP and have some experience with the typical usage of MPEG4, the group should work on the issues of multiplexing and multiple streams. We should solve the problem for the simple case first though. Colin From rem-conf Thu Sep 24 09:59:15 1998 From rem-conf-request@es.net Thu Sep 24 09:59:14 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zMEQr-0006MX-00; Thu, 24 Sep 1998 09:39:53 -0700 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zMEQq-0006MN-00; Thu, 24 Sep 1998 09:39:52 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id JAA23550; Thu, 24 Sep 1998 09:39:52 -0700 (PDT) Message-Id: <3.0.3.32.19980924093950.00a8ea10@gumby.cs.berkeley.edu> X-Sender: cwilliams@gumby.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 24 Sep 1998 09:39:50 -0700 To: (Recipient list suppressed) From: Chris Williams Subject: 9/30 Berkeley, Multimedia, Interfaces, and Graphics Seminar Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list
    Use What You Teach: Teaching CSCW Using CSCW Tools
    James Landay Computer Science Division - EECS UC Berkeley Wednesday September 30, 1998 12:30-2:00 PDT 405 Soda Hall
    Distance learning technology has repeatedly been cited as a way to reduce the cost of advanced education and to bring training to the masses. Drawbacks aside, this technology will be used in many educational settings and it is therefore important for educators to understand its advantages and limitations. Researchers in the field of computer-supported cooperative work (CSCW) have been building research systems for years that support distance learning. To expose students to the difficult issues in this area and to learn more myself, I taught a course on CSCW in the Fall 1997 semester in which we used CSCW tools. In this talk I describe the course structure, the technology we used, and the outcomes of the course. The course website is at: http://bmrc.berkeley.edu/courseware/cscw/fall97/index.html. The Mbone addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202. ____________________________________________ Chris Williams Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: cwilliams@bmrc.berkeley.edu From rem-conf Fri Sep 25 07:17:09 1998 From rem-conf-request@es.net Fri Sep 25 07:17:08 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zMYKg-0000Hn-00; Fri, 25 Sep 1998 06:54:50 -0700 Received: from (fsnt.future.futsoft.com) [38.242.192.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zMYKb-0000HC-00; Fri, 25 Sep 1998 06:54:49 -0700 Received: from kailash.future.futsoft.com (unverified [38.242.192.4]) by fsnt.future.futsoft.com (Integralis SMTPRS 2.04) with ESMTP id ; Fri, 25 Sep 1998 19:21:39 +0530 Received: from msgate.future.futsoft.com (msgate.future.futsoft.com [10.0.8.4]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id TAA05239; Fri, 25 Sep 1998 19:32:46 +0530 Received: by msgate.future.futsoft.com with Microsoft Mail id <360C505C@msgate.future.futsoft.com>; Fri, 25 Sep 98 19:24:28 PDT From: vishwas To: "'Bill Fenner'" Cc: rem-conf , mbone Subject: Setsockopt Date: Fri, 25 Sep 98 19:24:00 PDT Message-Id: <360C505C@msgate.future.futsoft.com> X-Mailer: Microsoft Mail V3.0 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Bill, Have a small problem in my multimedia apllication. When I do setsockopt for an IP addr which is a POINTOPOINT link running SLIP running on Linux 1.2.1. I get an error message saying "No Such Device".. Is setsock opt is supported for serial interfaces..? Regards vishwa From rem-conf Fri Sep 25 10:01:27 1998 From rem-conf-request@es.net Fri Sep 25 10:01:26 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zMb1P-0002dC-00; Fri, 25 Sep 1998 09:47:07 -0700 Received: from omega.xerox.com (alpha.xerox.com) [13.1.64.95] by mail1.es.net with smtp (Exim 1.81 #2) id 0zMb1O-0002ca-00; Fri, 25 Sep 1998 09:47:06 -0700 Received: from mango.parc.xerox.com ([13.1.102.232]) by alpha.xerox.com with SMTP id <433905(1)>; Fri, 25 Sep 1998 09:45:50 PDT Received: from mango.parc.xerox.com (localhost.parc.xerox.com [127.0.0.1]) by mango.parc.xerox.com (8.8.8/8.8.8) with ESMTP id JAA07175; Fri, 25 Sep 1998 09:45:46 -0700 (PDT) (envelope-from fenner@mango.parc.xerox.com) Message-Id: <199809251645.JAA07175@mango.parc.xerox.com> To: vishwas cc: "'Bill Fenner'" , rem-conf , mbone Reply-to: mbone@ISI.EDU Subject: Re: Setsockopt In-reply-to: Your message of "Fri, 25 Sep 1998 19:24:00 PDT." <360C505C@msgate.future.futsoft.com> Date: Fri, 25 Sep 1998 09:45:46 PDT From: Bill Fenner X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I assume you mean the IP_ADD_MEMBERSHIP or IP_MULTICAST_IF socket options. In order to support "unnumbered" interfaces, where the point-to-point interface has the same address as another interface, some OS's use the remote address of the interface. Others use the local address so there is no way to specify an "unnumbered" interface. You could use the route to 224/4 (or, in fact, any group) to specify the default interface for binding or sending multicast. If you point the route towards an interface and then use INADDR_ANY for the interface specification, you should get the same results. Bill From rem-conf Fri Sep 25 21:05:03 1998 From rem-conf-request@es.net Fri Sep 25 21:05:02 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zMlS4-0001sp-00; Fri, 25 Sep 1998 20:55:20 -0700 Received: from 1cust243.tnt36.dfw5.da.uu.net ([208.250.161.243] helo=server) by mail2.es.net with smtp (Exim 1.92 #1) id 0zMlS1-0001sc-00; Fri, 25 Sep 1998 20:55:18 -0700 To: From: Subject: Brethren CoOp Date: Fri, 25 Sep 1998 19:14:47 Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Brethren Long Distance CoOp Hi, Dino Layton here... You can now help missionaries with every long distance call you make. With the strength of the Brethren CoOp, we can now offer you, your family, and your business a rate of 8.9 cents per minute on all interstate calls (24 hours / 7days), unbeatable in-state rates, and unheard of international rates. AND, 4% of all your phone bills will go towards helping missionaries obtain discounted goods and services! This service includes: No sign-up fees No monthly minimums No service charges 6 second increments Calling cards at 17 cents per minute (No other charges) Toll-free numbers at 8.9 cents per minute ($2.00 monthly fee for this only) Reimbursement for switching your long distance service If you would like to save money on your phone bill while helping missionaries, reply to Brethren_coop@powercom.org with your name and postal address. We will e-mail you complete information and send you applications for service. Please feel free to call us toll-free if you wish. Our number is (888) 545-4746. Sincerely, Dino J. Layton Dino J. Layton 2900 Emily Nixa, MO. 65714 Toll-Free (888) 545-4746 Phone: (417) 581-9292 Fax: (417) 581-9393 From rem-conf Sat Sep 26 07:04:43 1998 From rem-conf-request@es.net Sat Sep 26 07:04:40 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zMut6-0004N4-00; Sat, 26 Sep 1998 06:59:52 -0700 Received: from mail.omnilink.net [194.64.25.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zMut5-0004Ms-00; Sat, 26 Sep 1998 06:59:51 -0700 Received: from ltt.de ([194.64.29.218]) by mail.omnilink.net (8.9.1a/8.9.1) with ESMTP id PAA26299; Sat, 26 Sep 1998 15:57:11 +0200 (MET DST) Message-ID: <360CF299.D0951D30@ltt.de> Date: Sat, 26 Sep 1998 15:56:45 +0200 From: Roberto Zicari Reply-To: zicari@ltt.de Organization: Logon Technology Transfer X-Mailer: Mozilla 4.04 (Macintosh; I; PPC) MIME-Version: 1.0 To: "KOBRYN, Cris" , "'commsoft@cc.bellcore.com'" , "'odp@dstc.edu.au'" , "'dbworld@cs.wisc.edu'" , "'enternet@BBN.COM'" , "'JavaCORBA@luke.org'" , "'ISWORLD@Danann.hea.ie'" , "'comsoc-chapters@IEEE.ORG'" , "'comsoc-gicb@IEEE.ORG'" , "'comsoc.tac@tab.ieee.org'" , "'comswtc@gmu.edu'" , "'ctc-members@redbank.tinac.com'" , "'end2end-interest@isi.edu'" , "'f-troup@codex.cis.upenn.edu'" , "'fokus-user@fokus.gmd.de'" , "'g-troup@ccrc.wustl.edu'" , "'giga@tele.pitt.edu'" , "'hipparch@sophia.inria.fr'" , "'ieee_rtc_list@cs.tamu.edu'" , "'ieeetcpc@ccvm.sunysb.edu'" , "'isadsoc@fokus.gmd.de'" , "'itc@fokus.gmd.de'" , "'modern-heuristics@uk.ac.mailbase'" , "'multicomm@cc.bellcore.com'" , "'osimcast@BBN.COM'" , "'rem-conf@es.net'" , "'reres@laas.fr'" , "'sb.all@IEEE.ORG'" , "'sc6wg4@ntd.comsat.com'" , "'sigmedia@bellcore.com'" , "'tccc@IEEE.ORG'" , "'xtp-relay@cs.concordia.ca'" Subject: last call References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list OBJECT WORLD London`98 -- LAST CALL Dear Colleague, The OBJECT WORLD London`98 conference, sponsored by the Object Management Group (OMG), will take place Oct.5-8, 1998 at Earls Court in London. The full conference program is available at http://www.comdex.de/OWUK/ with on-line registration. ** Bona fide educational institutions can claim a 50% discount on the conference prices. Please help posting this info as you see proper. If you wish to receive a printed copy of the conference brochure, please be so kind and tell us your postal address. E-mail: Logon@ltt.de, or fax +49-6173- 94 04 20 Thank you for your cooperation! Regards Roberto Zicari PC Chair OMG Central & Northern Europe KOBRYN, Cris wrote: > > [Please forward this message to colleagues who might be interested. > We apologize if you receive multiple copies.] > > The following is the final Call for Papers for the 2nd International > Enterprise Distributed Object Computing Workshop (EDOC '98). > > A HTML version of the CFP can be found at: > http://uml.systemhouse.mci.com/events/edoc98/home.htm > A PDF version of the CFP can be found at: > http://uml.systemhouse.mci.com/events/edoc98/docs/edoc98-cfp.pdf > > Invited speakers for the workshop include: > > Ivar Jacobson, VP of Business Engineering, Rational Software Corp. > Phil Bernstein, Repository Architect, Microsoft Corp. > > ====================================================================== > > ***** CALL FOR PAPERS ***** > > 2nd International Enterprise Distributed Object Computing Workshop (EDOC > '98) > > November 3-5, 1998 > > Hyatt Regency La Jolla, San Diego, California, USA > > http://uml.systemhouse.mci.com/events/edoc98/home.htm > > ====================================================================== > > Hosted by: > MCI Systemhouse Corporation > > Technical Co-Sponsors: > Object Management Group (OMG) > IEEE Communications Society, Enterprise Networking Technical > Committee > > Endorsed by: > Institute of Electronics, Information and Communication Engineers of > Japan > Information Processing Society of Japan (IPSJ) > > Corporate sponsors: > Distributed Systems Technology Centre (DSTC) > Unisys Corp. > Fujitsu Corp. > > ====================================================================== > > SCOPE: > ~~~~~~ > The software industry is in the midst of a major shift in technology > from > static, monolithic systems to the era of distributed objects and > components. > The remarkable level of interest in the first Enterprise Distributed > Object > Computing (EDOC '97) Workshop demonstrated that this transformation is > well > underway. However, there remain some major challenges to be overcome if > distributed objects and components are to fulfill their full potential > for > solving enterprise problems. > > The goal of the EDOC workshops is to provide a leading forum for the > exchange of ideas and results in this rapidly developing field of > computing, > and to establish a new community of researchers and industry experts to > address the enterprise issues associated with distributed object > technology. > Building on the success of the first EDOC workshop, EDOC '98 will focus > on > securing high-quality papers and tutorials from around the world, and > will > provide ample opportunities for discussion and debate. In addition, > there > will be relevant panel sessions with substantial time for open > discussions. > > EDOC '98 will target two interrelated categories of topics. The first > group > will deal with the specification of enterprise models for distributed > systems. This includes issues related to the specification of roles, > policies, business objects and their relationships in open distributed > systems. The second group will address the problems of implementing > systems > specified by enterprise models using currently available distributed > object > technologies (e.g., CORBA, DCOM, Java-RMI, TINA, RM-ODP). This includes > issues related to architectural models, technology bridges and the > general > problem of middleware selection and application. > > TOPICS: > ~~~~~~~ > The program committee seeks research results, experience reports and > case > studies related to all aspects of enterprise distributed object > computing, > including such topics as: > > - Distributed object architectures and frameworks > - Distributed business objects > - Analysis and design methods > - Metamodeling architectures > - Collaborative and workflow systems > - ODP enterprise language and business modeling > - UML for enterprise applications > - Enterprise policy, management and security > - Enterprise Quality of Service > - Traders, brokers, and agents for enterprise solutions > - Application of the above technologies in vertical application > domains such as telecomunnications, business and financial systems > > Papers must be of high quality and will be evaluated for originality, > significance, insight, clarity and their relevance to the enterprise > aspects > of distributed object computing. > > IMPORTANT DATES: > ~~~~~~~~~~~~~~~~ > June 1st, 1998: Papers due > August 10, 1998: Notification of acceptance > September 11, 1998: Final papers due > November 3-5, 1998: Workshop > > INFORMATION FOR AUTHORS: > ~~~~~~~~~~~~~~~~~~~~~~~~ > PAPERS: > Authors are invited to submit full papers according to the submission > guidelines below. Papers will be refereed by an international committee > of experts. Presented papers will be published by the IEEE > Computer Society Press. > > SUBMISSIONS: > The papers should not exceed 12 pages, according to IEEE format > (double column, single space, 10 point Times font). The preferred method > for submission is electronic mail (Word, RTF, PostScript or PDF format). > Please send your submissions to the following address: > edoc98-submissions@omg.org > > Enquiries should be directed to: > edoc98-info@omg.org > > WORKSHOP ORGANIZERS: > ~~~~~~~~~~~~~~~~~~~~ > General Chair: > Cris Kobryn (MCI Systemhouse, USA) > Program Chairs: > Colin Atkinson (IESE, Germany) > Zoran Milosevic (DSTC, Australia) > Program Committee: > Nigel Baker (University of West England, UK) > Phil Bernstein (Microsoft, USA) > Eng Chew (Optus, Australia) > Jim Coplien (Bell Labs, USA) > Fred Cummins (EDS, USA) > Takeo Hamada (Fujitsu Laboratories of America, USA) > Sridar Iyengar (Unisys, USA) > Peter Linington (University of Kent at Canterbury, UK) > Claudia Linnhoff-Popien (RWTH Aachen, Germany) > George Karetsos (National Technical University of Athens, Greece) > Subrata Mazumdar (Bell Labs, USA) > Osamu Miyagishi (NTT, Japan) > Luke O'Connor (IBM Zurich, Switzerland) > Maria Orlowska (The University of Queensland, Australia) > Jong-Tae Park (Kyungpook National University, Korea) > Thomas Preuss (Brandenburg University of Technology, Germany) > Kerry Raymond (DSTC, Australia) > Roberto Saracco (CSELT, Italy) > Marc-Thomas Schmidt (IBM, USA) > Morris Sloman (Imperial College, UK) > Richard Mark Soley (OMG, USA) > Jean-Bernard Stefani (CNET France Telecom, France) > Keith Swenson (Netscape, USA) > Sandy Tyndale-Biscoe (Birchquest Ltd, UK) > Kevin Tyson (Enterprise Engineering, USA) > Sanya Uehara (Fujitsu, Japan) > Karl-Heinz Weiss (Public Administration Berlin, Germany) > Edward White (MCI, USA) > Bryan Wood (Open-IT, UK) > Douglas Zuckerman (Bellcore, USA) > > Local Organizing Committee: > Cheryl Bissonnette (OMG, USA) > > VENUE: > ~~~~~~ > EDOC '98 will be held in San Diego, California at one of Southern > California's premier venues: the Hyatt Regency La Jolla at Aventine. The > hotel is a San Diego landmark destination and a Mobil 4-Star and AAA > 4-Diamond Award winner. It provides the perfect complement of business > and > recreation facilities. > > The Aventine complex includes the Hyatt Regency La Jolla, a 32,000 sq. > ft. > world-class Sporting Club and Spa, a restaurant village with > internationally > themed restaurants, lighted tennis courts and a heated pool. The hotel > is > five minutes from golf and the beach and 15 minutes from downtown San > Diego. > > ENQUIRIES AND REGISTRATION DETAILS: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Accommodation at a discounted conference rate is available at the > workshop > venue. Registration and accommodation details will be available in the > near > future. > For enquiries, please email to Cheryl Bissonette at: > cheryl@omg.org > Postal address: > Object Management Group > 492 Old Connecticut Path > Framingham, MA 01701 > USA > > RELATED EVENTS: > ~~~~~~~~~~~~~~~ > November 9-13, 1998 OMG Technical Committee meeting, Burlingame, CA, > USA > > WWW PAGE: > ~~~~~~~~~ > Further details about the EDOC'98 event and this Call For Papers can be > found at: > http://uml.systemhouse.mci.com/events/edoc98/home.htm From rem-conf Sun Sep 27 04:43:20 1998 From rem-conf-request@es.net Sun Sep 27 04:43:19 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zNEz4-0004QV-00; Sun, 27 Sep 1998 04:27:22 -0700 Received: from relay14.jaring.my [192.228.128.125] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zNEz2-0004QD-00; Sun, 27 Sep 1998 04:27:20 -0700 Received: from jyluke ([202.185.249.16]) by relay14.jaring.my (8.8.8/8.8.7) with SMTP id TAA26345 for ; Sun, 27 Sep 1998 19:26:18 +0800 (MYT) Message-ID: <360E20B8.1426@ew.mimos.my> Date: Sun, 27 Sep 1998 19:25:44 +0800 From: JY Luke Reply-To: jyluke@ew.mimos.my Organization: MIMOS Berhad X-Mailer: Mozilla 3.04 (Win95; U) MIME-Version: 1.0 To: rem-conf@es.net Subject: Multimedia Asia 1998 - Virtual Commonwealth Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear all, Sorry for this late annoucement as I can only confirm my MBone connection just a moment ago. In conjunction with Multimedia Asia, the annual conference on the Multimedia Super Corridor, the National Information Technology Council (NITC) presents the VIRTUAL COMMONWEALTH. The Virtual Commonwealth at MMA'98 is a dialogue session where issues of governance in the Information Age will be discussed by prominent local and international personalities. With the theme "Governance in an Internetworked World: Towards a Global Civilized Society", the Virtual Commonwealth session presents an opportunity for people to discuss solutions to the problems of a globalized and internet-worked world. Follow this url for more information: http://streamworks.jaring.my/mma98.html or http://propagation.jaring.my/mma98.html Your are welcome to send your questions to the panelists prior to the live session or during the Q&A session. For an overall view of the session content and topics to be discussed at the Virtual Commonwealth session, follow this link: http://streamworks.jaring.my/vircomm-content.html or http://propagation.jaring.my/vircomm-content.html The live session will be broadcasted on 29th September 1998, 2100MYT (GMT+8). Audio: DVI 224.2.227.121/21586 TTL=127 Video: H.261 224.2.211.189/49792 TTL=127 See you there. Regards, JY Luke MIMOS Berhad, Malaysia From rem-conf Mon Sep 28 19:31:11 1998 From rem-conf-request@es.net Mon Sep 28 19:31:10 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zNodO-0005lZ-00; Mon, 28 Sep 1998 18:31:22 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zNodN-0005lP-00; Mon, 28 Sep 1998 18:31:21 -0700 Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id VAA05652 for ; Mon, 28 Sep 1998 21:31:11 -0400 (EDT) Received: (from hgs@localhost) by erlang.cs.columbia.edu (8.9.1/8.9.1) id VAA29424; Mon, 28 Sep 1998 21:31:05 -0400 (EDT) Date: Mon, 28 Sep 1998 21:31:05 -0400 (EDT) From: Henning Schulzrinne Message-Id: <199809290131.VAA29424@erlang.cs.columbia.edu> To: rem-conf@es.net Subject: CFP: Internet Computing/IEEE Network on Internet Telephony List: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Call for Papers for a Joint Issue of IEEE Internet Computing (http://www.computer.org/internet) IEEE Network Magazine (http://www.comsoc.org/socstr/techcom/ntwrk/) --------------------------------------------------------------------- Special Issue on Internet Telephony (May/June 1999) --------------------------------------------------- Submission deadline: November 25, 1998 Guest Editor: Henning Schulzrinne Department of Computer Science Columbia University New York, NY Phone: 212 939 7042 Fax: 212 666 0140 WWW: http://www.cs.columbia.edu/~hgs email: hgs@cs.columbia.edu Internet telephony, that is, using the Internet as a communications infrastructure to replace and enhance existing telephone services, is promising to fundamentally change one of the most basic and familiar communications services. This special issue covers the technology needed to make Internet telephony a reality and the challenges that need to be addressed. This is a joint issue of the IEEE Internet Computing and IEEE Network Magazines. Topics of interest for technical papers include: * quality-of-service specific to large-scale telephony services * charging, billing and customer care * web-centric telephony service enhancements * service creation: applications, languages, tools * interworking with the global switched telephone network (GSTN): gateways, service location, directories * hybrid Internet-PSTN architectures * directory services * signaling * novel applications * embedded systems * management of QOS, services and * security and privacy issues * economic and regulatory impact We are especially interested in research papers that describe real services, software systems and experiments. Work-in-progress papers describing the state of on-going research projects in Internet telephony are also encouraged. Papers should explicate the technical issues related to Internet telephony, rather than just generic multimedia applications. Research papers should demonstrate the feasibility of the approach and describe the state of realization. Case studies and applied papers should discuss the key factors that made the system work and should also mention the pitfalls and problems encountered and how they may be overcome. Submission, Approval, Review, and Acceptance. --------------------------------------------- Authors are requested to send e-mail to the guest-editor, Henning Schulzrinne (hgs@cs.columbia.edu), giving a URL where the guest-editor can review the article, preferably in HTML format with GIF artwork (postscript or pdf format is also accepted). Upon approval by the guest-editor, all feature articles will then undergo a technical peer review consistent with other archival publications. Potential authors may wish to consult the sections on author information and guidelines for reviewers, which are given at http://www.comsoc.org/socstr/techcom/ntwrk. Articles for review should be in HTML or a common format easily read by reviewers. Authors will send all files to an anonymous ftp site provided by the guest editor. When an article consists of a collection of HTML and GIF files, all internal links pointing to this file should be relative. More details on the submission guidelines can be found in http://www.computer.org/internet/edguide.htm and http://www.comsoc.org/socstr/techcom/ntwrk/ Submission Deadline: November 25, 1998 Acceptance Notification: February 1, 1999 Final Manuscripts Due: March 1, 1999 Publication of Completed Special Issue: May/June 1999 http://www.comsoc.org/socstr/techcom/ntwrk/special/schulzrinne.html From rem-conf Tue Sep 29 04:45:38 1998 From rem-conf-request@es.net Tue Sep 29 04:45:38 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zNy6y-0002Hn-00; Tue, 29 Sep 1998 04:38:32 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zNy6x-0002HW-00; Tue, 29 Sep 1998 04:38:31 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA06408; Tue, 29 Sep 1998 07:36:53 -0400 (EDT) Message-Id: <199809291136.HAA06408@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: rem-conf@es.net From: The IESG Subject: Protocol Action: RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+) to Proposed Standard Date: Tue, 29 Sep 1998 07:36:53 -0400 Sender: scoya@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The IESG has approved the Internet-Draft 'RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)' as a Proposed Standard. This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Scott Bradner and Vern Paxson. Technical Summary This protocol specifies an RTP payload header format for carrying video streams transmitted using the 1998 version of ITU-T Recommendation H.263. The format is especially designed for resiliency in the face of packet loss. Working Group Summary This draft was presented at the AVT working group meeting in Washington, DC, and received extended discussion. The draft was revised based on that feedback and presented in Los Angeles where there was consensus for going to Proposed. The draft was subsequently given a working group last call. There was one issue that generated a number of comments, specifically the relationship between this draft and RFC 2190 on the earlier version of the H.263 encoding standard. It was agreed to add a paragraph in the new spec explaining its relationship to RFC 2190, which has been done in this version. There is at least one implementation of the protocol. Protocol Quality Vern Paxson reviewed the protocol for the IESG. Note that this protocol does not replace RFC 2190, which continues to be used by existing implementations, and may be required for backward compatibility in new implementations. From rem-conf Tue Sep 29 10:28:19 1998 From rem-conf-request@es.net Tue Sep 29 10:28:18 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zO3Qq-0006mF-00; Tue, 29 Sep 1998 10:19:24 -0700 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zO3Qo-0006m5-00; Tue, 29 Sep 1998 10:19:22 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id KAA08048; Tue, 29 Sep 1998 10:18:58 -0700 (PDT) Message-Id: <3.0.3.32.19980929101858.00a70210@gumby.cs.berkeley.edu> X-Sender: florissac@gumby.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 29 Sep 1998 10:18:58 -0700 To: rem-conf@es.net From: Florissa Colina Subject: 9/30 Berkeley, Multimedia, Interfaces, and Graphics Seminar Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list
    Use What You Teach: Teaching CSCW Using CSCW Tools James Landay Computer Science Division - EECS UC Berkeley Wednesday September 30, 1998 12:30-2:00 PDT 405 Soda Hall
    Distance learning technology has repeatedly been cited as a way to reduce the cost of advanced education and to bring training to the masses. Drawbacks aside, this technology will be used in many educational settings and it is therefore important for educators to understand its advantages and limitations. Researchers in the field of computer-supported cooperative work (CSCW) have been building research systems for years that support distance learning. To expose students to the difficult issues in this area and to learn more myself, I taught a course on CSCW in the Fall 1997 semester in which we used CSCW tools. In this talk I describe the course structure, the technology we used, and the outcomes of the course. The course website is at: 0000,0000,fefehttp://bmrc.berkeley.edu/courseware/cscw/fall97/index.html. The Mbone addresses are video 224.2.163.7/57076 and audio 224.2.147.61/27202. ____________________________________________ Florissa Colina Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: florissac@bmrc.berkeley.edu From rem-conf Tue Sep 29 13:51:13 1998 From rem-conf-request@es.net Tue Sep 29 13:51:11 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zO6eY-0001WW-00; Tue, 29 Sep 1998 13:45:46 -0700 Received: from mercury.sun.com [192.9.25.1] by mail1.es.net with smtp (Exim 1.81 #2) id 0zO6eW-0001W9-00; Tue, 29 Sep 1998 13:45:44 -0700 Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA16023; Tue, 29 Sep 1998 13:44:43 -0700 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id QAA21048; Tue, 29 Sep 1998 16:44:40 -0400 Received: from bcn.East.Sun.COM by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4) id QAA22411; Tue, 29 Sep 1998 16:44:41 -0400 Received: from pine by bcn.East.Sun.COM (SMI-8.6/SMI-SVR4) id QAA15572; Tue, 29 Sep 1998 16:44:39 -0400 Message-Id: <199809292044.QAA15572@bcn.East.Sun.COM> Date: Tue, 29 Sep 1998 16:44:40 -0400 (EDT) From: Steve Hanna Reply-To: Steve Hanna Subject: Re: Video and Java To: sukeshgg@caip.rutgers.edu Cc: rem-conf@es.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: fMCrFIAYYgzvrmMb+Nvu2A== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Sun has some hot "Java on Solaris" technology that is available as "early access" through the Solaris Developer connection. You have to register, but registration is free. Check out http://www.sun.com/solaris/java/ and look for the following blurb: Download the JDK 1.2 Early Access 4 (Production Release) As the leader in SPECjvm98 performance, this early access release (now supporting Solaris 2.5.1 and 2.6 - SPARC/Intel) provides significantly improved performance and scalability due to an enhanced JVM with improved JIT Compiler, fast thread synchronization and enhanced memory system. Sun also ships a reference platform designed to facilitate portability, but it has less performance, so make sure you are getting something labelled "Production Release." > Date: Thu, 10 Sep 1998 12:12:22 -0400 (EDT) > From: Sukesh Garg > To: rem-conf@es.net > Subject: Video and Java > MIME-Version: 1.0 > > Hi, > I am working on a project that involves sending real-time data over the > n/w using Java. > I have built an application and found the my application to be very slow. > > Is there any implementation available that is fast.... > or any pointers as to increase the speed...(using java) > > Thanks > > Sukesh > > > From rem-conf Tue Sep 29 14:54:16 1998 From rem-conf-request@es.net Tue Sep 29 14:54:15 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zO7gL-0002dQ-00; Tue, 29 Sep 1998 14:51:41 -0700 Received: from el-postino.s-vision.com [207.108.173.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zO7gJ-0002dG-00; Tue, 29 Sep 1998 14:51:40 -0700 Received: by el-postino.s-vision.com with Internet Mail Service (5.5.2232.9) id ; Tue, 29 Sep 1998 15:51:41 -0600 Message-ID: <00D7B108BAFFD011B66D00A0C903629C3A6260@el-postino.s-vision.com> From: Forrest Blair To: potsag@imtc.org, h323implementors@imtc.org, sg16.lbc@research.kpn.com, rem-conf@es.net Subject: H.263 Full PIcture Freezes Date: Tue, 29 Sep 1998 15:51:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Does anyone use H.263 "Full Picture Freeze" and if so what is the application? Thanks in advance, Forrest Blair Sorenson Vision, Inc. From rem-conf Wed Sep 30 12:03:10 1998 From rem-conf-request@es.net Wed Sep 30 12:03:09 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zORKm-0004Qh-00; Wed, 30 Sep 1998 11:50:44 -0700 Received: from ariel.gi.com [168.84.84.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zORKk-0004Q4-00; Wed, 30 Sep 1998 11:50:43 -0700 Received: from procy.gi.com by GI.COM (PMDF V5.1-8 #7516) with SMTP id <01J2F07PSYESHUBO1K@GI.COM> for rem-conf@es.net; Wed, 30 Sep 1998 11:49:40 PDT Received: from cream.gi.com by procy.gi.com (4.1/GIVC1.0) id AA17812; Wed, 30 Sep 1998 11:49:37 -0700 (PDT) Received: by cream.gi.com (SMI-8.6/SMI-SVR4) id LAA06339; Wed, 30 Sep 1998 11:49:36 -0700 Date: Wed, 30 Sep 1998 11:49:36 -0700 From: lalwaney@procy.gi.com (poornima lalwaney) Subject: CFP - Multimedia, Services, Applications and Technologies To: rem-conf@es.net Message-id: <199809301849.LAA06339@cream.gi.com> X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > Multimedia Applications, Services, & Technologies '99 (MAST-99) > in conjunction with ICC 1999, Vancouver, Canada > Sponsor: IEEE Communication Society, Technical Committee on Multimedia > Communications > > The miniconference will include a keynote speech, panel discussions, paper > session, and > applications/demo session by leaders, recognized experts and active > researchers in the field. > > The past few years have seen the Internet explode with multimedia content > and applications > taking advantage of the world-wide-web. High-speed access technologies > (e.g., xDSL and > cable-modems) and content distribution methodologies (e.g., web caching > and mirroring) > are now becoming available which will improve perceived network > performance. The > Internet protocol suite and open standards such as HTML, JAVA, etc. are > emerging as > leading-edge technologies for publishing and delivering multimedia content > (e.g, > video/audio streaming over IP multicast and unicast protocols, images, > text) to business and > residential customers worldwide. > > This mini-conference is intended to serve as an open forum for discussing > state-of-the-art > developments in the exciting field of multimedia applications, services > and technologies. The > emphasis will be on emerging services and applications designed over the > open Internet protocol > suite and web authoring tools. > > http://www.comsoc.org/confs/icc/99/mast.html ----- End Included Message -----