Re: MG Behavior on getting pending message response from MGCon ITO(Inactivity Timer) timeout

I'm not sure, but this looks like a bug in the MGC implementation. Hm?
Should be corrected first before thinking about subsequent ServiceChange
procedures.
(At least the it/ito-based "MGC-polling by MG" mechanism can't be used
correctly ...)
 


________________________________

	From: [email protected] [mailto:[email protected]]
On Behalf Of Rajiv Ginotra
	Sent: Freitag, 26. Juni 2009 01:48
	To: [email protected]; [email protected]
	Subject: [Megaco] MG Behavior on getting pending message
response from MGCon ITO(Inactivity Timer) timeout
	
	
	Hello All,
	 
	Consider the following scenario:
	When the MG is sending the ITO timeout notify and the MGC sends
the pending message along with IA(Immediate Acknowledgment) in the same
message.
	 
	 
	Question 1: After the ITO transaction retries are  finished,
should MG sends a "909 MGC Impending Failure" service change message to
other MGCs configured in the list or the send a ITO timeout notify with
a new transaction ID.
	 
	Question 2: Does the IA in the above reply from MGC make the
behavior different?
	 
	I have enclosed the call flow for reference
	 
	Regards
	Rajiv
	 
	Call flow
	======
	[1196396 (10 ms)] !/2 [10.78.161.24]:5099 Transaction=2 {
	Context = - {
	Modify = ROOT {
	Events = 1111 {it/ito {mit = 1000}}
	}
	}}
	 
	[10.78.161.24]:5099 [1196396 (10 ms)] !/2 [183.1.13.2]:2965 P =
2{ C = - {mf=ROOT }}
	
	ITO Timeout notify starts and MGC started sending pending
messages:
	
------------------------------------------------------------------------
------------------------------
	 
	[10.78.161.24]:5099 [1197496 (10 ms)] !/2 [183.1.13.2]:2965 T =
538{ C = - {n=ROOT  { oe = 1111 { IT/ITO }  } }}
	 
	[1197503 (10 ms)] !/2 [10.78.161.24]:5099 Reply=538 {IA, C  =  -
{ n=root { Error = 506 {"506"} }}}
	 
	[10.78.161.24]:5099 [1197503 (10 ms)] !/2 [183.1.13.2]:2965
k{537,538}
	 
	[10.78.161.24]:5099 [1198403 (10 ms)] !/2 [183.1.13.2]:2965 T =
539{ C = - {n=ROOT  { oe = 1111 { IT/ITO }  } }}
	 
	[1198408 (10 ms)] !/2 [10.78.161.24]:5099 Reply=539 {IA, C  =  -
{ n=root { Error = 506 {"506"} }}}
	 
	[10.78.161.24]:5099 [1198408 (10 ms)] !/2 [183.1.13.2]:2965
k{539}
	 
	[10.78.161.24]:5099 [1199408 (10 ms)] !/2 [183.1.13.2]:2965 T =
540{ C = - {n=ROOT  { oe = 1111 { IT/ITO }  } }}
	 
	[1199412 (10 ms)] !/2 [10.78.161.24]:5099 Reply=540 {IA, C  =  -
{ n=root { Error = 506 {"506"} }}}
	 
	[10.78.161.24]:5099 [1199412 (10 ms)] !/2 [183.1.13.2]:2965
k{540}
	 
	[10.78.161.24]:5099 [1200412 (10 ms)] !/2 [183.1.13.2]:2965 T =
541{ C = - {n=ROOT  { oe = 1111 { IT/ITO }  } }}
	 
	[1200417 (10 ms)] !/2 [10.78.161.24]:5099 Reply=541 {IA, C  =  -
{ n=root { Error = 506 {"506"} }}}
	 
	[10.78.161.24]:5099 [1200417 (10 ms)] !/2 [183.1.13.2]:2965
k{541}
	 
	Now the ITO retries get finished. what would be the next
transaction???

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