trunk sequence issue

[witekprytek]

Hi;
I have some issue with trunk failure functions.
I have configured 3 trunks in the system
1. voip - to voip provider
2. gsm via gsm gateway
3. Isdn via the BRA and isdn Carrier

The outbound route is set for two different patterns 1 for gsm and the second for any other outgoing call

In "other" configuration I have set trunk sequence:
1. VoIP
2. GSM
3. ISDN

I want to use trunk different than VoIP only in case of VoIP trunk failures.

But now when some outbound call is placeded via voip trunk and the called party does not pick up the phone, the system use different trunks to call the number again.

Is it possible to configure the outbound route to use other trunk only in case of the primary trunk is down or thera are some errors on it and not to forward call to another trunk when the called party does not respond.

 

[Bob1]

witekprytek,

First of all have a read of the qualify statement in any asterisk/freepbx docs. It is ideal to set qualify = (a number) which means that it only uses this trunk if it fits the criteria. This will force Elastix to use the next trunk in the sequence.

Next I believe is your next problem, in that after a Real call failure (e.g. Busy) in on trunk, it then tries the next trunk. (I believe this is what you are saying??).

This should not happen with a correctly configured trunk. As a test (only), put your ISDN first, then your GSM, and try to replicate the same issue (maybe dial a number that you know is engaged/busy). ISDN signaling is pretty robust, and it should report back to Elastix that the call was successful, but busy.

If this correctly works and your original trunk sequence doesn't then it is going to come down to your VoIP provider or your Trunk setup being incorrect (in simple words the SIP conversation is not working correctly). It may be something that you cannot fix especially if it is the VoIP provider (if it is a Big name voip provider, then generally you can discount that issue, but the smaller ones quite often do not have everything setup perfect).

Hope this gives you something to work on...

Regards

Bob

 

[witekprytek]

Hi Bob;
Thank you for your answer.

First of all have a read of the qualify statement in any asterisk/freepbx docs. It is ideal to set qualify = (a number) which means that it only uses this trunk if it fits the criteria. This will force Elastix to use the next trunk in the sequence.

All above is truth. and this works without any problem for me.

Next I believe is your next problem, in that after a Real call failure (e.g. Busy) in on trunk, it then tries the next trunk. (I believe this is what you are saying??).

That's exactly what I mean.

This should not happen with a correctly configured trunk.

unfortunately it does :-(

As a test (only), put your ISDN first, then your GSM, and try to replicate the same issue (maybe dial a number that you know is engaged/busy). ISDN signaling is pretty robust, and it should report back to Elastix that the call was successful, but busy.

I have made a lot of tests in different scenarios:
isdn->voip->gsm
voip->isdn->gsm
voip->gsm->isdn (default one)

I have called different targets - PSTN, mobile and VoIP

When the called party is busy everything works fine and the asterisk do not try to call using next trunk in sequence.
When the caller does not pick up the phone the macro [dial-out-trunk] always tries to call using next trunk.
I afraid that the asterisk does not recognize the HUNGUPCAUSE correctly and set the reason for CONGESTION
and the macro try to forward the call to another trunk.
(example below)

[Dec 3 10:06:57] DEBUG[25822] chan_sip.c: Acked pending invite 102
[Dec 3 10:06:57] DEBUG[25822] chan_sip.c: Stopping retransmission on '[email protected]' of Request 102: Match Found
[Dec 3 10:06:57] DEBUG[30287] channel.c: Hanging up channel 'SIP/topex_out-0000043a'
[Dec 3 10:06:57] DEBUG[30287] chan_sip.c: Hangup call SIP/topex_out-0000043a, SIP callid [email protected])
[Dec 3 10:06:57] DEBUG[30287] rtp.c: Channel '<unspecified>' has no RTP, not doing anything
[Dec 3 10:06:57] DEBUG[30287] app_dial.c: Exiting with DIALSTATUS=CONGESTION.
[Dec 3 10:06:57] DEBUG[30287] app_macro.c: Executed application: Dial

