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