[cisco-voip] CMM-ACT Transcoding - DSP locked active
Peter Slow
peter.slow at gmail.com
Thu May 14 17:27:58 EDT 2009
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