Is anyone running this on a 2504? I can't find the appropriately named file for that platform in the file repository.
Yes, you need the 5500 image - both 2500 and 5500 use the same image file.
... View more
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?
... 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 = 18.104.22.168 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
Thanks, that fixed it I've now got a different issue with the IAD tearing the call down when it's put on hold on the SIP side with Q.850 release cause 172 and a '%HPI-3-FAILED_START: channel:1/0:15 DSP ID:0x2, failed mode 1 for service 27' log - we have a Music On Hold server that only does G.711, so it seems to be an issue switching codecs during the call. I'll create a separate thread for this though...
... View more
Hi all, I have a couple of IAD 243x (specifically IAD2431 and IAD2432) running IOS 15.1(4)M5 that I'm using as SIP to E1 PRI ISDN gateways. They're configured with one POTS dial-peer for the ISDN and a couple of VoIP dial-peers depending on the incoming called number from the ISDN. This has been working fine with G.711 A-law end-to-end, but now I'm trying to get it to work with iLBC and having problems. My dial-peer configuration looks like this: dial-peer voice 1 pots description Peer for ISDN30 translation-profile incoming inbound-from-bt service session destination-pattern .T progress_ind alert strip 8 no digit-strip direct-inward-dial port 1/0:15 forward-digits all ! dial-peer voice 3 voip tone ringback alert-no-PI description Peer for bearer number huntstop service session destination-pattern 01234567890 rtp payload-type nte-tone 102 rtp payload-type comfort-noise 13 session protocol sipv2 session target ipv4:22.214.171.124:5060 voice-class codec 1 dtmf-relay rtp-nte digit-drop ip qos dscp cs3 signaling clid network-provided clid substitute name ! dial-peer voice 65008 voip tone ringback alert-no-PI description Peer for main range huntstop service session destination-pattern 01234567[1-8]. rtp payload-type nte-tone 102 rtp payload-type comfort-noise 13 session protocol sipv2 session target ipv4:126.96.36.199:5060 voice-class codec 1 dtmf-relay rtp-nte digit-drop ip qos dscp cs3 signaling clid network-provided clid substitute name Other relevant config: voice rtp send-recv ! voice service pots rtcp keepalive ! voice service voip ip address trusted list ipv4 188.8.131.52 rtcp keepalive dtmf-interworking standard fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711alaw sip transport switch udp tcp no anat block 183 sdp present ! voice class codec 1 codec preference 1 ilbc mode 30 codec preference 2 g729r8 codec preference 3 g711alaw ! Now, when I place a call from ISDN through the gateway, the SDP it offers to my SBC is: v=0 o=CiscoSystemsSIP-GW-UserAgent 7963 1810 IN IP4 184.108.40.206 s=SIP Call c=IN IP4 220.127.116.11 t=0 0 m=audio 18710 RTP/AVP 116 18 8 101 13 c=IN IP4 18.104.22.168 a=rtpmap:116 iLBC/8000 a=fmtp:116 mode=30 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000 This is great - both ends agree iLBC and the call comes up. However, if I make a call from the SIP side through to the ISDN, I offer this: v=0 o=- 78207127932020 78207127932020 IN IP4 22.214.171.124 s=- c=IN IP4 126.96.36.199 t=0 0 m=audio 24132 RTP/AVP 110 8 127 a=rtpmap:110 iLBC/8000 a=rtpmap:127 telephone-event/8000 a=fmtp:110 mode=30 a=silenceSupp:on - - - - a=ptime:20 It then gives me a 200 OK with this: v=0 o=CiscoSystemsSIP-GW-UserAgent 9977 8349 IN IP4 188.8.131.52 s=SIP Call c=IN IP4 184.108.40.206 t=0 0 m=audio 17650 RTP/AVP 8 127 c=IN IP4 220.127.116.11 a=rtpmap:8 PCMA/8000 a=rtpmap:127 telephone-event/8000 a=fmtp:127 0-16 a=ptime:20 This means we use G.711 A-Law. If I remove this from the offer and just propose iLBC, the IAD rejects the call request. Clearly it supports calls using G.711 over the ISDN and iLBC on the SIP side - how do I persuade it to allow calls initiated from the SIP side to work as well as calls initiated from the ISDN side? Many thanks in advance for any suggestions! Sean
... View more
Suspect it's not worth paying for SMARTnet just to get this one fix Shame it's not public! Don't suppose they gave you any idea when the next release incorporating the fix will be released?
... View more
I think we have the same issue. If you go to Administration > Background Tasks, do the Client Status tasks in the Other Background Tasks list show status Failure? If you click on them, do they indicate a Java NullPointerException? Assuming so, it sounds like it's a bug...
... View more