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

Francois Audet audet at nortelnetworks.com
Thu Mar 22 12:20:31 EST 2001


> 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 at ISDN-COMMS.CO.UK>
> To: <ITU-SG16 at 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 at ISDN-COMMS.CO.UK]
> > > Sent: Wednesday, March 21, 2001 3:31 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??
> > >
> > >
> > > 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 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
> > >
> > >
> > >
> > > --
> > > 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
> >
> >
> > --
> > 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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20010322/ec913933/attachment-0004.html>


More information about the sg16-avd mailing list