From tal@lists.research.bell-labs.com Mon Feb 14 22:08:48 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02524 for ; Mon, 14 Feb 2000 22:08:47 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix, from userid 21643) id 9CD6F52FA; Mon, 14 Feb 2000 22:08:13 -0500 (EST) To: pint-archive@ietf.org Subject: subscription check (pint@lists.research.bell-labs.com: pint-archive@lists.ietf.org) From: listcheck@lists.research.bell-labs.com Reply-To: listcheck@lists.research.bell-labs.com Message-Id: <20000215030813.9CD6F52FA@lists.research.bell-labs.com> Date: Mon, 14 Feb 2000 22:08:13 -0500 (EST) Sender: tal@lists.research.bell-labs.com This is a subscription check. Automatically generated by ListCheck. DO NOT REPLY UNLESS SOME OF THE INFORMATION BELOW IS INCORRECT. On the mailing list called: pint@lists.research.bell-labs.com You are subscribed by the name: pint-archive@lists.ietf.org [ Note to Ascend/Nortel/BayNetworks employees and companies involved in recent mergers: Is your email address going to change? This message tells you how to update your subscription to this mailing list! Save it for reference! ] DO YOU WANT TO BE REMOVED FROM THIS MAILING LIST? If this is so, please send email to majordomo@lists.research.bell-labs.com with the words unsubscribe pint pint-archive@lists.ietf.org on the first line of the message. A program will read this and remove you from the list. It isn't a smart program, so you have to type exactly what is above. The program also doesn't read the "Subject:" header, so put anything there, or nothing at all. If this does not work, please send email to tal@lists.research.bell-labs.com and he will manually process the request. He can not read your mind so please give him explicit instructions like: "Please remove pint-archive@lists.ietf.org from pint@lists.research.bell-labs.com" You can make it even easier if you forward this message to him with the words "please remove me" at the top of the message. IF YOUR EMAIL ADDRESS IS WRONG: If you are receiving this message, the address is in some ways correct or is forwarded to you. Maybe mail to an old account is being forwarded or your company name has changed and the old address is working temporarily. We would prefer to have your new address. TO CORRECT/CHANGE YOUR EMAIL ADDRESS: Please send email to majordomo@lists.research.bell-labs.com with these two lines of text: unsubscribe pint pint-archive@lists.ietf.org subscribe pint YOURNEWADDRESS@HOST (replace YOURNEWADDRESS@HOST with your new email address) A program will read this and remove you from the list. It isn't a smart program, so you have to type exactly what is above. The program also doesn't read the "Subject:" header, so put anything there, or nothing at all. If the above confuses you, please send email to tal@lists.research.bell-labs.com and request that the change be made. He is not psychic, so please give him explicit instructions like: "I am on pint@lists.research.bell-labs.com as pint-archive@lists.ietf.org but I would rather be on as so_and_so@where.com" LOCAL RE-FORWARDING TO MULTIPLE PEOPLE: You may get this message because someone forwards it to you (and maybe a couple friends) automatically. If this is so, you should talk to them if you want to discontinue your subscription or change your address. IF YOU GET EVERY MESSAGE TWICE: Please send email to tal@lists.research.bell-labs.com ...we'd love to fix the problem. It will be most helpful if you forward the COMPLETE headers from both copies. (Including all those "Received:" headers!) IF YOU ARE GOING ON AN EXTENDED VACATION: If you would like to be removed for a month or more and then be re-added automatically, send the "start and stop" dates and name of the list to tal@lists.research.bell-labs.com and he will do his best to accommodate you. (Students: Please remember this in the spring!) Otherwise, you do not need to reply. On the other hand, PLEASE save save this message for future reference. You will receive this message once for each mailing list that you are on via this server. We will be sending this message about three times a year. Thank you, ListCheck From owner-pint-outgoing@lists.research.bell-labs.com Wed Feb 16 17:50:44 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17869 for ; Wed, 16 Feb 2000 17:50:41 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id E85CC52DE; Wed, 16 Feb 2000 17:42:38 -0500 (EST) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id CF2E952D5; Wed, 16 Feb 2000 17:42:17 -0500 (EST) Delivered-To: pint-local@paperless.dnrc.bell-labs.com Date: Wed, 16 Feb 2000 11:08:11 +0800 From: wmshen Subject: question on video transcoder or gateway To: pint@lists.research.bell-labs.com Message-id: <002401bf782b$0f8710e0$501f67ca@dhx60.telware> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 4.72.3110.5 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_MSNxeR1+fOJV1wOnDAhREg)" X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Priority: 3 Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_MSNxeR1+fOJV1wOnDAhREg) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable Hello, all experts, =20 I am a Ph.D student working on video communication. I am wondering about = how the video transcoder/gateway works between H.261 and H.263, and = between IP network and PSTN or ISDN, in paticular i wonder whether there = is a method by which bitstreams can be translated directly between H.261 = and H.263 format. =20 Who knows the technique details on above topics or where may i get some = useful reference infomation? =20 Any help will be approciated. =20 =20 Weiming Shen =20 --Boundary_(ID_MSNxeR1+fOJV1wOnDAhREg) Content-type: text/html; charset=gb2312 Content-Transfer-Encoding: quoted-printable
Hello, = all=20 experts,
 
