[cisco-voip] Finisse -10.5 - cfadmin webpage doesnt open
Aaron Banks
amichaelbanks at hotmail.com
Tue Dec 2 12:39:15 EST 2014
Try IE 11 or Firefox version 24 and above. I've only ever used Firefox; that's what works for me.
> From: cisco-voip-request at puck.nether.net
> Subject: cisco-voip Digest, Vol 134, Issue 2
> To: cisco-voip at puck.nether.net
> Date: Tue, 2 Dec 2014 12:00:03 -0500
>
> Send cisco-voip mailing list submissions to
> cisco-voip at puck.nether.net
>
> 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
> cisco-voip-request at puck.nether.net
>
> You can reach the person managing the list at
> cisco-voip-owner at puck.nether.net
>
> 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
> (george.hendrix at l-3com.com)
> 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" <ajp26 at buffalo.edu>
> To: "cisco-voip at puck.nether.net" <cisco-voip at puck.nether.net>
> Subject: [cisco-voip] Expressway - 3rd Party Border Recommendation
> Message-ID:
> <AEB16C1BF994004E90A436C0CC62287F155FBA5F at 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 <bmeade90 at vt.edu>
> To: "Pawlowski, Adam" <ajp26 at buffalo.edu>
> Cc: "cisco-voip at puck.nether.net" <cisco-voip at puck.nether.net>
> Subject: Re: [cisco-voip] Expressway - 3rd Party Border Recommendation
> Message-ID:
> <CAGcuYh1dBMj6ij1hpo9j3NZ4U=5SdE1-QCMk8wRtBZDDfo49Uw at 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 <ajp26 at buffalo.edu> wrote:
>
> > Afternoon all,
> >
> > Trying to get some opinion on how (if) you would put up a
> > perimeter to your UCM clusters to bring in 3rd party clients, softphones,
> > etc, that are SIP based and reside outside of your secured LAN? Most of our
> > desktops are on public addresses, not behind any particular hardware
> > firewall, just software on the host. I'm concerned that the host could be
> > compromised, or as seen with some soft clients, they just get harassed by
> > driveby SIP/H.323 scans and calls.
> >
> > I haven't seen any great justification for trying to fence/proxy
> > connectivity to the UCM for Jabber, X-Lite, etc, to the cluster, but
> > general security practice is saying that if you can make it more secure, it
> > is at least worth looking into.
> >
> > I've looked at trying to set the UBE up for proxy/passthrough
> > registrar, and this seems tedious because it doesn't proxy auth and
> > requires dial-peer configuration (making dual usage as a gateway
> > cumbersome). I have heard "use expressway" a few times but have no idea how
> > that would work for 3rd party SIP devices. Other than that, I spent a bit
> > of time looking at stuff from Edgewater, OpenSIPS, etc, but it is not clear
> > to me if any of these products are worth the trouble, and what the Cisco
> > recommended way to go about this is.
> >
> > Anyone have any experience or thought in this area? Is this a bad
> > idea? Anything to say about trying to secure potentially 'untrusted'
> > connectivity on a larger scale?
> >
> > Regards,
> >
> > Adam Pawlowski
> > SUNYAB
> >
> > _______________________________________________
> > cisco-voip mailing list
> > cisco-voip at puck.nether.net
> > 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 <ryanhuff at outlook.com>
> To: "cisco-voip at puck.nether.net" <cisco-voip at puck.nether.net>
> Subject: [cisco-voip] Cisco Presence External Database Front End
> Application
> Message-ID: <COL130-W61E1DE4F7EBAC742DC87CFC57D0 at phx.gbl>
> 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: <george.hendrix at l-3com.com>
> To: <cisco-voip at puck.nether.net>
> Subject: [cisco-voip] UC integration with MS Office and Lync/MOC
> Message-ID:
> <255F57BB43F894468DA6BD4F2F5DD1CEB77C2A3F at 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 <dpagan at fidelus.com>
> To: "cisco-voip at puck.nether.net" <cisco-voip at puck.nether.net>
> Subject: [cisco-voip] H245Interface & Related Processes
> Message-ID:
> <a557b4ae8504494194455334cc1123c0 at NYC-EX2K13-MB.fidelus.com>
> 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)" <rratliff at cisco.com>
> To: Daniel Pagan <dpagan at fidelus.com>
> Cc: cisco-voip voyp list <cisco-voip at puck.nether.net>
> Subject: Re: [cisco-voip] H245Interface & Related Processes
> Message-ID: <DBD386D6-250E-4B1B-B144-79F515C22BAA at cisco.com>
> 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 <dpagan at fidelus.com<mailto:dpagan at fidelus.com>> wrote:
>
> Folks:
>
> Hoping to get some insight on SDL process creation for H245?
>
> Scenario is three CUCM clusters communicating over ICTs. Call is routed from Cluster-1 to Cluster-2? then Cluster-2 to Cluster-3. Cluster-3 sends the H245 address & port info via H225 ALERTING to Cluster-2, which then sends its own to Cluster-1. Issue is Cluster-1 never establishes the H245 session with Cluster-2. The H245 address and port is received on Cluster-1 but no H245 processes are being created for the MSD/TCS exchange. According to SDL traces on Cluster-2, the latest state of H245 on the node *sending* the ALERTING message is ?waitForTransportEstablishment?. On Cluster-1, the H245Interface process is never created according to SDL traces, so we never even reach the opportunity for TCS media caps exchange. MXTimeout occurs shortly after.
>
> Question is? For a node receiving an H245 address & port info via H225 (the calling cluster?), is creation of the H245Interface and/or related H245 process dependent on CUCM *first* establishing the new, 2nd TCP socket with the remote H.323 endpoint that advertised the H.245 port. In other words, at an SDL level, is H245Interface created only after the 2nd TCP session is successfully established at the transport level for H245 TCP communication? Knowing this would help me assess the likelihood of the issue being related to issues at the TCP level.
>
> Thanks!
>
> - Dan
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
> 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 <wokka at justfamily.org>
> To: voip puck <cisco-voip at puck.nether.net>
> Subject: [cisco-voip] NFAS t1
> Message-ID:
> <CAGm7T+BUdbxtzuFtT6Q75LzGq7_y8AWex0mh-tJ1izKnW5Ss5g at 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 <wokka at justfamily.org>
> To: Brian Meade <bmeade90 at vt.edu>
> Cc: voip puck <cisco-voip at puck.nether.net>
> Subject: Re: [cisco-voip] NFAS t1
> Message-ID:
> <CAGm7T+B923DRo3NMp-di5V8zgQDn0+fd2PWL5A3TiTxggvGLJQ at 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 <bmeade90 at vt.edu> 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 <wokka at justfamily.org>
> > wrote:
> >
> >> We are seeing an odd error on a migration from a Nortel setup over to an
> >> h323 setup.
> >>
> >> the error message after entering PRI 2 is
> >>
> >> *crsvr1(config-controller)#pri-group timeslots 1-24 nfas_ backup nfas_int
> >> 1 nfas_group 1*
> >>
> >> *%The Primary-group is already defined*
> >> *%The first definition of the primary-group must be removed before the
> >> primary-group can be redefined*
> >>
> >> Getting this after putting the timeslots command on the first pri, then
> >> seeing this error on the 2nd controller.
> >>
> >> This is on 15.2 on a 3945. I've done this before with no issues, but
> >> have never seen this error before.
> >>
> >> Thanks
> >>
> >>
> >> _______________________________________________
> >> cisco-voip mailing list
> >> cisco-voip at puck.nether.net
> >> 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 <bmeade90 at vt.edu>
> To: "Ryan Ratliff (rratliff)" <rratliff at cisco.com>
> Cc: cisco-voip voyp list <cisco-voip at puck.nether.net>
> Subject: Re: [cisco-voip] H245Interface & Related Processes
> Message-ID:
> <CAGcuYh3mfSeJcYwd7SiX-ESAuOwBF0Cj5iUaAdn+PwDEo4=umQ at 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) <rratliff at cisco.com>
> wrote:
>
> > Short answer without confirming in the lab is yes, when I send you my
> > H245 address I expect you to start a TCP connection to me on that port so
> > we can start H245.
> >
> >
> > -Ryan
> >
> > On Dec 1, 2014, at 5:12 PM, Daniel Pagan <dpagan at fidelus.com> wrote:
> >
> > Folks:
> >
> >
> >
> > Hoping to get some insight on SDL process creation for H245?
> >
> >
> >
> > Scenario is three CUCM clusters communicating over ICTs. Call is routed
> > from Cluster-1 to Cluster-2? then Cluster-2 to Cluster-3. Cluster-3 sends
> > the H245 address & port info via H225 ALERTING to Cluster-2, which then
> > sends its own to Cluster-1. Issue is Cluster-1 never establishes the H245
> > session with Cluster-2. The H245 address and port is received on Cluster-1
> > but no H245 processes are being created for the MSD/TCS exchange. According
> > to SDL traces on Cluster-2, the latest state of H245 on the node *
> > *sending** the ALERTING message is ?waitForTransportEstablishment?. On
> > Cluster-1, the H245Interface process is never created according to SDL
> > traces, so we never even reach the opportunity for TCS media caps exchange.
> > MXTimeout occurs shortly after.
> >
> >
> >
> > Question is? For a node receiving an H245 address & port info via H225
> > (the calling cluster?), is creation of the H245Interface and/or related
> > H245 process dependent on CUCM **first**** establishing the new, 2nd TCP
> > socket with the remote H.323 endpoint that advertised the H.245 port. In
> > other words, at an SDL level, is H245Interface created only after the 2nd
> > TCP session is successfully established at the transport level for H245 TCP
> > communication? Knowing this would help me assess the likelihood of the
> > issue being related to issues at the TCP level.
> >
> >
> >
> > Thanks!
> >
> >
> >
> > - Dan
> > _______________________________________________
> > cisco-voip mailing list
> > cisco-voip at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-voip
> >
> >
> > _______________________________________________
> > cisco-voip mailing list
> > cisco-voip at puck.nether.net
> > 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 <bmeade90 at vt.edu>
> To: Charles Goldsmith <wokka at justfamily.org>
> Cc: voip puck <cisco-voip at puck.nether.net>
> Subject: Re: [cisco-voip] NFAS t1
> Message-ID:
> <CAGcuYh2ApRD5KZCbD5hTVN9mjVp6=NJYr-1kkodJ_5hxmv69Nw at 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 <wokka at justfamily.org>
> wrote:
>
> > We are seeing an odd error on a migration from a Nortel setup over to an
> > h323 setup.
> >
> > the error message after entering PRI 2 is
> >
> > *crsvr1(config-controller)#pri-group timeslots 1-24 nfas_ backup nfas_int
> > 1 nfas_group 1*
> >
> > *%The Primary-group is already defined*
> > *%The first definition of the primary-group must be removed before the
> > primary-group can be redefined*
> >
> > Getting this after putting the timeslots command on the first pri, then
> > seeing this error on the 2nd controller.
> >
> > This is on 15.2 on a 3945. I've done this before with no issues, but have
> > never seen this error before.
> >
> > Thanks
> >
> >
> > _______________________________________________
> > cisco-voip mailing list
> > cisco-voip at puck.nether.net
> > 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 <dpagan at fidelus.com>
> To: "Ryan Ratliff (rratliff)" <rratliff at cisco.com>
> Cc: cisco-voip voyp list <cisco-voip at puck.nether.net>
> Subject: Re: [cisco-voip] H245Interface & Related Processes
> Message-ID:
> <dc2c5570502b47b681dc966d25824f84 at NYC-EX2K13-MB.fidelus.com>
> 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:rratliff at cisco.com]
> Sent: Monday, December 01, 2014 5:33 PM
> To: Daniel Pagan
> Cc: cisco-voip voyp list
> Subject: Re: [cisco-voip] H245Interface & Related Processes
>
> Short answer without confirming in the lab is yes, when I send you my H245 address I expect you to start a TCP connection to me on that port so we can start H245.
>
>
> -Ryan
>
> On Dec 1, 2014, at 5:12 PM, Daniel Pagan <dpagan at fidelus.com<mailto:dpagan at fidelus.com>> wrote:
>
> Folks:
>
> Hoping to get some insight on SDL process creation for H245...
>
> Scenario is three CUCM clusters communicating over ICTs. Call is routed from Cluster-1 to Cluster-2... then Cluster-2 to Cluster-3. Cluster-3 sends the H245 address & port info via H225 ALERTING to Cluster-2, which then sends its own to Cluster-1. Issue is Cluster-1 never establishes the H245 session with Cluster-2. The H245 address and port is received on Cluster-1 but no H245 processes are being created for the MSD/TCS exchange. According to SDL traces on Cluster-2, the latest state of H245 on the node *sending* the ALERTING message is "waitForTransportEstablishment". On Cluster-1, the H245Interface process is never created according to SDL traces, so we never even reach the opportunity for TCS media caps exchange. MXTimeout occurs shortly after.
>
> Question is... For a node receiving an H245 address & port info via H225 (the calling cluster...), is creation of the H245Interface and/or related H245 process dependent on CUCM *first* establishing the new, 2nd TCP socket with the remote H.323 endpoint that advertised the H.245 port. In other words, at an SDL level, is H245Interface created only after the 2nd TCP session is successfully established at the transport level for H245 TCP communication? Knowing this would help me assess the likelihood of the issue being related to issues at the TCP level.
>
> Thanks!
>
> - Dan
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
> 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 <nateccie at gmail.com>
> To: "'Brian Meade'" <bmeade90 at vt.edu>, "'Pawlowski, Adam'"
> <ajp26 at buffalo.edu>
> Cc: cisco-voip at puck.nether.net
> Subject: Re: [cisco-voip] Expressway - 3rd Party Border Recommendation
> Message-ID: <089b01d00d9b$96716450$c3542cf0$@gmail.com>
> 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:cisco-voip-bounces at puck.nether.net] On Behalf Of Brian Meade
> Sent: Monday, December 1, 2014 11:51 AM
> To: Pawlowski, Adam
> Cc: cisco-voip at puck.nether.net
> Subject: Re: [cisco-voip] Expressway - 3rd Party Border Recommendation
>
>
>
> I've done this before with a large Avaya setup. We had all of the UC stuff in a separate VRF and all soft clients had to come through an SBC for registration. We demoed Sipera and Acme. Sipera got the job done cheaper, but Acme scaled much better for us. I think CUCM supports Acme SBCs as well as an alternative to CUBE.
>
>
>
> Brian
>
>
>
> On Mon, Dec 1, 2014 at 1:23 PM, Pawlowski, Adam <ajp26 at buffalo.edu <mailto:ajp26 at buffalo.edu> > wrote:
>
> Afternoon all,
>
> Trying to get some opinion on how (if) you would put up a perimeter to your UCM clusters to bring in 3rd party clients, softphones, etc, that are SIP based and reside outside of your secured LAN? Most of our desktops are on public addresses, not behind any particular hardware firewall, just software on the host. I'm concerned that the host could be compromised, or as seen with some soft clients, they just get harassed by driveby SIP/H.323 scans and calls.
>
> I haven't seen any great justification for trying to fence/proxy connectivity to the UCM for Jabber, X-Lite, etc, to the cluster, but general security practice is saying that if you can make it more secure, it is at least worth looking into.
>
> I've looked at trying to set the UBE up for proxy/passthrough registrar, and this seems tedious because it doesn't proxy auth and requires dial-peer configuration (making dual usage as a gateway cumbersome). I have heard "use expressway" a few times but have no idea how that would work for 3rd party SIP devices. Other than that, I spent a bit of time looking at stuff from Edgewater, OpenSIPS, etc, but it is not clear to me if any of these products are worth the trouble, and what the Cisco recommended way to go about this is.
>
> Anyone have any experience or thought in this area? Is this a bad idea? Anything to say about trying to secure potentially 'untrusted' connectivity on a larger scale?
>
> Regards,
>
> Adam Pawlowski
> SUNYAB
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net <mailto:cisco-voip at puck.nether.net>
> 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 <svoll.voip at gmail.com>
> To: "george.hendrix at l-3com.com" <george.hendrix at l-3com.com>
> Cc: "cisco-voip at puck.nether.net" <cisco-voip at puck.nether.net>
> Subject: Re: [cisco-voip] UC integration with MS Office and Lync/MOC
> Message-ID:
> <CAHgd+39J08yh01dzfycrKDw3xyyFupaRQCF5ntoHyQcZtVddYA at 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, <george.hendrix at l-3com.com> 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 <dpagan at fidelus.com>
> To: Brian Meade <bmeade90 at vt.edu>, "Ryan Ratliff (rratliff)"
> <rratliff at cisco.com>
> Cc: cisco-voip voyp list <cisco-voip at puck.nether.net>
> Subject: Re: [cisco-voip] H245Interface & Related Processes
> Message-ID:
> <dc51ff672eb04f1485a6ac5804dc327d at NYC-EX2K13-MB.fidelus.com>
> 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: bmeade90 at gmail.com [mailto:bmeade90 at gmail.com] On Behalf Of Brian Meade
> Sent: Monday, December 01, 2014 5:51 PM
> To: Ryan Ratliff (rratliff)
> Cc: Daniel Pagan; cisco-voip voyp list
> Subject: Re: [cisco-voip] H245Interface & Related Processes
>
> Also should be fairly easy to capture via a packet capture on Cluster 1 if this is easily reproducible for the call flow.
>
> Brian
>
> On Mon, Dec 1, 2014 at 5:32 PM, Ryan Ratliff (rratliff) <rratliff at cisco.com<mailto:rratliff at cisco.com>> wrote:
> Short answer without confirming in the lab is yes, when I send you my H245 address I expect you to start a TCP connection to me on that port so we can start H245.
>
>
> -Ryan
>
> On Dec 1, 2014, at 5:12 PM, Daniel Pagan <dpagan at fidelus.com<mailto:dpagan at fidelus.com>> wrote:
>
> Folks:
>
> Hoping to get some insight on SDL process creation for H245?
>
> Scenario is three CUCM clusters communicating over ICTs. Call is routed from Cluster-1 to Cluster-2? then Cluster-2 to Cluster-3. Cluster-3 sends the H245 address & port info via H225 ALERTING to Cluster-2, which then sends its own to Cluster-1. Issue is Cluster-1 never establishes the H245 session with Cluster-2. The H245 address and port is received on Cluster-1 but no H245 processes are being created for the MSD/TCS exchange. According to SDL traces on Cluster-2, the latest state of H245 on the node *sending* the ALERTING message is ?waitForTransportEstablishment?. On Cluster-1, the H245Interface process is never created according to SDL traces, so we never even reach the opportunity for TCS media caps exchange. MXTimeout occurs shortly after.
>
> Question is? For a node receiving an H245 address & port info via H225 (the calling cluster?), is creation of the H245Interface and/or related H245 process dependent on CUCM *first* establishing the new, 2nd TCP socket with the remote H.323 endpoint that advertised the H.245 port. In other words, at an SDL level, is H245Interface created only after the 2nd TCP session is successfully established at the transport level for H245 TCP communication? Knowing this would help me assess the likelihood of the issue being related to issues at the TCP level.
>
> Thanks!
>
> - Dan
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
> 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)" <jason.aarons at dimensiondata.com>
> To: 0703Manjunath <winmanjunath at gmail.com>, "cisco-voip
> (cisco-voip at puck.nether.net)" <cisco-voip at puck.nether.net>
> Subject: Re: [cisco-voip] Finisse -10.5 - cfadmin webpage doesnt open
> Message-ID:
> <2EB6888CFB98614EA7384BEB9AF8B38216C026 at 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:cisco-voip-bounces at puck.nether.net] On Behalf Of 0703Manjunath
> Sent: Saturday, November 29, 2014 12:43 PM
> To: cisco-voip (cisco-voip at puck.nether.net)
> Subject: [cisco-voip] Finisse -10.5 - cfadmin webpage doesnt open
>
>
> hello,
>
>
> Iam stuck with a issue on finesse cfadmin webpage doesnt open.
>
> we are using UCCE 10.5 , agent webpage opens but admin page doesnt.
>
> Does anyone have any clue about this issue????
>
> --
> Cheers
> Manjunath
>
>
> itevomcid
> -------------- 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 <josh at warcop.com>
> To: NateCCIE <nateccie at gmail.com>, "'Brian Meade'" <bmeade90 at vt.edu>,
> "'Pawlowski, Adam'" <ajp26 at buffalo.edu>
> Cc: cisco-voip at puck.nether.net
> Subject: Re: [cisco-voip] Expressway - 3rd Party Border Recommendation
> Message-ID: <BLU406-EAS250264D086BF498E98F733DB37A0 at phx.gbl>
> 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:nateccie at gmail.com>
> Sent: ?12/?1/?2014 7:58 PM
> To: 'Brian Meade'<mailto:bmeade90 at vt.edu>; 'Pawlowski, Adam'<mailto:ajp26 at buffalo.edu>
> Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
> Subject: Re: [cisco-voip] Expressway - 3rd Party Border Recommendation
>
> Expressway is the first thought, then CUBE Lineside proxy would be where to go for 3rd party.
>
>
>
> https://ciscocollab.wordpress.com/2014/04/08/cube-sip-lineside-phone-vpn-configuration/
>
>
>
>
>
> From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Brian Meade
> Sent: Monday, December 1, 2014 11:51 AM
> To: Pawlowski, Adam
> Cc: cisco-voip at puck.nether.net
> Subject: Re: [cisco-voip] Expressway - 3rd Party Border Recommendation
>
>
>
> I've done this before with a large Avaya setup. We had all of the UC stuff in a separate VRF and all soft clients had to come through an SBC for registration. We demoed Sipera and Acme. Sipera got the job done cheaper, but Acme scaled much better for us. I think CUCM supports Acme SBCs as well as an alternative to CUBE.
>
>
>
> Brian
>
>
>
> On Mon, Dec 1, 2014 at 1:23 PM, Pawlowski, Adam <ajp26 at buffalo.edu <mailto:ajp26 at buffalo.edu> > wrote:
>
> Afternoon all,
>
> Trying to get some opinion on how (if) you would put up a perimeter to your UCM clusters to bring in 3rd party clients, softphones, etc, that are SIP based and reside outside of your secured LAN? Most of our desktops are on public addresses, not behind any particular hardware firewall, just software on the host. I'm concerned that the host could be compromised, or as seen with some soft clients, they just get harassed by driveby SIP/H.323 scans and calls.
>
> I haven't seen any great justification for trying to fence/proxy connectivity to the UCM for Jabber, X-Lite, etc, to the cluster, but general security practice is saying that if you can make it more secure, it is at least worth looking into.
>
> I've looked at trying to set the UBE up for proxy/passthrough registrar, and this seems tedious because it doesn't proxy auth and requires dial-peer configuration (making dual usage as a gateway cumbersome). I have heard "use expressway" a few times but have no idea how that would work for 3rd party SIP devices. Other than that, I spent a bit of time looking at stuff from Edgewater, OpenSIPS, etc, but it is not clear to me if any of these products are worth the trouble, and what the Cisco recommended way to go about this is.
>
> Anyone have any experience or thought in this area? Is this a bad idea? Anything to say about trying to secure potentially 'untrusted' connectivity on a larger scale?
>
> Regards,
>
> Adam Pawlowski
> SUNYAB
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net <mailto:cisco-voip at puck.nether.net>
> 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
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> ------------------------------
>
> Message: 17
> Date: Mon, 1 Dec 2014 22:01:28 -0500
> From: Josh Warcop <josh at warcop.com>
> To: "george.hendrix at l-3com.com" <george.hendrix at l-3com.com>,
> <cisco-voip at puck.nether.net>
> Subject: Re: [cisco-voip] UC integration with MS Office and Lync/MOC
> Message-ID: <BLU406-EAS102E49614D728F66623C98B37A0 at phx.gbl>
> 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: george.hendrix at l-3com.com<mailto:george.hendrix at l-3com.com>
> Sent: ?12/?1/?2014 3:57 PM
> To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
> Subject: [cisco-voip] UC integration with MS Office and Lync/MOC
>
> Hey Guys,
>
> We've been running Cisco UC integration version 8.X (CUCILYNC 8.6) for a while now and it works great with MS Office Communicator R2 and Office 2010, including the click to call add-in. Our MS folks are looking to migrate clients to MS Office 2013, but still use MOC R2. I can't find any product/solution that is compatible with MOC R2 as well as Office 2013 and still provide click to call functionality. Are there any options from Cisco that we can use that will allow integration with MS Office Communicator R2 and Office 2013 that will provide call control and click to call too? Also, it seems the "new" CUCILYNC version is a totally separate window, instead of an add-on section to the bottom, like it is with MOC R2.
>
> Thanks,
> Bill
> -------------- 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
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> ------------------------------
>
> Message: 18
> Date: Mon, 1 Dec 2014 19:29:44 -0800
> From: "Walenta, Philip" <Philip.Walenta at Polycom.com>
> To: Josh Warcop <josh at warcop.com>
> Cc: "cisco-voip at puck.nether.net" <cisco-voip at puck.nether.net>,
> "Pawlowski, Adam" <ajp26 at buffalo.edu>
> Subject: Re: [cisco-voip] Expressway - 3rd Party Border Recommendation
> Message-ID: <5E3C80EA-6632-4AA5-96B2-A54D9B0F3465 at Polycom.com>
> 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 <josh at warcop.com<mailto:josh at warcop.com>> wrote:
>
> TAC opened 3 bugs on my behalf related to CUBE line-side SIP proxy. Not including the documentation bugs that were opened. CUBE in that fashion has a few specific use cases and in my simple use case of replacing ASA phone-proxy it didn't hold up. Expressway is your go to solution for Jabber and TC endpoints and soon DX series.
>
> Not saying CUBE proxy is terrible, but I would tread carefully down that path and do plenty of testing.
>
> Sent from my Windows Phone
> ________________________________
> From: NateCCIE<mailto:nateccie at gmail.com>
> Sent: ?12/?1/?2014 7:58 PM
> To: 'Brian Meade'<mailto:bmeade90 at vt.edu>; 'Pawlowski, Adam'<mailto:ajp26 at buffalo.edu>
> Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
> Subject: Re: [cisco-voip] Expressway - 3rd Party Border Recommendation
>
>
> Expressway is the first thought, then CUBE Lineside proxy would be where to go for 3rd party.
>
>
>
> https://ciscocollab.wordpress.com/2014/04/08/cube-sip-lineside-phone-vpn-configuration/
>
>
>
>
>
> From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Brian Meade
> Sent: Monday, December 1, 2014 11:51 AM
> To: Pawlowski, Adam
> Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
> Subject: Re: [cisco-voip] Expressway - 3rd Party Border Recommendation
>
>
>
> I've done this before with a large Avaya setup. We had all of the UC stuff in a separate VRF and all soft clients had to come through an SBC for registration. We demoed Sipera and Acme. Sipera got the job done cheaper, but Acme scaled much better for us. I think CUCM supports Acme SBCs as well as an alternative to CUBE.
>
>
>
> Brian
>
>
>
> On Mon, Dec 1, 2014 at 1:23 PM, Pawlowski, Adam <ajp26 at buffalo.edu<mailto:ajp26 at buffalo.edu>> wrote:
>
> Afternoon all,
>
> Trying to get some opinion on how (if) you would put up a perimeter to your UCM clusters to bring in 3rd party clients, softphones, etc, that are SIP based and reside outside of your secured LAN? Most of our desktops are on public addresses, not behind any particular hardware firewall, just software on the host. I'm concerned that the host could be compromised, or as seen with some soft clients, they just get harassed by driveby SIP/H.323 scans and calls.
>
> I haven't seen any great justification for trying to fence/proxy connectivity to the UCM for Jabber, X-Lite, etc, to the cluster, but general security practice is saying that if you can make it more secure, it is at least worth looking into.
>
> I've looked at trying to set the UBE up for proxy/passthrough registrar, and this seems tedious because it doesn't proxy auth and requires dial-peer configuration (making dual usage as a gateway cumbersome). I have heard "use expressway" a few times but have no idea how that would work for 3rd party SIP devices. Other than that, I spent a bit of time looking at stuff from Edgewater, OpenSIPS, etc, but it is not clear to me if any of these products are worth the trouble, and what the Cisco recommended way to go about this is.
>
> Anyone have any experience or thought in this area? Is this a bad idea? Anything to say about trying to secure potentially 'untrusted' connectivity on a larger scale?
>
> Regards,
>
> Adam Pawlowski
> SUNYAB
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
> https://puck.nether.net/mailman/listinfo/cisco-voip
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
> 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)" <jason.aarons at dimensiondata.com>
> To: Josh Warcop <josh at warcop.com>, Ryan Huff <ryanhuff at outlook.com>,
> Pavan K <pav.ccie at gmail.com>, Leslie Meade <leslie.meade at lvs1.com>
> Cc: "cisco-voip \(cisco-voip at puck.nether.net\)"
> <cisco-voip at puck.nether.net>
> Subject: Re: [cisco-voip] Jabber contact disappears consistently
> Message-ID:
> <2EB6888CFB98614EA7384BEB9AF8B38216C549 at 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:ryanhuff at outlook.com>
> Sent: ?Wednesday?, ?November? ?26?, ?2014 ?11?:?59? ?AM
> To: Pavan K<mailto:pav.ccie at gmail.com>, Leslie Meade<mailto:leslie.meade at lvs1.com>
> Cc: cisco-voip (cisco-voip at puck.nether.net)<mailto:cisco-voip at puck.nether.net>
>
> 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: pav.ccie at gmail.com<mailto:pav.ccie at gmail.com>
> To: Leslie.Meade at lvs1.com<mailto:Leslie.Meade at lvs1.com>
> CC: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
> 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 <Leslie.Meade at lvs1.com<mailto:Leslie.Meade at lvs1.com>> 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: leslie.meade at lvs1.com<mailto:leslie.meade at lvs1.com>
>
>
>
> From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net>] On Behalf Of Jason Aarons (AM)
> Sent: Saturday, November 22, 2014 11:33 AM
> To: Josh Warcop; Pavan K; cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
> 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:cisco-voip-bounces at puck.nether.net] On Behalf Of Josh Warcop
> Sent: Friday, November 21, 2014 3:48 PM
> To: Pavan K; cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
> 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: pav.ccie at gmail.com<mailto:pav.ccie at gmail.com>
> To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
> 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 cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> itevomcid
>
>
>
> --
> - Pavan
>
> _______________________________________________ cisco-voip mailing list cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net> 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" <bpalmer at ctipath.com>
> To: cisco-voip at puck.nether.net
> Subject: [cisco-voip] CUSP High CPU utilization
> Message-ID: <em8c62e2a7-813a-46ab-b2cc-e665336c1c68 at 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)" <wsisk at cisco.com>
> To: Daniel Pagan <dpagan at fidelus.com>
> Cc: "cisco-voip at puck.nether.net" <cisco-voip at puck.nether.net>
> Subject: Re: [cisco-voip] H245Interface & Related Processes
> Message-ID: <0E5CD913-B278-45B3-A68B-2A56E860A335 at cisco.com>
> 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 <dpagan at fidelus.com<mailto:dpagan at fidelus.com>> wrote:
>
> Folks:
>
> Hoping to get some insight on SDL process creation for H245?
>
> Scenario is three CUCM clusters communicating over ICTs. Call is routed from Cluster-1 to Cluster-2? then Cluster-2 to Cluster-3. Cluster-3 sends the H245 address & port info via H225 ALERTING to Cluster-2, which then sends its own to Cluster-1. Issue is Cluster-1 never establishes the H245 session with Cluster-2. The H245 address and port is received on Cluster-1 but no H245 processes are being created for the MSD/TCS exchange. According to SDL traces on Cluster-2, the latest state of H245 on the node *sending* the ALERTING message is ?waitForTransportEstablishment?. On Cluster-1, the H245Interface process is never created according to SDL traces, so we never even reach the opportunity for TCS media caps exchange. MXTimeout occurs shortly after.
>
> Question is? For a node receiving an H245 address & port info via H225 (the calling cluster?), is creation of the H245Interface and/or related H245 process dependent on CUCM *first* establishing the new, 2nd TCP socket with the remote H.323 endpoint that advertised the H.245 port. In other words, at an SDL level, is H245Interface created only after the 2nd TCP session is successfully established at the transport level for H245 TCP communication? Knowing this would help me assess the likelihood of the issue being related to issues at the TCP level.
>
> Thanks!
>
> - Dan
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
> 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)" <jason.aarons at dimensiondata.com>
> To: "cisco-voip (cisco-voip at puck.nether.net)"
> <cisco-voip at puck.nether.net>
> Subject: [cisco-voip] Jabber 10.5.1 for Windows shows In a Meeting
> when he isn't
> Message-ID:
> <2EB6888CFB98614EA7384BEB9AF8B382176648 at 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
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> ------------------------------
>
> End of cisco-voip Digest, Vol 134, Issue 2
> ******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20141202/2cbbf3db/attachment.html>
More information about the cisco-voip
mailing list