i have a puzzler with this one. On Outbound dialler and especially in Progressive with seizing mode we get a high percentage of ‘General Error’ calls.
We have investigated and the calls are all being rejected on the B side and coming back with error 206, the network team have confirmed this below is a snippet…
15:19:14.655 – party_info XXXXXXXXXX.103dbc10 state change: from to
15:19:14.655 – AgnEmu: event stack empty
15:19:14.655 – G7 ringing
15:19:14.655 – call delivered @15:19:14.6556 [ISCC] Party added [ssp view]:
15:19:14.655 Int 04544 Interaction message “EventCallPartyAdded” generated
15:19:14.655 Trc 04542 EventCallPartyAdded sent to [39] (00009178 icon_sip_1_dc1_p 172.31.164.17:52564)
15:19:14.655: $-SIP:CTI:PARTY_STATE_CHANGED:980975066:0
15:19:20.584: $+SIP:CTI:PARTY_STATE_CHANGED:980975695:0
15:19:20.584 ClearContext: party XXXXXXXXXX.12875c48-11d92c10:1
15:19:20.584 +++ CIFace::Event +++
+++ Pre-event +++
Type EventReleased
Cause: IncompatibleDestination/15, Info: 0
Flags: divert=0 hook=0 postCall=0 active=1 moveAll=1 callType=1 hideOtherPi=0 InternalOther=0
— Pre-event —
+++ Released +++
– XAction: start Environment_DC1_1.102cde40-11d92c10:1
SetReleased: party Environment_DC1_1.102cde40-11d92c10:1, cause IncompatibleDestination
– party_info Environment_DC1_1.124f4720 state change: from <Connected,Dialing> to @15:19:20.5845 [0] 8.1.101.63 distribute_response: message EventReleased
AttributeEventSequenceNumber 000000003fd6003a
AttributeTimeinuSecs 584536
AttributeTimeinSecs 1470493160 (15:19:20)
AttributeExtensions [23] 00 01 01 00..
‘BusinessCall’ 1
AttributeOtherDNRole 2
AttributeOtherDN ‘XXXXXXXXXXX’
15:19:20.584: $+SIP:CTI:PARTY_STATE_CHANGED:980975696:0
15:19:20.584 – setting cntrlDN=XXXXXXXXXXX (for 1 parties)
15:19:20.584 – setting cntrlDN=XXXXXXXXXXX (for 1 parties)
15:19:20.584: SIPTS: external party released
15:19:20.584 ClearContext: party XXXXXXXXXXX.12875c48-11d92c10:1
15:19:20.584 +++ CIFace::Event +++
+++ Released +++
– XAction: start XXXXXXXXXX.12875c48-11d92c10:1
SetReleased: party XXXXXXXXXX.12875c48-11d92c10:1, cause Null
– party_info XXXXXXXXXXX.103dbc10 state change: from to
– G7 release
– TellReleased
You using MCP for AMD? If so check to be on last version, there is one with bug where it showed no me channels to dial as kept as used by SIP Server.
Upgrade both, MCP and Sipserver
and looking at more info these general errors seem to replace the amount of SIT tones we get.
Monday and Thursday we get general errors rest of week SIT tones ?!?!?! SIT tones come back at different speeds and almost immediately, general errors 6 seconds
That’s bizarre. Other than the rate at which OCS initiates dialing there should be nothing different between a call made for a predictive and progressive campaign, both send RequestMakePredictiveCall request to SIP Server, everything in the request is configuration dependent rather than dialing mode dependent. Are you sure that there aren’t some other differences between your predictive and progressive campaigns? Or have you tried the same campaign group dialing in both progressive and predictive modes with no other difference and experienced the problem only in progressive mode?
Also, you say that this happens mainly in progressive with seizing mode, but you haven’t said if it is the engaging call or customer call that fails in this way.
Cause No. 21 - call rejected [Q.850]
This cause indicates that the equipment sending this cause does not wish to accept this call. although it could have accepted the call because the equipment sending this cause is neither busy nor incompatible. This cause may also be generated by the network, indicating that the call was cleared due to a supplementary service constraint. The diagnostic field may contain additional information about the supplementary service and reason for rejection.
Hence you need to verify on the northside of the SBC why the call is rejected.
What you need to really understand here is that:
the Genesys dialer is ‘dumb’ when it comes to dialling, there is no intelligence as such embedded into it: whatever number you pass, it will try to dial it
the effective dialing takes place outside OCS/SIPS, in your case the SBC will forward the request to the PSTN
either the call attempt is successful, and then the call is connected back through the dialing chain, or there is a failure
if there is a failure in connecting a number, the PSTN returns an error code, which is mapped first into SIP (if you use SIP trunking / SIPS) and then into an OCS call results
there is some tweaking you can do on remapping telephony codes into OCS call results, but in essence SIP 4xx / 5xx have been mapped by default into General Error by Genesys
if you think that anumber exists / is valid / call should have put through rather than rejected, you need to investigate upstream the SBC.
