- sg16-avd - lists.packetizer.com

Liaison from ITU Question 21/15
by Glen Freundlich 01 Mar '99

01 Mar '99

Attached is a liaison statement from Question 21/15, of which Jerry Skene is the rapporteur, sent in response to a liaison from Q14 regarding the text of Q21/15. Mr. Skene's contact information is: Jerry Skene | Tellabs, Inc. Director, | 45085 University Drive International Standards | Ashburn, VA 20147.2745 tel: +1 703 724-7302 | URL: www.tellabs.com fax: +1 703 724-7202 | email:jerry.skene@tellabs.com -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

1 0

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

Re: Relationship of H.323 and H.245 versions
by Chris Purvis 12 Feb '99

12 Feb '99

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 > ================================= > > > >---------- > >From: Santo Wiryaman[SMTP:swiryaman@VIDEOSERVER.COM] > >Reply To: Mailing list for parties associated with > ITU-T Study Group > 16 > >Sent: 05 February 1999 13:36 > >To: ITU-SG16(a)MAILBAG.INTEL.COM > >Subject: Re: Relationship of H.323 and H.245 versions > > > >Jim, > >I do support this position. Thanks. > >-santo > > > >> -----Original Message----- > >> From: Jim Toga [SMTP:jim.toga@INTEL.COM] > >> Sent: Thursday, February 04, 1999 6:29 PM > >> To: ITU-SG16(a)mailbag.cps.intel.com > >> Subject: Re: Relationship of H.323 and H.245 versions > >> > >> Chris (and others) > >> > >> I'm penning up text (proposed) for the implementers guide. > (Which I will > >> post here for comments by tommorow) At this point I'm > going to go with > >> Paul's suggestion below even in light of your comments. Here's the > >> reasoning: > >> > >> If the GK is routing H.225.0 and _not_ H.245 (which is for further > study, > >> btw) then is should _not_ be messing with any > syntax/encoding that it > >> absolutely does not understand (for exactly this reason). If it is > >> routing > >> both, then it can 'proxy' and give what-ever 'face' revision to the > >> protocol that it wants (as long as it is consistent). > >> > >> I think what we gain by constraining the mix'n-match is > consistency and > >> predictability. The cost is that, as we revise the > 'umbrella' H.323 > >> Recommendation - products may have to support 'sets' of > H.225.0/H.245 to > >> play in multiple worlds. I don't see any great _system_ > advantage to > >> allowing vendors to provide a complete hodge-podge of > stack revisions. > >> (This is orthogonal to allowing vendors to provide a hodge-podge of > stack > >> support - H.235, annex E, annex G etc...) > >> > >> Regards, > >> jimt. > >> > >> > >> At 12:36 PM 2/1/99 -0000, you wrote: > >> >Paul (and others), > >> > > >> >Consider the case of a v1 gatekeeper routing H.225.0 and > NOT H.245 in a > >> call > >> >between two v2 endpoints. The gatekeeper certainly MAY > relegate the > >> H.225.0 > >> >messages to v1. This may be a policy decision, or it may > be due to > stack > >> >capabilities. Note that the gatekeeper may not always > desire to relay > >> >messages entirely transparently, and is entirely within > its rights to > >> make > >> >this sort of alteration (although people writing H.323 stacks for > >> >gatekeepers would probably be well advised to implement > relaying of > >> messages > >> >or message fragments). Certainly the standard should not > mandate that > >> >message relay should be entirely transparent. Anyway, > the upshot of > this > >> is > >> >that all H.225.0 messages in the call will be relegated > to v1 by the > >> >gatekeeper. The H.245 session runs directly end-to-end > and will hence > be > >> >version 3, so both endpoints in the call need to be able > to cope with > an > >> >H.245 session of a different version from that implied by > the H.225.0 > >> >session. > >> > > >> >Similar discrepancies may occur in the opposite direction (later > version > >> of > >> >H.225.0 than H.245) for similar, but marginally more > complex reasons. > >> > > >> >So what do we gain by insisting on an endpoint supporting EXACTLY > version > >> 3 > >> >of H.245 if it happens to be EXACTLY version 2 of H.225.0 and vice > versa? > >> >Although I agree that it is what is currently specified > I'm unconvinced > >> it > >> >buys us anything. > >> > > >> >Regards, > >> >Chris > >> > > >> >> -----Original Message----- > >> >> From: Paul Long [mailto:Plong@SMITHMICRO.COM] > >> >> Sent: 29 January 1999 8:09 > >> >> To: ITU-SG16(a)MAILBAG.INTEL.COM > >> >> Subject: Re: Relationship of H.323 and H.245 versions > >> >> > >> >> > >> >> Gary, > >> >> > >> >> You be the judge: > >> >> > >> >> Summary/H.323v2: "Products claiming compliance with Version 2 > >> >> of H.323 shall > >> >> comply with all of the mandatory requirements of this > >> >> document, H.323 (1998), > >> >> which references H.225.0 (1998) and H.245 (1998). Version 2 > >> >> products can be > >> >> identified by H.225.0 messages containing a > >> >> protocolIdentifier = {itu-t (0) > >> >> recommendation (0) h (8) 2250 version (0) 2} and H.225.0 > >> >> messages containing a > >> >> protocolIdentifier = {itu-t (0) recommendation (0) h (8) 245 > >> >> version (0) 3}." > >> >> > >> >> Assuming this text is normative, H.323v2 uses H.225.0v2 and > >> >> H.245v3. Period. > >> >> > >> >> IMO, we will be asking for big trouble if we at some point > >> >> decide that one can > >> >> mix and match versions and even use subsets or supersets of a > >> >> particular > >> >> version. Whatever interoperability problems we have now will > >> >> be magnified many > >> >> times over if we head down that slippery slope. > >> >> > >> >> Paul Long > >> >> Smith Micro Software, Inc. > >> >> > >> >> -----Original Message----- > >> >> From: Gary A. Thom [SMTP:gthom@DELTA-INFO.COM] > >> >> Sent: Friday, January 29, 1999 1:37 PM > >> >> To: ITU-SG16(a)MAILBAG.INTEL.COM > >> >> Subject: Re: Relationship of H.323 and > H.245 versions > >> >> > >> >> One more question???? > >> >> > >> >> > >> >> > Dave, > >> >> > > >> >> > Sorry, but I won't be in Monterey. > >> >> > > >> >> > I agree with what you say, except that I would go > >> >> further and state > >> >> that there > >> >> > is always a one-to-one mapping between > H.225.0 and H.245 > >> >> protocolIdentifiers > >> >> > via H.323. For example, > >> >> > > >> >> > H.225.0v1 => H.323v1 => H.245v2 and H.245v2 => > >> >> H.323v1 => > >> >> H.225.0v1 > >> >> > H.225.0v2 => H.323v2 => H.245v3 and H.245v3 => > >> >> H.323v2 => > >> >> H.225.0v2 > >> >> > > >> >> > This is already implied by the Summary section of > >> >> H.323 starting > >> >> with version > >> >> > 2. I think it's clear, but you could add > >> >> clarification text if you > >> >> like. IOW, > >> >> > for example, an EP cannot use H.245v2 and H.225.0v2 > >> >> in the same > >> >> call. > >> >> > > >> >> > >> >> But can H.225.0 V2 (H.323 V2) and H.245V4 (or 5) be > >> >> used in the same > >> >> call??? > >> >> > >> >> Gary > >> >> > >> >> ------------------------------------------------------ > >> >> Name : Gary A. Thom > >> >> Company: Delta Information Systems, Inc. > >> >> Address: 300 Welsh Rd., Bldg 3 > >> >> Horsham, PA 19044 USA > >> >> Phone : +1-215-657-5270 Fax : +1-215-657-5273 > >> >> E-mail : gthom(a)delta-info.com > >> >> ------------------------------------------------------ > >> >> > >> > > >> +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

