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

R:Take Care of Vicious Virus!
by Tosco Federico 11 Jun '99

11 Jun '99

Thank you. Also at CSELT we had problems with such virus. Federico CSELT Via Reiss Romoli 274 10148 TORINO, Italy Phone: +39 0112285321 Fax: +39 0112285295 E_mail: federico.tosco(a)cselt.it > ---------- > Da: Sakae OKUBO[SMTP:okubo@GITI.OR.JP] > Risposta a: Mailing list for parties associated with ITU-T Study Group > 16 > Inviato: venerdì 11 giugno 1999 11.50 > A: ITU-SG16(a)mailbag.cps.intel.com > Oggetto: Take Care of Vicious Virus! > > Dear Q12-14/16 experts, > > I have received the following message from a US registrant of this > reflector > in response to my message regarding the update of Mr. Tosco's meeting > reports posted yesterday: > > >> Hi Sakae ! > >> I received your email and I shall send you a reply ASAP. > >> Till then, take a look at the attached zipped docs. > >> bye. > >> <<zipped_files.exe>> > > I obediently tried to read the zipped_files.exe and all the Office files > on > my Windows machine were destroyed. > > This seems to be due to a new virus W32/ExploreZip. Please take care! > > 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

Take Care of Vicious Virus!
by Sakae OKUBO 11 Jun '99

11 Jun '99

Dear Q12-14/16 experts, I have received the following message from a US registrant of this reflector in response to my message regarding the update of Mr. Tosco's meeting reports posted yesterday: >> Hi Sakae ! >> I received your email and I shall send you a reply ASAP. >> Till then, take a look at the attached zipped docs. >> bye. >> <<zipped_files.exe>> I obediently tried to read the zipped_files.exe and all the Office files on my Windows machine were destroyed. This seems to be due to a new virus W32/ExploreZip. Please take care! 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: Questions on H.GCP applied on text telephony
by Gunnar Hellstrom 10 Jun '99

10 Jun '99

The structure you described for bearers, terminations, multiplexors, contexts etc. described seems reasonable. For a PSTN termination in text telephone mode of the highest level, where the PSTN way of alternating between voice and text is supported, I see it best described as a kind of user-driven multiplexor. When there is a carrier from the text phone, the multiplexor conveys the text stream. When the carrier ceases, the multiplexor conveys the audio stream. Text arriving from an IP termination may cause the state of the PSTN multiplexor to change from audio to text and then transmit the text in the prevailing text telephone mode. Audio coming from an IP termination while the multiplexor is in the text mode can not go through. The multiplexor stays in the text mode until the user makes the alteration. ( usually by lifting the handset and "stealing" the line from the textphone.) On the IP side, H.323 Annex G is supposed to support simultaneous audio and text. There is no need for this kind of user driven multiplexor there. ------------------------------------------------------------------------- I understand that the requirements behind this description should go into section 11.2.4 of megaco requirements (D-286 of Santiago). But where in H.gcp do you want the description of parameters and functions needed in the gateway components for this functionality? Gunnar Hellström At 10:09 AM 1999-06-10 +0200, John Segers wrote: >Hao, > >In the current MEGACO model as described in draft-01, a Termination >describes the media and in-band signaling for one user, and how they are >transported etc. A Context associates all Terminations in a session and >implies audio mixing if there are more than two. > >This idea is retained in the Santiago work. Going to multiple media, a >Termination still describes the media and in-band signaling for one >user. A Context still associates all Terminations in a session. For >multimedia sessions, the mixing/switching can no longer be implied, but >will be described by means of Context properties. If there is only >audio, nothing changes in the Context. > >In order to allow H.320 and H.324 where multiple media are multiplexed >on one or more bearers, there needs to be a distinction between >TerminationID and BearerID in order to retain the concept that a >Termination describes the media, in-band signaling and transport. > >You see, the goal was to stay close to the basic monomedia connection >model for multimedia, always keeping in mind that there should be as >little overhead as possible for controlling voice calls (setup, >teardown, ...). The places where you see overhead occurring in the >Santiago proposal are indeed when dealing with multiple bearers for >multimedia, and, as Brian Rosen pointed out, in Audits. It seems to me >that this is acceptable because these operations will occur much less >frequently than the voice/fax/NAS setups. > >Regards, > >John Segers > >HaoHou wrote: >> >> Jonh, >> >> Thanks for your reply, >> >> Please see comments below. >> >> > >> > Second, the use of Add/Subtract/Modify commands. You are proposing to >> > use Add/Subtract to add media streams to a session or delete them from >> > it. This changes the semantics of the commands drastically. They are >> > intended to perform operations on Contexts (add or remove >> > Terminations). In the Santiago proposal this semantics is maintained. >> > Operations to change Termination parameters are performed using the >> > Modify command. >> > >> > Regards, >> > >> > John Segers >> > >> >> Thats why the Santiago proposal makes the Modify command awkward. ? >> Suppose we have 3 bearer channels already in a Termination. >> In order to release one bearer channel, we have to list both the other two >> bearer channels in the MODIFY command. >> In order to add one more bearer channel, we have to list the new >> bearer channel and all the existed bearer channels in the MODIFY >> command. >> >> I dont think the change of semantics will affect the protocol and the >> implementation too much. Instead, it will make the protocol easier to >> be understood: >> As long as you want to add some entities into the context or termination, you >> use ADD. As long as you want to sbustract some entities from the context >> or termination, you use Subtract. It is a more natural way to express the >> intention >> of the commands. >> >> Could you tell me why Santiago proposal wants to keep the old semantics >> unchanged, >> after the big change of the Context and Termination concept? What does it gain? >> >> Id rather change the semantics to meet the change of the concept. >> >> Best Regards, >> >> Hao > >-- >John Segers email: jsegers(a)lucent.com >Lucent Technologies Room HE 306 >Dept. Forward Looking Work phone: +31 35 687 4724 >P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > ------------------------------------- Gunnar Hellström Ericsson Home Systems Tel +46 751 100 501 Fax +46 8 556 002 06 e-mail gunnar.hellstrom(a)omnitor.se Video +46 8 556 002 05 -------------------------------------

