- sg16-avd - lists.packetizer.com

Delayed Contribution
by Callaghan, Robert 25 Jan '00

25 Jan '00

Mr. Okubo, I have uploaded a delayed contribution "H.450.8 Character set for Name Identification" proposing Unicode for this service. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Information and Communication Networks Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------

1 0

FW: Last Call: RTP Payload for Text Conversation to Proposed Standard
by Gunnar Hellstrom 25 Jan '00

25 Jan '00

-----Original Message----- From: scoya(a)cnri.reston.va.us [mailto:scoya@cnri.reston.va.us]On Behalf Of The IESG Sent: Monday, January 24, 2000 7:56 PM To: IETF-Announce: ; Cc: rem-conf(a)es.net Subject: Last Call: RTP Payload for Text Conversation to Proposed Standard The IESG has received a request from the Audio/Video Transport Working Group to consider RTP Payload for Text Conversation <draft-ietf-avt-rtp-text-03.txt> 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(a)ietf.org or ietf(a)ietf.org mailing lists by February 7, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-text-03.txt

1 0

Reception of new/additional capability sets: delta or new
by Frank Derks 25 Jan '00

25 Jan '00

In previous discussions on this list it was often stated that newly/additional received capability sets are a delta. What is not clear, however, is a delta with respect to what. E.g. is this a delta with respect to the previously sent TCS or is this a delta with respect to the "used-up" capabilities by the terminal that receives the TCS. Furthermore, if it is a delta, then how do I remove capabilities from a set? Frank ----------------------------------------------------- Frank Derks |Tel +31 35 6893238 | Advanced Development |Fax +31 35 6891030 | Philips Business Communications|P.O. Box 32 | |1200 JD Hilversum | |The Netherlands | ----------------------------------------------------| E-mail: mailto:frank.derks@philips.com | WWW: http://www.sopho.philips.com | -----------------------------------------------------

1 0

Delayed contributions or TDs
by Sakae OKUBO 25 Jan '00

25 Jan '00

Dear Q12-14 experts, When you have submitted your delayed contributions or TDs to ITU-TSB, could you please upload them to ftp://standard.pictel.com/avc-site/Incoming as well? Please announce your uploading through the reflector. This will facilitate review and comments by interested parties before the SG16 meeting to be held during 7-18 February. 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 ***********************************************************

2 1

H.323 Annex I ToR for approval at SG16 Geneva, 2000
by Barry Aronson 24 Jan '00

24 Jan '00

Dale, Please find attached a clean copy of the H.323 Annex I ToR. Per the Red Bank meeting, I changed the title to reflect the true nature of this annex and clarified the "Radio Network, 4." section. Unfortunately, I will not be able to attend the upcoming SG meeting in Geneva this February. Although I know of two efforts underway regarding technical contributions to H.323 Annex I, there seems to be little indication that much editorial work will arise during the meeting. My colleague, Hirokazu Tanaka will be in Geneva for part of the meeting and may be able to help if required if doing so does not conflict with his primary tasks. Please inform me of the impact of my absence if any. Also, I will be available via e-mail and phone during the meeting if needed. I apologize in advance if my absence causes any inconvenience. Barry Aronson Toshiba Corp. 33 Lake Shore Dr. Beverly, MA 01915-1907 USA Voice +1 978 232 3994 Fax +1 978 232 9220 Mobile +1 978 902 0768 (worldwide w/ GSM) H.320 1B: +1 978 232 3994 (by arrangement) 2B: +1 978 232 9220 (by arrangement) H.324 +1 978 232 9220 (by arrangement) E-mail: baronson(a)ieee.org

2 1

H.248 comment Contribution uploaded to avc-site
by Chip Sharp 24 Jan '00

24 Jan '00

I've uploaded a delayed contribution to the avc-site incoming directory. The file name is h248_comments_Cisco.zip and contains comments on the white contribution of draft Recommendation H.248. ftp://standard.pictel.com/avc-site/Incoming/h248_comments_Cisco.zip Chip Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. --------------------------------------------------

1 0

Cisco IPR Statement on H.248
by Chip Sharp 24 Jan '00

24 Jan '00

Cisco's IPR statement on draft Recommendation H.248 should appear on the ITU Patents database sometime this week. http://www.itu.int/ITU-T/patent/Browse.htm This was originally faxed to ITU in November 1999, but for unknown reasons was never recorded. Chip Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. --------------------------------------------------

1 0

Re: teminalAlias in RegistrationConfirm?
by Frank Derks 24 Jan '00

24 Jan '00

Hi Chris, I was a bit to hasty with sending out this question. Reading on a bit made it a bit clearer how this field should be interpreted. According to the H.323 text it would "typically" be used when an endpoint does not provide an alias at all. I would say that your example is probably a bit more realistic. I suppose it could also be used to "create" an (unique) E-mail ID and associate with the enpoint to which it is conveyed, so that address can be used in environments where this sort of address is more appropriate. Regards, Frank ----------------------------------------------------- Frank Derks |Tel +31 35 6893238 | Advanced Development |Fax +31 35 6891030 | Philips Business Communications|P.O. Box 32 | |1200 JD Hilversum | |The Netherlands | ----------------------------------------------------| E-mail: mailto:frank.derks@philips.com | WWW: http://www.sopho.philips.com | ----------------------------------------------------- cwp@ISDN-COMMS.CO.UK@SMTP@MAILBAG.INTEL.COM on 24/01/2000 16:23:02 Please respond to ITU-SG16@MAILBAG.INTEL.COM@SMTP Sent by: ITU-SG16(a)MAILBAG.INTEL.COM To: ITU-SG16@MAILBAG.INTEL.COM@SMTP cc: Subject: Re: teminalAlias in RegistrationConfirm? Classification: Restricted Frank, You should interpret this as meaning exactly what it says. A gatekeeper may give an endpoint more, fewer, or simply different aliases from what it requests in RRQ - for whatever reason. The most common reason is probably that an endpoint registers with an E.164 address only (say "9007"), and the gatekeeper might work out from that who is referred to, decide it's me, and associate with it the publicPartyNumber +44 1344 899 007 and the emailID cwp(a)isdn-comms.co.uk It's only polite for the gatekeeper to TELL the terminal it has done this! What the terminal will do with the information is a little less certain (probably a simple endpoint will not care!). Regards, Chris Frank Derks wrote: > > The RCF contains an optional field with the name: "terminalAlias". The description of this field for this message states: "This optional value is a list of alias addresses, by which other terminals may identify this terminal". Should I interpret this by > assuming that the last word of this description ("terminal) should be "Gatekeeper", does this field have another purpose or should I ignore it alltogether? > > Frank > > ----------------------------------------------------- > Frank Derks |Tel +31 35 6893238 | > Advanced Development |Fax +31 35 6891030 | > Philips Business Communications|P.O. Box 32 | > |1200 JD Hilversum | > |The Netherlands | > ----------------------------------------------------| > E-mail: mailto:frank.derks@philips.com | > WWW: http://www.sopho.philips.com | > ----------------------------------------------------- -- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001

1 0

teminalAlias in RegistrationConfirm?
by Frank Derks 24 Jan '00

24 Jan '00

The RCF contains an optional field with the name: "terminalAlias". The description of this field for this message states: "This optional value is a list of alias addresses, by which other terminals may identify this terminal". Should I interpret this by assuming that the last word of this description ("terminal) should be "Gatekeeper", does this field have another purpose or should I ignore it alltogether? Frank ----------------------------------------------------- Frank Derks |Tel +31 35 6893238 | Advanced Development |Fax +31 35 6891030 | Philips Business Communications|P.O. Box 32 | |1200 JD Hilversum | |The Netherlands | ----------------------------------------------------| E-mail: mailto:frank.derks@philips.com | WWW: http://www.sopho.philips.com | -----------------------------------------------------

2 1

ＤｅｌａｙｅｄｃｏｎｔｒｉｂｕｔｉｏｎｆｏｒT.38 and H.323 Annex D
by 千村保文 24 Jan '00

24 Jan '00

I have uploaded the following two contributions for T.38 and H.323 Annex D in the incoming directory. ftp://standard.pictel.com/avc-site/Incoming/T38tpktSG16e.doc and ftp://standard.pictel.com/avc-site/Incoming/T38tcpSG16e.doc Thanks. Yasubumi Chimura Oki Electric Industry Co., Ltd. ************************************************ Yasubumi Chimura Oki Electric Industry Co.,Ltd. 4-10-16 Shibaura, Minato-ku, Tokyo 108-8551 Japan Phone: +81 3 3454 2111 Facsimile: +81 3 3798 7684 e-mail: chimura730(a)oki.co.jp ************************************************

1 0

FW: I-D ACTION:draft-ietf-avt-rtp-text-03.txt
by Gunnar Hellstrom 21 Jan '00

21 Jan '00

The RTP Payload for Text Conversation needed for H.323 Annex G Text Conversation and Text SET and other IP based text telephony and text telephone applications has taken one step closer publication in IETF. Regards Gunnar Hellström -----Original Message----- From: nsyracus(a)cnri.reston.va.us [mailto:nsyracus@cnri.reston.va.us]On Behalf Of Internet-Drafts(a)ietf.org Sent: Thursday, January 20, 2000 12:57 PM To: IETF-Announce: ; Cc: rem-conf(a)es.net Subject: I-D ACTION:draft-ietf-avt-rtp-text-03.txt 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 : RTP Payload for Text Conversation Author(s) : G. Hellstrom Filename : draft-ietf-avt-rtp-text-03.txt Pages : 8 Date : 19-Jan-00 This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents is specified in ITU-T Recommendation T.140 [1]. Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation services. This RTP payload description contains an optional possibility to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. The redundancy coding follows RFC 2198. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-text-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-avt-rtp-text-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(a)ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-text-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. ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-text-03.txt

1 0

Status of NAT support
by Melinda.Shore＠NOKIA.COM 21 Jan '00

21 Jan '00

What is the current status of NAT support in v3? There were several proposals at the Red Bank meeting in addition to the one from Madge/Vocaltec - have any of them been accepted? Thanks, Melinda -- Melinda Shore 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

1 0

Fw: SG16 meeting in Nov. 2000
by Sakae OKUBO 21 Jan '00

21 Jan '00

Dear Q12-14/16 experts, This is information from Mr. Federico Tosco, Chairman of WP2/16, on the very likely SG16 meeting in November 1999. Sakae OKUBO okubo(a)giti.or.jp --- Forwarded Message --- Dear all, I inform you that, subject to confirmation, a SG16 meeting is planned on November 13-17, 2000. The meeting will be conducted according to the current structure of the SG as at that time the structure for the next study period will not yet be in force. Best regards Federico --- End of Forwarded Message ---

1 0

Re: H.323 mobility: Ad hoc group meetings in Geneva
by Roy, Radhika R, ALARC 19 Jan '00

19 Jan '00

Hi, All: Yes, as Gösta pointed out that we agreed to meet on Feb 8 (preferably AM) in Geneva. Let me also point out that, per yesterday's US SG-D meeting, it had been advised that the Ad Hoc group's paper should be taken as Rap.'s contribution is Geneva. So, Ed will work with Dale related to this. (By the way, Glen was present and he indicated that it will not be a problem.) Best regards, Radhika R. Roy, AT&T H.323 Ad Hoc Mobility Group +1 732 420 1580 > -----Original Message----- > From: Gösta Linder (LME) [SMTP:Gosta.Linder@LME.ERICSSON.SE] > Sent: Wednesday, January 19, 2000 9:16 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 mobility: Ad hoc group meetings in Geneva > > Jaakko, > as agreed at the last Ad-Hoc Mobility meeting where you were not able to > attend, we agrred to meet already Feb 8 to agrrange for the proposed > planning > Regards / Gösta > > -----Original Message----- > From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] > Sent: den 19 januari 2000 13:38 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: H.323 mobility: Ad hoc group meetings in Geneva > > > 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

Re: H.323 mobility: Ad hoc group meetings in Geneva
by Gösta Linder (LME) 19 Jan '00

19 Jan '00

Jaakko, as agreed at the last Ad-Hoc Mobility meeting where you were not able to attend, we agrred to meet already Feb 8 to agrrange for the proposed planning Regards / Gösta -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] Sent: den 19 januari 2000 13:38 To: ITU-SG16(a)mailbag.cps.intel.com Subject: H.323 mobility: Ad hoc group meetings in Geneva 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

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