Subject: [Megaco] Megaco 3-Way Handshake

From: <[email-masked]>
Date: Tue, 6 Feb 2007 09:47:00 +0530

Hi,

I am currently working in a H.248 development project.

As per the ITU-T H.248.1 AnnexD.1.1, the copy of the responses may be
destroyed either LONG-TIMER seconds after the response is isuued, or
when the entity receives a Ack for the response.

Hence we can re-use the same TransId after destroying the Response copy.

But in D.1.2.2 it was stated that the "conformed Transaction ID ranges"
values shall not be used if more than LONG-TIMER seconds have elapsed
since the MG issued its last response to that MGC.

One more question: If we receive a duplicate request with in the
LONG-TIMER seconds from MGC, how the MG should behave.

1.       Resend the reply or

2.       ignore the request

Can anyone please clarify the above.

Thanks & Regards,

Krishna

 

Hi,

I am currently working in a H.248 development project.

As per the ITU-T H.248.1 AnnexD.1.1, the copy of the responses may be
destroyed either LONG-TIMER seconds after the response is isuued, or
when the entity receives a Ack for the response.

Hence we can re-use the same TransId after destroying the Response copy.

But in D.1.2.2 it was stated that the "conformed Transaction ID ranges"
values shall not be used if more than LONG-TIMER seconds have elapsed
since the MG issued its last response to that MGC.

One more question: If we receive a duplicate request with in the
LONG-TIMER seconds from MGC, how the MG should behave.

1.       Resend the reply or

2.       ignore the request

Can anyone please clarify the above.

Thanks & Regards,

Krishna

 

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

---

From: Dheeraj Gupta <[email-masked]>
Date: Tue, 6 Feb 2007 20:57:53 -0800

Hi Krishna,
 
As per AnnexD.1.1 , GW can use the same transaction ID , after it removes
the response on expiry of LONG-TIMER or when it receives a ACK from MGC for
the response it sends to it i.e 3-Way handshake comletes.
 
While AnnexD.1.2.2 says that there is no point for MGC to send ACK for the
response by GW , after expiry of LONG-TIMER as by that time GW must have
deleted the response from its database.
 
MG should ignore the request if it receives the same request within the
LONG-TIMER seconds from MGC.
 
Thanks
Dheeraj

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 05, 2007 8:17 PM
To: [email-masked]
Subject: [Megaco] Megaco 3-Way Handshake

Hi,

As per the ITU-T H.248.1 AnnexD.1.1, the copy of the responses may be
destroyed either LONG-TIMER seconds after the response is isuued, or when
the entity receives a Ack for the response.

But in D.1.2.2 it was stated that the "conformed Transaction ID ranges"
values shall not be used if more than LONG-TIMER seconds have elapsed since
the MG issued its last response to that MGC.

One more question: If we receive a duplicate request with in the LONG-TIMER
seconds from MGC, how the MG should behave.

1.       Resend the reply or

2.       ignore the request

Thanks & Regards,

Krishna

---

From: Sudhanshu Garg <[email-masked]>
Date: Wed, 7 Feb 2007 13:21:51 +0530

Hi,

In my opinion, if the MG receives the same request within the LONG-TIMER 
seconds from MGC,
then there are following two scenarios:
1. MG has received the Response Ack: Here MG should ignore the request
2. MG has not received the Response Ack: Here MG should resend the reply.

Snips from Protocol section D.1.1
        Peer protocol entities are expected to keep in memory a list of 
the responses that they sent to recent
        transactions and a list of the transactions that are currently 
outstanding. The TransactionID of each
        incoming message is compared to the TransactionIDs of the recent 
responses sent to the same MID.
        If a match is found, the entity does not execute the transaction, 
but simply repeats the response.

        The copy of the responses may be destroyed either LONG-TIMER 
seconds after the response is
        issued, or when the entity receives a confirmation that the 
response has been received, through the
        "Response Acknowledgement parameter". For transactions that are 
acknowledged through this
        parameter, the entity shall keep a copy of the TransactionID for 
LONG-TIMER seconds after the
        response is issued, in order to detect and ignore duplicate copies 
of the transaction request that
        could be produced by the network

Regards,
Sudhanshu Garg
Technical Leader
Aricent
Phone:  +91-124-4176333 extn 5109
Fax: +91-124-4176224
web: www.aricent.com

Dheeraj Gupta <[email-masked]> 
02/07/2007 10:27 AM

