- sg16-avd - lists.packetizer.com

Re: [H.323 Mobility:] Usage of H.225 Annex G in H.323 Annex H & a question about BEs
by Francois-Xavier Derome 31 Jul '00

31 Jul '00

hi all, Like the other I fully support the usage of annex G for mobility, but as I said before, It must be done without changing the current implementation. The interface between BE should not change. Here is the draft of the contribution I wanted to present in portland. This is in line with what was said. (See attached file: apcxxx.zip)

1 0

Re: [H.323 Mobility:] Update to Service Definitions for Annex H - > a question
by Roelands Marc 31 Jul '00

31 Jul '00

Hi Jaakko, Hi all, Here is an attempt to answer your question(s). As you say, the text is about requirements and so does not specify how 5.1.2 bullet 1 can be implemented. However, the text says "verification of the authenticity of the Terminal" and this is literally what is intended. So no association identifier of some sort, as you mention as a second interpretation, is directly meant. (However this might turn out to be an element for realization of this bullet.) Important however, is the fact that the authentication of a terminal is not useful for the Domain (taken out the indicated special purposes) _unless_ it can be associated with particular Users. Thus, an authenticated Terminal can do certain (restricted) things on behalf of Users that have registered with it. What is further assumed by the text is that some element in the Domain (likely a GK) knows which Users are registered at that (authenticated) Terminal. As mentioned in footnote 7, a way to transfer this association knowledge (possibly indexed by some identifier) between these Domain elements is needed in order to enable the Terminal to act on behalf of the User also when roaming. Hope this clarifies. (Thinking again about the temporary identifier issue you bring up, things can become more complex when one considers that for privacy reasons one may not want to have a straightforward way of finding out which Users are "linked" by means of their registration at the same Terminal, but I'm sure that we don't want to cope with such issues already in this first phase Annex H.) Regards, Marc Roelands Siemens ICN Dept. NC SD Atealaan 34 B-2200 Herentals Belgium Tel.: +32 14253965 Fax: +32 14222994 E-mail: marc.roelands(a)siemens.atea.be -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] Sent: Monday, July 24, 2000 10:14 To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] Update to Service Definitions for Annex H - > a question Hi Marc et al, I just finished reading MD-102a and I have a couple of questions. First of all, though, I want to thank you guys for the excelent contribution, I really liked it. Actually I have just one thing that I don't quite understand. In section 5.1.2 you talk about the Authentication of a H.323 Mobile Terminal and say that it enables the verification of the authenticity of the terminal is context of the association it has with the Mobile User. You also explain this a bit further by adding that this is used to verify that the terminal can act on behalf of the authenticated User using it but you still state that the identity of the terminal is only relevant for the purposes of denying the usage of stolen terminals, etc. (black lists). So my question is that are you talking here about authenticating the terminal or are you referring to authenticating some sort of identifier that is used for the association between the terminal and the user? Your statement in item 3. about not needing to authenticate the user in subsequent terminal re-registrations would also seem to indicate the latter. Thus are you thinking of implementing a way to avoid the User authentication at least in Intra-zone location changes by introducing some sort of temporary local identifier for the terminal/user pair? I know that these are just requirements, but these statements seem to lead to that direction, if I have understood them correctly. The idea seems to be worth while to consider and we should discuss this further, but I don't quite see, how the terminal/user pair could really be authenticated, i.e. you can authenticate the User (by contacting the AuF) and you can authenticate the terminal (if proper cryptographic methods are specified also for the terminal), but how can you authenticate their association? Or am I just reading too much into this? Otherwise the contribution seems fine and I would suggest the addition of its contents to the draft Annex H. Let's have a bit of discussion before that, however. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC s
by Roy, Radhika R, ALCOO 30 Jul '00

30 Jul '00

Dear Mr. OKUBO: I would appreciate if you would resubmit the following AT&T contributions of the Osaka meeting in Portland because we could not discuss those last time due to lack of time: APC-1765: Scope of H.323 QOS APC-1766: Requirements of H.323 QOS APC-1767: Architecture of H.323 QOS APC-1768: Specification of H.323 QOS Characteristics Best Regards, Radhika R. Roy AT&T +1 732 420 1480 rrroy(a)att.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: Request for APC number
by Sakae OKUBO 30 Jul '00

