cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
66
Views
0
Helpful
0
Comments
cdnadmin
Level 11
Level 11
This document was generated from CDN thread

Created by: Stephan Steiner on 08-02-2010 05:01:43 PM
Is this another race condition issue?
 
When my JTAPI apps start up, I set up Address and Call Observers on each terminal that is not restricted.
 
for (Terminal term : provider.getTerminals())
                {
                    addTerminal((CiscoTerminal)term);
                }
 
protected void addTerminal(CiscoTerminal term)
    {
        CiscoTerm ct = null;
        if (!term.isRestricted())
        {
            if (term instanceof CiscoMediaTerminal) // this is a cti port
                ct = new CiscoCTIPort(provider, term, this.tracer, false);
            else if (term instanceof CiscoRouteTerminal) // this is a routepoint
                ct = new CTIRoutePoint(provider, term, this.tracer, false);
            else
                ct = new CiscoTerm(provider, term, this.tracer);
            ct.registerCallbacks();
            this.terminals.put(term.getName(), ct);
        }
        else
            tracer.Trace("Terminal " + term.getName() + " is currently on the restriction list and cannot be monitored", 4);
    }
 
.. in CiscoTerm.java (term = the CiscoTerminal)
 
public boolean registerCallbacks()
    {
        boolean retval = false;
        lines = term.getAddresses();
        try
        {
            term.addCallObserver(this);
            term.addObserver(this);
            CiscoAddress caddr = null;
            if (this.lines == null)
            {
                tracer.Trace("Device " + this.terminalName + " has no lines, monitoring it will be a rather futile attempt.", 4);
            }
            else
            {
                for (Address addr : this.lines)
                {
                    caddr = (CiscoAddress)addr;
                    if (caddr.isRestricted((Terminal)this.term))
                        tracer.Trace("Unable to monitor line " + caddr.getName(), 3);
                    else
                        addr.addObserver(this);
                }
            }
            retval = true;
            setDeviceEventFilter(false, TerminalEventFilterType.rtp);
            //setDeviceEventFilter(true, TerminalEventFilterType.buttonPressed);
        }
        catch (javax.telephony.ResourceUnavailableException r)
        {
            tracer.Trace("Problem when registering callbacks for terminal " + term.getName() + ": " + r.getMessage(), 1);
        }
        catch (javax.telephony.MethodNotSupportedException m)
        {
            tracer.Trace("Problem when registering callbacks for terminal " + term.getName() + ": " + m.getMessage(), 1);
        }
        catch (javax.telephony.PlatformException p)
        {
            JtapiProvider.GetProvider().processPlatformException(p, "registerCallback(" + terminalName + ")");
        }
        catch (Exception e)
        {
            tracer.Trace("Generic exception during initialization of terminal " + this.terminalName, 1);
        }
        return retval;
    }
 
 
Now, I have never had any issues in my lab, but on site, with both CCM 6.1 and 7.1 deployments, I have a handful of phones that dump an exception when I try to add the listeners. Now I'm wondering if I'm doing something wrong here or is there an issue in JTAPI that makes this fail from time to time?
 
Note that when I check the offending terminals, they are not restricted, and neither are their addresses (so that makes me thing it's not race condition related... but I've seen it happening too with restricted terminals).

Subject: RE: CiscoTerm.isRestricted() returning incorrect values
Replied by: David Staudt on 08-02-2010 05:25:38 PM
Are you allowing the Provider inService event to arrive?  If not, adding observers may fail for the first few devices, until the Provider does come in service.  This could take slightly longer on a production system.
 

Subject: RE: CiscoTerm.isRestricted() returning incorrect values
Replied by: Stephan Steiner on 09-02-2010 08:31:25 AM
David
 
Yes I'm waiting for the provider to come into service. Additionally, we're not talking about the first phones that are being returned.. it happens at random and well into the list of phones. Here's my Provider initialization code:
 