I am a = Ph.D student=20 working on video communication. I am wondering about how the video=20 transcoder/gateway works between H.261 and H.263, and between IP network = and=20 PSTN or ISDN, in paticular i wonder whether there is a method by which=20 bitstreams can be translated directly between H.261 and H.263=20 format.
 
Who = knows the=20 technique details on above topics or where may i get some useful = reference=20 infomation?
 
Any help = will be=20 approciated.
 
 
Weiming=20 Shen
 
--Boundary_(ID_MSNxeR1+fOJV1wOnDAhREg)-- --------- This message came from the IETF PINT Working Group Mailing List. From owner-pint-outgoing@lists.research.bell-labs.com Mon Feb 21 06:29:59 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02632 for ; Mon, 21 Feb 2000 06:29:58 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id D6CBA52BB; Mon, 21 Feb 2000 06:27:23 -0500 (EST) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4FEF352C4; Mon, 21 Feb 2000 06:27:23 -0500 (EST) Delivered-To: pint-local@paperless.dnrc.bell-labs.com Message-Id: <200002211126.GAA02570@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: pint@lists.research.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pint-protocol-03.txt Date: Mon, 21 Feb 2000 06:26:05 -0500 Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the PSTN and Internet Internetworking Working Group of the IETF. Title : The PINT Service Protocol:Extensions to SIP and SDP for IP Access to Telephone Call Services Author(s) : S. Petrack, L. Conroy Filename : draft-ietf-pint-protocol-03.txt Pages : 63 Date : 18-Feb-00 This document contains the specification of the PINT Service Protocol 1.0, which defines a protocol for invoking certain telephone services from an IP network. These services include placing basic calls, sending and receiving faxes, and receiving content over the telephone. The protocol is specified as a set of enhancements and additions to the SIP 2.0 and SDP protocols. This document is intended for the PSTN-Internet Interworking (PINT) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at pint@lists.research.bell-labs.com and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pint-protocol-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pint-protocol-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pint-protocol-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000218115119.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pint-protocol-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pint-protocol-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000218115119.I-D@ietf.org> --OtherAccess-- --NextPart-- --------- This message came from the IETF PINT Working Group Mailing List. From owner-pint-outgoing@lists.research.bell-labs.com Mon Feb 21 15:12:51 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15787 for ; Mon, 21 Feb 2000 15:12:50 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 9B76D52E4; Mon, 21 Feb 2000 15:08:28 -0500 (EST) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1DA1952E8; Mon, 21 Feb 2000 15:08:28 -0500 (EST) Delivered-To: pint-local@paperless.dnrc.bell-labs.com Date: Thu, 17 Feb 2000 20:02:18 +0530 (IST) From: Sandeep Sharma Reply-To: Sandeep Sharma To: pint Subject: question on voice over ip Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk hai experts, i am a student and this is my thesis semester. I'm working on voice over ip. I have thought of testing some of the existing protocols and if possible then try to implement using some simulator or so. But the problem is that i'm not able to find some technical stuff needed. i need some technical info which talks about internetworking pstn with ip networks or where can find them. ur help would be of very use to me and appreciated.. thanx sasha --------- This message came from the IETF PINT Working Group Mailing List. From owner-pint-outgoing@lists.research.bell-labs.com Mon Feb 21 21:57:32 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21478 for ; Mon, 21 Feb 2000 21:57:25 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C4B5F52D5; Mon, 21 Feb 2000 21:54:40 -0500 (EST) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 30DD252DE; Mon, 21 Feb 2000 21:54:40 -0500 (EST) Delivered-To: pint-local@paperless.dnrc.bell-labs.com Message-ID: <38B1FA5B.34169FF@bell-labs.com> Date: Mon, 21 Feb 2000 21:54:19 -0500 From: Igor Faynberg Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: pint Cc: sob@harvard.edu Subject: Editors' Response to the IESG Comments X-Priority: 1 (Highest) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Ladies and Gentlemen: In our State of the WG message, Steve and I informed you about the IESG comments in the Last Call process. We are happy to say now that these comments have been addressed by our editors--severe flu, terrible snowstorms, and heavy travel in addition to day jobs--notwithstanding. The new (version 3) PINT Protocol draft is now available (please see http://www.ietf.org/internet-drafts/draft-ietf-pint-protocol-03.txt; you can also pick it up from the IETF PINT page). In addition, Lawrence and Scott--to whom many thanks!--provided detailed responses to specific comments and suggestions as well as the summary of changes, which I am attaching to this note. Since we are not quite done with the immediate charter work, Steve and I see no reason to meet in Adelaide. With best regards, Igor ATTACHMENT: Lawrence's responses (marked LWC) Re mimetype comments: LWC> Many thanks for the pointer to RFC2387. LWC> multipart/related seems to be designed to indicate the kind of LWC> situation we have in PINT, where sub-parts holding content are to be LWC> processed along with a sub-part that holds the session description. LWC> I've added a recommendation that it should be used, and a reference to LWC> the RFC. Re. minor typos: LWC> Thanks for pointing them out. Fixed throughout. e.g. I've corrected LWC> the spelling of call center. Duh! LWC> Likewise, have changed should to SHOULD, fail to decline/reject, and LWC> other small changes as suggested. LWC> The rest is intended to be English, so if there are still LWC> lapses into Swahili, please remind me. LWC> On the same theme, I've tweaked the descriptions that follow a LWC> couple of the examples; they were making assumptions that were not LWC> warranted for the examples given. Re. layout: LWC> The document should now be in valid layout. Re. major typos: LWC> I must appologise for a great deal of confusion spread by my missing LWC> the outdated "BYE" references thoughout the section on SUB/NOT/UNSUB. LWC> These should ALL have been replaced with UNSUB. LWC> The state model is really that simple, honest. I have not ASCIIfied LWC> the SUB/NOT/UNSUB message sequence charts (I have then in PDF format LWC> if that's useful, but they lose a lot in the conversion to ASCII). Re.clarity of descriptions LWC> I've taken the oppertunity (fixing major typo) to tweak the text in LWC> 3.5.3 and in 3.5.8.; I hope that they are clearer now. Re. Introduction LWC> Similarly, the descrition of what PINT is trying to do in the LWC> introduction has thrown some people, so I've tidied it up. LWC> I've also put in a pointer to the summary lists in section 3.2, LWC> so people can jump right to that rather than wading through LWC> the service descriptions. Re. Request-to-Fax and Request-to-Hear-Content service descriptions: LWC> The service descriptions are a little terse, and so are open LWC> confusion. I've added a couple of sentences to the Request-to- LWC> -Hear-Content description, emphasising that how the PINT request LWC> is formulated is not our problem, and the aim of a user is to LWC> hear a translation of some content, or to have that content spoken. LWC> I believe that it's called Request To Hear Content in the ITU LWC> service description (if you look, you may notice some similarities) LWC> so unless there's a good reason not to, perhaps it would be a good LWC> idea to keep the heading name as is. LWC> The Request-to-Fax description has obviously bemused people. The LWC> aim is to ask for a fax to be sent to a fax machine that appears LWC> to be connected to the PSTN. It was originally two services (Click LWC> -to-Fax and Click-to-Fax-Back) and I believe that it still is LWC> described as two services in the ITU docs. LWC> The goal of either variant is to have a facsimile generated from LWC> some content appear on a fax machine on the PSTN. If the content LWC> is originally available "on the Internet" then by definition it LWC> must be accessible to the PINT Gateway - it has to be transferred LWC> to the destination fax machine somehow. If the information is LWC> held on the PSTN, then it's a case of specifying that content and LWC> where the facsimile is to be sent. The effect is the same, however. Re. the use of UNSUB from either partner to end the monitoring session: LWC> There was a discussion of the use of NOTIFY with Expires:0 to LWC> indicate that the sender (the PINT Gateway that was passing LWC> status messages "up" to the PINT Client) wanted to close the LWC> monitoring session. LWC> My concern was that the Gateway might WELL want to send up LWC> a status message that reported only transient state (like a "meter LWC> pulse" or an "errored second") rather than something that has an LWC> extended duration (like "the call has started"). These NOTIFY LWC> messages could be indicated by an Expires of 0, with a similar LWC> interpretation to "Expires:0" or "no-cache" in HTTP. LWC> Being able to indicate the period of validity of a notification LWC> seems to be "a good idea" to me; however, this precludes its use LWC> to terminate a monitoring session. LWC> The PINT Client terminates the session by sending an UNSUB message LWC> so having the PINT Gateway do the same seemed a good solution. LWC> To summarise, use of Call-ID to start a monitoring session, and LWC> the use of a NOTIFY with Expires:0 is perfectly possible. It even LWC> reduces the packet traffic for the case where the Entity asking for LWC> the monitoring session is the one that made the service request in LWC> the first place. However, this comes at a cost; in the case of LWC> NOTIFY with Expires:0, there's no easy way to indicate a transient LWC> status notification, and in the case of using Call-ID to start the LWC> session, the Gateway must support another method when another UAS LWC> wants to start a monitoring session (like, for example, a Server LWC> that monitors corporate call usage). LWC> This is just a re-iteration of the mailing list posts and drafts of LWC> the last couple of years; if anyone interprets it differently then LWC> perhaps we really DO need to expand the descriptions. Scott's responses (marked SBP): 1. State Machine of SxBSCRIBE/UNSxBSCRIBE SBP> The typos in the earlier draft obscured the fact that the state-machine SBP> of SxBSCRIBE/UNSxBSCRIBE is now identical to that of INVITE/BYE. This SBP> was a major simplification. Anyone who understands the vanilla INVITE/BYE SBP> message flow can understand SxBSCRIBE/UNSxBSCRIBE. We added a sentence SBP> in the newest draft to make this explicit. SBP> We also added a sentence to make it clear that a SUBSCRIBE is sent to SBP> the PINT gateway directly (if that is known from a previous Contact: SBP> field) or to the server which got the original INVITE (if there was SBP> no previous Contact: field). SBP> The suggestion that one use a NOTIFY with Expires:0 to mean "UNSUBSCRIBE" SBP> was discussed at length in the mailing list, but the consensus was SBP> that one definitely needs an explicit "UNSUBSCRIBE" message. This SBP> is because any other possibility already has meaning: SBP> NOTIFY with Expires:0 means that the NOTIFY is only guaranteed to be SBP> valid this instant (needed to show transient states in the PSTN). SBP> SUBSCRIBE with Expires:0 means that the sxubscriber wants to get a SBP> single NOTIFY and then no more (Needed to allow clients to probe SBP> the state of a call once). SBP> The nice thing about this solution is that SUB/UNSUB has the same state SBP> machine as INVITE/BYE. --------- This message came from the IETF PINT Working Group Mailing List. From owner-pint-outgoing@lists.research.bell-labs.com Wed Feb 23 06:37:23 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18503 for ; Wed, 23 Feb 2000 06:37:23 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id B6D9552C4; Wed, 23 Feb 2000 06:33:39 -0500 (EST) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 147D252DA; Wed, 23 Feb 2000 06:33:38 -0500 (EST) Delivered-To: pint-local@paperless.dnrc.bell-labs.com From: "Thomas Magedanz" To: , , , , Subject: CFP: Computer Networks Special Issue on IN and IP Convergence Date: Wed, 23 Feb 2000 12:02:15 +0100 Message-ID: <000f01bf7ded$7302fcc0$ec4e25c3@ikvintern.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Ladies and Gentlemen! Computer Networks Journal plans to publish in February 2001 a special issue on "Voice / Data Integration - A Snapshot of Intelligent Network and Interent Convergence". Guest editors: T. Magedanz (IKV++) and M. Smirnov (GMD FOKUS) Deadline for submission is June 2000! Maybe a good candidate for disseminating your results! For more infos look at: http://www.fokus.gmd.de/events/IN-Internet/ Best regards, Thomas Magedanz (magedanz@ikv.de) IKV++ GmbH, Bernburger Str. 24-25, D-10963 Berlin, Germany --------- This message came from the IETF PINT Working Group Mailing List. From owner-pint-outgoing@lists.research.bell-labs.com Wed Feb 23 10:49:59 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24379 for ; Wed, 23 Feb 2000 10:49:57 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 1FA4F52D6; Wed, 23 Feb 2000 10:47:24 -0500 (EST) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8F43852DA; Wed, 23 Feb 2000 10:47:23 -0500 (EST) Delivered-To: pint-local@paperless.dnrc.bell-labs.com Message-ID: From: "Tom-PT Taylor" To: wmshen , pint@lists.research.bell-labs.com Subject: RE: question on video transcoder or gateway Date: Wed, 23 Feb 2000 09:44:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7E14.D26DDFC8" Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF7E14.D26DDFC8 Content-Type: text/plain The video experts responsible for the H.261 and H.263 Recommendations are in ITU-T Study Group 16. In particular, you may want to address your questions to the Rapporteur, Gary Sullivan . > -----Original Message----- > From: wmshen [SMTP:wmshen@public.wh.hb.cn] > Sent: Tuesday, February 15, 2000 10:08 PM > To: pint@lists.research.bell-labs.com > Subject: question on video transcoder or gateway > > Hello, all experts, > > I am a Ph.D student working on video communication. I am wondering about > how the video transcoder/gateway works between H.261 and H.263, and > between IP network and PSTN or ISDN, in paticular i wonder whether there > is a method by which bitstreams can be translated directly between H.261 > and H.263 format. > > Who knows the technique details on above topics or where may i get some > useful reference infomation? > > Any help will be approciated. > > > Weiming Shen > ------_=_NextPart_001_01BF7E14.D26DDFC8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: question on video transcoder or gateway

