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

Change of address
by Jim Toga 28 Feb '99

28 Feb '99

After today I am joining an IP telephony startup. For any directed email to me, please use the following address - the Intel address will be deactivated. jim.toga(a)metatel.com (my response time might be a little 'spotty' over the next couple of weeks) Best Regards, jimt. +1-503-264-8816(voice) Intel - Hillsboro, OR mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41

1 0

Re: Development of Decomposed Gateway Architecture
by Tom-PT Taylor 27 Feb '99

27 Feb '99

Most of the work items are grundge work to start with. I'm willing to tackle them until I start to run into issues that need others' comment. How would you like to start on the H.245 abstraction (interface ?:e)? > -----Original Message----- > From: Rex Coldren [SMTP:coldrenr@AGCS.COM] > Sent: Friday, February 26, 1999 7:36 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Development of Decomposed Gateway Architecture > > Tom, > Sorry to respond so late to this. In the interest of keeping my > mailbox close > to manageable I deal with the quickies first. Has anyone responded to > this or > are you taking these work items on yourself? I am wondering whether there > is > something here that you want me to tackle. > > Rex > > Tom-PT Taylor wrote: > > > This note is to point out the follow-up work required in the light of > the > > Monterey meeting's adoption of the revised Gateway functional > architecture > > as shown in TD-34 (Monterey). I am prepared to contribute to that work. > > People may wish to comment on the priorities of definition of the > different > > interfaces. > > > > First point: I followed up Bob Callaghan's pointers to the layer 4 > > interfaces applicable to our J:c interface (per the TD-34 definition). > The > > relevant references are the SDL charts shown in Annex A of Q.931 and > Annex H > > of Q.764 respectively. These show the messages exchanged over the J:c > > interface for their respective protocols, but do not show their content. > So > > that's one work item. > > > > Second point: Annex A of Q.931 shows messages going between a Q.931 > Protocol > > Control block and two higher blocks: Call Control and Resource Control > > respectively. Annex H of Q.764 is more complicated: it shows Call > Control > > above the ISUP User Part, but three blocks within it: Signalling > Procedure > > Control, Call Processing Control, and Circuit Supervision Control. I > think > > we should have a Call Control block in our picture, at the same level as > our > > High-Layer Resource Control. I also think the ISUP Circuit Supervision > > Control should report into High-Layer Resource Control rather than Call > > Control. > > > > Third point: the messaging on our ?:b interface can probably be derived > from > > the Q.931 SDL. The content also has to be worked out. Another couple > of > > work items. > > > > Final point: how to determine the content of the ?:e (abstracted H.245) > > interface and where it should flow? Definitely some detailed work items > > here. > > > > Tom Taylor > > E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor) > > Tel.: +1 613 765 4167 (internally 395-4167) > > FAX: +1 613 763 7236 (internally 393-7236)

1 0

Development of Decomposed Gateway Architecture
by Tom-PT Taylor 26 Feb '99

26 Feb '99

This note is to point out the follow-up work required in the light of the Monterey meeting's adoption of the revised Gateway functional architecture as shown in TD-34 (Monterey). I am prepared to contribute to that work. People may wish to comment on the priorities of definition of the different interfaces. First point: I followed up Bob Callaghan's pointers to the layer 4 interfaces applicable to our J:c interface (per the TD-34 definition). The relevant references are the SDL charts shown in Annex A of Q.931 and Annex H of Q.764 respectively. These show the messages exchanged over the J:c interface for their respective protocols, but do not show their content. So that's one work item. Second point: Annex A of Q.931 shows messages going between a Q.931 Protocol Control block and two higher blocks: Call Control and Resource Control respectively. Annex H of Q.764 is more complicated: it shows Call Control above the ISUP User Part, but three blocks within it: Signalling Procedure Control, Call Processing Control, and Circuit Supervision Control. I think we should have a Call Control block in our picture, at the same level as our High-Layer Resource Control. I also think the ISUP Circuit Supervision Control should report into High-Layer Resource Control rather than Call Control. Third point: the messaging on our ?:b interface can probably be derived from the Q.931 SDL. The content also has to be worked out. Another couple of work items. Final point: how to determine the content of the ?:e (abstracted H.245) interface and where it should flow? Definitely some detailed work items here. Tom Taylor E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor) Tel.: +1 613 765 4167 (internally 395-4167) FAX: +1 613 763 7236 (internally 393-7236)

