- sg16-avd - lists.packetizer.com

H.323 mobility: Ad hoc group meetings in Geneva
by Jaakko Sundquist 19 Jan '00

19 Jan '00

Hi all, As the Geneva meeting is a two week meeting (i.e. quite long), I would like to ask the members participating in the meeting, should we try to agree beforehand on (some of) the days when we will hold mobility meetings. I myself am present from the 10th day (Thursday) onwards and there will be Nokia representatives present during the whole two weeks, but if someone is planning to attend only a few days, it would certainly be good, if we can agree in advance at least on some days for the mobility work. - Jaakko Sundquist ------------------------------------------------------- In a hole in the ground there lived a hobbit. Not a nasty, dirty, wet hole, filled with the ends of worms and an oozy smell, nor yet a dry, bare, sandy hole with nothing in it to sit down on or to eat: it was a hobbit-hole, and that means comfort. -------------------------------------------------------

1 0

Rapporteur meeting after May 2000
by Sakae OKUBO 19 Jan '00

19 Jan '00

Dear Q11-15 experts, According to the agreement in Red Bank, Japan members are preparing for the Q11-15 meeting in Osaka during 15-19 May 2000. This and any other interim activities should be approved by the SG16 meeting next month. Probably we need another Rapporteur meeting sometime after May 2000 and before the first SG meeting of the next study period (may be late 2000 or early 2001). Could you please think of volunteering to host a Rapporteur meeting so that WP2/16 and WP3/16 can decide their interim activity plans at the coming SG16 meeting? Any early indications are very welcome. 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

Re: H.323 Annex M
by Sakae OKUBO 18 Jan '00

18 Jan '00

Dear Q12-14/16 experts, FA> I have uploaded the current draft for H.323 Annex M (Tunnelling of FA> signalling protocols - QSIG) in the incoming directory as FA> d-H323M.doc. This file from Mr. Audet has been moved to the following place: ftp://standard.pictel.com/avc-site/0002_Gen/d-H323M.doc or http://standard.pictel.com/ftp/avc-site/0002_Gen/d-H323M.doc 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

TDs for the SG16 meeting in February 2000
by Sakae OKUBO 18 Jan '00

18 Jan '00

Dear Q12-14/16 experts, Mr. Tosco, Chairman of WP2/16, has advised us of the TD availability. >Date: Mon, 17 Jan 2000 17:27:35 +0100 >From: Tosco Federico <Federico.Tosco(a)CSELT.IT> >To: Blaschitz <michael.blaschitz(a)infonova.at>,DeGrasse ><b.degrasse(a)prodigy.net>, Freundlich <ggf(a)lucent.com>,Geary ><tom.geary(a)conexant.com>, Okubo <okubo(a)giti.or.jp>,Robin-Champigneul ><yves.robinchampigneul(a)cnet.francetelecom.fr>,Skran <Dale.Skran(a)ascend.com> > >I think you have seen that in the informal SG16 FTP there are already a >number of TDs. You can find them at the addresses: >http://ties.itu.int/u/tsg16/sg16/td/gen/ >http://ties.itu.int/u/tsg16/sg16/td/plen/ >http://ties.itu.int/u/tsg16/sg16/td/wp2/ > >Best regards > >Federico 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

WP2 workplan for the SG16 meeting in February 2000
by Sakae OKUBO 18 Jan '00

18 Jan '00

Dear Q12-14/16 experts, Please find attached Mr. Tosco's workplan of WP2/16 for the SG16 meeting during 7-18 February 2000. This file is also placed at the following place: ftp://standard.pictel.com/avc-site/0002_Gen/WP2_Work_Plan_Feb_2000.xls or http://standard.pictel.com/ftp/avc-site/0002_Gen/WP2_Work_Plan_Feb_2000.xls 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

None
by Dave Walker 17 Jan '00

17 Jan '00

This person no longer works at Mitel. Please remove this individual from your mailing list. Thank-You Unix Server Support

1 0

Re: H225.0 RAS/AnnexG related queries
by Michael Fortinsky 17 Jan '00

17 Jan '00

Hi Krishna, See my answers below... > Hi ..!! > I have a few queries regarding H.225.0 RAS/AnnexG: > 1. AnnexGCommonInfo does not contain Protocol Identifier. Why is it not > required for AnnexG messages? > Keeping in view, the possible future versions of AnnexG; how shall a > Border Element, on receiving a PDU from some other Border Element know the > version of protocol being used by the sender of the PDU? Also, how does the > sender ascertain which version of protocol the receiver understands? e.g. if > an element is added in version 3 of the protocol, and the recepient can > handle upto version 7, how can it be ascertained that the peer entity would > understand the information sent/received? > Actually, Annex G does has a Protocol Identifier - it is the "version" field that is part of the common message info and is included in every message: AnnexGCommonInfo ::= SEQUENCE { sequenceNumber INTEGER (0..65535), version AnnexGVersion, hopCount INTEGER (1..255), replyAddress SEQUENCE OF TransportAddress OPTIONAL, -- Must be present in request integrityCheckValue ICV OPTIONAL, tokens SEQUENCE OF ClearToken OPTIONAL, cryptoTokens SEQUENCE OF CryptoH323Token OPTIONAL, nonStandard SEQUENCE OF NonStandardParameter OPTIONAL, ..., serviceID ServiceID OPTIONAL } In the first version of Annex G, it is defined as: AnnexGVersion ::= OBJECT IDENTIFIER -- shall be set to -- {itu-t (0) recommendation (0) h(8) 2250 annex (1) g (7) version (0) 1} > 2. Why is Sequence Number from 0 to 65535 for AnnexG, while for RAS its from > 1 to 65535 (ASN.1 Message Syntax)? > Also, in section 7.17 (Message Not Understood) of H.225.0 it is >mentioned that RequestSeqNum shall be zero if the message cannot be decoded; > PDU encoding shall fail in such a case. > You're right. I am guessing that nobody ever noticed the discrepancy between H.225.0 (RAS) and Annex G. From the section you quote (H.225.0, section 7.17)), specifying the sequence number to zero seems to be a bug in the standard, since it defines the sequence number as: RequestSeqNum ::= INTEGER (1..65535) > Regards > Krishna Michael Fortinsky ----------------------------------------------------------------- Senior Program Manager, IP Telephony Group, VocalTec Communications Ltd. Email: mike(a)vocaltec.com Tel: 972 9 9707768 Fax: 972 9 9561867

