Query Regarding Long Timer in conjuction with HandOff in H.248

That's the crucial part: 

>If the service 
> relationship with the sending MGC has ended, the replies 
> should be discarded. 

The H.248 CA with MGC1 does not exist anymore after step 4.


> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Ginotra, Rajiv
> Sent: Dienstag, 9. Februar 2010 07:21
> To: [email protected]
> Cc: sushil kumar
> Subject: Re: [Megaco] Megaco Digest, Vol 70, Issue 4
> 
> Hi Sushil,
> 
> I have some good text regarding the below question from the 
> Megaco ITU-T specs.
> 
> "When the MGC initiates a handoff, the handover should be 
> transparent to operations on the Media Gateway. Transactions 
> can be executed in any order, and could be in progress when 
> the ServiceChange is executed.
> Accordingly, commands in progress continue and replies to all 
> commands from the original MGC must be sent to the transport 
> address from which they were sent. If the service 
> relationship with the sending MGC has ended, the replies 
> should be discarded. The MG may receive outstanding 
> transaction replies from the new MGC. No new messages shall 
> be sent to the new MGC until the control association is 
> established. Repeated transaction requests shall be directed 
> to the new MGC. The MG shall maintain the state of all 
> terminations and contexts."
> 
> Regards,
> Rajiv
> 
> 
> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of [email protected]
> Sent: Monday, February 08, 2010 9:44 PM
> To: [email protected]
> Subject: Megaco Digest, Vol 70, Issue 4
> 
> If you have received this digest without all the individual 
> message attachments you will need to update your digest 
> options in your list subscription.  To do so, go to 
> 
> https://www.ietf.org/mailman/listinfo/megaco
> 
> Click the 'Unsubscribe or edit options' button, log in, and 
> set "Get MIME or Plain Text Digests?" to MIME.  You can set 
> this option globally for all the list digests you receive at 
> this point.
> 
> 
> 
> Send Megaco mailing list submissions to
> 	[email protected]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.ietf.org/mailman/listinfo/megaco
> or, via email, send a message with subject or body 'help' to
> 	[email protected]
> 
> You can reach the person managing the list at
> 	[email protected]
> 
> When replying, please edit your Subject line so it is more 
> specific than "Re: Contents of Megaco digest..."
> 
> 
> Today's Topics:
> 
>    1. Query Regarding Long Timer in conjuction with HandOff in
>       H.248 (sushil kumar)
>    2. Query Regarding Long Timer in conjuction with HandOff in
>       H.248 (sushil kumar)
>    3. Re: Query Regarding Long Timer in conjuction with HandOff
>       inH.248 (Schwarz Albrecht)
>    4. MGCP question? (John Wainwright)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 8 Feb 2010 14:44:40 +0530
> From: "sushil kumar" <[email protected]>
> Subject: [Megaco] Query Regarding Long Timer in conjuction with
> 	HandOff in	H.248
> To: <[email protected]>
> Message-ID: <007801caa89f$2616df20$72449d60$@com>
> Content-Type: text/plain; charset="us-ascii"
> 
> Hi All,
> 
> I need a help , what should be the behavior of MG (H.248 
> Protocol) in following scenario:-
> 
> 1. MGC1 established association with MG 
> 
> 2. MGC1 initiate Add 1 request towards MG with transaction 
> ID(let transactionID be 2)
> 
> 3. MG responded the Add request and should keep a copy of it 
> for 30 sec (LONG Timer ) so that it can response back if same 
> transaction request comes again.
> 
> 4. Now MGC1 initiate handoff towards MGC2 (upto this point 
> LONG timer did not expire ) .
> 
> 5. MGC2 established association with MG(upto this point LONG 
> timer did not expire ) .
> 
> 6. Now MGC2 initiate Add 2  request towards MG with 
> transaction ID 1( same as above) and still LONG Timer did not expire.
> 
> What should be the expected response from MG ?
> 
> i) Should it reply this Add2 request?
> 
>     Or
> 
> ii) should in response of this request (having same 
> transaction Id  and Long timer did not expire ) MG  should 
> return the same response which it saved already?
> 
> Currently it respond with the OLD response which it already saved .
> 
> Please find the attached call flow for reference.
> 
> Thanks in advance !!
> 
> Regards
> 
> Sushil
> 
>  
> 
>  
> 
>  
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://www.ietf.org/mail-archive/web/megaco/attachments/20100
208/2d4b48
> aa/attachment.htm>
> 
> ------------------------------
> 
> Message: 2
> Date: Mon, 8 Feb 2010 16:42:25 +0530
> From: "sushil kumar" <[email protected]>
> Subject: [Megaco] Query Regarding Long Timer in conjuction with
> 	HandOff in	H.248
> To: <[email protected]>
> Message-ID: <008e01caa8af$98e33250$caa996f0$@com>
> Content-Type: text/plain; charset="us-ascii"
> 
>  
> 
> Hi All,
> 
> I need a help , what should be the behavior of MG (H.248 
> Protocol) in following scenario:-
> 
> 1. MGC1 established association with MG 
> 
> 2. MGC1 initiate Add 1 request towards MG with transaction 
> ID(let transactionID be 2)
> 
> 3. MG responded the Add request and should keep a copy of it 
> for 30 sec (LONG Timer ) so that it can response back if same 
> transaction request comes again.
> 
> 4. Now MGC1 initiate handoff towards MGC2 (upto this point 
> LONG timer did not expire ) .
> 
> 5. MGC2 established association with MG(upto this point LONG 
> timer did not expire ) .
> 
> 6. Now MGC2 initiate Add 2  request towards MG with 
> transaction ID 1( same as above) and still LONG Timer did not expire.
> 
> What should be the expected response from MG ?
> 
> i) Should it reply this Add2 request?
> 
>     Or
> 
> ii) should in response of this request (having same 
> transaction Id  and Long timer did not expire ) MG  should 
> return the same response which it saved already?
> 
> Currently it respond with the OLD response which it already saved .
> 
> Please find the attached call flow for reference.
> 
> Thanks in advance !!
> 
> Regards
> 
> Sushil
> 
>  
> 
>  
> 
>  
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://www.ietf.org/mail-archive/web/megaco/attachments/20100
208/403159
> d5/attachment.htm>
> 
> ------------------------------
> 
> Message: 3
> Date: Mon, 8 Feb 2010 15:15:08 +0100
> From: "Schwarz Albrecht" <[email protected]>
> Subject: Re: [Megaco] Query Regarding Long Timer in conjuction with
> 	HandOff	inH.248
> To: "sushil kumar" <[email protected]>, <[email protected]>
> Message-ID:
> 	
> <[email protected]
lcatel.com
> >
> 	
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Your scenario might be too high level, thus I may just guess:
>  
> You know that there is just a single H.248 Control 
> Association (CA) from MG perspective (a PMG or VMG).
> Thus, the initial CA (with MGC1) does NOT exist anymore after 
> the successfull changeover procedure (via handoff) to MGC2.
>  
> Please don't forget that the 2nd CA is different to the 1st 
> CA (due to different MGC instances), see e.g.
> ITU-T H.Sup7, ? 5.2 Constitution of a Control Association.
>  
>  
> Thus, any OLD responses from the CA with MGC1 are meaningless 
> at the new CA with MGC2.
> Both MGC entities must use a different MID anyway.
>  
>  
> 
> 
> ________________________________
> 
> 	From: [email protected] 
> [mailto:[email protected]] On Behalf Of sushil kumar
> 	Sent: Montag, 8. Februar 2010 12:12
> 	To: [email protected]
> 	Subject: [Megaco] Query Regarding Long Timer in 
> conjuction with HandOff inH.248
> 	
> 	
> 
> 	 
> 
> 	Hi All,
> 
> 	I need a help , what should be the behavior of MG (H.248
> Protocol) in following scenario:-
> 
> 	1. MGC1 established association with MG 
> 
> 	2. MGC1 initiate Add 1 request towards MG with 
> transaction ID(let transactionID be 2)
> 
> 	3. MG responded the Add request and should keep a copy 
> of it for 30 sec (LONG Timer ) so that it can response back 
> if same transaction request comes again.
> 
> 	4. Now MGC1 initiate handoff towards MGC2 (upto this 
> point LONG timer did not expire ) .
> 
> 	5. MGC2 established association with MG(upto this point 
> LONG timer did not expire ) .
> 
> 	6. Now MGC2 initiate Add 2  request towards MG with 
> transaction ID 1( same as above) and still LONG Timer did not expire.
> 
> 	What should be the expected response from MG ?
> 
> 	i) Should it reply this Add2 request?
> 
> 	    Or
> 
> 	ii) should in response of this request (having same 
> transaction Id  and Long timer did not expire ) MG  should 
> return the same response which it saved already?
> 
> 	Currently it respond with the OLD response which it 
> already saved .
> 
> 	Please find the attached call flow for reference.
> 
> 	Thanks in advance !!
> 
> 	Regards
> 
> 	Sushil
> 
> 	 
> 
> 	 
> 
> 	 
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://www.ietf.org/mail-archive/web/megaco/attachments/20100
208/05a9ce
> 89/attachment.htm>
> 
> ------------------------------
> 
> Message: 4
> Date: Mon, 8 Feb 2010 10:14:58 -0600
> From: "John Wainwright" <[email protected]>
> Subject: [Megaco] MGCP question?
> To: <[email protected]>
> Message-ID:
> 	<[email protected]>
> Content-Type: text/plain; charset="us-ascii"
> 
> I know this is a Megaco forum but I was hoping someone could 
> help me with an MGCP question since the 2 protocols are 
> similar in many ways.
> 
> If a gateway receive the following from its Call Agent
> 
> RQNT 39086638 phone/1@[1.2.3.4] MGCP 1.0
> 
> X: 1
> 
> R: L/HU(N)
> 
> S:
> 
> Q: STEP
> 
> T: L/HU,L/HD,L/HF,D/[0-9A-D#*T]
> 
>  
> 
> When it detects a HookFlash event should this be immediately 
> reported since it is in the Detect Events parameter (T) or 
> should it be ignored because it is not in the Requested 
> Events parameter (R) ?  My confusion arises out of when 
> DetectEvents type events are reported as opposed to 
> RequestedEvents type events in cases such as this.
> 
> Thanks
> 
> John
> 
> 
> ****************************************
> The information contained in this message may be 
> confidential, privileged or protected from disclosure. If you 
> have received it by mistake, please let us know by e-mail 
> reply and delete it from your system; you may not copy, 
> disseminate or disclose the contents of this message to anyone.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://www.ietf.org/mail-archive/web/megaco/attachments/20100
208/00b290
> 0e/attachment.htm>
> 
> ------------------------------
> 
> _______________________________________________
> Megaco mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/megaco
> 
> 
> End of Megaco Digest, Vol 70, Issue 4
> *************************************
> _______________________________________________
> Megaco mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/megaco
>