[cisco-voip] CMM-ACT Transcoding - DSP locked active

Peter Slow peter.slow at gmail.com
Thu May 14 12:33:55 EDT 2009


you mean it will use either? CCM wont allocate an MTP when it needs a
transcoder, but it can certainly allocate a transcoder when it
requires an MTP.

-Peter

On Thu, May 14, 2009 at 11:03 AM, Shaw, Scott
<Scott.Shaw at alliancebernstein.com> wrote:
> Are you using MTP resources as well?  I noticed that when Transcoders and
> MTPs are in the same MRG, and you need an MTP it will use both a Transcoding
> resource and an MTP resource.
> ________________________________
> From: cisco-voip-bounces at puck.nether.net
> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Matthew Linsemier
> Sent: Thursday, May 14, 2009 9:59 AM
> To: cisco-voip at puck.nether.net
> Subject: [cisco-voip] CMM-ACT Transcoding - DSP locked active
>
> Hey all,
>
> I’m running into a weird issue. I have two CMM-ACT modules configured
> identically across two 6509 switches registered to two UCM 7.0.2.21010-2
> servers (latest ES, pub and sub).  All of the needed items are configured
> (Media Groups, Media Group Lists, etc.).  For some reason on the second
> CMM-ACT, the xcoder seems to be full of connections, even though I shut down
> both the profile as well as SCCP.  Users will get a fast busy if the profile
> is in no shutdown mode and SCCP is enabled (even though there are free
> resources on the other xcoder CMM-ACT).
>
> n-eln1-vgw-02#sh mediacard connections
> Id  Type  Slot/  RPort SPort RxPkts TxPkts Remote-Ip
>           DSP/Ch
> 1   xcode 2/1/1  0     0     0      0      0.0.0.0
> 2   xcode 2/1/2  0     0     0      0      0.0.0.0
> 3   xcode 2/1/3  0     0     0      0      0.0.0.0
> 4   xcode 2/1/4  0     0     0      0      0.0.0.0
> 5   xcode 2/1/5  0     0     0      0      0.0.0.0
> 6   xcode 2/1/6  0     0     0      0      0.0.0.0
> 7   xcode 2/1/7  0     0     0      0      0.0.0.0
> 8   xcode 2/1/8  0     0     0      0      0.0.0.0
> 9   xcode 2/1/9  0     0     0      0      0.0.0.0
> 10  xcode 2/1/10 0     0     0      0      0.0.0.0
> 11  xcode 2/1/11 0     0     0      0      0.0.0.0
> 12  xcode 2/1/12 0     0     0      0      0.0.0.0
> 14  xcode 2/1/14 0     0     0      0      0.0.0.0
> 13  xcode 2/1/13 0     0     0      0      0.0.0.0
> 15  xcode 2/1/15 0     0     0      0      0.0.0.0
> 16  xcode 2/1/16 0     0     0      0      0.0.0.0
> 17  xcode 2/1/17 0     0     0      0      0.0.0.0
> 18  xcode 2/1/18 0     0     0      0      0.0.0.0
> 19  xcode 2/1/19 0     0     0      0      0.0.0.0
> 21  xcode 2/1/21 0     0     0      0      0.0.0.0
> 20  xcode 2/1/20 0     0     0      0      0.0.0.0
> 22  xcode 2/1/22 0     0     0      0      0.0.0.0
> 23  xcode 2/1/23 0     0     0      0      0.0.0.0
> 24  xcode 2/1/24 0     0     0      0      0.0.0.0
> 25  xcode 2/1/25 0     0     0      0      0.0.0.0
> 26  xcode 2/1/26 0     0     0      0      0.0.0.0
> 27  xcode 2/1/27 0     0     0      0      0.0.0.0
> 28  xcode 2/1/28 0     0     0      0      0.0.0.0
> 29  xcode 2/1/29 0     0     0      0      0.0.0.0
> 30  xcode 2/1/30 0     0     0      0      0.0.0.0
> 31  xcode 2/1/31 0     0     0      0      0.0.0.0
> 32  xcode 2/1/32 0     0     0      0      0.0.0.0
> Total: 32
>
> We’ve never had much trouble with these before so I am trying to determine
> if its a IOS issue (we are running 12.4(15)T9 or a new issue with the newer
> UCM ES.  I suspect that if I restart the CMM, that the problem may resolve
> itself.  The other DSP’s registered with CallManager (conference and MTP)
> work just fine.  The question is when will it crop up again.
>
> I would prefer to run 12.4(25)MD on the voice gateways, but there seems to
> be a bug with g729 phones placing calls as all you get is dead air.
>  Downgrading to 12.4(22) or 12.4(15)T9 fixes that issue.
>
> Anyone seen anything like this before.
>
> Matt
>
> ________________________________
>
> CONFIDENTIALITY STATEMENT
> This communication and any attachments are CONFIDENTIAL and may be protected
> by one or more legal privileges. It is intended solely for the use of the
> addressee identified above. If you are not the intended recipient, any use,
> disclosure, copying or distribution of this communication is UNAUTHORIZED.
> Neither this information block, the typed name of the sender, nor anything
> else in this message is intended to constitute an electronic signature
> unless a specific statement to the contrary is included in this message. If
> you have received this communication in error, please immediately contact me
> and delete this communication from your computer. Thank you.
>
> ________________________________
>
> -----------------------------------------------------------------------------------
> The information contained in the linked e-mail transmission and any
> attachments may be privileged and confidential and is intended only for
> the use of the person(s) named in the linked e-mail transmission. If you
> are not the intended recipient, or an employee or agent responsible for
> delivering this message to the intended recipient, you should not
> review, disseminate, distribute or duplicate this e-mail transmission or
> any attachments. If you are not the intended recipient, please contact
> the sender immediately by reply e-mail and destroy all copies of the
> original message. We do not accept account orders and/or instructions
> related to AllianceBernstein products or services by e-mail, and
> therefore will not be responsible for carrying out such orders and/or
> instructions. The linked e-mail transmission and any attachments are
> provided for informational purposes only and should not be construed in
> any manner as any solicitation or offer to buy or sell any investment
> opportunities or any related financial instruments and should not be
> construed in any manner as a public offer of any investment
> opportunities or any related financial instruments.  If you, as the
> intended recipient of the linked e-mail transmission, the purpose of
> which is to inform and update our clients, prospects and consultants of
> developments relating to our services and products, would not like to
> receive further e-mail correspondence from the sender, please "reply"
> to the sender indicating your wishes.  Although we attempt to sweep
> e-mail and attachments for viruses, we will not be liable for any
> damages arising from the alteration of the contents of this linked e-mail
> transmission and any attachments by a third party or as a result of any
> virus being passed on. Please note: Trading instructions sent
> electronically to Bernstein shall not be deemed accepted until a
> representative of Bernstein acknowledges receipt electronically or by
> telephone. Comments in the linked e-mail transmission and any
> attachments are part of a larger body of investment analysis. For our
> research reports, which contain information that may be used to
> support investment decisions, and disclosures, see our website at
> www.bernsteinresearch.com.
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>


More information about the cisco-voip mailing list