Hi all, We are doing T.37 fax on 2811 and 2911 routers, with calls coming in over two T1 links.  Occasionally the unit hits a bug where a call gets stuck and the CPU gradually rises up to near 100 over about 45 minutes.  It stays close to 100%, almost all in the DocMSP process, with the unit rejecting all incoming calls until something tears down the stuck call when everything returns to normal. Cisco TAC have been unable to identify or fix the bug, so we have implemented an EEM script to detect the high CPU and bounce the two T1 links.  Here is the script, triggered on the call rejection logs: event manager applet high_cpu_recovery  event syslog pattern "IVR-3-LOW_CPU_RESOURCE"  action 1.0 syslog msg "----HIGH CPU DETECTED, BOUNCING T1s----"  action 2.0 cli command "enable"  action 3.0 cli command "show clock | append flash:high_cpu_recovery.txt"  action 4.0 cli command "show call active fax brief | append flash:high_cpu_recovery.txt"  action 5.0 cli command "config t"  action 5.1 cli command "controller t1 1/0"  action 5.2 cli command "shutdown"  action 5.3 cli command "controller t1 1/1"  action 5.4 cli command "shutdown"  action 5.5 cli command "controller t1 1/0"  action 5.6 cli command "no shutdown"  action 5.7 cli command "controller t1 1/1"  action 5.8 cli command "no shutdown"  action 5.9 cli command "end" The script seems to work fine functionally (tested by having it trigger off a user-defined log event instead of the high CPU event), but it seems that when the CPU is very high the script definitely gets triggered but often just doesn't seem to run.  30 minutes or an hour later, it still hasn't bounced the T1 links. We have the following config line attempting to give more priority to the EEM script, but it doesn't seem to be helping much: scheduler allocate 40000 5000 I have also seen mention of a 'scheduler interval' command to allow time for low-priority processes, but that doesn't seem to be available on this platform. Any suggestions for other ways to give more priority to the EEM script, or better values for the 'scheduler allocate' command?  Thanks, Ollie ... View more

I've been seeing a nasty fax/VoIP problem on a 2911, running  IOS 15.0(1r)M12.  Any suggestions would be welcome.   I have a 2911 which is set up to do T.37 offramp fax delivery (SMTP message is sent to 2911, which places a VoIP call over SIP/RTP/T.38 to deliver the fax).  The mainline case is set up, and working correctly - faxes are delivered without issue.  If a destination address is selected such that the VoIP switch returns a SIP 484 error, then everything fails in a spectacular fashion: The outdial is immediately retried, placing another SIP INVITE to the switch, with the same destination address, which obviously also gets the same 484 response. Each time the outdial takes place, it consumes voice channels on the DSP, which are not released on receipt of the 484. When there are no free voice channels, a no circuit (0x22) error is returned, and all the voice channels are finally released. The MTA that submitted the SMTP message retries every minute (it doesn't get a permanent failure report when the 2911 fails to place the call)   This leads to a situation where no fax calls can be placed, as all the voice channels are being used up by retrying this call that can never succeed.   Some other relevant information: The VoIP switch does not return a 484 immediately.  First it sends a SIP 183, and plays early media (an announcement about how the call isn't allowed). It takes 8 seconds before the 484 is returned.  The 2911 sends a new SIP INVITE every 8 seconds (as soon as it gets a 484 for the previous attempt). The "sip-ua" statistics show that the INVITE retry counter is not  being incremented (i.e. this is not a retry at the scope of the SIP stack). The T1 cable is looped-back to the 2911, so that the complete path for fax delivery looks like this:     MTA ---SMTP---> 2911 ---T1---> 2911 ---SIP---> VoIP switch If I set "mta receive generate permanent-error", then I still see this retry behaviour, with all the voice channels being consumed.  Once that has happened (after about 3 minutes) the MTA does get the error response, and no longer retries every minute after that (although this setting has other negative effects that I'd like to avoid).   Does anyone have any idea how I can get the 2911 to return a permanent failure to the MTA after just a single outdial has failed with a SIP 484?   Here is the dial-peer config: ! dial-peer voice 1 voip  translation-profile incoming IncomingVoip  incoming called-number .  voice-class codec 1  dtmf-relay rtp-nte  fax protocol t38 version 0 ls-redundancy 3 hs-redundancy 0 fallback pass-through g711ulaw  no vad ! dial-peer voice 2 pots  destination-pattern ^0005  port 1/1:23  forward-digits all ! dial-peer voice 3 pots  translation-profile incoming IncomingPRI_1_0  service onramp-app  incoming called-number ^0005  direct-inward-dial  port 1/0:23 ! dial-peer voice 4 mmoip  service fax_on_vfc_onramp_app out-bound  destination-pattern .  information-type fax  session target mailto:$m$@<DOMAIN NAME>  image encoding MH ! dial-peer voice 101 mmoip  translation-profile incoming IncomingMMoIP  service offramp-app  information-type fax  incoming called-number . ! dial-peer voice 102 pots  destination-pattern .  port 1/0:23  forward-digits all ! dial-peer voice 103 pots  translation-profile incoming IncomingPRI_1_1  incoming called-number ^0007  direct-inward-dial  port 1/1:23 ! dial-peer voice 104 voip  translation-profile outgoing OutgoingVoip  destination-pattern ^0008  session protocol sipv2  session target ipv4:<VoIP SWITCH IP ADDRESS>  voice-class codec 1  dtmf-relay rtp-nte  fax protocol t38 version 0 ls-redundancy 3 hs-redundancy 0 fallback pass-through g711ulaw  no vad !     ... View more