APC-1510 CryptoTokens in Annex G uploaded
by Andrew Draper 11 Feb '99

11 Feb '99

This document has been uploaded to the ftp site. It describes minor modifications relating to the use of CryptoTokens with Annex G. Regards, Andy -- Andrew Draper -- Principal Development Engineer -- WAVE Software Madge Networks, Wexham Springs, Framewood Road, Wexham, Berks UK mailto:adraper@madge.com phone:+44 1753 661329 pgp fingerprint D6 ED 72 4F 96 BB CA 2D 68 74 4C E0 CB B9 0B 3F

1 0

APC-1548 uploaded to ftp site
by Mark Duckworth 11 Feb '99

11 Feb '99

Apc-1548.zip is uploaded to the avc-site Incoming area. This contribution proposes minor changes to H.341 Mark

1 0

Internet services in Monterey
by Joerg Ott 11 Feb '99

11 Feb '99

Folks, [this is relevant only to the attendees of the Monterey meeting next week] we (Stephan Wenger and myself with much help Georgia Lund from the IMTC) are working on organizing Internet connectivity for the meeting rooms in Monterey and we probably need your support for this. The IMTC got the hotel chasing for an ISDN line and we are bringing an ISDN router, one or two 16-port hubs, and some twisted pair cables. What we now need are some volunteers (actually, there cannot be enough :-) to bring additional hubs so that we can provide a port for everyone -- without having to buy too much stuff. Getting additional power outlet strips would be nice, too. Please contact me via private e-mail (jo(a)teles.de or jo(a)tzi.uni-bremen.de) if you want to commit to bring some equipment. Even if you don't commit, please bring it anyway. Of course, we expect everybody to care for their own cabling. BTW: There remains the minor issue of the cost for 120 hours of Internet connectivity but I assume we will be able to sort that out... Thanks a lot for your support, Joerg

1 0

Re: APC-1515: Tunneling As Supplementary Service (Siemens)
by Chris Purvis 11 Feb '99

11 Feb '99

Bob, Why? Chris > -----Original Message----- > From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] > Sent: 10 February 1999 8:52 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: APC-1515: Tunneling As Supplementary Service (Siemens) > > > Tom, > > This excludes the use or existence of Gatekeeper that are capable of > interworking ISUP to H.323. > > Or, the interworking function is limited to a Gateway. > > Bob > > ------------------------------------------------------------------ > Robert Callaghan > Siemens Information & Communication Networks > Tel: +1.561.997.3756 Fax: +1.561.997.3403 > Email: Robert.Callaghan(a)ICN.Siemens.com > ------------------------------------------------------------------ > > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] > Sent: Wednesday, February 10, 1999 2:51 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: APC-1515: Tunneling As Supplementary Service (Siemens) > > > I have a quick question on the intent of clause 5) of section 9. of > APC-1515. It reads as follows: > > 5) It is the responsibility of the ingress gateway to > insure that the > tunnel is only sent when the egress gateway has compatible > capabilities. > (This specifically excludes the use of interworking capable > gatekeepers.) > > Does that parenthesized statement mean that you intend that > there be no > interworking capable gatekeepers, or does it mean that there > can be no such > involved in the specified supplementary service? > > 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

