Re: [cisco-voip] CUCM Interop with MS Teams
I am looking at something similar. Have a whole mix of deskphones, jabber, cisco team, m/s teams, in the client’s environment. Just wondering how your landscape looks like and how well it works for calling between cisco-Microsoft and PSTN. Do you have a mix of teams + Desk-phones + jabber at user end or purely MS Teams client and backend Cisco ? Thanks Thanks, Terry > On 25 Mar 2020, at 11:18 am, Loren Hillukka wrote: > > Yes. We are embarking on this adventure soon, using CUBE. > > Loren > >>> On Mar 24, 2020, at 6:28 PM, Brian Meade wrote: >>> >> >> Cisco CUBE can be used for this as well. >> >> Official documentation should be coming in the near future but you can do it >> now with the right configuration. >> >>> On Tue, Mar 24, 2020 at 6:07 PM UC Penguin wrote: >>> Does anyone have an experience with setting up interop between >>> CUCM/Microsoft Teams with Direct Routing? >>> >>> If so what (supported) SBC did you use and what if any issues did you >>> encounter? >>> >>> Thanks! >>> ___ >>> cisco-voip mailing list >>> cisco-voip@puck.nether.net >>> https://puck.nether.net/mailman/listinfo/cisco-voip >> ___ >> cisco-voip mailing list >> cisco-voip@puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-voip > ___ > cisco-voip mailing list > cisco-voip@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] ITL/CTL - CUCM 11
Thanks mate - much appreciated! > On 28 Feb 2019, at 1:25 pm, Ryan Ratliff (rratliff) > wrote: > > > - Ryan Ratliff > >> On Feb 27, 2019, at 2:10 AM, Gr ccie wrote: >> >> Thanks Ryan - this is one of the complex area in the CUCM. >> >> 1) If we let the hardware token expire, do you mean we will not be able to >> use CTL update from the CLI and use software tokens? And we will need to >> have TAC perform the CTL recovery procedure from the root similar to the ITL >> recovery procedure in case we need security in future? Apart from the bug >> you have mentioned there is no other complications as ITL will have the >> certs with TVS as fallback - right? > > You can switch to using tokenless CTL or use the CTL recovery procedure > (normal CLI, no root option) as long as your ITLRecovery cert is in the CTL > currently. The biggest risk is devices that don’t support ITLs and TVS. > >> 2) The only reason I am looking at updating the CTL is as sometimes the >> third party tools don’t work on all the phones. I have Phonview but it will >> show CTL/ITL status for some phones unknown or unreachable even though I can >> see ITL/CTL from the web page. I am thinking of updating CTL to software >> token may stand better chances of pushing CTL to a larger number of phones >> than the number of phones I may be able to clear out remotely. > > I agree, given the difficulty in removing the CTL entirely you are better off > keeping it around and moving forward with awareness of its dependencies. > >> Thanks >> >> On 27 Feb 2019, at 7:33 am, Ryan Ratliff (rratliff) >> wrote: >> >>> Inline. >>> >>> - Ryan Ratliff >>> >>>> On Feb 26, 2019, at 7:39 AM, Gr ccie wrote: >>>> >>>> Hi Team, >>>> >>>> Cucm cluster 11 was in secure mode once (using hw tokens) - then changed >>>> back to non-secure mode. The servers and phones both have the CTL files. >>>> >>>> 1) What issues can we run into if the hardware tokens expire? (Server has >>>> itl and ctl both) >>>> Will the phones keep trusting files when it has both ITL AND CTL, based on >>>> ITL even if the CTL is corrupt or expired. >>> >>> If they expire your chance to update them with anything besides CTLRecovery >>> is gone. >>> >>>> 2) Any real benefit of updating the CTLs using the software CTL tokens by >>>> changing to secure mode and then again turn off secure mode? >>> >>> Only to avoid the case where your eTokens expire. It shifts this risk to >>> when the cert that signed the CTL (publisher CallManager.pem) expires >>> instead. >>> >>>> 3) Would it be a good idea to delete the CTL files from the server and >>>> phones if we don’t want mixed mode? How can we do it, we can delete the >>>> CTL from cli but how abt the phones - can we remove ctl by another method >>>> apart from the third party tools like phone view? >>> >>> Yes, if you really want to make it look like mixed-mode never happened then >>> you have to delete the CTL file everywhere, including at the phones. You >>> are looking at automation via some 3rd party tool to do this. >>> >>>> I believe LSC (being used for dot1x) would continue to operate by getting >>>> CAPF info from ITL. >>> >>> Correct, the CAPF cert is in both ITL and CTL so as long as the ITL remains >>> current you won’t have an issue obtaining LSCs. >>> >>>> 3) I need to regenerate the certificates as well on this cluster >>>> (capf/callmanager/tvs) - will it matter to have an updated CTL or expired? >>> >>> This depends on the phones. There was a bug at one point with 78xx/88xx >>> where they would invalidate their good ITL at boot because the cert that >>> signed it wasn’t in the CTL. If your firmware version is up to date you >>> won’t be exposed to that but. >>> >>>> 4) Another unrelated question if we push a blank ITL file (enabling >>>> cluster rollback feature) and then update CTL in a secure CUCM (not >>>> something I would do but asking for sake of clarity) will it still trust >>>> the updated CTL file based on blank ITL? >>> >>> Empty ITL is still signed, it just doesn’t have a TFTP or CCM+TFTP role in >>> it, so the phone doesn’t look for signed files from TFTP. Accepting that >>> ITL is still subject to validation of the cert that signed it against the >>> certs in the current trust store (CTL + ITL). >>> >>>> >>>> Thanks, >>>> GR >>>> ___ >>>> cisco-voip mailing list >>>> cisco-voip@puck.nether.net >>>> https://puck.nether.net/mailman/listinfo/cisco-voip >>> > ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] ITL/CTL - CUCM 11
Thanks Ryan - this is one of the complex area in the CUCM. 1) If we let the hardware token expire, do you mean we will not be able to use CTL update from the CLI and use software tokens? And we will need to have TAC perform the CTL recovery procedure from the root similar to the ITL recovery procedure in case we need security in future? Apart from the bug you have mentioned there is no other complications as ITL will have the certs with TVS as fallback - right? 2) The only reason I am looking at updating the CTL is as sometimes the third party tools don’t work on all the phones. I have Phonview but it will show CTL/ITL status for some phones unknown or unreachable even though I can see ITL/CTL from the web page. I am thinking of updating CTL to software token may stand better chances of pushing CTL to a larger number of phones than the number of phones I may be able to clear out remotely. Thanks > On 27 Feb 2019, at 7:33 am, Ryan Ratliff (rratliff) > wrote: > > Inline. > > - Ryan Ratliff > >> On Feb 26, 2019, at 7:39 AM, Gr ccie wrote: >> >> Hi Team, >> >> Cucm cluster 11 was in secure mode once (using hw tokens) - then changed >> back to non-secure mode. The servers and phones both have the CTL files. >> >> 1) What issues can we run into if the hardware tokens expire? (Server has >> itl and ctl both) >> Will the phones keep trusting files when it has both ITL AND CTL, based on >> ITL even if the CTL is corrupt or expired. > > If they expire your chance to update them with anything besides CTLRecovery > is gone. > >> 2) Any real benefit of updating the CTLs using the software CTL tokens by >> changing to secure mode and then again turn off secure mode? > > Only to avoid the case where your eTokens expire. It shifts this risk to when > the cert that signed the CTL (publisher CallManager.pem) expires instead. > >> 3) Would it be a good idea to delete the CTL files from the server and >> phones if we don’t want mixed mode? How can we do it, we can delete the CTL >> from cli but how abt the phones - can we remove ctl by another method apart >> from the third party tools like phone view? > > Yes, if you really want to make it look like mixed-mode never happened then > you have to delete the CTL file everywhere, including at the phones. You are > looking at automation via some 3rd party tool to do this. > >> I believe LSC (being used for dot1x) would continue to operate by getting >> CAPF info from ITL. > > Correct, the CAPF cert is in both ITL and CTL so as long as the ITL remains > current you won’t have an issue obtaining LSCs. > >> 3) I need to regenerate the certificates as well on this cluster >> (capf/callmanager/tvs) - will it matter to have an updated CTL or expired? > > This depends on the phones. There was a bug at one point with 78xx/88xx where > they would invalidate their good ITL at boot because the cert that signed it > wasn’t in the CTL. If your firmware version is up to date you won’t be > exposed to that but. > >> 4) Another unrelated question if we push a blank ITL file (enabling cluster >> rollback feature) and then update CTL in a secure CUCM (not something I >> would do but asking for sake of clarity) will it still trust the updated CTL >> file based on blank ITL? > > Empty ITL is still signed, it just doesn’t have a TFTP or CCM+TFTP role in > it, so the phone doesn’t look for signed files from TFTP. Accepting that ITL > is still subject to validation of the cert that signed it against the certs > in the current trust store (CTL + ITL). > >> >> Thanks, >> GR >> ___ >> cisco-voip mailing list >> cisco-voip@puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-voip > ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
[cisco-voip] Jabber Phone Mode - Login ID
Hi Team, We have a customer using Jabber in Phone mode no presence. Currently using userID@Domain for login.Cucm version is 11.5. Jabber version is 12. CUCM is sso enabled with AD integration. Directory URI etc is set at end user level in CUCM. How can we get it to use - email as Jabber login instead of the userid field. Sent from my iPhone ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] CUBE DTMF
Yeah - it was initially rtp-nte only (both internal and provider facing) but some sites could only do out of band and I wanted to steer clear of using MTPs - so added kpml on top of rtp nte. It works fine now and without the need for mtp. Sent from my iPhone > On 31 Mar 2018, at 2:38 pm, Kent Roberts <k...@fredf.org> wrote: > > Put the NTE first, or if you can only use NTE. > >> On Mar 30, 2018, at 9:10 PM, GR <grc...@gmail.com> wrote: >> >> Thx Anthony. Just an update, did that and interworking works fine between >> kpml and rtp nte. >> >> Was enquiring abt digit drop to follow a proactive approach rather than >> reactive. So far its ok without that - but I still have few pending sites >> so not implemented globally yet. >> >> Sent from my iPhone >> >>> On 17 Mar 2018, at 5:08 am, Anthony Holloway >>> <avholloway+cisco-v...@gmail.com> wrote: >>> >>> I have had to add digit-drop to the dial-peers when calls were heading to >>> CUC, but not 100% of the time. As with a lot of things, don't configure >>> something just to configure it. Know that it's needed first, then >>> configure it. Else you end up with this giant configuration that you >>> cannot explain half of what its doing. >>> >>>> On Fri, Mar 16, 2018 at 12:33 AM GR <grc...@gmail.com> wrote: >>>> Thanks Anthony. So no need to configure digit drop ? Even if I am doing >>>> RFC2833 on one leg and advertise both Inband and OOB on second leg. >>>> >>>> >>>> Sent from my iPhone >>>> >>>>> On 16 Mar 2018, at 2:10 am, Anthony Holloway >>>>> <avholloway+cisco-v...@gmail.com> wrote: >>>>> >>>>> I was going to mention that CUBE doesn't support rtp-nte to sip-kpml >>>>> interworking. Weird, I know. But that's how it was. However, when I >>>>> went to grab the link for my source, the table has been updated, and I >>>>> see that this is now supported. >>>>> >>>>> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/dtmf-relay.html#concept_264617919921874995299551391601561 >>>>> >>>>> Therefore, I see no gotchas with enablingwell...maybe one gotcha. If >>>>> you enable both RTP-NTE and SIP-KPML on a dial-peer, note that CUBE will >>>>> advertise both, and the offer answer model dictates that CUBE will then >>>>> not be able to choose or control the DTMF relay selected. However, when >>>>> CUBE receives an offer with multiple relays in it, it will choose which >>>>> to use based on ordermaybe. >>>>> >>>>> Citations from that link: >>>>> >>>>> "If multiple DTMF relay mechanisms are enabled on a SIP dial peer and are >>>>> negotiated successfully, NOTIFY-based out-of-band DTMF relay takes >>>>> precedence." >>>>> >>>>> "If you configure more than one out-of-band DTMF method, preference goes >>>>> from highest to lowest in the order of configuration." >>>>> >>>>> "CUBE negotiates both rtp-nte and sip-kpml if both are supported and >>>>> advertised in the incoming INVITE. However, CUBE relies on the rtp-nte >>>>> DTMF method to receive digits and a SUBSCRIBE if sip-kpml is not >>>>> initiated. CUBE still accepts SUBSCRIBEs for KPML. This prevents >>>>> double-digit reporting problems at CUBE." >>>>> >>>>> "CUBE selects DTMF relay mechanisms using the following priority: >>>>> sip-notify or sip-kpml (highest priority) >>>>> rtp-nte >>>>> None—Send DTMF in-band" >>>>> I recommend to read that entire document, or at least the chapter I >>>>> linked, because it has some good info on it. Of course, you'll want to >>>>> test everything, because it's not out of reason to have to file a >>>>> documentation defect. >>>>> >>>>>> On Thu, Mar 15, 2018 at 8:44 AM GR <grc...@gmail.com> wrote: >>>>>> Hi Guys, >>>>>> >>>>>> I am having an issue with SIP provider only supporting rfc2833. The >>>>>> CUBEs are configured only for rtp-nte on all dial-peers facing both the >>>>>> provider and the CUCM internal network (multiple clusters) >>>>&
Re: [cisco-voip] CUBE DTMF
Thx Anthony. Just an update, did that and interworking works fine between kpml and rtp nte. Was enquiring abt digit drop to follow a proactive approach rather than reactive. So far its ok without that - but I still have few pending sites so not implemented globally yet. Sent from my iPhone > On 17 Mar 2018, at 5:08 am, Anthony Holloway > <avholloway+cisco-v...@gmail.com> wrote: > > I have had to add digit-drop to the dial-peers when calls were heading to > CUC, but not 100% of the time. As with a lot of things, don't configure > something just to configure it. Know that it's needed first, then configure > it. Else you end up with this giant configuration that you cannot explain > half of what its doing. > >> On Fri, Mar 16, 2018 at 12:33 AM GR <grc...@gmail.com> wrote: >> Thanks Anthony. So no need to configure digit drop ? Even if I am doing >> RFC2833 on one leg and advertise both Inband and OOB on second leg. >> >> >> Sent from my iPhone >> >>> On 16 Mar 2018, at 2:10 am, Anthony Holloway >>> <avholloway+cisco-v...@gmail.com> wrote: >>> >>> I was going to mention that CUBE doesn't support rtp-nte to sip-kpml >>> interworking. Weird, I know. But that's how it was. However, when I went >>> to grab the link for my source, the table has been updated, and I see that >>> this is now supported. >>> >>> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/dtmf-relay.html#concept_264617919921874995299551391601561 >>> >>> Therefore, I see no gotchas with enablingwell...maybe one gotcha. If >>> you enable both RTP-NTE and SIP-KPML on a dial-peer, note that CUBE will >>> advertise both, and the offer answer model dictates that CUBE will then not >>> be able to choose or control the DTMF relay selected. However, when CUBE >>> receives an offer with multiple relays in it, it will choose which to use >>> based on ordermaybe. >>> >>> Citations from that link: >>> >>> "If multiple DTMF relay mechanisms are enabled on a SIP dial peer and are >>> negotiated successfully, NOTIFY-based out-of-band DTMF relay takes >>> precedence." >>> >>> "If you configure more than one out-of-band DTMF method, preference goes >>> from highest to lowest in the order of configuration." >>> >>> "CUBE negotiates both rtp-nte and sip-kpml if both are supported and >>> advertised in the incoming INVITE. However, CUBE relies on the rtp-nte DTMF >>> method to receive digits and a SUBSCRIBE if sip-kpml is not initiated. CUBE >>> still accepts SUBSCRIBEs for KPML. This prevents double-digit reporting >>> problems at CUBE." >>> >>> "CUBE selects DTMF relay mechanisms using the following priority: >>> sip-notify or sip-kpml (highest priority) >>> rtp-nte >>> None—Send DTMF in-band" >>> I recommend to read that entire document, or at least the chapter I linked, >>> because it has some good info on it. Of course, you'll want to test >>> everything, because it's not out of reason to have to file a documentation >>> defect. >>> >>>> On Thu, Mar 15, 2018 at 8:44 AM GR <grc...@gmail.com> wrote: >>>> Hi Guys, >>>> >>>> I am having an issue with SIP provider only supporting rfc2833. The CUBEs >>>> are configured only for rtp-nte on all dial-peers facing both the provider >>>> and the CUCM internal network (multiple clusters) >>>> >>>> Randomly one of the MGCP/h323 gateway is having issues, where it only >>>> supports OOB and then further complications trying to resolve the problem. >>>> >>>> I am planning to add sip kpml as well on top of rtp-nte to advertise both >>>> inband and outofband DTMF methods towards our internal CUCM network and >>>> let CUBE do inter-working in case where one leg is rfc2833 (carrier side) >>>> and other is kpml(internal network lets say MGCP gateway). Trying to stay >>>> away from MTPs. >>>> >>>> Any gotchas if I just go ahead and add kpml on top of existing rtp-nte >>>> method (on CUBE dial-peers facing our internal network) as I don’t want to >>>> break the setup where only inband is supported, hard to check in a global >>>> deployment. >>>> >>>> Any need to use digit-drop in case both inband and out of band digits are >>>> sent? If required it will be only on dial-peers facing CUCM side? Or this >>>> is not required as the provider only supports rfc2833. >>>> >>>> Thanks >>>> GR >>>> >>>> >>>> >>>> >>>> Sent from my iPhone >>>> ___ >>>> cisco-voip mailing list >>>> cisco-voip@puck.nether.net >>>> https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] CUBE DTMF
Thanks Anthony. So no need to configure digit drop ? Even if I am doing RFC2833 on one leg and advertise both Inband and OOB on second leg. Sent from my iPhone > On 16 Mar 2018, at 2:10 am, Anthony Holloway > <avholloway+cisco-v...@gmail.com> wrote: > > I was going to mention that CUBE doesn't support rtp-nte to sip-kpml > interworking. Weird, I know. But that's how it was. However, when I went > to grab the link for my source, the table has been updated, and I see that > this is now supported. > > https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/dtmf-relay.html#concept_264617919921874995299551391601561 > > Therefore, I see no gotchas with enablingwell...maybe one gotcha. If you > enable both RTP-NTE and SIP-KPML on a dial-peer, note that CUBE will > advertise both, and the offer answer model dictates that CUBE will then not > be able to choose or control the DTMF relay selected. However, when CUBE > receives an offer with multiple relays in it, it will choose which to use > based on ordermaybe. > > Citations from that link: > > "If multiple DTMF relay mechanisms are enabled on a SIP dial peer and are > negotiated successfully, NOTIFY-based out-of-band DTMF relay takes > precedence." > > "If you configure more than one out-of-band DTMF method, preference goes from > highest to lowest in the order of configuration." > > "CUBE negotiates both rtp-nte and sip-kpml if both are supported and > advertised in the incoming INVITE. However, CUBE relies on the rtp-nte DTMF > method to receive digits and a SUBSCRIBE if sip-kpml is not initiated. CUBE > still accepts SUBSCRIBEs for KPML. This prevents double-digit reporting > problems at CUBE." > > "CUBE selects DTMF relay mechanisms using the following priority: > sip-notify or sip-kpml (highest priority) > rtp-nte > None—Send DTMF in-band" > I recommend to read that entire document, or at least the chapter I linked, > because it has some good info on it. Of course, you'll want to test > everything, because it's not out of reason to have to file a documentation > defect. > >> On Thu, Mar 15, 2018 at 8:44 AM GR <grc...@gmail.com> wrote: >> Hi Guys, >> >> I am having an issue with SIP provider only supporting rfc2833. The CUBEs >> are configured only for rtp-nte on all dial-peers facing both the provider >> and the CUCM internal network (multiple clusters) >> >> Randomly one of the MGCP/h323 gateway is having issues, where it only >> supports OOB and then further complications trying to resolve the problem. >> >> I am planning to add sip kpml as well on top of rtp-nte to advertise both >> inband and outofband DTMF methods towards our internal CUCM network and let >> CUBE do inter-working in case where one leg is rfc2833 (carrier side) and >> other is kpml(internal network lets say MGCP gateway). Trying to stay away >> from MTPs. >> >> Any gotchas if I just go ahead and add kpml on top of existing rtp-nte >> method (on CUBE dial-peers facing our internal network) as I don’t want to >> break the setup where only inband is supported, hard to check in a global >> deployment. >> >> Any need to use digit-drop in case both inband and out of band digits are >> sent? If required it will be only on dial-peers facing CUCM side? Or this is >> not required as the provider only supports rfc2833. >> >> Thanks >> GR >> >> >> >> >> Sent from my iPhone >> ___ >> cisco-voip mailing list >> cisco-voip@puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
[cisco-voip] CUBE DTMF
Hi Guys, I am having an issue with SIP provider only supporting rfc2833. The CUBEs are configured only for rtp-nte on all dial-peers facing both the provider and the CUCM internal network (multiple clusters) Randomly one of the MGCP/h323 gateway is having issues, where it only supports OOB and then further complications trying to resolve the problem. I am planning to add sip kpml as well on top of rtp-nte to advertise both inband and outofband DTMF methods towards our internal CUCM network and let CUBE do inter-working in case where one leg is rfc2833 (carrier side) and other is kpml(internal network lets say MGCP gateway). Trying to stay away from MTPs. Any gotchas if I just go ahead and add kpml on top of existing rtp-nte method (on CUBE dial-peers facing our internal network) as I don’t want to break the setup where only inband is supported, hard to check in a global deployment. Any need to use digit-drop in case both inband and out of band digits are sent? If required it will be only on dial-peers facing CUCM side? Or this is not required as the provider only supports rfc2833. Thanks GR Sent from my iPhone ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] CSR 12 - CUCM etc.
Thanks Matthew - looks like either i missed the beta testing window or it wasn't made available for testing like the earlier versions. Sent from my iPhone > On 12 Oct 2017, at 9:41 am, Matthew Loraditch > <mloradi...@heliontechnologies.com> wrote: > > 12 is FCS for UCM/IMP/UCXN and I think CER they are only on PUT. The Ucxn toi > stuff is on the ciscounitytools.com site. The rest of the partner slides are > on sales connect from the PBT > > Get Outlook for iOS > > Matthew Loraditch > Sr. Network Engineer > p: 443.541.1518 > w: www.heliontechnologies.com | e: mloradi...@heliontechnologies.com > > > > > From: cisco-voip <cisco-voip-boun...@puck.nether.net> on behalf of GR > <grc...@gmail.com> > Sent: Wednesday, October 11, 2017 6:38:48 PM > To: cisco-voip@puck.nether.net > Subject: [cisco-voip] CSR 12 - CUCM etc. > > Hi Guys, > > Was/is there a Beta testing running for CSR release 12. Used to participate > in the previous versions, but looks like may have missed on this one. > > Any information or any pointers to any presentation slides for version 12? > > Thanks > > Sent from my iPhone > ___ > cisco-voip mailing list > cisco-voip@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
[cisco-voip] CSR 12 - CUCM etc.
Hi Guys, Was/is there a Beta testing running for CSR release 12. Used to participate in the previous versions, but looks like may have missed on this one. Any information or any pointers to any presentation slides for version 12? Thanks Sent from my iPhone ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] cucm 10.5(1) vs 10.0(1)
Thanks Anthony good point. Anyone from Cisco on the list can clarify this plz? VG224 and 7937 will definitely be a big deal. -gr On 9 Jul 2014, at 4:02 pm, Hughes, Scott GRE-MG shug...@grenergy.com wrote: I would love for some clarification on this-- specifically VG224, 7925, and 7937 support. On Jul 8, 2014, at 3:26 PM, Anthony Holloway avholloway+cisco-v...@gmail.commailto:avholloway+cisco-v...@gmail.com wrote: It appears as though CUCM 10.5 drops official support for some phone and gateway models. E.g., 7925, 7937, 1861 and VG224. Or at least, the compatibility matrix is no longer being maintained for these products. Check here: http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/uc_system/unified/communications/system/versions/IPTMtrix.html#wp1016708 On Tue, Jul 8, 2014 at 7:23 AM, GR grc...@gmail.commailto:grc...@gmail.com wrote: Hi Guys, Was just about to do a fresh installation of ucm/cuc/imp on a Cisco BE6k. Is 10.5 mature enough to go ahead? Anyone has anything to share on whether to go for a 10.0 or 10.5? Googling didnot yield sufficient results - if anyone can share there first hand experience or thoughts would be great. -gr Sent from my iPhone ___ cisco-voip mailing list cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip NOTICE TO RECIPIENT: The information contained in this message from Great River Energy and any attachments are confidential and intended only for the named recipient(s). If you have received this message in error, you are prohibited from copying, distributing or using the information. Please contact the sender immediately by return email and delete the original message. ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
[cisco-voip] cucm 10.5(1) vs 10.0(1)
Hi Guys, Was just about to do a fresh installation of ucm/cuc/imp on a Cisco BE6k. Is 10.5 mature enough to go ahead? Anyone has anything to share on whether to go for a 10.0 or 10.5? Googling didnot yield sufficient results - if anyone can share there first hand experience or thoughts would be great. -gr Sent from my iPhone ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
