IP Calls

dmatthysen

Well-Known Member
Joined
Feb 21, 2007
Messages
115
Reaction score
1
Hi

Where can I find some documented info on why I`m capable of making more than one call per SIP UA.
 
I presume you are using Asterisk.

In the extensions config in sip.conf you can add a command "call-limit=2" ie max 2 calls at a time.
 
I presume you are using Asterisk.

In the extensions config in sip.conf you can add a command "call-limit=2" ie max 2 calls at a time.

I`m actually using a SIP Server (3CX) but how does this work as I dont see more than 2 concurrent calls at the same time in the CDR`s?
 
I don't know 3CX at all, but with my sip handsets I can put calls on hold and switch between them or conference them together.

I've seen though that a user gets completely confused if there are more than 2 calls at a time, so I've left all mine at max 2, more than that goes to voice mail.
 
I don't know 3CX at all, but with my sip handsets I can put calls on hold and switch between them or conference them together.

I've seen though that a user gets completely confused if there are more than 2 calls at a time, so I've left all mine at max 2, more than that goes to voice mail.

It`s the same on a Porta One...anyway I think you`re misunderstanding my question...What makes it possible to have more than one call per SIP UA; e.g. I have one 087 number but I can receive and make more than one call at any time.
 
It`s the same on a Porta One...anyway I think you`re misunderstanding my question...What makes it possible to have more than one call per SIP UA; e.g. I have one 087 number but I can receive and make more than one call at any time.

The server you are connecting places that limit on the SIP user/extension.
 
Here is the technical specification for SIP:

http://www.ietf.org/rfc/rfc3261.txt

You'll struggle to find anything that says why you can make multiple calls. You need to change your mindset and ask why not? In TDM world, the answer is restricted bandwidth: you have only a certain number of available 64kb/s PCM-encoded timeslots. (1 for traditional PSTN, 2 for ISDN BRI, 30 for ISDN PRI). In a SIP environment, your limit is equally defined by bandwidth, just that bandwidth available tends to be hundreds of Kb/s or even Mb/s, so with a single SIP/g.729 call taking 24Kb/s, your call limit is typically a lot greater than any single human can practically deal with. But try run over a dial-up link, and you'll quickly hit a 1-call limit.

What does make most SIP UA's scale quite nicely is that end-devices like phones only need to transmit voice for active calls. If they place a call on hold, the media (voice) is usually RE-INVITEd to the switchboad (which provides music-on-hold), so that if the phone has 8 calls on hold and 1 active, it's bandwidth requirement is usually only slightly greater than for just 1 call. Similarly, processing power used is not much greater than with a single call.

If they transfer a call, they do not need to remain in the path of the media as with a TDM environment. Eg. If you receive a call in Jhb and transfer it to CPT in a TDM environment, the JHB switchboard will open a second channel to CPT. With SIP, it's possible to re-direct the actual call. (Note, certain restrictions apply, particularly in setups where NAT is involved).

That being said, there are other factors that affect call limits to SIP end-points. Since many popular codecs (e.g. g.729, g.723.1) are subject to patents and royalty fees, a lot of handset manufacturers place an artificial call limit so that they only need to pay a finite amount on royalties.

So I guess it's fair to say that there are restrictions with any technology, but in the case of VoIP, the SIP signalling protocol is so lightweight (hence 'S' for "Simple") that it doesn't take much bandwidth or processing power to deal with hundreds of calls.
 
It`s the same on a Porta One.
Note on Porta you're restricted to 1 concurrent call on a debit (pre-paid) account while a credit (post-paid) is only limited by configured value. This is to avoid fraud as the system has to maintain accurate timing to end calls precisely at balance expiry, and this is virtually impossible to get right with multiple calls on the same account running at differing price/sec.
 
1 call limit on prepaid is rather annoying.

What Switch Telecom does, to work around potential fraud, is that we calculate the call limit based on the available credit divided by the number of channels.

e.g. If you sign-up for an 8-channel service and have R80 credit left, it will limit the call length to R10's worth (e.g. 6min22sec for a cell call or 18min+ for a land-line call).

The same is actually applied to post-paid customers, based on the approved credit limit. e.g. If your approved credit limit is R10,000 and you've already spend R9,920 that month, the same restrictions would be effected, even though you're post-paid. This protects you against fraud and lets you apply a debit-order limit of your choice.

In postpaid this is mostly transparent to the customer as the credit limit assigned is usually sufficiently higher than their call spend to allow calls of two hours in length to most destinations (excluding the really expensive calls like to ships, some satellite phones, etc.).

We also - both with prepaid and postpaid - have a system that checks the usage on the 10th, 20th and 25th of each month and estimates your expected usage for the month based on pro-rata usage from the 1st. If it thinks that you're going to use more than 80% of your credit, it emails us so we can contact you pre-emptively before the credit becomes an issue.
 
1 call limit on prepaid is rather annoying.

What Switch Telecom does, to work around potential fraud, is that we calculate the call limit based on the available credit divided by the number of channels.

e.g. If you sign-up for an 8-channel service and have R80 credit left, it will limit the call length to R10's worth (e.g. 6min22sec for a cell call or 18min+ for a land-line call).
I would find this system even more annoying. For example if I had 60min worth of credit for a particular destination and I could only make call of 10min before being cut off, I would be a bit peeved.

Also your system would get incredibly complex if dynamic route selection (e.g. by best ASR) via multiple alternate paths to the same destination with diff price/sec was being used.
 
Route selection via ASR does not affect the retail tariff that customers pay, so doesn't affect this.

But if you have a better suggestion as to how to handle this situation - one that takes into account the need to prevent fraud - I'm open to suggestions!

As I mentioned, we mostly work on post-paid, where - provided the client doesn't have judgements or a bad credit profile, the credit limit assigned is sufficiently higher than their monthly usage that these sorts of limits should never be encountered (except in the event of fraud)
 
Route selection via ASR does not affect the retail tariff that customers pay, so doesn't affect this.
You're right on the route selection/failover, however the main logic problem still remains;

If 2 ch customer has R10 account balance and makes a call to a R1/min destination you'd set the max call dur to 5min. 4 min later they make a 2nd call which also set to 5min max as the balance is still R10. The 1st call ends at 5min and the account is updated to R5 balance. Immediately after a 3rd call is placed and its max dur is set to 2min 30sec.

How do you stop the customer from getting R12.50 worth of calls from a R10 balance? In pre-paid the R2.50 overrun is an unrecoverable amount, however since post-paid is on invoice, you can still bill minor overrruns.

Hence the logic of limiting pre-paid accounts to 1 concurrent call.

But if you have a better suggestion as to how to handle this situation - one that takes into account the need to prevent fraud - I'm open to suggestions!
Don't take on multi-channel customers on pre-paid.
 
Last edited:
Top
Sign up to the MyBroadband newsletter
X