July 1999 - sg16-avd - lists.packetizer.com

APC-1643 Liaison from MPEG
by Sakae OKUBO 27 Jul '99

27 Jul '99

Dear Q.12-14/16 experts, The following document has been registered and uploaded as APC-1643. SOURCE : MPEG TITLE : Liaison Statement from SC 29/WG 11 to ITU-T SG 16 on MPEG-4 Over H.32x Terminals [SC 29/WG 11 N 2887] PURPOSE: Liaison - Information FILE : APC-1643.txt Best regards, Sakae OKUBO (Mr.) *********************************************************** 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 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

APC-1606 and APC-1607
by Rich Bowen 27 Jul '99

27 Jul '99

Dear Mr. Okubo: Please find attached the following contributions for the Berlin meeting: o APC-1606, "Proposal for Transporting User Input via RTP" o APC-1607, "Proposal for Enforcing Symmetric Codec Operation with Fast Connect" I apologize for sending these contributions to the mailing list - for some reason I am encountering errors when trying to upload them to the FTP site. Regards, Rich -------------------------------------------------------------------- Richard K. Bowen Cisco Systems, Inc. rkbowen(a)cisco.com Research Triangle Park, NC --------------------------------------------------------------------

1 0

reference to the ATMF specification af-saa-0124.000
by Ameneh Zahir-Emami 27 Jul '99

27 Jul '99

Hello, This is Ameneh Zahir. I have been chairing the H323 gateway over ATM activity over the past 2 years in the ATM-Forum. The ATM-Forum is glad that this specification is referred to in the H323V3 recommendation. In order for the ITU-T organization to keep this reference in its determined version of H323.V3 I was told that you need an official ITU form to be filled. Because the ATM-Forum is meeting this week (starting today) it was almost impossible to meet the SG16 rapporteur's meeting deadline. I hope it is not too late for you to consider this contribution which is purely administrative. I uploaded it on the picture-tel website server under: ITU-af124.doc. Unfortunately it does not have any APC number. I would like to apologize and hope that if not in Berlin then in September during the interim meeting this contribution will be considered. Best regard. Ameneh Zahir Alcatel

2 1

APC-1626 and APC-1640
by Francois Audet 27 Jul '99

27 Jul '99

I have uploaded: APC-1626 "Tunneling of Q.SIG information in H.225.0" APC-1640 "Clarification on the use of E.164 numbers" ----- François Audet Tel:+1 408 565 5675 mailto:audet@NortelNetworks.com <mailto:audet@NortelNetworks.com> Nortel Networks Fax:+1 408 565 2375 http://www.NortelNetworks.com <http://www.nortelnetworks.com/>

1 0

draft-hellstrom-avt-rtp-text-01.txt Result of Oslo discussion.
by Gunnar Hellstrom 26 Jul '99

26 Jul '99

The draft rtp specification for text conversation that is discussed in the IETF AVT group is now available in the following URL. www.omnitor.se/english/standards/rtp/draft-hellstrom-avt-rtp-text-01.txt It is referenced in the H.323 Annex G Text Conversation draft that is entered as a contribution to the ITU-T Q13/16 meeting next week as document APC1561. I would like to receive comments on this draft. I am aware of the following points that might need discussion. 1. Timestamp clock frequency. I had put a low figure 10 Hz in the specification. It was questioned and proposed that a figure of some thousands should be selected. I am willing to accept that, and propose that 1000 Hz is used. A millisecond per tick is a handy figure. This will however lead to the timestamp offset in the redundancy data headers that use only 14 bits, flip around in only 16 seconds. If correct timing information is wanted, the data flush procedure described in next section should be used. 2. Retransmission of text before a pause. Text does not flow continously, but only when a user enter text. Therefore, a recommended procedure could specify that for the redundancy scheme, it is advisable to send the ISO 10646 synch character FEFF after some inactivity timer to flush out redundant data - see section 3.4. 3. Recommended procedures section. In the draft that accompanies this mail, section 3 documents the recommended procedures for using the payload format. Does the group want it to be kept there or shall it be moved to the specification specifying use of this RTP Payload? ( The first user being H.323 Annex G) Any other comments are welcome. Gunnar Hellström ----------------------------------------------- Gunnar Hellstrom LM Ericsson E-mail gunnar.hellstrom(a)omnitor.se Tel +46 751 100 501 fax +46 8 556 002 06

1 0

uploaded new document
by Mickey Nasiri 26 Jul '99

26 Jul '99

Dear colleagues, I have uploaded the document Q11-J-07 to ftp://standards.pictel.com/q11-site/dropbox/ This document is the same as document APC-1564 (White H.224 modified for text conversation with correction). Best regards //Mickey -- //Mickey Nasiri Ericsson Telecom AB Home Communications SE-126 25 STOCKHOLM Tel: +46-8-719 38 61 Mob: +46-70-319 38 61 email: mickey.nasiri(a)ericsson.com

1 0

APC-1609 Uploaded
by Robert J. Abrams 26 Jul '99

26 Jul '99

APC-1609, a proposal to support Q.931 TNS and NSF IEs in H.225.0, has been uploaded to the Incoming directory of the FTP site. Bob Abrams Lucent Technologies

1 0

APC-1580 - Megaco/H.248 reqs - uploaded
by Nancy-M Greene 26 Jul '99

26 Jul '99

I've just uploaded APC-1580 - Media Gateway control protocol architecture and requirements. It is the same as the internet-draft ftp://ftp.ietf.org/internet-drafts/draft-ietf-megaco-reqs-05.txt put out June 25th. Mr. Okubo, Please note that the source for this document is the IETF Megaco Working Group, and NOT Nortel Networks as I previously indicated. Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

1 0

APC1634
by El-Gebaly, Hani 26 Jul '99

26 Jul '99

Dear Q12/13/14 experts, I uploaded APC1634.doc to the Incoming directory. This is a proposal to add security tokens to the releaseComplete message. Regards, Hani ElGebaly Intel Corp.

1 0

Comment on APC-1636 (Was: Documents uploaded)
by Pete Cordell 26 Jul '99

26 Jul '99

Well it seems the Telcordia crowd still haven't read my proposal!!!!!! What I am proposing is an ASN.1-LIKE specification. That means similar to, but not exactly the same as. In my proposal your line: quarenteenProcessing QuarenteenProcessing OPTIONAL would be represented as: quarenteenProcessing AS q QuarenteenProcessing OPTIONAL. and q would be used as the on the wire tag for precisely the reasons quoted in APC-1636. If there are worries that this isn't ASN.1 (if that is worth worrying about!), then all you have to do is go through removing any AS specifiers either manually or automatically. It's no big deal. Pete ============================================= Pete Cordell pete(a)tech-know-ware.com ============================================= -----Original Message----- From: Hong Liu <lhong(a)RESEARCH.TELCORDIA.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: 26 July 1999 17:01 Subject: Documents uploaded >Hi, all, > >I have uploaded two contributions from Telcordia Technologies to the ftp >incoming directory for the Berlin meeting: > >APC-1635: Mapping H.245 Semantics to SDP >APC-1636: Comparing EBNF and ASN.1 for Text Encoding > >Cheers, > >--Hong >

2 1