Subject: Re: Packages Conference Call Minutes

From: [email-masked]
Date: Thu, 7 Oct 1999 13:48:51 +0530

Chip,
           Do we really need to go to the detail of "Tip Close", "Ring ON" etc
when defining packages for line
  signaling such as FXS/FXO, E&M etc ? Can't we use normal PSTN signaling terms
like "Seizure", "Wink",
  "Off hook", "On hook" etc. ? I feel that the MG should be intelligent enough
to handle the finer details of the
   Line signalling. the MGC should only be reported events that help it to run
its Call State machine.

  Regards,

Vikas Bajaj

Chip Sharp <[email-masked]> on 10/06/99 09:52:08 PM

Please respond to Chip Sharp <[email-masked]>

To:   [email-masked]
cc:    (bcc: Vikas Bajaj/HSS)

Subject:  Re: Packages Conference Call Minutes

In writing up an applicability statement for supporting T1 RBS with megaco,
I had some similar questions to ones that came up on conference call.
At 06:36 AM 10/5/99 -0500, Tom-PT Taylor wrote:
...snip...
>5. Event aliasing
>
>Tom Taylor pointed out that for FAX service, calling (CNG) and called (CED)
>tone events should be reported separately.  Roy Spitzer raised the objection
>that the CED tone is identical to modem answer signal.  We realized that
>this problem of event aliasing is more general, and requires a solution.
>The problem statement is this: a given physical event may correspond to more
>than one event as defined in one or more package specifications.  The MGC
>has some control over event reporting, in that it can state which events the
>MG should watch for.  If despite this the MGC supplies an event descriptor
>which sets up the event aliasing situation which of the following
>alternatives should we specify:
>
>(a) the MG should report the first applicable event it finds in the event
>descriptor;
>
>(b) the MG reports all of the applicable events;
>
>(c) we should add to the syntax so that the MGC can control which of (a) or
>(b) applies in a given situation;
>
>(d) none of the above -- some other solution.
>
>***Action: the list to indicate a preference.

When supporting Ground Start FXS signaling, the FXO indicates an incoming
call by seizing the line (Tip Close) and sending ring pattern.  I could
look for the following events to indicate an incoming call:

a) Only Tip Close.  This is the easiest since it is a single event.

b) Only Ring ON.  This is as simple as a) since it is a single event.  This
is how Loop Start will work.

c) Either Tip Close or Ring ON.  This is more difficult since it involves
telling the MG to look for one of two events and when one is detected stop
looking for the other.

d) Both Tip Close and Ring ON.  This is a little more difficult as well
since it means a dependency on two events before sending a Notify.

e) Tip Close and a certain number of Rings.  This gets deeper into the
difficulty level  since it requires dependency between one event and a
series of another event.

It isn't apparent how to do c, d or e with the current syntax.

Related to this is the question of how the MGC cancels an event.
Say for something like c, the MGC programs the MG to look for 2 events
(Event A and Event B).  When one of the events occurs (say Event A), the MG
notifies the MGC.  The MGC takes some action and wants to tell the MG to
stop looking for the other event (Event B). Theoretically, this could be
done by sending an empty Event Descriptor with the same Request ID;
however, this is not allowed in the syntax. Sending a Event Descriptor with
the same Request ID and with no eventAction specified could achieve the
same thing, but the text doesn't really say what to do if the MG gets such
a beast (this is another question below).

Item d could conceivably be accomplished with embeddedevents such as:

      Events = 2222 {
           FX/tc {
                Action { NotifyAction:
                     Event = 2223 {
                          FX/ri {
                               Action{NotifyAction:
                                    Signals{FX/rb}
                               }
                          }
                     },
                     Event = 2224 {
                          FX/to {
                               Action{NotifyAction:
                                    "Stop Event 2223"?
                               }
                          }
                     }
                }
           }
      }

      Events = 2225 {
           FX/ri {
                Action { NotifyAction:
                     Event = 2226 {
                          FX/tc {
                               Action{NotifyAction:
                                    Signals{FX/rb},
                                    Event = 2224 {
                                         FX/to {
                                              Action{NotifyAction:
                                                   Signals{}
                                              }
                                         }
                                    }
                               }
                          }
                     },
                }
           }
    }
The above doesn't even take into account the case when ringing stops.
FX/tc is Tip Close, FX/to is Tip Open, FX/ri is Ringing signal and FX/rb is
ringback.
Ringback wouldn't necessarily be sent out from here, but I use it in this
example to show how more embedding may need to be used.  As shown, several
layers of embedding is needed to program this behavior.  It isn't clear
whether or not the above encoding violates the embedding rules.

