<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Try IE 11 or Firefox version 24 and above. I've only ever used Firefox; that's what works for me.<br><br><div>> From: cisco-voip-request@puck.nether.net<br>> Subject: cisco-voip Digest, Vol 134, Issue 2<br>> To: cisco-voip@puck.nether.net<br>> Date: Tue, 2 Dec 2014 12:00:03 -0500<br>> <br>> Send cisco-voip mailing list submissions to<br>> cisco-voip@puck.nether.net<br>> <br>> To subscribe or unsubscribe via the World Wide Web, visit<br>> https://puck.nether.net/mailman/listinfo/cisco-voip<br>> or, via email, send a message with subject or body 'help' to<br>> cisco-voip-request@puck.nether.net<br>> <br>> You can reach the person managing the list at<br>> cisco-voip-owner@puck.nether.net<br>> <br>> When replying, please edit your Subject line so it is more specific<br>> than "Re: Contents of cisco-voip digest..."<br>> <br>> <br>> Today's Topics:<br>> <br>> 1. Expressway - 3rd Party Border Recommendation (Pawlowski, Adam)<br>> 2. Re: Expressway - 3rd Party Border Recommendation (Brian Meade)<br>> 3. Cisco Presence External Database Front End Application (Ryan Huff)<br>> 4. UC integration with MS Office and Lync/MOC<br>> (george.hendrix@l-3com.com)<br>> 5. H245Interface & Related Processes (Daniel Pagan)<br>> 6. Re: H245Interface & Related Processes (Ryan Ratliff (rratliff))<br>> 7. NFAS t1 (Charles Goldsmith)<br>> 8. Re: NFAS t1 (Charles Goldsmith)<br>> 9. Re: H245Interface & Related Processes (Brian Meade)<br>> 10. Re: NFAS t1 (Brian Meade)<br>> 11. Re: H245Interface & Related Processes (Daniel Pagan)<br>> 12. Re: Expressway - 3rd Party Border Recommendation (NateCCIE)<br>> 13. Re: UC integration with MS Office and Lync/MOC (Scott Voll)<br>> 14. Re: H245Interface & Related Processes (Daniel Pagan)<br>> 15. Re: Finisse -10.5 - cfadmin webpage doesnt open<br>> (Jason Aarons (AM))<br>> 16. Re: Expressway - 3rd Party Border Recommendation (Josh Warcop)<br>> 17. Re: UC integration with MS Office and Lync/MOC (Josh Warcop)<br>> 18. Re: Expressway - 3rd Party Border Recommendation (Walenta, Philip)<br>> 19. Re: Jabber contact disappears consistently (Jason Aarons (AM))<br>> 20. CUSP High CPU utilization (Brian Palmer)<br>> 21. Re: H245Interface & Related Processes (Wes Sisk (wsisk))<br>> 22. Jabber 10.5.1 for Windows shows In a Meeting when he isn't<br>> (Jason Aarons (AM))<br>> <br>> <br>> ----------------------------------------------------------------------<br>> <br>> Message: 1<br>> Date: Mon, 1 Dec 2014 18:23:59 +0000<br>> From: "Pawlowski, Adam" <ajp26@buffalo.edu><br>> To: "cisco-voip@puck.nether.net" <cisco-voip@puck.nether.net><br>> Subject: [cisco-voip] Expressway - 3rd Party Border Recommendation<br>> Message-ID:<br>> <AEB16C1BF994004E90A436C0CC62287F155FBA5F@mb-ls3.itorg.ad.buffalo.edu><br>> Content-Type: text/plain; charset="us-ascii"<br>> <br>> Afternoon all,<br>> <br>> 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. <br>> <br>> 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. <br>> <br>> 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.<br>> <br>> 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?<br>> <br>> Regards,<br>> <br>> Adam Pawlowski<br>> SUNYAB<br>> <br>> <br>> <br>> ------------------------------<br>> <br>> Message: 2<br>> Date: Mon, 1 Dec 2014 13:51:18 -0500<br>> From: Brian Meade <bmeade90@vt.edu><br>> To: "Pawlowski, Adam" <ajp26@buffalo.edu><br>> Cc: "cisco-voip@puck.nether.net" <cisco-voip@puck.nether.net><br>> Subject: Re: [cisco-voip] Expressway - 3rd Party Border Recommendation<br>> Message-ID:<br>> <CAGcuYh1dBMj6ij1hpo9j3NZ4U=5SdE1-QCMk8wRtBZDDfo49Uw@mail.gmail.com><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> I've done this before with a large Avaya setup. We had all of the UC stuff<br>> in a separate VRF and all soft clients had to come through an SBC for<br>> registration. We demoed Sipera and Acme. Sipera got the job done cheaper,<br>> but Acme scaled much better for us. I think CUCM supports Acme SBCs as<br>> well as an alternative to CUBE.<br>> <br>> Brian<br>> <br>> On Mon, Dec 1, 2014 at 1:23 PM, Pawlowski, Adam <ajp26@buffalo.edu> wrote:<br>> <br>> > Afternoon all,<br>> ><br>> > Trying to get some opinion on how (if) you would put up a<br>> > perimeter to your UCM clusters to bring in 3rd party clients, softphones,<br>> > etc, that are SIP based and reside outside of your secured LAN? Most of our<br>> > desktops are on public addresses, not behind any particular hardware<br>> > firewall, just software on the host. I'm concerned that the host could be<br>> > compromised, or as seen with some soft clients, they just get harassed by<br>> > driveby SIP/H.323 scans and calls.<br>> ><br>> > I haven't seen any great justification for trying to fence/proxy<br>> > connectivity to the UCM for Jabber, X-Lite, etc, to the cluster, but<br>> > general security practice is saying that if you can make it more secure, it<br>> > is at least worth looking into.<br>> ><br>> > I've looked at trying to set the UBE up for proxy/passthrough<br>> > registrar, and this seems tedious because it doesn't proxy auth and<br>> > requires dial-peer configuration (making dual usage as a gateway<br>> > cumbersome). I have heard "use expressway" a few times but have no idea how<br>> > that would work for 3rd party SIP devices. Other than that, I spent a bit<br>> > of time looking at stuff from Edgewater, OpenSIPS, etc, but it is not clear<br>> > to me if any of these products are worth the trouble, and what the Cisco<br>> > recommended way to go about this is.<br>> ><br>> > Anyone have any experience or thought in this area? Is this a bad<br>> > idea? Anything to say about trying to secure potentially 'untrusted'<br>> > connectivity on a larger scale?<br>> ><br>> > Regards,<br>> ><br>> > Adam Pawlowski<br>> > SUNYAB<br>> ><br>> > _______________________________________________<br>> > cisco-voip mailing list<br>> > cisco-voip@puck.nether.net<br>> > https://puck.nether.net/mailman/listinfo/cisco-voip<br>> ><br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20141201/c4b157f7/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 3<br>> Date: Mon, 1 Dec 2014 14:09:47 -0500<br>> From: Ryan Huff <ryanhuff@outlook.com><br>> To: "cisco-voip@puck.nether.net" <cisco-voip@puck.nether.net><br>> Subject: [cisco-voip] Cisco Presence External Database Front End<br>> Application<br>> Message-ID: <COL130-W61E1DE4F7EBAC742DC87CFC57D0@phx.gbl><br>> Content-Type: text/plain; charset="iso-8859-1"<br>> <br>> 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.<br>> <br>> 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.<br>> <br>> Please download at: http://ryanthomashuff.com/downloads/<br>> <br>> Let me know if you have any questions/need assistance getting it set up.<br>> <br>> Thanks,<br>> <br>> Ryan Huff<br>> ryanthomashuff.com<br>> CCNA R/S, CCNA Wireless, CCNP Voice, UCCX Specialist<br>> <br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20141201/8507d271/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 4<br>> Date: Mon, 1 Dec 2014 20:53:52 +0000<br>> From: <george.hendrix@l-3com.com><br>> To: <cisco-voip@puck.nether.net><br>> Subject: [cisco-voip] UC integration with MS Office and Lync/MOC<br>> Message-ID:<br>> <255F57BB43F894468DA6BD4F2F5DD1CEB77C2A3F@rw-s-exch03.net.its.l-3com.com><br>> <br>> Content-Type: text/plain; charset="us-ascii"<br>> <br>> Hey Guys,<br>> <br>> 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.<br>> <br>> Thanks,<br>> Bill<br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20141201/e6986472/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 5<br>> Date: Mon, 1 Dec 2014 22:12:46 +0000<br>> From: Daniel Pagan <dpagan@fidelus.com><br>> To: "cisco-voip@puck.nether.net" <cisco-voip@puck.nether.net><br>> Subject: [cisco-voip] H245Interface & Related Processes<br>> Message-ID:<br>> <a557b4ae8504494194455334cc1123c0@NYC-EX2K13-MB.fidelus.com><br>> Content-Type: text/plain; charset="windows-1252"<br>> <br>> Folks:<br>> <br>> Hoping to get some insight on SDL process creation for H245...<br>> <br>> 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.<br>> <br>> 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.<br>> <br>> Thanks!<br>> <br>> - Dan<br>> <br>> <br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20141201/340f9a2f/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 6<br>> Date: Mon, 1 Dec 2014 22:32:32 +0000<br>> From: "Ryan Ratliff (rratliff)" <rratliff@cisco.com><br>> To: Daniel Pagan <dpagan@fidelus.com><br>> Cc: cisco-voip voyp list <cisco-voip@puck.nether.net><br>> Subject: Re: [cisco-voip] H245Interface & Related Processes<br>> Message-ID: <DBD386D6-250E-4B1B-B144-79F515C22BAA@cisco.com><br>> Content-Type: text/plain; charset="windows-1252"<br>> <br>> 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.<br>> <br>> <br>> -Ryan<br>> <br>> On Dec 1, 2014, at 5:12 PM, Daniel Pagan <dpagan@fidelus.com<mailto:dpagan@fidelus.com>> wrote:<br>> <br>> Folks:<br>> <br>> Hoping to get some insight on SDL process creation for H245?<br>> <br>> 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.<br>> <br>> 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.<br>> <br>> Thanks!<br>> <br>> - Dan<br>> _______________________________________________<br>> cisco-voip mailing list<br>> cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net><br>> https://puck.nether.net/mailman/listinfo/cisco-voip<br>> <br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20141201/36a22c9a/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 7<br>> Date: Mon, 1 Dec 2014 15:37:49 -0700<br>> From: Charles Goldsmith <wokka@justfamily.org><br>> To: voip puck <cisco-voip@puck.nether.net><br>> Subject: [cisco-voip] NFAS t1<br>> Message-ID:<br>> <CAGm7T+BUdbxtzuFtT6Q75LzGq7_y8AWex0mh-tJ1izKnW5Ss5g@mail.gmail.com><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> We are seeing an odd error on a migration from a Nortel setup over to an<br>> h323 setup.<br>> <br>> the error message after entering PRI 2 is<br>> <br>> *crsvr1(config-controller)#pri-group timeslots 1-24 nfas_ backup nfas_int 1<br>> nfas_group 1*<br>> <br>> *%The Primary-group is already defined*<br>> *%The first definition of the primary-group must be removed before the<br>> primary-group can be redefined*<br>> <br>> Getting this after putting the timeslots command on the first pri, then<br>> seeing this error on the 2nd controller.<br>> <br>> This is on 15.2 on a 3945. I've done this before with no issues, but have<br>> never seen this error before.<br>> <br>> Thanks<br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20141201/bf4b1b0c/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 8<br>> Date: Mon, 1 Dec 2014 15:47:53 -0700<br>> From: Charles Goldsmith <wokka@justfamily.org><br>> To: Brian Meade <bmeade90@vt.edu><br>> Cc: voip puck <cisco-voip@puck.nether.net><br>> Subject: Re: [cisco-voip] NFAS t1<br>> Message-ID:<br>> <CAGm7T+B923DRo3NMp-di5V8zgQDn0+fd2PWL5A3TiTxggvGLJQ@mail.gmail.com><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> No, it's not, we cleared the pri-group's on both controllers by shutting<br>> down both voice-port and serial interfaces, removed the pri-group's, then<br>> added in correct config for NFAS.<br>> <br>> Going to open a TAC case in a bit on it.<br>> <br>> On Mon, Dec 1, 2014 at 3:46 PM, Brian Meade <bmeade90@vt.edu> wrote:<br>> <br>> > Is the pri-group already configured on that controller? If so, you'll<br>> > need to shut down the voice-port, the serial interface, and then do "no<br>> > pri-group" on the controller before re-defining the pri-group configuration.<br>> ><br>> > On Mon, Dec 1, 2014 at 5:37 PM, Charles Goldsmith <wokka@justfamily.org><br>> > wrote:<br>> ><br>> >> We are seeing an odd error on a migration from a Nortel setup over to an<br>> >> h323 setup.<br>> >><br>> >> the error message after entering PRI 2 is<br>> >><br>> >> *crsvr1(config-controller)#pri-group timeslots 1-24 nfas_ backup nfas_int<br>> >> 1 nfas_group 1*<br>> >><br>> >> *%The Primary-group is already defined*<br>> >> *%The first definition of the primary-group must be removed before the<br>> >> primary-group can be redefined*<br>> >><br>> >> Getting this after putting the timeslots command on the first pri, then<br>> >> seeing this error on the 2nd controller.<br>> >><br>> >> This is on 15.2 on a 3945. I've done this before with no issues, but<br>> >> have never seen this error before.<br>> >><br>> >> Thanks<br>> >><br>> >><br>> >> _______________________________________________<br>> >> cisco-voip mailing list<br>> >> cisco-voip@puck.nether.net<br>> >> https://puck.nether.net/mailman/listinfo/cisco-voip<br>> >><br>> >><br>> ><br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20141201/d2a4633f/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 9<br>> Date: Mon, 1 Dec 2014 17:50:51 -0500<br>> From: Brian Meade <bmeade90@vt.edu><br>> To: "Ryan Ratliff (rratliff)" <rratliff@cisco.com><br>> Cc: cisco-voip voyp list <cisco-voip@puck.nether.net><br>> Subject: Re: [cisco-voip] H245Interface & Related Processes<br>> Message-ID:<br>> <CAGcuYh3mfSeJcYwd7SiX-ESAuOwBF0Cj5iUaAdn+PwDEo4=umQ@mail.gmail.com><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> Also should be fairly easy to capture via a packet capture on Cluster 1 if<br>> this is easily reproducible for the call flow.<br>> <br>> Brian<br>> <br>> On Mon, Dec 1, 2014 at 5:32 PM, Ryan Ratliff (rratliff) <rratliff@cisco.com><br>> wrote:<br>> <br>> > Short answer without confirming in the lab is yes, when I send you my<br>> > H245 address I expect you to start a TCP connection to me on that port so<br>> > we can start H245.<br>> ><br>> ><br>> > -Ryan<br>> ><br>> > On Dec 1, 2014, at 5:12 PM, Daniel Pagan <dpagan@fidelus.com> wrote:<br>> ><br>> > Folks:<br>> ><br>> ><br>> ><br>> > Hoping to get some insight on SDL process creation for H245?<br>> ><br>> ><br>> ><br>> > Scenario is three CUCM clusters communicating over ICTs. Call is routed<br>> > from Cluster-1 to Cluster-2? then Cluster-2 to Cluster-3. Cluster-3 sends<br>> > the H245 address & port info via H225 ALERTING to Cluster-2, which then<br>> > sends its own to Cluster-1. Issue is Cluster-1 never establishes the H245<br>> > session with Cluster-2. The H245 address and port is received on Cluster-1<br>> > but no H245 processes are being created for the MSD/TCS exchange. According<br>> > to SDL traces on Cluster-2, the latest state of H245 on the node *<br>> > *sending** the ALERTING message is ?waitForTransportEstablishment?. On<br>> > Cluster-1, the H245Interface process is never created according to SDL<br>> > traces, so we never even reach the opportunity for TCS media caps exchange.<br>> > MXTimeout occurs shortly after.<br>> ><br>> ><br>> ><br>> > Question is? For a node receiving an H245 address & port info via H225<br>> > (the calling cluster?), is creation of the H245Interface and/or related<br>> > H245 process dependent on CUCM **first**** establishing the new, 2nd TCP<br>> > socket with the remote H.323 endpoint that advertised the H.245 port. In<br>> > other words, at an SDL level, is H245Interface created only after the 2nd<br>> > TCP session is successfully established at the transport level for H245 TCP<br>> > communication? Knowing this would help me assess the likelihood of the<br>> > issue being related to issues at the TCP level.<br>> ><br>> ><br>> ><br>> > Thanks!<br>> ><br>> ><br>> ><br>> > - Dan<br>> > _______________________________________________<br>> > cisco-voip mailing list<br>> > cisco-voip@puck.nether.net<br>> > https://puck.nether.net/mailman/listinfo/cisco-voip<br>> ><br>> ><br>> > _______________________________________________<br>> > cisco-voip mailing list<br>> > cisco-voip@puck.nether.net<br>> > https://puck.nether.net/mailman/listinfo/cisco-voip<br>> ><br>> ><br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20141201/b63e1625/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 10<br>> Date: Mon, 1 Dec 2014 17:46:15 -0500<br>> From: Brian Meade <bmeade90@vt.edu><br>> To: Charles Goldsmith <wokka@justfamily.org><br>> Cc: voip puck <cisco-voip@puck.nether.net><br>> Subject: Re: [cisco-voip] NFAS t1<br>> Message-ID:<br>> <CAGcuYh2ApRD5KZCbD5hTVN9mjVp6=NJYr-1kkodJ_5hxmv69Nw@mail.gmail.com><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> Is the pri-group already configured on that controller? If so, you'll need<br>> to shut down the voice-port, the serial interface, and then do "no<br>> pri-group" on the controller before re-defining the pri-group configuration.<br>> <br>> On Mon, Dec 1, 2014 at 5:37 PM, Charles Goldsmith <wokka@justfamily.org><br>> wrote:<br>> <br>> > We are seeing an odd error on a migration from a Nortel setup over to an<br>> > h323 setup.<br>> ><br>> > the error message after entering PRI 2 is<br>> ><br>> > *crsvr1(config-controller)#pri-group timeslots 1-24 nfas_ backup nfas_int<br>> > 1 nfas_group 1*<br>> ><br>> > *%The Primary-group is already defined*<br>> > *%The first definition of the primary-group must be removed before the<br>> > primary-group can be redefined*<br>> ><br>> > Getting this after putting the timeslots command on the first pri, then<br>> > seeing this error on the 2nd controller.<br>> ><br>> > This is on 15.2 on a 3945. I've done this before with no issues, but have<br>> > never seen this error before.<br>> ><br>> > Thanks<br>> ><br>> ><br>> > _______________________________________________<br>> > cisco-voip mailing list<br>> > cisco-voip@puck.nether.net<br>> > https://puck.nether.net/mailman/listinfo/cisco-voip<br>> ><br>> ><br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20141201/9a872a2c/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 11<br>> Date: Tue, 2 Dec 2014 00:51:38 +0000<br>> From: Daniel Pagan <dpagan@fidelus.com><br>> To: "Ryan Ratliff (rratliff)" <rratliff@cisco.com><br>> Cc: cisco-voip voyp list <cisco-voip@puck.nether.net><br>> Subject: Re: [cisco-voip] H245Interface & Related Processes<br>> Message-ID:<br>> <dc2c5570502b47b681dc966d25824f84@NYC-EX2K13-MB.fidelus.com><br>> Content-Type: text/plain; charset="windows-1252"<br>> <br>> 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.<br>> <br>> - Dan<br>> <br>> From: Ryan Ratliff (rratliff) [mailto:rratliff@cisco.com]<br>> Sent: Monday, December 01, 2014 5:33 PM<br>> To: Daniel Pagan<br>> Cc: cisco-voip voyp list<br>> Subject: Re: [cisco-voip] H245Interface & Related Processes<br>> <br>> 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.<br>> <br>> <br>> -Ryan<br>> <br>> On Dec 1, 2014, at 5:12 PM, Daniel Pagan <dpagan@fidelus.com<mailto:dpagan@fidelus.com>> wrote:<br>> <br>> Folks:<br>> <br>> Hoping to get some insight on SDL process creation for H245...<br>> <br>> 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.<br>> <br>> 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.<br>> <br>> Thanks!<br>> <br>> - Dan<br>> _______________________________________________<br>> cisco-voip mailing list<br>> cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net><br>> https://puck.nether.net/mailman/listinfo/cisco-voip<br>> <br>> <br>> <br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20141202/187fa055/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 12<br>> Date: Mon, 1 Dec 2014 12:18:27 -0700<br>> From: NateCCIE <nateccie@gmail.com><br>> To: "'Brian Meade'" <bmeade90@vt.edu>, "'Pawlowski, Adam'"<br>> <ajp26@buffalo.edu><br>> Cc: cisco-voip@puck.nether.net<br>> Subject: Re: [cisco-voip] Expressway - 3rd Party Border Recommendation<br>> Message-ID: <089b01d00d9b$96716450$c3542cf0$@gmail.com><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> Expressway is the first thought, then CUBE Lineside proxy would be where to go for 3rd party.<br>> <br>> <br>> <br>> https://ciscocollab.wordpress.com/2014/04/08/cube-sip-lineside-phone-vpn-configuration/<br>> <br>> <br>> <br>> <br>> <br>> From: cisco-voip [mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Brian Meade<br>> Sent: Monday, December 1, 2014 11:51 AM<br>> To: Pawlowski, Adam<br>> Cc: cisco-voip@puck.nether.net<br>> Subject: Re: [cisco-voip] Expressway - 3rd Party Border Recommendation<br>> <br>> <br>> <br>> 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.<br>> <br>> <br>> <br>> Brian<br>> <br>> <br>> <br>> On Mon, Dec 1, 2014 at 1:23 PM, Pawlowski, Adam <ajp26@buffalo.edu <mailto:ajp26@buffalo.edu> > wrote:<br>> <br>> Afternoon all,<br>> <br>> 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.<br>> <br>> 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.<br>> <br>> 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.<br>> <br>> 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?<br>> <br>> Regards,<br>> <br>> Adam Pawlowski<br>> SUNYAB<br>> <br>> _______________________________________________<br>> cisco-voip mailing list<br>> cisco-voip@puck.nether.net <mailto:cisco-voip@puck.nether.net> <br>> https://puck.nether.net/mailman/listinfo/cisco-voip<br>> <br>> <br>> <br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20141201/c477a406/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 13<br>> Date: Mon, 1 Dec 2014 15:28:28 -0800<br>> From: Scott Voll <svoll.voip@gmail.com><br>> To: "george.hendrix@l-3com.com" <george.hendrix@l-3com.com><br>> Cc: "cisco-voip@puck.nether.net" <cisco-voip@puck.nether.net><br>> Subject: Re: [cisco-voip] UC integration with MS Office and Lync/MOC<br>> Message-ID:<br>> <CAHgd+39J08yh01dzfycrKDw3xyyFupaRQCF5ntoHyQcZtVddYA@mail.gmail.com><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> Correct. The new cicilync is more like jabber. If you go to the o365 cloud<br>> it pretty much breaks everything. Good luck<br>> <br>> Scott<br>> <br>> On Monday, December 1, 2014, <george.hendrix@l-3com.com> wrote:<br>> <br>> > Hey Guys,<br>> ><br>> ><br>> ><br>> > We?ve been running Cisco UC integration version 8.X (CUCILYNC 8.6) for a<br>> > while now and it works great with MS Office Communicator R2 and Office<br>> > 2010, including the click to call add-in. Our MS folks are looking to<br>> > migrate clients to MS Office 2013, but still use MOC R2. I can?t find any<br>> > product/solution that is compatible with MOC R2 as well as Office 2013 and<br>> > still provide click to call functionality. Are there any options from<br>> > Cisco that we can use that will allow integration with MS Office<br>> > Communicator R2 and Office 2013 that will provide call control and click to<br>> > call too? Also, it seems the ?new? CUCILYNC version is a totally separate<br>> > window, instead of an add-on section to the bottom, like it is with MOC R2.<br>> ><br>> ><br>> ><br>> > Thanks,<br>> ><br>> > Bill<br>> ><br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20141201/cf1412ab/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 14<br>> Date: Tue, 2 Dec 2014 01:07:15 +0000<br>> From: Daniel Pagan <dpagan@fidelus.com><br>> To: Brian Meade <bmeade90@vt.edu>, "Ryan Ratliff (rratliff)"<br>> <rratliff@cisco.com><br>> Cc: cisco-voip voyp list <cisco-voip@puck.nether.net><br>> Subject: Re: [cisco-voip] H245Interface & Related Processes<br>> Message-ID:<br>> <dc51ff672eb04f1485a6ac5804dc327d@NYC-EX2K13-MB.fidelus.com><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> Hey Brian ? hope you?re doing well. This is a difficult issue to reproduce so a pcap would be tricky to obtain.<br>> <br>> I?ll try and recreate the issue in a lab and see what results I get from an SDL process creation standpoint.<br>> <br>> Thanks!<br>> <br>> - Dan<br>> <br>> <br>> From: bmeade90@gmail.com [mailto:bmeade90@gmail.com] On Behalf Of Brian Meade<br>> Sent: Monday, December 01, 2014 5:51 PM<br>> To: Ryan Ratliff (rratliff)<br>> Cc: Daniel Pagan; cisco-voip voyp list<br>> Subject: Re: [cisco-voip] H245Interface & Related Processes<br>> <br>> Also should be fairly easy to capture via a packet capture on Cluster 1 if this is easily reproducible for the call flow.<br>> <br>> Brian<br>> <br>> On Mon, Dec 1, 2014 at 5:32 PM, Ryan Ratliff (rratliff) <rratliff@cisco.com<mailto:rratliff@cisco.com>> wrote:<br>> 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.<br>> <br>> <br>> -Ryan<br>> <br>> On Dec 1, 2014, at 5:12 PM, Daniel Pagan <dpagan@fidelus.com<mailto:dpagan@fidelus.com>> wrote:<br>> <br>> Folks:<br>> <br>> Hoping to get some insight on SDL process creation for H245?<br>> <br>> 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.<br>> <br>> 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.<br>> <br>> Thanks!<br>> <br>> - Dan<br>> _______________________________________________<br>> cisco-voip mailing list<br>> cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net><br>> https://puck.nether.net/mailman/listinfo/cisco-voip<br>> <br>> <br>> _______________________________________________<br>> cisco-voip mailing list<br>> cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net><br>> https://puck.nether.net/mailman/listinfo/cisco-voip<br>> <br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20141202/2c663b1d/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 15<br>> Date: Tue, 2 Dec 2014 01:35:18 +0000<br>> From: "Jason Aarons (AM)" <jason.aarons@dimensiondata.com><br>> To: 0703Manjunath <winmanjunath@gmail.com>, "cisco-voip<br>> (cisco-voip@puck.nether.net)" <cisco-voip@puck.nether.net><br>> Subject: Re: [cisco-voip] Finisse -10.5 - cfadmin webpage doesnt open<br>> Message-ID:<br>> <2EB6888CFB98614EA7384BEB9AF8B38216C026@usispsvexdb03.na.didata.local><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> What OS/Browser versions? If IE have you tried Compatibility mode?<br>> <br>> http://docwiki.cisco.com/wiki/Unified_CCE_Software_Compatibility_Matrix_for_10.5%28x%29#Unified_CCE_Release_10.5..281.29_Supported_Browsers<br>> <br>> <br>> From: cisco-voip [mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of 0703Manjunath<br>> Sent: Saturday, November 29, 2014 12:43 PM<br>> To: cisco-voip (cisco-voip@puck.nether.net)<br>> Subject: [cisco-voip] Finisse -10.5 - cfadmin webpage doesnt open<br>> <br>> <br>> hello,<br>> <br>> <br>> Iam stuck with a issue on finesse cfadmin webpage doesnt open.<br>> <br>> we are using UCCE 10.5 , agent webpage opens but admin page doesnt.<br>> <br>> Does anyone have any clue about this issue????<br>> <br>> --<br>> Cheers<br>> Manjunath<br>> <br>> <br>> itevomcid<br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20141202/1949f1be/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 16<br>> Date: Mon, 1 Dec 2014 21:51:38 -0500<br>> From: Josh Warcop <josh@warcop.com><br>> To: NateCCIE <nateccie@gmail.com>, "'Brian Meade'" <bmeade90@vt.edu>,<br>> "'Pawlowski, Adam'" <ajp26@buffalo.edu><br>> Cc: cisco-voip@puck.nether.net<br>> Subject: Re: [cisco-voip] Expressway - 3rd Party Border Recommendation<br>> Message-ID: <BLU406-EAS250264D086BF498E98F733DB37A0@phx.gbl><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> 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.<br>> <br>> Not saying CUBE proxy is terrible, but I would tread carefully down that path and do plenty of testing.<br>> <br>> Sent from my Windows Phone<br>> ________________________________<br>> From: NateCCIE<mailto:nateccie@gmail.com><br>> Sent: ?12/?1/?2014 7:58 PM<br>> To: 'Brian Meade'<mailto:bmeade90@vt.edu>; 'Pawlowski, Adam'<mailto:ajp26@buffalo.edu><br>> Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net><br>> Subject: Re: [cisco-voip] Expressway - 3rd Party Border Recommendation<br>> <br>> Expressway is the first thought, then CUBE Lineside proxy would be where to go for 3rd party.<br>> <br>> <br>> <br>> https://ciscocollab.wordpress.com/2014/04/08/cube-sip-lineside-phone-vpn-configuration/<br>> <br>> <br>> <br>> <br>> <br>> From: cisco-voip [mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Brian Meade<br>> Sent: Monday, December 1, 2014 11:51 AM<br>> To: Pawlowski, Adam<br>> Cc: cisco-voip@puck.nether.net<br>> Subject: Re: [cisco-voip] Expressway - 3rd Party Border Recommendation<br>> <br>> <br>> <br>> 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.<br>> <br>> <br>> <br>> Brian<br>> <br>> <br>> <br>> On Mon, Dec 1, 2014 at 1:23 PM, Pawlowski, Adam <ajp26@buffalo.edu <mailto:ajp26@buffalo.edu> > wrote:<br>> <br>> Afternoon all,<br>> <br>> 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.<br>> <br>> 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.<br>> <br>> 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.<br>> <br>> 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?<br>> <br>> Regards,<br>> <br>> Adam Pawlowski<br>> SUNYAB<br>> <br>> _______________________________________________<br>> cisco-voip mailing list<br>> cisco-voip@puck.nether.net <mailto:cisco-voip@puck.nether.net><br>> https://puck.nether.net/mailman/listinfo/cisco-voip<br>> <br>> <br>> <br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20141201/f960fe3e/attachment-0001.html><br>> -------------- next part --------------<br>> _______________________________________________<br>> cisco-voip mailing list<br>> cisco-voip@puck.nether.net<br>> https://puck.nether.net/mailman/listinfo/cisco-voip<br>> <br>> ------------------------------<br>> <br>> Message: 17<br>> Date: Mon, 1 Dec 2014 22:01:28 -0500<br>> From: Josh Warcop <josh@warcop.com><br>> To: "george.hendrix@l-3com.com" <george.hendrix@l-3com.com>,<br>> <cisco-voip@puck.nether.net><br>> Subject: Re: [cisco-voip] UC integration with MS Office and Lync/MOC<br>> Message-ID: <BLU406-EAS102E49614D728F66623C98B37A0@phx.gbl><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> I'm first coming at this from a Microsoft perspective. Have you moved to Lync Server 2013 and running OCS for CUCILYNC backward compatibility?<br>> <br>> MS Office 2013 includes the Lync 2013 client so you would have to suppress that part of the upgrade.<br>> <br>> You're not finding products compatible with both because Microsoft forked that between OCS and Lync with the Office 2007 to Office 2013 transition.<br>> <br>> My recommendation is to drop CUCILYNC.<br>> <br>> Sent from my Windows Phone<br>> ________________________________<br>> From: george.hendrix@l-3com.com<mailto:george.hendrix@l-3com.com><br>> Sent: ?12/?1/?2014 3:57 PM<br>> To: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net><br>> Subject: [cisco-voip] UC integration with MS Office and Lync/MOC<br>> <br>> Hey Guys,<br>> <br>> 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.<br>> <br>> Thanks,<br>> Bill<br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20141201/3659c5f7/attachment-0001.html><br>> -------------- next part --------------<br>> _______________________________________________<br>> cisco-voip mailing list<br>> cisco-voip@puck.nether.net<br>> https://puck.nether.net/mailman/listinfo/cisco-voip<br>> <br>> ------------------------------<br>> <br>> Message: 18<br>> Date: Mon, 1 Dec 2014 19:29:44 -0800<br>> From: "Walenta, Philip" <Philip.Walenta@Polycom.com><br>> To: Josh Warcop <josh@warcop.com><br>> Cc: "cisco-voip@puck.nether.net" <cisco-voip@puck.nether.net>,<br>> "Pawlowski, Adam" <ajp26@buffalo.edu><br>> Subject: Re: [cisco-voip] Expressway - 3rd Party Border Recommendation<br>> Message-ID: <5E3C80EA-6632-4AA5-96B2-A54D9B0F3465@Polycom.com><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> 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.<br>> <br>> Sent from my iPhone<br>> <br>> On Dec 1, 2014, at 8:55 PM, Josh Warcop <josh@warcop.com<mailto:josh@warcop.com>> wrote:<br>> <br>> 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.<br>> <br>> Not saying CUBE proxy is terrible, but I would tread carefully down that path and do plenty of testing.<br>> <br>> Sent from my Windows Phone<br>> ________________________________<br>> From: NateCCIE<mailto:nateccie@gmail.com><br>> Sent: ?12/?1/?2014 7:58 PM<br>> To: 'Brian Meade'<mailto:bmeade90@vt.edu>; 'Pawlowski, Adam'<mailto:ajp26@buffalo.edu><br>> Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net><br>> Subject: Re: [cisco-voip] Expressway - 3rd Party Border Recommendation<br>> <br>> <br>> Expressway is the first thought, then CUBE Lineside proxy would be where to go for 3rd party.<br>> <br>> <br>> <br>> https://ciscocollab.wordpress.com/2014/04/08/cube-sip-lineside-phone-vpn-configuration/<br>> <br>> <br>> <br>> <br>> <br>> From: cisco-voip [mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Brian Meade<br>> Sent: Monday, December 1, 2014 11:51 AM<br>> To: Pawlowski, Adam<br>> Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net><br>> Subject: Re: [cisco-voip] Expressway - 3rd Party Border Recommendation<br>> <br>> <br>> <br>> 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.<br>> <br>> <br>> <br>> Brian<br>> <br>> <br>> <br>> On Mon, Dec 1, 2014 at 1:23 PM, Pawlowski, Adam <ajp26@buffalo.edu<mailto:ajp26@buffalo.edu>> wrote:<br>> <br>> Afternoon all,<br>> <br>> 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.<br>> <br>> 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.<br>> <br>> 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.<br>> <br>> 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?<br>> <br>> Regards,<br>> <br>> Adam Pawlowski<br>> SUNYAB<br>> <br>> _______________________________________________<br>> cisco-voip mailing list<br>> cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net><br>> https://puck.nether.net/mailman/listinfo/cisco-voip<br>> <br>> <br>> <br>> _______________________________________________<br>> cisco-voip mailing list<br>> cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net><br>> https://puck.nether.net/mailman/listinfo/cisco-voip<br>> _______________________________________________<br>> cisco-voip mailing list<br>> cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net><br>> https://puck.nether.net/mailman/listinfo/cisco-voip<br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20141201/c39f163c/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 19<br>> Date: Tue, 2 Dec 2014 13:21:02 +0000<br>> From: "Jason Aarons (AM)" <jason.aarons@dimensiondata.com><br>> To: Josh Warcop <josh@warcop.com>, Ryan Huff <ryanhuff@outlook.com>,<br>> Pavan K <pav.ccie@gmail.com>, Leslie Meade <leslie.meade@lvs1.com><br>> Cc: "cisco-voip \(cisco-voip@puck.nether.net\)"<br>> <cisco-voip@puck.nether.net><br>> Subject: Re: [cisco-voip] Jabber contact disappears consistently<br>> Message-ID:<br>> <2EB6888CFB98614EA7384BEB9AF8B38216C549@usispsvexdb03.na.didata.local><br>> Content-Type: text/plain; charset="utf-8"<br>> <br>> 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.<br>> <br>> CSCuo95266 - Jabber Windows and directory URI address scheme in IMP 10.x -doc defect<br>> Symptom:<br>> Documentation defect for Jabber for Windows support with directory URI address scheme which was introduced in IMP 10.x<br>> <br>> Cisco Jabber for Windows - 9.7.1<br>> IM and Presence - 10.x<br>> <br>> Conditions:<br>> 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,<br>> 10.6 will support use of a single domain with directoryURI. <<<<THIS HAS NOT BEEN COMMITTED PER BU<br>> <br>> But Cisco J4W 9.7 installation guide incorrectly states that the feature is supported.<br>> <br>> 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<br>> <br>> <br>> <br>> <br>> From: Ryan Huff<mailto:ryanhuff@outlook.com><br>> Sent: ?Wednesday?, ?November? ?26?, ?2014 ?11?:?59? ?AM<br>> To: Pavan K<mailto:pav.ccie@gmail.com>, Leslie Meade<mailto:leslie.meade@lvs1.com><br>> Cc: cisco-voip (cisco-voip@puck.nether.net)<mailto:cisco-voip@puck.nether.net><br>> <br>> I call BS!<br>> <br>> 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.<br>> <br>> 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.<br>> <br>> 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.<br>> <br>> <br>> ________________________________<br>> Date: Wed, 26 Nov 2014 09:09:50 -0600<br>> From: pav.ccie@gmail.com<mailto:pav.ccie@gmail.com><br>> To: Leslie.Meade@lvs1.com<mailto:Leslie.Meade@lvs1.com><br>> CC: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net><br>> Subject: Re: [cisco-voip] Jabber contact disappears consistently<br>> Just to close this out.<br>> <br>> Official word from Cisco even though every piece of Jabber doc says its supported in J4W 10.5<br>> ==<br>> <br>> 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<br>> <br>> ==<br>> <br>> <br>> On Sat, Nov 22, 2014 at 2:15 PM, Leslie Meade <Leslie.Meade@lvs1.com<mailto:Leslie.Meade@lvs1.com>> wrote:<br>> <br>> I also have seen the same issue, and put everyone onto the same server<br>> <br>> <br>> <br>> Leslie Meade<br>> <br>> <br>> <br>> ..................................................................<br>> Mobile:778.228.4339 | Main: 604.676.5239<br>> Email: leslie.meade@lvs1.com<mailto:leslie.meade@lvs1.com><br>> <br>> <br>> <br>> From: cisco-voip [mailto:cisco-voip-bounces@puck.nether.net<mailto:cisco-voip-bounces@puck.nether.net>] On Behalf Of Jason Aarons (AM)<br>> Sent: Saturday, November 22, 2014 11:33 AM<br>> To: Josh Warcop; Pavan K; cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net><br>> Subject: Re: [cisco-voip] Jabber contact disappears consistently<br>> <br>> <br>> <br>> I complete agree, put all Jabberusers on single server. Saw the same bugs in 10x.<br>> <br>> <br>> <br>> From: cisco-voip [mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Josh Warcop<br>> Sent: Friday, November 21, 2014 3:48 PM<br>> To: Pavan K; cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net><br>> Subject: Re: [cisco-voip] Jabber contact disappears consistently<br>> <br>> <br>> <br>> <br>> <br>> 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.<br>> <br>> <br>> ________________________________<br>> <br>> Date: Fri, 21 Nov 2014 11:31:39 -0600<br>> From: pav.ccie@gmail.com<mailto:pav.ccie@gmail.com><br>> To: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net><br>> Subject: [cisco-voip] Jabber contact disappears consistently<br>> We have an interesting problem on a new jabber deployment that has us stumped. Wonder if anybody else saw this.<br>> Two jabber servers with ha enabled and balanced users. Using 10.5su1 for jabber windows and ucm/imp.<br>> Leveraging sip directory uri as the IM scheme due to a multi forest environment with duplicate Samaccountnames across domains.<br>> 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.<br>> Repeatable across multiple users with different userA and userB and happens every time regardless of moving them from server1 to server2 or vice versa.<br>> Using router to router communication between nodes and default jabber-config.<br>> <br>> Any ideas ?<br>> Have a TAC case open but its going nowhere.<br>> <br>> _______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net> https://puck.nether.net/mailman/listinfo/cisco-voip<br>> <br>> <br>> itevomcid<br>> <br>> <br>> <br>> --<br>> - Pavan<br>> <br>> _______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net> https://puck.nether.net/mailman/listinfo/cisco-voip<br>> <br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20141202/b2fc815c/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 20<br>> Date: Tue, 02 Dec 2014 15:01:06 +0000<br>> From: "Brian Palmer" <bpalmer@ctipath.com><br>> To: cisco-voip@puck.nether.net<br>> Subject: [cisco-voip] CUSP High CPU utilization<br>> Message-ID: <em8c62e2a7-813a-46ab-b2cc-e665336c1c68@praetorian><br>> Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>> <br>> Got a customer with a CUSP and both sides seem to be pegging very very <br>> high on the cpu usage. So high I believe it is interfering with call <br>> processing. The vendor that put this new cluster did not follow best <br>> practices in general so there are all kinds of things going on like <br>> criss-crossing of media between the two geographically separated sides. <br>> My real problem is that the CUSP module is much harder to diagnose than <br>> say a regular voice gateway due to a lack of commands to figure out what <br>> is pegging the cpu so bad. Anybody have any good ideas? I can say the <br>> licensing is woefully inadequate and looks to be based on average CPS <br>> and not peak though I don't think that would have an impact on cpu <br>> usage.<br>> <br>> <br>> thanks<br>> <br>> Brian<br>> <br>> -- <br>> *The information contained in this electronic transmission and any <br>> attachments hereto may be considered proprietary and confidential. <br>> Unauthorized distribution of this material to anyone other than the <br>> addressed is prohibited. Any disclosure, distribution or use of this <br>> transmission for any reason other than their intended purpose is <br>> prohibited.*<br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20141202/a975fd1a/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 21<br>> Date: Tue, 2 Dec 2014 16:29:04 +0000<br>> From: "Wes Sisk (wsisk)" <wsisk@cisco.com><br>> To: Daniel Pagan <dpagan@fidelus.com><br>> Cc: "cisco-voip@puck.nether.net" <cisco-voip@puck.nether.net><br>> Subject: Re: [cisco-voip] H245Interface & Related Processes<br>> Message-ID: <0E5CD913-B278-45B3-A68B-2A56E860A335@cisco.com><br>> Content-Type: text/plain; charset="windows-1252"<br>> <br>> Hmm,<br>> <br>> These should help:<br>> CSCsm26337 need clear messages for h225 tcp session failure<br>> <br>> In versions with fix h225 session setup is clearly indicated in cm sdi traces<br>> with one of these messages:<br>> H225Cdpc(%07d)::requestConnect_TcpStartSessionErr: H225 Tcp Start Session<br>> request failed<br>> <br>> H225 Call is aborted as no response received for H225 Tcp Start Session Request<br>> within configured H225TcpTimer value<br>> <br>> h225 session abort due to RST or FIN is clearly indicated in cm sdi traces with:<br>> H225 Tcp session terminated abnormally<br>> <br>> <br>> With fix for this defect TCP session aborts will be reported by one of the following statements in CallManager SDI trace:<br>> requestConnect_TcpStartSessionErr: H225 Tcp Start Session request failed<br>> requestConnect_H225TcpTimer: H225 Call is aborted as no response received for H225 Tcp Start Session Request within configured H225TcpTimer value<br>> call_initiated1_TcpStopSessionInd: H225 Tcp session terminated abnormally<br>> overlap_sending2_TcpStopSessionInd: H225 Tcp session terminated abnormally<br>> outgoing_call_proceeding3_TcpStopSessionInd: H225 Tcp session terminated abnormally<br>> call_delivered4_TcpStopSessionInd: H225 Tcp session terminated abnormally<br>> call_present6_TcpStopSessionInd: H225 Tcp session terminated abnormally<br>> incoming_call_proceeding9_TcpStopSessionInd: H225 Tcp session terminated abnormally<br>> active10_TcpStopSessionInd: H225 Tcp session terminated abnormally<br>> await_ann_complete_TcpStopSessionInd: H225 Tcp session terminated abnormally<br>> active10a_TcpStopSessionInd: H225 Tcp session terminated abnormally<br>> active10b_TcpStopSessionInd: H225 Tcp session terminated abnormally<br>> GKRasARQH225Setup_TcpStopSessionInd: H225 Tcp session terminated abnormally<br>> GKRasCcSetupRequestConnect_TcpStartSessionErr(%d, %d): TcpStartSessionErr from IP=%s<br>> GKRasCcSetupRequestConnect_TcpStartSessionErr: H225 Tcp Start Session request failed<br>> GKRasCcSetupRequestConnect_H225TcpTimer: H225 Call is aborted as no response received for H225 Tcp Start Session Request within configured H225TcpTimer value<br>> overlap_receiving25_TcpStopSessionInd: H225 Tcp session terminated abnormally<br>> wait_for_disconn_kluge_TcpStopSessionInd: H225 Tcp session terminated abnormally<br>> paused_TcpStopSessionInd: H225 Tcp session terminated abnormally<br>> <br>> <br>> <br>> CSCsm26355 need clear messages for h245 tcp session failure<br>> h.245 tcp session setup failure:<br>> TCP ERROR: H245ListenReq or H245ConnectReq failure, or received SdlCloseInd<br>> from H245Handler, Perform cleanup of H245 Session<br>> <br>> established h.245 session experiences TCP keepalive timeout:<br>> TranslateAndTransport(%d)::wait_SdlCloseInd - ERROR: H245 signaling connection<br>> aborted<br>> <br>> established h.245 session receives unexpected TCP FIN or RST:<br>> TranslateAndTransport(%d)::wait_SdlCloseInd - ERROR: H245 signaling connection<br>> aborted<br>> <br>> <br>> <br>> <br>> 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).<br>> <br>> <br>> I believe one of the additional traces above will get you insight to socket requests down to the network layer in UCM.<br>> <br>> -Wes<br>> <br>> <br>> <br>> On Dec 1, 2014, at 5:12 PM, Daniel Pagan <dpagan@fidelus.com<mailto:dpagan@fidelus.com>> wrote:<br>> <br>> Folks:<br>> <br>> Hoping to get some insight on SDL process creation for H245?<br>> <br>> 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.<br>> <br>> 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.<br>> <br>> Thanks!<br>> <br>> - Dan<br>> _______________________________________________<br>> cisco-voip mailing list<br>> cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net><br>> https://puck.nether.net/mailman/listinfo/cisco-voip<br>> <br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20141202/d3dc1152/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Message: 22<br>> Date: Tue, 2 Dec 2014 16:31:49 +0000<br>> From: "Jason Aarons (AM)" <jason.aarons@dimensiondata.com><br>> To: "cisco-voip (cisco-voip@puck.nether.net)"<br>> <cisco-voip@puck.nether.net><br>> Subject: [cisco-voip] Jabber 10.5.1 for Windows shows In a Meeting<br>> when he isn't<br>> Message-ID:<br>> <2EB6888CFB98614EA7384BEB9AF8B382176648@usispsvexdb03.na.didata.local><br>> Content-Type: text/plain; charset="windows-1252"<br>> <br>> 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.<br>> <br>> IMP 10.5.1<br>> <br>> <br>> <br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20141202/4357a4b1/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> Subject: Digest Footer<br>> <br>> _______________________________________________<br>> cisco-voip mailing list<br>> cisco-voip@puck.nether.net<br>> https://puck.nether.net/mailman/listinfo/cisco-voip<br>> <br>> <br>> ------------------------------<br>> <br>> End of cisco-voip Digest, Vol 134, Issue 2<br>> ******************************************<br></div> </div></body>
</html>