Subject: RE: Query Related to Parameters in Signal Descriptor

From: "Kevin Boyle" <[email-masked]>
Date: Thu, 28 Jun 2001 10:47:40 -0400

Why is there a substantial difference between "timeout" and "ended on its
own"?  Signals of type TO will "timeout"; signals of type BR will "end on
its own"; signals of type OO will not end unless interrupted by an event or
a new signals descriptor.

In the example given by Terry, the voice announcement should be a BR signal
-- one that has a finite length and does not repeat.  Timeout signals repeat
until they reach their timeout duration, for example, playing dial tone for
16 seconds.

Essentially, therefore, "timeout" and "ended on its own" are exactly
functionally equivalent, with one applying to TO signals, and the other to
BR signals.

That being the case, I see no reason to alter what Terry has proposed.

Kevin

-----Original Message-----
From: Sarju Garg [mailto:[email-masked]] 
Sent: Thursday, June 28, 2001 1:21 AM
To: Terry L Anderson
Cc: 'megaco'
Subject: Re: Query Related to Parameters in Signal Descriptor

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
----- Original Message -----
From: Terry L Anderson <[email-masked]>
To: Sarju Garg <[email-masked]>
Cc: 'megaco' <[email-masked]>
Sent: Wednesday, June 27, 2001 7:19 PM
Subject: Re: Query Related to Parameters in Signal Descriptor

>
>
> 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
> >
> >  ;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?
>
> 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).
>
> >
> >
> > TIA
> >
> > Sarju
> >
> >
>
> --
> ------------------------------------------------------------
> 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: Terry L Anderson <[email-masked]>
Date: Thu, 28 Jun 2001 16:24:12 -0400

Kevin Boyle wrote:

> Why is there a substantial difference between "timeout" and "ended on
> its own"?  Signals of type TO will "timeout"; signals of type BR will
> "end on its own"; signals of type OO will not end unless interrupted
> by an event or a new signals descriptor.
>
> In the example given by Terry, the voice announcement should be a BR
> signal -- one that has a finite length and does not repeat.  Timeout
> signals repeat until they reach their timeout duration, for example,
> playing dial tone for 16 seconds.

I would have also thought voice announcements would nomally use BR, but
some seem to think that they should be TO (with the provisioned
"duration" being their natural length so they would not repeat unless an
explicit duration is given).  For example,  Annex K specifies that
an/apv is default TO.  But in either case (BR or TO with default
duration) the behavior is same.

> functionally equivalent, with one applying to TO signals, and the
> other to BR signals.
>