2 1

Monterey meeting report APC-1554
by Sakae OKUBO 24 Feb '99

24 Feb '99

Dear participants of the Q12-14/16 Monterey meeting, I have uploaded Version of the subject document as follows: ftp://standard.pictel.com/avc-site/9902_Mon/APC-1554.zip or http://standard.pictel.com/ftp/avc-site/9902_Mon/APC-1554.zip The current version has been made by integrating TD-30, 31, 32, 37 and other TDs. Please note the following: - Obvious editorial corrections have been made. - Section 4.4 (future plan of Q12) has been added. - List of participants is yet to be edited. - Annex 5 (TD-39 with refinements) is yet to be provided. Please review it and return your comments in a week time (by Tuesday 2 March 1999). Then I will produce Version 2 with confirmed status. 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

Monterey meeting documents
by Sakae OKUBO 22 Feb '99

22 Feb '99

Dear Q.12-14/16 experts, I have uploaded all the TDs to the following place: ftp://standard.pictel.com/avc-site/9902_Mon/ or http://standard.pictel.com/ftp/avc-site/9902_Mon/ The files there are of final version as far as I believe. File names of the revised version are with suffix a (revision 1), b (revision 2), etc. Please advise me if there is anything wrong in your documents. The meeting reports made available at the end of the meeting are: TD-30 General TD-31 Q12 TD-32 Q13 TD-37 Q14 They will be edited into APC-1554. A list of all the files containing APC- and TD-numbered documents is: ftp://standard.pictel.com/avc-site/9902_Mon/9902_Mon.html or http://standard.pictel.com/ftp/avc-site/9902_Mon/9902_Mon.html 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: Relationship of H.323 and H.245 versions
by Pete Cordell 15 Feb '99

15 Feb '99

