Subject: Re: [Megaco] Megaco Digest, Vol 70, Issue 4

From: "Ginotra, Rajiv" <[email-masked]>
Date: Tue, 9 Feb 2010 11:51:12 +0530

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-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Monday, February 08, 2010 9:44 PM
To: [email-masked]
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-masked]

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-masked]

You can reach the person managing the list at
	[email-masked]

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-masked]>
Subject: [Megaco] Query Regarding Long Timer in conjuction with
	HandOff in	H.248
To: <[email-masked]>
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/20100208/2d4b48
aa/attachment.htm>

------------------------------

Message: 2
Date: Mon, 8 Feb 2010 16:42:25 +0530
From: "sushil kumar" <[email-masked]>
Subject: [Megaco] Query Regarding Long Timer in conjuction with
	HandOff in	H.248
To: <[email-masked]>
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/20100208/403159
d5/attachment.htm>

------------------------------

Message: 3
Date: Mon, 8 Feb 2010 15:15:08 +0100
From: "Schwarz Albrecht" <[email-masked]>
Subject: Re: [Megaco] Query Regarding Long Timer in conjuction with
	HandOff	inH.248
To: "sushil kumar" <[email-masked]>, <[email-masked]>
Message-ID:
	
<[email-masked]
	
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-masked] [mailto:[email-masked]]
On Behalf Of sushil kumar
	Sent: Montag, 8. Februar 2010 12:12
	To: [email-masked]
	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/20100208/05a9ce
89/attachment.htm>

------------------------------

Message: 4
Date: Mon, 8 Feb 2010 10:14:58 -0600
From: "John Wainwright" <[email-masked]>
Subject: [Megaco] MGCP question?
To: <[email-masked]>
Message-ID:
	<[email-masked]>
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/20100208/00b290
0e/attachment.htm>

------------------------------

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

End of Megaco Digest, Vol 70, Issue 4
*************************************

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Tue, 9 Feb 2010 10:40:09 +0100

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.

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ginotra, Rajiv
> Sent: Dienstag, 9. Februar 2010 07:21
> To: [email-masked]
> 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
> 
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> 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 
> 
> 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.
> 
> 
> 
> When replying, please edit your Subject line so it is more 
> specific than "Re: Contents of Megaco digest..."
> 
> 
> Today's Topics:
> 
> 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 ) .
> 
> 6. Now MGC2 initiate Add 2  request towards MG with 
> transaction ID 1( same as above) and still LONG Timer did not expire.
> 
> 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?
> 
> 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 ) .
> 
> 6. Now MGC2 initiate Add 2  request towards MG with 
> transaction ID 1( same as above) and still LONG Timer did not expire.
> 
> 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?
> 
> 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.
> Thus, any OLD responses from the CA with MGC1 are meaningless 
> at the new CA with MGC2.
> 	From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of sushil kumar
> 	Subject: [Megaco] Query Regarding Long Timer in 
> conjuction with HandOff inH.248
> 	
> 	
> 
> 	 
> 
> 	Hi All,
> 
> 	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.
> 
> 	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?
> 
> 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.
> 
> 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 
> 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.