Conflicting text in H.323 concerning the requirement for establishing a H.245 control channel??

Paul E. Jones paulej at PACKETIZER.COM
Thu Mar 22 10:44:22 EST 2001


Agreed.. and noted.

pj

----- Original Message -----
From: "Terry L Anderson" <tla at LUCENT.COM>
To: <ITU-SG16 at mailbag.cps.INTEL.COM>
Sent: Wednesday, March 21, 2001 10:31 AM
Subject: Re: Conflicting text in H.323 concerning the requirement for
establishing a H.245 control channel??


> Since there appears to be differing opinions about the current
recommendation's
> requirements for opening an H.245 channel when using fast connect (open
ASAP,
> open only if needed, ...) and discussion seems to recur every few months.
It
> would seem worth adding a clear statement about this through the
Implementor's
> Guide.
>
> Roni Even wrote:
>
> > All,
> >
> > H.323 mandates the support of H.245 for end points that comply with the
> > standard. It does not mean, when using fast connect that it must be open
> > immediately but can be opened at a later stage by any side. The reason
for
> > mandating H.245 is to supply a control channel and is important for
gateways
> > and MCUs as well as for control functions in point to point calls such
as
> > Video fast updates. H.323 annex F defines a simple end point that has
H.245
> > support as optional.
> > I do not see the conflict between 6.2.8 and 8.1.7 if 6.2.8 means that
you
> > have to support it but not to actually open it as in simple fast connect
> > calls.
> > As for DTMF you can use the DTMF RTP payload to have it in band instead
of
> > H.245.
> >
> > Regards
> > Roni Even
> >
> > -----Original Message-----
> > From: Agboh, Charles [mailto:charles.agboh at EBONE.COM]
> > Sent: Tuesday, March 20, 2001 6:59 PM
> > To: ITU-SG16 at MAILBAG.INTEL.COM
> > Subject: Re: Conflicting text in H.323 concerning the requirement for
> > esta blishing a H.245 control channel??
> >
> > Chris,
> >
> > Part of  establishing a "point-to-point" call involves opening 2 TCP
> > connnections using the Fast Connect procedure as you described it.  If
that
> > is the case, then the extract from H.323v2 below is misleading(I
believe).
> >
> > H.323v2: 8.1.7 Fast Connect Procedure
> >
> > "..... The Fast Connect procedure allows the endpoints to establish a
basic
> > point-to-point call with as few as one round-trip message exchange,
enabling
> > immediate media stream delivery upon call connection."
> >
> > BR,
> > Charles
> > > -----Original Message-----
> > > From: Chris Wayman Purvis [mailto:cwp at ISDN-COMMS.CO.UK]
> > > Sent: Tuesday, March 20, 2001 5:47 PM
> > > To: ITU-SG16 at MAILBAG.INTEL.COM
> > > Subject: Re: Conflicting text in H.323 concerning the requirement for
> > > esta blishing a H.245 control channel??
> > >
> > >
> > > Charles,
> > >
> > > It does NOT defeat ANY of the stated aims of FastConnect.
> > > These aims were to get agreed media channels in both
> > > directions open as
> > > quickly as possible.  Doing FastStart AND H.245 gives you your media
> > > quickly, and means you have the power of H.245 thereon.
> > >
> > > In-band DTMF transfer may be used.  If you happen to be using
> > > a codec that
> > > supports it.  If you assume it when you're using an
> > > unsuitable codec you'll
> > > have a problem.  Which is a reason for using H.245 capability
> > > negotiation.
> > >
> > > Regards,
> > > Chris
> > >
> > > Agboh, Charles wrote:
> > >
> > > > which defeats the whole point of having a Fast Connect
> > > procedure (FS +
> > > > H.245).  Why isn't in-band- DTMF transfer used instead (in FS)?
> > > >
> > > > -Charles
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: Frank Derks [mailto:frank.derks at PHILIPS.COM]
> > > >> Sent: Tuesday, March 20, 2001 4:40 PM
> > > >> To: ITU-SG16 at MAILBAG.INTEL.COM
> > > >> Subject: Re: Conflicting text in H.323 concerning the
> > > requirement for
> > > >> establishing a H.245 control channel??
> > > >>
> > > >>
> > > >> Chris,
> > > >>
> > > >> I thought I was being clear enough, so let me try again.
> > > >> 6.2.8/H.323 states
> > > >> that an enpoint must open one (and exactly one) H.245 control
> > > >> channel. When
> > > >> Fast Connect is being used, I assume that the intention is
> > > >> that no such control
> > > >> channel is opened.
> > > >>
> > > >> To be compliant with 6.2.8/H,323 I would have to open a H.245
> > > >> control channel
> > > >> irrespective of which type of H.245 procedures I will be
> > > >> using. So if I intend
> > > >> to use Fast Start (and assuming that the other party also
> > > >> supports this), I
> > > >> still have to open a H.245 control channel.
> > > >>
> > > >> Frank
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> cwp at isdn-comms.co.uk on 20-03-2001 15:17:14
> > > >> To:     Frank Derks/HVS/BE/PHILIPS at EMEA2
> > > >> cc:     ITU-SG16 at mailbag.cps.INTEL.COM@SMTP
> > > >> Subject:        Re: Conflicting text in H.323 concerning the
> > > >> requirement for establishing a H.245 control channel??
> > > >> Classification:
> > > >>
> > > >> Frank,
> > > >>
> > > >> Why do you consider this text to be "conflicting"?
> > > >> Specifically, with what does it conflict?
> > > >>
> > > >> Regards,
> > > >> Chris
> > > >>
> > > >>
> > > >>> 6.2.8/H.323 states: "The endpoint shall establish exactly
> > > one H.245
> > > >>> Control Channel for each call that the endpoint is
> > > >>
> > > >> participating in."
> > > >>
> > > >>> 8.1.7/H.323 never states that when Fast Connect is being
> > > used such a
> > > >>> control channel should be established. As far as I understand the
> > > >>> mechanism this is only required to switch to "normal" H.245
> > > >>
> > > >> procedures.
> > > >>
> > > >>> It would seem that section 6.2.8 should be rephrased to
> > > >>
> > > >> make clear that
> > > >>
> > > >>> the H.245 control channel shall only be established when
> > > >>
> > > >> "normal" H.245
> > > >>
> > > >>> procedures are being followed and not in the fast connect case.
> > > >>>
> > > >>> Frank
> > > >>
> > > >> --
> > > >> Dr Chris Purvis -- Development Manager
> > > >> ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
> > > >> Winkfield Row, Berkshire.  RG42 6LY  ENGLAND
> > > >> Phone: +44 1344 899 007
> > > >> Fax:   +44 1344 899 001
> > > >>
> > > >>
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > >> For help on this mail list, send "HELP ITU-SG16" in a message to
> > > >> listserv at mailbag.intel.com
> > > >>
> > > >
> > > >
> > > >
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > For help on this mail list, send "HELP ITU-SG16" in a message to
> > > > listserv at mailbag.intel.com
> > >
> > >
> > > --
> > > Dr Chris Purvis -- Development Manager
> > > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
> > > Winkfield Row, Berkshire.  RG42 6LY  ENGLAND
> > > Phone: +44 1344 899 007
> > > Fax:   +44 1344 899 001
> > >
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > For help on this mail list, send "HELP ITU-SG16" in a message to
> > > listserv at mailbag.intel.com
> > >
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv at mailbag.intel.com
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv at mailbag.intel.com
>
> --
> ------------------------------------------------------------
> Terry L Anderson              mailto:tla at lucent.com
> Tel:908.582.7013   Fax:908.582.6729
> Pager:800.759.8352 pin 1704572   1704572 at 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
>
>

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



More information about the sg16-avd mailing list