The video experts = responsible for the H.261 and H.263 Recommendations are in ITU-T Study = Group 16.  In particular, you may want to address your questions = to the Rapporteur, Gary Sullivan = <garysull@microsoft.com>.

    -----Original Message-----
    From:   wmshen [SMTP:wmshen@public.wh.hb.cn]
    Sent:   Tuesday, February 15, 2000 10:08 PM
    To:     pint@lists.research.bell-labs.com
    Subject:       = question on video transcoder or = gateway

    Hello, = all experts,
    =A0
    I am a = Ph.D student working on video communication. I am wondering about how = the video transcoder/gateway works between H.261 and H.263, and between = IP network and PSTN or ISDN, in paticular i wonder whether there is a = method by which bitstreams can be translated directly between H.261 and = H.263 format.

    =A0
    Who = knows the technique details on above topics or where may i get some = useful reference infomation?
    =A0
    Any = help will be approciated.
    =A0
    =A0
    Weiming Shen
    =A0

------_=_NextPart_001_01BF7E14.D26DDFC8-- --------- This message came from the IETF PINT Working Group Mailing List. From owner-pint-outgoing@lists.research.bell-labs.com Wed Feb 23 14:29:56 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00905 for ; Wed, 23 Feb 2000 14:29:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id B866A52DC; Wed, 23 Feb 2000 14:27:23 -0500 (EST) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3EAED52E0; Wed, 23 Feb 2000 14:27:23 -0500 (EST) Delivered-To: pint-local@paperless.dnrc.bell-labs.com X-Authentication-Warning: adsl-151-203-17-31.metatel.office: scott.petrack owned process doing -bs Date: Wed, 23 Feb 2000 09:29:13 -0500 (EST) From: Scott Petrack X-Sender: scott.petrack@adsl-151-203-17-31.metatel.office To: pint@lists.research.bell-labs.com Subject: New draft-ietf-pint-protocol-04.txt released Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk I just submitted a new revision of the pint-protocol, which contains some small revisions included as a result of further IESG review of the 03 draft. The changes made are as follows: 1. The name "Request to Fax" is now "Request to Fax Content" 2. The name "Request to Hear Content" is now "Request to Speak/Play/Send Content" 3. The MUST in the definition of Request to Fax Content has been changed to a MAY. (The draft has such an example itself at the end of section 3.4.2.3). 4. Some clarifying language about the the SUBSCRIBE/UNSUBSCRIBE state machine has been added. --------- This message came from the IETF PINT Working Group Mailing List. From owner-pint-outgoing@lists.research.bell-labs.com Thu Feb 24 06:33:22 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25946 for ; Thu, 24 Feb 2000 06:33:22 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 91CDA52EA; Thu, 24 Feb 2000 06:29:23 -0500 (EST) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1334452EB; Thu, 24 Feb 2000 06:29:22 -0500 (EST) Delivered-To: pint-local@paperless.dnrc.bell-labs.com Message-Id: <200002241127.GAA25843@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: pint@lists.research.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pint-protocol-04.txt Date: Thu, 24 Feb 2000 06:27:02 -0500 Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the PSTN and Internet Internetworking Working Group of the IETF. Title : The PINT Service Protocol:Extensions to SIP and SDP for IP Access to Telephone Call Services Author(s) : S. Petrack, L. Conroy Filename : draft-ietf-pint-protocol-04.txt Pages : 63 Date : 23-Feb-00 This document contains the specification of the PINT Service Protocol 1.0, which defines a protocol for invoking certain telephone services from an IP network. These services include placing basic calls, sending and receiving faxes, and receiving content over the telephone. The protocol is specified as a set of enhancements and additions to the SIP 2.0 and SDP protocols. This document is intended for the PSTN-Internet Interworking (PINT) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at pint@lists.research.bell-labs.com and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pint-protocol-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pint-protocol-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pint-protocol-04.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: <20000223140944.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pint-protocol-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pint-protocol-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000223140944.I-D@ietf.org> --OtherAccess-- --NextPart-- --------- This message came from the IETF PINT Working Group Mailing List. From owner-pint-outgoing@lists.research.bell-labs.com Mon Feb 28 14:28:49 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18137 for ; Mon, 28 Feb 2000 14:28:48 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 1CBB252E0; Mon, 28 Feb 2000 14:22:49 -0500 (EST) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2C45352EB; Mon, 28 Feb 2000 13:59:12 -0500 (EST) Delivered-To: pint-local@paperless.dnrc.bell-labs.com Message-Id: <200002270923.MAA05999@ncc.moc.kw> Date: 27 Feb 00 12:14:00 +-0300 From: "CA$HFLOWEB" To: Subject: Do You Want to Be a Millionaire? Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk Dear , Have you ever sat in front of your PC and thought that there must be some way to use this powerful piece of technology to make extra money, but didn't have slightest idea how to go about doing it? Welcome to the world of Mail Order! Now before you get the idea that this will involve a lot of stamp-licking and trips to the post office, let me say that this business is not like the traditional mail-ordering business. Instead of a lot of paperwork, your PC will be accomplishing the bulk of the work much faster and easier than if it was done manually. The total investment for this opportunity is $5.00 (no kidding!) and the cost of five postage stamps. The rest of the work will be done by your PC, and will only involve a small amount of time behind the keyboard. But once again, I'd like to ask that you follow the instructions carefully. The success or failure of this plan depends on the honesty and integrity of its participants. If the plan is followed to the letter, it cannot fail. go to the following link http://www.cashfloweb.freeservers.com. Once you are there, download the program from the main page and start making money. Best Regards, CA$HFLOWEB --------- This message came from the IETF PINT Working Group Mailing List.