Send cisco-voip mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/cisco-voip
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of cisco-voip digest..."
Today's Topics:
1. TSP capacity? (Scott Voll)
2. Re: 9.3.1 , TVS, and IPv6 (Adam Pawlowski)
3. Re: Multicast MoH issue from branch router (Steve Miller)
4. mgcp pri channels (cisco.voip)
5. Re: mgcp pri channels (Ted Nugent)
6. Re: mgcp pri channels (Lelio Fulgenzi)
7. upgrading UCCX 5.0 to 9.0 (Abebe Amare)
8. Re: upgrading UCCX 5.0 to 9.0 (Buchanan, James)
9. Re: upgrading UCCX 5.0 to 9.0 (Abebe Amare)
10. Communication Problem between CUBE and CUCM (Cleothus Spady)
11. Re: upgrading UCCX 5.0 to 9.0 (Buchanan, James)
12. Enterprise Feature Access Number not working (Roger Wiklund)
13. CUCM 8.6 publisher rebuild (Eric Pedersen)
14. Re: CUCM 8.6 publisher rebuild (Rick Gilliam)
15. Re: Communication Problem between CUBE and CUCM (Eric Pedersen)
----------------------------------------------------------------------
Message: 1
Date: Thu, 8 Nov 2012 10:09:36 -0800
From: Scott Voll <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [cisco-voip] TSP capacity?
Message-ID:
<CAHgd+3-1iB24GL1FAEGOvSCiaPmeyp0q56No=cd4w28ggv1...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I have an application (call recording) that uses TSP / TAPI. How many
phone can I associate to the application user?
we are running 7835h3 with cm 7.1.5 very soon to be 8.6.2.
I don't know where to look.
Thanks
Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20121108/1cb89392/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 8 Nov 2012 13:47:52 -0500
From: "Adam Pawlowski" <[email protected]>
To: "'Tom Piscitell \(tpiscite\)'" <[email protected]>, "'Jason
Burns'" <[email protected]>
Cc: [email protected]
Subject: Re: [cisco-voip] 9.3.1 , TVS, and IPv6
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
This does seem to be a way around this trouble.
>From the set that wasn't working correctly, from the CLI, we were able to
get this output:
001B2A20FFFF> show tvs
Priority : 0
TVS IPv4 Address : 1.2.3.4
TVS IPv6 Address :
TVS Port : 2445
Priority : 1
TVS IPv4 Address : 2.3.4.5
TVS IPv6 Address :
TVS Port : 2445
>From a working set though:
001B2A20FFFF> show tvs
Priority : 0
TVS IPv4 Address : 1.2.3.4
TVS IPv6 Address :
TVS Port : 2445
IP Mode : 0
IP Pref : 0
DSCP value : 96
Priority : 1
TVS IPv4 Address : 2.3.4.5
TVS IPv6 Address :
TVS Port : 2445
IP Mode : 0
IP Pref : 0
DSCP value : 96
Since we moved from 9.1.1 to 9.3.1, I wonder if the format of this file
changed, and wasn't successfully updated on some phones for whatever reason.
One the phone was "repaired" the file reflects the latter format. I wonder
if it's that this file is not correctly formatted that causes it causes that
fallback to happen, since I could see some errors about reading the tvs conf
file in the phone's log. Then again, the file may not be formatted correctly
because of some other thing, either way, I'm not sure I'm going to find a
cause. This is life on the bleeding edge of things, I guess, running into
anomalies. The TFTP "fix" works, and makes sense. TAC was going down the bad
ITL route, which I would guess is the basket most people are in with ITL
problems, but, it wasn't that at all. The ITL would have successfully
updated if it bothered to contact the host. Wireshark showed the phone not
emitting any traffic at all, (I didn't try configuring the phone with an
IPv6 address itself to see if it started spouting out traffic but there was
no V6 address for the TVS/TFTP present at that time), so it had no chance to
upgrade.
I'm not convinced this has anything to do with the UCM and not the software
on the phone, but in this case this investigation was being tied to the UCM
version, which we need to upgrade, I guess, to pursue this further. If it
comes up again I'll open a case again to see what they say.
Anyways, we'll probably still end up picking up some software to deal with
the ITLs so we are not in panic mode if we do run into problems with it
later on.
Thanks all for your help
Adam
> -----Original Message-----
> From: Tom Piscitell (tpiscite) [mailto:[email protected]]
> Sent: Wednesday, November 07, 2012 4:22 PM
> To: Jason Burns
> Cc: Stephen Welsh; Tom Piscitell (tpiscite); Heim, Dennis; <cisco-
> [email protected]>; Adam Pawlowski
> Subject: Re: [cisco-voip] 9.3.1 , TVS, and IPv6
>
> Hey Adam,
>
> This does sounds like the situation me and Jason have ran into a couple
> times. Unfortunately we were never able to reproduce it so we never
> understood exactly what happened to put the phones in this situation.
>
> However, more specific to your situation, a phone will only need to use
TVS
> to verify its configuration file if it is using a TFTP server that it did
not get its
> ITL file from. In the ITL file there is only one CallManager.pem (the
certificate
> that signs the config files). So if you have an ITL from Server A, and
then try
> and use Server B for TFTP, you will need to use TVS. However, as long as
you
> use Server A for TFTP, there will be no need for TVS.
>
> So with that said, it sounds like the phones have an ITL file from some
server
> other than their primary TFTP server (192.168.0.1??). Alternatively, they
may
> have an older version of the ITL from the primary TFTP server because the
> CallManager.pem was recently regenerated. Let's assume its the former
> since the only change was a firmware upgrade. To find out what server the
> ITL file came from, we need to compare the hash that shows up in the phone
> UI (Settings > Security Settings > Trust List > ITL). You will then need
to
> compare that to the ITL file on the servers. Here is a quick one-liner to
get
> the hash of the current ITL on CUCM:
>
> tpiscite-mac:CUCMFolder tompiscitell$ curl
> http://14.48.30.101:6970/ITLFile.tlv 2>/dev/null | md5
> 48bf091242356d56dcdbb4aca5d9095e
>
> Note: If you want to do the same for the CTL just replace "ITLFile.tlv"
with
> "CTLFile.tlv".
>
> Once you find the TFTP server that the ITL file came from, you just need
to
> point the phones at that (Alternate TFTP, DHCP Option 150, shutting down
> the other TFTP server, etc), and have it register. If you cannot find a
matching
> ITL file on any of the servers, then the phones probably have an old ITL
file
> and SBD was "broken" for quite a while, but the firmware upgrade
> uncovered it.
>
> Hope this helps.
>
> Tom Piscitell
> Customer Support Engineer
> Unified Communications Infrastructure
> +1-919-574-0081, 9am-5pm EST (GMT -5)
>
> On Nov 7, 2012, at 1:38 PM, Jason Burns <[email protected]> wrote:
>
> > Adam,
> >
> > I've seen this exact same thing with some of my customers. Here's what I
> think caused the whole IPv6 problem on the phone:
> >
> > 1. CUCM cluster was upgraded.
> > 2. Pub and TFTP servers were rebooted.
> > 3. Backup subs were rebooted.
> > 4. Primary subs were rebooted.
> > 5. Phones reset and try to get a TFTP file from the TFTP server.
> >
> > Here's where the problem is. The phones tried to get a TFTP file, but
the
> TFTP server hadn't completed database replication yet. The phones
> downloaded a non complete config file, or a non complete ITL file. This
ITL or
> config file (i never did figure out which) put the phone into a mode where
for
> every single TVS request it tried to use the IPv6 stack on the phone.
You'd
> see on the phone console logs that the phone tried to connect to TVS and
it
> timed out. You'd never see any packets leave the phone to TCP 2445 in a
> packet capture.
> >
> > I believe we fixed the problem by shutting down the primary TFTP server
> and letting the phones use the backup TFTP server. This worked because the
> phones had an ITL that was signed by the backup TFTP server so they
trusted
> the backup TFTP server's key. The ITL file they had though, or the config
file
> wouldn't let TVS work.. we needed to find the server that signed the
phone's
> file and get the phone to go BACK to that original server so it could get
a
> complete config file.
> >
> > Either do that or erase the ITL manually from the phone (or use an
> automated tool). I'm including Tom here because he worked on this problem
> and may remember the details more accurately. I don't know if we ever
> found a bug for this.
> >
> > There are automated tools that make erasing the ITL easier, but for your
> case if you have more than one TFTP server try either:
> >
> > 1. Shutting down the primary TFTP service and resetting the phones so
> they go to backup.
> > 2. Changing the DHCP scope so they go to the backup.
> > 3. Change the TFTP address manually in a phone to point to another
server.
> >
> > Hope that points you in the right direction.
> >
> > -Jason
> >
> >
> >
> > On Mon, Nov 5, 2012 at 11:46 AM, Stephen Welsh
> <[email protected]> wrote:
> > Absolutely correct Dennis ;)
> >
> > That is a valid approach as long as the phone 'trusts' the
callmanager.pem
> certificate used by the TFTP service, however if it does not you need to
get
> the phones ITL file updated before you can remove it. There are two main
> ways to do that:
> >
> > 1) Get the TVS service to update the phones ITL File (sometimes a
> > restart of the TVS Service, or regenerating the Callmanager.pem cert
> > works)
> > 2) Delete the ITL file on the phone
> >
> > Option 1 doesn't always work and can cause further issues that need to
> > be considered/managed (Catch-22) Option 2 generally always works
> >
> > It's too easy to get stuck in a catch-22 with SBD related issues, the
> combination of certificates, phone configuration and TVS service all lead
back
> to each other in a nasty loop, from our experience the easiest way to
break
> the look is delete the ITL file on the phone's user interface.
> >
> > I'm not stating that remotely deleting the ITL file from all your phones
is the
> ideal solution to the problem, just that in reality it is the best
solution that is
> proven to work when other approaches can fail at points.
> >
> > Thanks
> >
> > Stephen
> >
> > On 5 Nov 2012, at 16:30, "Heim, Dennis" <[email protected]>
> > wrote:
> >
> >> The article also talks about setting the rollback parameter to true,
which
> will erase the ITL on the phones. Obviously this requires that your phones
> can still register.
> >>
> >> Dennis Heim | Sr. UC Engineer
> >> World Wide Technology | 314.212.1814 | [email protected]
> "Creating
> >> Impact, Ignition & Scalability"
> >>
> >> From: [email protected]
> >> [mailto:[email protected]] On Behalf Of Stephen
> >> Welsh
> >> Sent: Monday, November 05, 2012 11:06 AM
> >> To: Adam Pawlowski
> >> Cc: <[email protected]>
> >> Subject: Re: [cisco-voip] 9.3.1 , TVS, and IPv6
> >>
> >> Hi Adam,
> >>
> >> As you stated (very nicely :), everyone that upgrades to (or between)
> UCM 8 & 9 versions needs to understand SBD. Unfortunately even if you do
> everything right you can still get hit by a SBD/ITL problems, there are
several
> different ways to get caught out even if you go 100% by the book.
> >> In our experience the best way to handle almost any SBD issue is
> >> deleting the ITL File, there are some steps to prevent issues, but
> >> they are never 100% fool-proof, the best thing to do is be prepared
> >> to 'easily' manage/delete those pesky ITL files ;)
> >>
> >> If you haven't already found this, the best information on Security by
> Default is by Jason Burns:
> >>
> >> https://supportforums.cisco.com/docs/DOC-17679
> >>
> >> I completely appreciate your point of view that the last thing you
> >> should "have" to do is delete the ITL file, if you read Jason's
> >> document this will give you the best understanding and chance to
> >> eliminate (or minimise) this likely hood. However I always recommend
> >> that you have a Plan-B, Unified FX has devised an approach (a way to
> >> configure your cluster) that will ensure that you will never need to
> >> physically go to a phone to delete an ITL files even in the worst and
> >> most rare SDB Issues. Believe me the issue you have at the moment is
> >> nothing compared to some of the SBD problems we have had to solve, at
> >> least your phones are still registered ;)
> >>
> >> Thanks
> >>
> >> Stephen Welsh, CCIE #12345
> >> CTO
> >> Unified FX
> >> http://www.unifiedfx.com
> >>
> >> On 5 Nov 2012, at 15:37, Adam Pawlowski <[email protected]>
> >> wrote:
> >>
> >>
> >> Stephen,
> >>
> >> Removing the ITL file from the phone does seem to allow it to grab
a
> new one, since it doesn't need to verify it. When the phone is booting up,
it
> lists, from a file on its flash, that it has no TVS servers, until it has
read the
> configuration file and established the CM nodes from that device pool. TVS
is
> running on all hosts in the cluster, including the TFTP, which it seems to
want
> to fall back to, to verify its configuration and ITL initially. For
whatever reason
> it insists on using the TFTP, yet, it wants to connect via IPv6 which just
can't
> work and doesn't. It's placed me into a situation where I want to turn off
V6
> but, have to do so in the phone's config, and can't change the phone's
config
> until I turn off V6 (or erase the ITL).
> >>
> >> I will inspect the ITL on the phone again to see what's going on -
the
> nodes should all be listed but the ITLs hash has changed. I'd love to
> understand just what is going on with this. As we were talking earlier
about
> here, the license documentation for the 8 upgrades should have come with a
> singing telegram or at least a stack of bright red paper drawing our
attention
> to this feature. There's a lot that's new in the UCM and it seems easy to
get
> underwater on the everything that comes up, but this just seems too easy
to
> run afoul of bugs or problems which can hose over your cluster. If we have
to
> erase, we have to erase, but, I don't want to get into the habit of
planning to
> or having to erase security certificates if there's a way to correct the
issue.
> >>
> >> Thanks much though for your time and reply
> >>
> >> Adam
> >>
> >> From: Stephen Welsh [mailto:[email protected]]
> >> Sent: Monday, November 05, 2012 9:09 AM
> >> To: Pawlowski, Adam
> >> Cc: [email protected]
> >> Subject: Re: [cisco-voip] 9.3.1 , TVS, and IPv6
> >>
> >> Hi Adam,
> >>
> >> Are you sure the ipv6 thing is not a red herring?
> >>
> >> Have you tried removing the ITL File from the phone and/or restarting
the
> TVS service?
> >>
> >> If you are not aware the choice of TVS service (node IP Address) is
based
> on the Call Manager Group configured on the phone, you could try adding
all
> nodes to the phones CM Group to see if that helps the phone to contact a
> TVS service it has a matching ITL entry for.
> >>
> >> If you are still stuck I'm happy to host a WebEx session to share my
SDB &
> ITL experiences, I'm the original author of PhoneView
> (http://www.unifiedfx.com), it's been used to help a LOT of people with
SBD
> related issues, never-mind countless UCM installations and upgrades.
> >>
> >> In-case you do need to delete/manage your ITL Files, or even just get a
> proper view/handle on the phone firmware version of your estate you
> should give PhoneView a try:
> >>
> >> http://www.unifiedfx.com/phoneview/trial
> >>
> >> Thanks
> >>
> >> Stephen
> >>
> >> On 5 Nov 2012, at 13:51, "Pawlowski, Adam" <[email protected]>
> >> wrote:
> >>
> >>
> >>
> >> Morning list,
> >>
> >> From what I can read, TVS has been a thrill ride for those of us
lucky
> enough to run afoul of SBD. I'm hoping we haven't run into such a
situation
> here but I have a question. We just pushed 9.3.1 out to devices from
> 9.1.1SR1, with peer firmware sharing enabled. This went miserably and left
a
> lot of devices stranded at 9.1.1 or at an "Upgrading" screen. Working with
> TAC on that but so far nothing. We began receiving reports from end users
> that their directories were missing, they can't change ringers, etc. Last
time
> this happened we had phones that had picked up a bum ITL from a partial
> rollout, and we had to erase them by hand.
> >>
> >> This time that shouldn't have been the case - it was just a
firmware
> upgrade. However, it looks like some of the phones that have gone to 9.3.1
> have decided that they want to use IPv6 when talking to the TFTP to verify
> their initial configurations, when they have no TVS server list built on
the
> device. In looking at the phone console logs, you can see that the device
is in
> "IP mode 1" and tries to connect to TFTP, say "192.168.0.1 :: " which is
> obviously not a V6 address. We're not running V6 so it has no address
bound.
> No traffic leaves the phone, but, the phone says it timed out (EAGAIN)
> connecting to the TFTP and won't verify the ITL/CFG/etc.
> >>
> >> What I'm looking at it is setting V6 to off at the cluster, but,
I don't see
> any way to repair this on affected devices (could be a large amount) other
> than erasing the ITL, or deploying IPv6. Given the leg work that could go
into
> identifying and taking care of these devices, it's arguable as to which
one
> would be harder at this point.
> >>
> >> Any comment on this with this firmware? Anyone else run into this
> miserable trouble?
> >>
> >> Adam Pawlowski
> >> SUNYAB Network and Classroom Services
> >> _______________________________________________
> >> cisco-voip mailing list
> >> [email protected]
> >> https://puck.nether.net/mailman/listinfo/cisco-voip
> >
> >
> > _______________________________________________
> > cisco-voip mailing list
> > [email protected]
> > https://puck.nether.net/mailman/listinfo/cisco-voip
> >
> >
>
------------------------------
Message: 3
Date: Thu, 8 Nov 2012 13:13:04 -0800 (PST)
From: Steve Miller <[email protected]>
To: John Van Laecke <[email protected]>, gr11 <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [cisco-voip] Multicast MoH issue from branch router
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Do a show ephone summ
you should have a music file stored in flash
sh ephone summary
File music-on-hold.au type AU Media_Payload_G711Ulaw64k 160 bytes
Moh multicast on 239.1.1.1 port 16384 via 10.213.67.1
via 1.1.1.1
This is the music file music-on-hold.au
Multcast address 239.1.1.1
Port must match the audio stream in CCM 16384
Lan Interface 10.213.67.1
Loopback 1.1.1.1
moh music-on-hold.au
multicast moh 239.1.1.1 port 16384 route 10.213.67.1 1.1.1.1
________________________________
From: John Van Laecke <[email protected]>
To: gr11 <[email protected]>; "[email protected]"
<[email protected]>
Sent: Thu, November 1, 2012 5:36:59 PM
Subject: Re: [cisco-voip] Multicast MoH issue from branch router
Under call manager fallback whats your config for multicast ? or are you doing
multicast over the wan ?
From:[email protected]
[mailto:[email protected]] On Behalf Of gr11
Sent: Thursday, 1 November 2012 8:22 PM
To: [email protected]
Subject: [cisco-voip] Multicast MoH issue from branch router
I am having this issue, one of the branch router is not streaming multicast
moh.
I was told it was working and has stopped working (not sure though)...when the
user is put on hold - there is silence and the output of sh ccm music-on-hold
is as below:
sh ccm music
Current active multicast sessions : 1
Multicast RTP port Packets Call Codec Incoming
Address number in/out id Interface
===================================================================
239.1.1.1 16384 0/0 77911 g711ulaw
<<<<< no interface and packets stay at 0
CUCM - checked multicast is enabled and MRGL is assigned to DP ..On the router
max-dn command was missing under fallback...rest is configured properly..with
multicast route and correct file name..if i try adding max-dn i get below error
and i am not even able to add max-dn 1....
%DIALPEER_DB-3-ADDPEER_MEM_THRESHOLD: Addition of dial-peers limited by
available memory
sh ephone summ output shows - no MOH file...i have tried removing and re-adding
fallback and also re uploading the MoH file....could the issue be due to max-dn
not configured....??? or it could be two separate issues..? Router is 3845 and
IOS is 12.3(11r)T2....Any clue if any one came across this????
sh ephone summ
hairpin_block:
Max 500, Registered 0, Unregistered 0, Deceased 0 High Water Mark 501, Sockets 0
ephone_send_packet process switched 0
Max Conferences 12 with 0 active (4 allowed)
Skinny Music On Hold Status
Active MOH clients 0 (max 830), Media Clients 0, B-ACD Clients 0
No MOH file loaded <<<<<<<<<<< even thoug file is in flash and triple
checked
and reuploaded.....
_____________________
This e-mail has been scanned for viruses by MessageLabs.
_____________________
This email and all attachments are confidential. For further important
information about emails sent to or from GHD or if you have received this email
in error, please refer to http://www.ghd.com/emaildisclaimer.html .
_____________________
This e-mail has been scanned for viruses by MessageLabs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20121108/4cf06fa0/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 08 Nov 2012 20:25:32 -0500
From: "cisco.voip" <[email protected]>
To: [email protected]
Subject: [cisco-voip] mgcp pri channels
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
All - I have a CUCM7 with an MGCP gateway, but with my service provider
I wish to only use channels 1-12 in/out and
leave 12-23 for inbound only. Is there a way to control this on the
2800 router, or is there something in the call Manager I can do?
Thanks
------------------------------
Message: 5
Date: Thu, 8 Nov 2012 21:08:08 -0500
From: Ted Nugent <[email protected]>
To: "cisco.voip" <[email protected]>
Cc: Cisco VoIPoE List <[email protected]>
Subject: Re: [cisco-voip] mgcp pri channels
Message-ID:
<cahs2vyunp4zjcugsckhch4vj74zqmysqq519ejvm5dq4kbt...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Frac PRIs via MGCP are not supported however it can work, you're better off
reconfiguring the gateway as H323
Here's a DOC that outlines how to do it on CM4 but the premise is the same,
you will probably need to change the channel selection from Bottom-up to
top-down as well. It's been a while since I set it up
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_configuration_example09186a008076f8d2.shtml
On Thu, Nov 8, 2012 at 8:25 PM, cisco.voip <[email protected]> wrote:
> All - I have a CUCM7 with an MGCP gateway, but with my service provider I
> wish to only use channels 1-12 in/out and
> leave 12-23 for inbound only. Is there a way to control this on the 2800
> router, or is there something in the call Manager I can do?
> Thanks
> ______________________________**_________________
> cisco-voip mailing list
> [email protected]
> https://puck.nether.net/**mailman/listinfo/cisco-voip<https://puck.nether.net/mailman/listinfo/cisco-voip>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20121108/6cdd03ac/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 8 Nov 2012 21:21:29 -0500 (EST)
From: Lelio Fulgenzi <[email protected]>
To: "cisco.voip" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [cisco-voip] mgcp pri channels
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Ask your service provider to configure inbound calls capped at 23 and outbound
calls capped at 12.
They should be able to do this for you.
Sent from my iPhone...
"There's no place like 127.0.0.1"
On Nov 8, 2012, at 8:26 PM, "cisco.voip" <[email protected]> wrote:
> All - I have a CUCM7 with an MGCP gateway, but with my service provider I
> wish to only use channels 1-12 in/out and
> leave 12-23 for inbound only. Is there a way to control this on the 2800
> router, or is there something in the call Manager I can do?
> Thanks
> _______________________________________________
> cisco-voip mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-voip
------------------------------
Message: 7
Date: Fri, 9 Nov 2012 12:24:52 +0300
From: Abebe Amare <[email protected]>
To: cisco voip <[email protected]>
Subject: [cisco-voip] upgrading UCCX 5.0 to 9.0
Message-ID:
<canrv87jeh8ph42t7r3zlc9xuucv+mdepqpjjizj5js-2587...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi, we are planning to upgrade UCCX 5.0(2) to version 9.0 running on UCS
servers. The system integrator send us email regarding the upgrade process
and I am looking for some information regarding the following two points:
1. We will do a fresh installation for the Unified Contact Center Express
version 9, no data will be migrated from the old UCCX server to the new
UCCX server. You can still see the old UCCX data (reporting) from the old
server only (Windows based)
2. We will do a fresh installation for the Quality Manager version 9, no
data will be migrated from the old QM server to the new QM server. You can
still hear the old calls if you open the web interface of the old QM server
only.
what other ways exist to upgrade to version 9 without losing data?
best regards,
Abebe Amare
Senior Network Admin
VivaCell
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20121109/b3c71d2f/attachment-0001.html>
------------------------------
Message: 8
Date: Fri, 9 Nov 2012 09:31:22 +0000
From: "Buchanan, James" <[email protected]>
To: Abebe Amare <[email protected]>, cisco voip
<[email protected]>
Subject: Re: [cisco-voip] upgrading UCCX 5.0 to 9.0
Message-ID:
<12d6a6a157b44348974e5ed93738628c0969f...@hqexchmbx03.presidio.corp>
Content-Type: text/plain; charset="utf-8"
You can do this a couple of ways. One way would be to upgrade UCCX to 7.0, run
the migration tool to 8.5, then upgrade the 8.5 to 9.0. You could install 5.0
on another box, restore the data, upgrade to 7.0, then get the data from there.
If you do that, you will lose some data before cutover but not as much as not
getting any data at all.
From: [email protected]
[mailto:[email protected]] On Behalf Of Abebe Amare
Sent: Friday, November 09, 2012 11:25 AM
To: cisco voip
Subject: [cisco-voip] upgrading UCCX 5.0 to 9.0
Hi, we are planning to upgrade UCCX 5.0(2) to version 9.0 running on UCS
servers. The system integrator send us email regarding the upgrade process and
I am looking for some information regarding the following two points:
1. We will do a fresh installation for the Unified Contact Center Express
version 9, no data will be migrated from the old UCCX server to the new UCCX
server. You can still see the old UCCX data (reporting) from the old server
only (Windows based)
2. We will do a fresh installation for the Quality Manager version 9, no data
will be migrated from the old QM server to the new QM server. You can still
hear the old calls if you open the web interface of the old QM server only.
what other ways exist to upgrade to version 9 without losing data?
best regards,
Abebe Amare
Senior Network Admin
VivaCell
James Buchanan | Sr. Network Engineer
Presidio | www.presidio.com<http://www.presidio.com>
12 Cadillac Drive Suite 130, Brentwood, TN 37027
D: 615.866.5729 | C: 931.797.2326 | F: 615.866.5781 |
[email protected]<mailto:[email protected]>
[Be Secure In The Knowledge]<http://www.presidio.com>
Follow us:
[Follow Presidio on Twitter]<http://www.twitter.com/presidio>
This message w/attachments (message) is intended solely for the use of the
intended recipient(s) and may contain information that is privileged,
confidential or proprietary. If you are not an intended recipient, please
notify the sender, and then please delete and destroy all copies and
attachments. Please be advised that any review or dissemination of, or the
taking of any action in reliance on, the information contained in or attached
to this message is prohibited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20121109/0883d59f/attachment-0001.html>
------------------------------
Message: 9
Date: Fri, 9 Nov 2012 14:29:01 +0300
From: Abebe Amare <[email protected]>
To: "Buchanan, James" <[email protected]>
Cc: cisco voip <[email protected]>
Subject: Re: [cisco-voip] upgrading UCCX 5.0 to 9.0
Message-ID:
<canrv87hsmd7owo3ubvblpedyyythceog0zh0eiz-wynotkb...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi James, thanks for your quick reply.
The current system is running on MCS 7845 machines in HA mode. We are going
to get two redundant UCS servers and all other UC application like CUCM,
UCCX, Connecion and QM will be running as virtual servers. Based on what
you pointed out, is it better to install the old version of UCCX on the UCS
servers and follow the upgrade path
UCCX 5.0->7.0->run migration tool->8.5->9.0
And upgrade the current UCCX running on the MCS server to 7.0 and get the
data?
Thanks in Advance
On Fri, Nov 9, 2012 at 12:31 PM, Buchanan, James <[email protected]>wrote:
> You can do this a couple of ways. One way would be to upgrade UCCX to
> 7.0, run the migration tool to 8.5, then upgrade the 8.5 to 9.0. You could
> install 5.0 on another box, restore the data, upgrade to 7.0, then get the
> data from there. If you do that, you will lose some data before cutover but
> not as much as not getting any data at all.****
>
> ** **
>
> *From:* [email protected] [mailto:
> [email protected]] *On Behalf Of *Abebe Amare
> *Sent:* Friday, November 09, 2012 11:25 AM
> *To:* cisco voip
> *Subject:* [cisco-voip] upgrading UCCX 5.0 to 9.0****
>
> ** **
>
> Hi, we are planning to upgrade UCCX 5.0(2) to version 9.0 running on UCS
> servers. The system integrator send us email regarding the upgrade process
> and I am looking for some information regarding the following two points:
>
> 1. We will do a fresh installation for the Unified Contact Center Express
> version 9, no data will be migrated from the old UCCX server to the new
> UCCX server. You can still see the old UCCX data (reporting) from the old
> server only (Windows based)
> 2. We will do a fresh installation for the Quality Manager version 9, no
> data will be migrated from the old QM server to the new QM server. You can
> still hear the old calls if you open the web interface of the old QM server
> only.
>
> what other ways exist to upgrade to version 9 without losing data?
>
> best regards,
>
> Abebe Amare
> Senior Network Admin
> VivaCell****
>
>
> James Buchanan | Sr. Network Engineer
> Presidio | www.presidio.com
> 12 Cadillac Drive Suite 130, Brentwood, TN 37027
> D: 615.866.5729 | C: 931.797.2326 | F: 615.866.5781 |
> [email protected]
>
>
>
> [image: Be Secure In The Knowledge] <http://www.presidio.com>
>
>
> Follow us:
>
> [image: Follow Presidio on Twitter] <http://www.twitter.com/presidio>
>
> *This message w/attachments (message) is intended solely for the use of
> the intended recipient(s) and may contain information that is privileged,
> confidential or proprietary. If you are not an intended recipient, please
> notify the sender, and then please delete and destroy all copies and
> attachments. Please be advised that any review or dissemination of, or
> the taking of any action in reliance on, the information contained in or
> attached to this message is prohibited.*****
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20121109/cdb5eb46/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 9 Nov 2012 04:15:31 -0800 (PST)
From: Cleothus Spady <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [cisco-voip] Communication Problem between CUBE and CUCM
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
?Heres whats Happening,?? I'm unable to register media resources from my DAllas
Cube to my DAllas CUCM(Sub),I'm able to register them with another sub located
in (DC) but not Dallas, The problem with the media resources registering
in(DC),?the call flow will go like this DALCUBE>DC?CUCM>DALCUBE>ITSP (sip)
?
I'm able to ping Dal Cube from Dal Cucm and DAl Cucm to Dal Cube
I have packet captures that show There is No TCP (port 2000)?ACK message both
ways, If the Cube sends the request there is no ACK message from CUCM,? if CUCM
sends the request there is no ACK from the CUBE
?
The funny thing is there is no firewall or access list? between DAL CUBE and
DAL CUCM, but there is one between DAL CUBE and DC CUCM
?
?
?
I think this connection would solve my one way audio issue, that was solved by
using a MTP,(using the MTP worked until the firewall block the voice traffic
coming from DAllas to DC)
?
?
I'm sure? the cube configurations are correct since they are able to register
with other cucm, just not the one i need it too
?
?
Thanks in Advance
?
?
?
?
?
?
?
?
?
?
Tell me and I will forget
Show me and I might Remember
Involve me and I will understand
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20121109/dcf62236/attachment-0001.html>
------------------------------
Message: 11
Date: Fri, 9 Nov 2012 12:24:55 +0000
From: "Buchanan, James" <[email protected]>
To: Abebe Amare <[email protected]>
Cc: cisco voip <[email protected]>
Subject: Re: [cisco-voip] upgrading UCCX 5.0 to 9.0
Message-ID:
<12d6a6a157b44348974e5ed93738628c0969f...@hqexchmbx03.presidio.corp>
Content-Type: text/plain; charset="utf-8"
Well, you cannot install UCCX 7.0 on the UCS servers?they are not supported for
VMWare. So, you would need a loaner MCS server. However, since you are
migrating your entire environment to UCS, you could take a secondary Unity
server or CUCM server and use it as a staging server for UCCX 7.0.
From: Abebe Amare [mailto:[email protected]]
Sent: Friday, November 09, 2012 1:29 PM
To: Buchanan, James
Cc: cisco voip
Subject: Re: [cisco-voip] upgrading UCCX 5.0 to 9.0
Hi James, thanks for your quick reply.
The current system is running on MCS 7845 machines in HA mode. We are going to
get two redundant UCS servers and all other UC application like CUCM, UCCX,
Connecion and QM will be running as virtual servers. Based on what you pointed
out, is it better to install the old version of UCCX on the UCS servers and
follow the upgrade path
UCCX 5.0->7.0->run migration tool->8.5->9.0
And upgrade the current UCCX running on the MCS server to 7.0 and get the data?
Thanks in Advance
On Fri, Nov 9, 2012 at 12:31 PM, Buchanan, James
<[email protected]<mailto:[email protected]>> wrote:
You can do this a couple of ways. One way would be to upgrade UCCX to 7.0, run
the migration tool to 8.5, then upgrade the 8.5 to 9.0. You could install 5.0
on another box, restore the data, upgrade to 7.0, then get the data from there.
If you do that, you will lose some data before cutover but not as much as not
getting any data at all.
From:
[email protected]<mailto:[email protected]>
[mailto:[email protected]<mailto:[email protected]>]
On Behalf Of Abebe Amare
Sent: Friday, November 09, 2012 11:25 AM
To: cisco voip
Subject: [cisco-voip] upgrading UCCX 5.0 to 9.0
Hi, we are planning to upgrade UCCX 5.0(2) to version 9.0 running on UCS
servers. The system integrator send us email regarding the upgrade process and
I am looking for some information regarding the following two points:
1. We will do a fresh installation for the Unified Contact Center Express
version 9, no data will be migrated from the old UCCX server to the new UCCX
server. You can still see the old UCCX data (reporting) from the old server
only (Windows based)
2. We will do a fresh installation for the Quality Manager version 9, no data
will be migrated from the old QM server to the new QM server. You can still
hear the old calls if you open the web interface of the old QM server only.
what other ways exist to upgrade to version 9 without losing data?
best regards,
Abebe Amare
Senior Network Admin
VivaCell
James Buchanan | Sr. Network Engineer
Presidio | www.presidio.com<http://www.presidio.com>
12 Cadillac Drive Suite 130, Brentwood, TN 37027
D: 615.866.5729 | C: 931.797.2326 | F: 615.866.5781 |
[email protected]<mailto:[email protected]>
<http://www.presidio.com>
Follow us:
<http://www.presidio.com>
This message w/attachments (message) is intended solely for the use of the
intended recipient(s) and may contain information that is privileged,
confidential or proprietary. If you are not an intended recipient, please
notify the sender, and then please delete and destroy all copies and
attachments. Please be advised that any review or dissemination of, or the
taking of any action in reliance on, the information contained in or attached
to this message is prohibited.
<http://www.presidio.com>
James Buchanan | Sr. Network Engineer
Presidio | www.presidio.com<http://www.presidio.com>
12 Cadillac Drive Suite 130, Brentwood, TN 37027
D: 615.866.5729 | C: 931.797.2326 | F: 615.866.5781 |
[email protected]<mailto:[email protected]>
[Be Secure In The Knowledge]<http://www.presidio.com>
Follow us:
[Follow Presidio on Twitter]<http://www.twitter.com/presidio>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20121109/69dab53b/attachment-0001.html>
------------------------------
Message: 12
Date: Fri, 9 Nov 2012 15:38:35 +0100
From: Roger Wiklund <[email protected]>
To: Cisco VOIP <[email protected]>
Subject: [cisco-voip] Enterprise Feature Access Number not working
Message-ID:
<CAC+aSK1=eKmsePK=-9s14aiz0wbW6FLF1+54kEu+CQo=rjd...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi
I cannot get EFA to work no matter what I do.
I have looked through all Cisco documentation and just found this blog:
http://cisco-uc-learning.blogspot.se/2010/07/single-number-reachsnr-and-enterprise.html
The problem is that I cannot call the Enterprise Feature Access number. I
just get 404 not found. And when I do a DNA it says unallocated/unassigned
number.
Has anyone else got this running? I'm not using MVA, only EFA.
Thanks
/Roger
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20121109/43e81199/attachment-0001.html>
------------------------------
Message: 13
Date: Fri, 9 Nov 2012 16:08:03 +0000
From: Eric Pedersen <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [cisco-voip] CUCM 8.6 publisher rebuild
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
I would like more disk space on our CUCM 8.6 publisher so I'm planning
rebuilding the publisher on a new VM with more disk. Is there any impact to the
subscribers during a publisher restore? Do I need to reboot them after? I
didn't see any required steps in the DRS guide for the subscribers.
I've only done a publisher restore as part of a cluster hardware upgrade
before, not on its own, so it would be good to know if there are any gotchas.
Thanks,
Eric
The contents of this message may contain confidential and/or privileged
subject matter. If this message has been received in error, please contact
the sender and delete all copies. Like other forms of communication,
e-mail communications may be vulnerable to interception by unauthorized
parties. If you do not wish us to communicate with you by e-mail, please
notify us at your earliest convenience. In the absence of such
notification, your consent is assumed. Should you choose to allow us to
communicate by e-mail, we will not take any additional security measures
(such as encryption) unless specifically requested.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20121109/6b88c911/attachment-0001.html>
------------------------------
Message: 14
Date: Fri, 9 Nov 2012 08:23:11 -0800 (PST)
From: Rick Gilliam <[email protected]>
To: Eric Pedersen <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [cisco-voip] CUCM 8.6 publisher rebuild
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
When Running a DSR Recovery/Restore followed up with a reboot to make sure sync
is good at that time there is definate subscribers being effected Eric.?
Rick
________________________________
From: Eric Pedersen <[email protected]>
To: "[email protected]" <[email protected]>
Sent: Friday, November 9, 2012 8:08 AM
Subject: [cisco-voip] CUCM 8.6 publisher rebuild
I would like more disk space on our CUCM 8.6 publisher so I'm planning
rebuilding the publisher on a new VM with more disk. Is there any impact to the
subscribers during a publisher restore? Do I need to reboot them after? I
didn?t see any required steps in the DRS guide for the subscribers.?
?
I've only done a publisher restore as part of a cluster hardware upgrade
before, not on its own, so it would be good to know if there are any gotchas.?
?
Thanks,
Eric
The contents of this message may contain confidential and/or privileged
subject matter. If this message has been received in error, please contact
the sender and delete all copies. Like other forms of communication,
e-mail communications may be vulnerable to interception by unauthorized
parties. If you do not wish us to communicate with you by e-mail, please
notify us at your earliest convenience. In the absence of such
notification, your consent is assumed. Should you choose to allow us to
communicate by e-mail, we will not take any additional security measures
(such as encryption) unless specifically requested.
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20121109/093c15b3/attachment-0001.html>
------------------------------
Message: 15
Date: Fri, 9 Nov 2012 16:23:07 +0000
From: Eric Pedersen <[email protected]>
To: Cleothus Spady <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [cisco-voip] Communication Problem between CUBE and CUCM
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Where are you taking the packet capture? If you take a capture on CUCM do you
see a SYN arriving there from the CUBE and CUCM sending the ACK?
From: [email protected]
[mailto:[email protected]] On Behalf Of Cleothus Spady
Sent: 09 November 2012 5:16 AM
To: [email protected]
Subject: [cisco-voip] Communication Problem between CUBE and CUCM
Heres whats Happening, I'm unable to register media resources from my DAllas
Cube to my DAllas CUCM(Sub),I'm able to register them with another sub located
in (DC) but not Dallas, The problem with the media resources registering
in(DC), the call flow will go like this DALCUBE>DC CUCM>DALCUBE>ITSP (sip)
I'm able to ping Dal Cube from Dal Cucm and DAl Cucm to Dal Cube
I have packet captures that show There is No TCP (port 2000) ACK message both
ways, If the Cube sends the request there is no ACK message from CUCM, if CUCM
sends the request there is no ACK from the CUBE
The funny thing is there is no firewall or access list between DAL CUBE and
DAL CUCM, but there is one between DAL CUBE and DC CUCM
I think this connection would solve my one way audio issue, that was solved by
using a MTP,(using the MTP worked until the firewall block the voice traffic
coming from DAllas to DC)
I'm sure the cube configurations are correct since they are able to register
with other cucm, just not the one i need it too
Thanks in Advance
Tell me and I will forget
Show me and I might Remember
Involve me and I will understand
The contents of this message may contain confidential and/or privileged
subject matter. If this message has been received in error, please contact
the sender and delete all copies. Like other forms of communication,
e-mail communications may be vulnerable to interception by unauthorized
parties. If you do not wish us to communicate with you by e-mail, please
notify us at your earliest convenience. In the absence of such
notification, your consent is assumed. Should you choose to allow us to
communicate by e-mail, we will not take any additional security measures
(such as encryption) unless specifically requested.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20121109/80fe53fe/attachment-0001.html>
------------------------------
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
End of cisco-voip Digest, Vol 109, Issue 7
******************************************
