- sg16-avd - lists.packetizer.com

Outcome of the SG16 meeting
by Sakae OKUBO 22 Nov '00

22 Nov '00

Dear SG16 experts, The following output documents from the last week SG16 meeting have been placed at http://standard.pictel.com/ftp/avc-site/0011_Gen/ WP2_Report_001117.zip Report of WP2/16 * WP2_Report_Part_I.doc General, Q1, Q11, Q12, Q13, Q14 * WP2_Report_Part_II.doc Recs for "consent" and texts for approval * WP2_Report_Annex_1.doc Status of Recommendations * WP2_Report_Meetings.doc Planned Rapporteurs meetings H323v4-final_001117.zip H.323 v4 * H.323v4-wcm.… [View More]

1 1

Re: Request of uploading
by Mike Nilsson 22 Nov '00

22 Nov '00

> The decided Version 7 of H.245 has been uploaded to the ftp site ( > ftp://standard.pictel.com/avc-site/Incoming/H245Version7.zip ) > > This will in due course be moved to another directory, probably, > ftp://standard.pictel.com/avc-site/0011_Gen/ > > > Best regards > > Mike Nilsson > > -------------------- > Mike Nilsson > Multimedia Applications > B81 Room 102 pp14 > BT Advanced Communications Technology Centre > Adastral Park, Martlesham … [View More]

1 0

Uploaded H.248 documents
by Christian Groves 22 Nov '00

22 Nov '00

G'Day all, I've uploaded the outputs of the Geneva SG16 meeting: H248_Annex_L.zip H248_Implementors_guide_approved.zip h248_annex_H_decided.zip h248_annex_i_decided.zip h248_annex_k_decided.zip H248_annex_n_draft.zip These are available as both as doc & pdf in the following directory: ftp://standard.pictel.com/avc-site/Incoming/ Cheers, Christian ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

[Fwd: I-D ACTION:draft-bouwen-megaco-isdn-bcp-00.txt]
by Christian Groves 22 Nov '00

22 Nov '00

FYI. Some work occuring on ISDN Gateways using Sigtran and Megaco. Cheers, Christian -------- Original Message -------- Subject: I-D ACTION:draft-bouwen-megaco-isdn-bcp-00.txt Date: Tue, 21 Nov 2000 05:53:36 -0500 From: Internet-Drafts(a)ietf.org Reply-To: Internet-Drafts(a)ietf.org To: IETF-Announce: ; --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Best Current Practice for Megaco-Sigtran Interaction … [View More] in ISDN Access Gateways Author(s) : J. Bouwen Filename : draft-bouwen-megaco-isdn-bcp-00.txt Pages : 10 Date : 20-Nov-00 A Media Gateway with ISDN terminations will use both Megaco [1] and Sigtran protocols for communication with the Media Gateway Controller. In an ISDN Access Gateway the media carrying B-channels are controlled by the Media Gateway Controller using Megaco, while the User-to-Network signalling running over the D-channels will be relayed to the Media Gateway Controller using Sigtran protocols (IUA [3] over SCTP [2]). At the moment, in the absence of appropriate specifications, the Megaco and Sigtran protocols may interact in different ways in the Access Gateway, leaving room for non-interoperable solutions. This draft proposes a set of guidelines for the Megaco-Sigtran interworking, documenting a best current practice for ISDN Access Gateways. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bouwen-megaco-isdn-bcp-00.txt ======================================================================= A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensions to Megaco to support Data in an ISDN D-channel Author(s) : J. Bouwen Filename : draft-bouwen-megaco-isdn-data-00.txt Pages : Date : 20-Nov-00 In ISDN interfaces the D-channel is used to transport the Q.931 signalling messages. In addition, the D-channel can transport packet data for user-to-user communication. The Megaco protocol specification has to be extended to support data in an ISDN D- channel. More specifically, ephemeral terminations on top of physical ISDN terminations have to be allowed, and support for the ISDN addressing scheme has to be added to refer to the data streams in the D-channel. This draft defines the required additional functionality, that could be part of the second version of the Megaco protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bouwen-megaco-isdn-data-00.txt ======================================================================= A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ISDN Package for Megaco Author(s) : J. Bouwen Filename : draft-bouwen-megaco-isdn-pack-00.txt Pages : 5 Date : 20-Nov-00 This draft introduces a Megaco package to support voip access gateways with ISDN terminations. The package defines TerminationState properties for ISDN terminations, and events/signals that are to be used for the layer 1 activation/deactivation procedure for ISDN basic interfaces. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bouwen-megaco-isdn-pack-00.txt ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com [View Less]

1 0

Re: Audio Codec
by Roni Even 21 Nov '00

21 Nov '00

Hi, It is allowed to change codec during the call. One reason is for sending announcements. This can be done either be replacement for procedure or by using zero cap set. Those procedures are described in H.323 standards. Roni Even -----Original Message----- From: Martin [mailto:martin@HELLOSOFT.COM] Sent: Tuesday, November 21, 2000 8:51 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Audio Codec Hi, As it is very clear that any End Point may operate in specified set of capabilities … [View More]

1 0

Audio Codec
by Martin 21 Nov '00

21 Nov '00

Hi, As it is very clear that any End Point may operate in specified set of capabilities depending on the policies or bit rate or whatever. When the call is in proceed on a particular codec, what are the factors which decide on changing to a new codec ? Is user allowed to change codec when the call is in proceed ? ( Assuming that the other end point indicated MaxPendingReplacementFor capability ) Can anyone help me in this regard ? thanks Martin D.

1 0

AW: questions concerning H.450 Supplementary Services
by Horvath Ernst 20 Nov '00

20 Nov '00

Dear Mr. Bandow, regarding your first question, the H.323 terminal will ignore the complete H4501Apdu if it has no H.450 support at all. If it supports H.450.1 but not the specific feature, the content of the H4501Apdu will be unknown to the terminal. In this case the reaction depends on the interpretationPdu field; default is to send a rejectApdu (see H.450.1 for details). regarding your second question, it is certainly allowed to divert to a terminal behind a gateway. Whether the gateway … [View More]

1 0

questions concerning H.450 Supplementary Services
by Wolfgang Bandow 20 Nov '00

20 Nov '00

Dear H.450-Experts, let me please put 2 questions concerning the H.450 Supplementary Services. H.323 says that the support of H.450 is optional. How shall a H.323 terminal not supporting a particular H.450 service react on receiving an unexpected signal or apdu respectively? Is H.450 Call Diversion restricted to H.323 terminals or is it also permitted to divert a call to a terminal which can exclusively be reached via a gateway? In the latter case: shall the gateway omit any restriction … [View More]

1 0

Positive decisiions in ITU-T SG 16 complete the basic work with Total Conversation
by Gunnar Hellstrom 19 Nov '00

19 Nov '00

A meeting in ITU-T SG16 Multimedia Systems and Services, was closed on November 17, 2000, marking the end of a successful four year long study period and the beginning of a new. It has been a pleasure to lead Question 9, "Accessibility to Multimedia" to good achievements in a stimulating and co-operative environment. I want to thank the experts in all SG16 groups for the work during the study period leading to the situation that: -We have real time text conversation specified in all major … [View More]multimedia protocol environments. (H.320,H.323,H,324,T.120) -We have a service description for Total Conversation, being conversational multimedia including video, text and voice,(F.703). -We have one universal presentation protocol for real time text conversation (T.140), also applicable to the IP environment (IETF RFC2793). -We have maintained and improved the Recommendation for text telephony modems created during the previous study period, so that it now forms the natural base for harmonising Text Telephony, (v.18) -We have a service description recognizing Text Telephony (F.703). -We have the specification of how gateways connecting text conversation in different environments can be controlled (H.248 Annex F) -We have brought awareness about the needs in video communication for sign language and lip reading to the video coding and multimedia system experts. (H series Supplement 1 ) All these achievements are intended to be useful for all, and essential for people who have no or little use of voice communication because of a disability in hearing or speech. With these basic Recommendations for accessibility completed, we are now prepared to accept proposals for new work with Accessibility to Multimedia services, systems and terminals. ---------------------------------------------------------------------------- ---------------- Report from the meeting ----------------------- For Q9/16, "Accessibility to Multimedia", this meeting resulted in a set of positive decisions, that mark the end of a series of actions intended to enable higher accessibility to conversational multimedia. Q9 is seen as a "Horisontal" question, and will be transformed to Question H/16 "Accessibility to Multimedia" in the new study period. "Horisontal" means that most work items are performed in close co-operation with other questions handling specific technologies. The decisions related to Q.9 accessibility goals in this meeting were: 1. Text telephone modem Recommendation V.18 ---------------------------------------------------------------------------- --------- Q.9 own work item. Version 3 of V.18 Operation and Interworking procedures for the DCE:s in the text telephone mode. Main improvements: Use full V.8 connection procedure, for better opportunities to negotiate the connection, and include the changes earlier published in implementor guides and appendices. 2. Gateway control packages H.248 Annex F ---------------------------------------------------------------------------- -- With Q.14 and "Q.Fax": H.248 Annex F, Text Conversation, Facsimile and Call Discrimination packages. The control of a Media Gateway capable of handling Fax, multimedia Text Conversation and Text Telephony, with general call discrimination between different modem type connections. 3. Multimedia service descriptions; F.700, F.703 ---------------------------------------------------------------------------- -- With Q.1: F.700 revision of Annex A to include a definition of the medium conversational text. F.703 Multimedia Conversation Service Description Inclusion of a Description of Total Conversation as a combination of Video, Text and Voice. Inclusion of a Description of Text Telephony as real time character by character text conversation with optional opportunity to use voice. 4. Managed objects for modems; V.59 ---------------------------------------------------------------------------- --------- With Q.4: V.59 Managed objects for modems Inclusion of message definitions for V.18 management. 5. DCE control; V.250 ---------------------------------------------------------------------------- --------- With Q.7: V.250 Implementors guide Revision of the commands and responses for control of V.18 modems. ---------------------------------------------------------------------------- --------- The group has only one open issue, about an alternative proposal for simultaneous voice and text in PSTN text telephony. A usability report is expected. The full report is in document TD73(plen) of the meeting. Thank you all! **************************************** Gunnar Hellström Ericsson Radio Systems AB tel +46 708 204 288 ***************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com [View Less]

1 0

Request of uploading
by Sakae OKUBO 17 Nov '00

17 Nov '00

Dear Editors, Could you please upload the final edited documents for decision, approval, "consent", "previously intended determination" to the PictureTel site and announce through the reflector? Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) … [View More]