APC-1549 uploaded
by Patrick Luthi 10 Feb '99

10 Feb '99

Dear Q12-14 experts, I uploaded contribution APC-1549 (Correction of problems related to MCV in H.230 and H.243) to the Incoming directory. Regards, Patrick Luthi PictureTel

1 0

APC-1544 uploaded
by Glen Freundlich 10 Feb '99

10 Feb '99

Dear Mr. Okubo, I have uploaded APC-1544, draft H.225 V3, to the Incoming directory of the avc ftp site. Regards, Glen Freundlich -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

1 0

Re: APC-1515: Tunneling As Supplementary Service (Siemens)
by Callaghan, Robert 10 Feb '99

10 Feb '99

Tom, This excludes the use or existence of Gatekeeper that are capable of interworking ISUP to H.323. Or, the interworking function is limited to a Gateway. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Information & Communication Networks Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] Sent: Wednesday, February 10, 1999 2:51 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: APC-1515: Tunneling As Supplementary Service (Siemens) I have a quick question on the intent of clause 5) of section 9. of APC-1515. It reads as follows: 5) It is the responsibility of the ingress gateway to insure that the tunnel is only sent when the egress gateway has compatible capabilities. (This specifically excludes the use of interworking capable gatekeepers.) Does that parenthesized statement mean that you intend that there be no interworking capable gatekeepers, or does it mean that there can be no such involved in the specified supplementary service? 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

APC-1515: Tunneling As Supplementary Service (Siemens)
by Tom-PT Taylor 10 Feb '99

10 Feb '99

I have a quick question on the intent of clause 5) of section 9. of APC-1515. It reads as follows: 5) It is the responsibility of the ingress gateway to insure that the tunnel is only sent when the egress gateway has compatible capabilities. (This specifically excludes the use of interworking capable gatekeepers.) Does that parenthesized statement mean that you intend that there be no interworking capable gatekeepers, or does it mean that there can be no such involved in the specified supplementary service? 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

AW: Comments to draft H.450.8
by Klaghofer Karl ICN IB NL IP 7 10 Feb '99

10 Feb '99

