- 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

Re: Expediting H.245
by Francois Audet 27 Jul '00

27 Jul '00

Me too. Unless it really improves anything, I think these last minute changes to the White document are pretty dangerous. > -----Original Message----- > From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] > Sent: Thursday, July 27, 2000 10:49 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > 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 >

1 0

documents for Portland meeting
by Glen Freundlich 27 Jul '00

27 Jul '00

Colleagues, I have placed 4 documents from SG8 in the Incoming directory of the Pictel avc site: APC-1889: Voice/fax switching in draft H.323 Annex D V2 APC-1890: Facsimile related work on draft H.248 Annex F APC-1891: Draft T.38 Appendix V H.248 Call Establishment Procedure Examples APC-1892: Proposed Edits to H.248 Annex F Regards, Glen

1 0

Re: [H.323 Mobility:] Usage of H.225 Annex G in H.323 Annex H & a question about BEs
by Roy, Radhika R, ALCOO 27 Jul '00

27 Jul '00

Hi, Jaakko: I am glad that you have clarified most of the points. Let me add a little more in this area from Annex G point of view as follows: 1. GK and BE are assumed to be co-located (that is, no protocol has been defined yet between the GK and the BE). 2. We will be within the framework of H.225.0 Annex G and base H.323 protocol if our H.323 mobile architecture and protocol follow the simple logic considering VLF, HLF, and AuF are the H.323 backend services where H.323 functional entities like GKs and BEs need to communicate: GK <-> VLF; GK <-> HLF; GK <-> AuF; GK <-> any other new entities; BE <-> VLF; BE <-> HLF; BE <-> AuF; BE <-> any other new entities; 3. The protocols/architecture that are NOT within the jurisdiction of base H.323 or H.225.0 Annex G spec are as follows: HLF <-> VLF; AuF <-> VLF; or HLF <-> AuF So, we need to focus only on item 2 for now as long as we consider that we are working within the framework of H.323 protocol and architecture because it extends the H.323 protocol to support "mobility." For item 3, it is completely outside the scope of H.323 and we are NOT authorized to do this. A new question may be opened to address this area because it is nothing do with H.323 protocol. This area is not only true for mobility, but this is also true for security, QOS, billing, directory, management and others as well. These are NEW protocols, not the extension of H.323 protocol. Definitely, we may have to address how we define home/foreign (visiting/serving, visited, target) GKs/Zones/Domains. Similarly, we may have to define home/foreign (visiting/serving, visited, target) BEs. The only comment that I have for the "home" BE is: How do we define the "home" BE element uniquely assuming that a domain may have more then one BE. Please note that this is not the case in defining the "home" GK because a use can directly register with the GK (this is not the case with the BE). Let us have more discussion on this topic. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] Sent: Thursday, July 27, 2000 3:56 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] Usage of H.225 Annex G in H.323 Annex H & a question about BEs Hi Radhika et al, As I said, this issue has been brought up several times in the past. Your contribution APC-1770 is a good example of that. Also Mr. Kumar's APC-1780 included the idea of using Annex G, Lucent had a contribution talking about Home and Visited BEs in Geneva (February) and so on (I remember doing a contribution for the Red Bank meeting along similar lines). So the idea has been around and I'm certainly taking your contribution into account when I'm doing my proposal about the Annex G protocol usage. You're also right in saying that the current Annex H architectural model breaks the H.323 model by allowing communications between VLFs and HLFs in different domains without going through the BE functionality. The H.225 Annex G clearly states that all Inter-domain communications should go through the BEs. Now, I have a bit of a philosophical question about the nature of the BE functionality. H.225 Annex G defines a protocol for the usage in communications between the BEs. So, is the BE functionality defined as being the (only) functionality that is capable of understanding the Annex G protocol? If that is so and we want to use this protocol in the communications between the Mobility functional elements (e.g. VLF, HLF), it would actually mean that the Mobility functional elements would have to be BEs as was suggested by the Lucent contribution in Geneva. On the other hand I remember a discussion in Osaka about allowing the usage of the Annex G protocol also between GKs inside one domain, which would indicate that the BE is not defined as being the functionality that knows the Annex G protocol, but rather, as its name states, just the edge point of a domain. If this assumption is true, I would suggest that we should be able to use the Annex G protocol between the Mobility functional elements inside a domain (and also between a GK and a VLF, for example) and convey all Inter-domain communications through the BE, thus getting rid of the interface between the VLF and HLF across the domain boundaries. Anyway, I think that the statement about only using the BEs in the Inter-domain communications is intended to rather say: "Inter-domain communications are only allowed by using the Annex G protocol". Since we are talking about BE functionality which, at the moment, can not even exist on its own in a network element, it is trivial to just glue the BE functionality to each functionality that we wish to be using the Annex G protocol (thus forming "composite" network elements, such as VLF/BE and HLF/BE). If we still want to keep the statement about the BEs being the only connection points between domains and still wish to use the Annex G protocol for communications between the Mobility functional elements, that is what we need to do. -Jaakko ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

Re: [H.323 Mobility:] Usage of H.225 Annex G in H.323 Annex H & a question about BEs
by Jaakko Sundquist 27 Jul '00

27 Jul '00

Hi Radhika et al, As I said, this issue has been brought up several times in the past. Your contribution APC-1770 is a good example of that. Also Mr. Kumar's APC-1780 included the idea of using Annex G, Lucent had a contribution talking about Home and Visited BEs in Geneva (February) and so on (I remember doing a contribution for the Red Bank meeting along similar lines). So the idea has been around and I'm certainly taking your contribution into account when I'm doing my proposal about the Annex G protocol usage. You're also right in saying that the current Annex H architectural model breaks the H.323 model by allowing communications between VLFs and HLFs in different domains without going through the BE functionality. The H.225 Annex G clearly states that all Inter-domain communications should go through the BEs. Now, I have a bit of a philosophical question about the nature of the BE functionality. H.225 Annex G defines a protocol for the usage in communications between the BEs. So, is the BE functionality defined as being the (only) functionality that is capable of understanding the Annex G protocol? If that is so and we want to use this protocol in the communications between the Mobility functional elements (e.g. VLF, HLF), it would actually mean that the Mobility functional elements would have to be BEs as was suggested by the Lucent contribution in Geneva. On the other hand I remember a discussion in Osaka about allowing the usage of the Annex G protocol also between GKs inside one domain, which would indicate that the BE is not defined as being the functionality that knows the Annex G protocol, but rather, as its name states, just the edge point of a domain. If this assumption is true, I would suggest that we should be able to use the Annex G protocol between the Mobility functional elements inside a domain (and also between a GK and a VLF, for example) and convey all Inter-domain communications through the BE, thus getting rid of the interface between the VLF and HLF across the domain boundaries. Anyway, I think that the statement about only using the BEs in the Inter-domain communications is intended to rather say: "Inter-domain communications are only allowed by using the Annex G protocol". Since we are talking about BE functionality which, at the moment, can not even exist on its own in a network element, it is trivial to just glue the BE functionality to each functionality that we wish to be using the Annex G protocol (thus forming "composite" network elements, such as VLF/BE and HLF/BE). If we still want to keep the statement about the BEs being the only connection points between domains and still wish to use the Annex G protocol for communications between the Mobility functional elements, that is what we need to do. -Jaakko ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Expediting H.245
by Francois Audet 27 Jul '00

27 Jul '00

Actually, I believe the editor (correct me if I'm wrong Paul Jones) did some editorial (I love this word) changes from what was in TD-26a. So Paul Long should really look at the latest and greatest H.323v4. > -----Original Message----- > From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] > Sent: Wednesday, July 26, 2000 8:28 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Expediting H.245 > > > Paul, > > This topic was discussed in the Osaka meeting. The need for a faster > started H.245 was very apparent for several reasons. The compromised > proposal is presented in TD-26a from Osaka. It is the same > as your proposal > in the number of required messages. It also solves the problems of > negotiating particular elements by including full TCS and M/S in the > procedure. > > Please look at this. > > 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: Paul Long [mailto:Plong@SMITHMICRO.COM] > Sent: Wednesday, July 26, 2000 11:00 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Expediting H.245 > > 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 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

2 1

Re: APC Numbers
by Sakae OKUBO 27 Jul '00

27 Jul '00

Dear Mr. Potter, >You may remember there was not time at the Osaka meeting to cover all of >the contributions uploaded. In particular, we did not have time to >discuss a BT contribution, APC 1845 - Applying the Extensible Package >Framework to Annex G'. It was agreed at the time, that this (and other >docs) would be discusssed at Portland. Does this mean we have to resubmit >the document again, and get another APC number? Yes, I remember some contributions were carried over to Portland from Osaka as attached at the end of this message. If we should discuss APC-1845 as it is, you need not resubmit it. I will list it as part of the contributions to be considered at the Portland meeting. If you wish to make an updated version, it is better to use a new number with indication of relationship to APC-1845 inside the new document. 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 *********************************************************** Excerpt from APC-1871a >5.2 Coordination > >... > >1819 Lucent Technologies Update on ETSI TIPHON architecture work including >latest TIPHON Architecture Draft > >TD-16 has slides that explain this document. TD-35a has updated slides. > > >1820 Lucent Technologies Update on ETSI TIPHON QoS work including latest >TIPHON End to End QoS Framework Draft > >Return to this in the context of the QoS discussion at the Portland >meeting. TD-17 has slides on this topic. > >... > >5.5.7 H.225.0 Annex G V2 > >1797 Editor (M Fortinsky) H.225.0 Annex G version 2 - draft >1781 Lucent Technologies Reference Points for the Use of Annex G >1796 Editor (M Fortinsky) H.225.0 Annex G version1 - with corrections >1845 BT Applying the Extensible Package Framework to Annex G > >This material was not covered due to lack of time and will be covered in >Portland. ------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

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

26 Jul '00

Paul, This topic was discussed in the Osaka meeting. The need for a faster started H.245 was very apparent for several reasons. The compromised proposal is presented in TD-26a from Osaka. It is the same as your proposal in the number of required messages. It also solves the problems of negotiating particular elements by including full TCS and M/S in the procedure. Please look at this. 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: Paul Long [mailto:Plong@SMITHMICRO.COM] Sent: Wednesday, July 26, 2000 11:00 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Expediting H.245 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

subscribe
by nagaraju 26 Jul '00

26 Jul '00

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC-1883a
by Terry L Anderson 25 Jul '00

25 Jul '00

After I uploaded APC-1883, a copy of the internet draft of CPL <draft-ietf-iptel-cpl-01.txt>, to the incoming directory, a new draft, 02, was made available. So I have created APC-1883a containing the newer draft and uploaded it. Could you remove the APC-1883.zip file and replace it with the new APC-1883a.zip? Thank you. -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572(a)skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

1 0

Re: [H.323 Mobility:] Usage of H.225 Annex G in H.323 Annex H
by Roy, Radhika R, ALCOO 25 Jul '00

25 Jul '00

Hi, Jaakko and All: In fact, AT&T's contribution APC-1770 submitted in Osaka provides the framework for H.323 inter-domain mobility management using H.225.0 Annex G. So far I understand that this framework has been accepted. The next question is: How do we extend the H.323 protocol to support mobility using H.225.0 Annex G? We have not resolved this issue. I made several attempts what we need to do and why some of the proposals made earlier were NOT acceptable from Annex G point of view. I raised the issue that some proposals for inter-domain communications VIOLATE Annex G. One of the fundamental objections has been Figure 7 (H.323 Annex H Functional Architecture Diagram with Reference Points) of H.323 Annex H draft that shows that "VLF of one domain can communicate with another domain." In my opinion, this "VIOLATES" H.225.0 Annex G. Because Annex G ONLY allows that the communications between the two domains can ONLY be permitted via Border Elements (BEs). I am fully confident that we can solve all H.323 mobility related problems abiding by the "fundamental" principles of H.225.0 Annex G. For example, APC-1770 provides guidelines how we can do this. Please note that this is a very "SERIOUS" issue as I explained in many of my emails because it may break the fundamental protocol architecture of H.323 in general. One of the examples can be H.323 QOS. For inter-domain QOS, we also need to adhere to the same principles of H.225.0 Annex G. We cannot allow one QOS manager module sitting behind the GK will be communicating with another QOS manager of another domain "by-passing" the BEs. Similarly, we can extend the models for billing, directory, and many other services. In fact, H.225.0 Annex G is addressing usage and other services that are used for billing, and Annex G has solved this problem through communicating via BEs (not by-passing them). If one by-passes the BEs (as the VLFs and HLFs of Figure 7 do), people can develop an entirely new protocol (or a new sets of protocols) that can be totally independent of H.323 protocol ( and may not have any relationship of the existing H.323 or H.225.0 Annex G protocol). So, I am raising my serious concerns as I did in the past. I am also enclosing a copy of APC-1770. I like to see the comments of other members as well. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] Sent: Tuesday, July 25, 2000 9:19 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: [H.323 Mobility:] Usage of H.225 Annex G in H.323 Annex H Hi all, As the Mobility AHG members know, the idea of using the H.225 Annex G (Communication between Administrative Domains)protocol in H.323 Annex H has been brought up many times in the discussions. So far, we haven't, however, made any decision or even exhaustive proposals for its usage. Now, the next thing I would like to see in the next draft of Annex H would be the refinement of the information flows and the messages used in the flows and at this point I would like to see what the reaction of the AHG members as well as anyone interested in the topic to the usage of H.225 Annex G protocol would be. The more I have refreshed my memory and knowledge about H.225 Annex G, the more I think that the protocol would be suitable for use in H.323 Annex H (some additions to the protocol would surely be needed). I'm planning on writing an MD contribution for the Mobility Management procedures using the actual H.225 Annex G protocol and if it seems after discussion on the contribution that people are in favor of using the protocol, I'll add this stuff in the next draft annex. So, at this point I would just like to see your overall comments about the usage of H.225 Annex G. ------------------------------------------------ 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

1 0

[H.323 Mobility:] Usage of H.225 Annex G in H.323 Annex H
by Jaakko Sundquist 25 Jul '00

25 Jul '00

Hi all, As the Mobility AHG members know, the idea of using the H.225 Annex G (Communication between Administrative Domains)protocol in H.323 Annex H has been brought up many times in the discussions. So far, we haven't, however, made any decision or even exhaustive proposals for its usage. Now, the next thing I would like to see in the next draft of Annex H would be the refinement of the information flows and the messages used in the flows and at this point I would like to see what the reaction of the AHG members as well as anyone interested in the topic to the usage of H.225 Annex G protocol would be. The more I have refreshed my memory and knowledge about H.225 Annex G, the more I think that the protocol would be suitable for use in H.323 Annex H (some additions to the protocol would surely be needed). I'm planning on writing an MD contribution for the Mobility Management procedures using the actual H.225 Annex G protocol and if it seems after discussion on the contribution that people are in favor of using the protocol, I'll add this stuff in the next draft annex. So, at this point I would just like to see your overall comments about the usage of H.225 Annex G. ------------------------------------------------ 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

1 0

Re: [H.323 Mobility:] Update to Service Definitions for Annex H - > a question
by Jaakko Sundquist 25 Jul '00

25 Jul '00

Hi all, For once, a really short and simple email... > I think that MD-102a is good one. It consists of 3 parts: > > 1. Use mobility > 2. Terminal mobility > 3. Service mobility (clip) > So, my proposal for the interest of the rapid standardization > effort is as > follows: > a. Phase 1: Items 1 and 2 > b. Phase 2: Item 3 > > I like to see other members also provide comments on this. This is exactly my feeling on how we should proceed with the work. Let's try to get the basic services stuff determined in this autumn (October, was it?) and decided next spring. After that we can continue with the supplementary services, etc. in the next version of Annex H. Otherwise, I'm afraid we have too much to do with regards to the decision next spring. -Jaakko ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Request for APC Numbers for Portland
by Sakae OKUBO 24 Jul '00

24 Jul '00

Dear Bob, In response to your request, APC numbers have been allocated to your contributions as follows: APC-1887 >H.450.12 - Common Information Additional Network Feature for H.323 > From Siemens AG APC-1888 >M.3 - Tunneling of DSS1 in H.323 > From Siemens AG 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

H.225-Annex G clarification
by Archana Nehru 24 Jul '00

24 Jul '00

hi everyone, I need a clarification on the following issue for H.225 -Annex G used for communication between two border elements(BE). I would appreciate any help on this. 1. In the current Annex G specfications, border elements exchange "usageIndication" messages with each other to inform each about "call usages" etc for billing purposes. The usage Indication message is sent according to a information element called "usageSpecifcation". This element is exchanged in messages like ACCESS_CONFIRM etc. The ASN syntax defined for this "usageSpecification" is: UsageSpecification::= sequence { sendTo ElementIdentifier .... } The "sendTo" field is supposed to identify the destination "border element" to which the "usage indication" messages for a call must be sent. The issue here is that "elementidentifier" is not defined as a "unique string", so the "sendTo" field by itself cannot identify the destination BE of the "usageIndication" message uniquely? In other words, to send a usage indication message, a BE needs to know the logical address of the "destination" BE. This logical address could then be resolved to a transport address which in turn is used to send "usageIndication" messages. So dont we need to add suitable fields to the "usageSpecification" field to identify the recipient of the "usageindication" message uniquely? If yes, then we should add a "domainId"(this defines the domain within which the BE resides) and also a "logical address" to the "usageSpecification" element. Do we agree that this is required? Regards Archana ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [H.323 Mobility:] Update to Service Definitions for Annex H - > a question
by Roy, Radhika R, ALCOO 24 Jul '00

24 Jul '00

Hi, Mark and Jaakko: I think that MD-102a is good one. It consists of 3 parts: 1. Use mobility 2. Terminal mobility 3. Service mobility The interesting thing is that services also overlap for items 1 and 2 indirectly. However, let me relate above items from the H.323 standard perspective. Item 3 as described in the contribution, it may fall into the category of H.323 supplementary services mobility, while items 1 and 2 will be H.323 (basic) call services. With respect to the "scope" of our present standardization effort of Annex H, the basic question is: How far do we want to go? The reason that I am saying so is that AT&T contribution D.353 provides another view of the services mobility. MD-102a (Siemens and Intel) also describes how many more items need to be addressed for the services mobility. You can easily imagine that the services mobility is one of the most important items that the service providers like to see happen in standard arena. So, my proposal for the interest of the rapid standardization effort is as follows: a. Phase 1: Items 1 and 2 b. Phase 2: Item 3 I like to see other members also provide comments on this. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com] Sent: Monday, July 24, 2000 4:14 AM 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