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

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