Re: [asterisk-users] handling SIP trunk with limited concurent calls
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___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] handling SIP trunk with limited concurent calls
Gordon Henderson wrote:
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
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
He's right, you should get congestion in less than a second (unless your
provider is slow anyway in which case you should switch providers anyway).
--
Sherwood McGowan
VoIP / Telecom Solutions
[EMAIL PROTECTED]
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] handling SIP trunk with limited concurent calls
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
?
--
Benoit
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] handling SIP trunk with limited concurent calls
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
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] handling SIP trunk with limited concurent calls
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 ?
benoit
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] handling SIP trunk with limited concurent calls
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 ?
benoit
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
i think i should look after another sip provider
--
Benoit
begin:vcard
fn:Benoit Plessis
n:Plessis;Benoit
email;internet:[EMAIL PROTECTED]
tel;home:+33 9 52 49 25 06
tel;cell:+33 6 77 42 78 32
x-mozilla-html:FALSE
version:2.1
end:vcard
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