Hong-Linh, H.450.8 is not a new conference. The draft clearly points out that existing H.245 conference mechanisms are used, once the central conference is in place (see e.g. clause 1 of the draft). H.450 only provides an improved procedure for replacing the existing calls of a consultation scenario (i.e. a held call and a consulted call) by new calls so that we end up with point to points calls between an MCU and the involved endpoints (see FIGURE 2/H.450.8). The deficiencies of using the FACILITY re-route to MC method (compared to H.450.8 proposal) for doing such a call replacement we have pointed out already in clause 8.3.3 of APC-1505. Some could life with such deficiencies (as you indicated) other may not. We have even included interaction (fallback) procedures for the case where the MCU does not yet support H.450.8. The current "conference invite" method you are referring to for usage in conference out of consultation requires multiple SETUP messages at SS-CoC invocation to be sent from the served endpoint to the MCU for each remote endpoint the served user wants to invite. With the H.450.8 proposal only one call is established to the MCU/CUSE. The operation included in the SETUP contains all information the MCU needs to complete the feature. So, H.450.8 is an improvement also in this respect. You could start modifying H.225.0 to get similar improvements. This requires a new H.225 version in the involved endpoints. To use H.450 for new functionality or for an improved functionality has the advantage that the endpoints can provide this functionality independent of the version of their base protocols ! Regards, Karl ------------------------------------------------ Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL IP7 Hofmannstr. 51, D-81359 Munich, Germany Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 e-mail: karl.klaghofer(a)vs.siemens.de > -----Ursprüngliche Nachricht----- > Von: Truong Hong-Linh [SMTP:ctNotes@ZURICH.IBM.COM] > Gesendet am: Mittwoch, 10. Februar 1999 14:02 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: Comments to draft H.450.8 > > Dear Karl, > > Thanks for putting together draft H.450.8. In the editors note of section > 8.3.3 you re-produced only your own viewpoints. I'm missing at least the > points I've made during the private discussion I've had with you and many > others. I therefore take the liberty to repeat them here again. > > The main concern I've against H.450.8 is that we will have two different > ways of doing conferencing, one defined in H.323 section 8.4.3 and one in > H.450.8. The two differ only marginally; almost of the conference service > defined by H.450.8 can be performed by using the protocols and procedures > defined in the current H.323 version 2 (which I will show later on in > going > point by point through your list of defiencies). I fear that having two > conferencing methods will lead to interoperability problems and confusion > of > the users. > > I acknowledge that you have tried to resolve the interoperability problems > between the two methods in introducing a fall-back feature which allows an > H.450.8 CSSE to talk to an MCU and in using as much as possible existing > H.245 procedures, but I'm not sure whether we oversee some. > > The problem of users confusion still remains. How should we explain to > them > that we need in H.323 two conferencing methods? The items you listed in > your > editors note in section 8.3.3 are in my opinion of minor importance, since > they improve only marginally the performance of the service. However, if > you > insist on having them, then I think that it is better to add them to the > current H.323 method instead of inventing a new method which differs very > little from the old one. > > Let me now go through the points you made in your editors note. > > >a) The SETUP message from the endpoint A to the MCU does not tell > >the MCU how many remote users B, C, ... are going to be re-routed to > >the MCU. I.e. MCU resources may not be reserved appropriately. > > I do not see the need for that. The PBX I use here in Zurich (BTW it's a > HiCom :-) ) does not require me to input that information any time I start > a > conference. And I'd feel annoying if I have to. Furthermore, how can I > know > a-priori how many participants I'll have in my ad-hoc conference? > > >b) The SETUP message from the endpoint A to the MCU does not tell > >the MCU the addresses of the parties to be re-routed. The MCU may have > >to accept any re-routed call (security issue ?). > > If security is really a concern, then I'd use other means e.g. H.235 to > protect my conference instead of sending an unprotected list to the CUSE. > BTW if you don't like or have problems with the FACILITY "re-routeToMC", > then you can still let the endpoint which wants to create the conference > INVITES the participants (using H.323 clauses 8.4.3.2 and 8.4.3.5). You > will > then end up with exactely what you want to achieve in H.450.8! > > >c) The served user A does not get feedback from the MCU in CONNECT > >message whether the intended feature can be supported by the MCU (no > >acknowledgement in CONNECT). > > Which intended feature you are talking about here? > > >d) Although FACILITY message itself is mandatory in H.225.0, not > >every endpoint may support the "Facility re-route to MC" method and > >thus, not every endpoint may participate in SS-CoC as remote endpoint. > >A remote endpoint may intentionally block Facility re-route messages > >in general for e.g. security reasons. > > >e) With H.450.8, the remote endpoints receive incoming H.323 calls > >from the MCU (i.e. the MCU establishes the calls). With H.450.8 the > >remote endpoints do not necessarily have to support H.450.8 and can > >still participate in SS-CoC (i.e. the confEstablish Invoke APDU may be > >ignored). > > Again, if you don't like the FACILITY message, you can use the already > defined H.323 INVITATION method to add the participants to the conference. > In this case -as you wish- the remote endpoints do not have to support > FACILITY "re-routeToMC". And in addition to that you even do not have to > implement H.450.8 to create a conference. You just need to implement H.323 > version 2! > > >f) If the "Facility re-route to MC" is supported by the remote > >endpoint, H.323 clause 8.4.3.7 allows different options, e.g. to > >immediately clear the call to the served endpoint A. > >g) If the remote endpoint immediately clears the call, the served > >endpoint A would not receive any feedback whether the remote endpoint > can support the request. > >h) If the remote endpoint immediately clears the call, the served > >endpoint A would not receive any information about a possible > >unsuccessful call establishment from the remote endpoint to the MCU, > >and thus the call may be lost. > >i) If the remote endpoint B would NOT immediately clear the call and > >the call establishment from the remote endpoint to the MCU fails, > >there is not signal in H.225.0 to inform the served endpoint A. > > I don't see the need for an explicit confirmation in all of the cases > above. > From an user's point of view, he/she will get from the MC the information > of > who are on the conference and therefore can derive out of that information > which calls have failed. And if the H.323 invitation method is used, the > information on whether the invitation succeeds or not is more than > explicit. > > >j) It is the remote endpoint - and not the remote endpoint user - > >that establishes the call to the MCU. This may result in the remote > >endpoint being charged for the call (which may not be acceptable to > >the remote endpoint user). > > The invitation method could be used to avoid that. > But, as discussed within our private conversation, the charging issue is > an > important one and also affects the transfer feature defined in H.450.2. I > don't agree that we can resolve the charging issue in just letting the MCU > establishing the calls. There are situations in which I don't want to pay > for the others just because I'm the one who calls the conference. I > believe > we need to think and discuss more carefully about that issue and all of > its > impact, and not only for the conference service but also for the other > ones. > > >k) The MCU does not provide detailed conference notification > >information to the endpoints. In H.450.8, conference notification > >(conferenceIndication Invoke APDU) is provided to all conference > >participants (containing e.g. alias addresses, names, endpoint types, > status, etc.). > > The alias addresses can be requested from the MC using H.245 Terminal ID > Request. For the other information, I don't understand why do you need > them. > What are you going to do with them? And if needed, why can't we add them > to > the H.245 MC Terminal ID response? > > >l) A terminal has to ask for receiving a list of conference > >participants (H.245 terminalListRequest). In ISDN and PBX networking, > >it is the entity containing the conference bridge (i.e. the CUSE) that > >provides information about the conference participants. Due to this > >different function split interworking with SCN may be more difficult. > > But it eases the interworking with other H.32x conferencing systems. It is > my understanding the H.245 is designed for that aim. > > >m) Missing signalling elements as identified in different items > >above could be added to H.225.0 or H.245. However, this would create > >new versions of these standards. The endpoints participating in SS- > >CoC would have to be of a certain H.323/H.225.0/H.245 version > >(backwards compatibility problem). Still, there would be the problem > >of not all endpoints supporting the "Facility re-route to MC" method. > > See my comments above on the missing items. Also, why is adding something > to > H.323/H.225/H.245 causing backward compability problem? The items you want > to add can be ignored by an endpoint that do not understand them, but we > still can convene a conference. > > >n) With H.450.8, the base standards H.323, H.225.0 and H.245 are not > affected. > > With H.323 version 2 we can already do conferencing, even the way you want > to have. We do not need H.450.8. > > Regards, > Linh > -------------------------------------------------------------------------- > -- > ------------------------------------------------------------------- > TRUONG Hong Linh hlt(a)zurich.ibm.com > IBM Zurich Research Laboratory tel : +41 1 724 8434 > CH-8803 Rueschlikon / Switzerland fax : +41 1 724 8955

