Subject: Re: questions regarding hook state in residential gateways

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 22 Nov 1999 09:40:16 -0500

I do not believe this is correct.  The event is the transition.
If the EventsDescriptor does not have the off hook event
in it (which is the case at boot), then the event is discarded.
Programming it subsequently to look for that event won't bring
back the transition.

Brian

> -----Original Message-----
> From: David Stonehouse [mailto:[email-masked]]
> Sent: Monday, November 22, 1999 7:41 AM
> To: [email-masked]
> Subject: Re: questions regarding hook state in residential gateways
>
>
> Events that relate to the state of a termination - e.g.,
> on-hook and off-hook -
> should be Notify'ed the same way whether the line is already
> in that state when it
> gets the EventsDescriptor, or if it transitions to that state
> in the future.
> I.e., the event "on-hook" should not just refer to detecting
> the transition to
> on-hook.  I don't see the value in restricting its meaning in
> that way.
>
> Dave Stonehouse
> Succession Multi-service Gateways
> Nortel Networks
> T:919-991-2776 (internal:ESN351-2776) E:[email-masked]
>
> Jon Steer wrote:
>
> > At 09:40 AM 11/20/99 -0800, Wai-Tak Siu wrote:
> >
> > Waitak,
> >
> >   I'm wondering how you differentiate this scenario from the
> >   scenario where the phone is already off-hook when the MG
> >   starts up.
> >
> >   Offhook without idle supervision should always be a
> >   GW side error and generate the appropriate tone.
> >
> >   jon
> >
> > >Nancy,
> > >         I was asking about event detection, not signal generation.
> > >         My original question is best illustrated by this scenario:
> > >
> > >A residential gateway has just cold-started. Before the
> gateway generates
> > >a restart ServiceChange, the user picks up the handset. The gateway
> > >detects the offhook transition, but since it does not have an
> > >EventDescriptor, it does not generate Notify.
> > >Soon later, the gateway generates a restart ServiceChange.
> After the MGC
> > >receives the message, it generates a Modify to the gateway
> to request for
> > >offhook detection. However, since the offhook transition
> has happened, the
> > >gateway does not generate Notify.
> > >Since the gateway does not play any tone to the user, the
> user hangs up
> > >the phone. Since the MGC has not requested the gateway to
> detect onhook
> > >transition, the gateway does not generate Notify either.
> > >
> > >         Explicit detection could solve this problem. When
> the phone is
> > >offhook, and the gateway receives an EventDescriptor, the
> gateway can
> > >reject the descriptor with a specific error code to tell
> the MGC that the
> > >phone is already offhook. Since there has been no call
> established, the
> > >user must have wanted to make a phone call, and the MGC can sends a
> > >SignalDescriptor in time to instruct the gateway to
> generate dialtone.
> > >         However, v12 does not define explicit detection.
> > >
> > >         Thanks.
> > >Waitak
> > >
> > >On Fri, 19 Nov 1999, Nancy-M Greene wrote:
> > >
> > > > Waitak, I'm not sure I understand the issue.
> > > >
> > > > In Annex E.7, the Analog Line Supervision Package
> defines events "on" for
> > > > onhook, and "off" for offhook. The MGC asks the MG to
> look for them using a
> > > > Modify command with SignalsDescriptor set as follows:
> > > >
> > > > To look for onhook:
> > > > Context = contextID {
> > > >   Modify = terminationID { Signals {al/on} } }
> > > >
> > > > To look for offhook:
> > > > Context = contextID {
> > > >   Modify = terminationID { Signals {al/off} } }
> > > >
> > > > What do you mean when you say the MGC always has to request both
> > > offhook and
> > > > onhook transitions?
> > > >
> > > > Nancy
> > > >
> --------------------------------------------------------------
> ------------
> > > > Nancy M. Greene
> > > > Internet & Service Provider Networks, Nortel Networks
> > > > T:514-271-7221 (internal:ESN853-1077)
> E:[email-masked]
> > > >
> > > > > ----------
> > > > > From:         Wai-tak Siu[SMTP:[email-masked]]
> > > > > Sent:         Friday, November 19, 1999 4:40 PM
> > > > > To:   [email-masked]
> > > > > Subject:      questions regarding hook state in
> residential gateways
> > > > >
> > > > > Hi,
> > > > >     If H.248 is used in residential gateway
> applications, because the
> > > > > protocol does not define how MGC and MG can be
> synchronized on the
> > > > > gateway's hook state (i.e. offhook vs onhook), MGC,
> when requesting the
> > > > > gateway to detect hook state change, always has to
> request both offhook
> > > > > and onhook transitions. Is this too cumbersome?
> > > > >     Explicit detection (as defined in MGCP) should
> help solve this
> > > > > problem. What is the reason why it is left out in H.248?
> > > > >     Thanks.
> > > > > Waitak
> > > > > Cisco Systems
> > > > >
> > > >
>

---

From: Michael Brown <[email-masked]>
Date: Mon, 22 Nov 1999 16:08:24 -0500

I do believe that what David has proposed (and Sophia Scoggins described in
her posting) is actually appropriate. The issue isn't to try to bring back
the transition, but is pointing out that there appears to be a need for some
sort of mechanism (implementation detail) to be able to determine the
current state of the termination to determine if requesting notification of
an particular event makes sense. It doesn't matter HOW the MG determines
that an event has occurred previously, just that it can do so at least in
the case of an event such as offhook. As David put it, this is a case where
the requested event (offhook) is both a transition and a state. If the line
is in the state corresponding to the requested event transition, then the
transition can be assumed to have occurred. The desired behavior should be
that the line comes into services and is requested to scan for offhook. The
determination is made that the line IS offhook, and the MGC is informed.
Standard line call processing would proceed to provide dial tone and, if
time-out occurs, the line should run through Receiver Off Hook handling. I
don't feel that there is any error condition involved here and the event
should be reported as at any other time.

Another point about this is related to being able to detect the event and
perform some action before the either the gateway or the line is in service
isn't the right approach. At least in PSTN, if a line is out of service,
going offhook results in dead air, not some tone. I suppose some intelligent
gateways may try to implement this type of behavior, but from a PSTN
transparency perspective, it is not required and shouldn't be a requirement
in the protocol.

After all of that, my bottom line view is that this issue doesn't
necessarily belong in the protocol spec. One could implement their gateway
where the initial hook state discrepancy is ignored until the line goes back
on hook without going through the ROH handling described above. The next
time the line goes off hook everything would be as expected. So, this can
all be handled as an implementation issue and doesn't require specific
protocol support.

Michael

PS. I think the intent was to describe this type of detection as implicit
rather than explicit.

---

From: Jon Steer <[email-masked]>
Date: Mon, 22 Nov 1999 19:52:29 -0500

At 04:08 PM 11/22/99 -0500, Michael Brown wrote:
>  As David put it, this is a case where

"States" are implementation dependent.

>PS. I think the intent was to describe this type of detection as implicit
I would also posit that if there
is a special understanding for "hook-state" that the concept/understanding
would have to be extended to the initial state of different types of
terminations,
such as H.320.

jon