Subject: Query Related to Parameters in Signal Descriptor

From: "Sarju Garg" <[email-masked]>
Date: Wed, 27 Jun 2001 17:55:31 +0530

Hi all,

I have a following query related to "notifyCompletion" Parameter in Signal Descriptor:
The Annex B says:
 
signalsDescriptor    = SignalsToken LBRKT [ signalParm  *(COMMA signalParm)] RBRKT
signalParm           = signalList / signalRequest

signalRequest        = signalName [ LBRKT sigParameter      *(COMMA sigParameter) RBRKT ]

signalList           = SignalListToken EQUAL signalListId LBRKT  signalListParm *(COMMA signalListParm) RBRKT

signalListId         = UINT16

 ;exactly once signalType, at most once duration and every signal;parameter

signalListParm       = signalRequest

 signalName           = pkgdName

;at-most-once sigStream, at-most-once sigSignalType,

;at-most-once sigDuration, every signalParameterName at most once

sigParameter       = sigStream / sigSignalType / sigDuration / sigOther   / notifyCompletion / KeepActiveToken

sigStream            = StreamToken EQUAL StreamID

sigOther             = sigParameterName parmValue

sigParameterName     = NAME

sigSignalType        = SignalTypeToken EQUAL signalType

signalType           = (OnOffToken / TimeOutToken / BriefToken)

sigDuration          = DurationToken EQUAL UINT16

notifyCompletion     = NotifyCompletionToken EQUAL (LBRKT   notificationReason *(COMMA notificationReason) RBRKT)

 notificationReason   = ( TimeOutToken / InterruptByEventToken   / InterruptByNewSignalsDescrToken  / OtherReasonToken )

My query is related to comment above the sigParameter. Does the comment mean that notifyCompletion and keepActiveToken can come multiple times? 

Also what does notifyCompletion parameter means? I understand that it allows MGC to request MG to indicate that MGC is interested in signal completion notification. I understand that MGC is not interested in specifying the failure cases. Consider a case that MGC specifies notifyCompletion parameter with TimeOutToken. Suppose the signal is played out successfully. What does MG do in that case? I think notification is only done in failure cases and not for successful case? Please verify. If so, that in the above case, if the signal fails for other reason apart from TimeOut what should MG do now? Do it need to send completion event in that case. Can anyone clarify how to use this parameter?

TIA

Sarju

---

From: Terry L Anderson <[email-masked]>
Date: Wed, 27 Jun 2001 09:49:11 -0400

Sarju Garg wrote:

> Hi all, I have a following query related to "notifyCompletion"
> Parameter in Signal Descriptor:The Annex B says: signalsDescriptor=
> SignalsToken LBRKT [ signalParm*(COMMA signalParm)] RBRKT
> signalParm= signalList / signalRequest
>
> signalRequest= signalName [ LBRKT sigParameter *(COMMA sigParameter)
> RBRKT ]
>
> signalList= SignalListToken EQUAL signalListId LBRKT signalListParm
> *(COMMA signalListParm) RBRKT
>
> signalListId= UINT16
>
> signalListParm= signalRequest
>
>  signalName= pkgdName
>
> sigParameter= sigStream / sigSignalType / sigDuration / sigOther/
> notifyCompletion / KeepActiveToken
>
> sigStream= StreamToken EQUAL StreamID
>
> sigOther= sigParameterName parmValue
>
> sigParameterName= NAME
>
> sigSignalType= SignalTypeToken EQUAL signalType
>
> signalType= (OnOffToken / TimeOutToken / BriefToken)
>
> sigDuration= DurationToken EQUAL UINT16
>
> notifyCompletion= NotifyCompletionToken EQUAL
> (LBRKT notificationReason *(COMMA notificationReason) RBRKT)
>
>  notificationReason= ( TimeOutToken / InterruptByEventToken/
> InterruptByNewSignalsDescrToken/ OtherReasonToken )
>
> My query is related to comment above the sigParameter. Does the
> comment mean that notifyCompletion and keepActiveToken can come
> multiple times?
>
> Also what does notifyCompletion parameter means? I understand that it
> allows MGC to request MG to indicate that MGC is interested in signal
> completion notification. I understand that MGC is not interested in
> specifying the failure cases. Consider a case that MGC specifies
> notifyCompletion parameter with TimeOutToken. Suppose the signal is
> played out successfully. What does MG do in that case? I think
> notification is only done in failure cases and not for successful
> case? Please verify. If so, that in the above case, if the signal
> fails for other reason apart from TimeOut what should MG do now? Do it
> need to send completion event in that case. Can anyone clarify how to
> use this parameter?

