Re: [cisco-voip] Expressway - 3rd Party Border Recommendation

[Walenta, Philip]

I would second this opinion.  I've done a lot of work with CUBE and it does not 
handle phone proxy well at all (or much when it comes to endpoint auth 
situations). VCS is your best best.

Sent from my iPhone

On Dec 1, 2014, at 8:55 PM, Josh Warcop 
mailto:j...@warcop.com>> wrote:

TAC opened 3 bugs on my behalf related to CUBE line-side SIP proxy. Not 
including the documentation bugs that were opened.  CUBE in that fashion has a 
few specific use cases and in my simple use case of replacing ASA phone-proxy 
it didn't hold up. Expressway is your go to solution for Jabber and TC 
endpoints and soon DX series.

Not saying CUBE proxy is terrible, but I would tread carefully down that path 
and do plenty of testing.

Sent from my Windows Phone

From: NateCCIE
Sent: ‎12/‎1/‎2014 7:58 PM
To: 'Brian Meade'; 'Pawlowski, 
Adam'
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Expressway - 3rd Party Border Recommendation


Expressway is the first thought, then CUBE Lineside proxy would be where to go 
for 3rd party.



https://ciscocollab.wordpress.com/2014/04/08/cube-sip-lineside-phone-vpn-configuration/





From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Brian 
Meade
Sent: Monday, December 1, 2014 11:51 AM
To: Pawlowski, Adam
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Expressway - 3rd Party Border Recommendation



I've done this before with a large Avaya setup.  We had all of the UC stuff in 
a separate VRF and all soft clients had to come through an SBC for 
registration.  We demoed Sipera and Acme.  Sipera got the job done cheaper, but 
Acme scaled much better for us.  I think CUCM supports Acme SBCs as well as an 
alternative to CUBE.



Brian



On Mon, Dec 1, 2014 at 1:23 PM, Pawlowski, Adam 
mailto:aj...@buffalo.edu>> wrote:

Afternoon all,

Trying to get some opinion on how (if) you would put up a perimeter to 
your UCM clusters to bring in 3rd party clients, softphones, etc, that are SIP 
based and reside outside of your secured LAN? Most of our desktops are on 
public addresses, not behind any particular hardware firewall, just software on 
the host. I'm concerned that the host could be compromised, or as seen with 
some soft clients, they just get harassed by driveby SIP/H.323 scans and calls.

I haven't seen any great justification for trying to fence/proxy 
connectivity to the UCM for Jabber, X-Lite, etc, to the cluster, but general 
security practice is saying that if you can make it more secure, it is at least 
worth looking into.

I've looked at trying to set the UBE up for proxy/passthrough 
registrar, and this seems tedious because it doesn't proxy auth and requires 
dial-peer configuration (making dual usage as a gateway cumbersome). I have 
heard "use expressway" a few times but have no idea how that would work for 3rd 
party SIP devices. Other than that, I spent a bit of time looking at stuff from 
Edgewater, OpenSIPS, etc, but it is not clear to me if any of these products 
are worth the trouble, and what the Cisco recommended way to go about this is.

Anyone have any experience or thought in this area? Is this a bad idea? 
Anything to say about trying to secure potentially 'untrusted' connectivity on 
a larger scale?

Regards,

Adam Pawlowski
SUNYAB

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip



___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] UC integration with MS Office and Lync/MOC

[Josh Warcop]

I'm first coming at this from a Microsoft perspective. Have you moved to Lync 
Server 2013 and running OCS for CUCILYNC backward compatibility?

MS Office 2013 includes the Lync 2013 client so you would have to suppress that 
part of the upgrade.

You're not finding products compatible with both because Microsoft forked that 
between OCS and Lync with the Office 2007 to Office 2013 transition.

My recommendation is to drop CUCILYNC.

Sent from my Windows Phone

From: george.hend...@l-3com.com
Sent: ‎12/‎1/‎2014 3:57 PM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] UC integration with MS Office and Lync/MOC

Hey Guys,

  We've been running Cisco UC integration version 8.X (CUCILYNC 8.6) for a 
while now and it works great with MS Office Communicator R2 and Office 2010, 
including the click to call add-in.  Our MS folks are looking to migrate 
clients to MS Office 2013, but still use MOC R2.  I can't find any 
product/solution that is compatible with MOC R2 as well as Office 2013 and 
still provide click to call functionality.  Are there any options from Cisco 
that we can use that will allow integration with MS Office Communicator R2 and 
Office 2013 that will provide call control and click to call too?  Also, it 
seems the "new" CUCILYNC version is a totally separate window, instead of an 
add-on section to the bottom, like it is with MOC R2.