1 0

Re: Updated presentation - H.323 overview
by Tam, Mimi 16 Nov '00

16 Nov '00

Dear Boaz, If I may ask you a question, how did you get a web page in the http://people.itu.int space? I am with the SG16 and have been a ties member for quite a while. Is it possible for me to get a web page there as well? Sorry to bother you. I'd greatly appreciate your help. Thanks very much...Mimi Tam Mimi Tam Davox Corp. Technical Director 6 Technology Park Drive Westford, MA 01886 +1 978 952 0695 -----Original Message----- From: Boaz Michaely [mailto:boaz.michaely@TIES.ITU.INT] … [View More]

1 0

List Status: Worst is over?
by Meyer, Greg W 15 Nov '00

15 Nov '00

The ITU-SG16 list shut down yesterday because of all the virus alerts. After freeing the list today, several more alerts came in but they appear to be ones that were queued, not new ones. I've changed some characteristics of the list to stem the chances of this happening again. First, as Chip Sharp pointed out, the Reply-To field will now point to the Sender (originator) of the message, not the list. Also, for a temporary period, I will moderate the list to insure more virus alerts and any … [View More]

1 0

Updated presentation - H.323 overview
by Boaz Michaely 15 Nov '00

15 Nov '00

Dear experts, I've updated the H.323 overview presentation on my ITU page. Please take a moment to review it, and notify me of mistakes and omissions. (note specific slides about changes in H.323 and H.225.0 v4) Thanks, Boaz Michaely http://people.itu.int/~michaely ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Virus Alerts & Loops
by Meyer, Greg W 15 Nov '00