>7. Complex events
>
>Tom Taylor had proposed the creation of complex events comprising a sequence
>of events and signals with carefully pre-defined behaviour.  It was noted
>that this was a variation on the theme of scripting -- the feeling of the
>group seemed to be that it should not be done.  There is still the problem
>of ensuring that dial tone ends when the first digit is received.  In
>effect, this is a new class of behaviour added to the set {BR, OO, TO} which
>we have already defined.  Nancy pointed out that the protocol document
>already states that a signal stops being applied as soon as an event is
>detected [in an embedded descriptor? in an event descriptor in the same
>command? Have to check.].
>
>***Action: list to verify that existing behavioural specification is
>sufficient to meet requirements.

I believe the text says that an embeddedevent can be used for this.  A
signal in an embedded event stops when the event occurs.  The definition of
Accumulatebydigitmap implies that each digit is a separate event.  This
implies that the signal is stopped not only when the first digit is
received, but when each digit is received.  I'm sure creative programming
can get around this.

My guess as to how this would be coded is as follows.
This programs a channel on a T1 line to look for Loop Close.
When Loop Close is received, take the following steps:
      1.  Notify the MGC
      2.  Send Dial Tone Signal
      3.  Start Detecting Digits.
      4.  When first digit is detected, turn off Dial Tone.
      5.  When end of digits occurs, notify MGC.
          I actually don't see this explicitly defined
          but I'm assuming the Notify is implicit in
          the DigitMap action.
      6.  Notify MGC when Loop Open occurs.

Events = 2222 {
      FX/lc {
           Action { NotifyAction:
                Signals{FX/dt},
                Events=2223 {
                     FX/DTMF{
                          ACTION{DigitMap=Dialplan_0:
                               Signals{}
                          }
                     }
                },
                Events = 2224 {FX/lo
                     Action {NotifyAction}
                }
           }
      }

Note:  In the text on EventDescriptors, it says the Action is optional.
If an Action is optional, what is the point of detecting the event?

Note:  The example for digit map given on page 22 is inconsistent with the
ABNF.

      "Event=1139 { Line/DTMF {ACTION=AccumulateByDigitMap{GenMap} } }"

should be

      Event=1139 {Line/DTMF {ACTION{DigitMap=GenMap}}}

>8. Missing packages
>
>The basic packages draft currently lacks a package for analogue line
>supervision, containing the on-hook, off-hook, and hookflash events and the
>physical ringing signal.
>***Action: Tom Taylor to draft the package specification.

Related to these packages are packages for Loop Start/Ground Start
(FXO/FXS) and E&M (there is a MF package somwhere) signaling.

I would assume that an FX package could use the analogue line supervision
package since FX is a direct analogue of analogue line supervision.

An E&M supervision package would have special items like a wink, reverse
wink, delay-dial, start-stop and other events and signals.

>9. Directionality
>
>After considerable discussion it was agreed that the following
>interpretations of terms dealing with direction are to be applied:
>
>terminationMode=send implies that the stream passes through the termination
>toward the exterior of the MG
>
>terminationMode=receive implies that the stream passes through the
>termination toward the centre of the context (and thence to all other
>terminations, except as modified by a topology descriptor)
>
>Signals applied on a termination pass toward the exterior of the MG.  There
>is a requirement under some circumstances to pass the same signals to all
>other terminations.  The fallback position is that this is done by applying
>the same signal to every termination in the context where it is required.
>***Action: list to consider whether additional syntax is preferable to
>indicate two-way propagation of the signal.
>
>Events at a termination are detected on the termination itself (e.g.
>supervision events) or on streams incoming from the exterior of the MG
>(received streams).

A question in this case is if the termination Mode is ReceiveOnly and it
receives an inband tone for which it has an outstanding Event (e.g.,
digits), does it pass that tone to the other terminations in the Context or
does it eat it.  If the former is true, then the MGC would have to set the
Mode to Inactive while looking for an inband tone.  If the latter, then
clarification could be made that the TerminationMode does not apply to
Signals and Events.  As far as I can tell there is no text in the draft
that says this.

...snip...
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------

---

From: Chip Sharp <[email-masked]>
Date: Thu, 7 Oct 1999 08:17:10 -0400

>    Line signalling. the MGC should only be reported events that help it

Depends on what you mean by "normal". :-)

It is possible that Tip Close could be conflated with Ring ON without too
much loss of operation.  Loop Open and Loop Close could be defined as
offhook and onhook.  these mappings would have to be suitably defined.

Chip