Switching to H.245

Francois Audet audet at NORTELNETWORKS.COM
Fri May 18 16:00:20 EDT 2001


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 at RADVISION.COM]
> Sent: Friday, May 18, 2001 12:16 PM
> To: ITU-SG16 at 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 at ISDN-COMMS.CO.UK]
> Sent: Friday, May 18, 2001 6:56 AM
> To: ITU-SG16 at 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 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
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 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/20010518/81e860b9/attachment-0004.html>


More information about the sg16-avd mailing list