so in my opinion the only way to fix this is some modification of the dialout-trunk macro, but I do not know much about asterisk scripts :-(

 

[Bob1]

Not to sound like you have it wrong, and I appreciate your level of knowledge, especially providing the log, but unless you have deviated from the original setup of Elastix and the versions that it comes with (e.g. you have not upgraded to Freepbx 2.9), it does work.

Otherwise I have a large number of systems out there are that are not working, which I highly doubt with many of them with them with multiple trunks (e.g. ISDN, GSM, SIP) and fall throughs.

You have shown the log with the GSM device which is exactly the device that I would expect you have the problems with. Many of these GSM devices implement the SIP spec poorly, and furthermore their documentation of their SIP options leaves a lot to be desired, and I have worked with a number of them, including the commercial units. Even the large commercial units, it is surprising to see their firmware with a large number of SIP issues.

The VoiceBlue series are the ones that I currently work with, which are still not great, but they provide a reasonable amount of configuration especially in regards to the "SIP Conversation Sequence".

[Dec 3 10:06:57] DEBUG[30287] app_dial.c: Exiting with DIALSTATUS=CONGESTION.
This line in particular is where the failure is happening as the incorrect SIP "signal" has come back from the GSM device. Asterisk will take the congestion and believe it needs to fall to the next trunk.

Making modifications to the dialout trunk macro is not the way to correct the issue, as it will most likely break something else. Your choices are

1) Upgrade your Freepbx modules to the latest (don't upgrade the core to 2.9)
2) Poke around the Freepbx forums to see if there is a bug in Freepbx 2.8 - I doubt it
3) Learn the standard SIP conversation sequence, and use Wireshark to determine if your GSM device is adhering correctly to that sequence.
4) Confirm you have the latest firmware for your GSM device and ask for support.

Whilst there is a very remote possibility that there could be a bug, I find it hard to believe that tens of thousands of Freepbx 2.8 users have not found the bug.

Regards

Bob

 

[witekprytek]

Bob;
As I said - this is not the GSM gateway problem (I use- topex mobil link 2 gateway - one of the best i ever had). I just have shown the first log i had
The others logs ( including connection via sip trunk) shows the same reason of call end.

I use elastix 1.6.2-37 with freepbx 2.5.2-2.

My system is based on generic Xorcom PABX. I do not know if I can do upgrade of freepbx without loosing system consistence.
Maybe it is possible to change the code of the macro dialout-trunk only - do you think that it could be a good idea?

 

[Bob1]

Ahh, there's the missing bits of the puzzle... :cheer:

Now we are going back to some possible known issues with Freepbx 2.5

I agree, I can't give you any guarantees with trying to upgrade your freePBX....so yes you might have to do some changes to the dialout Macro...to get round the issue.

One of the bugs I know about in Freepbx is
http://www.freepbx.org/trac/ticket/3046

Where the database has the trunk twice (not the GUI), which on congestion tries to ring again (which would affect GSM, ISDN, SIP lines). Whilst I have not tried it, I am wondering whether once you have your configuration working, whether you could access the database.

Now I know this was with 2.4, but wondering if you have something similar or a left over that was not corrected (in upgrades)...not knowing the history, I am only taking guesses, but it does seem very similar to your issue....possibly something to look at....

Regards

Bob

 

[IbrahimTerm]

Good news for owners of Topex equipment!

Now you can unload your working day:

- Quickly deploy network equipment without a long setup for Asterisk and SimServer;
- Opportunity to pass calls through one SIM-card / gateway in different directions, adjusting the volume of traffic on each of them;
- Collect detailed statistics on specific cards and channels;
- Receive alerts by E-mail or Skype;
- Automated replenishment of SIM-cards, sending USSD, SMS;
- Extend the life of SIM-cards when properly configured.

All of these features are now available for the owners of VoIP-GSM Topex equipment, which is now compatible with the GoAntiFraud service.

A full list of features is on the official website: https://goantifraud.com/en/topex/

New service for owners of Topex equipment!

The new comprehensive solution Topex + GoAntiFraud will allow you to earn more and save time in the New Year!

Comprehensible interface and fast connection for Topex equipment.
Automation of the system and time saving.
Masking SIM-cards from Fraud-systems operator.
Flexible configuration of channels and distribution of calls for individually SIM-cards.
Complete statistics of the equipment Topex without installing additional modules.
Remote access to all the settings of the SIM-bank from the personal account of the user.

Service GoAntiFraud opens new possibilities for termination Topex equipment in the New Year.

https://goantifraud.com/en/topex/