30 Jul '00

Dear Mr. Luthi, In response to your request, APC number has been allocated to your contribution as follows: APC-1893 >Source: PictureTel >Title: Proposed H.242/H.245 text for dynamicPictureResizingByFour >Purpose: Proposal >Question: 14 > >Already has Q11 number Q11-M-03 ! A Q15 number will also be assigned. Best regards, Sakae OKUBO *********************************************************** 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 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

alternateGk mechanism?
by Johan Gerhardsson (ETX) 29 Jul '00

29 Jul '00

Hello all, my name is Johan Gerhardsson and I was wondering if any one could help me with a couple of questions regarding the of the alternateGk machanism (h.323v2). How is it possible to make an endpoint (gw) gracefully switch over registration and new calls to another gk without loosing existing calls on the current GK? I.e. how can the Gk tell the gw that it should send its SETUP messages (and keep alive RRQ) to another Gk? I see two possible ways that is almost working: 1) ARQ/ARJ with altGkInfo: What if one wants to use pregranted ARQ? Is the registration (keep alive RRQ) also applied? 2) keep alive RRQ/RRJ with altGkInfo: What happens with existing calls on the GW if the registration is rejected by GK? My scenario is this: Two GK's (Gk1 and Gk2, h323v2) is together working in a load sharing mode. Registration data are duplicated. Calls are not duplicated. The two GK knows that the endpoint Gw shall have Gk1 as primary GK. 1. Gw: RRQ -> Gk1 2. Gk1: RCF (alternateGk=[Gk2's rasaddress,<gkid>,needToRegister = FALSE,prio=1], pregranted=yes) -> Gw 3. Gw sends keep alive RRQ to Gk1. 4. Gw sends SETUP messages to Gk1 and calls are now ongoing (gkrouted) through Gk1. 5. Gk1 goes down (calls are cleared by the Gw). 6. Gw detects that Gk1 has gone down. 7. New call: Gw sends ARQ to Gk2 to get Gk2's call signaling address which is saved for further use. 8. Gw routes new calls through Gk2 (no ARQ is used since pregranted is used). 9. Gw sends keep alive RRQ to Gk2. 10. Gk2: RCF (alternateGk=[Gk2's rasaddress,<gkid>,needToRegister = FALSE,prio=0]) -> Gw 11. Gk1 comes up again. 12. Gk2 detects that Gk1 is up again and wants to tell the Gw that it shall go back to "normal operation" (step 3-4) as this is the wanted scenario with this load shared network setup. Questions: 1) If pregranted was not in use, the Gk2 could use the alternateGk mechanism with ARQ by sending ARJ with altGkInfo = altGkIsPermenent = TRUE, alternateGk=[Gk1,<gkid>,needToRegister=FALSE,prio=0],[Gk2,<gkid>,needToRegister=FALSE,prio=1], but the ARQ is only valid for new calls, not calls AND registration (or?). In the case above, pregranted is wanted to reduce SETUP time, so what shall the Gk2 do? 2) In step 9. the Gw has begun to send keep alive RRQ to Gk2. How shall Gk2 tell the Gw to send keep alive RRQ to Gk1 when it is up and running again? (By using RRJ and altGkInfo you might think, but how is the GW handling the active calls that is routed through Gk2? Is it safe to make the assumption that the Gw will not clear these calls?) Thanks in advance for your comments. Johan Gerhardsson Software developer Ericsson Telecom AB Data Backbone & Optical Networks, IP telephony Phone: +46 (0)8 719 2396 email: Johan.Gerhardsson(a)ericsson.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

H323-URL is on the IPTEL Agenda for IETF, Pittsburgh
by Orit Levin 28 Jul '00

28 Jul '00

Hi all! I would like to let you know, that H323-URL is a topic to be discussed on the IPTEL working session next week during the IETF. (Despite the fact, that it was not listed on the official Agenda, posted on July 23rd) For those, who will be participating in the IETF, please join the forum : Thursday, August 3, 9:00-11:30 AM Best Regards, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit(a)radvision.com

1 0