Thanks,
Bill
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Expressway - 3rd Party Border Recommendation

[Josh Warcop]

TAC opened 3 bugs on my behalf related to CUBE line-side SIP proxy. Not 
including the documentation bugs that were opened.  CUBE in that fashion has a 
few specific use cases and in my simple use case of replacing ASA phone-proxy 
it didn't hold up. Expressway is your go to solution for Jabber and TC 
endpoints and soon DX series.

Not saying CUBE proxy is terrible, but I would tread carefully down that path 
and do plenty of testing.

Sent from my Windows Phone

From: NateCCIE
Sent: ‎12/‎1/‎2014 7:58 PM
To: 'Brian Meade'; 'Pawlowski, 
Adam'
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Expressway - 3rd Party Border Recommendation

Expressway is the first thought, then CUBE Lineside proxy would be where to go 
for 3rd party.



https://ciscocollab.wordpress.com/2014/04/08/cube-sip-lineside-phone-vpn-configuration/





From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Brian 
Meade
Sent: Monday, December 1, 2014 11:51 AM
To: Pawlowski, Adam
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Expressway - 3rd Party Border Recommendation



I've done this before with a large Avaya setup.  We had all of the UC stuff in 
a separate VRF and all soft clients had to come through an SBC for 
registration.  We demoed Sipera and Acme.  Sipera got the job done cheaper, but 
Acme scaled much better for us.  I think CUCM supports Acme SBCs as well as an 
alternative to CUBE.



Brian



On Mon, Dec 1, 2014 at 1:23 PM, Pawlowski, Adam mailto:aj...@buffalo.edu> > wrote:

Afternoon all,

Trying to get some opinion on how (if) you would put up a perimeter to 
your UCM clusters to bring in 3rd party clients, softphones, etc, that are SIP 
based and reside outside of your secured LAN? Most of our desktops are on 
public addresses, not behind any particular hardware firewall, just software on 
the host. I'm concerned that the host could be compromised, or as seen with 
some soft clients, they just get harassed by driveby SIP/H.323 scans and calls.

I haven't seen any great justification for trying to fence/proxy 
connectivity to the UCM for Jabber, X-Lite, etc, to the cluster, but general 
security practice is saying that if you can make it more secure, it is at least 
worth looking into.

I've looked at trying to set the UBE up for proxy/passthrough 
registrar, and this seems tedious because it doesn't proxy auth and requires 
dial-peer configuration (making dual usage as a gateway cumbersome). I have 
heard "use expressway" a few times but have no idea how that would work for 3rd 
party SIP devices. Other than that, I spent a bit of time looking at stuff from 
Edgewater, OpenSIPS, etc, but it is not clear to me if any of these products 
are worth the trouble, and what the Cisco recommended way to go about this is.

Anyone have any experience or thought in this area? Is this a bad idea? 
Anything to say about trying to secure potentially 'untrusted' connectivity on 
a larger scale?

Regards,

Adam Pawlowski
SUNYAB

___
cisco-voip mailing list
cisco-voip@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-voip



___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Finisse -10.5 - cfadmin webpage doesnt open

[Jason Aarons (AM)]

What OS/Browser versions?  If IE have you tried Compatibility mode?

http://docwiki.cisco.com/wiki/Unified_CCE_Software_Compatibility_Matrix_for_10.5%28x%29#Unified_CCE_Release_10.5..281.29_Supported_Browsers


From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
0703Manjunath
Sent: Saturday, November 29, 2014 12:43 PM
To: cisco-voip (cisco-voip@puck.nether.net)
Subject: [cisco-voip] Finisse -10.5 - cfadmin webpage doesnt open


hello,


Iam stuck with  a issue on finesse  cfadmin  webpage doesnt open.

we are using UCCE 10.5 , agent webpage opens but admin page doesnt.

Does anyone have any clue about this issue

--
Cheers
Manjunath


itevomcid
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] UC integration with MS Office and Lync/MOC

[Scott Voll]

Correct.  The new cicilync is more like jabber. If you go to the o365 cloud
it pretty much breaks everything. Good luck

Scott

On Monday, December 1, 2014,  wrote:

>  Hey Guys,
>
>
>
>   We’ve been running Cisco UC integration version 8.X (CUCILYNC 8.6) for a
> while now and it works great with MS Office Communicator R2 and Office
> 2010, including the click to call add-in.  Our MS folks are looking to
> migrate clients to MS Office 2013, but still use MOC R2.  I can’t find any
> product/solution that is compatible with MOC R2 as well as Office 2013 and
> still provide click to call functionality.  Are there any options from
> Cisco that we can use that will allow integration with MS Office
> Communicator R2 and Office 2013 that will provide call control and click to
> call too?  Also, it seems the “new” CUCILYNC version is a totally separate
> window, instead of an add-on section to the bottom, like it is with MOC R2.
>
>
>
> Thanks,
>
> Bill
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] H245Interface & Related Processes

[Daniel Pagan]

Hey Brian – hope you’re doing well. This is a difficult issue to reproduce so a 
pcap would be tricky to obtain.

I’ll try and recreate the issue in a lab and see what results I get from an SDL 
process creation standpoint.

Thanks!

- Dan


From: bmead...@gmail.com [mailto:bmead...@gmail.com] On Behalf Of Brian Meade
Sent: Monday, December 01, 2014 5:51 PM
To: Ryan Ratliff (rratliff)
Cc: Daniel Pagan; cisco-voip voyp list
Subject: Re: [cisco-voip] H245Interface & Related Processes

Also should be fairly easy to capture via a packet capture on Cluster 1 if this 
is easily reproducible for the call flow.

Brian

On Mon, Dec 1, 2014 at 5:32 PM, Ryan Ratliff (rratliff) 
mailto:rratl...@cisco.com>> wrote:
Short answer without confirming in the lab is yes, when I send you my H245 
address I expect you to start a TCP connection to me on that port so we can 
start H245.


-Ryan

On Dec 1, 2014, at 5:12 PM, Daniel Pagan 
mailto:dpa...@fidelus.com>> wrote:

Folks:

Hoping to get some insight on SDL process creation for H245…

Scenario is three CUCM clusters communicating over ICTs. Call is routed from 
Cluster-1 to Cluster-2… then Cluster-2 to Cluster-3. Cluster-3 sends the H245 
address & port info via H225 ALERTING to Cluster-2, which then sends its own to 
Cluster-1. Issue is Cluster-1 never establishes the H245 session with 
Cluster-2. The H245 address and port is received on Cluster-1 but no H245 
processes are being created for the MSD/TCS exchange. According to SDL traces 
on Cluster-2, the latest state of H245 on the node *sending* the ALERTING 
message is “waitForTransportEstablishment”. On Cluster-1, the H245Interface 
process is never created according to SDL traces, so we never even reach the 
opportunity for TCS media caps exchange. MXTimeout occurs shortly after.

Question is… For a node receiving an H245 address & port info via H225 (the 
calling cluster…), is creation of the H245Interface and/or related H245 process 
dependent on CUCM *first* establishing the new, 2nd TCP socket with the remote 
H.323 endpoint that advertised the H.245 port. In other words, at an SDL level, 
is H245Interface created only after the 2nd TCP session is successfully 
established at the transport level for H245 TCP communication? Knowing this 
would help me assess the likelihood of the issue being related to issues at the 
TCP level.

Thanks!

- Dan
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip


___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Expressway - 3rd Party Border Recommendation

[NateCCIE]

Expressway is the first thought, then CUBE Lineside proxy would be where to go 
for 3rd party.

 

https://ciscocollab.wordpress.com/2014/04/08/cube-sip-lineside-phone-vpn-configuration/

 

 

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Brian 
Meade
Sent: Monday, December 1, 2014 11:51 AM
To: Pawlowski, Adam
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Expressway - 3rd Party Border Recommendation

 

I've done this before with a large Avaya setup.  We had all of the UC stuff in 
a separate VRF and all soft clients had to come through an SBC for 
registration.  We demoed Sipera and Acme.  Sipera got the job done cheaper, but 
Acme scaled much better for us.  I think CUCM supports Acme SBCs as well as an 
alternative to CUBE.

 

Brian

 

On Mon, Dec 1, 2014 at 1:23 PM, Pawlowski, Adam mailto:aj...@buffalo.edu> > wrote:

Afternoon all,

