🚀 go-pugleaf

In comp.sys.next.programmer, samurai@cs.mcgill.ca (Darcy BROCKBANK) writes:
>Well, it doesn't work for me that is.
>
>1) The example "MessageCenter" that shipped wouldn't compile
>because it had the wrong libraries. I changed the library
>from libphonekit to libphone, and it compiled.

It compiled fine for me without any problems and without any
changes.  Are you using project builder?  The Makefile
uses these libs:

   LIBS = -lphone_s -lMedia_s -lNeXT_s

What is this libphonekit you are talking about?  Are you running
3.0 or one of the pre releases?

>2) MessageCenter now crashes whenever incoming calls arrive.

Message Center doesn't handle errors very well - hey it's a demo.

It was doing that for me at one point.  Check the console log for
an error messages - then if there is one, find it in the code and
figure out what's going on.

When I had the same problem, it was because I had recorded a new
greating, and later removed the .snd file.  If message center can't
open the greating file, it just prints an error and exits (it doesn't
bomb).  It would try to open the file whenever a new phone call
came in.

>3) Giving up on this nice example, I've been struggling along
>with the flakiness of the phonekit.
>
>The flakiness could be due to the fact that I don't know what
>the hell I'm doing however...

>However, it never recieves notification of:
>
>- remotePickup
>- remoteRing
>- dialingComplete
>- remoteBusy

>I'm in Canada, and I'm using an ISDN Extender on
>a POTS line.

How can a POTS interface know that the remote end has picked up
the phone?  It can't (at least not very easilly).  And remote Ring
and remoteBusy could only work if it had very intelligent tone
detection - which I assume it doesn't.  I assume that these only
work for ISDN calls.  The NeXT ISDN Extender is an ISDN interface
that does POTS on the side.  I don't think it was ever intended to
be a great POTS interface.  These type of signals come over the ISDN
D channel as digital messages, so it's easy to relay this information
to the program.  To try to get these functions on a POTS line, you
have to write very fancy tone detection DSP code.  Maybe NeXT will
add that one day, but I wouldn't hold my breath.  You can always
just process the data stream yourself and look for ring tones.

However, dialingComplete should work for POTS.  The manual even
says that you have to use it to insert delays which are sometimes
needed.  I've never tried it yet so I don't have an idea why
that wasn't working for you.

Curt Welch

In article <1992Sep29.041031.11735@kcwc.com> curt@kcwc.com (Curt Welch) writes:
>In comp.sys.next.programmer, samurai@cs.mcgill.ca (Darcy BROCKBANK) writes:
>>Well, it doesn't work for me that is.
>>
>>1) The example "MessageCenter" that shipped wouldn't compile
>>because it had the wrong libraries. I changed the library
>>from libphonekit to libphone, and it compiled.
>
>It compiled fine for me without any problems and without any
>changes.  Are you using project builder?  The Makefile
>uses these libs:

Right... what happened was that I had an old copy of MessageCenter
from the PR2 days... that was the one that was buggy and crashed,
and the new one works fine.

Anyway, I guess the old lib was "libphonekit".. and that's what
was in the makefile.

>>3) Giving up on this nice example, I've been struggling along
>>with the flakiness of the phonekit.
>>
>>The flakiness could be due to the fact that I don't know what
>>the hell I'm doing however...
>
>>However, it never recieves notification of:
>>
>>- remotePickup
>>- remoteRing
>>- dialingComplete
>>- remoteBusy
>
>>I'm in Canada, and I'm using an ISDN Extender on
>>a POTS line.
>
>How can a POTS interface know that the remote end has picked up
>the phone?  It can't (at least not very easilly).  And remote Ring
>and remoteBusy could only work if it had very intelligent tone
>detection - which I assume it doesn't.  I assume that these only
>work for ISDN calls.  The NeXT ISDN Extender is an ISDN interface


Question: why isn't it in the docs???? The Docs say that POTS
works with the phone kit voice calls. They don't say it works
50% with voice calls.

Why don't the methods say "this won't work with POTS." So far,
nobody at NeXT has said anything as to why these methods 
aren't working.


Why do we have to "assume" all of this anyway? It really should
be documented!

>that does POTS on the side.  I don't think it was ever intended to
>be a great POTS interface.  These type of signals come over the ISDN

Still, they claim POTS functionality, which is why we bought $1,200
worth of extenders. We don't have ISDN in Canada, and we likely will not
get ISDN any time before 2,000 A.D. If the phone kit DOESN'T work
with POTS (they claim it does), then I'm screwed.

>D channel as digital messages, so it's easy to relay this information
>to the program.  To try to get these functions on a POTS line, you
>have to write very fancy tone detection DSP code.  Maybe NeXT will
>add that one day, but I wouldn't hold my breath.  You can always
>just process the data stream yourself and look for ring tones.

Well, they were intelligent enough to be able to handle touch
tones, and I don't see why it would be much harder to handle
ring tones or busy tones. Hell, I don't even get notification that
I'm finished dialing!!! If I at least knew that I'd be in better
shape.

I suppose that failing all else, I could just scan the streams
(provided they work with POTS) and try to figure out what's
happening from that.


HELLO NEXT???

CAN SOMEONE SHED SOME LIGHT ON THIS?

Can someone just say, "Yes it works, so you're obviously screwing
up somewhere." - or - "No it doesn't work, so stop banging your
head on it."

Please? Please? Someone?

>
>However, dialingComplete should work for POTS.  The manual even

It doesn't work for me. Sigh.

>says that you have to use it to insert delays which are sometimes
>needed.  I've never tried it yet so I don't have an idea why
>that wasn't working for you.

I know, but if some methods don't work, and some do, and we
weren't told which, then we have no way of knowing for sure.
Maybe someone forgot this too was an ISDN-only method.

That's not to say that I know that there are ISDN-only methods
or not (I hope not)...


Further complaints and words of wisdom.

1) alloc your NXPhone object first. If you try to alloc it after
   a channel or a call, then you WILL crash. It has to be done
   in order.

2) If a NXPhone can't do an ISDN init (or something like that)
   attempting to add a channel to it WILL MAKE YOUR PROGRAM
   exit(0). That's not a very nice thing to do, having your
   server kill off a client like that. It should RAISE or return
   nil or SOMETHING that will allow you to recover.

3) The PhoneServer is not very robust. While making your app,
   be prepared to have root kill the PhoneServer process at any
   time. If your app corrupts it (which is VERY easy to do), then
   it has to be killed. Allocing an NXPhone will start the server
   again.

4) Even if your ISDN extender is NOT plugged into a phone line,
   the PhoneServer will still issue a "dialToneReceived" message
   ALTHOUGH THERE IS NONE. This made me lose a LOT of time trying
   to figure out why the other phone wasn't ringing... :-). Stupid
   error, and my fault BUT HOW CAN THE PHONESERVER FIND A DIAL
   TONE WHEN THERE IS NO PHONE LINE!!!


Anyway, I'm still begging for some official clarification on this
issue..., and hopefully it's in the loop.

- db