I have an IAD 2431 acting as a SIP<>ISDN gateway. I've got it set up so that SIP<>ISDN calls use iLBC on the VoIP side; however, when the VoIP side puts the call on hold, connecting it to our (G.711-only) Music On Hold server, the IAD tears the call down. I've turned on 'debug ccsip media' and grabbed the following log output: Oct 24 11:32:11.750: //1326/44A678F2800B/SIP/Media/ccsip_api_request_offer: Call has been put on hold Oct 24 11:32:11.758: %HPI-3-FAILED_START: channel:1/0:15 DSP ID:0x2, failed mode 1 for service 27 -Traceback= 62AA72D4z 6202D9B4z 6202DEECz 62A8ACD4z 62A8B1ECz 607A1634z 607A1618z Oct 24 11:32:11.826: //1326/44A678F2800B/SIP/Media/sipSPISetMediaSrcAddr: Media src addr for stream 1 = 1.2.3.4 Oct 24 11:32:11.826: //1326/44A678F2800B/SIP/Media/sipSPIDoPtimeNegotiation: Offered ptime:20, Negotiated ptime:20            Negotiated codec bytes: 160 for codec g711alaw Oct 24 11:32:11.826: //1326/44A678F2800B/SIP/Media/sipSPICompareStreams: stream 1 dest_port: old=27584 new=27584 Oct 24 11:32:11.826: //1326/44A678F2800B/SIP/Media/sipSPIGetNewLocalMediaDirection:         New Remote Media Direction = SENDRECV         Present Local Media Direction = RECVONLY         New Local Media Direction = SENDRECV         retVal = 1 Oct 24 11:32:11.830: //1326/44A678F2800B/SIP/Media/sipSPIUpdateRtpSession: stun is disabled for stream:68F81370 Oct 24 11:32:11.830: //1326/44A678F2800B/SIP/Media/sipSPIUpdateRtpSession: stun is disabled for stream:68F81370 Oct 24 11:32:11.830: //1326/44A678F2800B/SIP/Media/sipSPICompareConnectionAddress: Call hold deactivated for stream            1 Oct 24 11:32:11.830: //1326/44A678F2800B/SIP/Media/sipSPICompareStreams: negotiated codec changed from ilbc to g711           alaw Oct 24 11:32:11.830: //1326/44A678F2800B/SIP/Media/sipSPICompareStreams: Flags set for stream 1: RTP_CHANGE=Yes CAP           S_CHANGE=Yes RSVP_ADDR_CHANGE=No RSVP_MEDIA_CHANGE=Yes Oct 24 11:32:11.830: //1326/44A678F2800B/SIP/Media/sipSPICompareSDP: Flags set for call: NEW_MEDIA=Yes DSPDNLD_REQD           =Yes IPIP_MEDIA=Yes Oct 24 11:32:11.830: //1326/44A678F2800B/SIP/Media/sipSPIRSVPCompareSDP: Media Codec Change Identified Oct 24 11:32:11.830: //1326/44A678F2800B/SIP/Media/sipSPIRSVPCompareSDP: Media Offer Changed Oct 24 11:32:11.830: //1326/44A678F2800B/SIP/Media/sipSPIReplaceSDP: Main stream got changed & it's Flow Around Oct 24 11:32:11.830: //1326/44A678F2800B/SIP/Media/sipSPIGetNewLocalMediaDirection:         New Remote Media Direction = SENDRECV         Present Local Media Direction = SENDRECV         New Local Media Direction = SENDRECV         retVal = 0 Oct 24 11:32:11.834: //1326/44A678F2800B/SIP/Media/ccsip_api_request_offer: Call has been taken off hold Oct 24 11:32:11.834: //1326/44A678F2800B/SIP/Media/sipSPIDeleteStream: Deleting stream 1 from the VOIP RTP library Oct 24 11:32:11.834: //1326/44A678F2800B/SIP/Media/sipSPIDestroyRtpSession: stream:68E89CFC I assume it's line 2 (%HPI-3-FAILED_START) that's the problem here - does this mean I have a misconfiguration somewhere, or is this just broken? Thanks! ... View more