JTapi Bug - phone strange status

[stefania.oliviero@farnetworks.]

Hi to all.

We have implemented a very complex system that controls via JTapi about 60 IP Phones (7975) and over 1200 CTI Ports and 50 Route Points to manage communications towards and from a central control room. In the control room converge all communications that come from various systems such as trains, intercoms, analog phones and so on.

Our software is based on JBoss Application server on a Linux system.

Because of specific input by our customer, All incoming calls, can't be managed directly by operators, but must be put on queue and then picked up, when the operator want to answer the call.

Incoming calls are directed to Route Points and then redirect to CTI Ports, where the calls are answered and then placed on Hold.

When an operator wants to pickup a call, from CTI port where call is held, starts a consultation call to operator ipphone and when the operator answers, the two calls (original and the  consultation one) is merged.

This systems is in production about from 2 years and until september 2014 has worked well.

Now sometimes it happens that an ipphone goes in a strange status  after incoming  calls can't be no  more picked up in this way, but  the two calls can't be merged so the original call cant' be picked up by the operator (original call remain hooked on CTI port).

The IPPhone state is unlocked only when the IPPhone is disassociated and then riassociated to the application user on CUCM.

I don't know why the IPPhone goes in that strange status, our customer can't say what he does.

I can't the issue reproduce on my test environment.

But I think this is a jtapi bug, becasue it is resolved disassociating and then riassociateing the IPPhone to the application user on CUCM.

Also resetting IPPhone doesn't work.

I hope in help.

Thanks, Stefania.

[smupadhy]

[Moving post to JTAPI space]

Hi Stefania,

I see that you opened a DevNet Support ticket for this issue, and it is currently being worked on. For the benefit of other developers, we will post a summary of the solution after ticket is resolved.

Thanks,

[stefania.oliviero@farnetworks.]

Hi to all, I opened a ticket but nothing has resolved. I still have the problem.

Cisco support told me that was a problem of my software, which not handle events in the rights order  but  can't find a solution, because software I implemented is very complex and is in production since 3 years, handling more than 20000 calls in a week, and  I can't think to modify this critical software that works well at the 99%.  This problem happens seldom, but still happens on some phones and at the moment the only solution is to disassociate and then reassociate the phone to the application user.

I'm developing a workaround to do automatically the previous operation.

[upchaurasia]

Is there any CUCM version change?

Can you check if application is getting any error/exception from JTAPI when try to merge to calls? If yes, can you post those exceptions.

Regards,

Umesh

[stefania.oliviero@farnetworks.]

Thank Umesh, we don't get any error except for the following:

55574798: Mar 25 14:49:52.844 CET %JTAPI-JTAPI-7-UNK:[CTI-SPV-L1-09]PlatformExceptionImpl caught: Handle is unknown to the system

But I get it also for calls succesfully merged.

CUCM version is 8.6 ES and firmware on the phones was updated for other issue.

Regards, Stefania.

[mpotluri]

'Handle is unknown to the system' typically indicates that the call went to IDLE state when the request is done.  Can you attach jtapi log with the call in question?

[stefania.oliviero@farnetworks.]

Attached you can find an extract of the log with the issue.

Call not OK:

424430/2 = 33978862 (MaincallId)

562966/1 = 17340182 (COnsultCallId)

Call Ok to compare:

CallId               : 50823207 (491559/3)

ConsultCallId        : 17340186 (562970/1)

Thanks for your help.

[mpotluri]

Stefania,

    One issue I see is that application is not setting the RTP for the second call from CTIPort to 6522 before transferring the call. On the second call from CTIPort GCID=(562966/1) to 6522, application gets CiscoMediaOpenLogicalChannelEv when 6522 answers the call:

55574486: Mar 25 14:49:52.799 CET %JTAPI-JTAPI-7-UNK:(P1-ApplicationUser) [CTI-SPV-L1-09] CiscoMediaOpenLogicalChannelEv [#5152758]

Application is doing a transfer request before setting the RTP:

55574492: Mar 25 14:49:52.807 CET %JTAPI-JTAPI-7-UNK:[(P1-ApplicationUser) GCID=(2,424430)->ACTIVE]transfer ((P1-ApplicationUser) GCID=(1,562966)->ACTIVE,[CTI-SPV-L1-09/[11010100109:PT_CTIPort:1/(P1-ApplicationUser) GCID=(2,424430)->ACTIVE]->ESTABLISHED]->HELD,[CTI-SPV-L1-09/[11010100109:PT_CTIPort:1/(P1-ApplicationUser) GCID=(1,562966)->ACTIVE]->ESTABLISHED]->TALKING)

As a part of transfer both the calls on CTIPort go IDLE state.

55574746: Mar 25 14:49:52.839 CET %JTAPI-JTAPI-7-UNK:(P1-ApplicationUser) 562966/1 CallInvalidEv [#5152800] Cause:100 CallCtlCause:0 CiscoCause:500 FeatReason:2

RTP is set after the call is invalid:

5574790: Mar 25 14:49:52.842 CET %JTAPI-JTAPI-7-UNK:(P1-ApplicationUser)[atmJTAPI-workmanager-threads 6723276 6962551atmJTAPI-workmanager-threads][CTI-SPV-L1-09]Request: setRTPParams(CiscoRTPParams0.0.0.0/0)

55574791: Mar 25 14:49:52.842 CET %JTAPI-JTAPIIMPL-7-UNK:[IPPhone:SEP08D09F9ED42A]ObserverProxy.deliverEvents()

55574792: Mar 25 14:49:52.842 CET %JTAPI-JTAPIIMPL-7-UNK:[IPPhone:SEP08D09F9ED42A]delivering to callChangedEvent

55574793: Mar 25 14:49:52.842 CET %JTAPI-PROTOCOL-7-UNK:(P1-10.120.4.20) [atmJTAPI-workmanager-threads 6723276 6962551atmJTAPI-workmanager-threads] sending: com.cisco.cti.protocol.DeviceSetRTPForCallRequest {

sequenceNumber    = 4678340

  callManagerID     = 2

  deviceID          = 35068

  callCallManagerID = 3

  callLegID         = 61968646

55574798: Mar 25 14:49:52.844 CET %JTAPI-JTAPI-7-UNK:[CTI-SPV-L1-09]PlatformExceptionImpl caught: Handle is unknown to the system

Application should first set the RTP (Call setRTPParams API) wait for CiscoRTP events and then call transfer API to avoid this.

[upchaurasia]

Hi Stefania,

Have you resolved the issue? We generally prefer to do transfer after receiving the RTPOutPutStartedEvent in TerminalCHange event as suggested by Mohan?

Is it possible for you to call the steps from  RTPOutPutStartedEvent in TerminalCHange in place of CallChange event.

Regards,

Umesh