Subject: [Megaco] Auditing of CAS line states

From: Jon Rowland <[email-masked]>
Date: Wed, 17 Mar 2004 16:33:24 -0000

> Hello,
> 
> I have an issue related to auditing of CAS states, and have proposed an
> approach to resolve it below. I'd appreciate any input or insight anyone
> might have on this.
> 
> The Basic CAS package (bcas 0x003f) as described in H.248.25 includes
> signal definitions for setting line CAS states of seize,
> seize-acknowledge, idle and answered. These signals are defined as being
> 'brief', and the Signal Procedures (7.5.3) indicate that they should be
> treated as affecting changes in the CAS line state and these changes shall
> be considered to be completed instantaneously by the media gateway. This
> means there are no 'active' signals for any subsequent event detection to
> cancel.
> 
> In failover scenarios, it is important for the MGC to be able to audit the
> CAS line state of lines on the MG to determine call state or correct
> discrepancies by reprogramming the CAS state.
> 
> The Basic CAS package does not provide an auditable property of the
> termination that indicates the current CAS state, so the information
> cannot be returned by the MG on an audit response in this way. The usual
> way to audit for this sort of signal-related information would be for the
> MGC to audit the current SignalsDescriptor to get a list of all signals
> being played on the termination. However, because the CAS signals are
> actually mapped to state transitions and are defined as being brief, they
> are technically not being played once the state transition has occurred.
> This means that in the strict Megaco sense of brief signals, they should
> not be returned on any audited SignalsDescriptor.
> 
> The above behaviour makes it impossible to audit CAS line states.
> Therefore, I propose that 'brief' CAS signals as defined in H.248.25 and
> related recommendations should be treated as a special kind of brief
> signal by the MG for the purpose of audits. The signal maintains its
> properties of being brief from the point of view of not being cancelled by
> subsequent events detection, but is considered to be always playing while
> the CAS line state matches that defined by the signal. This means the MG
> can include the CAS signals in the SignalsDescriptor of the audit response
> always, and allows the MGC to determine the CAS line state.
> 
> Does this approach seem sensible?
> Has anyone come across this problem before and solved it in a different
> way?
> 
> Thanks for your input,
> Jon Rowland.
> 
> -----
> Jon Rowland
> MetaSwitch Group
> Data Connection Ltd (DCL)
> 
> Tel:	+44 20 8366 1177		Fax: +44 20 8363 4478
> Email:	[email-masked]	Web: http://www.metaswitch.com
> 
> 
> 
> 

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

---

From: "VOITH, Thomas" <[email-masked]>
Date: Thu, 18 Mar 2004 09:06:02 +0100

Hello Jon

I think the correct way to treat this is to use the
same 'strict' paramter as used for al/on or al/of.
With value 'state' you could get the state of the CAS line.
This mechanism should be taken for all static interface states
to get this audit behavior.
The problem is, that it is not included in all of the packages 
dealing with such static states.

Regards

Thomas Voith

-----Ursprüngliche Nachricht-----
Von: Jon Rowland [mailto:[email-masked]]
Gesendet am: Mittwoch, 17. März 2004 17:33
An: [email-masked]'
Betreff: [Megaco] Auditing of CAS line states

____________________________________________________________
          _
          V                 | Thomas Voith
  +---------------+         | Dept. ZFZ/A
  | A L C A T E L |         | EG/102
  +---------------+         | 
                            | Tel:   +49 711 821-40293
Alcatel SEL AG              | Fax:   +49 711 821-32453
Research & Innovation       |
Holderaeckerstr. 35         | mailto:[email-masked]
D-70499 Stuttgart, Germany  | 
------------------------------------------------------------

---

From: "VOITH, Thomas" <[email-masked]>
Date: Thu, 18 Mar 2004 09:06:02 +0100

Hello Jon

Regards

Thomas Voith

---

From: Jon Rowland <[email-masked]>
Date: Fri, 19 Mar 2004 16:47:39 -0000

Thomas,

Thanks for the reply.

The approach you suggest below seems like a sensible one for determining
line states set by remote equipment (i.e. states that would be incoming to
the MG and notified to the MGC as an event).

However, I am interested in auditing the line state in the outwards (from
the MG) direction - i.e. the state that would have previously have been set
by the MGC programming a SignalsDescriptor down to the MG. The strict
parameter doesn't make sense for signals, only events, which is why I have
proposed the scheme below of treating such brief signals as persistent for
auditing purposes.

However, your reply has made me consider that for (e.g.) digital trunks it
is possible for such steady CAS states to be applied in both outgoing (by
the MG) and incoming (by remote devices) directions, and there may be a need
for the MGC to be able to determine both states when auditing a termination.

It therefore seems like a better approach would be to extend the Basic CAS
package to add two new read-only properties for incoming and outgoing CAS
state of the line. These properties would automatically be updated by the MG
on detection of CAS events on the line, or requests for CAS signals to be
'played' by the MGC respectively. The MGC could then audit these properties
as required to determine the line state.

Your suggested use of the strict parameter is also useful in this case to
spot discrepancies at the point of programming the termination without
requiring an audit, so it would be sensible to include this mechanism in the
extended package as well.

This feels like a better overall scheme as it caters for incoming and
outgoing directions with a single mechanism.
Do you agree this is a sensible approach?
Can you think of any preferable alternatives?

Thanks,
Jon Rowland.

-----Original Message-----
From: VOITH, Thomas [mailto:[email-masked]]
Sent: 18 March 2004 08:06
To: Jon Rowland; [email-masked]'
Subject: AW: [Megaco] Auditing of CAS line states

Hello Jon

Regards

Thomas Voith

---

From: Jon Rowland <[email-masked]>
Date: Fri, 19 Mar 2004 16:47:39 -0000

Thomas,

Thanks for the reply.

Thanks,
Jon Rowland.

-----Original Message-----
From: VOITH, Thomas [mailto:[email-masked]]
Sent: 18 March 2004 08:06
To: Jon Rowland; [email-masked]'
Subject: AW: [Megaco] Auditing of CAS line states

Hello Jon

Regards

Thomas Voith

---

From: "VOITH, Thomas" <[email-masked]>
Date: Mon, 22 Mar 2004 10:38:47 +0100

Hello Jon

First I am not a strong expert for CAS signalling, but I think
that in dependency of direction (incoming or outgoing) the 
line states are unambiguos states. 
It does not matter, which side the states changes, the meaning of 
line state is fix.
i.e. all changes from own or remote end results in a line state change,
which always can be detected via Events Descriptor.

For bothway configured lines, the seizure collision should be detected as 
event. The problem is, that the EventsDescriptor should not only contain
just the
good case events, the bad case events are needed also.

Seizure colision result in Idle/Release state. Which is the same in forward
and
backward direction. At least, this can be detected with an EventsDescriptor,
in
case you want to have such an audit capablity.

With the strict parameter, you can specify the state towards the MG, from
which
the MGC thinks, that the line is in this state. In case it is different, you

will be notified.

One problem remains, using SignalsDescriptor changes also the line state,
which prohibit
you to being notified all static line states.

Regards

Thomas Voith 

-----Ursprüngliche Nachricht-----
Von: Jon Rowland [mailto:[email-masked]]
Gesendet am: Freitag, 19. März 2004 17:48
An: 'VOITH, Thomas'; [email-masked]'
Betreff: RE: [Megaco] Auditing of CAS line states

Thomas,

Thanks for the reply.

Thanks,
Jon Rowland.

-----Original Message-----
From: VOITH, Thomas [mailto:[email-masked]]
Sent: 18 March 2004 08:06
To: Jon Rowland; [email-masked]'
Subject: AW: [Megaco] Auditing of CAS line states

Hello Jon

Regards

Thomas Voith

---

From: "VOITH, Thomas" <[email-masked]>
Date: Mon, 22 Mar 2004 10:38:47 +0100

Hello Jon

will be notified.

Regards

Thomas Voith 