Re: Expediting H.245
by Callaghan, Robert 28 Jul '00

28 Jul '00

Bob, For the record, what you call "Fast Open" was rejected during the Santiago de Chile meeting. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Bob Gilman [mailto:rrg@LUCENT.COM] Sent: Thursday, July 27, 2000 6:55 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Expediting H.245 Paul- In trying to think about ways to avoid adding the earlyH245 element to SETUP, I overlooked the fact that it could be used just as well to initiate the Fast Open procedures in a way that was backward compatible. That would permit us to offer both Fast Connect and Fast Open - the called endpoint could accept either one (or would see only the fastStart if it were an older endpoint). The advantage of Fast Open in this case would arise from it's use later on in the call (e.g., to switch to FAX or to redirect audio). -Bob ---------------------------------------------------- Bob Gilman rrg(a)avaya.com +1 303 538 3868 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: Expediting H.245
by Callaghan, Robert 28 Jul '00

28 Jul '00

Pete, I do not foresee further enhancements H.323 basic call. There will be enhancements for various "add ons." Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM] Sent: Thursday, July 27, 2000 5:18 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Expediting H.245 Bob, My ears pricked up when you mentioned "migration path". Do you see more additions to fast start/ quicker start/ flexible start? It would be nice to know what your thoughts are. Pete. ============================================= Pete Cordell Tech-Know-Ware pete(a)tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: Callaghan, Robert <Robert.Callaghan(a)ICN.SIEMENS.COM> To: <ITU-SG16(a)mailbag.cps.intel.com> Sent: 27 July 2000 18:48 Subject: Re: Expediting H.245 > Paul, > > Actually I like the procedure for early H.245 tunneling that is in H.323 v4. > It allows for an incremental addition to the Fast Connect procedure of v4 > with a reasonable migration path. The additional field in SETUP that > eliminates the conflict with the requirements of V2 is minimal. I see no > need to create a new procedure that then requires administration or > negotiation. > > Bob > > ------------------------------------------------------------------ > Robert Callaghan > Siemens Enterprise Networks > Tel: +1.561.923.1756 Fax: +1.561.923.1403 > Email: Robert.Callaghan(a)ICN.Siemens.com > ------------------------------------------------------------------ > > -----Original Message----- > From: Bob Gilman [mailto:rrg@LUCENT.COM] > Sent: Thursday, July 27, 2000 12:52 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Expediting H.245 > > Paul- > I didn't say anything about the possiblity of offering > both Fast Connect and Fast Open. It seems to me that > doing so would present the same problems that TD-26 > encountered: we'd need a new tunnel to hide H.245 in the > SETUP message and we'd need to abandon the statement that > starting H.245 terminated Fast Connect (or use the same > tunnel to continue to hide H.245). The only reason > to offer Fast Connect from an endpoint that supports > Fast Open is to work with earlier-version endpoints - > and they're the ones that can't tolerate starting H.245 > before Fast Connect is completed. > I'd rather specify that an endpoint could offer either > Fast Connect or Fast Open (or accept the one offered) > at its option. The question is: how does a calling > endpoint know which to do? It could be done by out-of- > band means (administration), but it could also be done > by looking at the RAS protocolIdentifier which requires > a relationship between H.225.0 and H.245 versions. Isn't > that usually the case anyway? > Again, the advantages of Fast Open over Fast Connect and > early H.245 include: > 1. More compact messaging; > - multiple caps, one OLC; > 2. can be used anytime, not just call establishment; > - no need to switch from one protocol to another, > or from one tunnel to another, especially going > forward; > - uses current cap set; > - just as fast as Fast Connect; > 3. backward compatible with Fast Connect; > - Fast Open "callee" can accept Fast Start from an > earlier version, knows not to use Fast Open; > - but Fast Open caller should not offer Both Fast Open > and Fast Connect - needs to know which to do; > - processing is very similar to Fast Connect; > - no need to modify historical H.225.0 restrictions. > - Fast Open offered to older version endpoint results > in H.245 operation. > The problem of backward compatibility is a sticky one, given > the existing restrictions on simultaneous operation and early > switching to H.245. The sooner we remove these restrictions > from H.225.0, the better off we will be, but I think we've > actually backed ourselves into a corner, unless we effectively > change v2. I would note that the cases for which TD-26 would > work would also work for simultaneous Fast Connect and Fast > Open - but there's no way around the fact that some v2 endpoints > will object in either case. > -Bob > ---------------------------------------------------- > Bob Gilman rrg(a)avaya.com +1 303 538 3868 > > > "Paul E. Jones" wrote: > > > > Bob, > > > > This looks quite reasonable to me. > > > > I may have missed it in here, but do you say anything about including both > > fastStart and these new fields. Proponents of TD-26 wanted to ensure that > > the devices could still take advantage of Fast Connect for those devices > > that support the procedure. > > > > However, I'm not sure that I understand exactly what the advantage is over > > the combined usage of the existing Fast Connect procedure + Early H.245. > > Can you clarify that for me? > > > > Paul > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Expediting H.245
by Paul Long 27 Jul '00

