Gatekeeper behavior question

[Hans Viens]

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 at IPDIALOG.COM]
>     Sent: Thursday, May 17, 2001 11:52 AM
>     To: ITU-SG16 at 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 at mailbag.cps.INTEL.COM]On Behalf Of Francois
>         Audet
>         Sent: Thursday, May 17, 2001 1:07 PM
>         To: ITU-SG16 at 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 at 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 at mailbag.intel.com