1 0

Re: Relationship of H.323 and H.245 versions
by Ami Amir 10 Feb '99

10 Feb '99

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 ================================= >---------- >From: Santo Wiryaman[SMTP:swiryaman@VIDEOSERVER.COM] >Reply To: Mailing list for parties associated with ITU-T Study Group 16 >Sent: 05 February 1999 13:36 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: Relationship of H.323 and H.245 versions > >Jim, >I do support this position. Thanks. >-santo > >> -----Original Message----- >> From: Jim Toga [SMTP:jim.toga@INTEL.COM] >> Sent: Thursday, February 04, 1999 6:29 PM >> To: ITU-SG16(a)mailbag.cps.intel.com >> Subject: Re: Relationship of H.323 and H.245 versions >> >> Chris (and others) >> >> I'm penning up text (proposed) for the implementers guide. (Which I will >> post here for comments by tommorow) At this point I'm going to go with >> Paul's suggestion below even in light of your comments. Here's the >> reasoning: >> >> If the GK is routing H.225.0 and _not_ H.245 (which is for further study, >> btw) then is should _not_ be messing with any syntax/encoding that it >> absolutely does not understand (for exactly this reason). If it is >> routing >> both, then it can 'proxy' and give what-ever 'face' revision to the >> protocol that it wants (as long as it is consistent). >> >> I think what we gain by constraining the mix'n-match is consistency and >> predictability. The cost is that, as we revise the 'umbrella' H.323 >> Recommendation - products may have to support 'sets' of H.225.0/H.245 to >> play in multiple worlds. I don't see any great _system_ advantage to >> allowing vendors to provide a complete hodge-podge of stack revisions. >> (This is orthogonal to allowing vendors to provide a hodge-podge of stack >> support - H.235, annex E, annex G etc...) >> >> Regards, >> jimt. >> >> >> At 12:36 PM 2/1/99 -0000, you wrote: >> >Paul (and others), >> > >> >Consider the case of a v1 gatekeeper routing H.225.0 and NOT H.245 in a >> call >> >between two v2 endpoints. The gatekeeper certainly MAY relegate the >> H.225.0 >> >messages to v1. This may be a policy decision, or it may be due to stack >> >capabilities. Note that the gatekeeper may not always desire to relay >> >messages entirely transparently, and is entirely within its rights to >> make >> >this sort of alteration (although people writing H.323 stacks for >> >gatekeepers would probably be well advised to implement relaying of >> messages >> >or message fragments). Certainly the standard should not mandate that >> >message relay should be entirely transparent. Anyway, the upshot of this >> is >> >that all H.225.0 messages in the call will be relegated to v1 by the >> >gatekeeper. The H.245 session runs directly end-to-end and will hence be >> >version 3, so both endpoints in the call need to be able to cope with an >> >H.245 session of a different version from that implied by the H.225.0 >> >session. >> > >> >Similar discrepancies may occur in the opposite direction (later version >> of >> >H.225.0 than H.245) for similar, but marginally more complex reasons. >> > >> >So what do we gain by insisting on an endpoint supporting EXACTLY version >> 3 >> >of H.245 if it happens to be EXACTLY version 2 of H.225.0 and vice versa? >> >Although I agree that it is what is currently specified I'm unconvinced >> it >> >buys us anything. >> > >> >Regards, >> >Chris >> > >> >> -----Original Message----- >> >> From: Paul Long [mailto:Plong@SMITHMICRO.COM] >> >> Sent: 29 January 1999 8:09 >> >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> >> Subject: Re: Relationship of H.323 and H.245 versions >> >> >> >> >> >> Gary, >> >> >> >> You be the judge: >> >> >> >> Summary/H.323v2: "Products claiming compliance with Version 2 >> >> of H.323 shall >> >> comply with all of the mandatory requirements of this >> >> document, H.323 (1998), >> >> which references H.225.0 (1998) and H.245 (1998). Version 2 >> >> products can be >> >> identified by H.225.0 messages containing a >> >> protocolIdentifier = {itu-t (0) >> >> recommendation (0) h (8) 2250 version (0) 2} and H.225.0 >> >> messages containing a >> >> protocolIdentifier = {itu-t (0) recommendation (0) h (8) 245 >> >> version (0) 3}." >> >> >> >> Assuming this text is normative, H.323v2 uses H.225.0v2 and >> >> H.245v3. Period. >> >> >> >> IMO, we will be asking for big trouble if we at some point >> >> decide that one can >> >> mix and match versions and even use subsets or supersets of a >> >> particular >> >> version. Whatever interoperability problems we have now will >> >> be magnified many >> >> times over if we head down that slippery slope. >> >> >> >> Paul Long >> >> Smith Micro Software, Inc. >> >> >> >> -----Original Message----- >> >> From: Gary A. Thom [SMTP:gthom@DELTA-INFO.COM] >> >> Sent: Friday, January 29, 1999 1:37 PM >> >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> >> Subject: Re: Relationship of H.323 and H.245 versions >> >> >> >> One more question???? >> >> >> >> >> >> > Dave, >> >> > >> >> > Sorry, but I won't be in Monterey. >> >> > >> >> > I agree with what you say, except that I would go >> >> further and state >> >> that there >> >> > is always a one-to-one mapping between H.225.0 and H.245 >> >> protocolIdentifiers >> >> > via H.323. For example, >> >> > >> >> > H.225.0v1 => H.323v1 => H.245v2 and H.245v2 => >> >> H.323v1 => >> >> H.225.0v1 >> >> > H.225.0v2 => H.323v2 => H.245v3 and H.245v3 => >> >> H.323v2 => >> >> H.225.0v2 >> >> > >> >> > This is already implied by the Summary section of >> >> H.323 starting >> >> with version >> >> > 2. I think it's clear, but you could add >> >> clarification text if you >> >> like. IOW, >> >> > for example, an EP cannot use H.245v2 and H.225.0v2 >> >> in the same >> >> call. >> >> > >> >> >> >> But can H.225.0 V2 (H.323 V2) and H.245V4 (or 5) be >> >> used in the same >> >> call??? >> >> >> >> Gary >> >> >> >> ------------------------------------------------------ >> >> Name : Gary A. Thom >> >> Company: Delta Information Systems, Inc. >> >> Address: 300 Welsh Rd., Bldg 3 >> >> Horsham, PA 19044 USA >> >> Phone : +1-215-657-5270 Fax : +1-215-657-5273 >> >> E-mail : gthom(a)delta-info.com >> >> ------------------------------------------------------ >> >> >> > >> +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

