New Editor of H.225.0 and the H.323-Series Implementers Guide

Paul E. Jones paulej at PACKETIZER.COM
Thu Mar 22 12:13:25 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.

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



More information about the sg16-avd mailing list