On TD26 - Fast TCS and M/S negotiation in H.323v4

Francois Audet audet at NORTELNETWORKS.COM
Wed Jun 7 13:59:14 EDT 2000


Dave, I am sure you know that Keypad doesn't allow you to send
long tones.

For voice GATEWAYS (like a PBX), it is necessary 
to perform a full TCS after call setup to know each other's capabilities.
A simple example is FAX: for sure a big gateway can not set-up two channels
(one for voice and one for fax) just in case, fax tone is detected on one
of the ends. 

There are other H.245 commands that are necessary in H.245 for PBX
functionality:
e.g., Third Party pause and re-routing, to offer call features (AVR,
hunting, etc.).

All these issues were discussed at length in Osaka. 
It's déjà-vu all over again...

> -----Original Message-----
> From: Dave Walker [mailto:drwalker at SS8NETWORKS.COM]
> Sent: Tuesday, June 06, 2000 1:45 PM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
> 
> 
> Paul, why are we even doing this?  I'd just tell Bob to use the Keypad
> Facility IE if he really needs DTMF signalling.  You must realize how
> ridiculous this'll look to advocates of other solutions:  the ITU
> screwed up H.245 tunneling, and now they're adding a new tunnel to fix
> it - yech.
> 
> Dave.
> 
> 
> "Paul E. Jones" wrote:
> >
> > Bob,
> >
> > For messages other than SETUP, I was assuming we could use 
> the existing
> > h245Control field for H.245 message exchange-- only the 
> SETUP message is a
> > special case, since it was explicitly disallowed in H.323v2 
> when fastStart
> > was also present.
> >
> > Paul
> >
> > ----- Original Message -----
> > From: "Callaghan, Robert" <Robert.Callaghan at icn.siemens.com>
> > To: "'Paul E. Jones'" <paulej at PACKETIZER.COM>
> > Cc: "'Mailing list for parties associated with ITU-T Study 
> Group 16'"
> > <ITU-SG16 at mailbag.cps.intel.com>
> > Sent: Tuesday, June 06, 2000 11:27 AM
> > Subject: RE: On TD26 - Fast TCS and M/S negotiation in H.323v4
> >
> > > Paul,
> > >
> > > It would be required in the SETUP, CALL PROCeeding, 
> ALERT, FACILITY, and
> > > CONNECT message in that all of these messages can be sent 
> before Fast
> > Start
> > > is completed or may not be present with Fast Start 
> elements based on v2.
> > >
> > > Bob
> > >
> > > -----Original Message-----
> > > From: Paul E. Jones [mailto:paulej at PACKETIZER.COM]
> > > Sent: Saturday, June 03, 2000 6:41 AM
> > > To: ITU-SG16 at mailbag.cps.intel.com
> > > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
> > >
> > >
> > > Paul, Francois, and others,
> > >
> > > If we were able to get consensus here, I believe we could 
> add a field to
> > the
> > > SETUP-UUIE.  I'd rather not put it in the H323-UU-PDU, since it is
> > intended
> > > for SETUP only as a means of allowing H.245 to used with 
> fastConnect in a
> > > backward compatible manner.
> > >
> > > We have an entire proposal on verbiage to be added to 
> H.323.  I'll have to
> > > review that to see what needs changing-- but there's 
> actually a lot of
> > > description.
> > >
> > > Can we agree to introduce a new "earlyH245" field to go along with
> > > "fastStart" in the SETUP?
> > >
> > > Paul
> > >
> > > ----- Original Message -----
> > > From: "Paul Long" <Plong at SMITHMICRO.COM>
> > > To: <ITU-SG16 at mailbag.cps.intel.com>
> > > Sent: Friday, June 02, 2000 10:11 PM
> > > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
> > >
> > >
> > > > Paul,
> > > >
> > > > While not ideal (nothing is), that's a safe, workable 
> solution. I like
> > it.
> > > > Are you proposing adding the new component to the 
> H323-UU-PDU or the
> > > > Setup-UUIE type? Both locations have their merits. This 
> then should be
> > the
> > > > new text for section 8.2.1/H.323: "The calling endpoint 
> shall not
> > include
> > > > both a fastStart element and encapsulated H.245 
> messages in h245Control
> > in
> > > > the same Setup message. However, the calling endpoint 
> may include both a
> > > > fastStart element and encapsulated H.245 messages in 
> earlyH245Control in
> > > the
> > > > same Setup message." And then explain what the called 
> endpoint is
> > supposed
> > > > to do when fastStart and earlyH245Control are present. 
> While we're at
> > it,
> > > > maybe we should define a separate type, i.e.,
> > > >
> > > > H245Control ::= SEQUENCE OF OCTET STRING OPTIONAL
> > > >                                                 -- each 
> octet string may
> > > contain exactly
> > > >                                                 -- one H.245 PDU
> > > >
> > > > But now how do the two components, h245Control and 
> earlyH245Control
> > > > otherwise relate to each other, i.e., when fastStart is 
> not included?
> > > Should
> > > > we say that if one is present the other shall not be 
> present? That would
> > > be
> > > > the clearest, IMO. Not much is gained by allowing both.
> > > >
> > > >
> > > > Remember, the first rule of standards revision is 
> (everybody repeat
> > after
> > > > me)...
> > > >         "Primum non nocere" ("First do no harm.")
> > > >                 - the Roman physician, Galen
> > > >
> > > > Paul Long
> > > > Smith Micro Software, Inc.
> > > >
> > > > -----Original Message-----
> > > > From: Paul E. Jones [mailto:paulej at PACKETIZER.COM]
> > > > Sent: Friday, June 02, 2000 8:14 PM
> > > > To: ITU-SG16 at MAILBAG.INTEL.COM
> > > > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
> > > >
> > > >
> > > > Francois,
> > > >
> > > > I agree that the behavior is desirable, but I still 
> argue that it will
> > > > break backward compatibility.  If we can agree with a new field
> > > > "earlyH245" as a special field for SETUP to do 
> essentially the same
> > > > thing, but only for V4, I would be quite happy-- we get 
> the same end
> > > > result without V3 and V2 compatibility issues.
> > > >
> > > > I do not want to wait until Portland.  The Whitepaper 
> drafts are due
> > > > before then and I hope that that meeting will be focused on only
> > > > critical issues in H.323 and that most of our time will 
> be spent on
> > > > further development of Annexes and perhaps forward 
> thinking on V5 :-)
> > > >
> > > > Paul
> > > >
> > > > 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > 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
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 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/20000607/e10ed876/attachment-0004.html>


More information about the sg16-avd mailing list