Re: [cisco-voip] Java and custom UCCX

[Anthony Holloway]

The one I linked in my last reply?  ;)

On Wed, Apr 15, 2020 at 7:30 PM  wrote:

> Haha oh dear, I totally forgot Tanner reached out and had an inventive
> way to get around this issue.. dynamically loading the classes.. which we
> think probably would have worked.
>
> But honestly not going to sink anymore time into it at this stage.
> Happy with it as an external proxy.
>
> I did find a bug for the cert thing, but can't find the ID now 
>
>
> Cheers,
>
> Tim
> --
> *From:* Anthony Holloway 
> *Sent:* Wednesday, 15 April 2020 4:03 PM
> *To:* Tim Smith 
> *Cc:* voyp list, cisco-voip (cisco-voip@puck.nether.net) <
> cisco-voip@puck.nether.net>
> *Subject:* Re: [cisco-voip] Java and custom UCCX
>
>
> EXTERNAL SENDER WARNING. This message was sent from outside your
> organisation. Please do not click links or open attachments unless you
> recognise the source of this email and know the content is safe.
> Thanks for the update.  Strange that the cert didn't work for you.  It used
> to be in 9.x and lower
> 
> that you'd need root access to add certs to the keystore, but not since v10.
>
> On Tue, Apr 14, 2020 at 11:01 PM  wrote:
>
> Hey Anthony, been buried working on it  forgot to check back here.
>
> Hope everyone is keeping safe!
>
> I think probably was working with most of the guys you are thinking of
> there inc Cloverhound.
> It managed to stump a lot of people, and we did end up digging pretty deep
> with a couple of great Cisco escalation guys too.
> I think the only people that could solve it are really deep in the
> development team, and it's not really worth it.
> The short answer is upgrade or offbox (because we have a nice version of
> this working in 11.x) already with no issues.
>
> The big issue was the old JRE, and the lack of TLS 1.2.
> All of the code was running off box with exactly the same versions etc, so
> it seemed to be something specific to UCCX, possibly a security measure or
> restriction.
>
> Anyway, we wanted to run off box proxy, but we weren't permitted in this
> environment.
> So we built off box in AWS (API Gateway and Lambda)
> And it's working really nicely.
>
> I think as you said below... no more Java..
> Use the Set Steps if required (we have done that instead of the built in
> REST step)
> And we have one custom class to override the certificate trust (as there
> also seems to be a bug with that in the version of UCCX - it doesn't trust
> things in it's trust store) 
>
> But yeah, no more Java seems like a good plan.
>
> Cheers,
>
> Tim
>
>
> --
> *From:* Anthony Holloway 
> *Sent:* Wednesday, 8 April 2020 6:54 AM
> *To:* Tim Smith 
> *Cc:* voyp list, cisco-voip (cisco-voip@puck.nether.net) <
> cisco-voip@puck.nether.net>
> *Subject:* Re: [cisco-voip] Java and custom UCCX
>
>
> EXTERNAL SENDER WARNING. This message was sent from outside your
> organisation. Please do not click links or open attachments unless you
> recognise the source of this email and know the content is safe.
> I see your post on the developer forums, and as as here, didn't get much
> in the way of a solution.  Did you ever end up moving past your hurdles and
> successfully solve this one?
>
> On Thu, Mar 26, 2020 at 6:58 AM Pawlowski, Adam  wrote:
>
> I shunted in a new oracle jdbc jar to replace the existing one (and thus
> losing the entire database connection pooling framework that CCX has)
> because the in built one is archaic and doesn’t work with oracle encryption
> or modern rev, then wrote some java code to handle simple queries.
>
>
>
> It works until it doesn’t want to – SU installs or system reboots
> sometimes the jar doesn’t load for … no given reason at all, then you have
> to reboot to bring it up hopefully.
>
>
>
> As bad as it sounds if you’re stuck on that system would it be more
> reasonable to write a broker/proxy that can shuttle these requests for you?
>
>
>
> Adam
>
>
>
> *From:* cisco-voip  *On Behalf Of *Anthony
> Holloway
> *Sent:* Thursday, March 26, 2020 2:32 AM
> *To:* Tim Smith 
> *Cc:* voyp list, cisco-voip (cisco-voip@puck.nether.net) <
> cisco-voip@puck.nether.net>
> *Subject:* Re: [cisco-voip] Java and custom UCCX
>
>
>
> I did a Java thingonce
> never
> again man.  never again.
>
>
>
> I would recommend posting in the UCCX 

Re: [cisco-voip] Java and custom UCCX

[tim.smith]

Haha oh dear, I totally forgot Tanner reached out and had an inventive way to 
get around this issue.. dynamically loading the classes.. which we think 
probably would have worked.

But honestly not going to sink anymore time into it at this stage.
Happy with it as an external proxy.

I did find a bug for the cert thing, but can't find the ID now 


Cheers,

Tim

From: Anthony Holloway 
Sent: Wednesday, 15 April 2020 4:03 PM
To: Tim Smith 
Cc: voyp list, cisco-voip (cisco-voip@puck.nether.net) 

Subject: Re: [cisco-voip] Java and custom UCCX


EXTERNAL SENDER WARNING. This message was sent from outside your organisation. 
Please do not click links or open attachments unless you recognise the source 
of this email and know the content is safe.

Thanks for the update.  Strange that the cert didn't work for you.  It used to 
be in 9.x and 
lower
 that you'd need root access to add certs to the keystore, but not since v10.

On Tue, Apr 14, 2020 at 11:01 PM 
mailto:tim.sm...@enject.com.au>> wrote:
Hey Anthony, been buried working on it  forgot to check back here.

Hope everyone is keeping safe!

I think probably was working with most of the guys you are thinking of there 
inc Cloverhound.
It managed to stump a lot of people, and we did end up digging pretty deep with 
a couple of great Cisco escalation guys too.
I think the only people that could solve it are really deep in the development 
team, and it's not really worth it.
The short answer is upgrade or offbox (because we have a nice version of this 
working in 11.x) already with no issues.

The big issue was the old JRE, and the lack of TLS 1.2.
All of the code was running off box with exactly the same versions etc, so it 
seemed to be something specific to UCCX, possibly a security measure or 
restriction.

Anyway, we wanted to run off box proxy, but we weren't permitted in this 
environment.
So we built off box in AWS (API Gateway and Lambda)
And it's working really nicely.

I think as you said below... no more Java..
Use the Set Steps if required (we have done that instead of the built in REST 
step)
And we have one custom class to override the certificate trust (as there also 
seems to be a bug with that in the version of UCCX - it doesn't trust things in 
it's trust store) 

But yeah, no more Java seems like a good plan.

Cheers,

Tim



From: Anthony Holloway 
mailto:avholloway%2bcisco-v...@gmail.com>>
Sent: Wednesday, 8 April 2020 6:54 AM
To: Tim Smith mailto:tim.sm...@enject.com.au>>
Cc: voyp list, cisco-voip 
(cisco-voip@puck.nether.net) 
mailto:cisco-voip@puck.nether.net>>
Subject: Re: [cisco-voip] Java and custom UCCX


EXTERNAL SENDER WARNING. This message was sent from outside your organisation. 
Please do not click links or open attachments unless you recognise the source 
of this email and know the content is safe.

I see your post on the developer forums, and as as here, didn't get much in the 
way of a solution.  Did you ever end up moving past your hurdles and 
successfully solve this one?

On Thu, Mar 26, 2020 at 6:58 AM Pawlowski, Adam 
mailto:aj...@buffalo.edu>> wrote:

I shunted in a new oracle jdbc jar to replace the existing one (and thus losing 
the entire database connection pooling framework that CCX has) because the in 
built one is archaic and doesn’t work with oracle encryption or modern rev, 
then wrote some java code to handle simple queries.



It works until it doesn’t want to – SU installs or system reboots sometimes the 
jar doesn’t load for … no given reason at all, then you have to reboot to bring 
it up hopefully.



As bad as it sounds if you’re stuck on that system would it be more reasonable 
to write a broker/proxy that can shuttle these requests for you?



Adam



From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Anthony Holloway
Sent: Thursday, March 26, 2020 2:32 AM
To: Tim Smith mailto:tim.sm...@enject.com.au>>
Cc: voyp list, cisco-voip 
(cisco-voip@puck.nether.net) 
mailto:cisco-voip@puck.nether.net>>
Subject: Re: [cisco-voip] Java and custom UCCX



I did a Java 
thingoncenever
 again man.  never again.



I would recommend posting in the UCCX community 

[cisco-voip] Cisco 8800 series repairs

[Terry Oakley via cisco-voip]

Does anyone know of a place in Canada that will repair Cisco 8800 series end
devices?

 

Thanks

 

Terry



smime.p7s
Description: S/MIME cryptographic signature
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Java and custom UCCX

[Anthony Holloway]

Thanks for the update.  Strange that the cert didn't work for you.  It used
to be in 9.x and lower
 that you'd need
root access to add certs to the keystore, but not since v10.

On Tue, Apr 14, 2020 at 11:01 PM  wrote:

> Hey Anthony, been buried working on it  forgot to check back here.
>
> Hope everyone is keeping safe!
>
> I think probably was working with most of the guys you are thinking of
> there inc Cloverhound.
> It managed to stump a lot of people, and we did end up digging pretty deep
> with a couple of great Cisco escalation guys too.
> I think the only people that could solve it are really deep in the
> development team, and it's not really worth it.
> The short answer is upgrade or offbox (because we have a nice version of
> this working in 11.x) already with no issues.
>
> The big issue was the old JRE, and the lack of TLS 1.2.
> All of the code was running off box with exactly the same versions etc, so
> it seemed to be something specific to UCCX, possibly a security measure or
> restriction.
>
> Anyway, we wanted to run off box proxy, but we weren't permitted in this
> environment.
> So we built off box in AWS (API Gateway and Lambda)
> And it's working really nicely.
>
> I think as you said below... no more Java..
> Use the Set Steps if required (we have done that instead of the built in
> REST step)
> And we have one custom class to override the certificate trust (as there
> also seems to be a bug with that in the version of UCCX - it doesn't trust
> things in it's trust store) 
>
> But yeah, no more Java seems like a good plan.
>
> Cheers,
>
> Tim
>
>
> --
> *From:* Anthony Holloway 
> *Sent:* Wednesday, 8 April 2020 6:54 AM
> *To:* Tim Smith 
> *Cc:* voyp list, cisco-voip (cisco-voip@puck.nether.net) <
> cisco-voip@puck.nether.net>
> *Subject:* Re: [cisco-voip] Java and custom UCCX
>
>
> EXTERNAL SENDER WARNING. This message was sent from outside your
> organisation. Please do not click links or open attachments unless you
> recognise the source of this email and know the content is safe.
> I see your post on the developer forums, and as as here, didn't get much
> in the way of a solution.  Did you ever end up moving past your hurdles and
> successfully solve this one?
>
> On Thu, Mar 26, 2020 at 6:58 AM Pawlowski, Adam  wrote:
>
> I shunted in a new oracle jdbc jar to replace the existing one (and thus
> losing the entire database connection pooling framework that CCX has)
> because the in built one is archaic and doesn’t work with oracle encryption
> or modern rev, then wrote some java code to handle simple queries.
>
>
>
> It works until it doesn’t want to – SU installs or system reboots
> sometimes the jar doesn’t load for … no given reason at all, then you have
> to reboot to bring it up hopefully.
>
>
>
> As bad as it sounds if you’re stuck on that system would it be more
> reasonable to write a broker/proxy that can shuttle these requests for you?
>
>
>
> Adam
>
>
>
> *From:* cisco-voip  *On Behalf Of *Anthony
> Holloway
> *Sent:* Thursday, March 26, 2020 2:32 AM
> *To:* Tim Smith 
> *Cc:* voyp list, cisco-voip (cisco-voip@puck.nether.net) <
> cisco-voip@puck.nether.net>
> *Subject:* Re: [cisco-voip] Java and custom UCCX
>
>
>
> I did a Java thingonce
> never
> again man.  never again.
>
>
>
> I would recommend posting in the UCCX community forum
> ,
> as there are at least 2 or 3 regulars who I believe could help with this
> type of thing.
>
>
>
> And, it's less active, but the developer section for UCCX
> 
> might be worth a shot too.
>
>
>
> Last but not least, the dude's over at Cloverhound seem to love
> challenges, as they've competed in like a dozen Engineering Death match
> episodes.  Maybe ping them on Twitter
>