-----Ursprüngliche Nachricht-----
Von: Jon Rowland [mailto:[email-masked]]
Gesendet am: Freitag, 19. März 2004 17:48
An: 'VOITH, Thomas'; [email-masked]'
Betreff: RE: [Megaco] Auditing of CAS line states

Thomas,

Thanks for the reply.

Thanks,
Jon Rowland.

-----Original Message-----
From: VOITH, Thomas [mailto:[email-masked]]
Sent: 18 March 2004 08:06
To: Jon Rowland; [email-masked]'
Subject: AW: [Megaco] Auditing of CAS line states

Hello Jon

Regards

Thomas Voith

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 23 Mar 2004 14:54:00 -0500

I agree with Jon that adding read-only properties with the line states is a
much better method than being dependent upon the "strict" parameter.  Note
that there is no requirement to set the strict parameter in the al package
to "state" -- there are two other settings that are equally legitimate.
Unless your proposal is to mandate that the strict parameter be "state" for
this package, then this really doesn't solve the stated problem.  If that IS
your proposal, then it would be better to just define that behavior, rather
than define a new parameter which is unchangeable.

The problem as stated is that the MGC has no way to determine at a given
instant what the line state is.  The obvious way to do that would be to
audit.  So, having a read-only property the reflects the line state is the
logical way to enable such an audit, so that the MGC can determine the line
state.

Note that problems with the line state during call processing would be
detectable via the casfail event as a state transition problem.  I see no
need to add the strict parameter to the line signalling events.

Kevin 

-----Original Message-----
From: VOITH, Thomas [mailto:[email-masked]] 
Sent: Monday, March 22, 2004 4:39 AM
To: 'Jon Rowland'; VOITH, Thomas; [email-masked]'
Subject: AW: [Megaco] Auditing of CAS line states

Hello Jon

First I am not a strong expert for CAS signalling, but I think that in
dependency of direction (incoming or outgoing) the line states are
unambiguos states. 
It does not matter, which side the states changes, the meaning of line state
is fix.
i.e. all changes from own or remote end results in a line state change,
which always can be detected via Events Descriptor.

For bothway configured lines, the seizure collision should be detected as
event. The problem is, that the EventsDescriptor should not only contain
just the good case events, the bad case events are needed also.

Seizure colision result in Idle/Release state. Which is the same in forward
and backward direction. At least, this can be detected with an
EventsDescriptor, in case you want to have such an audit capablity.

With the strict parameter, you can specify the state towards the MG, from
which the MGC thinks, that the line is in this state. In case it is
different, you

will be notified.

One problem remains, using SignalsDescriptor changes also the line state,
which prohibit you to being notified all static line states.

Regards

Thomas Voith 

-----Ursprüngliche Nachricht-----
Von: Jon Rowland [mailto:[email-masked]]
Gesendet am: Freitag, 19. März 2004 17:48
An: 'VOITH, Thomas'; [email-masked]'
Betreff: RE: [Megaco] Auditing of CAS line states

Thomas,

Thanks for the reply.

Thanks,
Jon Rowland.

-----Original Message-----
From: VOITH, Thomas [mailto:[email-masked]]
Sent: 18 March 2004 08:06
To: Jon Rowland; [email-masked]'
Subject: AW: [Megaco] Auditing of CAS line states

Hello Jon

I think the correct way to treat this is to use the same 'strict' paramter
as used for al/on or al/of.
With value 'state' you could get the state of the CAS line.
This mechanism should be taken for all static interface states to get this
audit behavior.
The problem is, that it is not included in all of the packages dealing with
such static states.

Regards

Thomas Voith

-----Ursprüngliche Nachricht-----
Von: Jon Rowland [mailto:[email-masked]]
Gesendet am: Mittwoch, 17. März 2004 17:33
An: [email-masked]'
Betreff: [Megaco] Auditing of CAS line states

> Hello,
> 
> I have an issue related to auditing of CAS states, and have proposed 
> an approach to resolve it below. I'd appreciate any input or insight 
> anyone might have on this.
> 
> seize-acknowledge, idle and answered. These signals are defined as 
> being 'brief', and the Signal Procedures (7.5.3) indicate that they 
> should be treated as affecting changes in the CAS line state and these 
> changes shall be considered to be completed instantaneously by the 
> media gateway. This means there are no 'active' signals for any 
> subsequent event detection to cancel.
> 
> In failover scenarios, it is important for the MGC to be able to audit 
> the CAS line state of lines on the MG to determine call state or 
> correct discrepancies by reprogramming the CAS state.
> 
> cannot be returned by the MG on an audit response in this way. The 
> usual way to audit for this sort of signal-related information would 
> be for the MGC to audit the current SignalsDescriptor to get a list of 
> all signals being played on the termination. However, because the CAS 
> signals are actually mapped to state transitions and are defined as 
> being brief, they are technically not being played once the state
transition has occurred.
> This means that in the strict Megaco sense of brief signals, they 
> should not be returned on any audited SignalsDescriptor.
> 
> Therefore, I propose that 'brief' CAS signals as defined in H.248.25 
> and related recommendations should be treated as a special kind of 
> brief signal by the MG for the purpose of audits. The signal maintains 
> its properties of being brief from the point of view of not being 
> cancelled by subsequent events detection, but is considered to be 
> always playing while the CAS line state matches that defined by the 
> signal. This means the MG can include the CAS signals in the 
> SignalsDescriptor of the audit response always, and allows the MGC to
determine the CAS line state.
> Has anyone come across this problem before and solved it in a 
> different way?
> 
> Thanks for your input,
> Jon Rowland.
> 
> -----
> Jon Rowland
> MetaSwitch Group

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 23 Mar 2004 14:54:00 -0500

Kevin 

-----Original Message-----
From: VOITH, Thomas [mailto:[email-masked]] 
Sent: Monday, March 22, 2004 4:39 AM
To: 'Jon Rowland'; VOITH, Thomas; [email-masked]'
Subject: AW: [Megaco] Auditing of CAS line states

Hello Jon

will be notified.

Regards

Thomas Voith 

-----Ursprüngliche Nachricht-----
Von: Jon Rowland [mailto:[email-masked]]
Gesendet am: Freitag, 19. März 2004 17:48
An: 'VOITH, Thomas'; [email-masked]'
Betreff: RE: [Megaco] Auditing of CAS line states

Thomas,

Thanks for the reply.

Thanks,
Jon Rowland.

-----Original Message-----
From: VOITH, Thomas [mailto:[email-masked]]
Sent: 18 March 2004 08:06
To: Jon Rowland; [email-masked]'
Subject: AW: [Megaco] Auditing of CAS line states

Hello Jon

Regards

Thomas Voith

-----Ursprüngliche Nachricht-----
Von: Jon Rowland [mailto:[email-masked]]
Gesendet am: Mittwoch, 17. März 2004 17:33
An: [email-masked]'
Betreff: [Megaco] Auditing of CAS line states

transition has occurred.

---

From: "VOITH, Thomas" <[email-masked]>
Date: Wed, 24 Mar 2004 09:56:45 +0100

Kevin, Jon
 
I have the feeling we do mix different approaches.
My way is to try use the Events/Signal Descripors in a way to be notified
for each
state change. Otherwise you are forced to audit states in case the MGC has
the "feeling" that a 
different line state exist. That's for me not an equivalent to a signalling
interface.
 
If Megaco is not able with Events/Signals Descriptors to report ALL state
changes to MGC, then
Megaco is not a good candidate to be used as signalling interface like CAS.
 
First goal should be to define the Events/Signals Descriptors  in a way so
that an audit afterwards
is not necessary.
If this approach is used you could have an audit in addition, but it is not
really necessary.
 
Regards 
 
Thomas

-----Ursprüngliche Nachricht-----
Von: Kevin Boyle [mailto:[email-masked]]
Gesendet am: Dienstag, 23. März 2004 20:54
An: VOITH, Thomas; 'Jon Rowland'; [email-masked]'
Betreff: RE: [Megaco] Auditing of CAS line states

Kevin 