1 0

WP2 reports of the Santiago meeting have been updated
by Sakae OKUBO 10 Jun '99

10 Jun '99

Dear Q.12-14/16 experts, A set of Mr. Tosco's WP2 meeting reports at the ftp site has been replaced with the final version. ftp://standard.pictel.com/avc-site/9905_San/Tosco_WP2_report_9905.zip or http://standard.pictel.com/ftp/avc-site/9905_San/Tosco_WP2_report_9905.zip 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

H.GCP / Megaco Audio call
by Bryan Hill 08 Jun '99

08 Jun '99

In order to continue the cooperation between SG16 and the IETF, there will be another Megaco/H.gcp conference call so that we have rough consensus on what Brian Rosen will put into megaco-protocol-02 (Internet-Draft cutoff date for IETF Oslo meeting is June 25/99). In Megaco we have agreed to produce a completed audio-only version of the megaco protocol for June 25th, but that this version would take into consideration the proposals for multimedia in SG16's H.gcpSantiago so that they can easily be added in a future version. We need to have an "implementable" version of the Megaco protocol by the July Oslo meeting, or we will have missed the boat. It is expected that the megaco-protocol-02 would be an implementable audio version of the Megaco/H.gcp protocol, and that SG16 would be able to add to the protocol syntax, in a backwards compatible way, all that is necessary for multimedia. Proposed discussion topics: 1) Termination naming - hierarchical or logical, or a combination with TerminationId + Bearer? 2) handling multplexing terminations - as in H.gcp? or as a new context type? 3) allowing one BearerDescriptor, and multiple MediaDescriptors per termination - acceptable? 4) decision on transport 5) proposal for tagging the MediaDescriptor with its encoding: SDP or H.GCP 6) proposal for text vs binary encoding of the protocol (draft-huitema-megaco-sdp-discuss-01.txt) 7) multimedia vs monomedia contexts (related to #3) Call Details Date: Wednesday, June 16th Time: 11amET for 2 hours Phone: 613-763-6338 PassCode: 131313# Problems getting on the bridge? call 613-765-CONF, and ask for the conference chaired by Nancy Greene. As before, minutes of the meeting will be posted ASAP after the call. Nancy Greene Bryan Hill ngreene(a)nortelnetworks.com <mailto:ngreene@nortelnetworks.com> bhill(a)videoserver.com <mailto:bhill@videoserver.com> -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

1 0

H.GCP is about gateway recomposition, not decomposition.. (attached)
by Boaz Michaely 06 Jun '99

06 Jun '99

