Subject: RE : [Megaco] Service Change and Testing

From: "CHATRAS Bruno FTRD/DAC/ISS" <[email-masked]>
Date: Thu, 11 Dec 2003 10:06:03 +0100

Hello,
 
As we are getting close to the next Q3 meeting, I'd like to come kack on this discussion about Sevrice Change and Testing.
 
Actually, there seems to be two issues :
 
1) Need to modify the description of the Service Change procedure to allow the MG to report state transitions when a termination is brought in test and when it is returned to service. Whether the state transation is triggerred by the MGC (i.e. using a modify command) or by the MG (i.e. test activated via a local management interface) is irrelevant to this issue. As this modification does not require any new method, I believe that it could be included in the IG as a clarification to H.248 V2. A new service change reason might need to be registered (e.g. 918 "Term in Test").
 
2) Need to remove the ability to change the Service State in two different competing ways. Beyond making the Service State read-only, this indeed requires a new Method and might be differred to V3, although, I think that there is value in removing competing options as soon as possible.
 
Bruno

-----Message d'origine-----
De : Kevin Boyle [mailto:[email-masked]] 
Envoyé : mercredi 1 octobre 2003 19:44
À : CHATRAS Bruno FTRD/DAC/ISS; [email-masked]
Objet : RE: [Megaco] Service Change and Testing

I have noticed this same discrepancy.  The problem is that the MGC is allowed to set the ServiceStates parm utilizing a Modify command, while the MG has no such capability (it must utilize ServiceChange).  Therefore, there is no way for the MG to set the term into the Test state.
 
In the Annex F work at the most recent Q3 meeting, I raised the idea of restricting the SI parm to being Read-only, and mandating that state changes must utilize ServiceChange (in both directions).  This would also require a new Method to set the term to Test.  The big problem is that this is a change from the current function, and may have to wait until V3 due to the parsing change with the Method parm (unless there is wide acceptance to push this into earlier versions...)
 
This simplifies the termination state model by removing the ability to change the parm in two different, competing ways.  It also provides the MG the capability of setting the term into Test (which I think has value and utility).
 
Comments?
 
Kevin

-----Original Message-----
From: CHATRAS Bruno FTRD/DAC/ISS [mailto:[email-masked]] 
Sent: Wednesday, October 01, 2003 1:06 PM
To: [email-masked]
Subject: [Megaco] Service Change and Testing

Hi,
 
H.248 defines three values for the Termination State descriptor ("in service", "out of service" and "test"). The ServiceChange procedures allows the MG to notify the MGC when a termination is about to be taken out of service (or is being returned to service). It seems that there is not equivalent procedure when a termination is about to be tested (i.e. termination state = test) and is therefore not available for normal traffic. Is there a specific reason for treating these two states differently or is just that the wording "out of service" in the ServiceChange description encompasses both the "test" and "out of service" termination states. If this is the case, I think a clarification in the IG guide might be useful.
 
Regards,
BC

---

From: Christian Groves <[email-masked]>
Date: Fri, 12 Dec 2003 10:11:44 +1100

Hello Bruno and Kevin,

I think there is/was some confusion over what "test state" is. I believe when it 
was added to the protocol it was for the situation of test calls. The MGC 
ordered these test calls thus there was no reason to have the MG indicate this 
through a Servicechange. In "test state" there is no restriction on what the MGC 
can do with the termination.

It seems that people may be using "test state" for more than the example above. 
If we add a ServiceChange reason for test state then we'll have 2 methods of 
changing the state.

With respect to having multiple ways of changing state to "out-of-service" this 
is unfortunate and I agree can be looked at but whatever solution is proposed 
should ensure backwards compatibility. There's not a problem changing 
"out-of-service" to "in-service" because the MGC can't ADD/MOD those terminations.

Bruno: Will you be sending the Tispan: Residential/Access Gateway Profile
Gate Control Profile to Q.3 and Megaco for info/review? People may be interested 
in these.

Regards, Christian

CHATRAS Bruno FTRD/DAC/ISS wrote:

> Hello,
>  
> As we are getting close to the next Q3 meeting, I'd like to come kack on 
> this discussion about Sevrice Change and Testing.
>  
> 1) Need to modify the description of the Service Change procedure to 
> allow the MG to report state transitions when a termination is brought 
> in test and when it is returned to service. Whether the state transation 
> is triggerred by the MGC (i.e. using a modify command) or by the MG 
> (i.e. test activated via a local management interface) is irrelevant to 
> this issue. As this modification does not require any new method, I 
> believe that it could be included in the IG as a clarification to H.248 
> V2. A new service change reason might need to be registered (e.g. 918 
> "Term in Test").
>  
> 2) Need to remove the ability to change the Service State in two 
> different competing ways. Beyond making the Service State read-only, 
> this indeed requires a new Method and might be differred to V3, 
> although, I think that there is value in removing competing options as 
> soon as possible.
>  
> Bruno
>  
>  
>  
> 
>     I have noticed this same discrepancy.  The problem is that the MGC
>     is allowed to set the ServiceStates parm utilizing a Modify command,
>     while the MG has no such capability (it must utilize
>     ServiceChange).  Therefore, there is no way for the MG to set the
>     term into the Test state.
>      
>     In the Annex F work at the most recent Q3 meeting, I raised the idea
>     of restricting the SI parm to being Read-only, and mandating that
>     state changes must utilize ServiceChange (in both directions).  This
>     would also require a new Method to set the term to Test.  The big
>     problem is that this is a change from the current function, and may
>     have to wait until V3 due to the parsing change with the Method
>     parm (unless there is wide acceptance to push this into earlier
>     versions...)
>      
>     This simplifies the termination state model by removing the ability
>     to change the parm in two different, competing ways.  It also
>     provides the MG the capability of setting the term into Test (which
>     I think has value and utility).
>      
>     Comments?
>      
>     Kevin
> 
>         H.248 defines three values for the Termination State descriptor
>         ("in service", "out of service" and "test"). The ServiceChange
>         procedures allows the MG to notify the MGC when a termination is
>         about to be taken out of service (or is being returned to
>         service). It seems that there is not equivalent procedure when a
>         termination is about to be tested (i.e. termination state =
>         test) and is therefore not available for normal traffic. Is
>         there a specific reason for treating these two states
>         differently or is just that the wording "out of service" in the
>         ServiceChange description encompasses both the "test" and "out
>         of service" termination states. If this is the case, I think a
>         clarification in the IG guide might be useful.
>          
>         Regards,
>         BC

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

---

From: Christian Groves <[email-masked]>
Date: Fri, 12 Dec 2003 10:11:44 +1100

Hello Bruno and Kevin,

Regards, Christian