- sg16-avd - lists.packetizer.com

Question about text in implementers guide
by Pete Cordell 22 Jun '99

22 Jun '99

Dear All, The following revised paragraph seems to have been added to H.323 v3 via the implementers guide. Endpoint system capabilities are exchanged by transmission of the H.245 terminalCapabilitySet message. This capability message shall be the first H.245 message sent. If prior to successful completion of terminal capability exchange, any other procedure fails, (i.e. rejected, not understood, not supported) then the initiating endpoint should initiate and successfully complete terminal capability exchange before attempting any other procedure. An endpoint which receives a terminalCapabilitySet message from a peer prior to initiating capabilities exchange shall respond as required by 6.2.8.1, and should initiate and successfully complete capabilities exchange with that peer prior to initiating any other procedure. I'm a bit confused about what it is saying. It seems to be saying that an endpoint can send a TCS and prior to receiving the Ack, send MSD (as there is really no other procedure that can fail). This is a good thing. However, it then says, that if for some reason you receive TCS before you yourself have sent one, then, I think the paragraph is saying that, you must send your own TCS, and are not allowed to do MSD until you get the TCS Ack back. This is a bad thing. But worse still there seems to be conflicting information for what is essentially a minor timing issue. Could someone kindly explain to me what the background to it is. Thanks, Pete ============================================= Pete Cordell pete(a)tech-know-ware.com =============================================

1 0

Re: Proposed Changes To Requirements
by Nancy-M Greene 22 Jun '99

22 Jun '99