Trying to get some opinion on how (if) you would put up a perimeter to 
your UCM clusters to bring in 3rd party clients, softphones, etc, that are SIP 
based and reside outside of your secured LAN? Most of our desktops are on 
public addresses, not behind any particular hardware firewall, just software on 
the host. I'm concerned that the host could be compromised, or as seen with 
some soft clients, they just get harassed by driveby SIP/H.323 scans and calls.

I haven't seen any great justification for trying to fence/proxy 
connectivity to the UCM for Jabber, X-Lite, etc, to the cluster, but general 
security practice is saying that if you can make it more secure, it is at least 
worth looking into.

I've looked at trying to set the UBE up for proxy/passthrough 
registrar, and this seems tedious because it doesn't proxy auth and requires 
dial-peer configuration (making dual usage as a gateway cumbersome). I have 
heard "use expressway" a few times but have no idea how that would work for 3rd 
party SIP devices. Other than that, I spent a bit of time looking at stuff from 
Edgewater, OpenSIPS, etc, but it is not clear to me if any of these products 
are worth the trouble, and what the Cisco recommended way to go about this is.

Anyone have any experience or thought in this area? Is this a bad idea? 
Anything to say about trying to secure potentially 'untrusted' connectivity on 
a larger scale?

Regards,

Adam Pawlowski
SUNYAB

___
cisco-voip mailing list
cisco-voip@puck.nether.net  
https://puck.nether.net/mailman/listinfo/cisco-voip

 

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] H245Interface & Related Processes

[Daniel Pagan]

Thanks Ryan - that's what I was hoping to hear. I'll try to set this up in a 
lab to confirm with some simple ACLs.

- Dan

From: Ryan Ratliff (rratliff) [mailto:rratl...@cisco.com]
Sent: Monday, December 01, 2014 5:33 PM
To: Daniel Pagan
Cc: cisco-voip voyp list
Subject: Re: [cisco-voip] H245Interface & Related Processes

Short answer without confirming in the lab is yes, when I send you my H245 
address I expect you to start a TCP connection to me on that port so we can 
start H245.


-Ryan

On Dec 1, 2014, at 5:12 PM, Daniel Pagan 
mailto:dpa...@fidelus.com>> wrote:

Folks:

Hoping to get some insight on SDL process creation for H245...

Scenario is three CUCM clusters communicating over ICTs. Call is routed from 
Cluster-1 to Cluster-2... then Cluster-2 to Cluster-3. Cluster-3 sends the H245 
address & port info via H225 ALERTING to Cluster-2, which then sends its own to 
Cluster-1. Issue is Cluster-1 never establishes the H245 session with 
Cluster-2. The H245 address and port is received on Cluster-1 but no H245 
processes are being created for the MSD/TCS exchange. According to SDL traces 
on Cluster-2, the latest state of H245 on the node *sending* the ALERTING 
message is "waitForTransportEstablishment". On Cluster-1, the H245Interface 
process is never created according to SDL traces, so we never even reach the 
opportunity for TCS media caps exchange. MXTimeout occurs shortly after.

Question is... For a node receiving an H245 address & port info via H225 (the 
calling cluster...), is creation of the H245Interface and/or related H245 
process dependent on CUCM *first* establishing the new, 2nd TCP socket with the 
remote H.323 endpoint that advertised the H.245 port. In other words, at an SDL 
level, is H245Interface created only after the 2nd TCP session is successfully 
established at the transport level for H245 TCP communication? Knowing this 
would help me assess the likelihood of the issue being related to issues at the 
TCP level.

Thanks!

- Dan
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip



___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] NFAS t1

[Brian Meade]

Is the pri-group already configured on that controller?  If so, you'll need
to shut down the voice-port, the serial interface, and then do "no
pri-group" on the controller before re-defining the pri-group configuration.

On Mon, Dec 1, 2014 at 5:37 PM, Charles Goldsmith 
wrote:

> We are seeing an odd error on a migration from a Nortel setup over to an
> h323 setup.
>
> the error message after entering PRI 2 is
>
> *crsvr1(config-controller)#pri-group timeslots 1-24 nfas_ backup nfas_int
> 1 nfas_group 1*
>
> *%The Primary-group is already defined*
> *%The first definition of the primary-group must be removed before the
> primary-group can be redefined*
>
> Getting this after putting the timeslots command on the first pri, then
> seeing this error on the 2nd controller.
>
> This is on 15.2 on a 3945.  I've done this before with no issues, but have
> never seen this error before.
>
> Thanks
>
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] H245Interface & Related Processes

