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

From: "Kevin Boyle" <[email-masked]>
Date: Thu, 11 Dec 2003 19:08:31 -0500

The first portion is easily done -- if we don't get any objections, I will
add it as an IG item for H.248.8.  This means that it would become part of
the H.248.8 amendment that we are planning to consent at the meeting in
January.
 
I introduced the second portion as part of the Annex F work in Paris in
September.  I happen to think that it is a good idea, as it simplifies the
overall state model for H.248 and allows the MG the capability of putting
the termination in Test -- a capability that is notably lacking in the
current protocol.
 
Now, because it would involve a new Method, this would make today's parsers
out of date.  While I don't have any objection to including these changes in
V2, I do understand that problems that a syntax change would cause for some
implementations.  If anyone has objections to including this in V2, then we
can add it to V3.  Otherwise, I think it is of benefit now, and so I would
seek to get these changes incorporated in V2.
 
Kevin

  _____  

From: CHATRAS Bruno FTRD/DAC/ISS [mailto:[email-masked]] 
Sent: Thursday, December 11, 2003 4:06 AM 
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; [email-masked]
Subject: RE : [Megaco] Service Change and Testing

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: Christian Groves <[email-masked]>
Date: Fri, 12 Dec 2003 13:57:38 +1100

G'Day Kevin,

Is there really a need for the MG to signal state "test"? What does this really 
mean? If it means "don't use me" then we already have "out of service". If it 
means "use me for testing" then if the MGC is becoming involved it could have 
ordered state "test" through a MOD.

Regards, Christian

Kevin Boyle wrote:

> Envoye : mercredi 1 octobre 2003 19:44
> A : CHATRAS Bruno FTRD/DAC/ISS; [email-masked]

---

From: Christian Groves <[email-masked]>
Date: Fri, 12 Dec 2003 13:57:38 +1100

G'Day Kevin,

Regards, Christian