APC-1524 Uploaded
by Pete Cordell 10 Feb '99

10 Feb '99

Dear Mr. Okubo, I have uploaded APC-1524 to the PictureTel site. Please be advised that APC-1524a.zip is the correct version. A fault occurred when attempting the upload initially. Regards, Pete Cordell ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================

1 0

Re: Comments to draft H.450.8
by Roni Even 10 Feb '99

10 Feb '99

Dear all, I read H.450.8 and I have to agree with Linh. It is not clear why we need another method to create a conference. If there are problems in the current method we can fix it. The benefit of the H.323 method is that you do not need to support h4501SupplementaryService APDUs to create an ad hoc conference and it achieves the same purpose. Thanks Roni Even ********************************************** 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: Truong Hong-Linh [SMTP:ctNotes@ZURICH.IBM.COM] > Sent: Wednesday, February 10, 1999 3:02 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Comments to draft H.450.8 > > Dear Karl, > > Thanks for putting together draft H.450.8. In the editors note of > section > 8.3.3 you re-produced only your own viewpoints. I'm missing at least > the > points I've made during the private discussion I've had with you and > many > others. I therefore take the liberty to repeat them here again. > > The main concern I've against H.450.8 is that we will have two > different > ways of doing conferencing, one defined in H.323 section 8.4.3 and one > in > H.450.8. The two differ only marginally; almost of the conference > service > defined by H.450.8 can be performed by using the protocols and > procedures > defined in the current H.323 version 2 (which I will show later on in > going > point by point through your list of defiencies). I fear that having > two > conferencing methods will lead to interoperability problems and > confusion of > the users. > > I acknowledge that you have tried to resolve the interoperability > problems > between the two methods in introducing a fall-back feature which > allows an > H.450.8 CSSE to talk to an MCU and in using as much as possible > existing > H.245 procedures, but I'm not sure whether we oversee some. > > The problem of users confusion still remains. How should we explain to > them > that we need in H.323 two conferencing methods? The items you listed > in your > editors note in section 8.3.3 are in my opinion of minor importance, > since > they improve only marginally the performance of the service. However, > if you > insist on having them, then I think that it is better to add them to > the > current H.323 method instead of inventing a new method which differs > very > little from the old one. > > Let me now go through the points you made in your editors note. > > >a) The SETUP message from the endpoint A to the MCU does not tell > >the MCU how many remote users B, C, ... are going to be re-routed to > >the MCU. I.e. MCU resources may not be reserved appropriately. > > I do not see the need for that. The PBX I use here in Zurich (BTW it's > a > HiCom :-) ) does not require me to input that information any time I > start a > conference. And I'd feel annoying if I have to. Furthermore, how can I > know > a-priori how many participants I'll have in my ad-hoc conference? > > >b) The SETUP message from the endpoint A to the MCU does not tell > >the MCU the addresses of the parties to be re-routed. The MCU may > have > >to accept any re-routed call (security issue ?). > > If security is really a concern, then I'd use other means e.g. H.235 > to > protect my conference instead of sending an unprotected list to the > CUSE. > BTW if you don't like or have problems with the FACILITY > "re-routeToMC", > then you can still let the endpoint which wants to create the > conference > INVITES the participants (using H.323 clauses 8.4.3.2 and 8.4.3.5). > You will > then end up with exactely what you want to achieve in H.450.8! > > >c) The served user A does not get feedback from the MCU in CONNECT > >message whether the intended feature can be supported by the MCU (no > >acknowledgement in CONNECT). > > Which intended feature you are talking about here? > > >d) Although FACILITY message itself is mandatory in H.225.0, not > >every endpoint may support the "Facility re-route to MC" method and > >thus, not every endpoint may participate in SS-CoC as remote > endpoint. > >A remote endpoint may intentionally block Facility re-route messages > >in general for e.g. security reasons. > > >e) With H.450.8, the remote endpoints receive incoming H.323 calls > >from the MCU (i.e. the MCU establishes the calls). With H.450.8 the > >remote endpoints do not necessarily have to support H.450.8 and can > >still participate in SS-CoC (i.e. the confEstablish Invoke APDU may > be > >ignored). > > Again, if you don't like the FACILITY message, you can use the already > defined H.323 INVITATION method to add the participants to the > conference. > In this case -as you wish- the remote endpoints do not have to support > FACILITY "re-routeToMC". And in addition to that you even do not have > to > implement H.450.8 to create a conference. You just need to implement > H.323 > version 2! > > >f) If the "Facility re-route to MC" is supported by the remote > >endpoint, H.323 clause 8.4.3.7 allows different options, e.g. to > >immediately clear the call to the served endpoint A. > >g) If the remote endpoint immediately clears the call, the served > >endpoint A would not receive any feedback whether the remote endpoint > can support the request. > >h) If the remote endpoint immediately clears the call, the served > >endpoint A would not receive any information about a possible > >unsuccessful call establishment from the remote endpoint to the MCU, > >and thus the call may be lost. > >i) If the remote endpoint B would NOT immediately clear the call and > >the call establishment from the remote endpoint to the MCU fails, > >there is not signal in H.225.0 to inform the served endpoint A. > > I don't see the need for an explicit confirmation in all of the cases > above. > From an user's point of view, he/she will get from the MC the > information of > who are on the conference and therefore can derive out of that > information > which calls have failed. And if the H.323 invitation method is used, > the > information on whether the invitation succeeds or not is more than > explicit. > > >j) It is the remote endpoint - and not the remote endpoint user - > >that establishes the call to the MCU. This may result in the remote > >endpoint being charged for the call (which may not be acceptable to > >the remote endpoint user). > > The invitation method could be used to avoid that. > But, as discussed within our private conversation, the charging issue > is an > important one and also affects the transfer feature defined in > H.450.2. I > don't agree that we can resolve the charging issue in just letting the > MCU > establishing the calls. There are situations in which I don't want to > pay > for the others just because I'm the one who calls the conference. I > believe > we need to think and discuss more carefully about that issue and all > of its > impact, and not only for the conference service but also for the other > ones. > > >k) The MCU does not provide detailed conference notification > >information to the endpoints. In H.450.8, conference notification > >(conferenceIndication Invoke APDU) is provided to all conference > >participants (containing e.g. alias addresses, names, endpoint types, > status, etc.). > > The alias addresses can be requested from the MC using H.245 Terminal > ID > Request. For the other information, I don't understand why do you need > them. > What are you going to do with them? And if needed, why can't we add > them to > the H.245 MC Terminal ID response? > > >l) A terminal has to ask for receiving a list of conference > >participants (H.245 terminalListRequest). In ISDN and PBX > networking, > >it is the entity containing the conference bridge (i.e. the CUSE) > that > >provides information about the conference participants. Due to this > >different function split interworking with SCN may be more difficult. > > But it eases the interworking with other H.32x conferencing systems. > It is > my understanding the H.245 is designed for that aim. > > >m) Missing signalling elements as identified in different items > >above could be added to H.225.0 or H.245. However, this would create > >new versions of these standards. The endpoints participating in SS- > >CoC would have to be of a certain H.323/H.225.0/H.245 version > >(backwards compatibility problem). Still, there would be the problem > >of not all endpoints supporting the "Facility re-route to MC" method. > > See my comments above on the missing items. Also, why is adding > something to > H.323/H.225/H.245 causing backward compability problem? The items you > want > to add can be ignored by an endpoint that do not understand them, but > we > still can convene a conference. > > >n) With H.450.8, the base standards H.323, H.225.0 and H.245 are not > affected. > > With H.323 version 2 we can already do conferencing, even the way you > want > to have. We do not need H.450.8. > > Regards, > Linh > ---------------------------------------------------------------------- > ------ > ------------------------------------------------------------------- > TRUONG Hong Linh hlt(a)zurich.ibm.com > IBM Zurich Research Laboratory tel : +41 1 724 8434 > CH-8803 Rueschlikon / Switzerland fax : +41 1 724 8955

