headers
Mahesh | 3 Jan 2005 11:15
Favicon

MGProvisionalResponsetimer

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 )

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 .

 

 

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 .

 

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 .

 

With regards

Mahesh

 

 

 

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
Permalink | Reply | 11 comments |
headers
sudgarg | 3 Jan 2005 13:31

Re: MGProvisionalResponsetimer


Hi Mahesh,

Please see my responses inline

Regards,
Sudhanshu
Hughes Software Systems
www.hssworld.com

                                                                          
             "Mahesh"                                                     
             <mahesh <at> ccpu.com>                                            
             Sent by:                                                   To
             megaco-bounces <at> ie         <megaco <at> ietf.org>                  
             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
Megaco <at> ietf.org
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."
Permalink | Reply | 10 comments |
headers
Mahesh | 4 Jan 2005 07:59
Favicon

RE: MGProvisionalResponsetimer

HI ,
I have some more queries related to the topic .

1) If we have to retransmit the message from MGC side when
normalMGExecutionTime timer times out , what will happen to the old
retransmission algorithm , which calculates the retransmission intervals
.Also from the MG side what MG has to with the old algorithm for sending
provisional responses .

With regards
Mahesh

-----Original Message-----
From: Nagaraj Holla [mailto:rnholla <at> infosys.com] 
Sent: Tuesday, January 04, 2005 12:05 PM
To: sudgarg <at> hssworld.com
Cc: Mahesh; megaco <at> ietf.org
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.

sudgarg <at> hssworld.com wrote:

>
>
>
>
>
> Hi Mahesh,
>
> Please see my responses inline
>
> Regards,
> Sudhanshu
> Hughes Software Systems
> www.hssworld.com
>
>
>                                                                          
>
>              "Mahesh"                                                    
>
>              <mahesh <at> ccpu.com>                                           
>
>              Sent 
> by:                                                   To
>
>              megaco-bounces <at> ie         <megaco <at> ietf.org>                 
>
>              
> 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
> Megaco <at> ietf.org
> 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
> Megaco <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>
Permalink | Reply | 0 comments |
headers
Nagaraj Holla | 4 Jan 2005 07:34
Favicon

Re: 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.

sudgarg <at> hssworld.com wrote:

>
>
>
>
>
> Hi Mahesh,
>
> Please see my responses inline
>
> Regards,
> Sudhanshu
> Hughes Software Systems
> www.hssworld.com
>
>
>                                                                          
>
>              "Mahesh"                                                    
>
>              <mahesh <at> ccpu.com>                                           
>
>              Sent 
> by:                                                   To
>
>              megaco-bounces <at> ie         <megaco <at> ietf.org>                 
>
>              
> 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
> Megaco <at> ietf.org
> 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
> Megaco <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>
Permalink | Reply | 9 comments |
headers
Rajeev K R | 4 Jan 2005 09:00
Favicon

RE: 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: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of
Nagaraj Holla
Sent: Tuesday, January 04, 2005 2:35 PM
To: sudgarg <at> hssworld.com
Cc: megaco <at> ietf.org
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.

sudgarg <at> hssworld.com wrote:

>
>
>
>
>
> Hi Mahesh,
>
> Please see my responses inline
>
> Regards,
> Sudhanshu
> Hughes Software Systems
> www.hssworld.com
>
>
>                                                                          
>
>              "Mahesh"                                                    
>
>              <mahesh <at> ccpu.com>                                           
>
>              Sent 
> by:                                                   To
>
>              megaco-bounces <at> ie         <megaco <at> ietf.org>                 
>
>              
> 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
> Megaco <at> ietf.org
> 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
> Megaco <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
Permalink | Reply | 7 comments |
headers
Mahesh | 4 Jan 2005 10:36
Favicon

RE: 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: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of
Rajeev K R
Sent: Tuesday, January 04, 2005 1:30 PM
To: megaco <at> ietf.org
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: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of
Nagaraj Holla
Sent: Tuesday, January 04, 2005 2:35 PM
To: sudgarg <at> hssworld.com
Cc: megaco <at> ietf.org
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.

sudgarg <at> hssworld.com wrote:

>
>
>
>
>
> Hi Mahesh,
>
> Please see my responses inline
>
> Regards,
> Sudhanshu
> Hughes Software Systems
> www.hssworld.com
>
>
>                                                                          
>
>              "Mahesh"                                                    
>
>              <mahesh <at> ccpu.com>                                           
>
>              Sent 
> by:                                                   To
>
>              megaco-bounces <at> ie         <megaco <at> ietf.org>                 
>
>              
> 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
> Megaco <at> ietf.org
> 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
> Megaco <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
Permalink | Reply | 4 comments |
headers
Naylor, Bob | 4 Jan 2005 14:06

Open source Megaco MGC?

Hello,

