Try IE 11 or Firefox version 24 and above. I've only ever used Firefox; that's what works for me.
> From: [email protected] > Subject: cisco-voip Digest, Vol 134, Issue 2 > To: [email protected] > Date: Tue, 2 Dec 2014 12:00:03 -0500 > > Send cisco-voip mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://puck.nether.net/mailman/listinfo/cisco-voip > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of cisco-voip digest..." > > > Today's Topics: > > 1. Expressway - 3rd Party Border Recommendation (Pawlowski, Adam) > 2. Re: Expressway - 3rd Party Border Recommendation (Brian Meade) > 3. Cisco Presence External Database Front End Application (Ryan Huff) > 4. UC integration with MS Office and Lync/MOC > ([email protected]) > 5. H245Interface & Related Processes (Daniel Pagan) > 6. Re: H245Interface & Related Processes (Ryan Ratliff (rratliff)) > 7. NFAS t1 (Charles Goldsmith) > 8. Re: NFAS t1 (Charles Goldsmith) > 9. Re: H245Interface & Related Processes (Brian Meade) > 10. Re: NFAS t1 (Brian Meade) > 11. Re: H245Interface & Related Processes (Daniel Pagan) > 12. Re: Expressway - 3rd Party Border Recommendation (NateCCIE) > 13. Re: UC integration with MS Office and Lync/MOC (Scott Voll) > 14. Re: H245Interface & Related Processes (Daniel Pagan) > 15. Re: Finisse -10.5 - cfadmin webpage doesnt open > (Jason Aarons (AM)) > 16. Re: Expressway - 3rd Party Border Recommendation (Josh Warcop) > 17. Re: UC integration with MS Office and Lync/MOC (Josh Warcop) > 18. Re: Expressway - 3rd Party Border Recommendation (Walenta, Philip) > 19. Re: Jabber contact disappears consistently (Jason Aarons (AM)) > 20. CUSP High CPU utilization (Brian Palmer) > 21. Re: H245Interface & Related Processes (Wes Sisk (wsisk)) > 22. Jabber 10.5.1 for Windows shows In a Meeting when he isn't > (Jason Aarons (AM)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 1 Dec 2014 18:23:59 +0000 > From: "Pawlowski, Adam" <[email protected]> > To: "[email protected]" <[email protected]> > Subject: [cisco-voip] Expressway - 3rd Party Border Recommendation > Message-ID: > <aeb16c1bf994004e90a436c0cc62287f155fb...@mb-ls3.itorg.ad.buffalo.edu> > Content-Type: text/plain; charset="us-ascii" > > 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 > > > > ------------------------------ > > Message: 2 > Date: Mon, 1 Dec 2014 13:51:18 -0500 > From: Brian Meade <[email protected]> > To: "Pawlowski, Adam" <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [cisco-voip] Expressway - 3rd Party Border Recommendation > Message-ID: > <CAGcuYh1dBMj6ij1hpo9j3NZ4U=5sde1-qcmk8wrtbzddfo4...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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 <[email protected]> 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 > > [email protected] > > https://puck.nether.net/mailman/listinfo/cisco-voip > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://puck.nether.net/pipermail/cisco-voip/attachments/20141201/c4b157f7/attachment-0001.html> > > ------------------------------ > > Message: 3 > Date: Mon, 1 Dec 2014 14:09:47 -0500 > From: Ryan Huff <[email protected]> > To: "[email protected]" <[email protected]> > Subject: [cisco-voip] Cisco Presence External Database Front End > Application > Message-ID: <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > 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 > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://puck.nether.net/pipermail/cisco-voip/attachments/20141201/8507d271/attachment-0001.html> > > ------------------------------ > > Message: 4 > Date: Mon, 1 Dec 2014 20:53:52 +0000 > From: <[email protected]> > To: <[email protected]> > Subject: [cisco-voip] UC integration with MS Office and Lync/MOC > Message-ID: > > <255f57bb43f894468da6bd4f2f5dd1ceb77c2...@rw-s-exch03.net.its.l-3com.com> > > Content-Type: text/plain; charset="us-ascii" > > 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 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://puck.nether.net/pipermail/cisco-voip/attachments/20141201/e6986472/attachment-0001.html> > > ------------------------------ > > Message: 5 > Date: Mon, 1 Dec 2014 22:12:46 +0000 > From: Daniel Pagan <[email protected]> > To: "[email protected]" <[email protected]> > Subject: [cisco-voip] H245Interface & Related Processes > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="windows-1252" > > 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 > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://puck.nether.net/pipermail/cisco-voip/attachments/20141201/340f9a2f/attachment-0001.html> > > ------------------------------ > > Message: 6 > Date: Mon, 1 Dec 2014 22:32:32 +0000 > From: "Ryan Ratliff (rratliff)" <[email protected]> > To: Daniel Pagan <[email protected]> > Cc: cisco-voip voyp list <[email protected]> > Subject: Re: [cisco-voip] H245Interface & Related Processes > Message-ID: <[email protected]> > Content-Type: text/plain; charset="windows-1252" > > 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 > <[email protected]<mailto:[email protected]>> 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 > [email protected]<mailto:[email protected]> > https://puck.nether.net/mailman/listinfo/cisco-voip > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://puck.nether.net/pipermail/cisco-voip/attachments/20141201/36a22c9a/attachment-0001.html> > > ------------------------------ > > Message: 7 > Date: Mon, 1 Dec 2014 15:37:49 -0700 > From: Charles Goldsmith <[email protected]> > To: voip puck <[email protected]> > Subject: [cisco-voip] NFAS t1 > Message-ID: > <cagm7t+budbxtzuftt6q75lzgq7_y8awex0mh-tj1izknw5s...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://puck.nether.net/pipermail/cisco-voip/attachments/20141201/bf4b1b0c/attachment-0001.html> > > ------------------------------ > > Message: 8 > Date: Mon, 1 Dec 2014 15:47:53 -0700 > From: Charles Goldsmith <[email protected]> > To: Brian Meade <[email protected]> > Cc: voip puck <[email protected]> > Subject: Re: [cisco-voip] NFAS t1 > Message-ID: > <cagm7t+b923dro3nmp-di5v8zgqdn0+fd2pwl5a3titxggvg...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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 <[email protected]> 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 <[email protected]> > > 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 > >> [email protected] > >> https://puck.nether.net/mailman/listinfo/cisco-voip > >> > >> > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://puck.nether.net/pipermail/cisco-voip/attachments/20141201/d2a4633f/attachment-0001.html> > > ------------------------------ > > Message: 9 > Date: Mon, 1 Dec 2014 17:50:51 -0500 > From: Brian Meade <[email protected]> > To: "Ryan Ratliff (rratliff)" <[email protected]> > Cc: cisco-voip voyp list <[email protected]> > Subject: Re: [cisco-voip] H245Interface & Related Processes > Message-ID: > <CAGcuYh3mfSeJcYwd7SiX-ESAuOwBF0Cj5iUaAdn+PwDEo4=u...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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) <[email protected]> > 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 <[email protected]> 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 > > [email protected] > > https://puck.nether.net/mailman/listinfo/cisco-voip > > > > > > _______________________________________________ > > cisco-voip mailing list > > [email protected] > > https://puck.nether.net/mailman/listinfo/cisco-voip > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://puck.nether.net/pipermail/cisco-voip/attachments/20141201/b63e1625/attachment-0001.html> > > ------------------------------ > > Message: 10 > Date: Mon, 1 Dec 2014 17:46:15 -0500 > From: Brian Meade <[email protected]> > To: Charles Goldsmith <[email protected]> > Cc: voip puck <[email protected]> > Subject: Re: [cisco-voip] NFAS t1 > Message-ID: > <CAGcuYh2ApRD5KZCbD5hTVN9mjVp6=njyr-1kkodj_5hxmv6...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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 <[email protected]> > 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 > > [email protected] > > https://puck.nether.net/mailman/listinfo/cisco-voip > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://puck.nether.net/pipermail/cisco-voip/attachments/20141201/9a872a2c/attachment-0001.html> > > ------------------------------ > > Message: 11 > Date: Tue, 2 Dec 2014 00:51:38 +0000 > From: Daniel Pagan <[email protected]> > To: "Ryan Ratliff (rratliff)" <[email protected]> > Cc: cisco-voip voyp list <[email protected]> > Subject: Re: [cisco-voip] H245Interface & Related Processes > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="windows-1252" > > 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:[email protected]] > 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 > <[email protected]<mailto:[email protected]>> 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 > [email protected]<mailto:[email protected]> > https://puck.nether.net/mailman/listinfo/cisco-voip > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://puck.nether.net/pipermail/cisco-voip/attachments/20141202/187fa055/attachment-0001.html> > > ------------------------------ > > Message: 12 > Date: Mon, 1 Dec 2014 12:18:27 -0700 > From: NateCCIE <[email protected]> > To: "'Brian Meade'" <[email protected]>, "'Pawlowski, Adam'" > <[email protected]> > Cc: [email protected] > Subject: Re: [cisco-voip] Expressway - 3rd Party Border Recommendation > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > 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:[email protected]] On Behalf Of > Brian Meade > Sent: Monday, December 1, 2014 11:51 AM > To: Pawlowski, Adam > Cc: [email protected] > 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 <[email protected] > <mailto:[email protected]> > 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 > [email protected] <mailto:[email protected]> > https://puck.nether.net/mailman/listinfo/cisco-voip > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://puck.nether.net/pipermail/cisco-voip/attachments/20141201/c477a406/attachment-0001.html> > > ------------------------------ > > Message: 13 > Date: Mon, 1 Dec 2014 15:28:28 -0800 > From: Scott Voll <[email protected]> > To: "[email protected]" <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [cisco-voip] UC integration with MS Office and Lync/MOC > Message-ID: > <cahgd+39j08yh01dzfycrkdw3xyyfuparqcf5ntohyqcztvd...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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, <[email protected]> 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 > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://puck.nether.net/pipermail/cisco-voip/attachments/20141201/cf1412ab/attachment-0001.html> > > ------------------------------ > > Message: 14 > Date: Tue, 2 Dec 2014 01:07:15 +0000 > From: Daniel Pagan <[email protected]> > To: Brian Meade <[email protected]>, "Ryan Ratliff (rratliff)" > <[email protected]> > Cc: cisco-voip voyp list <[email protected]> > Subject: Re: [cisco-voip] H245Interface & Related Processes > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="utf-8" > > 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: [email protected] [mailto:[email protected]] 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) > <[email protected]<mailto:[email protected]>> 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 > <[email protected]<mailto:[email protected]>> 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 > [email protected]<mailto:[email protected]> > https://puck.nether.net/mailman/listinfo/cisco-voip > > > _______________________________________________ > cisco-voip mailing list > [email protected]<mailto:[email protected]> > https://puck.nether.net/mailman/listinfo/cisco-voip > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://puck.nether.net/pipermail/cisco-voip/attachments/20141202/2c663b1d/attachment-0001.html> > > ------------------------------ > > Message: 15 > Date: Tue, 2 Dec 2014 01:35:18 +0000 > From: "Jason Aarons (AM)" <[email protected]> > To: 0703Manjunath <[email protected]>, "cisco-voip > ([email protected])" <[email protected]> > Subject: Re: [cisco-voip] Finisse -10.5 - cfadmin webpage doesnt open > Message-ID: > <2eb6888cfb98614ea7384beb9af8b38216c...@usispsvexdb03.na.didata.local> > Content-Type: text/plain; charset="utf-8" > > 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:[email protected]] On Behalf Of > 0703Manjunath > Sent: Saturday, November 29, 2014 12:43 PM > To: cisco-voip ([email protected]) > 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 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://puck.nether.net/pipermail/cisco-voip/attachments/20141202/1949f1be/attachment-0001.html> > > ------------------------------ > > Message: 16 > Date: Mon, 1 Dec 2014 21:51:38 -0500 > From: Josh Warcop <[email protected]> > To: NateCCIE <[email protected]>, "'Brian Meade'" <[email protected]>, > "'Pawlowski, Adam'" <[email protected]> > Cc: [email protected] > Subject: Re: [cisco-voip] Expressway - 3rd Party Border Recommendation > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > 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<mailto:[email protected]> > Sent: ?12/?1/?2014 7:58 PM > To: 'Brian Meade'<mailto:[email protected]>; 'Pawlowski, > Adam'<mailto:[email protected]> > Cc: [email protected]<mailto:[email protected]> > 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:[email protected]] On Behalf Of > Brian Meade > Sent: Monday, December 1, 2014 11:51 AM > To: Pawlowski, Adam > Cc: [email protected] > 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 <[email protected] > <mailto:[email protected]> > 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 > [email protected] <mailto:[email protected]> > https://puck.nether.net/mailman/listinfo/cisco-voip > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://puck.nether.net/pipermail/cisco-voip/attachments/20141201/f960fe3e/attachment-0001.html> > -------------- next part -------------- > _______________________________________________ > cisco-voip mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-voip > > ------------------------------ > > Message: 17 > Date: Mon, 1 Dec 2014 22:01:28 -0500 > From: Josh Warcop <[email protected]> > To: "[email protected]" <[email protected]>, > <[email protected]> > Subject: Re: [cisco-voip] UC integration with MS Office and Lync/MOC > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > 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: [email protected]<mailto:[email protected]> > Sent: ?12/?1/?2014 3:57 PM > To: [email protected]<mailto:[email protected]> > 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 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://puck.nether.net/pipermail/cisco-voip/attachments/20141201/3659c5f7/attachment-0001.html> > -------------- next part -------------- > _______________________________________________ > cisco-voip mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-voip > > ------------------------------ > > Message: 18 > Date: Mon, 1 Dec 2014 19:29:44 -0800 > From: "Walenta, Philip" <[email protected]> > To: Josh Warcop <[email protected]> > Cc: "[email protected]" <[email protected]>, > "Pawlowski, Adam" <[email protected]> > Subject: Re: [cisco-voip] Expressway - 3rd Party Border Recommendation > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > 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 > <[email protected]<mailto:[email protected]>> 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<mailto:[email protected]> > Sent: ?12/?1/?2014 7:58 PM > To: 'Brian Meade'<mailto:[email protected]>; 'Pawlowski, > Adam'<mailto:[email protected]> > Cc: [email protected]<mailto:[email protected]> > 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:[email protected]] On Behalf Of > Brian Meade > Sent: Monday, December 1, 2014 11:51 AM > To: Pawlowski, Adam > Cc: [email protected]<mailto:[email protected]> > 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 > <[email protected]<mailto:[email protected]>> 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 > [email protected]<mailto:[email protected]> > https://puck.nether.net/mailman/listinfo/cisco-voip > > > > _______________________________________________ > cisco-voip mailing list > [email protected]<mailto:[email protected]> > https://puck.nether.net/mailman/listinfo/cisco-voip > _______________________________________________ > cisco-voip mailing list > [email protected]<mailto:[email protected]> > https://puck.nether.net/mailman/listinfo/cisco-voip > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://puck.nether.net/pipermail/cisco-voip/attachments/20141201/c39f163c/attachment-0001.html> > > ------------------------------ > > Message: 19 > Date: Tue, 2 Dec 2014 13:21:02 +0000 > From: "Jason Aarons (AM)" <[email protected]> > To: Josh Warcop <[email protected]>, Ryan Huff <[email protected]>, > Pavan K <[email protected]>, Leslie Meade <[email protected]> > Cc: "cisco-voip \([email protected]\)" > <[email protected]> > Subject: Re: [cisco-voip] Jabber contact disappears consistently > Message-ID: > <2eb6888cfb98614ea7384beb9af8b38216c...@usispsvexdb03.na.didata.local> > Content-Type: text/plain; charset="utf-8" > > Yes URI Dialing works great and is kind of neat. What we are discussing is a > setting in IMP to select DirectoryURI as the Jabber ID (JID) address scheme > for Presence/Chat. Has nothing to do with URI Dialing. > > CSCuo95266 - Jabber Windows and directory URI address scheme in IMP 10.x -doc > defect > Symptom: > Documentation defect for Jabber for Windows support with directory URI > address scheme which was introduced in IMP 10.x > > Cisco Jabber for Windows - 9.7.1 > IM and Presence - 10.x > > Conditions: > Jabber for Windows 9.7 does not support directory URI address scheme which > was introduced in IM and Presence 10.x. Currently Jabber for windows 10.5 > does not support enhanced directory URI, > 10.6 will support use of a single domain with directoryURI. <<<<THIS HAS NOT > BEEN COMMITTED PER BU > > But Cisco J4W 9.7 installation guide incorrectly states that the feature is > supported. > > http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/Windows/9_7/JABW_BK_C4C679C9_00_cisco-jabber-for-windows-97/JABW_BK_C4C679C9_00_cisco-jabber-for-windows-97_chapter_0111.html#CJAB_TK_P8652662_00 > > > > > From: Ryan Huff<mailto:[email protected]> > Sent: ?Wednesday?, ?November? ?26?, ?2014 ?11?:?59? ?AM > To: Pavan K<mailto:[email protected]>, Leslie > Meade<mailto:[email protected]> > Cc: cisco-voip ([email protected])<mailto:[email protected]> > > I call BS! > > I am running a fully AD integrated 9.1.2 CUCM with IM&Presence 9.1.2 and I > have the Cisco Jabber for Windows 10.5 client deployed and I have URI Dialing > running in the Jabber client, ALL. DAY. LONG and it works flawlessly. > > In the deployment docs, it says to use EnableSIPUriDialing in the > jabber-config.xml HOWEVER; if you look at the PRT logs generated from one of > the 10.5 Jabber clients I bet you it is looking for the EnableSIPURIDialing > node and not the EnableSIPUriDialing node. > > Notice the casing difference in URI Vs. Uri ..... I couldn't get URI in the > client for weeks, got the same junk answer from TAC as well .... then I > troll'ed the PRT logs and found that to be my issue, a flippin' casing issue. > > > ________________________________ > Date: Wed, 26 Nov 2014 09:09:50 -0600 > From: [email protected]<mailto:[email protected]> > To: [email protected]<mailto:[email protected]> > CC: [email protected]<mailto:[email protected]> > Subject: Re: [cisco-voip] Jabber contact disappears consistently > Just to close this out. > > Official word from Cisco even though every piece of Jabber doc says its > supported in J4W 10.5 > == > > Currently Directory URI is only supported on the server. The client has not > yet been updated to fully support this. So no, Jabber 10.5 does NOT support > directory URI > > == > > > On Sat, Nov 22, 2014 at 2:15 PM, Leslie Meade > <[email protected]<mailto:[email protected]>> wrote: > > I also have seen the same issue, and put everyone onto the same server > > > > Leslie Meade > > > > .................................................................. > Mobile:778.228.4339 | Main: 604.676.5239 > Email: [email protected]<mailto:[email protected]> > > > > From: cisco-voip > [mailto:[email protected]<mailto:[email protected]>] > On Behalf Of Jason Aarons (AM) > Sent: Saturday, November 22, 2014 11:33 AM > To: Josh Warcop; Pavan K; > [email protected]<mailto:[email protected]> > Subject: Re: [cisco-voip] Jabber contact disappears consistently > > > > I complete agree, put all Jabberusers on single server. Saw the same bugs in > 10x. > > > > From: cisco-voip [mailto:[email protected]] On Behalf Of > Josh Warcop > Sent: Friday, November 21, 2014 3:48 PM > To: Pavan K; [email protected]<mailto:[email protected]> > Subject: Re: [cisco-voip] Jabber contact disappears consistently > > > > > > Do to the bugs I've seen I have been pinning all users to a single node in > the cluster and just having HA failover. > > > ________________________________ > > Date: Fri, 21 Nov 2014 11:31:39 -0600 > From: [email protected]<mailto:[email protected]> > To: [email protected]<mailto:[email protected]> > Subject: [cisco-voip] Jabber contact disappears consistently > We have an interesting problem on a new jabber deployment that has us > stumped. Wonder if anybody else saw this. > Two jabber servers with ha enabled and balanced users. Using 10.5su1 for > jabber windows and ucm/imp. > Leveraging sip directory uri as the IM scheme due to a multi forest > environment with duplicate Samaccountnames across domains. > UserA contact list has userB on it. Folks can im each other without any > problem. If we move userB from his imp server to another server in the same > subcluster, userB disappears from userA's contact list. > Repeatable across multiple users with different userA and userB and happens > every time regardless of moving them from server1 to server2 or vice versa. > Using router to router communication between nodes and default jabber-config. > > Any ideas ? > Have a TAC case open but its going nowhere. > > _______________________________________________ cisco-voip mailing list > [email protected]<mailto:[email protected]> > https://puck.nether.net/mailman/listinfo/cisco-voip > > > itevomcid > > > > -- > - Pavan > > _______________________________________________ cisco-voip mailing list > [email protected]<mailto:[email protected]> > https://puck.nether.net/mailman/listinfo/cisco-voip > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://puck.nether.net/pipermail/cisco-voip/attachments/20141202/b2fc815c/attachment-0001.html> > > ------------------------------ > > Message: 20 > Date: Tue, 02 Dec 2014 15:01:06 +0000 > From: "Brian Palmer" <[email protected]> > To: [email protected] > Subject: [cisco-voip] CUSP High CPU utilization > Message-ID: <em8c62e2a7-813a-46ab-b2cc-e665336c1c68@praetorian> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Got a customer with a CUSP and both sides seem to be pegging very very > high on the cpu usage. So high I believe it is interfering with call > processing. The vendor that put this new cluster did not follow best > practices in general so there are all kinds of things going on like > criss-crossing of media between the two geographically separated sides. > My real problem is that the CUSP module is much harder to diagnose than > say a regular voice gateway due to a lack of commands to figure out what > is pegging the cpu so bad. Anybody have any good ideas? I can say the > licensing is woefully inadequate and looks to be based on average CPS > and not peak though I don't think that would have an impact on cpu > usage. > > > thanks > > Brian > > -- > *The information contained in this electronic transmission and any > attachments hereto may be considered proprietary and confidential. > Unauthorized distribution of this material to anyone other than the > addressed is prohibited. Any disclosure, distribution or use of this > transmission for any reason other than their intended purpose is > prohibited.* > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://puck.nether.net/pipermail/cisco-voip/attachments/20141202/a975fd1a/attachment-0001.html> > > ------------------------------ > > Message: 21 > Date: Tue, 2 Dec 2014 16:29:04 +0000 > From: "Wes Sisk (wsisk)" <[email protected]> > To: Daniel Pagan <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [cisco-voip] H245Interface & Related Processes > Message-ID: <[email protected]> > Content-Type: text/plain; charset="windows-1252" > > Hmm, > > These should help: > CSCsm26337 need clear messages for h225 tcp session failure > > In versions with fix h225 session setup is clearly indicated in cm sdi traces > with one of these messages: > H225Cdpc(%07d)::requestConnect_TcpStartSessionErr: H225 Tcp Start Session > request failed > > H225 Call is aborted as no response received for H225 Tcp Start Session > Request > within configured H225TcpTimer value > > h225 session abort due to RST or FIN is clearly indicated in cm sdi traces > with: > H225 Tcp session terminated abnormally > > > With fix for this defect TCP session aborts will be reported by one of the > following statements in CallManager SDI trace: > requestConnect_TcpStartSessionErr: H225 Tcp Start Session request failed > requestConnect_H225TcpTimer: H225 Call is aborted as no response received for > H225 Tcp Start Session Request within configured H225TcpTimer value > call_initiated1_TcpStopSessionInd: H225 Tcp session terminated abnormally > overlap_sending2_TcpStopSessionInd: H225 Tcp session terminated abnormally > outgoing_call_proceeding3_TcpStopSessionInd: H225 Tcp session terminated > abnormally > call_delivered4_TcpStopSessionInd: H225 Tcp session terminated abnormally > call_present6_TcpStopSessionInd: H225 Tcp session terminated abnormally > incoming_call_proceeding9_TcpStopSessionInd: H225 Tcp session terminated > abnormally > active10_TcpStopSessionInd: H225 Tcp session terminated abnormally > await_ann_complete_TcpStopSessionInd: H225 Tcp session terminated abnormally > active10a_TcpStopSessionInd: H225 Tcp session terminated abnormally > active10b_TcpStopSessionInd: H225 Tcp session terminated abnormally > GKRasARQH225Setup_TcpStopSessionInd: H225 Tcp session terminated abnormally > GKRasCcSetupRequestConnect_TcpStartSessionErr(%d, %d): TcpStartSessionErr > from IP=%s > GKRasCcSetupRequestConnect_TcpStartSessionErr: H225 Tcp Start Session request > failed > GKRasCcSetupRequestConnect_H225TcpTimer: H225 Call is aborted as no response > received for H225 Tcp Start Session Request within configured H225TcpTimer > value > overlap_receiving25_TcpStopSessionInd: H225 Tcp session terminated abnormally > wait_for_disconn_kluge_TcpStopSessionInd: H225 Tcp session terminated > abnormally > paused_TcpStopSessionInd: H225 Tcp session terminated abnormally > > > > CSCsm26355 need clear messages for h245 tcp session failure > h.245 tcp session setup failure: > TCP ERROR: H245ListenReq or H245ConnectReq failure, or received SdlCloseInd > from H245Handler, Perform cleanup of H245 Session > > established h.245 session experiences TCP keepalive timeout: > TranslateAndTransport(%d)::wait_SdlCloseInd - ERROR: H245 signaling connection > aborted > > established h.245 session receives unexpected TCP FIN or RST: > TranslateAndTransport(%d)::wait_SdlCloseInd - ERROR: H245 signaling connection > aborted > > > > > Otherwise, consider enabling additional SDL trace flags like ?enable network > *? and ?enable SDL TCP event trace?. However, these will cause significant > additional trace lines (one or more SDL signal per TCP segment received). > > > I believe one of the additional traces above will get you insight to socket > requests down to the network layer in UCM. > > -Wes > > > > On Dec 1, 2014, at 5:12 PM, Daniel Pagan > <[email protected]<mailto:[email protected]>> 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 > [email protected]<mailto:[email protected]> > https://puck.nether.net/mailman/listinfo/cisco-voip > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://puck.nether.net/pipermail/cisco-voip/attachments/20141202/d3dc1152/attachment-0001.html> > > ------------------------------ > > Message: 22 > Date: Tue, 2 Dec 2014 16:31:49 +0000 > From: "Jason Aarons (AM)" <[email protected]> > To: "cisco-voip ([email protected])" > <[email protected]> > Subject: [cisco-voip] Jabber 10.5.1 for Windows shows In a Meeting > when he isn't > Message-ID: > <2eb6888cfb98614ea7384beb9af8b382176...@usispsvexdb03.na.didata.local> > Content-Type: text/plain; charset="windows-1252" > > We have a user who's Jabber for Windows 10.5.1 client shows "In a Meeting" > when his calendar is clear. I looked in outlook if he has multiple calendars > which he did not, when he logs into Jabber his status shows as "available" > for around 15 seconds before changing to "In a meeting". If I clear the local > Jabber CSF folders it still displays the same behavior. > > IMP 10.5.1 > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://puck.nether.net/pipermail/cisco-voip/attachments/20141202/4357a4b1/attachment-0001.html> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > cisco-voip mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-voip > > > ------------------------------ > > End of cisco-voip Digest, Vol 134, Issue 2 > ******************************************
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
