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

From: "CHATRAS Bruno FTRD/DAC/ISS" <[email-masked]>
Date: Fri, 12 Dec 2003 17:18:54 +0100

I agree. Having the MGC aware of the reason why the terminaition is out of sevrice would be much better. Adding a new service change reason should not be a big issue.
 
Actually metallic test access is exactly what I had in mind when I wrote "direct connection to specific devices".
 
Bruno

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

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

---

From: manish rathi <[email-masked]>
Date: Fri, 12 Dec 2003 22:23:53 +0530

hi,
cd u tell me
1) whether this configuration works multiple servers (MGC) and one Media
gateway?
2) whether does physical wire terminate media gateway or MGC?

thanks
regards
Manish

---

From: manish rathi <[email-masked]>
Date: Fri, 12 Dec 2003 22:23:53 +0530

hi,
cd u tell me

thanks
regards
Manish