Re: Question on RFC1577.

[[e-mail]]

> From: [e-mail] (Drew Perkins)
> Subject: Re: Question on RFC1577.
> 
> 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).

Ah, not so trivial! You are changing the semantics of CONNECT ACK by
allowing the called party to receive data before it gets the CONNECT
ACK. The problem would be in negotiating VPI/VCI. Consider the following
scenario:

- P-NNI signalling is the same as UNI signalling (at least for VPI/VCI
  negotiation)

- The originating side at any interface (UNI, P-NNI) selects a desired 
  VPI/VCI, X, and indicates that in the SETUP message. The other side 
  responds with its own choice, Y, in the CONNECT message. The originating
  side accepts it by responding with a CONNECT ACK. If either side disagrees
  about the VPI/VCI to use, it can RELEASE the call.

  In this scenario, the destination side cannot start receiving data on
  Y until the originating side agrees to it. To see why this might be
  needed, consider that the destination side is a user endpoint with
  multiple applications. VPI/VCI Y chosen by one application conflicts
  with that used by another application. The network side switch detects
  this and refuses to accept Y (by sending a RELEASE). If the user
  application had started to use Y before getting CONNECT ACK (or RELEASE),
  it might wrongly receive data intended for another application.

Hence the semantics of the CONNECT ACK are that until the called party
gets it, it cannot start to use the VPI/VCI indicated in the CONNECT.
Of course, different negotiating schemes may place different constraints
on the call setup handshake.

Anyway, I think this is the wrong place for such discussion since we are
not about to design a new signalling protocol here. We have to live with
UNI 3.0/3.1 (or Q.2931) and will have to work around its quirks.

-------------------------------------------------------------------
Rajeev Gupta                       Email     : [e-mail]
Trillium Digital Systems, Inc.     Voice (w) : [phone]
Los Angeles, CA 90025.             Fax   (w) : [phone]
* I speak only for myself, but make no claim to original thought *
-------------------------------------------------------------------