[cisco-voip] CMM Gone from IOS SW Downloads Page again (WAS: CMM-ACT Transcoding - DSP locked active)
Peter Slow
peter.slow at gmail.com
Thu May 14 17:45:24 EDT 2009
*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.
>>
>
More information about the cisco-voip
mailing list