To
<[email-masked]>, <[email-masked]>
cc

Subject
RE: [Megaco] Megaco 3-Way Handshake

Hi Krishna,
 
As per AnnexD.1.1 , GW can use the same transaction ID , after it removes 
the response on expiry of LONG-TIMER or when it receives a ACK from MGC 
for the response it sends to it i.e 3-Way handshake comletes.

 
Thanks
Dheeraj

Hi,
 
But in D.1.2.2 it was stated that the ?conformed Transaction ID ranges? 

 
Thanks & Regards,
Krishna

 

***********************  Aricent-Private   ***********************
"DISCLAIMER: This message is proprietary to Aricent  and is intended solely for the use of 
the individual to whom it is addressed. It may contain privileged or confidential information and should not be 
circulated or used for any purpose other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for 
loss or damage arising from the use of the information transmitted by this email including damage from virus."
_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Michael DiGioia <[email-masked]>
Date: Tue, 6 Feb 2007 10:57:57 -0800 (PST)

HI,
   
  Yes I believe that you can reuse the TID. But why not recycle the IDs and not reuse them till the existing pool is used up?
   
  I believe that you have to resend the reply (check the timestamp) if still within the timeout period for UDP transports. As long as the ID is the same. Otherwise the MGC will never receive the response since it has already resent the request. 

  /mpd