[Brian Meade]

Also should be fairly easy to capture via a packet capture on Cluster 1 if
this is easily reproducible for the call flow.

Brian

On Mon, Dec 1, 2014 at 5:32 PM, Ryan Ratliff (rratliff) 
wrote:

>  Short answer without confirming in the lab is yes, when I send you my
> H245 address I expect you to start a TCP connection to me on that port so
> we can start H245.
>
>
> -Ryan
>
>  On Dec 1, 2014, at 5:12 PM, Daniel Pagan  wrote:
>
>   Folks:
>
>
>
> Hoping to get some insight on SDL process creation for H245…
>
>
>
> Scenario is three CUCM clusters communicating over ICTs. Call is routed
> from Cluster-1 to Cluster-2… then Cluster-2 to Cluster-3. Cluster-3 sends
> the H245 address & port info via H225 ALERTING to Cluster-2, which then
> sends its own to Cluster-1. Issue is Cluster-1 never establishes the H245
> session with Cluster-2. The H245 address and port is received on Cluster-1
> but no H245 processes are being created for the MSD/TCS exchange. According
> to SDL traces on Cluster-2, the latest state of H245 on the node *
> *sending** the ALERTING message is “waitForTransportEstablishment”. On
> Cluster-1, the H245Interface process is never created according to SDL
> traces, so we never even reach the opportunity for TCS media caps exchange.
> MXTimeout occurs shortly after.
>
>
>
> Question is… For a node receiving an H245 address & port info via H225
> (the calling cluster…), is creation of the H245Interface and/or related
> H245 process dependent on CUCM **first establishing the new, 2nd TCP
> socket with the remote H.323 endpoint that advertised the H.245 port. In
> other words, at an SDL level, is H245Interface created only after the 2nd
> TCP session is successfully established at the transport level for H245 TCP
> communication? Knowing this would help me assess the likelihood of the
> issue being related to issues at the TCP level.
>
>
>
> Thanks!
>
>
>
> - Dan
>  ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] NFAS t1

[Charles Goldsmith]

No, it's not, we cleared the pri-group's on both controllers by shutting
down both voice-port and serial interfaces, removed the pri-group's, then
added in correct config for NFAS.

Going to open a TAC case in a bit on it.

On Mon, Dec 1, 2014 at 3:46 PM, Brian Meade  wrote:

> Is the pri-group already configured on that controller?  If so, you'll
> need to shut down the voice-port, the serial interface, and then do "no
> pri-group" on the controller before re-defining the pri-group configuration.
>
> On Mon, Dec 1, 2014 at 5:37 PM, Charles Goldsmith 
> wrote:
>
>> We are seeing an odd error on a migration from a Nortel setup over to an
>> h323 setup.
>>
>> the error message after entering PRI 2 is
>>
>> *crsvr1(config-controller)#pri-group timeslots 1-24 nfas_ backup nfas_int
>> 1 nfas_group 1*
>>
>> *%The Primary-group is already defined*
>> *%The first definition of the primary-group must be removed before the
>> primary-group can be redefined*
>>
>> Getting this after putting the timeslots command on the first pri, then
>> seeing this error on the 2nd controller.
>>
>> This is on 15.2 on a 3945.  I've done this before with no issues, but
>> have never seen this error before.
>>
>> Thanks
>>
>>
>> ___
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] NFAS t1

[Charles Goldsmith]

We are seeing an odd error on a migration from a Nortel setup over to an
h323 setup.

the error message after entering PRI 2 is

*crsvr1(config-controller)#pri-group timeslots 1-24 nfas_ backup nfas_int 1
nfas_group 1*

*%The Primary-group is already defined*
*%The first definition of the primary-group must be removed before the
primary-group can be redefined*

Getting this after putting the timeslots command on the first pri, then
seeing this error on the 2nd controller.

This is on 15.2 on a 3945.  I've done this before with no issues, but have
never seen this error before.

Thanks
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] H245Interface & Related Processes

[Ryan Ratliff (rratliff)]

Short answer without confirming in the lab is yes, when I send you my H245 
address I expect you to start a TCP connection to me on that port so we can 
start H245.


-Ryan

On Dec 1, 2014, at 5:12 PM, Daniel Pagan 
mailto:dpa...@fidelus.com>> wrote:

Folks:

Hoping to get some insight on SDL process creation for H245…

Scenario is three CUCM clusters communicating over ICTs. Call is routed from 
Cluster-1 to Cluster-2… then Cluster-2 to Cluster-3. Cluster-3 sends the H245 
address & port info via H225 ALERTING to Cluster-2, which then sends its own to 
Cluster-1. Issue is Cluster-1 never establishes the H245 session with 
Cluster-2. The H245 address and port is received on Cluster-1 but no H245 
processes are being created for the MSD/TCS exchange. According to SDL traces 
on Cluster-2, the latest state of H245 on the node *sending* the ALERTING 
message is “waitForTransportEstablishment”. On Cluster-1, the H245Interface 
process is never created according to SDL traces, so we never even reach the 
opportunity for TCS media caps exchange. MXTimeout occurs shortly after.

Question is… For a node receiving an H245 address & port info via H225 (the 
calling cluster…), is creation of the H245Interface and/or related H245 process 
dependent on CUCM *first* establishing the new, 2nd TCP socket with the remote 
H.323 endpoint that advertised the H.245 port. In other words, at an SDL level, 
is H245Interface created only after the 2nd TCP session is successfully 
established at the transport level for H245 TCP communication? Knowing this 
would help me assess the likelihood of the issue being related to issues at the 
TCP level.

Thanks!

- Dan
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] H245Interface & Related Processes

[Daniel Pagan]

Folks:

Hoping to get some insight on SDL process creation for H245...

Scenario is three CUCM clusters communicating over ICTs. Call is routed from 
Cluster-1 to Cluster-2... then Cluster-2 to Cluster-3. Cluster-3 sends the H245 
address & port info via H225 ALERTING to Cluster-2, which then sends its own to 
Cluster-1. Issue is Cluster-1 never establishes the H245 session with 
Cluster-2. The H245 address and port is received on Cluster-1 but no H245 
processes are being created for the MSD/TCS exchange. According to SDL traces 
on Cluster-2, the latest state of H245 on the node *sending* the ALERTING 
message is "waitForTransportEstablishment". On Cluster-1, the H245Interface 
process is never created according to SDL traces, so we never even reach the 
opportunity for TCS media caps exchange. MXTimeout occurs shortly after.

Question is... For a node receiving an H245 address & port info via H225 (the 
calling cluster...), is creation of the H245Interface and/or related H245 
process dependent on CUCM *first* establishing the new, 2nd TCP socket with the 
remote H.323 endpoint that advertised the H.245 port. In other words, at an SDL 
level, is H245Interface created only after the 2nd TCP session is successfully 
established at the transport level for H245 TCP communication? Knowing this 
would help me assess the likelihood of the issue being related to issues at the 
TCP level.

Thanks!

- Dan


___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] UC integration with MS Office and Lync/MOC

[george.hendrix]

Hey Guys,

  We've been running Cisco UC integration version 8.X (CUCILYNC 8.6) for a 
while now and it works great with MS Office Communicator R2 and Office 2010, 
including the click to call add-in.  Our MS folks are looking to migrate 
clients to MS Office 2013, but still use MOC R2.  I can't find any 
product/solution that is compatible with MOC R2 as well as Office 2013 and 
still provide click to call functionality.  Are there any options from Cisco 
that we can use that will allow integration with MS Office Communicator R2 and 
Office 2013 that will provide call control and click to call too?  Also, it 
seems the "new" CUCILYNC version is a totally separate window, instead of an 
add-on section to the bottom, like it is with MOC R2.

Thanks,
Bill
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] Cisco Presence External Database Front End Application

[Ryan Huff]

I have had a few requests from folks for help with a front-end GUI application 
for the external PostgreSQL database that can be used with the Cisco Presence 
and IM server.

Using something like PgAdmin is a great tool to use in an administrative 
function but not very user friendly for the non tech. I have written a PHP 
based application (developed on a LAMP stack). That is a great front-end GUI 
for basic functionality. The application has 2 of the 4 features finished and 
can be a great learning tool or a head start to writing/expanding your own app.

Please download at: http://ryanthomashuff.com/downloads/

Let me know if you have any questions/need assistance getting it set up.

Thanks,

Ryan Huff
ryanthomashuff.com
CCNA R/S, CCNA Wireless, CCNP Voice, UCCX Specialist
  ___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Expressway - 3rd Party Border Recommendation

