Fax outdial retries consume all voice channels on SIP 484 error (Cisco 2911)
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 !
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
[toc:faq]CUCM Database Replication is an area in which Cisco customers
and partners have asked for more in-depth training in being able to
properly assess a replication problem and potentially resolve an issue
without involving TAC. This document discusse...