January 2000 - 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 25 Jan '00

25 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