Monday of a
three-day week. I came in early because I had some code modifications I
needed to make before Imju came to work. Last week I lost my electronic
key so I can't get into the switch room. Now most of the time I leave
it in the switch room but I couldn't find it which is annoying because
I don't want to down to security to replace it. Hopefully it'll turn up.
Anyway, since I can't get into the switch room I can't get to the
physical telesets and all the current testing is with the physical
telesets. But Sonali has two Nortel telesets on her desk so I used
those to do some testing. They're Nortel IP telesets I believe and
they're not that good looking. I think the Avaya IP telesets aesthetics
are even worse. Cisco IP telesets are the best looking ones I've seen.
The problem was that if you use the physical teleset the Nortel switch
does not throw dialing events, which are Delivered/Destination Seized
events for CT Connect. You do get an Initiate/Offhook event with no
real data which I've always ignored. And you get the Active/Established
event when the other party answers.
There is really no way to cleanly fix the problem since I can either
send a callDialingEvent when the phone goes offhook but have no
ANI/DNIS information or wait until the callEstablished event which is
kind of late. For now we left that alone and it's good enough.
|
The real
problem is that if you make a consultation call you also only
get a Initiate/Offhook and no Delivered/Destination Seized. Not only
that but you don't get any further events on the consultation line,
though that was already a known problem with the Nortel switch -- the
consultation line gets few events.
The effect is that when you place a consultation call, the controller
gets no consultation call events, which the OTM team needs for their no
softphone algorithm. So first we have to look at the events and see
what we do get. This involves using the CT Connect Ctctest program to
capture events thrown by the switch.
Luckily, the Initiate/Offhook event has application data
including the media item id. So I can fake a callDialingEvent which
will have no ANI/DNIS information but will have the media item id.
Since the Media Item has the original call ANI and DNIS we can backfill
the data and everything is more or less ok. Problem solved.
As long as I was at it I added code so that the consultation receiver
tells the controller when the call is established and released. That
way for the common case (consultation to a monitored agent) the
controller behaves normally.
There are still some gaps if the consultation call is to an unmonitored
agent. In that case we never get a Null/Tp Disconnected event which
would leave a hanging call reference at the adapter level. The best I
can do is clear the consultation line when a new call appears on the
same base line, since that implies no consultation call.
|