Subject: g/sc SigID list

From: Troy Cauble <[email-masked]>
Date: Wed, 13 Jun 2001 09:15:27 -0400

Proposal:

Change the Type of the g/sc SigId parameter in E.1.2 
from "list" to "string".

Argument:

Sections 12.1.2 and 12.2 define allowable types
for Properties and Parameters, including "String"
and "Sub-list".

Annex E.1.2 (g/sc) defines parameter SigID as
being a "list" and references a complex syntax for
that "list" which includes nested braces.

This specific syntax conflicts with the established 
syntax for a list.

   parmValue            = (EQUAL alternativeValue/ INEQUAL VALUE)
   alternativeValue     = ( VALUE
                          / LSBRKT VALUE *(COMMA VALUE) RSBRKT
                            ; sublist (i.e. A AND B AND ...)
                          / LBRKT VALUE *(COMMA VALUE) RBRKT
                            ; alternatives (i.e. A OR B OR ...)
                          / LSBRKT VALUE COLON VALUE RSBRKT )
                            ; range

If the type is redefined as "String", double quotes
will be required (IG 6.80).  Within that quotedString, 
the syntax could stay as defined.

Besides the fact that this syntax is in direct conflict
of the ABNF specification,  I think it is unreasonable 
to allow a package to define a complex syntax to be 
embedded directly in a VALUE without quoting.  Parsers 
should be able to parse the message down to the VALUE
level without package knowledge.

Comments?

-troy

---

From: Troy Cauble <[email-masked]>
Date: Wed, 13 Jun 2001 11:04:43 -0400

BTW, here are some uses that I think are consistent with 
the syntax description in E.1.2.  Anyone care to comment?
This is vague enough in E.1.2 that it should be clarified
with some examples.

Note that a sublist uses [] not {} according to the ABNF
for alternativeValue.

1.Reporting a signal outside of sequential signal list:
SigID="pkg1/sig1"

2.Reporting a  signal inside a sequential signal list:
SigID="SignalList = 1 {pkg1/sig1}"

3.Reporting a  list of signals outside of sequential signal list:
SigID=[ "pkg1/sig1" , "pkg2/sig2" ]

4.Reporting a  list of signals inside a sequential signal list:
SigID=[ "SignalList = 1 {pkg1/sig1}", "SignalList = 2 {pkg2/sig2}" ]

5.Reporting a list of both signals and sequential signal lists:
SigID=[ "pkg1/sig1" , "pkg2/sig2", "SignalList = 1 {pkg3/sig3}", 
"SignalList = 2 {pkg4/sig4}" ]

-troy

---

From: Troy Cauble <[email-masked]>
Date: Wed, 13 Jun 2001 11:27:41 -0400

New proposal:

Change the Type of the g/sc SigId parameter in E.1.2
from "list" to "string or list of strings".  
Clarify syntax with examples below.

Objections?

-troy

---

From: Terry L Anderson <[email-masked]>
Date: Wed, 13 Jun 2001 14:53:02 -0400

While were on the topic of signal completion events, what is the correct
notificationReason and corresponding g/sc Meth value for the completion of
a Brief signal?  I assume an on/off signal normally completes with SD and
NotifyCompletion={IntBySigDescr} since it ends by MGC sending a new or
empty signal descriptor and other signals can end this way.  I assume a
timeout signal normally complete with TO and NotifyCompletion={TimeOut}.

But what does a Brief signal normally end with?  NC and
NotifyCompletion={OtherReason}?  Seems odd to use this but none of the
others are appropriate.  The description of NC "Not completed, other
cause" seems odd since it DID complete.  Or is there no way to request a
completion event for Brief signals?

Perhaps I do not understand the proper use of these three types.  I am
puzzled by Annex K's announcements being listed as "OO, TO (default)".
Since these announcements will often be a voice file of finite duration,
they would normally play to end of file and quit.  This sounds like the
description of "brief".  On/Off requires a new signal descriptor to turn
it off.  TimeOut is "until turned off or a specific period of time
elapses".  That sounds like a provisioned time period rather than simply
end of file reached.  Or was TimeOut intended to cover this as well.  If
so what is Brief intended for?

