Re: Query Regarding MG -MGC behavior

The right "MG strategy" is beyond the H.248 protocol itself, because
dependent in engineering networks with regards to service/system
availability.
It is almost impossible to define a single (qualitative) behaviour on a
generic level.
You have to take into account the quantitative performance of your MGC
entitities concering system availability (i.e., the estimated time or
ratio of In-Service periods vs expected Out-of-Service periods).
 
On the highest level you could categorize MGCs (and MGs) in HA-MGC and
LA-MGC implementations (high available vs low available).
 
Assuming that both MGCs got correct H.248 protocol implementations, it
looks like that both MGC entities are rather LA-MGC types in your
example.
That type of info would go into the configuration of timers, number of
reattempts, etc ... and even the EMS/NMS behaviour.
 
-Albrecht
 
 
PS
H.248 does not know the term of a "standby" node, you should rather use
the H.248 terms "primary", "first secondary", etc.
E.g., a primary MGC may itself implemented in a redundant manner (in
order to achieve HA) by an internal architecture with a working &
protection plane. See e.g. Fig. 1/H.Sup7.
 



________________________________

	From: [email protected] [mailto:[email protected]]
On Behalf Of Sushil Kumar
	Sent: Mittwoch, 29. April 2009 10:45
	To: [email protected]
	Subject: [Megaco] Query Regarding MG -MGC behavior
	
	

	Hi All,

	 

	I had a query regarding MG - MGC behavior in H.248

	 

	Scenario is as follows:

	 

	1.       MG  is registered with only one  MGC (say MGC1) and
MGC1 is in redundant mode (i.e. it has a  standby MGC2  )

	2.       MG initiate Service change request "901" towards MGC1
and MGC1 in reply sends handoff to MG with MGCIdToTry = MGC2 .

	3.       MG is now trying to register with MGC2  with message
"903".

	4.       MGC2  ack the service change request from MG and after
that there is no message exchange between MG and  MGC2 and in the mean
time  ITO expired.

	5.       Therefore MG now tries to register again with  MGC1
with service change request  "909 MGC Impending Failure"

	6.       MGC doesn't respond to this serviceChange request. MG
performs  several retry for this above service change request in step 5.


	7.       To this MGC1 sends  error =506 { "Number of
TransactionPendings Exceeded" } 

	8.       Now what should MG do in response to this error ?

	9.       Should MG  again retry to register itself with standby
MGC2 considering its a failed registration attempt ?

	Or

	        In response of this error=506 ,  it should go to Out of
service state considering it as failure in response of service change
request?

	 

	 

	Any help on this is really appreciated.

	 

	Thanks in advance.

	 

	 

	Regards

	Sushil

_______________________________________________
Megaco mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/megaco