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

Thu May 14 17:51:00 EDT 2009

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=268438000&mdfLevel=Model&treeName=Routers&modelName=Cisco%20Catalyst%206509%20Switch&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
>