[cisco-voip] social miner setup design queries

2020-01-28 Thread naresh rathore
hi all, i am currently testing web chat in my office server but soon i have to deploy it at customer end. i have some queries regarding design. 1. only web server (with build in uccx chat webform) needs to communicate with social miner or the customer who is using website also should be

Re: [cisco-voip] Expressway Cluster failover for MRA...

2020-01-28 Thread Charles Goldsmith
We've built them as individual pairs (Edge/Core) and then use DNS to control which one goes where. Without the cluster, we know that Edge1 will always talk to Core1. I get the feeling that clustering was always meant to be in the same DC, and for redundancy purposes in the same DC. If you have

Re: [cisco-voip] Expressway Cluster failover for MRA...

2020-01-28 Thread Lelio Fulgenzi
How does no. 2 actually solve the problem of having to log back in? Is this a supported/suggested deployment method? It’s been a while since I first looked at things and don’t recall things mentioning using the cluster name in the SRV records. I’m intrigued. And interested! -sent from

Re: [cisco-voip] Expressway Cluster failover for MRA...

2020-01-28 Thread Ryan Huff
1.) It used to be in previous versions that all cluster nodes could technically be active at any time and SRV weights and priorities could influence the path selection but not guarantee it end-to-end when all cluster nodes are up and running. I believe this behavior has changed/improved and I

Re: [cisco-voip] Expressway Cluster failover for MRA...

2020-01-28 Thread Lelio Fulgenzi
I could be wrong here, but from what was explained to me... You may be able to control the initial connection from off-prem device to the E of your choosing, but you cannot control which C that E talks to. And vice-versa. So, you could point people to Ea, but they could easily be sent to Cs.

[cisco-voip] Expressway Cluster failover for MRA...

2020-01-28 Thread Jonathan Charles
We have two pairs of Expressway clusters (C/E) at two different locations (primary and DR)... The cluster is up, however, we want to make sure that we are in Active/Standby. Currently, we have one of our SRV records for collab-edge set at 5 (the backup is at 10) with the same weight. The

Re: [cisco-voip] HTTP Response for HTTP Triggered Script

2020-01-28 Thread Anthony Holloway
I mean, you could probably contain it all in a single app script and by inspecting the triggering events/data, figure out which phase you're on. E.g., If trigger is HTTP Trigger then Phase 1; If Trigger is JTAPI extension 1000, then Phase 3, else Phase 2 There's probably something to be

[cisco-voip] default for "Multiple Call/Call Waiting Settings on Device" and "Forwarded Call Information Display on Device"

2020-01-28 Thread Lelio Fulgenzi
Is there somewhere I can set the default values I'd like to see for "Multiple Call/Call Waiting Settings on Device" and "Forwarded Call Information Display on Device" when I go and add a DN to a device? The use case here is me clicking on "Add a new DN" in the right hand side of listed DNs on

Re: [cisco-voip] Cisco Headset Inventory SSL Issue

2020-01-28 Thread Matthew Loraditch
After an hour down the rabbit hole: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvk45630/?rfs=iqvred Hopefully this helps someone else out! Matthew Loraditch Sr. Network Engineer p: 443.541.1518 w: www.heliontechnologies.com | e: mloradi...@heliontechnologies.com From: cisco-voip On

[cisco-voip] Cisco Headset Inventory SSL Issue

2020-01-28 Thread Matthew Loraditch
So we have a couple of the Cisco headsets and noticed they have never reported to the inventory function. Figured out that they connect over ssl and are validating my tomcat cert. Cert is signed by my internal CA. Phones don't trust that CA. What trust does it need to go in and how do I ensure

Re: [cisco-voip] HTTP Response for HTTP Triggered Script

2020-01-28 Thread Johnson, Tim
Bingo bango bongo. From: Matthew Loraditch Sent: Tuesday, January 28, 2020 10:40 AM To: Anthony Holloway ; Johnson, Tim Cc: Cisco VoIP Group Subject: RE: [cisco-voip] HTTP Response for HTTP Triggered Script So basically I need 3 separate applications. The HTTP Trigger to take the input then

Re: [cisco-voip] HTTP Response for HTTP Triggered Script

2020-01-28 Thread Tanner Ezell
This is normal and expected behavior. Use the HTTP trigger app to catch the request, use Trigger Application step, and sessions to pass success failure, then end the http trigged app. That'll do the request. Good luck On Tue, Jan 28, 2020 at 6:15 AM Johnson, Tim wrote: > As far as my

Re: [cisco-voip] HTTP Response for HTTP Triggered Script

2020-01-28 Thread Anthony Holloway
Tim is correct: this is normal from my experience too. I feel partly responsible for your woes, since I think you found that solution from me pointing out the script repository online. Thinking about it some more, I think I would have the HTTP Triggered Application use the Trigger Application

Re: [cisco-voip] HTTP Response for HTTP Triggered Script

2020-01-28 Thread Johnson, Tim
As far as my experience, this is “normal” for UCCX. Yes, I believe the request stays open until the script ends. I believe we opened up a TAC case about it a year or two ago but I don’t believe it went anywhere. From: cisco-voip On Behalf Of Matthew Loraditch Sent: Tuesday, January 28, 2020

[cisco-voip] HTTP Response for HTTP Triggered Script

2020-01-28 Thread Matthew Loraditch
Got the following comment from the developer who is writing an app that will queue a call via http trigger: It seems like the MobileApp integration is accepting my request, spits back some HTML, but the HTTP request remains open until the queued call is answered. Ideally, that HTTP request