call rejected ## solved ##

[Tambo]

Hi All,

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 <Null> to <Alerting>
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 <Null>
@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 <Alerting> to <Null>
    -- G7 release
    -- TellReleased
             
                SIP/2.0 403 Forbidden
              Reason: X.int ;reasoncode=0x00000206;add-info=01CA.FFFE.0000
Reason: Q.850 ;cause=21


the thing is that these all come back rejected after 6 seconds  !!!!!

has anyone seen anything like this? we cant find a reason for the constant 6 seconds.

[Kubig]

Try to post entire log of TServer. In general, similiar issues are caused by Gateway or PSTN according to my experience.

[cavagnaro]

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

Enviado de meu E6633 usando Tapatalk

[Tambo]

yes, MCP

ok will check that out.

one other thing, if we dial in predictive mode we don't get the issue

[cavagnaro]

Ermmm
Then may not be the case...
Sizing mode is ASM?


Enviado de meu E6633 usando Tapatalk

[Tambo]

yes

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

[cavagnaro]

Check also your Media Gateway.
I do remember SIPServer RN about ASM mode, so better check you are running last version of all solution including OCS.

[caractacus]

[quote author=Tambo link=topic=9825.msg44559#msg44559 date=1473081288]
yes, MCP

ok will check that out.

one other thing, if we dial in predictive mode we don't get the issue
[/quote]


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.

[Grand_Master]

What is OCS log showing?  Usually it has the most info regarding call failure.

[Tambo]

yes OCS shows

RequestMakePredictiveCall
EventDialing
EventNetworkReached
EventReleased

nothing inbetween
no RequestRouteCall
no EventEstablished

yes progressive mode gets the most errors, predictive hardly any.

but.............we only get this issue on a Monday and a Thursday when new data is put in.

getting team to check for errors or formats of the data.

[cavagnaro]

Did you check RN?
For me is the ASM not freeing resources, therefore won't dial

[hsujdik]

[quote author=cavagnaro link=topic=9825.msg44573#msg44573 date=1473179192]
Did you check RN?
For me is the ASM not freeing resources, therefore won't dial
[/quote]
The one time it happened to me, I disabled/re-enabled the Trunk Group and got it dialing again. And then, upgraded SIP Server / OCS

[Tambo]

i've done the trunks and will see what happens

a MCP bounce will be next after this i think

logged with G but nothing back yet

[Tambo]

Genesys replied............

OCS and SIP working as designed, logs clearly show SBC returning 403 forbidden

Got SBC guys checking on debug
Got data guys checking calling list data

?!?!?!?

[Fra]

[quote author=Tambo link=topic=9825.msg44585#msg44585 date=1473328186]
Genesys replied............

OCS and SIP working as designed, logs clearly show SBC returning 403 forbidden

Got SBC guys checking on debug
Got data guys checking calling list data

?!?!?!?
[/quote]

I agree with Genesys.
You can clearly see that your SIPS received from the SBC:

SIP/2.0 403 Forbidden
Reason: X.int ;reasoncode=0x00000206;add-info=01CA.FFFE.0000
Reason: Q.850 ;cause=21

ISDN Q.850 cause 21 is detailed as such:

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.

Fra