Subject: RE: [Megaco] Baseroot v2 Use case query

From: "Anant Kumar \(anant\)" <[email-masked]>
Date: Thu, 18 May 2006 16:52:42 -0700

Kevin, Thanks for weighing in. I have some more questions inline.

________________________________

From: Kevin Boyle [mailto:[email-masked]] 

	This is probably the right place for this query. We are
implementing the
	baseroot v2 package and discussing the various timers and
retransmission
	limits. I will present this discussion in the context of a
transaction
	originated by and MGC  but this could apply in the reverse
direction as
	well.
	
	Lets say a transaction is originated by the MGC and a
provisional
	response is received from the MG. It does not make any sense for
the MGC
	to continue to retransmit the transaction request - it starts an
	appropriately long timer and sleeps waiting for the final
response.
	
	[BVS] You are right that retransmission should not be at the
same frequency
	as the earlier ones, and should switch to some bigger timer
values. 
	[/BVS]
	[KJBII] This is not entirely correct.  The MGC switches to a
much longer retransmit timer, and then awaits its expiry to retransmit
the message.  If there is not another Pending, or a Reply by the time
this longer retransmit timer expires, the MGC would retransmit the
original Transaction again. 
	
	[anant] This is the crux of the matter. The debate is around the
question whether the MGC retransmits the request or we rely on a
retransmission of the reply by the gateway. your statement suggests that
the MGC should retx the request. 
	
	2. Should the MG request ImmediateAck on the final response
(MGCP
	requires this) and if the immediate ack is not received, keep
	retransmitting the response - much like it was a request (MGCP
(or is it
	TGCP) mandates this).
	[KJBII] Keep in mind that this is not MGCP, and just because
MGCP does or does not require something is irrelevant.
	 [anant] I do not suggest that this being an MGCP feature makes
it binding in any way, on H248. This was an attempt at providing some
precedence of Response retransmission since I did not find any text in
H.248 about it. But, I do agree with you, from the perspective of the
protocol, it is irrelevant.

	[BVS] Megaco Protocol clearly provide the guidelines to send
IMMACK on the final response if it has 
	already generated pending. If the IMMACK is received then MG
removes the transaction context. If
	however IMMACK is not received, then protocol does not say
anything on sending the transaction response again
	untill retransmission occur from MGC. The transaction context is
removed once LongTimer gets expired.
	If MG has generated enough pending and exceeds pending limit
then it generates 
	Error 506 ("Number of TransactionPendings Exceeded")to the MGC
and clears its transaction context.
	[/BVS]

	[anant] once again, the reason this question arose is because
the protocol is silent on this! 
	[KJBII] Silent?  To quote from clause D.1.4: "An entity that
sends a provisional response shall include the immAckRequired field in
the ensuing final response, indicating that an immediate confirmation is
expected."  I'm not sure how much more explicit the text can get.  The
reply would be retransmitted until such time the TransResponseAck is
received. 

	[anant] Once again, I do not suggest that the spec is silent on
the requirement of including the immAckrequired field. I think it is
silent on the follow-up behavior if the TransResponseAck is not
received! You say here that the reply would be retransmitted.... I do
not find that explicitly stated in the spec.  

	In any case, paraphrasing your two statements above:

	1. MGC will retransmit the original transaction (request) upon
expiry of the longer retransmission timer.

	2. The reply will be retransmitted until the TransResponseAck is
received.

	I am not sure I agree if both sides should retransmit their
messages independently. I personally lean towards 1 but am willing to be
convinced that 2 is right!

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

---

From: Christian Groves <[email-masked]>
Date: Fri, 19 May 2006 15:01:40 +1000

Hello Anant,

Please see comments [CNG] below.

Regards, Christian

Anant Kumar (anant) wrote:

> ------------------------------------------------------------------------
> *From:* Kevin Boyle [mailto:[email-masked]]
>
>
>
>     limits. I will present this discussion in the context of a transaction
>     originated by and MGC but this could apply in the reverse direction as
>     well.
>
>     Lets say a transaction is originated by the MGC and a provisional
>     appropriately long timer and sleeps waiting for the final response.
>
>     [BVS] You are right that retransmission should not be at the same
>     frequency
>     as the earlier ones, and should switch to some bigger timer values.
>     [/BVS]
>     [KJBII] This is not entirely correct. The MGC switches to a much
>     longer retransmit timer, and then awaits its expiry to retransmit
>     the message. If there is not another Pending, or a Reply by the
>     time this longer retransmit timer expires, the MGC would
>     retransmit the original Transaction again.
>
>     retransmission of the reply by the gateway. your statement
>     suggests that the MGC should retx the request.
>
[CNG] The ALF procedures mainly talk about retransmission of 
Transactions, pending Transactions etc. A Transaction is the Request and 
Reply. So its the Transaction that is repeated not the message. 
Therefore if the transaction is initiated by the MGC then it retrys the 
Transaction. Also:
"D.1.3 Computing retransmission timers
It is the responsibility of the requesting entity to provide suitable 
timeouts for all outstanding transactions, and to retry transactions 
when timeouts have been exceeded. "

