Subject: [Megaco] Tracking Abandoned Contexts

From: "Alon Tal" <[email-masked]>
Date: Tue, 7 Feb 2006 10:15:17 +0200

Is there any accepted (or mandated) standard on deciding when a Megaco
context has been abandoned?

For example:
  1) A termination is added to a context
  2) The connection between the MG and MGC _silently_ dies.
  3) No SUBTRACT can thus arrive to the MG.

Will the MG then need to keep the context around forever? 

What is the accepted behavior? Expect a periodic message as a keepalive,
and drop the 
context after a certain period without any new messages? 
If so, what would a reasonable period of that keepalive-timeout be?

Thanks,
Alon

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

---

From: "Anant Kumar \(anant\)" <[email-masked]>
Date: Wed, 8 Feb 2006 00:43:41 -0800

That would be a fair assumption. From what I understand of H.248 procedures and to paraphrase what Kevin explains below,  the only case where it would be safe to assume that all contexts and ephemerals are destroyed would be when the MG sends a method=restart and reason = cold boot.

-anant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of FCG SHI Hao
Sent: Tuesday, February 07, 2006 7:19 PM
To: [email-masked]
Subject: 答复: [Megaco] Tracking Abandoned Contexts

How does MG notify MGC that current procedure is a Cold Boot? Is it to use the ServiceChangeReason "901 Cold Boot"?
ServiceChangeMethod and ServiceChangeReason are different parameters. They can have all kinds of combinations, such as "Restart" with "901 Cold Boot",  "Restart" with "902 Warm Boot" or "Restart" with "900 Service Restored". My question is whether these ServiceChangeReason are meanful for current process and whether MGC should judge these reasons to get which kind operation MG is doing or have done. I think if MGC receives a ServiceChange "Restart" with Reason "902 Warm Boot", it should not assume MG has destroyed all the contexts and ephemerals.

-----原始邮件-----
发件人: [email-masked] [mailto:[email-masked]]代表
Kevin Boyle
发送时间: 2006年2月8日 1:14
收件人: Alon Tal; [email-masked]
主题: RE: [Megaco] Tracking Abandoned Contexts

Until such time as the MG receives a Subtract Command in an established control association with the primary or a secondary MGC, yes, the context must be maintained.  MGs may not autonomously destroy ephemerals or contexts. The exception to this is a Cold Boot, at which time all contexts and ephemerals are deemed to have been destroyed.

As for "keepalives", there are many ways to achieve this function.  From the MGC to the MG, there are a number of "no-op" kinds of messages that can be used, though the most popular by my experience is an empty Audit on Root.  From the MG to the MGC, H.248.14 specifies a package and methodology that the MG can use to check its link state to the MGC.

Kevin 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alon Tal
Sent: Tuesday, February 07, 2006 3:15 AM
To: [email-masked]
Subject: [Megaco] Tracking Abandoned Contexts

Is there any accepted (or mandated) standard on deciding when a Megaco context has been abandoned?

For example:

What is the accepted behavior? Expect a periodic message as a keepalive, and drop the context after a certain period without any new messages? 
If so, what would a reasonable period of that keepalive-timeout be?

Thanks,
Alon

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 8 Feb 2006 14:05:09 -0500

ServiceChangeReason is  mandatory, and it needs to be considered in
conjunction with ServiceChangeMethod.

The only time the MGC can assume loss of ephemerals/contexts is when the
MGC receives a Restart with 901 on Root.

Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Anant Kumar (anant)
Sent: Wednesday, February 08, 2006 3:44 AM
To: FCG SHI Hao; [email-masked]
Subject: RE: [Megaco] Tracking Abandoned Contexts

That would be a fair assumption. From what I understand of H.248
procedures and to paraphrase what Kevin explains below,  the only case
where it would be safe to assume that all contexts and ephemerals are
destroyed would be when the MG sends a method=restart and reason = cold
boot.

-anant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of FCG SHI Hao
Sent: Tuesday, February 07, 2006 7:19 PM
To: [email-masked]
Subject: ��: [Megaco] Tracking Abandoned Contexts

How does MG notify MGC that current procedure is a Cold Boot? Is it to
use the ServiceChangeReason "901 Cold Boot"?
ServiceChangeMethod and ServiceChangeReason are different parameters.
They can have all kinds of combinations, such as "Restart" with "901
Cold Boot",  "Restart" with "902 Warm Boot" or "Restart" with "900
Service Restored". My question is whether these ServiceChangeReason are
meanful for current process and whether MGC should judge these reasons
to get which kind operation MG is doing or have done. I think if MGC
receives a ServiceChange "Restart" with Reason "902 Warm Boot", it
should not assume MG has destroyed all the contexts and ephemerals.

-----ԭʼ�ʼ�-----
������: [email-masked] [mailto:[email-masked]]����
Kevin Boyle
����ʱ��: 2006��2��8�� 1:14
�ռ���: Alon Tal; [email-masked]
����: RE: [Megaco] Tracking Abandoned Contexts

Until such time as the MG receives a Subtract Command in an established
control association with the primary or a secondary MGC, yes, the
context must be maintained.  MGs may not autonomously destroy ephemerals
or contexts. The exception to this is a Cold Boot, at which time all
contexts and ephemerals are deemed to have been destroyed.

As for "keepalives", there are many ways to achieve this function.  From
the MGC to the MG, there are a number of "no-op" kinds of messages that
can be used, though the most popular by my experience is an empty Audit
on Root.  From the MG to the MGC, H.248.14 specifies a package and
methodology that the MG can use to check its link state to the MGC.

Kevin 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Alon Tal
Sent: Tuesday, February 07, 2006 3:15 AM
To: [email-masked]
Subject: [Megaco] Tracking Abandoned Contexts

For example:

What is the accepted behavior? Expect a periodic message as a keepalive,
and drop the context after a certain period without any new messages? 
If so, what would a reasonable period of that keepalive-timeout be?

Thanks,
Alon