cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5210
Views
0
Helpful
4
Replies

SIP phone button pressed JTAPI listener

anoopr
Level 1
Level 1

Hi,

 

I am building an application that requires digit key pressed events (such as 1, 2, # etc) to be captured from SIP phones. I have followed the Cisco JTAPI 11.5 guide and enabled the CiscoTermEvFilter.setButtonPressedEnabled(true) before adding a TerminalObserver implementation to the Terminal. I am seeing CiscoTermInServiceEv and CiscoTermOutOfServiceEv events but no CiscoTermButtonPressedEv events. The JTAPI documentation specifies DeviceKeyPressedEvent as an unsupported CTI Event for SIP Phones. Is this the reason why no CiscoTermButtonPressedEv events are reported to the TerminalObserver implementation. Are the DeviceKeyPressedEvent and CiscoTermButtonPressedEv one and the same.

 

Full code listing and other details are below.

 

Adding the TerminalObserver implementation:

private static void addTerminalObserver(Provider provider, String extension) throws Exception {
final Address address = provider.getAddress(extension);
for (Terminal terminal : address.getTerminals()) {
final CiscoTermEvFilter ciscoTermEvFilter = ((CiscoTerminal) terminal).getFilter();
ciscoTermEvFilter.setButtonPressedEnabled(true);
((CiscoTerminal) terminal).setFilter(ciscoTermEvFilter);
terminal.addObserver(phoneListener);
}
}

 

The TerminalObserver implementation:

final class PhoneListener implements TerminalObserver {

PhoneListener() {
}

@Override
public void terminalChangedEvent(TermEv[] events) {
for (TermEv event : events) {
final Terminal terminal = event.getTerminal();
System.out.printf("[Terminal Event]:: %s from terminal %s%n", event.getID(), terminal.getName());
}
}
}

 

Cisco JTAPI Trace where buttonPressedEnabled is enabled.

96: May 26 23:45:11.625 BST %JTAPI-JTAPI-7-UNK:(P1-gr-cti-user)[main][CIPC1001]setFilter(): Terminal Filter (OLD): deviceDataEnabled=false, buttonPressedEnabled=false, rtpEventsEnabled=true, snapshotEnabled=false, rtpKeyEventsEnabled=false, activeStatusEnabled=false, holdStatusEnabled=false, alertingStatusEnabled=false, idleStatusEnabled=false, whisperStatusEnabled=false, dndStatusEnabled=false, dndOptionEnabled=false
97: May 26 23:45:11.625 BST %JTAPI-JTAPI-7-UNK:(P1-gr-cti-user)[main][CIPC1001]setFilter(): Terminal Filter (NEW): deviceDataEnabled=false, buttonPressedEnabled=true, rtpEventsEnabled=true, snapshotEnabled=false, rtpKeyEventsEnabled=false, activeStatusEnabled=false, holdStatusEnabled=false, alertingStatusEnabled=false, idleStatusEnabled=false, whisperStatusEnabled=false, dndStatusEnabled=false, dndOptionEnabled=false

 

Cisco JTAPI version 11.5(1.10000)-1 Release

Cisco Call manager version 11.5.1.11900-26

 

Any help is greatly appreciated.

 

Many thanks,

Anoop

1 Accepted Solution

Accepted Solutions

dstaudt
Cisco Employee
Cisco Employee

If the phone is using SIP with UCM for signaling (very likely as its the default for most non-ancient phones), and is using RTP-NTE for DTMF relay (also very likely as the default), then the DTMF data is being sent in the RTP/voice stream and not in the SIP signaling, and UCM (and by extension CTI Manager and JTAPI) have no visibility into what keys are being pressed.

 

In the case of placing a call, phone digit handling is usually either en-block (send as a complete string in the SIP INVITE) or uses the 'dial rules' mechanism to simulate per-digit dialing.

 

It may be possible to configure a phone to use KPML-only for digit entry, but that is not going to be recommended for many devices due to performance impact, and may have knock-on affects for other systems/apps that RTP-NTE - for example MTPs may be allocated per call to translate between in-band/out-of-band DTMF signaling...

View solution in original post

4 Replies 4

Alex Stevenson
Cisco Employee
Cisco Employee

 

Hello @anoopr,

 

"The following CTI events are not generated for SIP phones. Third party applications that expect these call events should use SCCP phones:

 

CallOpenLogicalChannelEvent

CallRingEvent

DeviceLampModeChangedEvent

DeviceModeChangedEvent

DeviceDisplayChangedEvent

DeviceFeatureButtonPressedEvent

DeviceKeyPressedEvent

DeviceLampModeChangedEvent

DeviceRingModeChangedEvent"

 

This is the only mention of DeviceKeyPressedEvent I can find in the Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 11.5(1)  , while CiscoTermButtonPressedEv is mentioned repeatedly.

 

Therefore, in answer to your question:

Are the DeviceKeyPressedEvent and CiscoTermButtonPressedEv one and the same?

I would answer 'no'.

 

I hope this helps.

Hi @Alex Stevenson,

 

Thank you very much. It definitely helps to know that CiscoTermButtonPressedEv and DeviceKeyPressedEvent are different.


However I am not seeing any CiscoTermButtonPressedEv in my TerminalObserver implementation despite setting CiscoTermEvFilter.setButtonPressedEnabled(true). Any ideas?


I am using Call manager version 11.5 and Cisco IP Communicator soft phone version 8.6.6.0.

 

Many thanks,

Anoop

dstaudt
Cisco Employee
Cisco Employee

If the phone is using SIP with UCM for signaling (very likely as its the default for most non-ancient phones), and is using RTP-NTE for DTMF relay (also very likely as the default), then the DTMF data is being sent in the RTP/voice stream and not in the SIP signaling, and UCM (and by extension CTI Manager and JTAPI) have no visibility into what keys are being pressed.

 

In the case of placing a call, phone digit handling is usually either en-block (send as a complete string in the SIP INVITE) or uses the 'dial rules' mechanism to simulate per-digit dialing.

 

It may be possible to configure a phone to use KPML-only for digit entry, but that is not going to be recommended for many devices due to performance impact, and may have knock-on affects for other systems/apps that RTP-NTE - for example MTPs may be allocated per call to translate between in-band/out-of-band DTMF signaling...

anoopr
Level 1
Level 1

Thank you very much for your answers. As JTAPI has no visibility into the keys pressed, I have employed a different approach. I am now sending xml objects to display a softkey menu which can be used to perform certain actions on my JTAPI driven application. It works for my use case and this ticket can now be closed.