I believe that there is only one case not covered by the current
language: the one where a signal ends normally but where it is not
explicitly timed, e.g., a voice announcement file plays to its end.  In
a recent discussion, we agreed that this should be treated the same as a
signal that completed due to time, that is, NotifyCompletion{TimeOut}
and g/sc{Meth=TO}.  I have changed the sentence in 7.1.11:
    "The possible cases are that the signal timed out (or otherwise
ended on its own)..."

and changed the description for "TO" in E.1.2 to:
    "Signal Timed out or otherwise ended on its own"

in the Implementors Guide to make this understanding explicit (of course
that will not be officially approved until the next IG is approved in
Feb 2002).

--
------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

---

From: "Sarju Garg" <[email-masked]>
Date: Thu, 28 Jun 2001 10:50:59 +0530

Thanks Terry for your reply.

How does MGC know in that case that the signal haved played out successfully
or timeout?

If the signal fails for other reason apart from that mentioned by MGC then
what should MG do ? Do it need to send completion event in that case also?.

 I think the logic should be as follows:
MGC should specify whether it wants notification for the signal playout for
both successful/unsuccessful cases?. It must only specify the optional
parameter "NotificationCompletionToken" and not the notificationReason as of
now. Now, after the MG plays the signal out, then it sends
NotificationCompletion with reason set to "signal ended on its own".In case
the MG finds some error it sends NotificationCompletion with reason set to
"one of 4 mentioned reasons". TO and signal ended on its own should be two
different cases and not one.

Also please let me know the answer of my question related to comment over
the sigParameter. I think the comment should be modified to:
;one or more sigother with every signalParameterName at most once
; other sigParameter at most once.

TIA
Sarju

---

From: Terry L Anderson <[email-masked]>
Date: Thu, 28 Jun 2001 13:30:30 -0400

> How does MGC know in that case that the signal haved played out successfully

Most signals that have a natural end (voice file) would not also have a
provisioned duration.  The time to natural end could be considered effectively
the provisioned duration.  For such signals the MGC should not send an explicit
duration as part of the Signals Descriptor, but if it does then the signal would
end when the explicit duration expired (including repeating the message or part
of it if necessary to complete the time).  With no explicit duration, then the
call would "timeout" when it reached the natural end.  In either case the reason
would be timeout with no distinction.

> what should MG do ? Do it need to send completion event in that case also?.

If NotifyCompletion is omitted but g/sc is on the event list, then MG notifies
ONLY for OtherReason (typically errors).  If NotifyCompletion is included then
it notifies for the indicated reasons (Termination Method).  If OtherReason is
not included in the list then the MG would not notify for these.  Essentially
OtherReason can be considered the default if NotifyCompletion is omitted.
OtherReason is the reason whenever the the other three do not apply, but was
only intended for abnormal/error terminations.

> different cases and not one.

Interesting alterative, but not what was chosen for the standard.

NotifyCompletion is, of course, not an event.  So for ANY notification one must
define an event.  One is available in generic package, g/sc.  If it, or some
other package event, is not on the event list, then no notification can occur.
Adding g/sc to the event list and specifying
NotifyCompletion={TimeOut,IntByEvent,IntBySigDescr,OtherReason} would result in
exactly what you want (except for the additional "signal ended on its own"
reason.  Ending due to TimeOut is certainly not considered an error.  It is the
natural end for many signals (DTMF digits, Call Waiting Tone, etc.)  For many,
the  signal end is naturally defined by time and for others by coming to the end
of a digitized signal file - the distinction is minor.  In neither case, does
MGC need to specify a duration.  Where it DOES, it is choosing to override the
natural (provisioned) duration.

> ; other sigParameter at most once.

Is you point that, notifyCompletion and KeepActiveToken should also be "at most
once"?
or a different wording for the restriction on sigOther?
or both?

I cannot think of a reason for notifyCompletion or KeepActiveToken being more
than once so I believe I agree with that part.  Anyone know of a reason they
were NOT make at most once?
I believe the sigOther restriction is the same as what you state.  Not sure it
needs changed.