Subject: questions regarding hook state in residential gateways

From: Wai-tak Siu <[email-masked]>
Date: Fri, 19 Nov 1999 13:40:57 -0800

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: Nancy-M Greene <[email-masked]>
Date: Sat, 20 Nov 1999 14:19:19 -0500

Wai-Tak, then I think this is something that needs to be added to v12.

Let's add this to the discussion items for the Monday 11amET call.

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:         Saturday, November 20, 1999 12:40 PM
> To:   Greene, Nancy-M [CAR:5N10:EXCH]
> Cc:   [email-masked]
> Subject:      Re: questions regarding hook state in residential gateways
>
> 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,

---

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

I agree with this assessment of the problem.

MGs probably ought to come "up" with terminations equivalent to
out of service, which I would expect to return some error tone
if the line went off hook.  The MGC has to program the terminations to get
them to respond.  We probably want to
state how this happens to maximize interoperability.

Possibly they are in this state until they get Modified in
null context.  That would be pretty simple.  Another possibility
is that they are explicitly out of service, and the MGC has
to command them to come into service with ServiceChange.
For this to work, it would have to be possible to Modify a
termination while it was out of service, but that sounds right
anyway.

Brian

> -----Original Message-----
> From: Jon Steer [mailto:[email-masked]]
> Sent: Sunday, November 21, 1999 10:22 PM
> To: [email-masked]
> 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,
> > > 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
> > > What do you mean when you say the MGC always has to request both
> > offhook and
> > > onhook transitions?
> > >
> > > Nancy
> > >

---

From: Jon Steer <[email-masked]>
Date: Wed, 24 Nov 1999 14:37:10 -0500

At 10:14 AM 11/24/99 -0500, Peter Blatherwick wrote:

>One simple approach to handle this problem (ask for offhook event, and
>device is already offhook due to ServiceChange) is to think of state as
>having changed from "unknown" (after ServiceChange) to "offhook", when the
>1st EventsDescriptor looking for hook state arrives.
>
>Another approach could be to define default states in packages where this
>would be applicable, and generate events if they are not in that default
>state after ServiceChange.
>
>Either way, the offhook event would be reported based on current state
>when the 1st EventsDescriptor arrives.
>
>I agree with Jon, same conceptual problem exists for *all* state
>transition like events, so we need general handling.  I think either of
>the above could extend to other situations as well.  Not sure which I
>would prefer.
>
>NOTE: The second approach implies we have default event buffering set to
>"on", so that no such events can be missed before arrival of the 1st
>EventsDescriptor.  I think this would be a very good idea regardless!

If we set event buffering on, then additional problem get added:
   What event set from what package is the default?

   Are the default event sets applied to all? or by
  endpoint (the case of a mixed endpoint type GW that supports analog and
digital endpoints)

   How many events shall we buffer?  I can see a real world scenario where
I happen
  to pick up the phone , get no dial tone, hook-flash (many) times, put the
phone down
  pick it up again, dial digits... This really adds to the GW burden (and
MGC) during startup.

  How did the MGC know what the default GW event set was?

  How did the MGC know that the default package was?

  There is also the (implicit) assumption that the off-hook state implies that
  the end-user wanted to make a call?  What happens if the MGC has gone done (
  or just the endpoint) and come back up before the user had a chance to put
  the phone down?

  I think it's far simpler to take the approach that any state and events are
  completely lost until the ACK from the MGC that implies that a termination is
  active. At that point, sending a MGC request for an event that "implies"
state
  can be handled as an error by the GW.

  jon

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 24 Nov 1999 16:27:37 -0500

How about something simpler?

Any such up/down event can't generate a down until it generates an up.
If the MG comes up with the switch up, it ignores down until it sees up.

See comments below:

 -----Original Message-----
From: Jon Steer [mailto:[email-masked]]
Sent: Wednesday, November 24, 1999 2:37 PM
To: [email-masked]
Subject: Re: questions regarding hook state in residential gateways

Too much mechanism IMO

Either way, the offhook event would be reported based on current state when
the 1st EventsDescriptor arrives.
Not necessary IMO

I agree with Jon, same conceptual problem exists for *all* state transition
like events, so we need general handling.  I think either of the above could
extend to other situations as well.  Not sure which I would prefer.
I agree we need a general answer.  Down before up is a better answer
methinks.

NOTE: The second approach implies we have default event buffering set to
"on", so that no such events can be missed before arrival of the 1st
EventsDescriptor.  I think this would be a very good idea regardless!
I think the opposite, you don't get any events you didn't ask for.  The
start state should be No Buffering.

  How many events shall we buffer?  I can see a real world scenario where I
happen
 to pick up the phone , get no dial tone, hook-flash (many) times, put the
phone down
 pick it up again, dial digits... This really adds to the GW burden (and
MGC) during startup.
If you pick up the phone during restart, I think you should get an error
tone and nothing else until you hang up.

 There is also the (implicit) assumption that the off-hook state implies
that
 the end-user wanted to make a call?  What happens if the MGC has gone done
(
 or just the endpoint) and come back up before the user had a chance to put
 the phone down?

 I think it's far simpler to take the approach that any state and events are
 completely lost until the ACK from the MGC that implies that a termination
is
 active. At that point, sending a MGC request for an event that "implies"
state
 can be handled as an error by the GW.
State and events are lost until there is programming by the MGC - Events
Descriptor, TerminationState, etc.  Then events can be detected

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 24 Nov 1999 16:48:22 -0500

I realized I left out one part of this (changes in bold):

Any such up/down event can't generate a down until it generates an up while
an EventsDescriptor with Up is active.
If the MG comes up with the switch up, it ignores down until it generates an
up event.

 -----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Wednesday, November 24, 1999 4:28 PM
To: [email-masked]
Subject: Re: questions regarding hook state in residential gateways

See comments below:

 -----Original Message-----
From: Jon Steer [mailto:[email-masked]]
Sent: Wednesday, November 24, 1999 2:37 PM
To: [email-masked]
Subject: Re: questions regarding hook state in residential gateways

Brian