> Chris,
>
> My opinion is that, if you do Fast Connect, there is no need
> to start H.245.
> I agree that support shall be there, so that either end may
> initiate H.245
> for whatever reason, but if using Fast Connect, opening the
> H.245 channel
> should be optional.
>
Correct. Unless you need to support any H.245 message, including
sending DTMF.
> Also, as I suggested earlier, given that tunneling is the
> "norm" now, one
> could argue that the H.245 channel is already there... we just don't
> exchanges messages over it :-) (Yes, I know.. that's a weak
> argument.)
>
> Paul
>
> ----- Original Message -----
> From: "Chris Wayman Purvis" <cwp(a)ISDN-COMMS.CO.UK>
> To: <ITU-SG16(a)mailbag.cps.INTEL.COM>
> Sent: Thursday, March 22, 2001 6:27 AM
> Subject: Re: Conflicting text in H.323 concerning the
> requirement for esta
> blishing a H.245 control channel??
>
>
> > Roni, Frank, Paul Jones et al,
> >
> > Having reread 8.1.7.2 (as referenced by Roni) I believe
> that Frank was
> right
> > all along in saying there is a conflict. 8.1.7.2 saying
> that a device
> "may"
> > establish an H.245 session at any point during a call is, I
> would argue,
> > clearly at odds with 6.2.8 stating that such a session "shall" be
> > established. After all, having not bothered to bring one
> up until an
> > instant before the end of the call (clearly permitted by
> 8.1.7.2), why
> > create one at that stage (except because 6.2.8 tells you to...)?
> >
> > There is an alternative reading: the implication of 6.2.8
> is that some
> sort
> > of H.245 session should start immediately (the start and
> end are the only
> > "special" times in an ordinary call, so if you must start
> one it's pretty
> > well a requirement to do it immediately). What I don't
> recall is whether
> > it's permitted to drop an H.245 session during a call. I
> think it is. So
> > is there an alternative reading, saying "start the H.245
> channel at the
> > beginning of the call, but you may drop and restart it as
> you like during
> > the call"?
> > I don't like this reading, though, it's probably the worst
> of all worlds.
> >
> > However I don't like the delay of setting up an H.245
> session being added
> to
> > the time taken to transmit the first DTMF tone in a call either...
> >
> > Paul,
> >
> > I think this really needs tidying up one way or another - I
> think it's a
> job
> > for the implementors guide... Consensus currently seems to
> be against me,
> > and to be that we should dump the relevant text in 6.2.8.
> >
> > Regards,
> > Chris
> >
> > Roni Even wrote:
> >
> > > Chris,
> > > About your comments
> > >
> > > 1. B can make A start H.245 by using facility message with reason
> > > startH.245. See H.323 8.2.3 Switching to a separate
> H.245 connection.
> > > 2. About 6.2.8 I agree that it states the H.245 shall be
> established, it
> > > does not say when. The when is mentioned in 8.1.7.2.
> > > Roni Even
> > >
> > >
> > > -----Original Message-----
> > > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK]
> > > Sent: Wednesday, March 21, 2001 3:31 PM
> > > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > > Subject: Re: Conflicting text in H.323 concerning the
> requirement for
> > > esta blishing a H.245 control channel??
> > >
> > >
> > > Roni,
> > >
> > >
> > >
> > >> 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.
> > >
> > > Except that it states exactly the opposite in the section under
> discussion.
> > >
> > > Also, consider the following scenario:
> > > Two endpoints, A and B. B does not support tunnelled
> H.245. A calls B,
> > > without giving any H.245 address in its Setup message. B
> accepts the
> call
> > > on the basis of fastStart. No H.245 channel is set up,
> as you suggest.
> > > Suppose now B wishes to send a UII (or any H.245 message)
> to A. It
> can't.
> > > It can't set up the H.245 channel. A could set it up,
> but doesn't see
> the
> > > need.
> > >
> > >
> > >> 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.
> > >
> > > But 6.2.8 does not mean that. It clearly states that an
> H.245 channel
> SHALL
> > > be opened.
> > >
> > >
> > >> As for DTMF you can use the DTMF RTP payload to have it
> in band instead
> of
> > >> H.245.
> > >
> > > If the person you're talking to happens to support this.
> Of course you
> > > don't know whether or not it does if you haven't exchanged TCS.
> > >
> > > Please let's not break this!
> > >
> > > Regards,
> > > Chris
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: Agboh, Charles [mailto:charles.agboh@EBONE.COM]
> > >> Sent: Tuesday, March 20, 2001 6:59 PM
> > >> To: ITU-SG16(a)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@ISDN-COMMS.CO.UK]
> > >>> Sent: Tuesday, March 20, 2001 5:47 PM
> > >>> To: ITU-SG16(a)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@PHILIPS.COM]
> > >>>>> Sent: Tuesday, March 20, 2001 4:40 PM
> > >>>>> To: ITU-SG16(a)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(a)isdn-comms.co.uk on 20-03-2001 15:17:14
> > >>>>> To: Frank Derks/HVS/BE/PHILIPS@EMEA2
> > >>>>> cc: ITU-SG16@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(a)mailbag.intel.com
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >>>
> > >>>
> > >>>> For help on this mail list, send "HELP ITU-SG16" in a
> message to
> > >>>> listserv(a)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(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
> > >
> > >
> > >
> > > --
> > > 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(a)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(a)mailbag.intel.com
> >
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