27 Jul '00

Here is a proposal for "expediting" H.245--eliminating explicit establishment of the H.245 control channel, H.323 Phase B. But first, here are the reasons for doing so: - At SuperOp! some people incorrectly assumed that an EP is not required to support H.245 if Fast Connect is performed. However wrong they may be, we all probably believe to some degree that this would be a natural thing to do. - A much-respected colleague at another company said that H.245 is a major encumbrance for large-scale entities. - Some vendors have expressed a desire to use H.245 features, e.g., DTMF and third-party pause, without first having to initiate H.245 procedures, i.e., TermCap exchange and MSD. - I have heard that SIP-H.323 interworking may eliminate H.245. This may primarily be due to the message-intensive channel establishment phase. In order to tempt you into actually reading all of the following explanation, here's the end result. The minimal dialogue necessary to establish a call and the H.245 session in both directions: Setup(expedite) --> <-- Connect(expedite) Here's how it can be done. Add the following ASN.1 component to Setup and all of the possible responses, i.e., Alerting, CallProceeding, Connect, Facility, and Progress: expedite ExpediteH245Tunneling OPTIONAL Define this new type: ExpediteH245Tunneling SEQUENCE { ... } For Setup, the presence of expedite _requests_ an expedited H.245 session; for all the other messages, this _grants_ the request. An EP shall only encode expedite if it also sets h245Tunneling to TRUE in the same message. An expedited H.245 session causes both EPs to treat the H.245 session _as if_ they had already successfully performed the TermCap exchange and MSD before the calling EP transmitted Setup. Once the called EP grants the request, the H.245 state in both EPs is the same as if the TCSs had contained no OPTIONAL components, the protocolIdentifiers were set to the lowest version of H.245 specified by H.323 based on the H.225.0 version, and the result of the MSD is that the calling EP is MASTER [could use any other method for MSD, including the EP with the "greater" IP address is the MASTER]. If the called EP accepts at least one Fast Connect channel, all of the accepted channels are inherited as capabilities by both EPs as if they had successfully performed a second TermCap exchange before the called EP responded to Setup. Once the called EP accepts the Fast Connect channel(s), the H.245 state in both EPs is the same as if the TCSs had contained capabilityTables with entries for all Fast Connect OLCs, numbered starting with 0, and single capabilityDescriptors components with a single capabilityDescriptor, numbered 0, containing a simultaneous capability for each unique sessionID value and an alternative capability for each OLC. In accordance with procedures already defined in H.245 and H.323, the EPs may subsequently perform the TermCap exchange and MSD at any time and any number of times to update the state of H.245 in the respective EPs. For example, the called EP can initiate the TermCap exchange "again" immediately upon receiving Setup (e.g., in Alerting) to indicate advanced DTMF caps, and the calling EP can start exploiting those caps in the very same message it returns the TCSAck. Setup(expedite) --> <-- Alerting(expedite, TCS w/UserInputCap=dtmf) Facility(TCSAck+Signal="7#0") --> Benefits: 1. Very little additional signaling is required (only a new codepoint)--this feature is mostly new interpretation of existing signaling. 2. The backwards-compatibility problems associated with allowing fastStart and h245Control in Setup are avoided. 3. The H.245 session is available to the calling EP in 1 RTD and to the called EP in 0.5 RTDs--the same as media and Fast Connect! 4. Without using Fast Connect, the calling EP can start transmitting media in one less RTD than it could without this new feature. Here are the comparisons: (Feature: calling EP RTDs, called EP RTDs) Fast Connect w/ or w/o Expedite: 1, 0.5 Expedite w/o Fast Connect: 2, 2.5 Neither: 3, 2.5 5. Perhaps this feature could benefit SIP-H.323 interworking if H.245 with full TCS and MSD is deemed too onerous, i.e., don't allow "real" TCSs and MSDs. 6. Marginally less bandwidth consumption and quicker transmission of initial call-signaling messages (okay, I'm reaching... :-) ). 7. This opens up other possibilities (maybe that's a disadvantage :-) ). That's why I defined H245TunnelingExpedition to be extensible. For example, we could indicate that all TCS and MSD requests will be rejected, so don't bother. 8. Works well with others. :-) I mean that it naturally fits in with Fast Connect and H.245 Tunneling. 9. Easy to understand. Okay, to me at least. This is not and may never be a formal contribution. Perhaps just consider it as food for thought. Paul Long Smith Micro Software, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

3 4

Re: Expediting H.245
by Callaghan, Robert 27 Jul '00

27 Jul '00

Paul, Actually I like the procedure for early H.245 tunneling that is in H.323 v4. It allows for an incremental addition to the Fast Connect procedure of v4 with a reasonable migration path. The additional field in SETUP that eliminates the conflict with the requirements of V2 is minimal. I see no need to create a new procedure that then requires administration or negotiation. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Bob Gilman [mailto:rrg@LUCENT.COM] Sent: Thursday, July 27, 2000 12:52 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Expediting H.245 Paul- I didn't say anything about the possiblity of offering both Fast Connect and Fast Open. It seems to me that doing so would present the same problems that TD-26 encountered: we'd need a new tunnel to hide H.245 in the SETUP message and we'd need to abandon the statement that starting H.245 terminated Fast Connect (or use the same tunnel to continue to hide H.245). The only reason to offer Fast Connect from an endpoint that supports Fast Open is to work with earlier-version endpoints - and they're the ones that can't tolerate starting H.245 before Fast Connect is completed. I'd rather specify that an endpoint could offer either Fast Connect or Fast Open (or accept the one offered) at its option. The question is: how does a calling endpoint know which to do? It could be done by out-of- band means (administration), but it could also be done by looking at the RAS protocolIdentifier which requires a relationship between H.225.0 and H.245 versions. Isn't that usually the case anyway? Again, the advantages of Fast Open over Fast Connect and early H.245 include: 1. More compact messaging; - multiple caps, one OLC; 2. can be used anytime, not just call establishment; - no need to switch from one protocol to another, or from one tunnel to another, especially going forward; - uses current cap set; - just as fast as Fast Connect; 3. backward compatible with Fast Connect; - Fast Open "callee" can accept Fast Start from an earlier version, knows not to use Fast Open; - but Fast Open caller should not offer Both Fast Open and Fast Connect - needs to know which to do; - processing is very similar to Fast Connect; - no need to modify historical H.225.0 restrictions. - Fast Open offered to older version endpoint results in H.245 operation. The problem of backward compatibility is a sticky one, given the existing restrictions on simultaneous operation and early switching to H.245. The sooner we remove these restrictions from H.225.0, the better off we will be, but I think we've actually backed ourselves into a corner, unless we effectively change v2. I would note that the cases for which TD-26 would work would also work for simultaneous Fast Connect and Fast Open - but there's no way around the fact that some v2 endpoints will object in either case. -Bob ---------------------------------------------------- Bob Gilman rrg(a)avaya.com +1 303 538 3868 "Paul E. Jones" wrote: > > Bob, > > This looks quite reasonable to me. > > I may have missed it in here, but do you say anything about including both > fastStart and these new fields. Proponents of TD-26 wanted to ensure that > the devices could still take advantage of Fast Connect for those devices > that support the procedure. > > However, I'm not sure that I understand exactly what the advantage is over > the combined usage of the existing Fast Connect procedure + Early H.245. > Can you clarify that for me? > > Paul > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1