Chris, Ami, I don't think that your (Chris's) solution 1 is any worse that adapting to any remote H.245 version. Perhaps we can say that for H.323 V2, the fast start structures shall conform to H.245 V4(?), but if its over an H.245 channel then H.245 version negotiation is via TCS. Alternatively, H.245 fast start version information could go into the H.225 SETUP/CALL PROCEEDING/ALERTING/CONNECT messages. I feel this is better than adding this information to the OLCs. We also need to work through whether things will work out when we have an H.323 version 3 endpoint with, say, H.245 version 6 fast start structures talking to an H.323 version 2 endpoint. My off the top of my head analysis suggests it does work out, but perhaps somebody that it more intimately familiar with it could also check (and explain). Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Chris Purvis[SMTP:CPurvis@MADGE.COM] >Reply To: Mailing list for parties associated with ITU-T Study Group 16 >Sent: 12 February 1999 11:17 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: Relationship of H.323 and H.245 versions > Ami, So in order to Make Things Work we probably need to do one of the following: 1. Bind tightly for messages in fast connect, but loosely otherwise (which may lead to implementations having to use different ASN for encoding/decoding OLCs depending on whether or not they came in via fast connect!). 2. Add versioning information to OLCs (and possibly elsewhere while we're at it). 3. Bind versions tightly, as currently specified. 4(the controversial one). Obselete fastStart Regards, Chris > -----Original Message----- > From: Ami Amir [mailto:amir@RADVISION.RAD.CO.IL] > Sent: 10 February 1999 7:20 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Relationship of H.323 and H.245 versions > > > Pete, > It seems to me that your idea is great, and the right approach. > > I might be asking something out of context - but doesn't this > neat model > break down once we decided to do fast connect - and in essence convey > bearer control inside the call control? Can we now assume > that the versions > can gallop along independently. > > Regards > > Ami > > -----Original Message----- > From: Pete Cordell [SMTP:pete.cordell@BT-SYS.BT.CO.UK] > Sent: Tuesday, February 09, 1999 5:05 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Relationship of H.323 and H.245 versions > > Dear All, > > Just to clarify why the original question was asked,.... > > It can be readily observed that functionality can be added to H.245 > without affecting H.225. (For example, object oriented caps which > enables H.RDC etc) They are also functionally separate > items. In telco > parlance (sorry!) H.225 is call control (or user invitation etc) and > H.245 is bearer control (or media control). It is quite > legitimate for > them to evolve at different paces as to a large degree they are > orthogonal items. > > At a technical level I can see no benefit from inferring the version > number of one from the version number of the other (any examples > welcome) as these are basically two functional sub-systems working > autonomously with only loose coupling (e.g. start, stop etc). > Also, as > a gatekeeper can do call re-routing as defined in H.450 - > assuming that > the gatekeeper wants to relay messages as much as possible to > allow the > full functionality of the attached endpoints to be realised and not > dumb-down the messaging to its level - an endpoint may well receive > different versions of H.245 as the life of the call evolves > (e.g. first > connect to IVR, then route to agent, then connect to sales etc). In > this case inferring the H.245 version of the endpoint that you are > connected to, say, third in a set of re-routes from the H.225 > version of > the first endpoint you are connected to is totally bogus. > > However, to make life easier, if for marketing/procurement purposes > alone, it does make sense for an H.323 version to require a minimum > level of support from H.225 and H.245. As H.323 and H.225 are > intimately linked, saying that the H.323 version is one and > the same as > the H.225 version is no problem. However, in a technology that is in > its infancy and still trying to find its feet in terms of how people > want to use it, it seems unreasonable to link H.245 versions > explicitly > in with the H.225 issue cycle if modifying H.245 allows more timely > adaptation to perceived evolving market needs. > > For this reason I believe that the relationship of the H.245 version > should be of the "or later" type so that exploitation of > enhancements to > H.245 do not need to wait for a new issue of H.323. As an example of > why this is attractive, it may be the case that there are no changes > needed to justify an H.225 version 4. However, enhancements > may be made > to H.245 after H.225 version 3 is issued. What would we do with > H.323/H.225 in this case? > > Regards, > > Pete > ================================= > Pete Cordell > BT Labs > E-Mail: pete.cordell(a)bt-sys.bt.co.uk > Tel: +44 1473 646436 > Fax: +44 1473 645499 > ================================= > >>

1 0

None
by Simon Lee 13 Feb '99

13 Feb '99

GET itu-sg16 LOG9702 GET itu-sg16 LOG9703

1 0

APC-1516, 1517, 1518
by Francois Audet 12 Feb '99

12 Feb '99

Hi, APC-1516, 1517 and 1518 have been placed in the incoming directory. APC-1516 is the ATM Forum's Gateway for H.323 Media transport over ATM baseline text. It just went out for straw ballots comments. APC-1517 and APC-1518 are brought in a Nortel Company contribution. ----- François Audet Tel:+1 408 565 5675 mailto:audet@NortelNetworks.com Nortel Networks Fax:+1 408 565 2375 http://www.NortelNetworks.com

1 0

APC-1547 Uploaded
by Tom-PT Taylor 12 Feb '99

12 Feb '99

APC-1547, the latest draft of Megaco's architecture and requirements document, has been uploaded to the Incoming directory. Tom Taylor E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor) Tel.: +1 613 765 4167 (internally 395-4167) FAX: +1 613 763 7236 (internally 393-7236)

1 0

Revised version of APC-1539
by Louis Christodoulides 12 Feb '99

12 Feb '99

Dear Mr. Okubo, I have uploaded a revised version of APC-1539 (now named APC-1539a) in the avc-site/Incoming directory. regards, ------------ Louis Christodoulides tel:+44 171 728 1698 Inmarsat email: louis_christodoulides(a)inmarsat.org 99 City Road London EC1Y 1AX ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **********************************************************************

1 0