in the test app for webcallcontroler for ECC lower middle of the page. There is a section for events. When a station is subscribed to you can see the events in this window.

Is there any way to get access to these events through an API? I can't seem to find it. I'm building an IVR application and I want to be able to subscribe a station and get the returned event so I can tell if the subscription was successful or not. The returned response for a subscribe station call to ECC does not tell you if the subscription was successful or not.

Hi,

The success/failure status message for the subscription will be sent to the call back url used in the subscription

In the subscription request, you would need to send a callbackurl, to that callbackurl an event would be sent back mentioning whether the subscription was successful or not.

Also, to the same callbackurl only the call events will be posted

Thank You,
Dinesh

understood but is it possible to intercept the success/failure message that is sent to the callback url?

Can you help understand why you'd want to do this? We've always thought of the callback URL corresponding to "the" application (the IVR, in your case). Under what circumstances would the subscriber, handler of events, and handler of unsuccessful subscriptions not the be same entity?

Also, Dinesh, the 3.4 API document says this for the HTTP response for the subscribe request:
200 – for successful subscription
400 – invalid request, callBackUrl invalid/not reachable
500 – Runtime errors

Are there cases where a 200 OK would be sent by the EventingConnector but the subscription actually doesn't succeed? If so, we should probably update the API documentation to cover this case.

I'm now recalling that there are in fact cases under which EventingConnector returns 200 OK but the subscription actually fails. Dinesh can correct me if I'm wrong on this. I think we made a conscious decision to improve runtime efficiences at the expense of requiring asynchronous handling of success / failure. The ECC subscriptions traverse a path across several Breeze snap-ins then to AES, CM and back again. We would have to hold the HTTP transaction open and block a number of threads for this entire round trip if we wanted the 200 OK in the subscription to reflect that the end to end subscription had succeeded. We decided instead to make the 200 OK mean "We got your well-formed request and are acting on it", with the real status then being delivered asynchronously in the resulting event stream.

It looks like our documentation could be improved in this area. I'll make sure that happens.

One other point: I think that you're probably aware that the Web Call Controller is a sample application rather than a production application. Those events that you see are the same events that would be posted to the callback URL that you would provide in your subscription. While you can't get access to the events FROM the Web Call Controller, you can get access to the SAME events as are seen by the Web Call Controller. If you'd like, you can have a subscription active on your own application simultaneously with WCC being active and subscribed.

Joel,

Yes its possible that HTTP subscription request returned with 200 OK but the subscription actually fails and only for those cases failure status event will be sent to the call back url. If the subscriptions request itself is failed, then there won't be any failure status event to the call back url

We can enhance the REST API doc eventing section to be more clear with these details

Thank You,
Dinesh