Re: Modify to do Audit hook state

"Raphael Tryster" <[email protected]>
Newsgroups gmane.ietf.megaco
Message-ID <[email protected]>
Hi Kevin,

I would like to clarify the "yes" answer you gave to Pascal's question 5
years ago, because I think the answer to his precise question is "no".

What I mean is: "Yes", if you are an MGC and want to use Modify to audit
the hook state, then you have to include any events previously present
in the Events descriptor in order to guarantee their continued
detection.

However: "No", it is NOT true that if the MG returns an error
"termination already off/on hook", the MGC has no longer any guarantee
as to which events are still programmed on the termination.  This is
because IN THE SPECIFIC CASE THAT THE MG HAS REPLIED WITH ERROR 540, the
MGC KNOWS that the old events descriptor was NOT replaced, because the
command failed.

The motivation for this clarification is to verify that an MG that
returns error 540 and later notifies an event based on the events
descriptor in the command that failed, is behaving incorrectly.

Regards,
Raphael

-----Original Message-----
From: Kevin Boyle [mailto:[email protected]] 
Sent: Wednesday, 18 August 2004 12:50 AM
To: Pascal Lambers; [email protected]
Subject: RE: [Megaco] Modify to do Audit hook state

The MGC would have to include any events previously present in the
Events
descriptor in order to guarantee their continued detection, yes.

Kevin 

-----Original Message-----
From: Pascal Lambers [mailto:[email protected]] 
Sent: Tuesday, August 17, 2004 5:03 PM
To: [email protected]
Subject: Re: [Megaco] Modify to do Audit hook state

Kevin,

"The MGC must account for these kinds of issues when it is building
messages".
By this you mean, that if the MG returns an error "termination allready
off/on hook", the MGC has no longer any guarantee as to which events are
still programmed on the termination?

If so, the strict/exact and strict/state won't be of any help I'm
afraid:
the Modify will always overwrite events that were present on the
termination
before... and if the MGC just sent this Modify to know whether the hook
status of a termination is still as it expected, without taking anything
else, this is a problem. Do I interpret this correctly?

Pascal


----- Original Message -----
From: "Kevin Boyle" <[email protected]>
To: "Pascal Lambers" <[email protected]>; <[email protected]>
Sent: Tuesday, August 17, 2004 10:45 PM
Subject: RE: [Megaco] Modify to do Audit hook state


> The MGC must account for these kinds of issues when it is building
messages.
>
> I would note that there are two other possible values for the strict
parm
> that may be of more use: 'state' and 'exact'.  If having the MG
generate
> errors is a problem, then you could use one of the other two options
> instead.
>
> Kevin
>
>
>
>   _____
>
> From: Pascal Lambers [mailto:[email protected]]
> Sent: Tuesday, August 17, 2004 4:32 PM
> To: [email protected]
> Subject: [Megaco] Modify to do Audit hook state
>
>
> Hello,
>
> Megaco does not provide an Audit message to audit a termination's hook
> status directly. That's clear.
>
> Instead, to know whether a termination is Off Hook, the MGC must send
a
> Modify with an Off Hook (strict/failWrong) Events descriptor.
Consequently,
> if the termination is already off hook, the MG will reply with an
error.
Is
> it sure that in such a case the events and signals implemented on this
> termination before the Modify arrived, are still present? In other
words,
is
> it sure that messages from the MGC to the MG replied to with an error
do
not
> have any negative effect?
>
> Kind regards,
> Pascal
>
>
>
>
> _______________________________________________
> Megaco mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/megaco
>


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

_______________________________________________
Megaco mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/megaco
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.