[asterisk-users] handling SIP trunk with limited concurent calls

[Gordon Henderson]

On Fri, 6 Jun 2008, Benoit Plessis wrote:

> Benoit Plessis a écrit :
>> Gordon Henderson a écrit :
>> 
>>> On Thu, 5 Jun 2008, benoit plessis wrote:
>>>
>>> 
>>>> Hi,
>>>> 
>>>> Now that we have a working asterisk server, i'm looking
>>>> toward cost optimization :)
>>>> 
>>>> We are actually testing a SIP provider, which has an interessting
>>>> limitation: each account support at max only two concurrent calls.
>>>> 
>>>> My problem is how to combine multiple accounts and fail back to PSTN
>>>> lines if all accounts are 'full'. I've added a "call-limit=2" in the
>>>> sip.conf entry, but i dont really now how to use it in the dialplan.
>>>> ChanIsAvail() was my first try but didn't work.
>>>> 
>>>> I've tried chaining Dial() calls:
>>>> 	Dial(SIP/line1/${EXTEN})
>>>> 	Dial(SIP/line2/${EXTEN})
>>>> 	...
>>>> but when an error condition occurs (busy/unavailable/whatever) it
>>>> dial the same number on every line, which can take a while at the end.
>>>> 
>>>> So, is there a way with the DIALSTATUS variable to detect a 'full' peer
>>>> ?
>>>> 
>>> Yes.
>>> 
>>> You need to check for CONGESTION.
>>> 
>>> something like:
>>>
>>>    n,Dial(SIP/line1/{EXTEN})
>>>    n,Noop(Dial line1 failed - we got ${DIALSTATUS})
>>>    n,GotoIf($["${DIALSTATUS}" = "CONGESTION"]?tryNext)
>>>    n,Hangup
>>>
>>>    n(tryNext),Dial(SIP/line2/${EXTEN})
>>> 
>>> But do check that the SIP provider does indeed return CONGESTION ... (You 
>>> may not need the call-limit=2, if they check for you, then if at a later 
>>> date, they increase the limit, then you don't need to change anything)
>>> 
>>> Gordon
>>> 
>> Isn't there a risk of getting a CONGESTION message from the other party ?

Isn't CONGESTION what you want? And if the remote SIP provider returns 
CONGESTION, then it ought to return it almost instantly too, so "scanning" 
a list of SIP providers in-turn, before ending up with a PSTN interface 
ought to take fractions of a second..

Just don't confuse CONGESTION with BUSY.

> Another problem i foresee is long delay in dialing sequence when asterisk 
> will have to dial using 4/5 account
> before having a working channel

See above - the SIP channels ought to return CONGESTION immediately if 
they're "full".. (I can't think what else they might return though?)

> i think i should look after another sip provider

I currently use this in 2 applications - one is to a SIP -> GSM box with 2 
ports, when each port is busy with a call, it returns CONGESTION, so I try 
port 1, then port 2, then fall-back to PSTN, (and I had to tell the box to 
give me CONGESTION in this case rather than BUSY!), and in another 
application where I do it the other way round - I dial out via 3 analogue 
lines, but when they're full, Zap/G1 returns CONGESTION and I then dial 
out via the Internet and a VoIP service.

Gordon