discrepancy in ringback doc/code

• Messages sorted by:[ date ][ thread ][ subject ][ author ]

"A month of sundays ago Russell King wrote:"
> 
> Peter T. Breuer writes:
> > You know when the other end has hung up after only 6s without a
> > ring after at least the first ring and anyway you could just tell mgetty
> > to go into ringback mode when it receives say 3 rings (RINGS = 3) 
> > and then come out of ringback mode when it receives a next ring within
> > TIMEIN seconds and then stop waiting after TIMEOUT seconds have elapsed
> > without a ring. This requires TIMEIN and TIMEOUT configuration variables.
> > Set TIMEIN=6s (or 30s?) by default and you have backward compatibility.
> 
> There is one problem - in the UK, we have a 'Ringback' service which works
> as follows:
> 
> Person A calls person B, person B answers.
> Person C calls person B, and they receive the engaged tone. They can then
> hit '5' to select ringback.
> 
> When person B finishes talking to A, person B's phone rings.

Well that's fine. It's some variant of call waiting. Over here I can
hear if someone rings me while I'm on the line. I usually ring off
for a moment and take the next call, then switch back if I can.

> Ok, now take this situation: person B does not answer the phone, but the
> answering machine does after 4 rings. He leaves no message, so the

To compare - there is no answering machine here .. the university switch
will pass the call to a voicebox after 20s of ananswered ringing, That
would ordinarily protect from the scenario you draw.

> answering machine disconnects after 4 seconds of OGM and 4 seconds of
> IGM. Meanwhile, person C has called and hit '5' as above.
> 
> What happens? Person A's phone rings within possibly as little as 10
> seconds of the first call. If it happens to have an mgetty with ringback
> on the line, it'll incorrectly answer the second call.

If I understand you right, and abstracting wildly, you are saying that
two deferred calls can arrive closely timed provided that something
answers the first deferred call and hangs up again within 8 seconds,
leading to a second ring within mgetty's attention window.

First of all, mgetty should have been configured to trigger into
ringback waiting after one ring, and to untrigger after two rings (the
present behaviour or configuration possibilities are not absolutely
clear to me), so it should not be in a state of waiting for a ringback
if the answering machine answers. The answering machine should be
configured to kick in only after mgetty has lost interest.

That aside, you are saying that it is possible to innocently trick
mgetty into answering in ringback mode when it should not.

Well, so what! I can arrange for any number of "incorrect" responses
with or without mgetty's help here! And I don't need three people
calling in a precisely timed sequence of actions in order to do it,
one of whom has managed to fix his answering machine so that he
won't get any messages anyway :-).

Half of my colleagues are busy profiting (in their research) from the
branch of computer science known as "feature interaction" and the
difficulty of predicting what adding a new feature to an existing system
will allow you to do that you didn't expect or perhaps want to be
allowed. Believe me, these telephone things are a gold mine.

In contrast, I was not advocating ANY new feature - just asking for the
ability to control one of the variables that is not currently under my
control - namely the time at which mgetty's ringback window opens.
I also want to control the number (min and max) of rings that will
trigger mgetty into waiting for a ringback. Let me deal with my own
feature interactions!

... we can get an "incorrect response" scenario anyway if I
have mgetty configured as it is now .. i.e. wait 17s after 1 ring
and then give me a window of 20s in which it will take an incoming
call. All I have to do is phone the lab to say I am coming, change my
mind about warning them, then switch my phone to pass calls to the lab
(on which mgetty is hanging) then walk down the corridor while somebody
phones me. Hey presto, mgetty answers instead of me. I haven't put any
effort into imagining this scenario (as you can tell :-), but what's the
problem?


> I don't think that the current mgetty behaviour is correct for this
> situation, and some improvement along the lines above would be most
> welcome to cover this situation if you wish to use this facility.
> 
> However, I don't agree that you should be able to set it too low -
> maybe impose a lower limit.

6s?

> Also, it isn't a good idea to specify a set number of rings - if you call
> though a PABX, then you simply can't tell how many rings the remote end
> will ring, since the clear-down time of the PABX is indeterminent.

That argument can't win. Because you can't control something at the
other end is no reason to not at least to control what you hear at your
end. And 90% of PABXs (more?) surely won't have more than a discrepency of
1 between number of rings at the two ends of the line. In any case, I
don't really care what is really happening at the mgetty end - given the
chance I will configure mgetty to go into ringback mode after recieving
either one or two rings and no more, and when I call I will listen for
exactly one ring and then hangup. If I find that one ring at my end
generally corresponds to zero at the other end, then I will wait for two
rings. I am not a machine.

> What I suggest is to keep the current behaviour and to allow the
> 17 seconds to be a configuration option. This will then allow you to

I agree .. I at least was not advocating anything different than what
you suggest here. What I did say was that the present behaviour is
uncomfortable for a number of reasons (I went into more detail in
private email with Gert - chiefly the point was that enforcing a
minimum "timein" frazzles my nerves for no good reason without making
it any easier for me, nor any easier for my colleagues - I'll add
now that it doesn't make false pickups any less likely anyway, since
real human beings are more likely, not less likely, to call at intervals
of 40s than at intervals of 15s, and they aren't likely to ring once
and then hangup the first time. I'll also add that it was difficult enough
to get my colleagues to remember that they had to ring twice within 50s
to get the modem, the fisrt time only ringing once. It's impossible to
expect them to remember that they are supposed to wait 20s before
ringing the second time).

> specify all timeouts for ringback, and will minimise the changes to
> mgetty.

Agreed .. I was trying to get some time to hack the code today.No go so
far.

> |_____| ------------------------------------------------- ---+---+-
> | |  Russell King  rmk@ecs.soton.ac.uk  --- ---
> | | | |  http://www.arm.uk.linux.org/~rmk/home.html  / / |
> | +-+-+          --- -+-
> / |   THE developer of ARM Linux   |+| /|\
> / | | |          --- |
>  +-+-+ ------------------------------------------------- /\\\ |


---------------------------------------------------------------------
Peter T. Breuer    MA CASM PhD (Ing.), Prof. Asoc.
Area de Ingenieria Telematica	 E-mail: ptb@it.uc3m.es
Dpto. Ingenieria		 Tel: +34 1 624 99 53
Universidad Carlos III de Madrid Fax: +34 1 624 94 30/65
Butarque 15, Leganes/Madrid  URL: http://www.it.uc3m.es/~ptb
E-28911 Spain   
.