July 2000 - sg16-avd - lists.packetizer.com

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