Sorry about that attachement. (don't you love NOTES too ?) Hope this works : (See attached file: H.GCP composition.doc) - Boaz "John Talbot" <jptalbot(a)nortelnetworks.com> on 03/06/99 07:08:47 PM To: Boaz Michaely cc: Subject: RE: H.GCP is about gateway recomposition, not decomposition.. Michaely, Did you realy mean to send the image of the icon of the document rather than the document itself with your email? Anyway I read your document and have included my comments :-) <<pic10782.pcx>> Cheers John > -----Original Message----- > From: Boaz Michaely [SMTP:Boaz_Michaely@VOCALTEC.COM] > Sent: 03 June 1999 13:46 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.GCP is about gateway recomposition, not decomposition.. > > Dear Brian, > I am documenting a piece on the "minimal interoperability" issue, which I > will forward to you next week. (if there is interest I can post it to the > list) > > The basic idea is that while the motivation for H.GCP was gateway > decomposition, the actual standard deals with composing rather than > decomposing. > > Thus I propose to introduce some terms, such as "composite gateway", while > adhering to H.323 current definitions, and work on the call setup > procedures, closely following the actual H.323 text. This will lead to the > resolution of transfering call signalling between the MGC and the MG in > the > various compositions. One thought that crossed my mind was to explicitly > deal with all the gateway categories that H.323 defines ( H.310 (H.320 on > B-ISDN), H.320 (ISDN), H.321 (ATM), H.322 (GQOS-LAN), H.324 (GSTN), H.324M > (Mobile), and V.70 (DSVD)). > > We may also need to modify H.323v3, at least to some extent, in order to > better cover gateway sub-components. > > A sample of the text is attached (Word 97) > > (Embedded image moved to file: pic10782.pcx) > > Boaz. > > Boaz Michaely > Senior Program Manager, Advanced Technologies > VocalTec Communications Ltd > e-mail boaz(a)vocaltec.com > Tel +972 (9) 970-7869

1 0

Santiago meeting documents
by Sakae OKUBO 04 Jun '99

04 Jun '99

Dear Q.12-14/16 experts, All the files uploaded to the /Incoming directory of the PictureTel ftp site have been moved to the /9905_San directory. They include Mr. Ott's Annex F to H.323 and Mr. Duckworth's H.283. The index is given by the following: http://standard.pictel.com/ftp/avc-site/9905_San/9905_San.html For your convenience, the index file is attached to this message. Please Editors upload your Recommendations in charge as soon as your editing is completed. 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

Text Telephone support in megaco and H.gcp
by Gunnar Hellstrom 04 Jun '99

04 Jun '99

It seems to be useful to structure Text Telephone support in gateways in three levels: 1. Simple text-only support. ---------------------------- There is a simple way to use a textphone. That is to connect with the intention from the beginning to get a pure text call established and stay in the text-only mode during the whole call. Many users use this mode only, and it is also used in many cases in connection to relay services and emergency services. (relay services are services where the users get help to translate between different modes in the conversation, most commonly between voice telephony and text telephony. Relay services are usually manned services.) 2. Alternating text and voice support. -------------------------------------- Text telephone suppport can be quite advanced, with switching back and forth between text and voice during the call. This mechanism is used with current textphones that were created long before any simultaneous voice-data technologies were invented. Ideally, this support would also be wanted on any gateway termination, monitoring the line during voice operation for textphone tones and at that moment initiate text mode. 3. Simultaneous text and voice call. ------------------------------------ Alternative 2 is quite cumbersome for the users. A simple way to use simultaneous voice and text is eagerly needed. It is likely that the H.323 Annex G Text Conversation and Text SET will make this happen as the normal thing in the IP environment. But will it also eventually evolve in the PSTN? Within V.18 there is an opportunity to use V.61 for text telephony with voice and text. H.324 (especially without video) is also a possible environment. Market forces may tell if this enhancement is wanted in the PSTN. The Total Conversation terminals with simultaneous Video, Text and Voice should be placed in the simultaneous voice-text level when discussing text telephone interworking. Since Total Conversation terminals already exist in the H.320 invironment in ISDN, we have them in SCN as well as in IP networks. ----------- Termination arrangement for text telephone support. --------------------------------------------------- Level 1. -------- Level 1 can be achieved with a simple termination. On the SCN side it would contain V.18 modem support and terminate a T.140 text media stream. ( see eartlier message in the lists) Level 2. -------- If level 2 - alternating voice - text is going to be supported, it is advisable to have a model for how it should be viewed in terms of terminations, contexts and signaling. Multiplexor model: One model would be to regard the termination to contain a kind of multiplexor. It would then terminate two media streams - one T.140 text stream and one audio stream. The mechanisms to connect either stream to the line would be an internal mechanism in the termination. The need for external signaling in this case is low. Another model would be to regard the termination to terminate only one type of stream at a time. It would need to report events, e.g. about the carrier dropping, so that the voice mode can be started by an MGC command. A whole set of detailed interactions seems to be needed, between the MGC and the MG for the purpose of controlling the termination to follow the user's expectations for mode changes. I prefer the multiplexor model for the alternating voice - text mode. Some thoughts should be given to it, to verify if decent support of user requirements can be achieved. Level 3. -------- Level 3, simultaneous voice and text, is seen on the IP side as one T.140 TCP termination and one RTP audio termination. On the SCN side it is seen as a termination according to the kind of multiplexor it uses. Conclusions: ------------ I see no problem in mapping this structure within the H.gcp . I just want the mechanisms to be agreed on and the details around specific termination parameters and MG behaviour. It may be useful to take part of the discussion above into the megaco requirement spec in order to clarify what is meant with text telephone support and text conversation support. Regards Gunnar Hellström At 07:51 1999-06-04 -0600, Don Stanwyck wrote: >Gunnar Hellstrom wrote: >> >> Text Telephone support is very similar to FAX. If we let FAX into gateway >> specifications, we shall also include text telephony and text conversation >> in the same move. It saves a lot of efforts. > >Actually, text telephone (e.g., TDD) is quite a bit different from FAX, and >in the US, at least, mandated to be supported in every network (ADA >requirements). TDD conversations can be one-way modem one-way voice, >two-way modem, part-time modem (what TDD users call voice-over mode), etc. >My daughter is a TDD user, and we have become quite familiar with it. The >difficulties it presents to IP-telephony are considerable, but can be >solved by allowing that any line, any time, can be instantly converted to a >modem communication line without any prior notice or any promise that modem >tones will continue on the line for any particular duration. > >Don >Attachment Converted: "c:\_Omnitor\Attach\stanwyck.vcf" > ----------------------------------------------- Gunnar Hellstrom LM Ericsson E-mail gunnar.hellstrom(a)omnitor.se Tel +46 751 100 501 fax +46 8 556 002 06

1 0

Re: Decided and Determined texts
by Kumar, Vineet 04 Jun '99

04 Jun '99

I found H323AnnexF-decided.zip in http://standard.pictel.com/ftp/avc-site/9905_San/ vineet -----Original Message----- From: Kumar, Vineet [mailto:vineet.kumar@INTEL.COM] Sent: Friday, June 04, 1999 10:16 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Decided and Determined texts I was expecting to find H323AnnexF-decided.zip at http://standard.pictel.com/ftp/avc-site/Incoming/ but I don't see it there yet. vineet -----Original Message----- From: Greg Herlein [mailto:gherlein@HERLEIN.COM] Sent: Friday, June 04, 1999 2:12 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Decided and Determined texts > I have uploaded the decided clean text version of H.323 Annex F > into the Incoming directory of the PictureTel ftp site. The file > name is H323AnnexF-decided.zip Can someone give me a full URL for this document? I can't find it by browsing around... Thanks, Greg /************************************************************** Greg Herlein gherlein(a)herlein.com Herlein Engineering www.herlein.com Software Development - Communications - Networking - Linux/Unix ***************************************************************/

1 0

Re: Decided and Determined texts
by Kumar, Vineet 04 Jun '99

04 Jun '99

I was expecting to find H323AnnexF-decided.zip at http://standard.pictel.com/ftp/avc-site/Incoming/ but I don't see it there yet. vineet -----Original Message----- From: Greg Herlein [mailto:gherlein@HERLEIN.COM] Sent: Friday, June 04, 1999 2:12 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Decided and Determined texts > I have uploaded the decided clean text version of H.323 Annex F > into the Incoming directory of the PictureTel ftp site. The file > name is H323AnnexF-decided.zip Can someone give me a full URL for this document? I can't find it by browsing around... Thanks, Greg /************************************************************** Greg Herlein gherlein(a)herlein.com Herlein Engineering www.herlein.com Software Development - Communications - Networking - Linux/Unix ***************************************************************/

1 0