Gents,

I need to capture the DNIS for outbound calls so that if the call wasn't answered an email to be sent to a third-party.

Is monitoring outbound calls on trunks possible by JTAPI?

If outbound call is answered. Is there an event for that answer?

Thanks for your interest.

As per some posts. I'm letting outbound calls passing through a vdn first so that user from extension=115 calls a vdn=171 which collects the outbound address.
When querying the call connection using JTAPI exerciser i got only trunk "T65#2" for the outbound leg as:

=>call1.getConnections() returned:
   Connection[0] 115_c[1] (CONNECTED)
   Connection[1] 171_c[0] (ALERTING)
   Connection[2] T65#2_c[2] (CONNECTED)

Any ideas?

I am facing similar issue. Actually when making out bound call, I am getting TERMINAL_CONNECTION_ACTIVE (115) when its only ringing. So I need to know if the call was in connected state to start sending DFMF .

Any pointers ?

Hi Rohit,

You will never see a terminalConnectionRinging for an outgoing call as the monitored phone does not ring. It goes into the Active state as soon as you pick up the handset.

I suggest you have a look at the CallControlTerminalConnectionListener. It includes a connectionEstablished event which will indicate that the call has been answered.

Please note that, depending on the trunks between the originating Communication Manager and the terminating phone, you may never get a connectionEstablished event. For example, Analog trunks do not have the ability to return answer supervision to the originator. In these cases you should get a connectionNetworkReached event. If you receive this, you know that you will not be able to know when/if the call is answered.

You can see an example of CallControlTerminalConnectionListener in action in the AgentView sample application on the Devconnect website.

Martin

Thanks Martin for the response.

But, I am getting ConnectionEstabished & connectionNetworkReached even when the outbound call is still ringing.
Using following API to connect.

callObject.connect(callingAvayaTerminal, callingAvayaAddress, calledNumber, false, userInfo);

Following are the list of events when my cell phone is just RINGING.
Even if I pick up the call, I get exactly same events.

RINGING

Event: TerminalConnectionCreated 3051 - TERMINAL-CONNECTION-CREATED
Event: ConnectionCreated: 3051 - CONNECTION-CREATED
Event: TerminalConnectionActive: 3051 - TERMINAL-CONNECTION-ACTIVE
Event: ConnectionConnected: 3051 - CONNECTION-CONNECTED
Event: CallActive - CALL-ACTIVE
Event: ConnectionInitiaited: - CALL-CONTROL-CONNECTION-INITIATED
Event: ConnectionEstablished: - CALL-CONTROL-CONNECTION-ESTABLISHED
Event: ConnectionCreated: T2664#2 - CONNECTION-CREATED
Event: ConnectionConnected: T2664#2 - CONNECTION-CONNECTED
Event: ConnectionNetworkReached: From: 3051 To: 1XXXXXXXXXX - CALL-CONTROL-CONNECTION-NETWORK-REACHED
Event: TerminalConnectionDropped 3051 - TERMINAL-CONNECTION-DROPPED
Event: ConnectionDisconnected: 3051 - CONNECTION-DISCONNECTED
Event: ConnectionDisconnected: - CALL-CONTROL-CONNECTION-DISCONNECTED
Event: CallEventTransmissionEnded = CALL-ENDED


Do you have an java sample program for the AgentView. I only find .Net project which has not been updated in a while.

Thanks,
Rohit

Hi Rohit,

The messages you see look consistent with an outgoing trunk having the parameters "Receive Answer Supervision = n" and "Answer Supervision Timeout = 0". That is, the switch knows that the far end will not be able to indicate when the terminating phone answers the call so it sends a Connect to the application immediately. This would be typical for an analog trunk. The documents "Avaya Aura Communication Manager Screen Reference" and "Avaya Aura Communication Manager Feature Description and Implementation" should help you to understand how these parameters operate. Start with the Trunk-group section of the screen reference.

You can find the AgentView sample application on the Devconnect website - https://devconnect.avaya.com/public/dyn/d_dyn.jsp?fn=672

Martin

Hi Martin,

I took sometime but got all the log messages from our Session Manager and ACM.
If you look at the logs then we do see a RINGING event.
So my question is how can I get the same event via JTAPI ?

Also on the same topic, can I get codec via any JTAPI API.
We are using latest JTAPI api's.

Summarize : Making a call from 3362 - > 4084771498

From ACM:
time data