Based on the emails exchanged on the Megaco mailing list, this is how I have addressed the issues from SG16 on the Megaco requirements draft (draft-ietf-megaco-reqs-03.txt). Let me know of any comments.The new requirements draft (-04) will be out this week. (this msg has been posted to both the ITU SG16 mailing list as well as the Megaco mailing list - please answer only to the Megaco mailing list.) Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: Taylor, Tom-PT [CAR:5V00-I:EXCH] > Sent: Wednesday, June 02, 1999 10:49 AM > To: megaco(a)standards.nortelnetworks.com > Subject: Proposed Changes To Requirements > > The following changes to our requirements were proposed by members of > Study > Group 16. > > ITU - Telecommunication Standardization Sector Temporary Document XX > (WP2/16) > STUDY GROUP 16 > > Santiago, 18-28 May 1999 > > Question(s): 14/16 > > SOURCE*: Rapporteur Q. 14/16 > > TITLE: Proposed Revisions To Megaco/H.GCP Requirements > __________________ > > > ABSTRACT > > This document describes the revisions proposed to the Megaco/H.GCP > requirements as documented in DC 16-286. IETF Working Group Megaco is > asked > to consider these for inclusion into the next draft of the Gateway Control > protocol requirements document. > > PROPOSED REVISIONS > Preliminary comment: it is unclear what the "Architecture" of the title > refers to. [PTT: It refers to the functional architecture within which > the > protocol is supposed to operate.] > > Section 3 - Definitions: Suggest including "SG Function" and "MG Function" > as defined terms. [PTT - they are already there. Looks like a title > change > is needed to make them obvious.] > "function"added to MG, MGC and SG definitions. > Section 3 "Termination Class": This is quite unclear. What you appear to > mean to say, from the examples in Chapter 11, is "Type of Bearer". > changed to "Type of Bearer". > Section 4 -- Specific Functions ...: This Section does not seems relevant > to > a specification of protocol requirements. The concept of contexts and > terminations is best handled in the protocol specification itself. In > addition much of the material is of a vague and general nature and seems > out > of place in a specification. If it is decided to leave some of this here > it should be pruned down to the essentials and the protocol connection > model should be avoided. Maybe replace "termination" with "resource". > Certainly get rid of "context". > "termination" changed to "resource", "context" removed. > Section 4 , 2nd bullet list, 8th bullet: Remove "(Sigtran)" as it is not > really related to the capability mentioned per se. > > General comment: It must be possible to extend the protocol to include > manufacturer-specific information, perhaps identified by T.35 manufacturer > code. At the same time, it must be possible for a given implementation > not > to support all features defined within the protocol. > [PTT: extensibility is already a stated requirement - see section 8, item > b. > Identification of extensions can be done in various ways. The final > protocol specification should indicate the minimal MG and MGC > implementations, and of course should provide for reasonable behaviour for > unimplemented features.] > > Section 5.1 -- Resource Reservation: add (c.) The media gateway is not > required (or allowed) by the protocol to maintain a sense of future time: > a > reservation remains in effect until explicitly released by the MGC. > added > Section 5.2 - Connection Requirements, Item (d): Suggest bringing "Support > multiple media types ..." out as its own item, and make it stronger: > support > multimedia connections. Add "Support the range of options used in > commonly > available coders such as H.263." > > Section 5.2 (g.): Remove termination-context terminology, which > anticipates > the protocol document. Can simply say "Add or delete media streams during > a > call or session.", and "Add or subtract participants to a call or > session." > May want to state these as separate points. > ok > Section 5.2 (h.): Use "call or session" rather than "context". This is > not > to say that the two expressions are equivalent, but only that the > suggested > rephrasing conveys the requirement without anticipating the protocol > solution. > ok > Section 5.2 (i.) Missing words: should read "... and which are blocked at > a > given point in time ...". > ok > Section 5.2 (j.): Special case of item (a) and should be combined with > that > item. > ok > Section 5.2 (l.): Could rephrase in less implementation-oriented terms: > "Allow the MGC to specify that a given connection has higher priority than > other connections." > ok > Section 5.3 -- Media Transformations, Item (e): This seems to have a lot > of > problems. Replace with the following: > > Allow the MGC to specify that MF/DTMF be extracted and handled in the > following ways: > [Nancy - I assume the above should read "in ANY OF the following ways"] > (1)encoded as part of the RTP stream > (2)extracted and sent to the MGC > (3)handled according to a script of instructions > [Nancy - we need to add (4) - extracted and encoded in a separate RTP > stream] > In all cases, if the MF/DTMF is extracted, the MG must replace the tones > with silence or comfort noise. Also, the option to have the MG not > extract > MF/DMTF must exist as well. > change made with my additions above. > [PTT: the original text provides for extraction of the MF/DTMF and its > onward transmission in a separate RTP stream. This is in anticipation > that > an RFC will eventually be created which supports such operation. Work on > this has been moving (slowly) through MMUSIC.] > > Section 5.3 (g.) Is this requirement intended to allow for adaptation of > ATM > AAL5 to and from ATM AAL2, among possibly other things? It is so badly > worded it is difficult to tell for sure. It needs clarification, and > probably is covered already by 5.3(a). > 5.3(g) reworded > Section 5.3 (h.) Define "audio normalization level" further. > > Add Section 5.3 (i): Allow conversion to take plece between media types > e.g > text to speech and speech to text. > added > Section 5.4 - Signal/Event Handling, Item (d): delete the word > "signaalling" > before events, making the requirement more general. > ok > Section 5.4 (e): Redundant, covered by earlier items. > > Section 5.5 - QOS/COS, Item (b) Define what "the connection as a whole" > is. > The link between MGs? The entire user to user connection? Probably the > former. > added "between MGs" > Section 5.5 (d.) "... by flow direction ... " It is unclear what this > means. > It is also unclear how this requirement differs from requirement 5.5 (c). > 5.5(d) removed (covered by 5.5(c)) > Add Section 5.5 (f): Allow the size and performance of jitter buffers on > RTP > channels to be specified at call set-up. > added ("at call setup" changed to "at connection setup") > Section 5.6 - Test Capabilities, Item (c): After some discussion the > conclusion here was that loopbacks and unspecified other test capabilities > are not a Gateway Control protocol issue. They will be invoked by other > means. Hence this item should be deleted. > No change - If a test is initiated by an ISUP message, then it needs to be part of the protocol. This includes loopbacks and continuity tests. [reference: Greene - Megaco/H.gcp conference call minutes, June 16/99] > Section 5.7 - Accounting - Item (a): use a term other than "terminations", > since the latter is specific to the protocol specification. Suggestion: > "resources". > ok > Section 5.8 - Signalling Control (General): The protocol for > establishment > of signaling backhaul channels should be part of this protocol, not "out > of > scope." Signalling could be viewed as another form of media from the > point > of view of the protocol. > No change - Establishment of a SIGTRAN backhaul is provisioning [reference: Rosen, June 8/99, and June 9/99] > Section 5.8 (b.) Calls for support of "national variations" of signaling. > This creates a potential "homologation horror". The opposite requirements > are suggested: "All national variations of signaling protocols that are > channel associated are reported to the MGC in a uniform fashion that > conceals the national varations." > No change: Reasons: * Creating a uniform representation for all CAS protocols may prove non-trivial. * A uniform superset protocol for representing all CAS protocols, if one could be created, would probably contain much that was not needed for particular applications, hence MGCs and MGs would tend to implement subsets, resulting in national variations anyway. * Simplifying the MGC at the expense of the MG isn't necessarily the right economic model in all applications. [reference Ashworth, June 15/99] > Section 5.8 (c): intent is unclear. Probably mean to say that support of > signalling should not be such as to cause the transmission time between > the > MG and the MGC to become a critical element in meeting signalling timing > constraints. More specifically, where responses to signalling events must > occur in less than one second, the protocol should assume that these > responses will be generated autonomously by the MG rather than via an > MG-MGC-MG messaging sequence. > > Add Section 5.9 (d): The protocol shall not create a situation where the > MGC > and the MG must be homologated together as a mandatory requirement of > using > the protocol; i.e. it must be possible to optionally conceal signaling > type > variation from the MGC. > added, but as Brian Rosen says, the current protocol definition would fail to meet this requirement for CAS, since it only covers some CAS variants.[reference: Rosen, June 8/99] > Section 6.1 - Resource Status Management - Item (c): replace the word > "contexts" with "connections". > ok > Section 6.1 (d): "...must enumerate the names and quantities of available > terminations..." Delete "quantities": terminations are instances, so > there > is only one of each. Also questionable whether the word "termination" > should be used without qualification (e.g. circuit termination). > ok > Section 6.1 (e.) Change "reasonable" to "reasonably". > ok > Section 6.2 (c.) What are "network entities"? Either define exactly or > remove. > network entities removed. > Section 7.1 - Assurance of Control/Connectivity - Item (a): This was > intended to be a summary of the section. Inserted as an item itself, it > is > redundant. > ok > Section 7.2 - Resiliency: This whole section is covered by the previous > one > and is redundant. Another way of looking at it is that it provides > implementation details to achieve the objectives of the previous section, > by > constraining the control models and specifying the recovery mechanisms. > 7.2 a, b, f, g removed, the rest moved into 7.1. > Section 7.3 - Error Control -- (b.) Define UPC events in more detail. > > Section 7.3 (c.) Needs rephrasing to make clear in what way this is a > protocol requirement rather than an MG implementation issue. Also, should > use more formal term than "shower". > "provide a mechanism to" replaced by "be able to" > Section 7.4 MIB Requirements: Note that since the MGC/MG must look like > an > H.323 GW, it must, as a unit, support the MIBs in H.341, including the RTP > MIB, etc. Mostly this burden falls on the MGC, but it seems there are two > requirements: > > 1)The protocol must provide enough information to the MGC to allow it to > support the MIBs in H.341. > Added the following to section 7.4: The protocol must allow the MG to provide to the MGC all information the MGC needs to provide in its MIB. > 2)The presence of the MG MIB must be concealable in some fashion so that > (optionally) the MG/MGC can look like an H.323 GW. This appears to > require > a bit of thought. > This comment is not understood - the MG MIB would not be visible in any way as the H.341 MIB [reference: Rosen, June 8/99] > Section 8 (c.) A suggested example of flexibility would be to allow the > SGF > (Signaling Agent Function) to reside in the Media GW Unit for H.323 > signaling. > ..but we are talking out MG functions and MGC functions here. An example of the flexibility required is for the MGC let the MG assign resources in some implementations, while in others, the MGC may want to assign the resources itself (this was added). > Section 8.1 (b) and (c): These requirements for a MG to receive messages > from more that one MGC threaten to make the protocol more complex that is > really needed. Suggest removing these requirements. > No change - this requirement will stay [reference: Rosen, June 8/99, ...] > Section 8.2 (General): The exact implication of mentioning the E.500 > series > is unclear. There is a possible implication that the protocol must > conform > to all aspects of the E.500 series. Provide specific references to > specific > documents as appropriate. A formal reference should be added as well. > sentence with E.500 in it has been removed. > Section 10: Add requirement that the protocol be able to pass through > commonly-used firewalls. > Add 10(h) that it would be desireable for the protocol to be able to pass through commonly-used firewalls. > Section 11 (General): the expression "Termination Class" is used, but > generally "bearer type" is what is meant and is a protocol-independent > phrase. > ok > Section 11 (Intro): add MultiMedia to Analogue and Restricted Capability > Applications (H.324 terminals). > Add the following two lines to Table 1: > Multimedia H.323 H.323 multimedia IP,ATM > Gateway and MCU > Multimedia H.320 h.323 GW and MCU ISDN, SS7 > ok > Section 11.1.1: add the following items: > k. H-channel (n x 64K) calls to/from the SCN. > l. B channel aggregation protocols for creating high speed channels for > multimedia over the SCN. > m. Modem terminations and negotiations > ok > Section 11.1.2 (c.) Make this required; not FFS. (reporting of codec > re-negotation). > No change - this remains FFS, since there is no proposal on the table today on how to do it. > Section 11.1.2 (h.) "seperate RTP flow" for DTMF - shouldn't this be the > same RTP flow as for voice?? What is meant by this? > 11.1.2(h) is replaced by section 5.3(e) > Add Section 11.1.2 (l) (required) The protocol shall allow for a request > to > initiate an H.323 call from the MGW (which implies the SG Function for > H.323 > is in the Media GW Unit). It also shall allow for the Media GW Unit to > report that arrival of such a call to the MGC. > [PTT: We never got back to discussing this one, after noting the need to > do > so.] > > Section 11.1.3: Should say somewhere that H.323 Annex C operation is > supported. > reference added to 11.1.3.3 Media Adaptation (i) > Section 11.2.4: should be > 11.2.4. Trunking/Access Gateway with text telephone access ports > Support translation of modem text conversation to/from audio > ok > Sections 11.2.7 (Analog GW) and 11.2.9 (ISDN GW): These sections should be > removed as they are not really applications. > ok > Section 11.2.10. Suggest changing the title to "MultiMedia GW" and > generalizing. The need is to be able to tell the MG what protocol to use > on > the SCN side (H.320, H.324) and what protocol to use on the packet side > (H.323) or ATM side (H.310, H.321). An implied requirement is that H.245 > to > H.242 processing must take place in the MG due to timing constraints. This > should be brought out explicitly > Add: > a) the gateway should support Bonding Bearer channel aggregation > b) the gateway must support 2xB (and possibly higher rates) aggregation > via > H.221 > c) dynamically change the size of audio, video and data channels within > the > h.320 multiplex > d) the gateway must react to changes in the H.320 multiplex on 20 msec > boundaries. > e) The gateway must support TCS4/IIS BAS commands > f) That gateway must support detection and creation of DTMF tones. > g) The gateway should support SNMP MIBS as specified in H.341 > ok > Section 11.2.10 (x.-new) It must be possible on a call by call basis to > specify different applications. Thus, one call might be PSTN to PSTN under > SS7 control, while the next might be ISDN/H.320 under SS7 control to > H.323. > This is only one example; the key requirement is that the protocol not > prevent such applications. > added > Section 11.2.11.: Web based and text based alternatives to IVR functions > should be more strongly promoted, if not required. This is needed by deaf, > hard-of-hearing and people from other language regions. And for all of us > who are tired of the tedious IVR systems. Maybe also for fax users and > multimedia users. > > Section 11.2.12: add > 11.2.12 Multipoint Control Units > The protocol shall support a mechanism to create multipoint conference of > audio only and multimedia conferences in the MG. > - audio mixing; mixing multiple audio streams into a new composite audio > stream > - audio switching; selection of incoming audio stream to be sent out to > all > conference participants. > - video switching; selection of video stream to be sent out to all > conference particiapants > - lecture video mode; a video selection option where on video source is > sent > out to all conference users > - multipoint of T.120 data conferencing > added > A final thought: > How are Mobile networks connected to the model? They may need to be > separately handled. > > ____________________ > > > * Contact: > Tom Taylor > Tel: +1 613 736 0961 > Fax: +1 613 736 0961 > E-mail: taylor(a)nortelnetworks.com > > -------------------------------------------------------------------------- > Nancy M. Greene > Internet & Service Provider Networks, Nortel Networks > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

