Or something like "H.323 entities shall only process the first fastStart element it receives for a call".
Thanks guys.
> -----Original Message-----
> From: Sasha Ruditsky [mailto:sasha@RADVISION.COM]
> Sent: Friday, May 18, 2001 12:16 PM
> To: ITU-SG16@mailbag.cps.intel.com
> Subject: Re: Switching to H.245
>
>
> Hi François
>
> Probably I'll try to state you question in more generic way.
>
> We know that it is possible to perform OLC operations after fast start
> completed
> and before another Q.931 message (like ALERTING or CONNECT)
> with fast start
> is sent.
> (the simplest probably is to close channel opened using fast start)
> (3rd party pause and redirection is of course procedure of this kind)
>
> What is the meaning of the fast start in such CONNECT message?
>
> And here I agree with Chris that such fast start elements
> should be ignored.
>
> So probably the text that may solve this and should be added
> should state
> something like:
> "H.323 entity shall process fast start elements only once
> during the call."
>
> BTW Probably the same statement should be done about
> h245Address. I just
> know one H.323 endpoint that established 3 H.245 connections
> when got the
> h245Address in CALL PROCEEDING, ALERTING and CONNECT.
>
> Sasha
>
>
>
> -----Original Message-----
> From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK]
> Sent: Friday, May 18, 2001 6:56 AM
> To: ITU-SG16@mailbag.cps.INTEL.COM
> Subject: Re: Switching to H.245
>
>
> Francois,
>
> Good catch! My suggestion would be to add some text saying
> that anything
> exchanged via H.245 overrides anything done by fastStart, even if the
> fastStart happens to arrive later.
>
> Now what happens if there's a possible scenario someone can
> devise where you
> manage to get tunnelled and "separate connection" H.245
> contradicting each
> other is a thornier problem - can anyone see that happening?
>
> Regards,
> Chris
>
> Francois Audet wrote:
>
> > Hum, interesting.
> >
> >
> >
> > My follow up question is then:
> >
> > * A sends SETUP to B with fast start with h245Address and
> > tunnelling. ALERTING responds to FS, and the whole TCS and M/S
> > process takes place. Then A wants to forward the call
> (internally)
> > before answer (i.e., in the ALERTING phase). It thus
> sends TCS=0,
> > TCS=full, OLCs and all that. Then B answers and sends
> the CONNECT
> > (with the same fastStart as the ALERTING as per earlier
> > discussions we had ;^) Wouldn't the content of the fastStart
> > contradict what the actual forwarded connections is
> really? Would
> > it be a problem?
> >
> > Seems pretty tricky...
> >
> > -----Original Message-----
> > From: Paul Long [mailto:plong@IPDIALOG.COM]
> > Sent: Thursday, May 17, 2001 11:52 AM
> > To: ITU-SG16@MAILBAG.INTEL.COM
> > Subject: Re: Switching to H.245
> >
> > Francois,
> >
> >
> >
> > I realize how this could be confusing, but I don't
> necessarily see a
> > conflict since they all say, "may." For example, if I
> say, "X may do
> > A or B," and, "X may do B," that does not preclude "X may do A."
> > Conversely, if I said "shall" instead of "may," I think
> there would
> > be real conflicts. I've worked on EPs that are very aggressive
> > during call establishment. For example, Setup contains an
> > h245Address and indicates support for Fast Connect and H.245
> > Tunneling. Other than all the non-compliant EPs out
> there, it worked
> > just fine. The EPs also support third-party pause, but I don't
> > remember ever testing that particular scenario. As long
> as an EP is
> > implemented correctly, I don't see anything in the
> Recommendation
> > that would prevent this from working.
> >
> >
> >
> > Paul Long
> >
> > ipDialog, Inc.
> >
> > -----Original Message-----
> > From: Mailing list for parties associated with
> ITU-T Study Group
> > 16 [mailto:ITU-SG16@mailbag.cps.INTEL.COM]On Behalf
> Of Francois
> > Audet
> > Sent: Thursday, May 17, 2001 1:07 PM
> > To: ITU-SG16@mailbag.cps.INTEL.COM
> > Subject: Switching to H.245
> >
> > Guys,
> >
> >
> >
> > H.323/8.1.7.2 says :
> >
> > After establishment of a call using the Fast Connect
> > procedure, either endpoint may determine that it is
> > necessary to invoke call features that require
> the use of
> > H.245 procedures. Either endpoint may initiate
> the use of
> > H.245 procedures at any point during the call, using
> > tunnelling as described in 8.2..1 (if
> h245Tunnelling remains
> > enabled) or a separate H.245 connection. The process for
> > switching to a separate H.245 connection is described in
> 8.2.3.
> >
> > 8.2..3 says:
> >
> > When H.245 encapsulation or Fast Connect is being used,
> > either endpoint may choose to switch to using
> the separate
> > H.245 connection at any time.
> >
> > There seem to be some contradiction in there: is it "after
> > establishment" or "at any time"?
> >
> >
> >
> > Do you have to wait for after CONNECT to establish
> a separate
> > H.245 channel or not?
> >
> >
> >
> > The case I'm interested in would be to send SETUP with
> > fastStart, then receive ALERTING with fastStart.
> Then can either
> > end initiate H.245 before CONNECT? If so, what if
> third party
> > pause and redirection is initiated before CONNECT?
> >
> >
> >
> > ----
> >
> > François AUDET, Nortel Networks
> >
> > mailto:audet@nortelnetworks.com, tel:+1 408 495 3756
> >
> >
> >
>
>
> --
> 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@mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv@mailbag.intel.com
>