Since you are coming from a dissimilar system, my advice is to create a phone
template in CUCM (located in the phone subsection of the BAT menu of the
publisher), per model, and put as much standardized data as you can in the
phone template (device pool, CSS, sip profile, number of lines,
Does anyone has a good phone BATTING Tamplate? I am converting Avaya phone
system to cisco phone system and having issue getting good tamplate. CUCM
VERSION: 10.5.2.
PHONES MODEL, 7942's, 881's, 8851's and some wireless phones.
Anything with good instructions will be appreciate.
Thanks
Hamu
What I am trying to express, although perhaps worded ambiguously, is that all
your TDM resources are on the NIM and that I don't believe you could share the
DSP from the backplane along with the NIM resources, for the purposes of TDM.
I would agree that you are correct, in that any unallocated
What do mean by shareable to the backplane? It is my understanding that unused
DSPs on a NIM can be used for conferencing/transcoding/MTP.
Sent from my iPhone
> On May 12, 2017, at 2:00 PM, Ryan Huff wrote:
>
> I think that is where my lack of specificity comes into
I think that is where my lack of specificity comes into play; the NIM
conversation I thought I was participating in was an extension of a convo this
AM, regarding a T1 PRI, in which those DSP are reserved for TDM only, and not
shareable to the backplane or vice a versa.
Thanks,
Ryan
On May
TDM DSPs on the 4ks have to be on the NIM because there is no shared TDM
clocking backplane like there is on the ISRs/ISR G2.
Dspfarm stuff can use extra dsps on a NIM and the motherboard DSPs can only be
used for dspfarm tasks.
Sent from my iPhone
> On May 12, 2017, at 1:35 PM, Jose Colon
I was under the same assumption of why there was a dsp slot on the NIM. I
know I read a Cisco doc somewhere that lead me that direction.
On May 12, 2017 2:28 PM, "Ryan Huff" wrote:
> So this is interesting; I was under the impression the backplane DSP could
> not extend to
So this is interesting; I was under the impression the backplane DSP could not
extend to the NIM (and is the fundamental reason, among others, that the NIM
has its own DSP) looks like I have a new lab task :).
On May 12, 2017, at 3:09 PM, Anthony Holloway
Rashmi Patel ( rashmika.pa...@zones.com ) - 12:31 PM
Q: Does that mean conference resource will be used from NIM DSP not from
mother board DSP resources
Priority: N/A
Dolan Spitler - 12:57 PM
A: When it comes to IP services (xcoding, conferencing, MTP) The
motherboard DSP can be pooled with the
I believe that is correct and further noted that you can't share the backplane
resource farm to the NIM. The NIM needs its own farm and can be bought
pre-installed on the NIM or as a separate SKU.
Sent from my iPhone
On May 12, 2017, at 2:17 PM, Brian Meade
My understanding is any dspfarm resources such as conferencing/transcoding
use the motherboard resources while the ones on the NIM are just for the
voice ports themselves.
On Fri, May 12, 2017 at 11:51 AM, Jose Colon II wrote:
> If you will be using DSP's you will need to
If you will be using DSP's you will need to decided if you will need them
on the motherboard or on the T1 NIM. On the motherboard I believe it can
only be used for conferencing. You will need them on the NIM for
transcoding.
On May 12, 2017 6:42 AM, "Ryan Huff" wrote:
> T1
Hey Ben,
Screen capture does use the same mechanics as file sharing; and file sharing
(native) does not work over MRA.
According to PDI, the GUI Jabber code in the Windows/Mac client allows you to
manipulate the "captured" image into the chat window using the cross hair
sizing tool
Personally, I don’t read that line as that feature. IM-only screen share I
believe would imply the RDP-based live presenting instead of the in-call BFCP
stream. Screen capture should theoretically be identical to the file transfer
feature, so the fact that it doesn’t work is very strange. Can
T1 PRI commands are substantially different if that is in play.
Sent from my iPhone
On May 12, 2017, at 7:35 AM, Matthew Loraditch
>
wrote:
The vast majority of commands are the same. Netflow stuff is changed
The native screen capture in the Jabber client does not work and is not
supported over MRA (internal or WebEx Messenger IM Jabber works fine).
I believe it is actually covered by the same Expressway caveat that states
native P2P file sharing won't work over MRA. By using MFT (Managed File
The vast majority of commands are the same. Netflow stuff is changed completely
if you use that. Outside of updating interface names, most of our templates
just worked.
Matthew G. Loraditch - CCNP-Voice, CCNA-R, CCDA
Network Engineer
Direct Voice: 443.541.1518
We have a base config we use for building our 2901/11's . Will this work on the
4321 or do I have to start from scratch.
Thanks
Norm Nicholson
Telecom Analyst
City of Kitchener
(519) 741-2200 x 7000
___
cisco-voip mailing list
18 matches
Mail list logo