[email-masked] wrote:        st1\:*{behavior:url(#default#ieooui) }                Hi,
   
  I am currently working in a H.248 development project.
  As per the ITU-T H.248.1 AnnexD.1.1, the copy of the responses may be destroyed either LONG-TIMER seconds after the response is isuued, or when the entity receives a Ack for the response.
  Hence we can re-use the same TransId after destroying the Response copy.
  But in D.1.2.2 it was stated that the “conformed Transaction ID ranges” values shall not be used if more than LONG-TIMER seconds have elapsed since the MG issued its last response to that MGC.
   
  One more question: If></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;color:windowtext'>As per the ITU-T H.248.1 AnnexD.1.1, the copy =
of the
responses may be destroyed either LONG-TIMER seconds after the response =
is
isuued, or when the entity receives a Ack for the =
response.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;color:windowtext'>Hence we can re-use the same TransId after =
destroying
the Response copy.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;color:windowtext'>But in D.1.2.2 it was stated that the =
&#8220;conformed
Transaction ID ranges&#8221; values shall not be used if more than =
LONG-TIMER
seconds have elapsed since the MG issued its last response to that =
MGC.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;color:windowtext'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;color:windowtext'>One more question: If we receive a duplicate =
request
with in the LONG-TIMER seconds from MGC, how the MG should =
behave.<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:1.75in;text-indent:-.25in;mso-list:l0 level1 =
lfo2'><![if !supportLists]><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;color:windowtext'><span
style=3D'mso-list:Ignore'>1.<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;color:windowtext'>Resend the
reply or<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:1.75in;text-indent:-.25in;mso-list:l0 level1 =
lfo2'><![if !supportLists]><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;color:windowtext'><span
style=3D'mso-list:Ignore'>2.<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></span></font><![endif]><font
size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;color:windowtext'>ignore the
request<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;color:windowtext'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;color:windowtext'>Can anyone please clarify the =
above.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;color:windowtext'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;color:windowtext'>Thanks &amp; =
Regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><st1:place w:st=3D"on"><font size=3D2 color=3Dblack =
face=3DArial><span
 =
style=3D'font-size:10.0pt;color:windowtext'>Krishna</span></font></st1:pl=
ace><font
size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;color:windowtext'><o:p></o:p></span></font></p>=

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;color:windowtext'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;color:windowtext'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;color:windowtext'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:1.5in'><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;color:windowtext'><o:p>&nbsp;</o:p></span></fon=
t></p>

<p class=3DMsoNormal><font size=3D2 we receive a duplicate request with in the LONG-TIMER seconds from MGC, how the MG should behave.
  1.       Resend the reply or
  2.       ignore the request

  Thanks & Regards,
  Krishna

 
---------------------------------
Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.

---

From: Michael DiGioia <[email-masked]>
Date: Tue, 6 Feb 2007 10:57:57 -0800 (PST)

HI,

  /mpd

   
  One more question: If <div class=MsoNormal><FONT face=Arial color=black size=2><SPAN style="FONT-SIZE: 10pt; COLOR: windowtext">One more question: If we receive a duplicate request with in the LONG-TIMER seconds from MGC, how the MG should behave.<o:p></o:p></SPAN></FONT></div>  <div class=MsoNormal style="MARGIN-LEFT: 1.75in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo1"><FONT face=Arial color=black size=2><SPAN style="FONT-SIZE: 10pt; COLOR: windowtext"><SPAN style="mso-list:

<hr size=1>Finding fabulous fares is fun.<br><a href="http://farechase.yahoo.com/promo-generic-14795097;_ylc=X3oDMTFtNW45amVpBF9TAzk3NDA3NTg5BF9zAzI3MTk0ODEEcG9zAzEEc2VjA21haWx0YWdsaW5lBHNsawNxMS0wNw--
">Let Yahoo! FareChase search your favorite travel sites</a> to find flight and hotel bargains.

---

From: Michael DiGioia <[email-masked]>
Date: Tue, 6 Feb 2007 21:48:43 -0800 (PST)

Dheeraj,
   
  I believe MG received the request twice from the same MGC within the LONG-TIMER, we must assume no response was received  by the MGC to this request and must resend. If an ACK was received by the MG, then ignore the second request.
   
  /mpd

Dheeraj Gupta <[email-masked]> wrote:
        st1\:*{behavior:url(#default#ieooui) }              Hi Krishna,
   
  As per AnnexD.1.1 , GW can use the same transaction ID , after it removes the response on expiry of LONG-TIMER or when it receives a ACK from MGC for the response it sends to it i.e 3-Way handshake comletes.
   
  While AnnexD.1.2.2 says that there is no point for MGC to send ACK for the response by GW , after expiry of LONG-TIMER as by that time GW must have deleted the response from its database.
   
  MG should ignore the request if it receives the same request within the LONG-TIMER seconds from MGC.
   
  Thanks
  Dheeraj

  
    Hi,

  One more question: If we receive a duplicate request with in the LONG-TIMER seconds from MGC, how the MG should behave.
  1.       Resend the reply or
  2.       ignore the request

  Thanks & Regards,
  Krishna

 
---------------------------------
Want to start your own business? Learn how on Yahoo! Small Business.

---

From: Michael DiGioia <[email-masked]>
Date: Wed, 7 Feb 2007 09:41:34 -0800 (PST)

Correct! I agree.
   
  /mpd

Sudhanshu Garg <[email-masked]> wrote:
  
Hi, 

In my opinion, if the MG receives the same request within the LONG-TIMER seconds from MGC, 
then there are following two scenarios: 
1. MG has received the Response Ack: Here MG should ignore the request 
2. MG has not received the Response Ack: Here MG should resend the reply.

Snips from Protocol section D.1.1 
        Peer protocol entities are expected to keep in memory a list of the responses that they sent to recent 
        transactions and a list of the transactions that are currently outstanding. The TransactionID of each 
        incoming message is compared to the TransactionIDs of the recent responses sent to the same MID. 
        If a match is found, the entity does not execute the transaction, but simply repeats the response. 

        The copy of the responses may be destroyed either LONG-TIMER seconds after the response is 
        issued, or when the entity receives a confirmation that the response has been received, through the 
        "Response Acknowledgement parameter". For transactions that are acknowledged through this 
        parameter, the entity shall keep a copy of the TransactionID for LONG-TIMER seconds after the 
        response is issued, in order to detect and ignore duplicate copies of the transaction request that 
        could be produced by the network

Regards,
Sudhanshu Garg
Technical Leader
Aricent

        Dheeraj Gupta <[email-masked]>   02/07/2007 10:27 AM 

            To
  <[email-masked]>, <[email-masked]>       cc
        Subject
  RE: [Megaco] Megaco 3-Way Handshake

Hi Krishna, 

  
  
Thanks 
Dheeraj 

Hi, 

  
  
Thanks & Regards, 
Krishna 

  

***********************  Aricent-Private   ***********************         
"DISCLAIMER: This message is proprietary to Aricent  and is intended solely for the use of   the individual to whom it is addressed. It may contain privileged or confidential information and should not be   circulated or used for any purpose other than for what it is intended. If you have received this message in error,   please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly  prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for   loss or damage arising from the use of the information transmitted by this email including damage from virus."  
_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---------------------------------
Don't get soaked.  Take a quick peak at the forecast 
 with theYahoo! Search weather shortcut.