1 0

af-saa-0124.000 inclusion in HGCP???
by /Q11, Q12, Q13 21 Jun '99

21 Jun '99

Hello, Is there any intention of including the af-saa-0124.000 scenario into the HGCP document. As this document is pointed by H323V3 I was wondering if SG16 would also include the requirements of this specification into the HGCP document. This would mean at least an additional bullet into the MG requirements. I know that one of the problem might be that HGCP refers to H323 V2 rather than V3 but I believe that especially for access gateways the af-saa-0124.000 might be an interesting scenario. Any comments? Ameneh Zahir - Alcatel

1 0

Invitation from the Berlin meeting host
by Sakae OKUBO 20 Jun '99

20 Jun '99

Dear Q.12-14/16 experts, Attached please find the invitation from the meeting host of the Rapporteur meeting in Berlin (2-6 August 1999), Mr. Joerg Ott. If you intend to attend the meeting, please take reservation and other actions. The meeting notice of this Rapporteur meeting will follow very soon. 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 *********************************************************** Dear colleagues, we are pleased to officially invite you to the next Joint Rapporteurs meeting of Questions 11-15 of SG 16 to be held in the city of Berlin, Germany, 2 - 6 August 1999. This mail should provide you with all necessary information about the meeting itself and support you making your travel arrangements. Meeting Location ---------------- The meeting will be held in the Grand Hotel Esplanade close the heart of the city. Besides all necessary meeting facilities, the hotel features sauna, pool, fitnes center, several restaurants, Harry's New York Bar among others. All rooms are equipped with phone and modem line (German TEA plugs, RJ11-adapters are available from the concierge). Those of you who do have travel kits or separate German TAE-RJ11 adapters, please bring them in any case. Electrical current in Germany is 220V~ at 50Hz. We have reserved a block of rooms until 1 July 1999. Please make your room reservations as soon as possible contacting the hotel directly. GRAND HOTEL ESPLANADE BERLIN Luetzowufer 15 10785 Berlin-Tiergarten Voice: +49 30 254 78-0 Fax: +49 30 265 1171 EMail: info(a)esplanade.de WWW: http://www.esplanade.de/eframe.htm The room rate is DEM 280,00 -- approximately USD 150 -- per night for a single/double room. This rate includes a breakfast buffet. Please make sure to refer to the keyword "ITU-Meeting" when making your reservation to obtain the special rate. You need to guarantee the room reservation with your credit card (as usual). The hotel has a 72-hour cancellation policy. If you cancel later than 72 hours before arrival, 50% of your total room charge will have to be paid. Registration ------------ There is a meeting fee of DEM 500,00 for early registration (up to and including 1 July, the Hotel room block deadline), and a fee of DEM 650,00 after this date. To allow us to make all the necessary arrangements and process payment of the meeting fee, please register as soon as possible using the attached fax form. Payment can be made with Visa and Mastercard. We are sorry that we cannot process electronic registration forms for payment. In addition, please send a separate e-mail registration to me and copy the Rapporteurs on this e-mail. Please use the subject and message body format shown below. To: jo(a)teles.de Cc: okubo(a)giti.or.jp, dskran(a)ascend.com, ggf(a)lucent.com, tom.geary(a)conexant.com, garysull(a)microsoft.com Subject: Berlin meeting registration NAME: COMPANY: EMAIL: ARRIVAL: DEPARTURE: Please attach a *small* photograph of yourself as GIF or JPG format and send this to jo(a)teles.de attached the registration mail (the Rapporteurs may not want to receive these copies as well). Meeting Facilities ------------------ We have reserved three meeting rooms plus a separate room for printing, document storage, etc. The larger meeting rooms will be equipped with data projectors, most of the rooms will have a 10BaseT Ethernet with Internet access. A file server will be available, preloaded with all documents that were posted to the ftp site prior to the meeting. Also, a shared printer will be provided. We will not offer photocopying service (at least not for large quantities or quick turnover), so please bring your laptop computer so that we can review documents electronically. For emergencies, the business center of the hotel and the concierge are available. Note that this will be really expensive. We will provide a sufficient number of Ethernet hubs/switches for all participants. All you need to bring is a 5 meter / 16 feet twisted pair cable to connect your computer to the hub. Starting on Monday morning, 8.00, the on-site registration will be open where you will receive some additional information concerning the meeting, the social event, and the city. When registering, you will also receive a bagde for access to the meeting rooms that needs to be worn all week long during the meeting. All meeting rooms can be locked over lunch breaks as well as at night. Meeting attendees will be able to get access using their badge 24 hours/day. Depending on the interest there might be some form a a full-day social event on Sunday, August 1st, in addition to the social on Wednesday evening. We will plan this event according to the number of participants and wheather conditions. Tentatively we plan on a tour outside of Berlin in the East-German countryside. Please let us know whether you are interested. Documentation ------------- As stated before, we are focusing on electronic copies of documents during the meeting. Long input documents, however, are more convenient to be reviewed as paper copies. For Q.12-14, please bring 80 copies of all your contributions on paper (preferably double-sided, 2 pages on a one). For Q.11, please bring 15 copies, for Q.15, 50 copies. Alternatively, you can mail your copies prior to the meeting to TELES AG -- Dr. Stephan Wenger -- Dovestr. 2-4 D-10587 Berlin GERMANY Travel Information & Logistics ------------------------------ Arrival by plane: Berlin (code BER) has three airports. There are direct flights to Berlin from many major European cities; intercontinental flight are typically one hop away: via Frankfurt, Munich, Paris, London, Hamburg (for Scandinavia). Two of the airports are conveniently located to get to the hotel: * Tegel (code TXL) Most flights to Berlin arrive at Tegel airport including - flights from Frankfurt (typically Lufthansa/United Airlines) - flights from London (British Airways/Deutsche BA) - flights from Paris (Air France) If you arrive at Tegel, don't get annoyed by the time it takes your luggage to appear, and then take one of the numerous cabs waiting outside the terminal buildings. It takes about 15-20 minutes to get to the hotel and should cost about DEM 20-30. * Tempelhof (code THF) Some flights from major European cities (e.g. Geneva, Brussels, Copenhagn) arrive at Tempelhof airport, but this is the minority. If you arrive at Tempelhof, do not get annoyed by potentially long immigration lines and take a taxi to the hotel. It takes about 10-15 minutes and should cost DEM 15-20. The third airport is Berlin Sch $BSO (Befeld (code SXF) which is located south of Berlin, outside the city. You definitely want to avoid to arrive at this airport since getting into town does not only take ages but is also costly (DEM 100+) or -- if you get a rental car -- somewhat adventurous :-) Berlin has a huge number of taxis and also a large network of public transportation: subway ("U-Bahn", tram ("S-Bahn"), Buses. They run frequently and quite few all night long (less frequently though). Plus Berlin has little free parking space in the center. Since the hotel is centrally located, we suggest that you do not rent a car, at least not for the duration of the meeting, as it will be sitting in a hotel parking lot (DEM 28,00 day unlimited in/out, not included in theroom rate) for most of the time anyway. Arrival by train: If you arrive by train, terminate your train ride at the station "Zoologischer Garten". From there, take a taxi to the hotel (this should take about 10 minutes). Arrival by car: >From any direction except south-east (SXF airport) and east (Poland) try to gain the B2/B5 major road, called Heerstrasse, Bismarckstrasse, or Strasse des 17. Juni (depending where you are). Follow this street direction east until you reach the "Siegessaeule", a high monument located in the middle of circular traffic. Here, turn right into "Hofjaegerallee". Stay on the second lane from the left. About 500 meters from the Siegessaeule, two lanes brake left and three lanes continue straigt. Continue straight, now on the leftmost lane. Turn left on the next opportunity (Luetzow-Ufer). The Hotel is 100 meters later on your right. If you come from SXF, buy a map first. Then try to reach the "A100 Stadtring" freeway in the western part of the city. This is NOT the freeway close to the airport and you will have some city traffic before you reach it. Continue on A100 until you reach the Sachsendamm exit. Turn left on Sachsendamm and continue for about 1.2 km until you reach Martin-Luther-Str, where you turn slightly right (this is the second major crossing). Continue on this street for roughly 2.5 km (making a slight right turn at the "Urania" after 1.5 km) until you can turn right into Hofjaegerallee. Please note that this area undergoes a lot of changes due to construction activity. Freshly bought maps might or might not up-to date, a two year old map is surely outdated in the questionable area. Luxury rental cars (DEM 300 per day, which is about twice as much as a compact) can be ordered with a Navigation System, where an electronic map in conjunction with GPS navigation guides you to your destination. Highly recommended. Weather conditions ------------------- Weather in Berlin is pretty unpredictable; we may have some 30+ degrees Celsius (85+ F) for weeks or we may have cloudy skies and rain for a week or two at temperatures of only some 15 C (60 F). We recommend to observe the weather forecasts e.g. at http://www.weather.com/weather/cities/gm__berlin.html Typically, the weather will be great but it is almost certain to have some rain as well. Further Information ------------------- The "official" Berlin web site can be found at http://www.berlin.de/ and features a large section in English (unfortunately only parts or the entire web site are translated so far) and a city map ("Stadtplan") that may help you to interactively locate places of interest (such as the hotel) and obtain map information at virtually arbitrary level of detail. Any Questions? -------------- We are happy to answer any questions you may have, just send us mail: Joerg jo(a)teles.de Stephan stewe(a)cs.tu-berlin.de Please do not send any questions to any of the mailing lists. We look forward to seeing you in Berlin, Stephan & Joerg

1 0

Re: FW: Transport - FW: new I-D: draft-cuervo-megaco-tudp-00.txt
by Edgar Martinez [1] 20 Jun '99

20 Jun '99

Another reliable signaling protocol in megaco.. Why not us Sigtran's Common Transport Protocol (CTP)?? Ed Nancy-M Greene wrote: > > > Until it appears on the IETF web site, the following Internet-Draft is > > available at ftp://standards.nortelnetworks.com/megaco/docs/Oslo99/ - in > > there, you will find the file > > draft-cuervo-megaco-tudp-00.txt. > > > > This I-D is a proposal that addresses the transport issue for > > Megaco/H.gcp. Any comments on the draft are welcome. ***Please post > > comments on megaco(a)standards.nortelnetworks.com.**** > > > thanks, > > Nancy > > -------------------------------------------------------------------------- > > Nancy M. Greene > > Internet & Service Provider Networks, Nortel Networks > > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > > > > ---------- > > From: Greene, Nancy-M [CAR:5N10:EXCH] > > Sent: Tuesday, June 15, 1999 9:26 PM > > To: 'internet-drafts(a)ietf.org' > > Cc: Cuervo, Fernando [CAR:5N10-I:EXCH]; Rayhan, Abdallah > > [CAR:5N00:EXCH]; 'smayer(a)dynamicsoft.com' > > Subject: new I-D: draft-cuervo-megaco-tudp-00.txt > > > > Please find attached a new internet-draft for you to post. This draft is > > relevant to the Megaco WG. > > > > Title : Transaction UDP plus Timers (TUDP) for > > MEGACO > > Author(s) : F. Cuervo, A. Rayhan, J. S. Mayer > > Filename : draft-cuervo-megaco-tudp-00.txt > > Pages : 22 > > Date : 15-Jun-99 > > > > This document describes transaction-oriented reliable UDP with timers > > (TUDP). It can be used to provide reliable delivery of transactions for > > MEGACO [1] applications. The objective of the protocol is to deliver > > transactions and messages within the time constraints of the application, > > i.e., the application timer. Transaction sequences are ordered perstream, > > and superseding of transactions is allowed. > > > > MEGACO implementations may choose to use TUDP for applications that > > require high fan-out, reliable and ordered delivery. Other transports such > > as TCP, UDP or SIGTRAN may be useful in other situations. > > > > > > Nancy > > -------------------------------------------------------------------------- > > Nancy M. Greene > > Internet & Service Provider Networks, Nortel Networks > > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > > > > -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 TIPHON & Other Stds -- http://www.cig.mot.com/~martinze/

1 0

Re: New version of H.GCP
by Nancy-M Greene 18 Jun '99

18 Jun '99

The solution seems to be to ask your browser to do a refresh. The file is there, but your browser is holding an older version of the contents of the ftp site. Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: Edgar Martinez [1][SMTP:martinze@CIG.MOT.COM] > Sent: Friday, June 18, 1999 8:48 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: New version of H.GCP > > I get the same as Roy where is The filename is hgcp_6_16.pdf. > > Roy Spitzer wrote: > > > > Nancy, > > > > Are there special access rights or a different login necessary? It > appears > > that I do not have full visibility to this Nortel site. The following > is > > the view I get when accessing the site. Thank you for your help. > > > > FTP directory /megaco/docs/Oslo99 at standards.nortelnetworks.com > > > > Up to higher level directory <..> > > 03/26/99 08:26AM 179,299 draft-ietf-megaco-protocol-00.txt > > </megaco/docs/Oslo99/draft-ietf-megaco-protocol-00.txt> > > 05/04/99 03:10AM 185,304 draft-ietf-megaco-protocol-01.txt > > </megaco/docs/Oslo99/draft-ietf-megaco-protocol-01.txt> > > 05/04/99 03:09AM 74,654 draft-ietf-megaco-reqs-03.txt > > </megaco/docs/Oslo99/draft-ietf-megaco-reqs-03.txt> > > 04/13/99 09:25PM 1,017,856 HGCP.DOC </megaco/docs/Oslo99/HGCP.DOC> > > 04/13/99 09:25PM 235,504 HGCP.PDF </megaco/docs/Oslo99/HGCP.PDF> > > 04/13/99 09:26PM 332,651 HGCP.ZIP </megaco/docs/Oslo99/HGCP.ZIP> > > 05/31/99 06:32PM 140,096 HgcpSantiago.pdf > > </megaco/docs/Oslo99/HgcpSantiago.pdf> > > 04/15/99 06:08PM 15,506 IssueList.PDF > > </megaco/docs/Oslo99/IssueList.PDF> > > > > Regards, > > Roy > > > > Roy Spitzer Telogy Networks, Inc. > > Phone: (301) 515-6531 20250 Century Blvd. > > Fax: (301) 515-7954 Germantown, MD 20874 > > Email: rspitzer(a)telogy.com > > > > -----Original Message----- > > From: Nancy-M Greene > [mailto:ngreene@NORTELNETWORKS.COM] > > Sent: Thursday, June 17, 1999 9:16 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: New version of H.GCP > > > > ... a good reason to go with pdf... I posted a pdf > version > > of the document > > at > > > > ftp://standards.nortelnetworks.com/megaco/docs/Oslo99/ > > > > The filename is hgcp_6_16.pdf > > > > Nancy > > > > > -------------------------------------------------------------------------- > > Nancy M. Greene > > Internet & Service Provider Networks, Nortel Networks > > T:514-271-7221 (internal:ESN853-1077) > > E:ngreene@nortelnetworks.com > > > > John Segers writes: > > > I have the same problem with the document Bryan > posted: no > > pictures. > > > > > > On your second point, I agree that it makes sense to > talk > > about > > > composing units (MGU, MGCU, SGU) into a complete GW. > > > > > > Regards, > > > > > > John Segers > > > > > > > > -- > Edgar Martinez - Principal Staff Engineer > Email mailto:martinze@cig.mot.com > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > 1501 West Shure Drive, Arlington Hgts. IL 60004 > TIPHON & Other Stds -- http://www.cig.mot.com/~martinze/ >

1 0

H.341 decided version
by Sakae OKUBO 18 Jun '99

18 Jun '99

Dear Q.12-14/16 experts, Irina Suconick wrote: > I have uploaded two files for the decided H.341 document > into the Incoming directory of the PictureTel ftp site. > H.341 clean document - H341nmc.doc > H.341 change-marked document against the white paper - H341wcm.doc I have zipped them and moved them to /9905_San directory. ftp://standard.pictel.com/avc-site/9905_San/H341NCM.zip ftp://standard.pictel.com/avc-site/9905_San/H341WCM.zip or http://standard.pictel.com/ftp/avc-site/9905_San/H341NCM.zip http://standard.pictel.com/ftp/avc-site/9905_San/H341WCM.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

Re: New version of H.GCP
by Edgar Martinez [1] 18 Jun '99

18 Jun '99

I get the same as Roy where is The filename is hgcp_6_16.pdf. Roy Spitzer wrote: > > Nancy, > > Are there special access rights or a different login necessary? It appears > that I do not have full visibility to this Nortel site. The following is > the view I get when accessing the site. Thank you for your help. > > FTP directory /megaco/docs/Oslo99 at standards.nortelnetworks.com > > Up to higher level directory <..> > 03/26/99 08:26AM 179,299 draft-ietf-megaco-protocol-00.txt > </megaco/docs/Oslo99/draft-ietf-megaco-protocol-00.txt> > 05/04/99 03:10AM 185,304 draft-ietf-megaco-protocol-01.txt > </megaco/docs/Oslo99/draft-ietf-megaco-protocol-01.txt> > 05/04/99 03:09AM 74,654 draft-ietf-megaco-reqs-03.txt > </megaco/docs/Oslo99/draft-ietf-megaco-reqs-03.txt> > 04/13/99 09:25PM 1,017,856 HGCP.DOC </megaco/docs/Oslo99/HGCP.DOC> > 04/13/99 09:25PM 235,504 HGCP.PDF </megaco/docs/Oslo99/HGCP.PDF> > 04/13/99 09:26PM 332,651 HGCP.ZIP </megaco/docs/Oslo99/HGCP.ZIP> > 05/31/99 06:32PM 140,096 HgcpSantiago.pdf > </megaco/docs/Oslo99/HgcpSantiago.pdf> > 04/15/99 06:08PM 15,506 IssueList.PDF > </megaco/docs/Oslo99/IssueList.PDF> > > Regards, > Roy > > Roy Spitzer Telogy Networks, Inc. > Phone: (301) 515-6531 20250 Century Blvd. > Fax: (301) 515-7954 Germantown, MD 20874 > Email: rspitzer(a)telogy.com > > -----Original Message----- > From: Nancy-M Greene [mailto:ngreene@NORTELNETWORKS.COM] > Sent: Thursday, June 17, 1999 9:16 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: New version of H.GCP > > ... a good reason to go with pdf... I posted a pdf version > of the document > at > > ftp://standards.nortelnetworks.com/megaco/docs/Oslo99/ > > The filename is hgcp_6_16.pdf > > Nancy > > -------------------------------------------------------------------------- > Nancy M. Greene > Internet & Service Provider Networks, Nortel Networks > T:514-271-7221 (internal:ESN853-1077) > E:ngreene@nortelnetworks.com > > John Segers writes: > > I have the same problem with the document Bryan posted: no > pictures. > > > > On your second point, I agree that it makes sense to talk > about > > composing units (MGU, MGCU, SGU) into a complete GW. > > > > Regards, > > > > John Segers > > > > -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 TIPHON & Other Stds -- http://www.cig.mot.com/~martinze/

1 0

Re: New version of H.GCP
by Roni Even 17 Jun '99

17 Jun '99

Hi, I used the link in the email and got the file with no problem. ********************************************** Roni Even VP Product Marketing Accord Video Telecommunication Email: roni_e(a)accord.co.il Tel: +972-3-9251412 Fax: +972-3-9211571 *************************************************** > -----Original Message----- > From: Nancy-M Greene [SMTP:ngreene@NORTELNETWORKS.COM] > Sent: Thursday, June 17, 1999 3:16 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: New version of H.GCP > > ... a good reason to go with pdf... I posted a pdf version of the > document > at > > ftp://standards.nortelnetworks.com/megaco/docs/Oslo99/ > > The filename is hgcp_6_16.pdf > > Nancy > ---------------------------------------------------------------------- > ---- > Nancy M. Greene > Internet & Service Provider Networks, Nortel Networks > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > > John Segers writes: > > I have the same problem with the document Bryan posted: no pictures. > > > > On your second point, I agree that it makes sense to talk about > > composing units (MGU, MGCU, SGU) into a complete GW. > > > > Regards, > > > > John Segers > > > >

1 0

Re: New version of H.GCP
by Roy Spitzer 17 Jun '99

17 Jun '99

Nancy, Are there special access rights or a different login necessary? It appears that I do not have full visibility to this Nortel site. The following is the view I get when accessing the site. Thank you for your help. FTP directory /megaco/docs/Oslo99 at standards.nortelnetworks.com Up to higher level directory <..> 03/26/99 08:26AM 179,299 draft-ietf-megaco-protocol-00.txt </megaco/docs/Oslo99/draft-ietf-megaco-protocol-00.txt> 05/04/99 03:10AM 185,304 draft-ietf-megaco-protocol-01.txt </megaco/docs/Oslo99/draft-ietf-megaco-protocol-01.txt> 05/04/99 03:09AM 74,654 draft-ietf-megaco-reqs-03.txt </megaco/docs/Oslo99/draft-ietf-megaco-reqs-03.txt> 04/13/99 09:25PM 1,017,856 HGCP.DOC </megaco/docs/Oslo99/HGCP.DOC> 04/13/99 09:25PM 235,504 HGCP.PDF </megaco/docs/Oslo99/HGCP.PDF> 04/13/99 09:26PM 332,651 HGCP.ZIP </megaco/docs/Oslo99/HGCP.ZIP> 05/31/99 06:32PM 140,096 HgcpSantiago.pdf </megaco/docs/Oslo99/HgcpSantiago.pdf> 04/15/99 06:08PM 15,506 IssueList.PDF </megaco/docs/Oslo99/IssueList.PDF> Regards, Roy Roy Spitzer Telogy Networks, Inc. Phone: (301) 515-6531 20250 Century Blvd. Fax: (301) 515-7954 Germantown, MD 20874 Email: rspitzer(a)telogy.com -----Original Message----- From: Nancy-M Greene [mailto:ngreene@NORTELNETWORKS.COM] Sent: Thursday, June 17, 1999 9:16 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: New version of H.GCP ... a good reason to go with pdf... I posted a pdf version of the document at ftp://standards.nortelnetworks.com/megaco/docs/Oslo99/ The filename is hgcp_6_16.pdf Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com John Segers writes: > I have the same problem with the document Bryan posted: no pictures. > > On your second point, I agree that it makes sense to talk about > composing units (MGU, MGCU, SGU) into a complete GW. > > Regards, > > John Segers > >

1 0

Re: New version of H.GCP
by Nancy-M Greene 17 Jun '99

17 Jun '99

... a good reason to go with pdf... I posted a pdf version of the document at ftp://standards.nortelnetworks.com/megaco/docs/Oslo99/ The filename is hgcp_6_16.pdf Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com John Segers writes: > I have the same problem with the document Bryan posted: no pictures. > > On your second point, I agree that it makes sense to talk about > composing units (MGU, MGCU, SGU) into a complete GW. > > Regards, > > John Segers > >

1 0

Re: New version of H.GCP
by Boaz Michaely 17 Jun '99

17 Jun '99

Dear Bryan, 1. I am unable to view any of the graphics. They all appear as a big red X . 2. As there was no objection from anyone, would you care to integrate the definitions I have proposed ? Again, she spirit of the change is that this standard is about composing H.323 gateways out of H.GCP MGCs and MGs, rather than the other way around. This, along with clear minimal requirements for the MGC and the MG is absolutely necessary in order to assure interoperability. Due to some urgent assignments, I was unable to deliver the text I started to work on, I hope have it next week. Best Regards, Boaz Boaz Michaely Senior Program Manager, Advanced Technologies VocalTec Communications Ltd e-mail boaz(a)vocaltec.com Tel +972 (9) 970-7869

2 1

Re: Megaco/H.gcp conference call
by Nancy-M Greene 16 Jun '99

16 Jun '99

Minutes of the Megaco/H.gcp conference call held June 16th/99, 11amET to 1:50pmET Number of participants: about 30, including Megaco, SG16, and Megaco/SG16 participants The meeting was structured around the following agenda points - they are each addressed below. 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) 8) code points process 9) naming an editor team for a combined IETF/SG16 document, document format ***NOTE, if you wish to start a new discussion thread on any of the topics below, PLEASE put a relevant subject on your msg (e.g. Subject: Issue #1) , and do not simply reply to this email. ***Another NOTE: all internet-drafts relevant to Megaco are at available at: ftp://standards.nortelnetworks.com/megaco/docs/Oslo99/ , as well as at ftp://ftp.ietf.org/internet-drafts Issue #1) Termination naming - hierarchical or logical, or a combination with TerminationId + Bearer? & Issue #2) handling multplexing terminations - as in H.gcp? or as a new context type? ------------- - Question: Is a circuit that is outside a context a kind of termination, or a separate construct? Much discussion from Brian Rosen, Paul Sijben, John Segers, Mike Buckley, Fernando Cuervo, Tom Taylor. There seemed to be consensus that a circuit is a kind of termination. However, it was brought up by Fernando Cuervo that if we consider the concept of resources for function keys, indicators, displays, softkeys, and dialpads, that are outside a context, as described in the IP Phone draft (draft-blatherwick-megaco-ipphone-00.txt), then perhaps we could consider a circuit as a resource when it is outside a context. - note that an issue had come up on the list that management issues may be out of scope of Megaco. In fact, COT cannot be considered management - it is part of ISUP call control and setup, so we need a way of expressing COT across the Megaco boundary. - it was agreed that the definition of an MG is: an MG does media adaptation and connections, nothing more - There was discussion on whether an MG knows about the concept of "users". Conclusion: a) We need better definitions of Termination and Context, and THEN define how to create a multiplex using terminations and contexts. b) Brian Rosen and Paul Sijben agreed to talk about Issues #1 and #2 tommorrow (June 17th) and post a msg to the Megaco mailing list. If there is consensus on the outcome of their conversation, this issue is closed, if not, Tom Taylor will appoint a design team to come up with a solution within a week. Issue #3) allowing one BearerDescriptor, and multiple MediaDescriptors per termination - acceptable? - related to #1 and #2 - not discussed - wait to see output from Brian Rosen and Paul Sijben. Issue #4) decision on transport ------------- Conclusion: - agreed that the Megaco protocol must define something for transport. We need something for fragmentation, and need to define the timers that the MGC and MG will use, how they will use them (i.e. what will the retry mechanism be), and be able to suggest default values for them. The transport solution itself could be in a separate document. - agreed that both MGC and MG "must" implement some kind of "UDP + timers" mechanism. We need to choose one. There are two proposals on the table: 1) the UDP + timers method in the Telcordia/Cisco MGCP - draft-huitema-megaco-mgcp-v0r1-05.txt, and 2) Transaction UDP + Timers (TUDP) - draft-cuervo-megaco-tudp-00.txt - This one has just come out, and addresses the needs of Megaco - people are invited to read it and comment on it. - agreed that the MGC and MG both "may" implement TCP. Issue #5) proposal for tagging the MediaDescriptor with its encoding: SDP or H.GCP & Issue #6) proposal for text vs binary encoding of the protocol (draft-huitema-megaco-sdp-discuss-01.txt) ------------- - as with the transport issue, we need to nail down this issue asap, so that the protocol can begin to be implemented - there was a desire to go with what we have already, which means SDP, but there is still the issue of and/or capability syntax to be added to the SDP - it was mentioned that we need to be able to express all codec parameters in SDP and in H.245 - Christian Huitema has built comparison tables for this already - see draft-huitema-megaco-sdp-discuss-01.txt Conclusion: - agreed that we will wait a week for Joerg Ott and Gur Kimchi to put a proposal on the table that allows us to express and/or syntax for stating codec capabilities - for example an MG can support both G.723 and GSM, but not both at the same time. - Tom Taylor will probably pull together a small design team to bring this issue to conclusion within the next week and a half. Issue #7) multimedia vs monomedia contexts (related to #3) ------------- - not discussed, although there seems to be consensus for multimedia contexts. Issue #8) code points process ------------- - Tom Taylor brought up the issue of having a registry to define code points for Megaco. - discussed that if we had a single registry, say IANA, then we could possibly modify H.245 to use code points coming out of IANA - there is a precedent for this: H.245 refers to IANA-defined RTP payload types. Conclusion: - look at new object oriented extension for defining codepoints in H.245 (in the H.245 coming out of Santiago) - if this is used, then IANA could define the codepoints, and it would be possible to add them to H.245 using the object oriented extension mechanism without having to change H.245 (NOTE: not sure if I got this right...) Issue #9) naming an editor team for a combined IETF/SG16 document, document format ------------- - addressed in Tom's email - see below: > ---------- > From: Taylor, Tom-PT [CAR:5V00-I:EXCH] > Sent: Wednesday, June 16, 1999 2:23 PM > To: megaco(a)standards.nortelnetworks.com > Subject: Working Methods For Our Protocol Document > > We came to several conclusions on the Megaco/H.GCP conference call today > regarding the mechanics of developing the protocol draft: > * Brian Rosen and Bryan Hill are officially co-editors of the > document, from both the IETF and the ITU point of view. (There may be ITU > legalities to be fulfilled before that is fully so). > * We are going with a single document from here on. That is, the > next > document merges the Megaco and H.GCP drafts. > * Our working documentation will be in the form of PDF files posted > on > the web site. Of course, when it is time to create an RFC, this will be > turned into text and Postscript. > > I have to ask: will this final point cause anyone major difficulties? Is > anyone in a position where they cannot read Adobe PDF? One drawback I can > think of is the inability to cut and paste quotations from the document > when > suggesting changes. Is this a major hangup, and if so, what suggestions > for > work-arounds? > > Tom Taylor > ----------- Once again, if I have made any errors or omissions in these minutes, please let me know. Thanks to those who joined the call. Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

1 0

New version of H.GCP
by Bryan Hill 16 Jun '99

16 Jun '99

Hi All, The latest H.GCP is attached. The file has been compressed via pkzip. Bryan <<HGCP616.ZIP>>

1 0

Decided H.341 document
by Irina Suconick 16 Jun '99

16 Jun '99

> Dear Mr. Okubo, > > I have uploaded two files for the decided H.341 document > into the Incoming directory of the PictureTel ftp site. H.341 clean document - H341nmc.doc H.341 change-marked document against the white paper - H341wcm.doc > Best regards, Irina

1 0

Bandwidth Control/Bandwidth Management
by VIPIN PALAWAT 16 Jun '99

16 Jun '99

Hi All, Can anyone tell me the idea behind keeping Bandwidth Control(mandatory for GK) and Bandwidth Management(optional for GK)as two different entities in H.323 standards. Regards Vipin --------------------------------------------------- Have a Nice Day!!! mailto:vipinpal@wipsys.soft.net

2 1

Reminder: Megaco/H.gcp conference call
by Nancy-M Greene 15 Jun '99

15 Jun '99

> ---------- > From: Greene, Nancy-M [CAR:5N10:EXCH] > Sent: Tuesday, June 08, 1999 2:10 PM > To: megaco(a)standards.nortelnetworks.com > Subject: Megaco/H.gcp conference call > > In order to continue the cooperation between SG16 and the IETF, Brian Hill > and I would like to schedule 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 bhill(a)videoserver.com > -------------------------------------------------------------------------- > Nancy M. Greene > Internet & Service Provider Networks, Nortel Networks > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com >

1 0

FW: Transport - FW: new I-D: draft-cuervo-megaco-tudp-00.txt
by Nancy-M Greene 15 Jun '99

15 Jun '99

> Until it appears on the IETF web site, the following Internet-Draft is > available at ftp://standards.nortelnetworks.com/megaco/docs/Oslo99/ - in > there, you will find the file > draft-cuervo-megaco-tudp-00.txt. > > This I-D is a proposal that addresses the transport issue for > Megaco/H.gcp. Any comments on the draft are welcome. ***Please post > comments on megaco(a)standards.nortelnetworks.com.**** > thanks, > Nancy > -------------------------------------------------------------------------- > Nancy M. Greene > Internet & Service Provider Networks, Nortel Networks > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > > ---------- > From: Greene, Nancy-M [CAR:5N10:EXCH] > Sent: Tuesday, June 15, 1999 9:26 PM > To: 'internet-drafts(a)ietf.org' > Cc: Cuervo, Fernando [CAR:5N10-I:EXCH]; Rayhan, Abdallah > [CAR:5N00:EXCH]; 'smayer(a)dynamicsoft.com' > Subject: new I-D: draft-cuervo-megaco-tudp-00.txt > > Please find attached a new internet-draft for you to post. This draft is > relevant to the Megaco WG. > > Title : Transaction UDP plus Timers (TUDP) for > MEGACO > Author(s) : F. Cuervo, A. Rayhan, J. S. Mayer > Filename : draft-cuervo-megaco-tudp-00.txt > Pages : 22 > Date : 15-Jun-99 > > This document describes transaction-oriented reliable UDP with timers > (TUDP). It can be used to provide reliable delivery of transactions for > MEGACO [1] applications. The objective of the protocol is to deliver > transactions and messages within the time constraints of the application, > i.e., the application timer. Transaction sequences are ordered perstream, > and superseding of transactions is allowed. > > MEGACO implementations may choose to use TUDP for applications that > require high fan-out, reliable and ordered delivery. Other transports such > as TCP, UDP or SIGTRAN may be useful in other situations. > > > Nancy > -------------------------------------------------------------------------- > Nancy M. Greene > Internet & Service Provider Networks, Nortel Networks > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > >

1 0

H.Multilin
by Mickey Nasiri (ETX) 15 Jun '99

15 Jun '99

Dear colleagues, Could any of you help me with following question. In H.324 D.4.6.1 "Exceptional bypass of V.140" it is explained how to bypass (or when it is possible to bypass) V.140. I wonder if it is possible to use H.multilink (H.226) if V.140 is bypassed? In other words: Is it possible to start H.multilink later than from the beginning. (start without H.226 and connect it later). 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

Re: Questions on H.GCP applied on text telephony
by Gunnar Hellstrom 11 Jun '99

11 Jun '99

John, I like your idea of a script driven termination, and that without the script, the MGC gets all events and has to take all decisions. Could be the appropriate model rather than the "user driven multiplexor" I described. Do you then see the context on the IP side containing both streams for text and voice and that the modem side gets orders of what stream to feed at each moment. (Rather than changing the context back and forth to contain only the currently active IP-termination.) Regards Gunnar At 05:47 PM 1999-06-10 +0200, John Segers wrote: >Gunnar, > >It took me a while to realize that you were addressing me with your >question since the thread moved over from MEGACO to SG 16 list, but I >clued in. > >My idea about transitioning between text and audio was slightly >different. I expected it would be driven by modem events. The modem >detects a carrier, and in the absence of any scripts, notifies the >controller. This then sends a command telling the Termination to change >its media to text. A script in the MG could also specify this behavior, >allowing us to get rid of the signaling to the MGC. > >In the H.GCP document, I think there would have to be a description of >the text medium as a subtype of data. And in the section explaining the >modem parameters, there has to be a reference to V.18. > >Does this sound reasonable? > >Thank you for your input, > >John Segers > >Gunnar Hellstrom wrote: >> >> 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 >> ------------------------------------- > >-- >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 -------------------------------------

2 1

A Virus was detected in the message.
by plclondon2.admin＠PLC.CWPLC.COM 11 Jun '99

11 Jun '99

The mail message subject: Take Care of Vicious Virus! to Stephen.Glick(a)plc.cwplc.com Our anti-virus software has detected a VIRUS in this message. PLEASE CLEAN AND RESEND.

1 0

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