Subject: RE: RE : RE : [Megaco] Service Change and Testing

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 12 Dec 2003 11:02:36 -0500

I believe that there is benefit to having the MGC aware that the reason that
the term is OOS is because it is undergoing test.  Given that the MGC and MG
may be in very different physical locations, the personnel at the MGC site
may not have immediate knowledge of what is going on at the remote MG
location.  Denoting that a particular termination is OOS tends to cause
concern if the term should otherwise be inservice.  However, having that
term in a test state shows that there isn't necessarily anything wrong at
the MG -- just that the term is being tested.

I believe the test state also applies to things like metallic test access --
not just test calls.

Kevin

-----Original Message-----
From: CHATRAS Bruno FTRD/DAC/ISS [mailto:[email-masked]] 
Sent: Friday, December 12, 2003 4:24 AM
To: Christian Groves; Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: [email-masked]
Subject: RE : RE : [Megaco] Service Change and Testing

Hello Christian,

Testing : What I'm really looking for is a solution that ensures that if a
local operator starts testing a termination, the MG notifies the MGC that
this termination cannot be used for normal traffic. The type of test I have
in mind is not a test call, but the direct connection of specific devices to
check the physical properties (e.g.; resistance, strand insulation)of the
copper line. I agree that in such cases, we may use "out of service" instead
of "test". However, if this is the agreement, I believe that explanatory
text would need to be added to the IG to limit the scope of the "test" state
to the case of test calls.

TISPAN : I did not thought about submitting the TISPAN profiles to Q3 at
this stage. However, this might be a good opportunity to get comments from a
wider audience.

Bruno

-----Message d'origine-----
De : Christian Groves [mailto:[email-masked]]
Envoyé : vendredi 12 décembre 2003 00:12 À : CHATRAS Bruno FTRD/DAC/ISS;
Kevin Boyle Cc : [email-masked] Objet : Re: RE : [Megaco] Service Change
and Testing

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

_______________________________________________
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: Christian Groves <[email-masked]>
Date: Mon, 15 Dec 2003 11:26:53 +1100

Hello Kevin,

What will the MGC do with this test state information? It can't take any 
maintenance action all it needs to know is if it can use a termination.

We already have:
5.2.6	Reason #: 905 Name: Termination taken out of service
Definition: This indicates that the entity indicated with the TerminationID is 
in ServiceState "Out Of-Service" due to maintenance action.

I'm sure testing equates to a maintenance action. This should be enough to make 
the MGC people happy, they could be more concerned at "904 Termination 
malfunctioning" so I don't think we need a new reason code.

With regards to Bruno's comment I think we could add something in Annex F saying 
that: MOD(test) is used for MGC initiated testing, State "Test" can be used 
internally in the MG for terminations and is indicated to the MG via 
ServiceChange(Graceful/Forced:reason 905). No new functionality needed and how 
it was designed to work. To further clear up confusion we could also clarify 
that MOD.req(Inservice) is used only change state from test to in-service and 
must not be used to put a termination out-of-service.

Regards, Christian

Kevin Boyle wrote:

> I believe that there is benefit to having the MGC aware that the reason 
> that the term is OOS is because it is undergoing test.  Given that the 
> MGC and MG may be in very different physical locations, the personnel at 
> the MGC site may not have immediate knowledge of what is going on at the 
> remote MG location.  Denoting that a particular termination is OOS tends 
> to cause concern if the term should otherwise be inservice.  However, 
> having that term in a test state shows that there isn't necessarily 
> anything wrong at the MG -- just that the term is being tested.
> 
> I believe the test state also applies to things like metallic test 
> access -- not just test calls.
> 
> Kevin
> 
> Testing : What I'm really looking for is a solution that ensures that if 
> a local operator starts testing a termination, the MG notifies the MGC 
> that this termination cannot be used for normal traffic. The type of 
> test I have in mind is not a test call, but the direct connection of 
> specific devices to check the physical properties (e.g.; resistance, 
> strand insulation)of the copper line. I agree that in such cases, we may 
> use "out of service" instead of "test". However, if this is the 
> agreement, I believe that explanatory text would need to be added to the 
> IG to limit the scope of the "test" state to the case of test calls.
> 
> this stage. However, this might be a good opportunity to get comments 
> from a wider audience.
> 
> Bruno
> 
> 
> 
> Kevin Boyle Cc : [email-masked] Objet : Re: RE : [Megaco] Service 
> Change and Testing
> 
> 
> Hello Bruno and Kevin,
> 
> 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
> With respect to having multiple ways of changing state to 
> "out-of-service" this
> 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
>

---

From: Christian Groves <[email-masked]>
Date: Mon, 15 Dec 2003 11:26:53 +1100

Hello Kevin,

We already have:

Regards, Christian