15 Nov '00

Hello: You probably noticed that your mailboxes are full of virus alerts from various companies' mail servers. The incident started with an inappropriate conference notice (not directly ITU-SG16 related). The sender has been notified. You should heed the virus notice and not open that attachment. The Bosch (Tenovis) mail server created an infinite loop so I was forced to restrict the ITU-SG16 list so that only subscribers can post mail. I apologize for any inconvenience. I will re-enable the … [View More]

1 0

Please fix this list server
by Chip Sharp 14 Nov '00

14 Nov '00

One way to avoid cascading auto-mail meltdowns is to change the list server so it does not replace the "Reply-To" address with the list name address. Thus, anyone that selects "reply" to an email will send the reply back to the original sender. "reply all" will send the reply to the original sender and the list. It seems that many companies have now instituted anti-virus filters that automatically generate a message back to the "Reply-To" address when they receive a virus. Can this list … [View More]setup be changed to this mode? Thanks, Chip At 01:49 AM 11/15/00 +0000, you wrote: >****** Message from InterScan E-Mail VirusWall NT ****** > >Sent >>> RCPT TO:<Marek.Przybyszewski(a)DE.BOSCH.COM> >Received <<< 550 5.7.1 Unable to relay for Marek.Przybyszewski(a)de.bosch.com > >Could not deliver mail to this user. > >***************** End of message *************** >Received: (from uucp@localhost) > by gwa.fe.bosch.de (8.9.1/8.9.1) id CAA02481 > for <Marek.Przybyszewski(a)DE.BOSCH.COM>; Wed, 15 Nov 2000 02:48:37 > +0100 (MET) >Received: from mailbag.cps.intel.com( 192.102.199.72) by gwa.fe.bosch.de >via smap (V2.1) > id xma002473; Wed, 15 Nov 00 02:47:33 +0100 >Received: from mailbag.intel.com (mailbag.cps.intel.com [192.102.199.72]) > by mailbag.cps.intel.com (8.9.3/8.9.1/d: relay.m4,v 1.6 > 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id RAA28705; > Tue, 14 Nov 2000 17:41:22 -0800 (PST) >Received: from MAILBAG.INTEL.COM by MAILBAG.INTEL.COM (LISTSERV-TCP/IP release > 1.8d) with spool id 1468 for ITU-SG16(a)MAILBAG.INTEL.COM; Tue, > 14 Nov > 2000 17:41:21 -0800 >Received: from gwa2.fe.bosch.de (gwa2.fe.bosch.de [194.39.218.2]) by > mailbag.cps.intel.com (8.9.3/8.9.1/d: relay.m4,v 1.6 1998/11/24 > 22:10:56 iwep Exp iwep $) with ESMTP id RAA27895 for > <ITU-SG16(a)mailbag.cps.intel.com>; Tue, 14 Nov 2000 17:31:19 -0800 > (PST) >Received: (from uucp@localhost) by gwa2.fe.bosch.de (8.10.2/8.10.2) id > eAF1TCw09153 for <ITU-SG16(a)mailbag.cps.intel.com>; Wed, 15 Nov 2000 > 01:29:12 GMT >X-Authentication-Warning: gwa2.fe.bosch.de: uucp set sender to > <virus-protection(a)bosch.com> using -f >Received: from fez8017.fe.internet.bosch.com(virus-in.fe.internet.bosch.de > 10.4.4.17) by gwa2.fe.bosch.de via smap (V2.1) id xma008913; > Wed, 15 > Nov 00 01:29:05 GMT >InterScan-Notification: yes >MIME-Version: 1.0 >Content-Type: multipart/mixed; > boundary="----=_NextPart_000_974251217_B78506032.R82506026" >Message-ID: <200011150129.eAF1TCw09153(a)gwa2.fe.bosch.de> >Date: Wed, 15 Nov 2000 02:20:17 +0100 >Reply-To: Mailing list for parties associated with ITU-T Study Group 16 > <ITU-SG16(a)mailbag.cps.intel.com> >Sender: Mailing list for parties associated with ITU-T Study Group 16 > <ITU-SG16(a)mailbag.cps.intel.com> >From: virus-protection(a)BOSCH.COM >Subject: InterScan eManager Content Management Notification! (Attachment > Removal) >Comments: To: ITU-SG16(a)mailbag.cps.intel.com >To: ITU-SG16(a)mailbag.cps.intel.com > >Content-Type: text/plain; > charset="iso-8859-1" >X-MIME-Autoconverted: from 8bit to quoted-printable by >mailbag.cps.intel.com id RAA28705 > >******Message from InterScan E-Mail VirusWall NT****** > >The following mail was blocked by InterScan eManager Content Management. > >Source mailbox: <ITU-SG16(a)mailbag.cps.intel.com> >Destination mailbox(es): ><Bjoern.Soelch(a)TENOVIS.COM>,<Axel.Niebuhr(a)TENOVIS.COM> >Policy: Attachment Removal >Attachment file name: Navidad.exe - application/x-msdownload >Action: Replaced with text > >Attached files with executable extension have been deleted, (i.e. *.exe). >Ausführbare Attachments wurden gelöscht (z.B. *.exe) > >******************* End of message ******************* >Received: (from uucp@localhost) > by gwa.fe.bosch.de (8.9.1/8.9.1) id CAA26146; > Wed, 15 Nov 2000 02:28:57 +0100 (MET) >Received: from mailbag.cps.intel.com( 192.102.199.72) by gwa.fe.bosch.de >via smap (V2.1) > id xma026048; Wed, 15 Nov 00 02:28:53 +0100 >Received: from mailbag.intel.com (mailbag.cps.intel.com [192.102.199.72]) > by mailbag.cps.intel.com (8.9.3/8.9.1/d: relay.m4,v 1.6 > 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id RAA27603; > Tue, 14 Nov 2000 17:20:47 -0800 (PST) >Received: from MAILBAG.INTEL.COM by MAILBAG.INTEL.COM (LISTSERV-TCP/IP release > 1.8d) with spool id 1414 for ITU-SG16(a)MAILBAG.INTEL.COM; Tue, > 14 Nov > 2000 17:20:43 -0800 >Received: from netsys.kaist.ac.kr (netsys.kaist.ac.kr [143.248.148.90]) by > mailbag.cps.intel.com (8.9.3/8.9.1/d: relay.m4,v 1.6 1998/11/24 > 22:10:56 iwep Exp iwep $) with ESMTP id RAA27507; Tue, 14 Nov 2000 > 17:10:37 -0800 (PST) >Received: from nice.etri.re.kr (nice.etri.re.kr [129.254.17.14]) by > netsys.kaist.ac.kr (8.9.3/8.9.3) with ESMTP id JAA21427 for > <pv_99(a)netsys.kaist.ac.kr>; Wed, 15 Nov 2000 09:05:35 +0900 >Received: from ghlee (ghlee.etri.re.kr [129.254.72.107]) by nice.etri.re.kr > (8.9.3/8.9.3) with SMTP id JAA10399 for <pv_99(a)netsys.kaist.ac.kr>; > Wed, 15 Nov 2000 09:21:33 +0900 (KST) >MIME-Version: 1.0 >Content-Type: multipart/mixed; > boundary="----=_NextPart_000_002B_01C04EEB.2D813F20" >X-Priority: 3 (Normal) >X-MSMail-Priority: Normal >X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) >X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 >Importance: Normal >Message-ID: <NEBBKFGEOLBEAFHGPDNAEEEBCAAA.ghlee(a)nice.etri.re.kr> >Date: Wed, 15 Nov 2000 10:02:35 +0900 >Reply-To: Mailing list for parties associated with ITU-T Study Group 16 > <ITU-SG16(a)mailbag.cps.intel.com> >Sender: Mailing list for parties associated with ITU-T Study Group 16 > <ITU-SG16(a)mailbag.cps.intel.com> >From: ghlee <ghlee(a)NICE.ETRI.RE.KR> >Subject: Extension of paper submission deadline of PV2001 (Nov. 30, 2000) >Comments: To: "pv(a)netsys.kaist.ac.kr" <pv_99(a)netsys.kaist.ac.kr> >To: ITU-SG16(a)mailbag.cps.intel.com ------------------------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems "The best way to pick a lock is with a key." http://www.netaid.org ------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com [View Less]

1 0

Extension of paper submission deadline of PV2001 (Nov. 30, 2000)
by ghlee 14 Nov '00

14 Nov '00

<<APOLOGIES TO THOSE WHO RECEIVE THIS EMAIL MORE THAN ONCE.>> Due to the large number of requests for extensions we have extended the deadline of paper submission to PV 2001 until November 30, 2000. Inviatation to PV(Packet Video Workshop) 2001 : 30 April - 1 May 2001, Kyongju, Korea The 11th International Packet Video Workshop (PV 2001) will be held on 30 April - 1 May 2001 in Kyongju, Korea, which was the capital city of ancient Korea (A.D 676 - A.D 935), located in … [View More]

1 0

PCS2001 Final Call for Papers
by ghlee 14 Nov '00

14 Nov '00

Please find attached Final Call for Papers of Picture Coding Symposium 2001 to be held in Seoul, Korea during 25 April - 27 April, 2001. The deadline for paper submission, 15 October 2000, is coming soon. Updated paper submissioin information is at http://pcs.kaist.ac.kr. For further information, please send an email to pcs(a)pcs.kaist.ac.kr. We look forward to seeing you at the exciting PCS2001. Best Regards, Yo-Sung Ho ********************************************************** Yo-… [View More]

1 0

FECC and remote device control
by Bian 14 Nov '00

14 Nov '00

Dear Paul, experts: Some H.323 Endpoints(Such as VCON) declear that they support FECC using H.281. How do we achieve interoperability with them ? Can we use H.281 in the context of H.323? Thanks Bian Xuegong ----- Original Message ----- From: Paul E. Jones To: ITU-SG16(a)MAILBAG.INTEL.COM Sent: Sunday, November 12, 2000 3:04 AM Subject: Re: FECC and remote device control Roni, FECC in the context of an H.323 call is supposed to be done using H.282 and H.283 through H.245. Paul

2 1

FECC and remote device control
by Roni Even 14 Nov '00

14 Nov '00

Hi, I noticed in H.323 v4 and v3 the section about remote device control 6.2.7.2. In H.323 version 2 there was a sentence in H.323 6.2.7 "A terminal that provide far-end camera control using H.281 and H.224 ....". I think that there is a confusion now about how to do FECC in H.323. 1. Is it through H.281 over H.224 in an H.245 channel or is it by H.282 over H.283 or T.120. 2. How do we achieve interoperability between v3 and v2 terminals. Thank Roni Even

3 2

Extension of paper submission deadline of PV2001 (Nov. 30, 2000)
by PV2001 Secretariat 13 Nov '00

13 Nov '00

<<APOLOGIES TO THOSE WHO RECEIVE THIS EMAIL MORE THAN ONCE.>> Due to the large number of requests for extensions we have extended the deadline of paper submission to PV 2001 until November 30, 2000. Inviatation to PV(Packet Video Workshop) 2001 : 30 April - 1 May 2001, Kyongju, Korea The 11th International Packet Video Workshop (PV 2001) will be held on 30 April - 1 May 2001 in Kyongju, Korea, which was the capital city of ancient Korea (A.D 676 - A.D 935), located in … [View More]

1 0

Report of the 9-10 November meeting
by Sakae OKUBO 11 Nov '00

11 Nov '00

Dear Q12-14/16 experts, I have integrated the following reports of the Geneva Rapporteur meeting into APC-2031: - General: TD-25 - Q12: TD-26 - Q13: TD-27 - Q14: TD28 and placed it at http://standard.pictel.com/ftp/avc-site/0011_Gen/APC-2031.zip ftp://ties.itu.int/u/tsg16/sg16/q12-14/APC-2031.zip Please advise me if you have any findings to improve the text. Please also note that all the TDs have been moved to /0011_Gen directory. Best regards, Sakae OKUBO ***************************… [View More]

1 0

fyi - the response from the IETF Transport Area to MPEG
by Scott Bradner 10 Nov '00

10 Nov '00

For your information: This is the response from the IETF Transport Area Directors to the request from MPEG to delay consideration of the AVT working group draft draft-ietf-avt-rtp-mpeg4-es-05.txt. While the specific timing of the IESG consieration takes into account SG16's timetable you can see by the response that the work itself is consistent with other RTP payloads - it is a simple solution to a specific problem. Scott Bradner Allison Mankin IETF Transport Area Directors --------------- … [View More]As the Transport Area Directors of the IETF Internet Engineering Steering Group, we have carefully reviewed the technology in draft-ietf-avt-rtp-mpeg4-es-05.txt, and the points in your liaison statement to us. We have decided to continue the process of advancing the draft on the standards track. Taking in turn each of the reasons you gave for IETF to suspend this process: > there is no > consensus yet on the payload formats for the carriage of various MPEG-4 > streams in WG11. For instance, there are still strong concerns that the > payload format for MPEG-4 audio specified in > <draft-ietf-avt-rtp-mpeg4-es-05.txt>, while adequate for a range of > applications, is not appropriate for general use. We first note that the MPEG-4 audio for the ES use in the draft is an approved standard of MPEG. The AVT Working Group reached what the chairs found to be an adequate rough consensus that the audio in the draft met the requirements of the intended applications of the draft. IETF-wide Last Call comments beside your liaison statement commented only on the question of generality, and did not question the validity of the audio for the intended applications using ES payload types. Candidates for Proposed Standard may be advanced even when they have a known technical omissions (in this case, omitting alternative audio specifications). According to RFC 2026: A Proposed Standard should have no known technical omissions with respect to the requirements placed upon it. However, the IESG may waive this requirement in order to allow a specification to advance to the Proposed Standard state when it is considered to be useful and necessary (and timely) even with known technical omissions. The Area Directors support the need for timeliness in the case of this specification. The request from ITU-T SG16 is to be able to reference RTP encapsulations of MPEG-4 audio and video that are adequately provided by the elementary streams payload types. Future development of additional audio payload format and/or improvements in the current Audio-LATM payload format are encouraged, and will in no way be contraindicated by the Proposed Standard status of the elementary streams draft. > <draft-ietf-avt-rtp-mpeg4-es-05.txt> may not be used in the context of > MPEG-4 over IP framework in the future. Indeed, additional development of MPEG-4 specifications is needed for some applications, but the elementary streams draft is expected to serve the purpose of others. We consider the situation to be analogous to the standards for MPEG-1 and -2 in RTP. For those payloads, when an application requires only Elementary Streams, it uses an ES-only payload type, and when it requires using all of the MPEG Systems Streams format, it uses an SL payload type. > WG11 would prefer to find a design > for a single RTP payload format that would suffice for the carriage of all > MPEG-4 content over IP networks. This is not consistent with the design of RTP, which encourages distinct payload encapsulation for distinct application purposes, and has mechanisms for supporting the application layer framing (ALF) approach. The format for both the ES and SL payload types for MPEG-2 happen to be contained in one RFC (2250), but the Transport Area generally prefers for working groups to publish the specifications meeting different applications requirements as separate RFCs, so that they can mature and be modified each on their own timescale. RTP provides ample mechanism for uniquely identifying distinct payload types and for applications to signal them. The MIME declarations and payload type considerations for IANA in draft-ietf-avt-rtp-mpeg4-es-05.txt are explicit in distinguishing that the draft pertains only to elementary stream video and elementary stream LATM audio. There would be no identification or signalling difficulty for future specification of other MPEG-4 related payloads. In summary, we welcome collaboration between the AVT Working Group and MPEG to develop the additional MPEG-4 payload types for RTP, but find that the technical development and IETF standards process are best served by submitting draft-ietf-avt-rtp-mpeg4-est-05.txt for IESG approval now and thereafter advancing it, with the best intention of meeting the ITU-T SG16 timeframe. Allison Mankin and Scott Bradner IESG Transport Area Directors ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com [View Less]

1 0

About APC-2014 and APC-2015
by SG Kim 09 Nov '00

09 Nov '00

Dear Mr. Okubo and experts, I had a plan to attand the ITU-T SG16 Q.12-14 Rapporteur Meeting Geneva, 9-10 November 2000 and submitted the contributions, APC-2014(Title : Comments to H.323 Annex K) and APC2015(Title : A Procedure for Multimedia Mail Service). But I cannot attend the meeting because of in-house problem. I apologize for the abscence of the meeting. I wrote the contributions that included comment about example 3 of H.323 Annex K. Please arrange the contributions to be discussed by … [View More]

1 0

Re: fastStart element in all Q.931 messages up toandincludingConnect
by Paul Long 09 Nov '00

09 Nov '00

Pete, H.225.0 says that it is optional for an EP to receive and act on these messages. The message type is encoded in the _Q.931 header_ which has a corresponding CHOICE in the ASN.1 h323-message-body type. I think you are confusing the Q.931 message-type field with the ASN.1 CHOICE component. When an EP encounters an optional Q.931 message which it does not support, it will discard this message based on the Q.931 message type and not parse all of the subsequent IEs including the User-User IE, … [View More]which contains all of the tunneling stuff we are talking about. IOW, the EP will not even see all of the supposedly common fields to which you are referring. Paul Long ipDialog ---------- Original Message ---------------------------------- From: Pete Cordell <pete(a)TECH-KNOW-WARE.COM> Reply-To: Mailing list for parties associated with ITU-T Study Group 16 Date: Tue, 7 Nov 2000 17:50:05 -0000 >I mentioned this on the other list, but this is a different thread. > >As it happens it is not necessary for an EP to understand all Q.931 messages >that might contain tunnelled H.245, early or otherwise. The tunnelled H.245 >is always in the same place for all messages. All you have to do is find >the UUIE, extract the ASN.1, and chuck it to the ASN.1 decoder. As the >H.245 (and H.450) are not in the message specific part of the ASN.1 >structure it will be interpretable (sp!) in all cases*, even if SETUP >ACKNOWLEDGE and NOTIFY are sent. > >Therefore there is no need to make interpretation of CALL PROCEEDING and >PROGRESS in there entirety mandatory. > >Earlier I suggested the following text (slightly revised) should be added to >the start of the tunnelling section to cover this: > >"If an entity implements H.245 tunnelling, then it shall extract and act on >H.245 information contained in all received Q.931 messages (including those >that it does not otherwise understand) irrespective of how it decides to >handle the other elements of the Q.931 message." > >Pete. > >* The ASN.1 does actually require to have knowledge of all messages types up >to the ellipsis in h323-message-body, and up to the corresponding ellipsis >in the sub-types. However, once decoded it doesn't actually have to do >anything with these parts, which is the true burden of making them >mandatory. > >============================================= >Pete Cordell >Tech-Know-Ware >pete(a)tech-know-ware.com >+44 1473 635863 >============================================= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com [View Less]

3 3

Revised H.248 Annex M (Advanced Audio Server packages)
by Tom-PT Taylor 09 Nov '00

09 Nov '00

Dear Dr. Okubo-san: I have uploaded a new draft of H.248 Annex M (Advanced Audio Server packages) in the Incoming directory of the PictureTel site. I realize it is too late for consideration at the present meeting, but please assign an APC number so it can be reviewed at a future date. Tom Taylor +1 613 736 0961 taylor(a)nortelnetworks.com

2 1