Is anyone aware of an open source MGC implementation?
If not, can anyone point me to commercial implementations available?

Thanks,
Bob Naylor
Permalink | Reply | 1 comment |
headers
sudgarg | 4 Jan 2005 15:18

RE: MGProvisionalResponsetimer


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"                                                      
             <mahesh <at> ccpu.com>                                             
             Sent by:                                                   To 
             megaco-bounces <at> ie         "'Rajeev K R'" <rajeev <at> huawei.com>, 
             tf.org                    <megaco <at> ietf.org>                   
                                                                        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: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of
Rajeev K R
Sent: Tuesday, January 04, 2005 1:30 PM
To: megaco <at> ietf.org
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: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of
Nagaraj Holla
Sent: Tuesday, January 04, 2005 2:35 PM
To: sudgarg <at> hssworld.com
Cc: megaco <at> ietf.org
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.

sudgarg <at> hssworld.com wrote:

>
>
>
>
>
> Hi Mahesh,
>
> Please see my responses inline
>
> Regards,
> Sudhanshu
> Hughes Software Systems
> www.hssworld.com
>
>
>
>
>              "Mahesh"
>
>              <mahesh <at> ccpu.com>
>
>              Sent
> by:                                                   To
>
>              megaco-bounces <at> ie         <megaco <at> ietf.org>
>
>
> 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
> Megaco <at> ietf.org
> 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
> Megaco <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
 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."
Permalink | Reply | 3 comments |
headers
prarch | 5 Jan 2005 03:36
Favicon

Re: MGProvisionalResponsetimer

A new start up company located in New York, NY in VoIP/Telephony software 
space is looking for software architects and developers.

  1.. Network Management Software product architects
  2.. SNMP/MIB architects and developers
  3.. Voice application product architects
  4.. Voice protocol architects and developers
  5.. Application GUI architects and developers
  6.. Technical marketing and product engineering
  7.. Sales engineers

Please send your resume to prarch <at> optonline.net

----- Original Message ----- 
From: "Rajeev K R" <rajeev <at> huawei.com>
To: <megaco <at> ietf.org>
Sent: Tuesday, January 04, 2005 3:00 AM
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: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf 
> Of
> Nagaraj Holla
> Sent: Tuesday, January 04, 2005 2:35 PM
> To: sudgarg <at> hssworld.com
> Cc: megaco <at> ietf.org
> 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.
>
>
> sudgarg <at> hssworld.com wrote:
>
>>
>>
>>
>>
>>
>> Hi Mahesh,
>>
>> Please see my responses inline
>>
>> Regards,
>> Sudhanshu
>> Hughes Software Systems
>> www.hssworld.com
>>
>>
>>
>>
>>              "Mahesh"
>>
>>              <mahesh <at> ccpu.com>
>>
>>              Sent
>> by:                                                   To
>>
>>              megaco-bounces <at> ie         <megaco <at> ietf.org>
>>
>>
>> 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
>> Megaco <at> ietf.org
>> 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
>> Megaco <at> ietf.org
>> https://www1.ietf.org/mailman/listinfo/megaco
>>
>
>
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>
>
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>
Permalink | Reply | 0 comments |
headers
prarch | 5 Jan 2005 03:37
Favicon

Re: MGProvisionalResponsetimer

A new start up company located in New York, NY in VoIP/Telephony software 
space is looking for software architects and developers.

  1.. Network Management Software product architects
  2.. SNMP/MIB architects and developers
  3.. Voice application product architects
  4.. Voice protocol architects and developers
  5.. Application GUI architects and developers
  6.. Technical marketing and product engineering
  7.. Sales engineers

Please send your resume to prarch <at> optonline.net

----- Original Message ----- 
From: "Rajeev K R" <rajeev <at> huawei.com>
To: <megaco <at> ietf.org>
Sent: Tuesday, January 04, 2005 3:00 AM
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: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf 
> Of
> Nagaraj Holla
> Sent: Tuesday, January 04, 2005 2:35 PM
> To: sudgarg <at> hssworld.com
> Cc: megaco <at> ietf.org
> 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.
>
>
> sudgarg <at> hssworld.com wrote:
>
>>
>>
>>
>>
>>
>> Hi Mahesh,
>>
>> Please see my responses inline
>>
>> Regards,
>> Sudhanshu
>> Hughes Software Systems
>> www.hssworld.com
>>
>>
>>
>>
>>              "Mahesh"
>>
>>              <mahesh <at> ccpu.com>
>>
>>              Sent
>> by:                                                   To
>>
>>              megaco-bounces <at> ie         <megaco <at> ietf.org>
>>
>>
>> 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
>> Megaco <at> ietf.org
>> 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
>> Megaco <at> ietf.org
>> https://www1.ietf.org/mailman/listinfo/megaco
>>
>
>
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>
>
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>
Permalink | Reply | 0 comments |

Gmane