I am running CUCM 11.0. I've installed Centos 7 which is running Python 2.7 in order to run the samplePolicyApp.py I downloaded from the CURRI DevNet page.
I have created the External Call Control Profile, and for the Web Service I entered: http://192.168.100.25:6162
Then I added this ECCP to a DN of a test user on CUCM. I also added it to a Translation Pattern on CUCM.
When a call is placed to either, nothing is reported on the Python screen, and the call behaves according to the status of "Call Treatment on Failures". In other words, it succeeds if I ALLOW, and it fails if select BLOCK.
On the Centos Server I am running the command: python ./samplePolicyApp.py 192.168.100.25 6162 http
I get the resulting:
HTTP://HOST_NAME:PORT http :// 192.168.100.25 : 6162
Fri Apr 8 16:15:55 2016 HTTP CURRI Server Started - 192.168.100.25:6162
If I use a normal web browser to open the page I get the resulting:
This is a test.
You accessed path: /
So the Python side seems good. On the Centos server I ran tcpdump. I noticed that the CUCM *NEVER* connects to the Centos/Python server.
I created another ECCP and assigned that to the DN (while the Python server was running) but that made no difference. Also, if I use lsof or netstat to view active connections, there are none except for my SSH session.
Where do I go from here?
It seems that by adding routingrequest to the end of the URL that now the CUCM connects to the server.
*PLEASE* could you add that rather valuable snippet to the README in the Sample ZIP file?
Thanks for the feedback. It's not just this sample app that will see that issue, any app you deploy using ECCP should have a URI that includes the full path to the web app. All of the Unified CM examples show that, but I agree that it could be a bit more explicit.
One more question: I have it "working" ... sort of. My intention is for it to play a greeting before passing the call to the user. The announcement has been uploaded (needed to have TAC fix permissions first before the upload would work) and the script calls it by the name I saved it as. If I use a wrong name, the failure option is used, so I know it's reading it. But when it should play the message, all I hear is continuous ringback.
Thanks a million for this very useful tool!
How is your call coming in? SIP trunk?
So it's PRI -> H323 Cisco Gateway -> CUCM 11.0
It has to do with the way the trunk sets up early media to the caller. CUCM is providing media via announcements prior to the call being delivered to the phone, so the trunk has to support the early media. It works out of the box with MGCP gateways. SIP requires some tweaking to get early offer, and H.323 requires the same. If you call phone to phone it will work, but the gateways may require some additional configuration.
Do you have any idea what the H323 gateway would need? I have already enabled:
voice rtp send-recv
which enables the early cut-over of voice.
Do you know of anything else?
that would be the right command. There are times where the ISDN providers ignore PI and won't open a b-channel to receive media. It looks like there is enhancement to address CSCuh15872 coming in 11.5, but, for now, TAC has a workaround that should work in the interim. If you open a case, they can verify that it is the issue and help you with the workaround. Refer to that defect and let them know that you believe you're hitting it.
Thanks for that info. TAC have applied the workaround (it's a TCL script on the gateway). So now, the announcement plays, the call diverts to the called party, he answers, he hears me speaking, but I only hear ringback instead of his voice.
Hmmm, that sounds like a side-effect of the TCL script that the connect message is not flowing through correctly. The best course of action is to re-open your TAC case and have them troubleshoot with you. I've done a lot of CURRI & announcement work, and never had this particular issue happen to me.
I am pleased to say it's FIXED, and I though to reply to the thread in case anyone else runs into this.
So in summary:
TAC gave me a TCL script on the H323 gateway called "forceanswer.tcl". This allowed the gateway to send the greeting announcement to the caller. However, after the called party answered, while he could hear the caller, the caller still only heard ring back.
This seems to be fixed by the following"
Under Service Parameter Configuration / Call Manager Service on the CUCM, the setting for "Send H225 User Info Message" was at default: namely "User Info for Call Progress Tone". I changed it to "Use ANN for Ring Back" and made sure that the MRGL of the gateway had an ANN resource in it.
I am still testing, but this seems to have fixed it.