15:52:42 TRACE STARTED 09/27/2013 CM Release String cold-02.0.823.0-20763
15:52:46 active station 3362 cid 0x1822
15:52:46 G711MU ss:off ps:20
rgn:1 [10.30.16.13]:3320
rgn:1 [10.30.12.20]:2066
15:52:46 dial 4084771498 route:UDP|AAR
15:52:46 term trunk-group 1 cid 0x1822
15:52:46 dial 4084771498 route:UDP|AAR
15:52:46 route-pattern 1 preference 1 location 1/ALL cid 0x1822
15:52:46 seize trunk-group 1 member 12 cid 0x1822
15:52:46 Calling Number & Name NO-CPNumber NO-CPName
15:52:46 SIP>INVITE sip:4084771498@10.30.12.16;user=phone SIP/2.0
15:52:46 Call-ID: 0ee3058e829e31b183521f65c800
15:52:46 Setup digits 4084771498
15:52:46 Calling Number & Name 3362 Nguyen, Ed
15:52:46 SIP<SIP/2.0 100 Trying
15:52:46 Call-ID: 0ee3058e829e31b183521f65c800
15:52:46 Proceed trunk-group 1 member 12 cid 0x1822
15:52:46 SIP<SIP/2.0 180 Ringing
15:52:46 Call-ID: 0ee3058e829e31b183521f65c800
15:52:46 Alert trunk-group 1 member 12 cid 0x1822
15:52:51 SIP>CANCEL sip:4084771498@10.30.12.16;user=phone SIP/2.0
15:52:51 Call-ID: 0ee3058e829e31b183521f65c800
15:52:51 idle cid 0x1822
15:52:51 idle station 3362 cid 0x1823
15:52:51 idle station 3362 cid 0x1824

From traceSM (Session Manager):
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
10.30.12.10 CUCM-PR-01
SM100 3004
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
15:52:46,502 |--INVITE-->| | | (1) T:4084771498 F:3362 U:4084771498 P:terminating
15:52:46,506 |<--Trying--| | | (1) 100 Trying
15:52:46,508 | Remote host is trusted | Trusted
15:52:46,508 | Registered contact | Handle: 3362 Domain: clarussystems.com
15:52:46,508 | Originating Location found | Location: Santa_Clara
15:52:46,509 | Try routing to determine if eme | Location: Santa_Clara
15:52:46,509 | Request Dial Pattern route | for: sip:4084771498@clarussystems.com;user=phone Location: Santa_Clara
15:52:46,509 | Dial Pattern route parameters | URI Domain: clarussystems.com Location: Santa_Clara
15:52:46,509 | Trying Dial Pattern route | Domain: clarussystems.com Location: Santa_Clara
15:52:46,509 | Dial Pattern route parameters | URI Domain: null Location: Santa_Clara
15:52:46,509 | Trying Dial Pattern route | Domain: null Location: Santa_Clara
15:52:46,509 | Dial Pattern found | for: 4084771498 Pattern: 40847714
15:52:46,510 | Route Policy found | Pattern: 40847714 RoutePolicyList: to_cucm-prod
15:52:46,511 | Route found | for: sip:4084771498@clarussystems.com;user=phone SIPEntity: CUCM-PR-01, CUCM-PR-01
15:52:46,511 | Entity Link found | SIPEntity: CUCM-PR-01 EntityLink: qa-asess62vm-01->TCP, biDirId=null:5060
15:52:46,512 | Request Adaptation | Adapter: CUCM-pr-01
15:52:46,514 | Applied egress Adaptation | NoAdaptationModuleExists=true, To=<sip:4084771498@10.30.15.38;user=phone>, Request-URI=sip:4084771498@10.30.15.38;user=phone;routeinfo=0-0;user=phone, Remot
15:52:46,515 | Routing SIP request | SipEntity: CUCM-PR-01 EntityLink: qa-asess62vm-01->TCP:5060
15:52:46,518 | No hostname resolution required | Routing to: sip:10.30.15.38;transport=tcp;lr;phase=terminating
15:52:46,518 | Location found | Location: Production
15:52:46,523 | |--INVITE-->| | (1) T:4084771498 F:3362 U:4084771498 P:terminating
15:52:46,571 | |<--Trying--| | (1) 100 Trying
15:52:46,575 | |<--Ringing-| | (1) 180 Ringing
15:52:46,581 | Request Adaptation | Adapter: CUCM-pr-01
15:52:46,586 |<--Ringing-| | | (1) 180 Ringing
15:52:51,765 |--CANCEL-->| | | (1) sip:4084771498@10.30.12.16
15:52:51,767 |<--200 OK--| | | (1) 200 OK (CANCEL)
15:52:51,769 | |--CANCEL-->| | (1) sip:4084771498@10.30.15.38
15:52:51,775 | |<--200 OK--| | (1) 200 OK (CANCEL)
15:52:51,776 | |<--Request-| | (1) 487 Request Cancelled
15:52:51,780 | Request Adaptation | Adapter: CUCM-pr-01
15:52:51,783 | |----ACK--->| | (1) sip:4084771498@10.30.15.38
15:52:51,784 |<--Request-| | | (1) 487 Request Cancelled
15:52:51,787 |----ACK--->| | | (1) sip:4084771498@10.30.12.16


Thanks,
Rohit

Try enabling the TSAPI traces and see if the AE Services is receiving events from the Communication Manager after the call is delivered to the other switch. There are instructions in the Devconnect FAQ "What is the procedure for enabling and accessing the AE Services logs for TSAPI (trace, tracing, g3trace, csta_trace)?".

If you need me to check the traces for you, open a technical Support ticket. Once I get the ticket, I will let you know where to put the traces.

Martin