Subject: [Megaco] Baseroot v2 Use case query

From: "Anant Kumar \(anant\)" <[email-masked]>
Date: Tue, 16 May 2006 20:40:41 -0700

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.
Clearly, if/when the final response is received, it will stop the timer
and everything is good. The problem case is when the final response is
not received by the MGC.

In this situation, one of the following 2 cases is true:

Possibility 1: The MG never sent the final response (error/bug).
Possibility 2: The MG sent the response but it was lost in the network.

The question is: what is the behavior (on the MG and the MGC) in this
situation.

1. Should the MGC retransmit the transaction request upon expiry of the
timer mentioned earlier?
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).

Clearly, 2 assumes that possibility 2 was the cause. 1 would apply in
either case.

Any thoughts.
-anant

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

---

From: "B Venkat S.R Swamy" <[email-masked]>
Date: Wed, 17 May 2006 10:48:41 +0530

Hi

pl. find the comments inline [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

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

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

05/17/2006 09:10 AM

To

<[email-masked]>

cc

Subject

[Megaco] Baseroot v2 Use case query

well.

[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]

not received by the MGC.

situation.

timer mentioned earlier?

[BVS] Yes, MGC should re-transmit the request if the timer gets expired and restart

the timer. If the MGC never gets reply of the request, then depending on implementation

it can even clear the association and wait for re-registration or Disconnect method from MG.

Other possiblity is that in V2, pendingLimit feature has been introduced and MGC on receiving

multiple pending can take corrective action itself or should wait for the

Error 506 (“Number of TransactionPendings Exceeded”) from MG.

[/BVS]

TGCP) mandates this).

[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]

either case.

Any thoughts.

-anant

Megaco mailing list

[email-masked]

*********************** 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."