Date: Mon, 26 Jun 2000 02:31:53 +0200 (CEST) From: Leif Neland <leifn@neland.dk> To: Gerhard Sittig <Gerhard.Sittig@gmx.net> Cc: freebsd-isdn@FreeBSD.ORG Subject: Re: reject Message-ID: <Pine.BSF.4.05.10006260213170.1324-100000@arnold.neland.dk> In-Reply-To: <20000615180028.M9883@speedy.gsinet>
next in thread | previous in thread | raw e-mail | index | archive | help
I'm back from vacation...
On Thu, 15 Jun 2000, Gerhard Sittig wrote:
> On Wed, Jun 14, 2000 at 23:05 +0200, Gary Jennejohn wrote:
> > David Wetzel writes:
> > >> From: Gary Jennejohn <garyj@peedub.muc.de>
> > >
> > >> Wait a second. If you have 2 devices on an S0 bus responding
> > >> to the same number then I would expect a race condition to
> > >> result. It doesn't seem reasonable to me to expect isdnd to
> > >> reject calls for other devices on the bus. In fact, I would
> > >> suspect that it would violate some standard. IMHO that's a
> > >> function which a PBX should carry out.
> > >
> > >No. i4b/the anwering machine should answer the call and hang
> > >up.
>
> Accepting the call with an AM and immediately hanging up is one
> solution. But regarding immediate _rejection_ this *is* possible
> (and we've been through that a few years ago in another project).
>
> AFAICT (I'm not an communications expert and might use the wrong
> terms, but you surely get the idea) an incoming call is just
> signalled to the internal bus(ses). *Every* device has the
> opportunity to
> - ignore the call ("not mine, I don't care")
> - accept the call ("I _could_ handle this" in the meaning of "I
> apply for getting this job"!)
> - reject the call ("not for me _and_for_nobody_else_ I can think
> of")
>
> There's a chance for multiple devices to accept the signalled
> call (not to get them, that's something the PBX will handle due
> to the packets' serialisation on the bus). And I consider this
> to be a feature. Think of signalling a voice call on many phones
> and have the user decide where to pick up the receiver. Or have
> a few remote control computers sit there and have them choose
> whether it's their working hour and whom they respond to. That's
> where they can share a MSN quite well.
>
> To summarize: There is a rejection message a device can emit
> speaking for *everyone* on the bus. It's just rarely used and
> might not be available at a userland command level. And it's
> very rare cases where this message is appropriate.
In the linux-isdn stuff there is a note of NOT to reject a call if it
might be for another device, so that also signify the existance of a
global reject command.
I have a few MSN's on my line: One for me, one for my wife, one for the
computer (also acting as fax) and one extra, just in case...
Mine and my wife's number each has "transfer call if no answer (after 4
rings)" to each our cell-phone.
When going on vacation, I took out these two MSN's of the phones, so the
house-sitter wouldn't be disturbed by calls to us, but still be able to be
called on the extra MSN.
But, as no device would accept the call for our numbers, the exhance just
reported "no such number", and the calls would never be transferred.
I had to put a phone in the computer-room accepting our numbers, to have
the calls accepted.
BTW, it is possible to have two phones on one ISDN2, and have both
accepting calls for the same number.
It is also possible to have more ISDN2-lines marked together, and when the
first one is busy, the next one recieves the call.
But is it possible to have say 2 ISDN2-lines, and 4 phones, and all 4 ring
when a call comes in? Or does that require a pbx?
> See above. We really suffered from this and it took quite some
> time to find out there's even such a feature and it's used in the
> software. Actually this tough rejection completely prevented the
> neighbour machines from getting any call (although they *saw*
> them). But this sounds like it absolutely is what's wanted here.
>
> (Mis)using the AM will accept the connection for a moment and
> lead to cost and a blocked B channel (i.e. data channel in
> contrast to the rejection completely handled in D channel
> messages). This should be considered -- unless one wants to
> "punish" the to be banned caller.
>
Well, we're back on speaking terms again, so this isn't nessecary anymore
:-)
Leif
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-isdn" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.10006260213170.1324-100000>