1 0

Comments to draft H.450.8
by Truong Hong-Linh 10 Feb '99

10 Feb '99

Dear Karl, Thanks for putting together draft H.450.8. In the editors note of section 8.3.3 you re-produced only your own viewpoints. I'm missing at least the points I've made during the private discussion I've had with you and many others. I therefore take the liberty to repeat them here again. The main concern I've against H.450.8 is that we will have two different ways of doing conferencing, one defined in H.323 section 8.4.3 and one in H.450.8. The two differ only marginally; almost of the conference service defined by H.450.8 can be performed by using the protocols and procedures defined in the current H.323 version 2 (which I will show later on in going point by point through your list of defiencies). I fear that having two conferencing methods will lead to interoperability problems and confusion of the users. I acknowledge that you have tried to resolve the interoperability problems between the two methods in introducing a fall-back feature which allows an H.450.8 CSSE to talk to an MCU and in using as much as possible existing H.245 procedures, but I'm not sure whether we oversee some. The problem of users confusion still remains. How should we explain to them that we need in H.323 two conferencing methods? The items you listed in your editors note in section 8.3.3 are in my opinion of minor importance, since they improve only marginally the performance of the service. However, if you insist on having them, then I think that it is better to add them to the current H.323 method instead of inventing a new method which differs very little from the old one. Let me now go through the points you made in your editors note. >a) The SETUP message from the endpoint A to the MCU does not tell >the MCU how many remote users B, C, ... are going to be re-routed to >the MCU. I.e. MCU resources may not be reserved appropriately. I do not see the need for that. The PBX I use here in Zurich (BTW it's a HiCom :-) ) does not require me to input that information any time I start a conference. And I'd feel annoying if I have to. Furthermore, how can I know a-priori how many participants I'll have in my ad-hoc conference? >b) The SETUP message from the endpoint A to the MCU does not tell >the MCU the addresses of the parties to be re-routed. The MCU may have >to accept any re-routed call (security issue ?). If security is really a concern, then I'd use other means e.g. H.235 to protect my conference instead of sending an unprotected list to the CUSE. BTW if you don't like or have problems with the FACILITY "re-routeToMC", then you can still let the endpoint which wants to create the conference INVITES the participants (using H.323 clauses 8.4.3.2 and 8.4.3.5). You will then end up with exactely what you want to achieve in H.450.8! >c) The served user A does not get feedback from the MCU in CONNECT >message whether the intended feature can be supported by the MCU (no >acknowledgement in CONNECT). Which intended feature you are talking about here? >d) Although FACILITY message itself is mandatory in H.225.0, not >every endpoint may support the "Facility re-route to MC" method and >thus, not every endpoint may participate in SS-CoC as remote endpoint. >A remote endpoint may intentionally block Facility re-route messages >in general for e.g. security reasons. >e) With H.450.8, the remote endpoints receive incoming H.323 calls >from the MCU (i.e. the MCU establishes the calls). With H.450.8 the >remote endpoints do not necessarily have to support H.450.8 and can >still participate in SS-CoC (i.e. the confEstablish Invoke APDU may be >ignored). Again, if you don't like the FACILITY message, you can use the already defined H.323 INVITATION method to add the participants to the conference. In this case -as you wish- the remote endpoints do not have to support FACILITY "re-routeToMC". And in addition to that you even do not have to implement H.450.8 to create a conference. You just need to implement H.323 version 2! >f) If the "Facility re-route to MC" is supported by the remote >endpoint, H.323 clause 8.4.3.7 allows different options, e.g. to >immediately clear the call to the served endpoint A. >g) If the remote endpoint immediately clears the call, the served >endpoint A would not receive any feedback whether the remote endpoint can support the request. >h) If the remote endpoint immediately clears the call, the served >endpoint A would not receive any information about a possible >unsuccessful call establishment from the remote endpoint to the MCU, >and thus the call may be lost. >i) If the remote endpoint B would NOT immediately clear the call and >the call establishment from the remote endpoint to the MCU fails, >there is not signal in H.225.0 to inform the served endpoint A. I don't see the need for an explicit confirmation in all of the cases above. >From an user's point of view, he/she will get from the MC the information of who are on the conference and therefore can derive out of that information which calls have failed. And if the H.323 invitation method is used, the information on whether the invitation succeeds or not is more than explicit. >j) It is the remote endpoint and not the remote endpoint user - >that establishes the call to the MCU. This may result in the remote >endpoint being charged for the call (which may not be acceptable to >the remote endpoint user). The invitation method could be used to avoid that. But, as discussed within our private conversation, the charging issue is an important one and also affects the transfer feature defined in H.450.2. I don't agree that we can resolve the charging issue in just letting the MCU establishing the calls. There are situations in which I don't want to pay for the others just because I'm the one who calls the conference. I believe we need to think and discuss more carefully about that issue and all of its impact, and not only for the conference service but also for the other ones. >k) The MCU does not provide detailed conference notification >information to the endpoints. In H.450.8, conference notification >(conferenceIndication Invoke APDU) is provided to all conference >participants (containing e.g. alias addresses, names, endpoint types, status, etc.). The alias addresses can be requested from the MC using H.245 Terminal ID Request. For the other information, I don't understand why do you need them. What are you going to do with them? And if needed, why can't we add them to the H.245 MC Terminal ID response? >l) A terminal has to ask for receiving a list of conference >participants (H.245 terminalListRequest). In ISDN and PBX networking, >it is the entity containing the conference bridge (i.e. the CUSE) that >provides information about the conference participants. Due to this >different function split interworking with SCN may be more difficult. But it eases the interworking with other H.32x conferencing systems. It is my understanding the H.245 is designed for that aim. >m) Missing signalling elements as identified in different items >above could be added to H.225.0 or H.245. However, this would create >new versions of these standards. The endpoints participating in SS- >CoC would have to be of a certain H.323/H.225.0/H.245 version >(backwards compatibility problem). Still, there would be the problem >of not all endpoints supporting the "Facility re-route to MC" method. See my comments above on the missing items. Also, why is adding something to H.323/H.225/H.245 causing backward compability problem? The items you want to add can be ignored by an endpoint that do not understand them, but we still can convene a conference. >n) With H.450.8, the base standards H.323, H.225.0 and H.245 are not affected. With H.323 version 2 we can already do conferencing, even the way you want to have. We do not need H.450.8. Regards, Linh ---------------------------------------------------------------------------- ------------------------------------------------------------------- TRUONG Hong Linh hlt(a)zurich.ibm.com IBM Zurich Research Laboratory tel : +41 1 724 8434 CH-8803 Rueschlikon / Switzerland fax : +41 1 724 8955

1 0