Subject: RE: [Megaco] MGProvisionalResponsetimer

From: "Kevin Boyle" <[email-masked]>
Date: Thu, 6 Jan 2005 13:55:18 -0500

MGCProvisionalResponseTimerValue may be used by the MG to expect a Pending
from the MGC.

Note that once the FIRST Pending to a transaction is set, the entity
receiving the Pending is supposed to switch to a much longer retransmission
timer (since it knows the responder received the message).  This means that
subsequent Pendings do not have to be sent per the ProvRespTimer property.
It can also revert to a longer period between Pendings.

Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jagan Mohan
Sent: Thursday, January 06, 2005 1:53 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Megaco] MGProvisionalResponsetimer

Hi Sudhanshu,

>From the H.248 ITU-T spec,

normalMGExecutionTime -  Settable by the MGC to indicate the interval within
which the MGC expects a response to any transaction from the MG (exclusive
of network delay)

In my opinion, if the MG is still processing the transaction from the MGC
when the normalMGExecutionTime timer expires, the pending response should be
sent immediately.

As Holla mentioned, MGProvisionalResponseTimerValue should be used only on
MGC.

Regards,
Jagan

On Wed, 05 Jan 2005 13:14:55 +0530, Nagaraj Holla <[email-masked]>
wrote:
> Hi Sudanshu,
> 
> I am not sure if this is the correct interpretation. From the H.248.1 
> document, MGProvisionalResponseTimerValue = normalMGExecutionTime + 
> network delay.
> 
> Also, MGProvisionalResponseTimerValue is the time within which the MGC 
> should expect a Provisional Response from MG. Hence it should not be 
> used by the MG.
> 
> Rgds
> holla.
> 
> [email-masked] wrote:
> 
> >
> >
> >
> >
> >
> > Hi All,
> >
> > In my opinion,
> > 1. normalMGExecutiontime should be used by MGC for retransmission 
> > timer calculations and MGProvisionalResponseTimerValue should be 
> > used by MG to send the provisional responses.
> >
> > 2. normalMGExecutiontime should be read only and MGC can get this 
> > value from MG through Audit procedures in order to run a 
> > retransmission timer starting with "normalMGExecutiontime + network 
> > delay" and apply backoff algorithm after that.
> >
> > 3. MG would run a timer for MGProvisionalResponseTimerValue and 
> > should send a provisional response after this time.
> >
> > 4. MGProvisionalResponseTimerValue should be initially set to 
> > normalMGExecutiontime MINUS network delay. However MGC can set this 
> > to a lower value as per its requirements.
> >
> > Lets see the scenario below.
> >
> > Lets take normalMGExecutiontime 200 ms and network Delay 10 ms.
> > 1. MGC knows normalMGExecutiontime with Audit.
> > 2. MGC sends a request at T0 time and starts a re-transmission timer 
> > for 210 ms (normalMGExecutiontime + Network Delay) 3. MG will 
> > receive the request at T0 + 10 ms.
> > 4. If execution at MG is taking more time then, to avoid any 
> > retransmissions from MGC, MG should send a provisional response 
> > on/before
> > T0+200 ms time, so that it reaches MGC before retransmission timer
> > expires
> > (T0 + 210 ms).
> >
> > So MG receives request at T0 + 10 ms and sends provisional response 
> > on/before T0+ (normalMGExecutiontime - Network Delay). It means the 
> > provisional response timer value should be normalMGExecutiontime - 
> > Network Delay or less than that. However care should be taken at MGC 
> > end that MGProvisionalResponseTimerValue is not set to a very low 
> > value which may lead to multiple provisional responses and pending 
> > limit is crossed.
> >
> > Can anybody please comment on this?
> >
> > Regards,
> > Sudhanshu
> > Hughes Software Systems
> > www.hssworld.com
> >
> >
> >
> >
> >
> > "Mahesh"
> >
> > <[email-masked]>
> >              Sent
> > by:                                                   To
> >              megaco-bounces@ie         "'Rajeev K R'"
> > <[email-masked]>,
> >              tf.org
> > <[email-masked]>
> >
> > cc
> >
> >
> >              01/04/2005 03:06
> > Subject
> >              PM                        RE:
> > [Megaco]
> >
> > MGProvisionalResponsetimer
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > HI ,
> >
> > If we are using   normalMGExecutiontime for retransmission
> > What we will have to do with the old retransmission algorithm .
> > We will have two ways for doing the same thing , the retransmission .
> >
> > The draft doesn't tells that when normalMGExecution time expires MGC 
> > has to retransmit .Also the draft doesn't tells , what an MG has to 
> > do on the expiry of the normalMGExecution time (this is  a property 
> > of root termination).
> >
> >
> > Could you please clarify these .
> > With thanks and regards
> > Mahesh
> >
> >
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of Rajeev K R
> > Sent: Tuesday, January 04, 2005 1:30 PM
> > To: [email-masked]
> > Subject: RE: [Megaco] MGProvisionalResponsetimer
> >
> >
> > Hi,
> >
> > I have two questions regading this :
> >
> > 1.
> > In the definition of normalMGExecutionTime, the word "pending" is 
> > not used.
> > <Settable by the MGC to indicate the interval within which the MGC 
> > expects a response to any transaction from the MG (exclusive of 
> > network delay)>.
> >
> > But the definition of MGProvisionalResponseTimerValue clearly states 
> > about pending response. <Indicates the time within which the MGC 
> > should expect a Pending Response from the MG if a Transaction cannot 
> > be completed.>
> >
> > Is this difference really intended? Should normalMGExecutionTime be 
> > taken as the maximum time the MGC allows MG to complete a 
> > transaction? (ie for the final response?)
> >
> >
> > 2.
> > If both these values are for provisional response, then two 
> > different values does not serve any purpose. Since both are settable 
> > by MGC, it would boil down that MG should use the minimum of these 
> > values (adjusting for the network delay) to send the provisional 
> > response. Is this the intented behaviour?  What was the rational 
> > behind having two values which looks like doing the same job?
> >
> >
> > Regards,
> > Rajeev
> >
> >
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of Nagaraj Holla
> > Sent: Tuesday, January 04, 2005 2:35 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: Re: [Megaco] MGProvisionalResponsetimer
> >
> > Hi all,
> >
> > While we are on this subject, I would like a few more calrifications 
> > on the interpretation of these values. From H.248.1 (May-2002) 
> > MGProvisionalResponseTimerValue definition :-
> >
> > <quote>
> > Indicates the time within which the MGC should expect a Pending 
> > Response from the MG if a Transaction cannot be completed. Initially 
> > set to normalMGExecutionTime plus network delay, but may be lowered.
> > <unquote>
> >
> > Now one way we can interpert this value is - 
> > MGProvisionalResponseTimerValue is an indication to MGC within which 
> > it can expect atleast a 'Pending Response' for a given transaction 
> > from the MG.
> >
> > MGProvisionalResponseTimerValue = normalMGExecutionTime + network delay.
> >
> > If normalMGExecutionTime is set on the MG, an implementation on MG 
> > should send a 'Pending Response' to MGC if this timer expires. The 
> > MGProvisionalResponseTimerValue does not make sense on the MG. It 
> > should only be an indication to MGC for the maximum time to wait for 
> > a 'Pending Response' from the MG.
> >
> > To summarize, I think we should use the 
> > 'MG/MGCProvisionalResponseTimerValues' as an *indication only* to 
> > MGC/MG and should not be settable ie., it should be a 'read only'
parameter.
> >
> > Also, is there some kind of 'Use cases' document to substantiate the 
> > implementation of this package [Base Root package-v2]?
> >
> > Rgds
> > holla.
> >
> >
> > [email-masked] wrote:
> >
> > >
> > >
> > >
> > >
> > >
> > > Hi Mahesh,
> > >
> > > Please see my responses inline
> > >
> > > Regards,
> > > Sudhanshu
> > > Hughes Software Systems
> > > www.hssworld.com
> > >
> > >
> > >
> > >
> > >              "Mahesh"
> > >
> > >              <[email-masked]>
> > >
> > >              Sent
> > > by:                                                   To
> > >
> > >              megaco-bounces@ie         <[email-masked]>
> > >
> > >
> > > tf.org                                                     cc
> > >
> > >
> > >
> > >
> > > Subject
> > >
> > >              01/03/2005 03:45          [Megaco]
> > > MGProvisionalResponsetimer
> > >
> > >              PM
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > HI ,
> > >
> > > I would like to get a clarification related to 
> > > MGProvisionalResponseTimerValue and MGCProvisionalResponseTimerValue .
> > >
> > >
> > >
> > > 1)Whether MGC is  setting this value for MG ( through some 
> > > commands , say a modify ) [SG] normalMGExecutionTime, 
> > > normalMGCExecutionTime, MGProvisionalResponseTimerValue, 
> > > MGCProvisionalResponseTimerValue, MGCOriginatedPendingLimit and 
> > > MGOriginatedPendingLimit are
> > properties of
> > > ROOT package defined in annexture E.2 of H.248.1 (05/2002).
> > > These values are settable by MGC so MODIFY with ROOT termination 
> > > should be used to set them.
> > > [/SG]
> > >
> > > 2)What happens when this values is crossed and the entity is not
> > getting
> > > any response .
> > >
> > > Say MGPRovisionalresponse value is crossed and  and MGC is not 
> > > getting any message/reply from mg .
> > > [SG]
> > > One thing could be that MGC retransmits the request and switches 
> > > to a different the retransmission timer value.
> > > For detailed provisional response handling, please refer sections
> > 8.2.3,
> > > Annexture E.2 Base Root Package and ALF procedures.
> > > [/SG]
> > >
> > >
> > >
> > >
> > > 3)If a message is having both  MGProvisionalResponseTimerValue and 
> > > normalMgExecution time .Both of this parameters are
> > >
> > > Having different values , which value we need to  choose for  
> > > MGProvisionalResponseTimerValue , Whether we need to take
> > >
> > > MGProvisionalResponseTimerValue or normalMgExecutionTime .
> > > [SG]
> > > If MGProvisionalResponseTimerValue is present, then it should be
> > used for
> > > sending provisional responses to MGC.
> > > [/SG]
> > >
> > >
> > >
> > > 4)Can we modify  MGProvisionalResponseTimerValue and 
> > > MGCProvisionalResponseTimerValue  on the fly using a
> > >
> > > Modify command  .Also can MG issue a modify command containing 
> > > MGProvisionalResponseTimerValue and MGC 
> > > ProvisionalResponseTimerValueto MG C.
> > >
> > > The reason is, in case of other properties  like pending limit or 
> > > execution time , they are set by MGC , by instructing MG .
> > > [SG]
> > > MGC can modify these values on the fly using a Modify ommand. MG 
> > > can
> > not
> > > issue any modify command to MGC.
> > > All of these properties have read/write characteristics so MGC can 
> > > set any of them.
> > > [/SG]
> > >
> > >
> > >
> > > With regards
> > >
> > > Mahesh
> > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Megaco mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/megaco
> > >
> > >
> > >
> > > ***********************  HSS-Private   ***********************
> > >
> > >
> > > "Please note:  The email domain of Hughes Software Systems Ltd. 
> > > has been changed to "hssworld.com" from hss.hns.com"
> > >
> > > "DISCLAIMER: This message is proprietary to Hughes Software 
> > > Systems Limited (HSS) 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.  HSS  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
> > >
> >
> >
> > _______________________________________________
> > Megaco mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/megaco
> >
> >
> > _______________________________________________
> > Megaco mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/megaco
> >
> >
> >
> > _______________________________________________
> > Megaco mailing list
> > [email-masked]
> >  https://www1.ietf.org/mailman/listinfo/megaco
> >
> >
> >  ***********************  HSS-Private   ***********************
> >
> >
> > "Please note:  The email domain of Hughes Software Systems Ltd. has 
> > been changed to "hssworld.com" from hss.hns.com"
> >
> > "DISCLAIMER: This message is proprietary to Hughes Software Systems 
> > Limited (HSS) 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.  HSS  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
> >
> 
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco
>

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

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

---

From: Rajeev K R <[email-masked]>
Date: Fri, 07 Jan 2005 10:58:33 +0800

Hi Kevin,

Could you please clarify this point also?

What was the rational behind having two values which looks like doing the
same job? (normalMGExecutionTime and MGProvisionalResponseTimerValue)
Do we have any specific instance where one of these was not sufficient to
meet some requirement?

Regards,
Rajeev

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Kevin Boyle
Sent: Friday, January 07, 2005 2:55 AM
To: Jagan Mohan; [email-masked]
Cc: [email-masked]
Subject: RE: [Megaco] MGProvisionalResponsetimer

Kevin

-----Original Message-----

Hi Sudhanshu,

Regards,
Jagan

parameter.
any purpose

---

From: Christian Groves <[email-masked]>
Date: Mon, 10 Jan 2005 13:45:51 +1100

Hello Rajeev,

At the September Q.3 meeting the issues around MGProvisionalResponse timers were 
discussed. An IG correction was accepted.

See section titled: "H.248.1 Provisional Response Timer Clarification"
http://[email-masked]/av-arch/avc-site/2001-2004/0408_San/AVD-2569.zip

Regards, Christian