[Brian Meade]

I've done this before with a large Avaya setup.  We had all of the UC stuff
in a separate VRF and all soft clients had to come through an SBC for
registration.  We demoed Sipera and Acme.  Sipera got the job done cheaper,
but Acme scaled much better for us.  I think CUCM supports Acme SBCs as
well as an alternative to CUBE.

Brian

On Mon, Dec 1, 2014 at 1:23 PM, Pawlowski, Adam  wrote:

> Afternoon all,
>
> Trying to get some opinion on how (if) you would put up a
> perimeter to your UCM clusters to bring in 3rd party clients, softphones,
> etc, that are SIP based and reside outside of your secured LAN? Most of our
> desktops are on public addresses, not behind any particular hardware
> firewall, just software on the host. I'm concerned that the host could be
> compromised, or as seen with some soft clients, they just get harassed by
> driveby SIP/H.323 scans and calls.
>
> I haven't seen any great justification for trying to fence/proxy
> connectivity to the UCM for Jabber, X-Lite, etc, to the cluster, but
> general security practice is saying that if you can make it more secure, it
> is at least worth looking into.
>
> I've looked at trying to set the UBE up for proxy/passthrough
> registrar, and this seems tedious because it doesn't proxy auth and
> requires dial-peer configuration (making dual usage as a gateway
> cumbersome). I have heard "use expressway" a few times but have no idea how
> that would work for 3rd party SIP devices. Other than that, I spent a bit
> of time looking at stuff from Edgewater, OpenSIPS, etc, but it is not clear
> to me if any of these products are worth the trouble, and what the Cisco
> recommended way to go about this is.
>
> Anyone have any experience or thought in this area? Is this a bad
> idea? Anything to say about trying to secure potentially 'untrusted'
> connectivity on a larger scale?
>
> Regards,
>
> Adam Pawlowski
> SUNYAB
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] Expressway - 3rd Party Border Recommendation

[Pawlowski, Adam]

Afternoon all,

Trying to get some opinion on how (if) you would put up a perimeter to 
your UCM clusters to bring in 3rd party clients, softphones, etc, that are SIP 
based and reside outside of your secured LAN? Most of our desktops are on 
public addresses, not behind any particular hardware firewall, just software on 
the host. I'm concerned that the host could be compromised, or as seen with 
some soft clients, they just get harassed by driveby SIP/H.323 scans and calls. 

I haven't seen any great justification for trying to fence/proxy 
connectivity to the UCM for Jabber, X-Lite, etc, to the cluster, but general 
security practice is saying that if you can make it more secure, it is at least 
worth looking into. 

I've looked at trying to set the UBE up for proxy/passthrough 
registrar, and this seems tedious because it doesn't proxy auth and requires 
dial-peer configuration (making dual usage as a gateway cumbersome). I have 
heard "use expressway" a few times but have no idea how that would work for 3rd 
party SIP devices. Other than that, I spent a bit of time looking at stuff from 
Edgewater, OpenSIPS, etc, but it is not clear to me if any of these products 
are worth the trouble, and what the Cisco recommended way to go about this is.

Anyone have any experience or thought in this area? Is this a bad idea? 
Anything to say about trying to secure potentially 'untrusted' connectivity on 
a larger scale?

Regards,

Adam Pawlowski
SUNYAB

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] CUCM 9.1

[Antonis Kouloglou]

Here Sean,

BR
Antonios

On 01-Dec-14 17:29, Sean Knight via cisco-voip wrote:


Hello,  does anyone have a default List.xml file from CUCM 9.1?  I may 
have overwritten mine with some new images that I tried to upload.  I 
contacted TAC about it and they didn’t have a List.xml file that I 
could have.  I stored it in Desktops/640x480x24 and 640x480x24 
folder.  Now when I go to settings and change wall paper it says 
“Unable to obtain additional wallpapers from server.”


*Sean E. Knight*



___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip


















___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] CUCM 9.1

[Sean Knight via cisco-voip]

Hello,  does anyone have a default List.xml file from CUCM 9.1?  I may have 
overwritten mine with some new images that I tried to upload.  I contacted TAC 
about it and they didn't have a List.xml file that I could have.  I stored it 
in Desktops/640x480x24 and 640x480x24 folder.  Now when I go to settings and 
change wall paper it says "Unable to obtain additional wallpapers from server."

Sean E. Knight




___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip