[cisco-voip] CMM Gone from IOS SW Downloads Page again (WAS: CMM-ACT Transcoding - DSP locked active)

Matthew Linsemier mlinsemier at apassurance.com
Thu May 14 17:58:50 EDT 2009 

Again, be careful with this release if you are doing any calls from g729
phones, as I always just get dead air.  Downgrading to 12.4(21)MD fixes the
issue though (or using 12.4(15)T9).


On 5/14/09 5:51 PM, "Erick Bergquist" <erickbee at gmail.com> wrote:

> Hmm, if you go under...
> 
>  Cisco IOS and NX-OS Software  > Cisco IOS Software Releases 12.4
> Mainline  > Cisco Catalyst 6509 Switch  > Cisco Catalyst 6500 Series
> Communication Media Module  > IOS Software
> 
> It is there, 12.4(25)MD for the CMM. Downloading the IOS now.
> 
> On Thu, May 14, 2009 at 4:45 PM, Peter Slow <peter.slow at gmail.com> wrote:
>> *sigh* - someone double check me on this.
>> 
>> Matt, How were you downloading your IOS for the CMM? I didnt recognize
>> the 12.4(25) rev you you had mentioned and wanted to check if it was
>> in fact mainline, or if MD was some particular train of code you'd
>> decided to run. I can't seem to do that, because the CMM appears to
>> have magically disappeared from the list of available platforms to
>> download IOS for. What steps are you taking to obtain software when
>> you go to download it? Perhaps I'm doing something wrong.
>> 
>> update:
>> if you look really hard, and  click    Routers  > Cisco Catalyst 6509
>> Switch, at the very very bottom of the page that comes up
>> http://tools.cisco.com/support/downloads/go/InterfaceModuleSWT.x?mdfid=268438
>> 000&mdfLevel=Model&treeName=Routers&modelName=Cisco%20Catalyst%206509%20Switc
>> h&treeMdfId=268437899
>> 
>> ...You can find a link for "Cisco Catalyst 6500 Series Communication
>> Media Module " -- However, if you search for "cmm" "communication" or
>> "media" where it lets you enter platform names, you won't get any
>> hits. This is not where it was originally located. the CMM used to be
>> at the same level of hierarchy as the 2800s, 3800s etc.
>> 
>> -Pete
>> 
>> 
>> On Thu, May 14, 2009 at 5:27 PM, Peter Slow <peter.slow at gmail.com> wrote:
>>> Ewww, somethign on your CMM is breaking in your particular call flow.
>>> This looks like a bug in the DSP firmware. SCCP knows the calls are
>>> gone, but either hasn't correctly signalled that to the DSPware or
>>> somethign else bad happened with the DSP messaging that caused the
>>> channels not to be released.
>>> 
>>> if you are determined to run the mainline code, you're going to need
>>> to open a TAC case to figure out what bug you're hitting. There are
>>> going to be a host of debugs you'll need to turn on on the CMM and
>>> once they're on, you'll need to monitor it until you see an
>>> inconsistency between the "sh sccp connection"  and the "sh mediacard
>>> conn" commands.
>>> 
>>> Doing s no sccp/sccp doesnt fix your issue because the problem isnt
>>> occurring in that layer of the IOS code. what you CAN try doing is
>>> unconfiguring the mediacard resource-pools (shoudl be near the top of
>>> your config in a show run) but that requires removal of the pool from
>>> the dspfarm profile and is kind of annoying. Might still be better
>>> than rebooting if that clears the sessions though. a reboot will
>>> certainly work, but i'd expect that you'd keep hanging sessions until
>>> you run out of channels, at which point you'd start hearing reorder
>>> again.
>>> 
>>> can you define "virtually identical configurations" a little further?
>>> 
>>> your calls are getting reorder tone because CUCM believes the ACT to
>>> have available sessions, the SCCP stack on the CMM is reporting
>>> available sessions, and so CCM thinks it's a valid resource to
>>> allocate, but upon sending the xcoder an ORC, there's most likely a
>>> failure and CCM is probably getting back an OLCAck with a status of 1
>>> since there really were _not_ resources available on the transcoder it
>>> just allocated.
>>> 
>>> -Pete
>>> 
>>> 
>>> On Thu, May 14, 2009 at 1:31 PM, Matthew Linsemier
>>> <mlinsemier at apassurance.com> wrote:
>>>> I am using transcoders for g729 (teleworkers) to g711 resources (UCCX, MPE,
>>>> etc.)...  On each of the CCM-ACT, I have one DSP allocated for xcode, 1 DSP
>>>> allocated for MTP, and 2 DSP allocated for conference.
>>>> 
>>>> To reiterate, the first CCM-ACT in the MRGL (vgw-01) works just fine.  This
>>>> is a second CCM-ACT (vgw-02) that is having the issue.  Both of them are
>>>> identical OS, identical hardware, and virtually identical configuration.
>>>> The interesting thing is, that when the xcode on vgw-02 is registered (with
>>>> all of the mediacard connections for this DSP showing active, calls ring
>>>> busy even though the first CCM-ACT in the group list has available
>>>> resources.
>>>> 
>>>> Now, even doing a no shut and doing a no sccp / sccp wont bring the DSP
>>>> back
>>>> up.  I wonder if I have some failing hardware..
>>>> 
>>>> n-eln1-vgw-02#sh sccp all
>>>> SCCP Admin State: UP
>>>> Gateway IP Address: 10.x.x.x, Port Number: 2000
>>>> IP Precedence: 5
>>>> User Masked Codec list: None
>>>> Call Manager: 10.x.x.x, Port Number: 2000
>>>>                Priority: N/A, Version: 5.0.1, Identifier: 1
>>>> Call Manager: 10.x.x.x, Port Number: 2000
>>>>                Priority: N/A, Version: 5.0.1, Identifier: 2
>>>> 
>>>> Conferencing Oper State: ACTIVE - Cause Code: NONE
>>>> Active Call Manager: 10.x.x.x, Port Number: 2000
>>>> TCP Link Status: CONNECTED, Profile Identifier: 1
>>>> Reported Max Streams: 64, Reported Max OOS Streams: 0
>>>> Supported Codec: pass-thru, Maximum Packetization Period: N/A
>>>> Supported Codec: g711ulaw, Maximum Packetization Period: 30
>>>> Supported Codec: g711alaw, Maximum Packetization Period: 30
>>>> Supported Codec: g729r8, Maximum Packetization Period: 30
>>>> Supported Codec: g729br8, Maximum Packetization Period: 30
>>>> Supported Codec: g729ar8, Maximum Packetization Period: 30
>>>> Supported Codec: g729abr8, Maximum Packetization Period: 30
>>>> Supported Codec: g723_6.3, Maximum Packetization Period: 30
>>>> Supported Codec: g723_5.3, Maximum Packetization Period: 30
>>>> Supported Codec: rfc2833 dtmf, Maximum Packetization Period: 30
>>>> Supported Codec: rfc2833 pass-thru, Maximum Packetization Period: 30
>>>> 
>>>> MTP Oper State: ACTIVE - Cause Code: NONE
>>>> Active Call Manager: 10.x.x.x, Port Number: 2000
>>>> TCP Link Status: CONNECTED, Profile Identifier: 3
>>>> Reported Max Streams: 128, Reported Max OOS Streams: 0
>>>> Supported Codec: pass-thru, Maximum Packetization Period: N/A
>>>> Supported Codec: g711ulaw, Maximum Packetization Period: 30
>>>> Supported Codec: g711alaw, Maximum Packetization Period: 30
>>>> Supported Codec: rfc2833 dtmf, Maximum Packetization Period: 30
>>>> Supported Codec: rfc2833 pass-thru, Maximum Packetization Period: 30
>>>> 
>>>> 
>>>> SCCP Application Service(s) Statistics:
>>>> 
>>>> Profile Identifier: 1, Service Type: Conferencing
>>>> TCP packets rx 4, tx 6
>>>> Unsupported pkts rx 0, Unrecognized pkts rx 0
>>>> Register tx 1, successful 1, rejected 0, failed 0
>>>> KeepAlive tx 1, successful 1, failed 0
>>>> OpenReceiveChannel rx 0, successful 0, failed 0
>>>> CloseReceiveChannel rx 0, successful 0, failed 0
>>>> StartMediaTransmission rx 0, successful 0, failed 0
>>>> StopMediaTransmission rx 0, successful 0, failed 0
>>>> PortReq rx 0
>>>> PortRes tx 0, successful 0, failed 0
>>>> PortClose rx 0
>>>> QosListen rx 0
>>>> QosPath rx 0
>>>> QosTeardown rx 0, send 0, recv 0, sendrecv 0
>>>> QosResvNotify tx 0, send 0, recv 0, sendrecv 0
>>>> QosErrorNotify tx 0, send 0, recv 0, sendrecv 0
>>>>   err0 0, err1 0, err2 0, err3 0, err4 0, err5 0,
>>>>   err6 0, err7 0, err8 0, err9 0, err10 0, err11 0,
>>>>   err12 0
>>>> QosModify rx 0, send 0, recv 0, sendrecv 0
>>>> UpdateDscp rx 0
>>>> Reset rx 0, successful 0, failed 0
>>>> MediaStreamingFailure rx 0
>>>> MediaStreamingFailure tx 0
>>>> Switchover 0, Switchback 0
>>>> 
>>>> 
>>>> Profile Identifier: 3, Service Type: MTP
>>>> TCP packets rx 5, tx 7
>>>> Unsupported pkts rx 0, Unrecognized pkts rx 0
>>>> Register tx 1, successful 1, rejected 0, failed 0
>>>> KeepAlive tx 2, successful 2, failed 0
>>>> OpenReceiveChannel rx 0, successful 0, failed 0
>>>> CloseReceiveChannel rx 0, successful 0, failed 0
>>>> StartMediaTransmission rx 0, successful 0, failed 0
>>>> StopMediaTransmission rx 0, successful 0, failed 0
>>>> PortReq rx 0
>>>> PortRes tx 0, successful 0, failed 0
>>>> PortClose rx 0
>>>> QosListen rx 0
>>>> QosPath rx 0
>>>> QosTeardown rx 0, send 0, recv 0, sendrecv 0
>>>> QosResvNotify tx 0, send 0, recv 0, sendrecv 0
>>>> QosErrorNotify tx 0, send 0, recv 0, sendrecv 0
>>>>   err0 0, err1 0, err2 0, err3 0, err4 0, err5 0,
>>>>   err6 0, err7 0, err8 0, err9 0, err10 0, err11 0,
>>>>   err12 0
>>>> QosModify rx 0, send 0, recv 0, sendrecv 0
>>>> UpdateDscp rx 0
>>>> Reset rx 0, successful 0, failed 0
>>>> MediaStreamingFailure rx 0
>>>> MediaStreamingFailure tx 0
>>>> Switchover 0, Switchback 0
>>>> 
>>>> CCM Group Identifier: 1
>>>>  Description: None
>>>>  Binded Interface: GigabitEthernet1/0, IP Address: 10.1.1.228
>>>>  Associated CCM Id: 2, Priority in this CCM Group: 1
>>>>  Associated CCM Id: 1, Priority in this CCM Group: 2
>>>>  Associated Profile: 3, Registration Name: MTP_HW_VGW-02
>>>>  Associated Profile: 2, Registration Name: M040015636e56e4
>>>>  Associated Profile: 1, Registration Name: C030015636e56e4
>>>>  Registration Retries: 3, Registration Timeout: 10 sec
>>>>  Keepalive Retries: 3, Keepalive Timeout: 30 sec
>>>>  CCM Connect Retries: 3, CCM Connect Interval: 10 sec
>>>>  Switchover Method: GRACEFUL, Switchback Method: GRACEFUL_GUARD
>>>>  Switchback Interval: 10 sec, Switchback Timeout: 7200 sec
>>>>  Signaling DSCP value: cs3, Audio DSCP value: ef
>>>> 
>>>> 
>>>> Total number of active session(s) 0, and connection(s) 0
>>>> 
>>>> 
>>>> Total number of active session(s) 0, and connection(s) 0
>>>> 
>>>> SCCP Application Service(s) Statistics Summary:
>>>> Total Conferencing Sessions: 0, Connections: 0
>>>> Total Transcoding Sessions: 0, Connections: 0
>>>> Total MTP Sessions: 0, Connections: 0
>>>> Total ALG-Phone Sessions: 0, Connections: 0
>>>> Total BRI-Phone Sessions: 0, Connections: 0
>>>> Total SCCP Sessions: 0, Connections: 0
>>>> 
>>>> 
>>>> On 5/14/09 11:21 AM, "Peter Slow" <peter.slow at gmail.com> wrote:
>>>> 
>>>>> Matt, would you please post a "sh sccp all" for us - i'd like to see
>>>>> what connections that says the sccp stack expects to be open (or
>>>>> half-open ;)
>>>>> what sort of scenario are you usign your transcoder is, coudl you tell
>>>>> us? is it being for a SIP trunk vs. h323 and so on...
>>>>> 
>>>>> On Thu, May 14, 2009 at 9:58 AM, Matthew Linsemier
>>>>> <mlinsemier at apassurance.com> wrote:
>>>>>> 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.
>>>>>> 
>>>>>> ________________________________
>>>>>> 
>>>>>> _______________________________________________
>>>>>> cisco-voip mailing list
>>>>>> cisco-voip at puck.nether.net
>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>> 
>>>>>> 
>>>> 
>>>> 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.
>>>> 
>>> 
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>> 

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.

More information about the cisco-voip mailing list