--
------------------------------------------------------------
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: Troy Cauble <[email-masked]>
Date: Wed, 13 Jun 2001 15:19:47 -0400

> puzzled by Annex K's announcements being listed as "OO, TO (default)".

This was changed with IG section 9.1.

> so what is Brief intended for?

There was a discussion of the different signal types in the
thread "SignalType ?" from about 1/15/01 to 1/23/01.
Christian clarified some things there (IMO), but not everyone 
agreed.

I'm attaching one of his posts below.

-troy

Subject: Re: SignalType ?
From: Christian Groves <[email-masked]>
To: Troy Cauble <[email-masked]>
Cc: [email-masked]
Date: Mon, 22 Jan 2001 11:57:12 +1100

G'Day Troy,

Please see my answers below marked CHG.

Cheers, Christian

Troy Cauble wrote:
> 
> Christian Groves wrote:
> >
> > Hello Troy,
> >
> > The different between duration & OO, TO, BR is that duration gives times
> > and OO, TO, BR give essentially a number of times that something will
> > play.
> >
> > ie. S1 is a signal that plays a cadence for 100ms
> > {Duration 50ms, Signal Type = Br}  would play half the signal
> > {Duration 150ms, Signal Type = Br} would play one instance of the signal
> > and 50ms of silence.
> > {Duration 150ms, Signal Type = TO} would play one and a half instances
> > of the signal.
> > {Signal Type = OO} would keep playing instances of the signal.
> >
> > The H.248 is different to MGCP. We had alot of disucssion what br, to &
> > oo meant during the development of the protocol.
> >
> 
> Christian,
> 
> Thanks, this does clarify some things. The different
> SignalType values do make a difference in your 150ms
> examples.  But that's a funny way to specify silence!

[CHG] Yes it is a funny way. Its a function of the protocol but I don't
expect that you'd use it that way.

> 
> Is it correct then, that the ONLY behavioral difference
> between signals that are defined as Brief or Timeout
> in their package definitions, is their behavior when
> asked to play longer than their default duration with
> no explicit SignalType specification?
[CHG] Yes.

> 
>         { Duration 150ms }      ; Note: No SignalType
> 
> Also, is it correct that all three signal types are
> suitable for notifyCompletion?
[CHG] Yes I believe so. All signals have a finite period of time and the
MGC might like to be notified once the signals plays successfully.

---

From: Terry L Anderson <[email-masked]>
Date: Wed, 13 Jun 2001 15:52:37 -0400

> This was changed with IG section 9.1.

Yes, but only removed OO.  As I say below I don't understand how TO applies to a finite-length, non-repeating voice announcement file like "Please
enter the number you are calling".

> I'm attaching one of his posts below.

This explains some things but none of the cases apply to announcements or finite-length, non-repeating voice files.  Is it assumed that if optional
Duration is NOT specified for a TO then the assumed duration is exactly one instance of the file?  But then wouldn't Brief without Duration mean the
same thing?

If so, I guess g/sc would use Meth=TO for both TimeOut and Brief completions?

>
>
> -troy
>
>   ------------------------------------------------------------------------
>
> CC: [email-masked]
> References: <[email-masked]> <[email-masked]> <[email-masked]>
>
> G'Day Troy,
>

---

From: Christian Groves <[email-masked]>
Date: Mon, 18 Jun 2001 14:45:53 +1000

G'Day Troy,

I guess the question I have is who would encode multiple signalIDs in
one signal completion response? I can see the following cases are
realistic:
(a) Individual Signal outside of a list
(b) Individual Signal in list
(c) Whole list
The whole list case is handled by the SignalListID parameter. I'm
inclined to have g/sc(SigID) only have the signalID. This is a string.
If you need multiple indication of signal completion you'd have multiple
notifications.

Christian

---

From: Troy Cauble <[email-masked]>
Date: Mon, 18 Jun 2001 10:08:13 -0400

Christian,

Changing it to a single string sounds reasonable
but is more of a change.  I'd be happy with it,
but will others?

My proposal is just a clarification:  "List of what?"

-troy