-----Original Message----- 
From: VOITH, Thomas [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Monday, March 22, 2004 4:39 AM 
To: 'Jon Rowland'; VOITH, Thomas; [email-masked]' 
Subject: AW: [Megaco] Auditing of CAS line states 

Hello Jon 

will be notified. 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 
Von: Jon Rowland [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Gesendet am: Freitag, 19. März 2004 17:48 
An: 'VOITH, Thomas'; [email-masked]' 
Betreff: RE: [Megaco] Auditing of CAS line states 

Thomas, 

Thanks for the reply. 

Thanks, 
Jon Rowland. 

-----Original Message----- 
From: VOITH, Thomas [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: 18 March 2004 08:06 
To: Jon Rowland; [email-masked]' 
Subject: AW: [Megaco] Auditing of CAS line states 

Hello Jon 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 
Von: Jon Rowland [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Gesendet am: Mittwoch, 17. März 2004 17:33 
An: [email-masked]' 
Betreff: [Megaco] Auditing of CAS line states 

transition has occurred. 
> Email:        [email-masked]  Web: http://www.metaswitch.com
<http://www.metaswitch.com>  

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

<mailto:[email-masked]>  

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

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

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

---

From: "VOITH, Thomas" <[email-masked]>
Date: Wed, 24 Mar 2004 09:56:45 +0100

Kevin, Jon

 
 
Regards 
 
Thomas

-----Ursprüngliche Nachricht-----
Von: Kevin Boyle [mailto:[email-masked]]
Gesendet am: Dienstag, 23. März 2004 20:54
An: VOITH, Thomas; 'Jon Rowland'; [email-masked]'
Betreff: RE: [Megaco] Auditing of CAS line states

Kevin 

-----Original Message----- 

Hello Jon 

will be notified. 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 

Thomas, 

Thanks for the reply. 

Thanks, 
Jon Rowland. 

-----Original Message----- 

Hello Jon 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 

transition has occurred.

---

From: Jon Rowland <[email-masked]>
Date: Wed, 24 Mar 2004 10:21:57 -0000

Kevin, 

Thanks for the reply. On thinking about it a bit more, I agree that using
the casfail event covers the issue of programming discrepancies and adding
something like a 'strict' parameter doesn't add much.

Thomas,

I think you might have slightly the wrong view of what problem we're trying
to address here.

During normal call setup procedures the MGC absolutely knows what the CAS
line state is. It will typically set this to 'idle' when programming line
terminations into the ground state and then will 'seize' the line during
call setup at the appropriate points. During this programming we do not
expect the CAS state to be anything other than what the MGC already knows it
to be.

The problem being addressed is how the MGC determines the current CAS state
in any of the following scenarios:
- MGC fails over
- MG fails over
- Network glitch

In all of the above cases it would be possible for outstanding commands to
change the CAS state, or events indicating changes to be lost at the problem
point. Typically the MGC will respond to these scenarios by auditing the
states of all the terminations it cares about on the MG. The addition of
read-only properties indicating CAS states allows it to do this, where it
currently cannot, given the existing package definitions.

Does that make sense? Do you now see the requirement for an auditable
property?

To address one other comment you made about CAS states being directionless:
for 2-wire analogue lines and equivalents the CAS states are effectively
directionless. However for 4-wire/E&M lines the CAS state being 'played' by
each end is independent and therefore there is a need to be able to audit
both the incoming and outgoing state (or effectively the states of the
transmit and receive lines) separately.
Kevin, Thomas - do you agree with this?

Thanks,
Jon.

-----Original Message-----
From: VOITH, Thomas [mailto:[email-masked]]
Sent: 24 March 2004 08:57
To: 'Kevin Boyle'; VOITH, Thomas; Jon Rowland; [email-masked]'
Subject: AW: [Megaco] Auditing of CAS line states

Kevin, Jon

 
 
Regards 
 
Thomas

-----Ursprüngliche Nachricht-----
Von: Kevin Boyle [mailto:[email-masked]]
Gesendet am: Dienstag, 23. März 2004 20:54
An: VOITH, Thomas; 'Jon Rowland'; [email-masked]'
Betreff: RE: [Megaco] Auditing of CAS line states

Kevin 

-----Original Message----- 

Hello Jon 

will be notified. 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 

Thomas, 

Thanks for the reply. 

Thanks, 
Jon Rowland. 

-----Original Message----- 

Hello Jon 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 

transition has occurred.

---

From: Jon Rowland <[email-masked]>
Date: Wed, 24 Mar 2004 10:21:57 -0000

Kevin, 

Thomas,

Thanks,
Jon.

-----Original Message-----
From: VOITH, Thomas [mailto:[email-masked]]
Sent: 24 March 2004 08:57
To: 'Kevin Boyle'; VOITH, Thomas; Jon Rowland; [email-masked]'
Subject: AW: [Megaco] Auditing of CAS line states

Kevin, Jon

 
 
Regards 
 
Thomas

-----Ursprüngliche Nachricht-----
Von: Kevin Boyle [mailto:[email-masked]]
Gesendet am: Dienstag, 23. März 2004 20:54
An: VOITH, Thomas; 'Jon Rowland'; [email-masked]'
Betreff: RE: [Megaco] Auditing of CAS line states

Kevin 

-----Original Message----- 

Hello Jon 

will be notified. 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 

Thomas, 

Thanks for the reply. 

Thanks, 
Jon Rowland. 

-----Original Message----- 

Hello Jon 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 

transition has occurred.

---

From: "VOITH, Thomas" <[email-masked]>
Date: Thu, 25 Mar 2004 12:30:24 +0100

Jon,Kevin

In the CAS package currently defined the line signals are interpreted
by the MG covering both directions in one set of states.
(in my opinion independent whether it is 2-wire or 4-wire, so in this point 
 I do not agree)

In the Audit proposal you made, what is then contained in the audit
response?
The pure line state in format of af bf ab bb Bit states ??
Do you report winks ??

Please note that some national implementations uses also winks
during stable phase.

The reason why I ask this is, just audit the line state is due to 
my understanding not always sufficient, since it depends how at this time
the EventDescriptor/SignalDescriptor is configured not falling in a 
"gap" until next Modify command is sent to MG and whether the MGC
is able to receive Notifies from MG. This is especially the case
after Fail-over scenarios.

With the state parameter you can synchronize the state machine in MGC
with the state machine on MG more efficient.
Since you do not know what happens between the audit and the next
Modify command from MGC.

With the EventDescriptor you can also cover all the extensions of further
dependent packages, such additional brief/wink signals, which could also
occur
during stable state of the call.

I know, that the treatment via EventDescriptor is more uncomfortable, but 
from then on the MGC is synchronized with the MG and it covers also 
dynamic signals.

One example in detail:
---------------------
I assume that after a fail-over the MGC checks via Audit the 
Context and Terminations for calls being in a call established or not.
Usually checking the lines states here the alignment between MGC and MG
is not guaranteed. 

The MGC then creates instances for each CAS line, which are in stable phase.
Usually this instance synchronizes itself with the line state 
using EventDescriptor with strict parameter. So in case it do not mach 
with the state on the related line, the MGC will be notified.
From then on they are aligned. For not aligned states additional steps may
be necessary.

For calls which are not in stable phase, MGC can force the MG directly going
into Idle state.

For calls which are in Null Context, the audit of line states is only
helpful, if
MGC want to reuse the existing EventsDescriptor and therefor MGC needs the
state.
But in case another MGC takes over a MG, it may use a different handling of
CAS lines and
it has to overwrite the existing EventsDescriptor anyway. 

In case you change the sequence or do auditing in parallel to instance
creation, how
does MGC reach the alignment with MG?
---------------------

I assume with your audit approach you may have a different scenario in mind
and
it depends how you use the EventsDescriptor/SignalDescriptor for CAS.
I think such an alignment is needed independent of the introduction of 
Audit of line states.

In general it remains the question, whether Audit is the right place 
for polling signal states on MG.

- using Audit for Error-recovering between MG and MGC as an independent
process
  then it is fine for me.
- using Audit for synchronization the state machine of MGC with MG, in my
opinion
  Audit is not sufficient.

Regards

Thomas

-----Ursprüngliche Nachricht-----
Von: Jon Rowland [mailto:[email-masked]]
Gesendet am: Mittwoch, 24. März 2004 11:22
An: 'VOITH, Thomas'; 'Kevin Boyle'; [email-masked]'
Betreff: RE: [Megaco] Auditing of CAS line states

Kevin, 

Thomas,

Thanks,
Jon.

-----Original Message-----
From: VOITH, Thomas [mailto:[email-masked]]
Sent: 24 March 2004 08:57
To: 'Kevin Boyle'; VOITH, Thomas; Jon Rowland; [email-masked]'
Subject: AW: [Megaco] Auditing of CAS line states

Kevin, Jon

 
 
Regards 
 
Thomas

-----Ursprüngliche Nachricht-----
Von: Kevin Boyle [mailto:[email-masked]]
Gesendet am: Dienstag, 23. März 2004 20:54
An: VOITH, Thomas; 'Jon Rowland'; [email-masked]'
Betreff: RE: [Megaco] Auditing of CAS line states

Kevin 

-----Original Message----- 

Hello Jon 

will be notified. 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 

Thomas, 

Thanks for the reply. 

Thanks, 
Jon Rowland. 

-----Original Message----- 

Hello Jon 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 

transition has occurred.

---

From: "VOITH, Thomas" <[email-masked]>
Date: Thu, 25 Mar 2004 12:30:24 +0100

Jon,Kevin

One example in detail:
---------------------

Regards

Thomas

-----Ursprüngliche Nachricht-----
Von: Jon Rowland [mailto:[email-masked]]
Gesendet am: Mittwoch, 24. März 2004 11:22
An: 'VOITH, Thomas'; 'Kevin Boyle'; [email-masked]'
Betreff: RE: [Megaco] Auditing of CAS line states

Kevin, 

Thomas,

Thanks,
Jon.

-----Original Message-----
From: VOITH, Thomas [mailto:[email-masked]]
Sent: 24 March 2004 08:57
To: 'Kevin Boyle'; VOITH, Thomas; Jon Rowland; [email-masked]'
Subject: AW: [Megaco] Auditing of CAS line states

Kevin, Jon

 
 
Regards 
 
Thomas

-----Ursprüngliche Nachricht-----
Von: Kevin Boyle [mailto:[email-masked]]
Gesendet am: Dienstag, 23. März 2004 20:54
An: VOITH, Thomas; 'Jon Rowland'; [email-masked]'
Betreff: RE: [Megaco] Auditing of CAS line states

Kevin 

-----Original Message----- 

Hello Jon 

will be notified. 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 

Thomas, 

Thanks for the reply. 

Thanks, 
Jon Rowland. 

-----Original Message----- 

Hello Jon 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 

transition has occurred.

---

From: "Kevin Boyle" <[email-masked]>
Date: Thu, 25 Mar 2004 15:16:53 -0500

Comments inline. [KJBII]

Kevin

-----Original Message-----
From: VOITH, Thomas [mailto:[email-masked]] 
Sent: Thursday, March 25, 2004 6:30 AM
To: 'Jon Rowland'; VOITH, Thomas; Boyle, Kevin [NCRTP:3Z40:EXCH];
[email-masked]'

Jon,Kevin

In the CAS package currently defined the line signals are interpreted by the
MG covering both directions in one set of states.
(in my opinion independent whether it is 2-wire or 4-wire, so in this point
I do not agree)

[KJBII] BCAS was only designed to do two-wire CAS.  You need ICAS for four
wire CAS, as is reflected by the additional "states" in the ICAS package.
Either way, adding read-only properties to reflect the states seems a much
better way to go about this.  Also, note that adding properties is a much
better method of solving this problem from a backwards-compatibility point
of view.

[KJBII] The value of the property as would be in the package.

[KJBII] I do not believe that is necessary.

Do you report winks ??

[KJBII] I do not see how winks would get reported in EITHER methodology
without counting them.

Please note that some national implementations uses also winks during stable
phase.

[KJBII] I don't see where this is relevant.  If the winks do not change the
line state, who cares?

The reason why I ask this is, just audit the line state is due to my
understanding not always sufficient, since it depends how at this time the
EventDescriptor/SignalDescriptor is configured not falling in a "gap" until
next Modify command is sent to MG and whether the MGC is able to receive
Notifies from MG. This is especially the case after Fail-over scenarios.

[KJBII] Huh?  The states are clearly defined now via the Signals and Events
descriptors.  Making a property that reflects the current state would cover
all possibilities.  I do not see how this is not sufficient.

With the state parameter you can synchronize the state machine in MGC with
the state machine on MG more efficient.
Since you do not know what happens between the audit and the next Modify
command from MGC.

[KJBII] What, exactly, are you trying to accomplish?  We are talking about
recovering from a failure scenario.  In a failure scenario, there will
always be cleanup and uncertainty.  I don't see any reduction of that
uncertainly unless you are proposing mandating that the line signaling
events operate as "state", in which case we don't need to define the
parameter, the definition of the line signal events would have to be changed
to make that mandate.

With the EventDescriptor you can also cover all the extensions of further
dependent packages, such additional brief/wink signals, which could also
occur during stable state of the call.

[KJBII] Again, if these do not change the current line state, then who
cares?

I know, that the treatment via EventDescriptor is more uncomfortable, but
from then on the MGC is synchronized with the MG and it covers also dynamic
signals.

One example in detail:
---------------------
I assume that after a fail-over the MGC checks via Audit the Context and
Terminations for calls being in a call established or not.
Usually checking the lines states here the alignment between MGC and MG is
not guaranteed.

[KJBII] Are you suggesting we mandate auditing, too?  This is roaming into
implementation mandates, which I am REALLY uncomfortable with.

The MGC then creates instances for each CAS line, which are in stable phase.
Usually this instance synchronizes itself with the line state using
EventDescriptor with strict parameter.

[KJBII] Umm... There is NO strict parameter for any event in the package.
If your implementation uses it, it is NON-COMPLIANT.

So in case it do not mach with the state on the related line, the MGC will
be notified.
From then on they are aligned. For not aligned states additional steps may
be necessary.

[KJBII]  I do not believe that it is just this easy to become aligned.  The
MGC would have to move its own state machine to the current state in the MG
-- possibly without all the necessary information to do so.  It seems to me
that the MGC may have to audit or clean the termination up at this point.
So there is no savings here.

[KJBII] This can be done anyway...

For calls which are in Null Context, the audit of line states is only
helpful, if MGC want to reuse the existing EventsDescriptor and therefor MGC
needs the state.

[KJBII] I don't follow this at all.  Audit allows the MGC to gather
information about the term.  It has nothing to do with "reuse" of the
existing events descriptor.

But in case another MGC takes over a MG, it may use a different handling of
CAS lines and it has to overwrite the existing EventsDescriptor anyway.

[KJBII] MGCs cannot autonomously take over MGs.  I don't see what you are
talking about.  If the MGC directs the MG to a new MGC, who is to say that
the new MGC does not already have state knowledge?  Assuming that the new
MGC has to overwrite the events descriptor makes an assumption about
implementation that does not necessarily apply.

In case you change the sequence or do auditing in parallel to instance
creation, how does MGC reach the alignment with MG?

[KJBII]  If the MGC wants to guarantee alignment, it can cleanup the MG to a
known state.
---------------------

I assume with your audit approach you may have a different scenario in mind
and it depends how you use the EventsDescriptor/SignalDescriptor for CAS.

[KJBII] Compliant implementations would use the descriptors as defined in
the package.  I don't see where there is a "how you use" component.

I think such an alignment is needed independent of the introduction of Audit
of line states.

[KJBII] It seems pretty clear to me that the way forward is to introduce
read-only properties into the BCAS and ICAS packages to reflect the line
state.  I still do not see the need for the strict parameter -- the
functionality you seek is available in a combination of the line signaling
events and the casfail event today.

[KJBII] I still have not seen evidence to this end.

Regards

Thomas

-----Ursprüngliche Nachricht-----
Von: Jon Rowland [mailto:[email-masked]]
Gesendet am: Mittwoch, 24. März 2004 11:22
An: 'VOITH, Thomas'; 'Kevin Boyle'; [email-masked]'
Betreff: RE: [Megaco] Auditing of CAS line states

Kevin, 

Thomas,

Thanks,
Jon.

-----Original Message-----
From: VOITH, Thomas [mailto:[email-masked]]
Sent: 24 March 2004 08:57
To: 'Kevin Boyle'; VOITH, Thomas; Jon Rowland; [email-masked]'
Subject: AW: [Megaco] Auditing of CAS line states

Kevin, Jon

 
 
Regards 
 
Thomas

-----Ursprüngliche Nachricht-----
Von: Kevin Boyle [mailto:[email-masked]]
Gesendet am: Dienstag, 23. März 2004 20:54
An: VOITH, Thomas; 'Jon Rowland'; [email-masked]'
Betreff: RE: [Megaco] Auditing of CAS line states

Kevin 

-----Original Message----- 

Hello Jon 

will be notified. 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 

Thomas, 

Thanks for the reply. 

Thanks, 
Jon Rowland. 

-----Original Message----- 

Hello Jon 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 

transition has occurred.

---

From: "Kevin Boyle" <[email-masked]>
Date: Thu, 25 Mar 2004 15:16:53 -0500

Comments inline. [KJBII]

Kevin

-----Original Message-----
From: VOITH, Thomas [mailto:[email-masked]] 
Sent: Thursday, March 25, 2004 6:30 AM
To: 'Jon Rowland'; VOITH, Thomas; Boyle, Kevin [NCRTP:3Z40:EXCH];
[email-masked]'

Jon,Kevin

Do you report winks ??

One example in detail:
---------------------

Regards

Thomas

-----Ursprüngliche Nachricht-----
Von: Jon Rowland [mailto:[email-masked]]
Gesendet am: Mittwoch, 24. März 2004 11:22
An: 'VOITH, Thomas'; 'Kevin Boyle'; [email-masked]'
Betreff: RE: [Megaco] Auditing of CAS line states

Kevin, 

Thomas,

Thanks,
Jon.

-----Original Message-----
From: VOITH, Thomas [mailto:[email-masked]]
Sent: 24 March 2004 08:57
To: 'Kevin Boyle'; VOITH, Thomas; Jon Rowland; [email-masked]'
Subject: AW: [Megaco] Auditing of CAS line states

Kevin, Jon

 
 
Regards 
 
Thomas

-----Ursprüngliche Nachricht-----
Von: Kevin Boyle [mailto:[email-masked]]
Gesendet am: Dienstag, 23. März 2004 20:54
An: VOITH, Thomas; 'Jon Rowland'; [email-masked]'
Betreff: RE: [Megaco] Auditing of CAS line states

Kevin 

-----Original Message----- 

Hello Jon 

will be notified. 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 

Thomas, 

Thanks for the reply. 

Thanks, 
Jon Rowland. 

-----Original Message----- 

Hello Jon 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 

transition has occurred.

---

From: "VOITH, Thomas" <[email-masked]>
Date: Mon, 29 Mar 2004 13:16:00 +0200

Hello 
 
Comments inline
 
Regards
 
Thomas

-----Ursprüngliche Nachricht-----
Von: Kevin Boyle [mailto:[email-masked]]
Gesendet am: Donnerstag, 25. März 2004 21:17
An: VOITH, Thomas; 'Jon Rowland'; [email-masked]'
Betreff: RE: [Megaco] Auditing of CAS line states

Comments inline. [KJBII] 

Kevin 

-----Original Message----- 

Jon,Kevin 

[TV] From a backward compatibility point of view, yes. 

Do you report winks ?? 

[KJBII] I do not see how winks would get reported in EITHER methodology
without counting them. 
[TV] In case the EventsDescriptor is used for getting line state, the
parallel active winks are known to the
MG, so MG can report the the line state in a correct way. Just using an
Audit, this information is missing.

[TV] That means only states with minimum 400-500 ms  will be reported as
long the MG has not the information
which kind of wink are also possible. Doing with the EventsDescriptor, the
MG looks for the longest winks and MG has to 
wait minimum this time before it can report the line state. In case an Audit
with wildcards is used, this is not longer
a simple snapshot.

[KJBII] Huh?  The states are clearly defined now via the Signals and Events
descriptors.  Making a property that reflects the current state would cover
all possibilities.  I do not see how this is not sufficient.
[TV] An EventDescriptor can be active in parallel. In case you audit the
line signal state you could get audit and Notifies in "parallel".
An audit descriptor usually do not have a time stamp information. Doing all
with EventsDescriptor would not raise such a situation.

[TV] In case strict is used, the "state" is used for all states different
from states in MGC. 

[KJBII] Again, if these do not change the current line state, then who
cares? 
[TV] It exists so many different CAS signaling variants.  I know only a very
small subset, but they are so different in respect
to static and wink signals changing the line state. I would prefer a
solution from which I know it would be a good basis 
for all further extensions.

One example in detail: 
--------------------- 

[KJBII] Are you suggesting we mandate auditing, too?  This is roaming into
implementation mandates, which I am REALLY uncomfortable with.
[TV] My intention was not to affix implementation arguments to this
discussion. In my opinion Signal and Events should
exclusively treated by Events/Signal Descriptor and not via an Audit. What I
miss is the continuity of basic mechanism over
packages using similar solutions. 
Arguing with implementation is not a good way from my side, so forget this
example. 

[KJBII] Umm... There is NO strict parameter for any event in the package.
If your implementation uses it, it is NON-COMPLIANT.
[TV] You know I made this proposal last year, since in my opinion really a
lack in this package. 

[KJBII]  I do not believe that it is just this easy to become aligned.  The
MGC would have to move its own state machine to the current state in the MG
-- possibly without all the necessary information to do so.  It seems to me
that the MGC may have to audit or clean the termination up at this point.
So there is no savings here.
[TV] Using strict has the advantage, that  the MGC get the information, that
is was misaligned with the last modify(with EventsDescriptor).
Just using an Audit this is not the same. 

[KJBII] This can be done anyway... 
[TV] This decision is made due to the information, that MGC was misaligned. 

[KJBII]  If the MGC wants to guarantee alignment, it can cleanup the MG to a
known state. 
--------------------- 
[TV] It was just an example.

[KJBII] Compliant implementations would use the descriptors as defined in
the package.  I don't see where there is a "how you use" component.
[TV]  What I meant here is, implementation just using next expected state
(good case) versus implementation which uses
the full set of possible states occurring on line (good case + bad cases). 

[KJBII] It seems pretty clear to me that the way forward is to introduce
read-only properties into the BCAS and ICAS packages to reflect the line
state.  I still do not see the need for the strict parameter -- the
functionality you seek is available in a combination of the line signaling
events and the casfail event today.
[TV] Does this also mean in consequence, that for "al/of al/on" , such an
audit is also missing ?
For the al package it is no need to introduce an audit, because 'strict'
parameter is defined.
It is REALLY strange to me solving similar problems with different
approaches.
Please not I am not strong against an Audit, but this would be to my
knowledge the first package
auditing signalling interface states via audit parameter.

Regards 

Thomas 

-----Ursprüngliche Nachricht----- 

Kevin, 

Thomas, 

to be. 

Thanks, 
Jon. 

-----Original Message----- 

Kevin, Jon 

  
  
Regards 
  
Thomas 

-----Ursprüngliche Nachricht----- 
Von: Kevin Boyle [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Gesendet am: Dienstag, 23. März 2004 20:54 
An: VOITH, Thomas; 'Jon Rowland'; [email-masked]' 
Betreff: RE: [Megaco] Auditing of CAS line states 

Kevin 

-----Original Message----- 
< mailto:[email-masked] <mailto:[email-masked]> > ] 

Hello Jon 

is fix. 

will be notified. 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 
Von: Jon Rowland [ mailto:[email-masked]
<mailto:[email-masked]>  
< mailto:[email-masked]
<mailto:[email-masked]> > ] 
Gesendet am: Freitag, 19. März 2004 17:48 
An: 'VOITH, Thomas'; [email-masked]' 
Betreff: RE: [Megaco] Auditing of CAS line states 

Thomas, 

Thanks for the reply. 

Thanks, 
Jon Rowland. 

-----Original Message----- 
< mailto:[email-masked] <mailto:[email-masked]> > ] 

Hello Jon 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 
Von: Jon Rowland [ mailto:[email-masked]
<mailto:[email-masked]>  
< mailto:[email-masked]
<mailto:[email-masked]> > ] 
Gesendet am: Mittwoch, 17. März 2004 17:33 
An: [email-masked]' 
Betreff: [Megaco] Auditing of CAS line states 

transition has occurred. 
<http://www.metaswitch.com>  
< http://www.metaswitch.com <http://www.metaswitch.com> >  

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

< mailto:[email-masked] <mailto:[email-masked]> >  

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

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

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

---

From: "VOITH, Thomas" <[email-masked]>
Date: Mon, 29 Mar 2004 13:16:00 +0200

Hello 
 
Comments inline
 
Regards
 
Thomas

-----Ursprüngliche Nachricht-----
Von: Kevin Boyle [mailto:[email-masked]]
Gesendet am: Donnerstag, 25. März 2004 21:17
An: VOITH, Thomas; 'Jon Rowland'; [email-masked]'
Betreff: RE: [Megaco] Auditing of CAS line states

Comments inline. [KJBII] 

Kevin 

-----Original Message----- 

Jon,Kevin 

Do you report winks ?? 

One example in detail: 
--------------------- 

Regards 

Thomas 

-----Ursprüngliche Nachricht----- 

Kevin, 

Thomas, 

to be. 

Thanks, 
Jon. 

-----Original Message----- 

Kevin, Jon 

  
  
Regards 
  
Thomas 

-----Ursprüngliche Nachricht----- 

Kevin 

-----Original Message----- 

Hello Jon 

is fix. 

will be notified. 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 

Thomas, 

Thanks for the reply. 

Thanks, 
Jon Rowland. 

-----Original Message----- 

Hello Jon 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 

transition has occurred.

---

From: "Kevin Boyle" <[email-masked]>
Date: Mon, 29 Mar 2004 09:53:22 -0500

Comments to comments inline. [KJBII]

Kevin

-----Original Message-----
From: VOITH, Thomas [mailto:[email-masked]] 
Sent: Monday, March 29, 2004 6:16 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; VOITH, Thomas; 'Jon Rowland';
[email-masked]'

Hello 
 
Comments inline
 
Regards
 
Thomas

-----Ursprüngliche Nachricht-----
Von: Kevin Boyle [mailto:[email-masked]]
Gesendet am: Donnerstag, 25. März 2004 21:17
An: VOITH, Thomas; 'Jon Rowland'; [email-masked]'
Betreff: RE: [Megaco] Auditing of CAS line states

Comments inline. [KJBII] 

Kevin 

-----Original Message-----

Jon,Kevin 

[KJBII] So... You are proposing destroying existing implementations then?

Do you report winks ?? 

[KJBII] I do not see how winks would get reported in EITHER methodology
without counting them. 
[TV] In case the EventsDescriptor is used for getting line state, the
parallel active winks are known to the MG, so MG can report the the line
state in a correct way. Just using an Audit, this information is missing.
[KJBII] So... Winks change the line state?  That would be akin to flash
changing the line state in the on/off-hook case you are trying to draw
parallels to.  I do not believe this is the case.  Just like flash, short
winks do not change the overall line state, which is what you are trying to
recover.

[TV] That means only states with minimum 400-500 ms  will be reported as
long the MG has not the information which kind of wink are also possible.
Doing with the EventsDescriptor, the MG looks for the longest winks and MG
has to wait minimum this time before it can report the line state. In case
an Audit with wildcards is used, this is not longer a simple snapshot.
[KJBII] Again, if we take the flash case from lines, the same problem exists
here -- there is NO way for the MGC to figure out that a flash occurred
while the MGC and MG were out of sync.

[KJBII] Huh?  The states are clearly defined now via the Signals and Events
descriptors.  Making a property that reflects the current state would cover
all possibilities.  I do not see how this is not sufficient.
[TV] An EventDescriptor can be active in parallel. In case you audit the
line signal state you could get audit and Notifies in "parallel".
An audit descriptor usually do not have a time stamp information. Doing all
with EventsDescriptor would not raise such a situation.
[KJBII] There will ALWAYS be a race condition, no matter what methodology is
adapted here.  I do not think the problem is large enough to warrant
invalidating existing implementations.

[KJBII] What, exactly, are you trying to accomplish?  We are talking about
recovering from a failure scenario.  In a failure scenario, there will
always be cleanup and uncertainty.  I don't see any reduction of that
uncertainly unless you are proposing mandating that the line signaling
events operate as "state", in which case we don't need to define the
parameter, the definition of the line signal events would have to be changed
to make that mandate.
[TV] In case strict is used, the "state" is used for all states different
from states in MGC.
[KJBII] Once again: the strict parameter for on and off-hook has more than
one possible value.  It sounds like you favor mandating "state". 

[KJBII] Again, if these do not change the current line state, then who
cares? 
[TV] It exists so many different CAS signaling variants.  I know only a very
small subset, but they are so different in respect to static and wink
signals changing the line state. I would prefer a solution from which I know
it would be a good basis for all further extensions.
[KJBII] However, just like flash, the line returns to its previous state --
we are looking for the distinct states, not intermittent "flashes" that have
only temporary impact upon the call signaling.

One example in detail: 
---------------------

[KJBII] Are you suggesting we mandate auditing, too?  This is roaming into
implementation mandates, which I am REALLY uncomfortable with.
[TV] My intention was not to affix implementation arguments to this
discussion. In my opinion Signal and Events should exclusively treated by
Events/Signal Descriptor and not via an Audit. What I miss is the continuity
of basic mechanism over packages using similar solutions. 
Arguing with implementation is not a good way from my side, so forget this
example. 

[KJBII] Umm... There is NO strict parameter for any event in the package.
If your implementation uses it, it is NON-COMPLIANT.
[TV] You know I made this proposal last year, since in my opinion really a
lack in this package.
[KJBII] Whether you proposed it or not is not the point.  Again, I state
that there is no strict parameter in the package.  Therefore, using one is a
deviation from the package and is, therefore, non-compliant.

[KJBII] It seems to me that if the audit returns a state that is different
from what the MGC is expecting, that it would know that it is misaligned.

[KJBII] This can be done anyway... 
[TV] This decision is made due to the information, that MGC was misaligned.
[KJBII] Right... Which can be determined via audit.

[KJBII] Compliant implementations would use the descriptors as defined in
the package.  I don't see where there is a "how you use" component.
[TV]  What I meant here is, implementation just using next expected state
(good case) versus implementation which uses the full set of possible states
occurring on line (good case + bad cases).
[KJBII] Implementations already must account for transition to an unexpected
state.  Any implementation that doesn't is asking for trouble.  This is
outside the scope of the current debate.

In general it remains the question, whether Audit is the right place for
polling signal states on MG. 

[KJBII] It seems pretty clear to me that the way forward is to introduce
read-only properties into the BCAS and ICAS packages to reflect the line
state.  I still do not see the need for the strict parameter -- the
functionality you seek is available in a combination of the line signaling
events and the casfail event today.
[TV] Does this also mean in consequence, that for "al/of al/on" , such an
audit is also missing ?
For the al package it is no need to introduce an audit, because 'strict'
parameter is defined.
It is REALLY strange to me solving similar problems with different
approaches.
Please not I am not strong against an Audit, but this would be to my
knowledge the first package auditing signalling interface states via audit
parameter.
[KJBII] Keep in mind that for lines, there are only two states: on-hook and
off-hook.  So it is relatively easy to protect against mismatch using a
parameter of this type.  For R1 and North American CAS there are 4 states
and for R2 and its many variants there are even more.  Using strict will
tell the MGC that there is a mismatch -- but will NOT tell the MGC WHICH
state the MG is in.  If the intent is to try to "save" calls, then an audit
is the only way forward.  If the intent is just to figure out that there is
a mismatch, that package is already capable of doing this today.

Regards 

Thomas 

-----Ursprüngliche Nachricht-----
Von: Jon Rowland [ mailto:[email-masked]
<mailto:[email-masked]> ] Gesendet am: Mittwoch, 24. März
2004 11:22
An: 'VOITH, Thomas'; 'Kevin Boyle'; [email-masked]' 
Betreff: RE: [Megaco] Auditing of CAS line states 

Kevin, 

Thomas, 

to be. 

Thanks,
Jon. 

-----Original Message-----

Kevin, Jon 
  
I have the feeling we do mix different approaches. 
My way is to try use the Events/Signal Descripors in a way to be notified
for each state change. Otherwise you are forced to audit states in case the
MGC has the "feeling" that a different line state exist. That's for me not
an equivalent to a signalling interface. 
  
If Megaco is not able with Events/Signals Descriptors to report ALL state
changes to MGC, then Megaco is not a good candidate to be used as signalling
interface like CAS. 
  
First goal should be to define the Events/Signals Descriptors  in a way so
that an audit afterwards is not necessary. 
If this approach is used you could have an audit in addition, but it is not
really necessary. 
  
Regards 
  
Thomas 

-----Ursprüngliche Nachricht-----
Von: Kevin Boyle [ mailto:[email-masked]
<mailto:[email-masked]> ] Gesendet am: Dienstag, 23. März 2004
20:54
An: VOITH, Thomas; 'Jon Rowland'; [email-masked]' 
Betreff: RE: [Megaco] Auditing of CAS line states 

Kevin 

-----Original Message-----
From: VOITH, Thomas [ mailto:[email-masked]
<mailto:[email-masked]> < mailto:[email-masked]
<mailto:[email-masked]> > ]
Sent: Monday, March 22, 2004 4:39 AM
To: 'Jon Rowland'; VOITH, Thomas; [email-masked]' 
Subject: AW: [Megaco] Auditing of CAS line states 

Hello Jon 

is fix. 

will be notified. 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht-----
<mailto:[email-masked]> > ] Gesendet am: Freitag, 19. März
2004 17:48

Thomas, 

Thanks for the reply. 

Thanks,
Jon Rowland. 

-----Original Message----- 

Hello Jon 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 

transition has occurred.

---

From: "Kevin Boyle" <[email-masked]>
Date: Mon, 29 Mar 2004 09:53:22 -0500

Kevin

-----Original Message-----
From: VOITH, Thomas [mailto:[email-masked]] 
Sent: Monday, March 29, 2004 6:16 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; VOITH, Thomas; 'Jon Rowland';
[email-masked]'

Hello 
 
Comments inline
 
Regards
 
Thomas

-----Ursprüngliche Nachricht-----
Von: Kevin Boyle [mailto:[email-masked]]
Gesendet am: Donnerstag, 25. März 2004 21:17
An: VOITH, Thomas; 'Jon Rowland'; [email-masked]'
Betreff: RE: [Megaco] Auditing of CAS line states

Comments inline. [KJBII] 

Kevin 

-----Original Message-----

Jon,Kevin 

Do you report winks ?? 

One example in detail: 
---------------------

Regards 

Thomas 

-----Ursprüngliche Nachricht-----

Kevin, 

Thomas, 

to be. 

Thanks,
Jon. 

-----Original Message-----

Kevin, Jon 

  
  
Regards 
  
Thomas 

-----Ursprüngliche Nachricht-----

Kevin 

-----Original Message-----

Hello Jon 

is fix. 

will be notified. 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht-----

Thomas, 

Thanks for the reply. 

Thanks,
Jon Rowland. 

-----Original Message----- 

Hello Jon 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 

transition has occurred.

---

From: "Kevin Boyle" <[email-masked]>
Date: Mon, 29 Mar 2004 11:20:42 -0500

I will draft a contribution to the May meeting suggesting a new version of
the BCAS and ICAS packages to include read-only properties.
 
Kevin

  _____  

From: Jon Rowland [mailto:[email-masked]] 
Sent: Monday, March 29, 2004 10:27 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; VOITH, Thomas; [email-masked]'
Subject: RE: [Megaco] Auditing of CAS line states

Hi chaps,
 
A couple of comments on my view of things to add into the mix:
 
- The BCAS and ICAS packages as currently defined already include the
behaviour defined by 'strict=state' in the al package. Each CAS event
includes the following text:
"The event is reported by the MG if either the timed transition to this line
signal is detected or the line signal already exists".
This means the behaviour that Thomas wants is already present, and there is
no need to add any new parameters to the package from this point of view.
 
- I think, Kevin, you've hit the nail on the head in your last comment
below. The key difference between using the EventsDescriptor method Thomas
advocates and our preferred audit mechanism is that the audit tells you what
the state *is* rather than what it *is not*. For protocols with more than 2
states (unlike al/on, al/of) this is a crucial difference, where the audit
allows the MGC full knowledge, but the EventsDescriptor does not.
 
Therefore, to my mind the issue is resolved:
- The strict=state behaviour is useful, but is already present, so no change
is required.
- Auditable properties are required for exact CAS state resynchronisation
between MGC and MG because there are >2 states possible (seize, idle,
answer).
 
Therefore the action should be to add a read-only property to the BCAS and
ICAS packages to allow the line state to be audited.
 
Agreed?
 
Jon.

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: 29 March 2004 15:53
To: VOITH, Thomas; VOITH, Thomas; Jon Rowland; [email-masked]'
Subject: RE: [Megaco] Auditing of CAS line states

Kevin 

-----Original Message----- 
From: VOITH, Thomas [mailto:[email-masked]

Hello 
  
Comments inline 
  
Regards 
  
Thomas 

-----Ursprüngliche Nachricht----- 
Von: Kevin Boyle [mailto:[email-masked]

Comments inline. [KJBII] 

Kevin 

-----Original Message----- 
<mailto:[email-masked]>  <mailto:[email-masked]

Jon,Kevin 

Do you report winks ?? 

One example in detail: 
--------------------- 

Regards 

Thomas 

-----Ursprüngliche Nachricht----- 
Von: Jon Rowland [ mailto:[email-masked]
<mailto:[email-masked]>  
<mailto:[email-masked]
<mailto:[email-masked]> > ] Gesendet am: Mittwoch, 24. März
2004 11:22 
An: 'VOITH, Thomas'; 'Kevin Boyle'; [email-masked]' 
Betreff: RE: [Megaco] Auditing of CAS line states 

Kevin, 

Thomas, 

to be. 

Thanks, 
Jon. 

-----Original Message----- 
<mailto:[email-masked]>  <mailto:[email-masked]

Kevin, Jon 

  
Regards 
  
Thomas 

-----Ursprüngliche Nachricht----- 
Von: Kevin Boyle [ mailto:[email-masked]
<mailto:[email-masked]>  <mailto:[email-masked]
<mailto:[email-masked]> > ] Gesendet am: Dienstag, 23. März 2004
20:54

Kevin 

-----Original Message----- 
From: VOITH, Thomas [ mailto:[email-masked]
<mailto:[email-masked]>  <mailto:[email-masked]
<mailto:[email-masked]> > < mailto:[email-masked]
<mailto:[email-masked]>  <mailto:[email-masked]
<mailto:[email-masked]> > > ]

Hello Jon 

is fix. 

will be notified. 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 
Von: Jon Rowland [ mailto:[email-masked]
<mailto:[email-masked]>  
<mailto:[email-masked]
<mailto:[email-masked]> > 
< mailto:[email-masked]
<mailto:[email-masked]>  
<mailto:[email-masked]
<mailto:[email-masked]> > > ] Gesendet am: Freitag, 19. März
2004 17:48 
An: 'VOITH, Thomas'; [email-masked]' 
Betreff: RE: [Megaco] Auditing of CAS line states 

Thomas, 

Thanks for the reply. 

Thanks, 
Jon Rowland. 

-----Original Message----- 
From: VOITH, Thomas [ mailto:[email-masked]
<mailto:[email-masked]>  
<mailto:[email-masked] <mailto:[email-masked]> >  
< mailto:[email-masked] <mailto:[email-masked]>
<mailto:[email-masked] <mailto:[email-masked]> > > ] 
Sent: 18 March 2004 08:06 
To: Jon Rowland; [email-masked]' 
Subject: AW: [Megaco] Auditing of CAS line states 

Hello Jon 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 
Von: Jon Rowland [ mailto:[email-masked]
<mailto:[email-masked]>  
<mailto:[email-masked]
<mailto:[email-masked]> >  
< mailto:[email-masked]
<mailto:[email-masked]>  
<mailto:[email-masked]
<mailto:[email-masked]> > > ] 
Gesendet am: Mittwoch, 17. März 2004 17:33 
An: [email-masked]' 
Betreff: [Megaco] Auditing of CAS line states 

transition has occurred. 
<http://www.metaswitch.com>  
<http://www.metaswitch.com <http://www.metaswitch.com> >  
< http://www.metaswitch.com <http://www.metaswitch.com>
<http://www.metaswitch.com <http://www.metaswitch.com> > >  

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

____________________________________________________________ 
          _ 
          V                 | Thomas Voith 
  +---------------+         | Dept. ZFZ/A 
  | A L C A T E L |         | EG/102 
  +---------------+         | 
                            | Tel:   +49 711 821-40293 
Alcatel SEL AG              | Fax:   +49 711 821-32453 
Research & Innovation       | 
Holderaeckerstr. 35         | mailto:[email-masked]
<mailto:[email-masked]>  
<mailto:[email-masked] <mailto:[email-masked]> >  
< mailto:[email-masked] <mailto:[email-masked]>
<mailto:[email-masked] <mailto:[email-masked]> > >  
D-70499 Stuttgart, Germany  | 
------------------------------------------------------------ 

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

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

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

<https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Kevin Boyle" <[email-masked]>
Date: Mon, 29 Mar 2004 11:20:42 -0500

Kevin

  _____  

Hi chaps,

 

 
Agreed?
 
Jon.

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: 29 March 2004 15:53
To: VOITH, Thomas; VOITH, Thomas; Jon Rowland; [email-masked]'
Subject: RE: [Megaco] Auditing of CAS line states

Kevin 

-----Original Message----- 

Hello 
  
Comments inline 
  
Regards 
  
Thomas 

-----Ursprüngliche Nachricht----- 

Comments inline. [KJBII] 

Kevin 

-----Original Message----- 

Jon,Kevin 

Do you report winks ?? 

One example in detail: 
--------------------- 

Regards 

Thomas 

-----Ursprüngliche Nachricht----- 

Kevin, 

Thomas, 

to be. 

Thanks, 
Jon. 

-----Original Message----- 

Kevin, Jon 

  
Regards 
  
Thomas 

-----Ursprüngliche Nachricht----- 

Kevin 

-----Original Message----- 

Hello Jon 

is fix. 

will be notified. 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 

Thomas, 

Thanks for the reply. 

Thanks, 
Jon Rowland. 

-----Original Message----- 

Hello Jon 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 

transition has occurred.

---

From: "VOITH, Thomas" <[email-masked]>
Date: Tue, 30 Mar 2004 09:11:37 +0200

Agreed  
 
Thomas

-----Ursprüngliche Nachricht-----
Von: Kevin Boyle [mailto:[email-masked]]
Gesendet am: Montag, 29. März 2004 18:21
An: Jon Rowland; VOITH, Thomas; [email-masked]'
Betreff: RE: [Megaco] Auditing of CAS line states

Kevin

  _____  

Hi chaps,

 

 
Agreed?
 
Jon.

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: 29 March 2004 15:53
To: VOITH, Thomas; VOITH, Thomas; Jon Rowland; [email-masked]'
Subject: RE: [Megaco] Auditing of CAS line states

Kevin 

-----Original Message----- 

Hello 
  
Comments inline 
  
Regards 
  
Thomas 

-----Ursprüngliche Nachricht----- 

Comments inline. [KJBII] 

Kevin 

-----Original Message----- 

Jon,Kevin 

Do you report winks ?? 

One example in detail: 
--------------------- 

Regards 

Thomas 

-----Ursprüngliche Nachricht----- 

Kevin, 

Thomas, 

to be. 

Thanks, 
Jon. 

-----Original Message----- 

Kevin, Jon 

  
Regards 
  
Thomas 

-----Ursprüngliche Nachricht----- 
Von: Kevin Boyle [ mailto:[email-masked]
<mailto:[email-masked]>  < mailto:[email-masked]
<mailto:[email-masked]> > ] Gesendet am: Dienstag, 23. März 2004
20:54

Kevin 

-----Original Message----- 

Hello Jon 

is fix. 

will be notified. 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 

Thomas, 

Thanks for the reply. 

Thanks, 
Jon Rowland. 

-----Original Message----- 
From: VOITH, Thomas [ mailto:[email-masked]
<mailto:[email-masked]>  
< mailto:[email-masked] <mailto:[email-masked]> >  
< mailto:[email-masked] <mailto:[email-masked]>  <
mailto:[email-masked] <mailto:[email-masked]> > > ] 
Sent: 18 March 2004 08:06 
To: Jon Rowland; [email-masked]' 
Subject: AW: [Megaco] Auditing of CAS line states 

Hello Jon 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 

transition has occurred. 
<http://www.metaswitch.com>  
< http://www.metaswitch.com <http://www.metaswitch.com> >  
< http://www.metaswitch.com <http://www.metaswitch.com>  <
http://www.metaswitch.com <http://www.metaswitch.com> > >  

< mailto:[email-masked] <mailto:[email-masked]>  <
mailto:[email-masked] <mailto:[email-masked]> > >

---

From: "VOITH, Thomas" <[email-masked]>
Date: Tue, 30 Mar 2004 09:11:37 +0200

Agreed  
 
Thomas

-----Ursprüngliche Nachricht-----
Von: Kevin Boyle [mailto:[email-masked]]
Gesendet am: Montag, 29. März 2004 18:21
An: Jon Rowland; VOITH, Thomas; [email-masked]'
Betreff: RE: [Megaco] Auditing of CAS line states

Kevin

  _____  

Hi chaps,

 

 
Agreed?
 
Jon.

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: 29 March 2004 15:53
To: VOITH, Thomas; VOITH, Thomas; Jon Rowland; [email-masked]'
Subject: RE: [Megaco] Auditing of CAS line states

Kevin 

-----Original Message----- 

Hello 
  
Comments inline 
  
Regards 
  
Thomas 

-----Ursprüngliche Nachricht----- 

Comments inline. [KJBII] 

Kevin 

-----Original Message----- 

Jon,Kevin 

Do you report winks ?? 

One example in detail: 
--------------------- 

Regards 

Thomas 

-----Ursprüngliche Nachricht----- 

Kevin, 

Thomas, 

to be. 

Thanks, 
Jon. 

-----Original Message----- 

Kevin, Jon 

  
Regards 
  
Thomas 

-----Ursprüngliche Nachricht----- 

Kevin 

-----Original Message----- 

Hello Jon 

is fix. 

will be notified. 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 

Thomas, 

Thanks for the reply. 

Thanks, 
Jon Rowland. 

-----Original Message----- 

Hello Jon 

Regards 

Thomas Voith 

-----Ursprüngliche Nachricht----- 

transition has occurred.