Results 1 to 6 of 6

Thread: Outbound call routing rule has stopped working

  1. #1

    Exclamation Outbound call routing rule has stopped working

    Hi,

    We are experincing a problem with our quadro 4x4 with outgoing mobile calls.

    Our current setup is that all mobile calls go out via sip line (pennytel) and then failover to PSTN if unavailable or busy.

    We have just discovered that for the last 4 days all calls have been failing and going out via PSTN (which has resulted in over 2 hours of mobile calls going to Telstra at very great expense).

    I have checked the call control and it seems that the quadro is not matching the first rule anymore and going straight to failover. The SIP registration is current and there are no problems with the SIP line.

    The rules are configured like this:

    Main Rule 04???????? Metric 10 - IP -PSTN via UES 96 (which is SIP line to Pennytel) Any Failover

    Failover Rule is 04???????? Metric 20 - FXO with no failover.

    Call control showed the following when both rules were in place to number 0404866658


    CM: .157 * <- * OnAdvFxsCallMake: line #15[0](e:27), dialed number - 0404866658, callID - 5331735584794866865, media - [<D>187.226.0.193:55190, PT:20, a: pcmu(0), pcma(8), g722(9), (G726-32)(2), gsm(3), g729(18), g723(4), telephone-event(101)(fmtp:0-16)].
    CM: .158 ATS: line #15(e:27) - OffHookWaiting.
    CM: .158 TS: line #15[0](e:27) - OffHookWaiting.
    CM: .159 ]-> SendTrunkStatus: line #15[0](e:27), L["Scott 27" 78745827@sip.epygi.com], R[PBX:N/A], S: "Trying", E: none, callID: 0, D: none.
    CM: .288 GetCR: [PBX/27|0404866658]-><04????????>->FXO/18310404866658<1>.
    CM: .288 TS: line #15[0](e:27) - OffHookDialComplete.
    CM: .290 * -> * MakeRoutingFXOCall: line #15[0](e:27), calling to number 18310404866658, number of records - 1.
    CM: .290 QueryOutgoingService: e:27, contact: any, FXO destination: 18310404866658.
    CM: .291 AddFXOCall: line #15, callID - 71531220026289559.
    CM: .301 FillFXOChannelList: line #15[0], channels - [1], callID - 71531220026289559.
    CM: .312 * -> * MakeOutgoingFXOCall: line #15[0](e:27), target number - 18310404866658, callID - 71531220026289559.
    CM: .315 * -> * MakeOutgoingFXOCall: line #15[0](e:27), caller info:
    CM: UN - 27
    CM: ID - N/A
    CM: DN - Scott 27
    CM: HA - sip.epygi.com
    CM: HP - 5060
    CM: PS - 80B63CB1B4A324C0D107514C1AADD6BD4F1688640CBFA5A6C9 46
    CM: SD - [NP#0:60]
    CM: DD - N/A
    CM: .317 SetTimer: line #15[0], type - FaintHopeHypnosis, interval - 10 sec, callID - 71531220026289559.
    CM: 08:57:11.039 OnFXOCallRinging: line #15[0](e:27), callID - 71531220026289559.
    CM: .040 TS: line #15[0](e:27) - OffHookRinging.
    CM: .041 ]-> SendTrunkStatus: line #15[0](e:27), L["Scott 27" 78745827@sip.epygi.com], R[PSTN:18310404866658], S: "Proceeding", E: none, callID: 71531220026289559, D: initiator.
    CM: .043 KillTimer: line #15[0], type - FaintHopeHypnosis, callID - 0.
    CM: .044 RingingAdvFxsFXOCall: line #15[0](e:27), callID - 71531220026289559[5331735584794866865], media - [N/A].
    CM: .047 OnFXOCallAccept(OffHookRinging|None): line #15[0](e:27), callID - 71531220026289559.
    CM: .048 AttachOutgoingFXOCall: line #15[0](e:27), granted endpoint - {MG0}<1>, callID - 71531220026289559.
    CM: .048 GetCoinsideInterfaces: {MG22}[187.226.0.193] <-> {MG0}[187.226.0.51].
    CM: .051 BeginMediaSession: {MG22} - [71531220026289559]<71531220026289559>.
    CM: .058 RequestMgResource: {MG22}[L:187.226.0.193, R:187.226.0.51], line #15[0], OutMakePstnRtpBridge, media - [<D>187.226.0.193:0, a: g729(18)(PT:20), telephone-event(101)(PT:20)(fmtp:0-16)], NM:1, NP:1, ND:1, callID - 71531220026289559.
    CM: .059 InsertEndpoint: {MG22}<RTP/1001>[187.226.0.193:55190] - 71531220026289559.
    CM: .061 ProcessMgReply: {MG22}, line #15, OutMakePstnRtpBridge, RTP port - 55190, CAC result - OK, media - [<D>187.226.0.193:55190, a: g729(18)(PT:20), telephone-event(101)(PT:20)(fmtp:0-16)], callID - 71531220026289559.
    CM: .062 BeginMediaSession: {MG0} - [71531220026289559]<71531220026289559>.
    CM: .064 RequestMgResource: {MG0}[L:187.226.0.51, R:187.226.0.193], line #15[0], OutMakePstnRtpBridge, media - [<D>187.226.0.51:55190, a: g729(18)(PT:20), telephone-event(101)(PT:20)(fmtp:0-16)], NM:1, NP:1, ND:1, callID - 71531220026289559.
    CM: .076 InsertEndpoint: {MG0}<RTP/1001>[187.226.0.51:6032] - 71531220026289559.
    CM: .078 ProcessMgReply: {MG0}, line #15, OutMakePstnRtpBridge, RTP port - 6032, CAC result - OK, media - [<D>187.226.0.51:55190, a: g729(18)(PT:20), telephone-event(101)(PT:20)(fmtp:0-16)], callID - 71531220026289559.
    CM: .079 TS: line #15[0](e:27) - OffHookInCall.
    CM: .080 ]-> SendTrunkStatus: line #15[0](e:27), L["Scott 27" 78745827@sip.epygi.com], R[PSTN:18310404866658], S: "Confirmed", E: none, callID: 71531220026289559, D: initiator.
    CM: .082 StartCallDetailLog: line #15[0](e:27), caller party, callID - 71531220026289559.
    CM: .082 EndTone: line #15(e:27), tone - None.
    CM: .084 AcceptAdvFxsFXOCall(InAcceptExtCall): line #15[0](e:27), callID - 71531220026289559[5331735584794866865], media - [<D>187.226.0.51:6032, PT:20, a: g729(18), telephone-event(101)(fmtp:0-16)].
    CM: .376 OnAdvFxsFXOCallDone(InAcceptExtCall): line #15[0](e:27), callID - 71531220026289559[5331735584794866865], media - [N/A].
    CM: .377 ExternalConnectionOpen: line #15[0], {MG22}71531220026289559<1>(TOS 0xB8), FXS[0] -> RTP[(187.226.0.193:55190)>187.226.0.51:6032>, a: G729a(18)(PT:20)].
    CM: .386 ExternalConnectionOpen: line #15[0], {MG0}71531220026289559<1>(TOS 0xB8), RTP[>187.226.0.193:55190>(187.226.0.51:6032), a: G729a(18)(PT:20)] -> FXO[1].
    CM: .424 ExternalConnectionOpen: line #15[0], {MG0}71531220026289559<2>(TOS 0xB8), FXO[1] -> RTP[(187.226.0.51:6032)>187.226.0.193:55190>, a: G729a(18)(PT:20)].
    CM: .452 ExternalConnectionOpen: line #15[0], {MG22}71531220026289559<2>(TOS 0xB8), RTP[>187.226.0.51:6032>(187.226.0.193:55190), a: G729a(18)(PT:20)] -> FXS[0].
    CM: .453 ExternalCallDone: line #15[0](e:27), media - [N/A], callID - 71531220026289559.
    CM: 08:57:17.812 OnAdvFxsFXOCallClose: line #15[0](e:27), callID - 71531220026289559[5331735584794866865].
    CM: .816 ExternalCallClose: callID - 71531220026289559.
    CM: .822 ExternalConnectionClose: line #15[0], {MG22}71531220026289559<1>.
    CM: .822 ExternalConnectionClose: line #15[0], {MG22}71531220026289559<2>.
    CM: .823 ExternalConnectionClose: line #15[0], {MG0}71531220026289559<2>.
    CM: .830 ExternalConnectionClose: line #15[0], {MG0}71531220026289559<1>.
    CM: .861 ATS: line #15(e:27) - OnHookSilent.
    CM: .861 TS: line #15[0](e:27) - OnHookSilent.
    CM: .862 ]-> SendTrunkStatus: line #15[0](e:27), L["Scott 27" 78745827@sip.epygi.com], R[PSTN:18310404866658], S: "Terminated", E: local_bye, callID: 71531220026289559, D: initiator.
    CM: .863 ]-> ResetTrunkStatus: line #15(e:27).
    CM: .864 EraseFXOCall: callID - 71531220026289559.
    CM: .865 EndMediaSession: {MG22} - 71531220026289559.
    CM: .865 EraseEndpoint: {MG22}<RTP/1001>[187.226.0.193:55190] - 71531220026289559.
    CM: .866 TidyMediaStatisticRequest: MG{0}, callID - 71530678860870636, sessID - 71530678860870636, remain records - 0.
    CM: .867 EndMediaSession: RESET {MG22}.


    This showes that it matched the PSTN Failover route.

    I tried disabling the failover route and when i did the call failed as "number was not found"

    CM: 09:03:50.970 AddPBXCall: line #15, callID - 5331737311372534765.
    CM: .972 * <- * OnAdvFxsCallMake: line #15[0](e:27), dialed number - 0404866658, callID - 5331737311372534765, media - [<D>187.226.0.193:58592, PT:20, a: pcmu(0), pcma(8), g722(9), (G726-32)(2), gsm(3), g729(18), g723(4), telephone-event(101)(fmtp:0-16)].
    CM: .972 ATS: line #15(e:27) - OffHookWaiting.
    CM: .972 TS: line #15[0](e:27) - OffHookWaiting.
    CM: .973 ]-> SendTrunkStatus: line #15[0](e:27), L["Scott 27" 78745827@sip.epygi.com], R[PBX:N/A], S: "Trying", E: none, callID: 0, D: none.
    CM: 09:03:51.041 GetCR: [PBX/27|0404866658]->N/A
    CM: .041 ProcessRoutingPlan: line #15[0](e:27), no match for pattern [0404866658].
    CM: .042 TS: line #15[0](e:27) - OffHookDialComplete.
    CM: .043 ]-> SendTrunkStatus: line #15[0](e:27), L["Scott 27" 78745827@sip.epygi.com], R[PBX:N/A], S: "Trying", E: none, callID: 0, D: none.
    CM: .044 * -> * MakeRoutingPBXCall: line #15[0](e:27), calling to number , number of records - 0.
    CM: .044 MakeRoutingPBXCall: line #15[0](e:27), got error "User Not Found", end of call records.
    CM: .046 TS: line #15[0](e:27) - OffHookError.
    CM: .078 ]-> SendTrunkStatus: line #15[0](e:27), L["Scott 27" 78745827@sip.epygi.com], R[PBX:N/A], S: "Terminated", E: error, callID: 0, D: none.
    CM: .106 BeginTone: line #15[0](e:27), tone - NoSuchNumber.
    CM: .129 AddPBXCall: line #15, callID - 71532950897924672.
    CM: .131 BeginMediaSession: {MG22} - [71532950897924672]<71532950897924672>.
    CM: .133 GetCoinsideInterfaces: {MG0}[187.226.0.51] <-> {MG22}[187.226.0.193].
    CM: .134 AddPBXCall: line #15, callID - 71532950897952610.
    CM: .135 BeginMediaSession: {MG22} - [71532950897952610]<71532950897924672>.
    CM: .235 RequestMgResource: {MG22}[L:187.226.0.193, R:187.226.0.51], line #15[0], BuildAlienFxsBridge, media - [<D>187.226.0.193:0, a: g729(18)(PT:20), telephone-event(101)(PT:20)(fmtp:0-16)], NM:1, NP:1, ND:1, callID - 71532950897952610.
    CM: .236 InsertEndpoint: {MG22}<RTP/1001>[187.226.0.193:58592] - 71532950897952610.
    CM: .237 ProcessMgReply: {MG22}, line #15, BuildAlienFxsBridge, RTP port - 58592, CAC result - OK, media - [<D>187.226.0.193:58592, a: g729(18)(PT:20), telephone-event(101)(PT:20)(fmtp:0-16)], callID - 71532950897952610.
    CM: .264 BeginMediaSession: {MG0} - [71532950897952610]<71532950897924672>.
    CM: .284 RequestMgResource: {MG0}[L:187.226.0.51, R:187.226.0.193], line #15[0], BuildAlienFxsBridge, media - [<D>187.226.0.51:0, a: g729(18)(PT:20), telephone-event(101)(PT:20)(fmtp:0-16)], NM:1, NP:1, ND:1, callID - 71532950897952610.
    CM: .287 InsertEndpoint: {MG0}<RTP/1001>[187.226.0.51:6036] - 71532950897952610.
    CM: .288 ProcessMgReply: {MG0}, line #15, BuildAlienFxsBridge, RTP port - 6036, CAC result - OK, media - [<D>187.226.0.51:0, a: g729(18)(PT:20), telephone-event(101)(PT:20)(fmtp:0-16)], callID - 71532950897952610.
    CM: .290 BeginTone: line #15[0](e:27), tone - NoSuchNumber.
    CM: .291 CreateFileEndpoint: {MG0}<FILE/1002> - 71532950897952610.
    CM: .292 AcceptAdvFxsPBXCall(None): line #15[0](e:27), callID - 71532950897924672[5331737311372534765], media - [<D>187.226.0.51:6036, a: G729a(18)(PT:20), telephone-event(101)(PT:20)(fmtp:0-16)].
    CM: .306 BeginTone: line #15[0], {MG0}71532950897952610<4>(TOS 0xB8), FILE[/telephony/sysmessages/C/usernotfound.wav, PC: 1, a: PCMU(0)] -> RTP[(187.226.0.51:6036)>187.226.0.193:58592>, a: G729a(18)(PT:20)].
    CM: .308 BeginTone: line #15[0], {MG22}71532950897952610<4>(TOS 0xB8), RTP[>187.226.0.51:6036>(187.226.0.193:58592), a: G729a(18)(PT:20)] -> FXS[0].
    CM: .564 OnAdvFxsPBXCallDone(None): line #15[0](e:27), callID - 71532950897924672[5331737311372534765], media - [N/A].
    CM: 09:03:53.171 ProcessConnectionClosed(FileOver): {MG0}71532950897952610<4>, line #15[0](e:27).
    CM: .172 TS: line #15[0](e:27) - OffHookWaiting.
    CM: .173 ]-> SendTrunkStatus: line #15[0](e:27), L["Scott 27" 78745827@sip.epygi.com], R[PBX:N/A], S: "Trying", E: none, callID: 0, D: none.
    CM: .174 ATS: line #15(e:27) - OnHookSilent.
    CM: .174 TS: line #15[0](e:27) - OnHookSilent.
    CM: .175 ]-> SendTrunkStatus: line #15[0](e:27), L["Scott 27" 78745827@sip.epygi.com], R[PBX:N/A], S: "Terminated", E: cancelled, callID: 71532950897924672, D: none.
    CM: .176 ]-> ResetTrunkStatus: line #15(e:27).
    CM: .177 CloseAdvFxsPBXCall: line #15[0](e:27), callID - 71532950897924672[5331737311372534765].
    CM: .205 ErasePBXCall: callID - 5331737311372534765.
    CM: .205 ResetFxsBridge: line #15(e:27), sessID - 71532950897952610.
    CM: .205 EndMediaSession: {MG22} - 71532950897952610.
    CM: .207 EraseEndpoint: {MG22}<RTP/1001>[187.226.0.193:58592] - 71532950897952610.
    CM: .211 <<<<<<<<<<<< Handle Map >>>>>>>>>>>>


    After checking this i tried changing the main rule from 04???????? to a direct match 0404866658. This worked and the call proceedout out the SIP line as expected. I changed this back to 04???????? and the problem was there again. I then tried changing to 04* and the calls routed correctly.


    Does anybody know if there are any bugs which would cause the Epygi to not recognise the correct call route?

    As far as i know there were no changes made to the call routing or any other settings which may have caused any problems.

    This is a big issue for us as we're now going to be up for 2 hours of mobile calls at a very high rate and there appears to be no other reason other than the Epygi failing to route correctly.

    Thanks in Advance
    Scott

  2. #2

    Default

    What firmware version of Epygi ? are you the reseller or end user ?

    Regards

    Kevin

  3. #3
    Quadro Architect
    Join Date
    Jun 2006
    Location
    Around myself
    Posts
    2,075

    Default

    Scott, did you try to reboot the system to get the rule working again?

    I suspect you have a simultaneous call limit set ("Multiple Login" option unchecked) on the ITSP routing rule. This means there only one call through that rule can be active at the same time. Is that the case?

    If yes, then it could happen that some call was not released correctly and is still considered as "active" by the system, so the rule is ignored, as the system is waiting for that call to be released...

    I remember similiar problems on old versions. Which version are you using on that unit?

  4. #4

    Default

    Hi Guys,

    Thanks for the quick responses.

    I haven't performed a reset as of yet as it appears to be working with the new rule.

    We do only have 1 outgoing call allowed on that ITSP so what davrays is suggesting could be correct.

    The current software version is 5.0.16.

    Regards
    Scott

  5. #5

    Default

    KSComms, we are the end user.

    Scott

  6. #6
    Quadro Architect
    Join Date
    Jun 2006
    Location
    Around myself
    Posts
    2,075

    Default

    So it looks here we have the problem I described above.. Not to face this problem again, you could remove that limitation from the rule.

    From the other hand, it could be useful to find out what exactly went wrong there. I would suspect the network outage during a long time, resulting in a hanging call. Or there can be something different making the call to hang on...

    If you are a end user, you would need to contact your reseller, if you need to find this out. He can log a ticket with us, so we can monitor your unit for some time until the problem appears again. Only after doing that we can tell which was the exact reason on the hanging call.

    Best regards,
    David

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. call routing ..the best way ?
    By dolmen in forum 'How Do I' Questions
    Replies: 17
    Last Post: 09-21-2009, 09:37 AM
  2. Call Routing
    By cornepiek in forum 'How Do I' Questions
    Replies: 5
    Last Post: 10-02-2008, 10:24 AM
  3. Destination NAT rule on medium level firwall
    By skyways in forum Troubleshooting and Problems
    Replies: 4
    Last Post: 05-02-2008, 09:29 AM
  4. call routing
    By mjnorris in forum 'How Do I' Questions
    Replies: 1
    Last Post: 04-20-2008, 09:25 AM
  5. Incoming call routing not working...
    By excellence-it in forum General Discussions
    Replies: 5
    Last Post: 03-10-2008, 03:20 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •