----- Original Message -----

From: Francois Audet

To: ITU-SG16@mailbag.cps.intel.com

Sent: Wednesday, July 26, 2000 1:52 PM

Subject: Re: Expediting H.245

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@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@ICN.Siemens.com
> ------------------------------------------------------------------
>
>  -----Original Message-----
> From:   Paul Long [mailto:Plong@SMITHMICRO.COM]
> Sent:   Wednesday, July 26, 2000 11:00 AM
> To:     ITU-SG16@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@mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv@mailbag.intel.com
>