>     2. Should the MG request ImmediateAck on the final response (MGCP
>     retransmitting the response - much like it was a request (MGCP (or
>     is it
>     TGCP) mandates this).
>     [KJBII] Keep in mind that this is not MGCP, and just because MGCP
>     does or does not require something is irrelevant.
>     [anant] I do not suggest that this being an MGCP feature makes it
>     binding in any way, on H248. This was an attempt at providing some
>     precedence of Response retransmission since I did not find any
>     text in H.248 about it. But, I do agree with you, from the
>     perspective of the protocol, it is irrelevant.
>
>
>     If MG has generated enough pending and exceeds pending limit then
>     it generates
>     Error 506 (“Number of TransactionPendings Exceeded”)to the MGC and
>     clears its transaction context.
>     [/BVS]
>
>     [anant] once again, the reason this question arose is because the
>     protocol is silent on this!
>     [KJBII] Silent? To quote from clause D.1.4: "An entity that sends
>     a provisional response shall include the immAckRequired field in
>     the ensuing final response, indicating that an immediate
>     confirmation is expected." I'm not sure how much more explicit the
>     text can get. The reply would be retransmitted until such time the
>     TransResponseAck is received.
>
>     the requirement of including the immAckrequired field. I think it
>     is silent on the follow-up behavior if the TransResponseAck is not
>     received! You say here that the reply would be retransmitted.... I
>     do not find that explicitly stated in the spec.
>
>     messages independently. I personally lean towards 1 but am willing
>     to be convinced that 2 is right!
>
[CNG] See my above comment.

>------------------------------------------------------------------------
>

---

From: "B Venkat S.R Swamy" <[email-masked]>
Date: Fri, 19 May 2006 11:34:32 +0530

Hi

further clarification on comments on retransmitting the request and response [BVS]

regards

B Venkat S.R Swamy

Senior Technical Leader

Flextronics Software Systems

Phone: +91-124- 4176213

Fax: +91-124-4300247

web: www.flextronicssoftware.com

Christian Groves <[email-masked]>

Christian Groves <[email-masked]>

05/19/2006 10:31 AM

To

"Anant Kumar (anant)" <[email-masked]>

cc

Kevin Boyle <[email-masked]>, B Venkat S.R Swamy/HSS@HSS, [email-masked]

Subject

Re: [Megaco] Baseroot v2 Use case query

Hello Anant,

Regards, Christian

Transaction. Also:

[BVS] IMO, although implementation dependant, another advantage of retranmitting the request even though pending is received,

is in cases where peer entities have a redundant architecture and the switchover is transparent to

other entity. Redundant architecture is such that only stable information is conveyed across redundant

entity and thus possbility of losing the transient information(say a new transaction request).

In this case there is possibility that after sending the pending the switchover happens

and therefore retransmission is required to handle the request again on the entity taking over after switchover.

[/BVS]

[BVS] Retransmission of response does not happen independently, it happens on receiving

the request retransmission from peer entity. This is as per ALF procedure defined in

D.1.1(" The TransactionID of each incoming message is compared to the

TransactionIDs of the recent responses sent to the same MID.

If a match is found, the entity does not execute the transaction, but simply repeats the response").

/BVS]

*********************** FSS-Restricted ***********************

"DISCLAIMER: This message is proprietary to Flextronics Software

Systems Limited (FSS) and is intended solely for the use of the

individual to whom it is addressed. It may contain privileged or

confidential information and should not be circulated or used for

any purpose other than for what it is intended. If you have received

this message in error, please notify the originator immediately.

If you are not the intended recipient, you are notified that you are

strictly prohibited from using, copying, altering, or disclosing

the contents of this message. FSS accepts no responsibility for

loss or damage arising from the use of the information transmitted

by this email including damage from virus."