Re: Question on RFC1577.

[Drew Perkins <[e-mail]>]

> > A fully synchronized three-way handshake is trivial.  The CONNECT ACK should
> > be passed end-to-end in exactly the same way as the SETUP and CONNECT.
> > The called party should simply assume that he may start receiving data any time
> > after he sends the CONNECT.  The calling party could then know that as soon as
> > he receives the CONNECT, he should send a CONNECT-ACK, and then can start sending
> > and receiving data.  The called party should not begin sending data until he
> > receives the CONNECT-ACK (even though he has been prepared to receive following
> > his transmission of CONNECT).
>  
> I agree, but this isn't what UNI 3.x says.  With UNI 3.x, it would seem
> that the called party either has to wait for incoming data, or be
> prepared for its transmissions to be lost.


> If I recall correctly, UNI 4.0 will have 3rd-party call setup where
> there are two called parties, and so, having each called party wait for
> incoming data would cuase a deadlock.  Perhaps, UNI 4.0 needs to have
> the CONNECT-ACK become end-to-end (even though I think that would
> require a "flag-day" to upgrade all the switches in a network).

I think the 3rd-party call setup argument is a red-herring.  You are confusing
the control and user planes again.  Each called party should be prepared to
receive data upon sending the CONNECT.  It should not send until it receives
the CONNECT-ACK.  Both sides will eventually receive this, so there is no
deadlock, just a small delay.

Also note that P-NNI phase 1 signalling is not yet complete, and might possibly
be able to fix this right off, particularly because it is being done in a
somewhat coordinated fashion with UNI 4.0.

Drew
-----------------------------------------------------------------
FORE Systems, Inc.			Tel: [phone]
174 Thorn Hill Road			Fax: [phone]
Warrendale, PA 15086-7535		Email: [e-mail]