public boolean init()
    {
        boolean retval = false;
        try
        {
            tracer.Trace("\r\n\r\nStarting Jtapi Connector 1.1 - 17.8.2008 (c) NextiraOne GmbH", 1);
            tracer.Trace("Initializing JTAPI", 1);
            CiscoJtapiVersion version = new CiscoJtapiVersion();
            tracer.Trace("JTAPI Client version: " + version.toString(), 1);
            JtapiPeer peer = JtapiPeerFactory.getJtapiPeer(null);
            if (peer instanceof CiscoJtapiPeer)
            {
                CiscoJtapiPeer myPeer = (CiscoJtapiPeer)peer;
                setJtapiPreferences(myPeer);
                String providerString = "";
                for (String callManager : config.callManagers)
                {
                    providerString += callManager + ",";
                }
                providerString = providerString.substring(0, providerString.length() - 1); // strip last comma
                tracer.Trace("Listening to the following call managers: " + providerString, 4);
                providerString += ";login=" + config.jtapiLogin + ";passwd=" + config.jtapiPassword + ";appinfo=CiscoJTAPI";
                provider = (CiscoProvider)((CiscoJtapiPeer)peer).getProvider(providerString);
                provider.addObserver(this);
                conditionInService.waitTrue();
                prov = this;
                tracer.Trace("Successfully opened provider", 1);
                provider.registerFeature(CiscoProvFeatureID.TERMINAL_REGISTER_UNREGISTER_EVENT_NOTIFY);
                for (Terminal term : provider.getTerminals())
                {
                    addTerminal((CiscoTerminal)term);
                }
                tracer.Trace("Successfully added observers for " + provider.getAddresses().length + " devices", 4);
                retval = true;
            }
            else
            {
                tracer.Trace("Unable to create a Cisco JTAPI Peer. Aborting..", 1);
            }
        }
        catch (javax.telephony.JtapiPeerUnavailableException p)
        {
            tracer.Trace("JTAPI Peer unavailable. Application cannot initialize." + p.getMessage(), 1);
        }
        catch (javax.telephony.ResourceUnavailableException r)
        {
            tracer.Trace("JTAPI provider reports resource unavailable. Application cannot initialize. " + r.getMessage(), 1);
        }
        catch (javax.telephony.MethodNotSupportedException m)
        {
            tracer.Trace("JTAPI provider method not supported when trying to add provider observer. Application cannot initialize. " + m.getMessage(), 1);
        }
        catch (Exception e) // catch all remaining exceptions
        {
            tracer.Trace("Generic exception during JTAPI initialization: " + e.getMessage());
            tracer.DumpStackTrace(e.getStackTrace());
        }
        return retval;
    }

Subject: RE: CiscoTerm.isRestricted() returning incorrect values
Replied by: Stephan Steiner on 17-02-2010 03:38:52 PM
I went ahead and checked out the terminals where the problem arises in a 7.1.3 cluster. Turns out those are all 7931 phones - I know I cannot monitor them in rollover mode.. though imho, JTAPI telling me the device is not restricted, then throw a "terminal is restricted" exception when I try to monitor it is not correct. Either the exception should mention that you're now able to monitor that terminal because that type/configuration mode is not supported, or then isDeviceRestricted should return true right away so we don't even try to monitor it.

Subject: RE: New Message from Stephan Steiner in Cisco JTAPI (JTAPI) - Cisco JTAPI Q
Replied by: Abhishek Malhotra on 17-02-2010 06:45:11 PM
Hi Stephan,



Can you please confirm if you are using 7.1(3) JTAPI client with 7.1(3) CUCM?

If you use 7.1(3) JTAPI then the devices configured in role over mode will be reported as restricted right away but if an older JTAPI client is used then device will not be reported restricted initially but will be marked as restricted when application tries to monitor it for which an exception will also be thrown.



For the above reason, we have recommended applications to use 7.1(3) JTAPI client with 7.1(3) CUCM.



Alternatively, if you wish to monitor the devices in roll over mode then there is a new user role added for this in release 7.1(3), which when associated to user will allow applications to control phones with roll over mode configured.



Thanks & Regards,

Abhishek Malhotra



From: Cisco Developer Community Forums [mailto:cdicuser@developer.cisco.com]
Sent: Wednesday, February 17, 2010 9:09 PM
To: cdicuser@developer.cisco.com
Subject: New Message from Stephan Steiner in Cisco JTAPI (JTAPI) - Cisco JTAPI Questions: RE: CiscoTerm.isRestricted() returning incorrect values



Stephan Steiner has created a new message in the forum "Cisco JTAPI Questions":
--------------------------------------------------------------
I went ahead and checked out the terminals where the problem arises in a 7.1.3 cluster. Turns out those are all 7931 phones - I know I cannot monitor them in rollover mode.. though imho, JTAPI telling me the device is not restricted, then throw a "terminal is restricted" exception when I try to monitor it is not correct. Either the exception should mention that you're now able to monitor that terminal because that type/configuration mode is not supported, or then isDeviceRestricted should return true right away so we don't even try to monitor it.
--
To respond to this post, please click the following link:
<http://developer.cisco.com/web/jtapi/forums/-/message_boards/message/1974292>
or simply reply to this email.
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Quick Links