Recognising Call State Changes On Extn For Trunk Calls

Sep 11, 2013 at 8:41 AM
Hi,

I have a C# application up and running in which the user connects to their phone line and when they answer a call, it pops a window.

This works fine if a call comes directly to the phone, however, most calls are directed via a trunk line to the phone. When this happens, no call state change seems to be recognised, even though the local phone is ringing. If I connect to the trunk line, the call state change is recognised, but the user would not want to do this.

I have tried the Julmar Dialler, and this seems to work how I would want things to, so I must be missing a trick somewhere?

A code example is shown below:

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using JulMar.Atapi;

namespace TapiEx_POC
{
public partial class telConn : Form
{
    TapiManager _mgr = new TapiManager("Telephony POC");
    private TapiLine gcurrline; 
    private TapiCall gcurrCall;
    int extnNumber;

    public telConn()
    {
        InitializeComponent();


    }

    private void telConn_Load(object sender, EventArgs e)
    {
        _mgr.Initialize();  // Find all Tapi devices

        availableLines.Items.Add("None"); // Add no line selected to top of list

        foreach (TapiLine line in _mgr.Lines) //Put all the line devices in list and track status
        {
            availableLines.Items.Add(line.Name);

            line.Ringing += this.OnRinging;              
            line.CallStateChanged += this.OnCallStateChanged;
        }


    }

    private void telConn_Closed(System.Object eventSender, System.EventArgs eventArgs)
    {
        _mgr.Shutdown();
    }


    private void availableLines_SelectedIndexChanged_1(object sender, EventArgs e)
    {
        if (availableLines.SelectedIndex == -1)
        {
            return;
        }


        if (!(gcurrline == null))
        {
            gcurrline.Close(); //Close the previous line
        }

        if (availableLines.SelectedItem != "None")
        {

            gcurrline = _mgr.Lines[(availableLines.SelectedIndex - 1)];
            gcurrline.Open(MediaModes.InteractiveVoice); //Open the line

         }
   private void OnCallStateChanged(object sender, CallStateEventArgs e)
    {

        if (InvokeRequired)
        {
            this.BeginInvoke(new EventHandler<CallStateEventArgs>(this.OnCallStateChanged), new object[] { sender, e });
            return;
        }

    }

    private void OnRinging(object sender, EventArgs e)
    {
        if (InvokeRequired == true)
        {
            this.BeginInvoke(new EventHandler<RingEventArgs>(this.OnRinging), new object[] { sender, e });
            return;
        }

    }
}
}

Any help would be greatly appreciated.
Coordinator
Sep 11, 2013 at 3:37 PM
Hi,

The TAPI dialer works because it opens ALL lines in monitor mode and then your single line in owner mode. So it sees all calls and can decide when an inbound call hits to take ownership and answer the call. I suspect you would need to do the same if calls arrive on different lines than your station.

mark
Sep 12, 2013 at 8:09 AM
Hi Mark,

Thank you for your quick response, that all seems to make sense.

I will give this a go.

Do you know if there are any scalability issues with this (i.e if I had 200 users logged in monitoring all the lines to take ownership of calls which belonged to them), or is there not much overhead in this?

Thanks again,
John
Coordinator
Sep 12, 2013 at 12:16 PM
Probably won't be an issue. Are you doing 1st or 3rd party TAPI? If you can determine the trunk tied to your station you could limit the lines you monitor which would probably help quite a bit.

mark
Sep 12, 2013 at 1:19 PM
Many thanks for this Mark.

I've already amended things to monitor, as per your previous reply, and this seems to be working well.

I'll try and refine further now.

John
Oct 22, 2015 at 5:35 PM
Edited Oct 23, 2015 at 10:10 AM
Hi,
we have a very similar problem. It's NEC Infront TAPI driver and we're using ATAPI 1.4.0 library. We have a line "EXTENSION 168 Keyset".

Inbound call from an internal extension is handled well: CallStateChange event fires.
Inbound call from an external extension doesn't fire any event, except NumberOfCalls. No CallStateChanges, CallInfoChanged or any other. But another line with name like "TRUNK 9030 Digital" (where 9030 every time is different) handles the call.

I've tried different tapi applications to monitor events. All of them show events on "EXTENSION 168 Keyset", except ones with ATAPI .NET library. Even more, I've tried TAPI Call Monitor (Cpp, http://julmar.com/samples/tapi/tapi_call_monitor.zip) and I've tried TAPI Call Monitor (C# from solution with examples). Result (C# is above):
Image

I've tried different versions of C# Call Monitor: both X32 and X64 don't see on "EXTENSION 168 Keyset" an external call.

Could you help with this issue?
Oct 29, 2015 at 6:00 PM
I've found out the problem.
When TapiLine is initialized it's constructor gets dwNumAddresses number of addresses from devCaps. For this extension this number is 165.
But when inbound call comes, line fires events LINE_ADDRESSSTATE and LINE_APPNEWCALL for address 251! And LineCallback throws exception. But it's exception is not handled by customer, because it is throwed in other thread. So call is not created and ProcessTapiMessage doesn't throws events to call's line.

Now I'm trying to found out why dwNumAddresses number is wrong at TapiLine's constructor.
Oct 30, 2015 at 10:17 AM
Edited Oct 30, 2015 at 10:18 AM
I've tried your Line Monitor tools and now I think that dwNumAddresses is correct. But addressId of messages LINE_ADDRESSSTATE and LINE_APPNEWCALL is wrong. Is it possible?
Should I make pull request, that throws such messages (with addressId greater than number of addresses) to address #0? I agree, that it is a crutch.
Coordinator
Oct 30, 2015 at 7:36 PM
That would likely be a driver issue — it’s what reports that information.. I’m not sure I’d throw an exception there since there would be no way for user code to catch it (since that’s the service thread processing TAPI messages). But certainly a debug log seems appropriate..

mark