Subject: [Megaco] C-289: H.248.36 extension for MG autonomous garbage collection

From: "Schwarz Albrecht" <[email-masked]>
Date: Fri, 22 Jun 2007 13:10:03 +0200

In order to save meeting time, also some initial questions in advance: 
Like to better understand your considered use case and problem.
A) MGC loss of internal data record for a TDM termination (T2) in a
non-NULL Context?
or
B) Loss of Subtract.request or .reply at the H.248 CA? 
Guess we may exclude (B).
There'll be a hanging termination T2 in C1 on MG level in case of (A).
Right?
However, T2 may be detected by the MGC, either
1) by the next resource reservation request (-> ADD.request T2), which
will be replied with an error code, or
2) in case of enabled and occurred events (-> NOTIFY.request).
Apart from the
3) auditing possibity by the MGC.
I wouldn't even enable the event hangterm/thb for phyical terminations,
due to detection capability (1).
Of course, (1) implies a "garbage collection" action by the MGC by a
SUBTRACT.request T2.
Which should be sufficient for implementations with a very low
probability of hanging physical terminations.
Thus, I'm questioning the proposed extension for an "MG autonomous
garbage collection" mechanism for such situations.
Even with such an extended garbage collection method, you may not avoid
situation (1) (i.e. timerx is not yet expired, but new ADD.req T2). I do
understand your proposal in that way, that the MG should internally
subtract T2, release C1, and add T2 in the new context. Right?

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

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Fri, 22 Jun 2007 14:36:54 +0200

Hi,
like to understand the difference between an (IP, ATM) TERMINATION
resource and an (IP, ATM) BEARER resource from H.248.32 point of view.
Q1: This package did so far consider only MG-INTERNAL resource
components, - is "bearer" defined as an external resource?
 
Q2: You propose to report a threshold-based occupance level of a
"bearer" via dcr/conrep. Did you consider also nt/qualert, which
provides also threshold-based occupance level reporting mechanism in my
understanding?

Thanks 
Albrecht

---

From: [email-masked]
Date: Sat, 23 Jun 2007 11:46:48 +0800

I am glad to receive your mail of C-289.

I think the main issue is the situation and its probability, and I agree 
with you it is a very low probability of hanging physical terminations in 
normal situation and  MGC can use three method to delete "garbage 
termination".

But there are still some situation which will cause a huge probability of 
hanging physical terminations, such as  the signalling link between MGC 
and MGW is broken for a short while, other internal failure of MGC. 

In any case, it is better to enable the new reservation request to  return 
OK immediately, and  ONLY the termination of TDM type exist this problem, 
so we suggest use this extention to correct it. 

I have answer your question with the beginning of the line //ningdz:

thanks
ningdongzi

"Schwarz Albrecht" <[email-masked]>

2007-06-22 19:10
 
        收件人：        <[email-masked]>, <[email-masked]>
        抄送：  <[email-masked]>
        主题：  C-289: H.248.36 extension for MG autonomous garbage 
collection

In order to save meeting time, also some initial questions in advance: 
Like to better understand your considered use case and problem. 
A) MGC loss of internal data record for a TDM termination (T2) in a 
non-NULL Context? 
or 
B) Loss of Subtract.request or .reply at the H.248 CA? 
Guess we may exclude (B). 
There'll be a hanging termination T2 in C1 on MG level in case of (A). 
Right? 
//ningdz:it is right.
However, T2 may be detected by the MGC, either 
1) by the next resource reservation request (-> ADD.request T2), which 
will be replied with an error code, or 
2) in case of enabled and occurred events (-> NOTIFY.request). 
Apart from the 
3) auditing possibity by the MGC. 
I wouldn't even enable the event hangterm/thb for phyical terminations, 
due to detection capability (1). 
Of course, (1) implies a "garbage collection" action by the MGC by a 
SUBTRACT.request T2. 
Which should be sufficient for implementations with a very low probability 
of hanging physical terminations.
//ningdz: details as above 
Thus, I'm questioning the proposed extension for an "MG autonomous garbage 
collection" mechanism for such situations. 
Even with such an extended garbage collection method, you may not avoid 
situation (1) (i.e. timerx is not yet expired, but new ADD.req T2). 
//ningdz: when timerx is not expired, just stop it and notify the MGC,then 
do as you write below. 
I do understand your proposal in that way, that the MG should internally 
subtract T2, release C1, and add T2 in the new context. Right?
//ningdz: it is right.
Thanks 
Albrecht