- sg16-avd - lists.packetizer.com

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 … [View More]

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 … [View More]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 > ================================= > >> [View Less]

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 … [View More]

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, … [View More]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 > > > [View Less]

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 :-) … [View More]

1 0