Subject: [Megaco] Is three-way handshake a mandatory requirement?

From: "Deng Pan" <[email-masked]>
Date: Fri, 11 Mar 2005 09:08:31 -0800

Hi:

I have two questions about the three-way handshake.

1.	Is three-way handshake a mandatory requirement for MGC? If
three-way handshake is not implemented in an MGC, can this MGC still
work with other Gateways and MGCs?
2.	If an empty K: parameter is included in every final response to
a transaction, no matter whether the provisional response was previously
sent or not, can this entity (MGC or Gateway) still work with other
entity correctly? Does this implementation violate any protocol
requirement?  What is the advantage and disadvantage of this
implementation?

Thanks and regards

Pan Deng

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Kevin Boyle" <[email-masked]>
Date: Sat, 12 Mar 2005 01:09:44 -0500

Three-way handshake specifically applies to unreliable transport, such as
UDP.  In my experience, however, even with UDP this isn't really necessary,
as retransmissions of commands will prevent loss of replies.  Note that if
the reply contains the ImmAckReq field, a TransResponseAck is mandatory.
 
Empty K parameter?  I assume you mean an empty TransResponseAck?  That is a
syntactically invalid construct.  The TransResponseAck construct requires
the inclusion of at least one TransactionID, per the syntax definitions in
Annexes A and B.
 
Kevin

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Deng Pan
Sent: Saturday, March 12, 2005 1:09 AM
To: [email-masked]
Subject: [Megaco] Is three-way handshake a mandatory requirement?

Hi:

1.	Is three-way handshake a mandatory requirement for MGC? If three-way
handshake is not implemented in an MGC, can this MGC still work with other
Gateways and MGCs? 

2.	If an empty K: parameter is included in every final response to a
transaction, no matter whether the provisional response was previously sent
or not, can this entity (MGC or Gateway) still work with other entity
correctly? Does this implementation violate any protocol requirement?  What
is the advantage and disadvantage of this implementation? 

Thanks and regards

Pan Deng

---

From: "Deng Pan" <[email-masked]>
Date: Sun, 13 Mar 2005 11:11:45 -0800

Hi, Kevin:

Thanks for your answer.  Actually, I should post this question to GCP
(RFC3435) mailing list. But unfortunately, I can not find such a mailing
list on www.ietf.org <http://www.ietf.org/> . So I post this question to
the MEGACO mailing list. I think that the answer should be the same
since the two teams work closely. 

We implemented the GCP protocol and sent it to our customer, and then
our customer designed two three-way handshake test cases for our GCP
protocol implementation. The first test case is that:

1.	the MGC send command to GW
2.	the GW send back the response to the transaction
3.	the MGC send back the acknowledgement to the response

The second test case is the same except that the GW initiates the
transaction.

But we do not think that this test case makes sense. The three-way
handshake does not mean three separated messages for the same
transaction. Actually, in our implementation, the MGC will not send back
the acknowledgement to the response until the MGC initiates another new
transaction, and the acknowledgement to the response will be included in
the new transaction.

However, the customer insists that this three-way handshake test case is
mandatory and must be passed. So we are really sorry about that. From
the protocol point of view, is there anything wrong with our
implementation?

Thanks and regards

Pan Deng 

________________________________

From: Kevin Boyle [mailto:[email-masked]] 
Sent: Friday, March 11, 2005 10:10 PM
To: Deng Pan; [email-masked]
Subject: RE: [Megaco] Is three-way handshake a mandatory requirement?

Three-way handshake specifically applies to unreliable transport, such
as UDP.  In my experience, however, even with UDP this isn't really
necessary, as retransmissions of commands will prevent loss of replies.
Note that if the reply contains the ImmAckReq field, a TransResponseAck
is mandatory.

Empty K parameter?  I assume you mean an empty TransResponseAck?  That
is a syntactically invalid construct.  The TransResponseAck construct
requires the inclusion of at least one TransactionID, per the syntax
definitions in Annexes A and B.

Kevin

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Deng Pan
	Sent: Saturday, March 12, 2005 1:09 AM
	To: [email-masked]
	Subject: [Megaco] Is three-way handshake a mandatory
requirement?

	Hi:

	1.	Is three-way handshake a mandatory requirement for MGC?
If three-way handshake is not implemented in an MGC, can this MGC still
work with other Gateways and MGCs? 
	2.	If an empty K: parameter is included in every final
response to a transaction, no matter whether the provisional response
was previously sent or not, can this entity (MGC or Gateway) still work
with other entity correctly? Does this implementation violate any
protocol requirement?  What is the advantage and disadvantage of this
implementation? 

	Thanks and regards

	Pan Deng

---

From: "Kevin Boyle" <[email-masked]>
Date: Sun, 13 Mar 2005 18:01:48 -0500

MGCP is a different protocol, and works differently than H.248.  There are
others here who can point you to the list for MGCP.
 
Other comments inline. [KJBII]
 
Kevin

  _____  

From: Deng Pan [mailto:[email-masked]] 
Sent: Monday, March 14, 2005 3:12 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; [email-masked]
Subject: RE: [Megaco] Is three-way handshake a mandatory requirement?

Hi, Kevin:

Thanks for your answer.  Actually, I should post this question to GCP
(RFC3435) mailing list. But unfortunately, I can not find such a mailing
list on www.ietf.org <http://www.ietf.org/> . So I post this question to the
MEGACO mailing list. I think that the answer should be the same since the
two teams work closely. 

We implemented the GCP protocol and sent it to our customer, and then our
customer designed two three-way handshake test cases for our GCP protocol
implementation. The first test case is that:

But we do not think that this test case makes sense. The three-way handshake
does not mean three separated messages for the same transaction. Actually,
in our implementation, the MGC will not send back the acknowledgement to the
response until the MGC initiates another new transaction, and the
acknowledgement to the response will be included in the new transaction.
[KJBII] What if there is no need for a new transaction for a long time?  The
point of the three-way handshake is to indicate that the reply was received.
While bundling is generally fine, especially to save messaging overhead, you
cannot hold messaging specifically for the purposes of bundling it.
Remember that this is a real-time operation, and artificial delays will only
cause race conditions and call failures. This applies to any protocol
operating in real-time.

However, the customer insists that this three-way handshake test case is
mandatory and must be passed. So we are really sorry about that. From the
protocol point of view, is there anything wrong with our implementation?
[KJBII] I would have to agree with your customer.  Your implementation needs
to be changed so that you are not holding the TransResponseAck. 

Thanks and regards

Pan Deng 

  _____  

Kevin

  _____  

Hi:

Thanks and regards

Pan Deng