1 0

H225.0 RAS/AnnexG related queries
by Krishna Kr Banka 17 Jan '00

17 Jan '00

Hi ..!! I have a few queries regarding H.225.0 RAS/AnnexG: 1. AnnexGCommonInfo does not contain Protocol Identifier. Why is it not required for AnnexG messages? Keeping in view, the possible future versions of AnnexG; how shall a Border Element, on receiving a PDU from some other Border Element know the version of protocol being used by the sender of the PDU? Also, how does the sender ascertain which version of protocol the receiver understands? e.g. if an element is added in version 3 of the protocol, and the recepient can handle upto version 7, how can it be ascertained that the peer entity would understand the information sent/received? 2. Why is Sequence Number from 0 to 65535 for AnnexG, while for RAS its from 1 to 65535 (ASN.1 Message Syntax)? Also, in section 7.17 (Message Not Understood) of H.225.0 it is mentioned that RequestSeqNum shall be zero if the message cannot be decoded; PDU encoding shall fail in such a case. Regards Krishna

1 0

[Fwd: Re: FW: I-D ACTION:draft-singh-sip-h323-00.txt,.ps]
by Edgar Martinez [1] 14 Jan '00

14 Jan '00

FYI -------- Original Message -------- Subject: Re: FW: I-D ACTION:draft-singh-sip-h323-00.txt,.ps Date: Fri, 14 Jan 2000 11:52:20 +0100 From: Paul Sijben <sijben(a)LUCENT.COM> Reply-To: Paul Sijben <sijben(a)LUCENT.COM> Organization: Lucent technologies, The Netherlands To: TIPHON(a)LIST.ETSI.FR References: <E39024226822D311BC880008C77318A1816106@oteis01nok> I have been reading this draft and have been both puzzled and pleasantly surprised. I have been puzzled over some of the statements that are made on H.323, I do not recall that there is a limit on the sample frequency on G711 in H.323, the draft claims its fixed to 8000. (Could someone resolve this?) The authors also seem to forget that there is H.323v4 now as well as the FastStart option... so the resulting call flow uses very many message exchanges, this is not necessary is it??? I also have been puzzled by the authors proposing to make a SIP-H.323 gateway whereby the H.323 side looks like an H.323 terminal, in some cases an H.323 gatekeepr seems more appropriate. I have been pleasantly surprised in that the authos basically use the same method of interworking as we have been looking at in the DTS02003 information flows. So either we are all wrong or all right :-) Paul Shore Melinda wrote: > > For those who don't receive IETF announcements ... > > Melinda > -- > Melinda Shore > Member of the Scientific Staff > Nokia IP Telephony > 127 West State Street "Software longa, > Ithaca, NY 14850 hardware brevis" > +1 607 273 0724 (office) > +1 607 275 3610 (fax) > +1 607 227 4096 (mobile) > melinda.shore(a)nokia.com > > -----Original Message----- > From: EXT Internet-Drafts(a)ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Wednesday, January 12, 2000 6:40 AM > Subject: I-D ACTION:draft-singh-sip-h323-00.txt,.ps > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Interworking Between SIP/SDP and H.323 > Author(s) : K. Singh, H. Schulzrinne > Filename : draft-singh-sip-h323-00.txt,.ps > Pages : 46 > Date : 11-Jan-00 > > This document describes the interworking between SIP and H.323, > including the translation between H.245 and SDP. We list general > requirements for such a translation and a solution which meets those > requirements. We describe the call setup via message flows and pseudo > code. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-singh-sip-h323-00.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-singh-sip-h323-00.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(a)ietf.org. > In the body type: > "FILE /internet-drafts/draft-singh-sip-h323-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. > > --------------------------------------------------------------------------- > > Subject: > Date: Wed, 12 Jan 2000 08:23:01 -0600 > > --------------------------------------------------------------------------- > > ATT19699Name: ATT19699 > Type: unspecified type (application/octet-stream) > > Access-Type: anon-ftp > Document Info: Site: internet-drafts > Mode: ftp.ietf.org -- Paul Sijben Tel:+31 356874774 Lucent Technologies Message:+31 208702874 Forward Looking Work Fax: +31 208702874 Huizen, The Netherlands http://voip.nl.lucent.com/~sijben (internal) ------------------------------------------------------------------- Mail archive for TIPHON can be browsed at the following url : http://www.etsi.org/tiphon/mailing.htm -------------------------------------------------------------------

2 1

H.248 White Contribution
by Chip Sharp 13 Jan '00

13 Jan '00

I cannot find COM 16-107 (draft Recommendation H.248 white contribution for decision) in the Contributions directory of the official SG16 web site (http://www.itu.int/itudoc/itu-t/com16/contr/). I understand that this is on the avc-site, but since it is up for decision I assume the official contribution would show up on the SG16 page. Thanks, Chip Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. --------------------------------------------------

1 0