- Type your task here, using "@" to assign to a user and "//" to select a due date
User Story
In South Africa, there are a lot of slow WAN links between the business customers and provider. The WAN bandwidth available for voice transport between a customer site and the service provider core network could be exceeded by running too many concurrent voice calls. That is why Limit Simultaneous Calls feature is used.
To save the bandwidth, RTP for calls within the office (Site in PortaBIlling) goes directly. It is organized by customer's SBC, which recognizes UAs using the same NAT.
Even with these optimizations, there are situations when too many concurrent voice calls cause voice quality degradation.
So it would help if Max Bandwidth limits for the Site would recognize:
| Type | What happens |
|---|---|
| Calls within the site (RTP goes directly) | excluded from bandwidth calculations |
Calls within the site (RTP is proxied) (eg in case of call recording or explicit NAT traversal) | taken into account for bandwidth limits calculations |
| Calls to IVR applications | taken into account for bandwidth limits calculations |
| Call recording | taken into account for bandwidth limits calculations |
| Calls to other sites | taken into account for bandwidth limits calculations |
| Incoming and outgoing calls | taken into account for bandwidth limits calculations |
Use Cases
Use case #1: Bandwidth control
Roles: End-user, Admin
Preconditions: Customer Twist has two offices: in Cape Town and Johannesburg.
1) In Cape Town. The accounts 000, 001, 002, 003, 004, 005, 006, 007, 008 of Cape Town are under site Cape Town; The calls between Cape Town office users are routed via LAN with the help of ACME SBC.
2) In Johannesburg. The users of Johannesburg (111, 112, 113) are under site Johannesburg. The calls between Johannesburg office users are routed via LAN with the help of ACME SBC.
3) 44999944444, 4499995555, 4499996666 are mobile users.
4) *98 is Voicemail.
Admin configured bandwidth limits: in Cape Town - enough for 2 concurrent calls, in Johannesburg - enough for 1 concurrent call.
Use scenario #1.1: Calls between users in Johannesburg
Scenario:
User 111 calls user 112
Since they are within the same site, bandwidth is not consumed
The system allows this call
- The system does not count it as occupying bandwidth
Users 111 and 112 are talking
Use scenario #1.2: Incoming call to Johannesburg
There is a local call between 111 and 112.
Mobile user 44999944444 dials 113.
- The system allows this call because there is free bandwidth (call from US 1.1 is not taken into account as direct)
44999944444 and 113, 111 and 112 are talking
Use scenario #1.3: Attempt to reach IVR application while bandwidth is used up
There is a call between mobile user 44999944444 and 113, which uses bandwidth.
112 decides to check voicemail and dials *98.
- The system does not allow this call because bandwidth is used by the call to 113.
The systems sends a specific response code.
The user 112 sees the code and understands that someone has used up the bandwidth.
Use scenario #1.4: Call to a different office while bandwidth is used up
Continuation of scenario #1.3
Scenario:
There is a call between mobile user 44999944444 and 113, which uses bandwidth.
112 calls a colleague from a different office in Cape Town, account 007
- The system does not allow this call because bandwidth is used by the call to 113.
The systems sends a specific response code.
The user 112 sees the code and understands that someone has used up the bandwidth.
Use scenario #1.5: Outgoing call to a mobile number while bandwidth is used up
Continuation of scenario #1.3
Scenario:
There is a call between mobile user 44999944444 and 113, which uses bandwidth.
112 calls external mobile number 4499995555
- The system does not allow this call because bandwidth is used by the call to 113.
The systems sends a specific response code.
The user 112 sees the code and understands that someone has used up the bandwidth.
Use scenario #1.6: Call recording while bandwidth is used up
Continuation of scenario #1.3
Scenario:
There is a call between mobile user 44999944444 and 113, which uses bandwidth.
Admin enables call recording for 112
- 112 calls user 111
- The system does not allow this call because bandwidth is used by the call to 113.
The systems sends a specific response code.
The user 112 sees the code on the phone and becomes very surprised.
Use case #2: Indication for the user that the bandwidth is used up
Let's consider Cape Town scenario. 9 extensions, connection that allows 2 concurrent calls. Connection may easily become congested by 2 users speaking. If the system plays prompts for rejected calls, bandwidth will be used to deliver announcements, thus congestion may occur and voice will be degraded.
When the users have SIP phones with display, definite SIP error code will be enough.
When the users are connected through some PBX->VoIP Gateway->PortaSIP, voice rejects will be easier to understand.
Use scenario #2.1: Rejection with playing a sound file
Admin configured that users hear the sound file
The bandwidth in Cape Town is occupied by 2 active calls
- The user 007 dials 44999944444, the system rejects the call due to bandwidth limit
The user 007 hears the sound file
Use scenario #2.2: Rejection with SIP error code
Admin configured that users get a SIP response code when call fails on bandwidth restriction
The bandwidth in Cape Town is occupied by 2 active calls
- The user 007 dials 44999944444, the system rejects the call due to bandwidth limit
The user 007 sees a specific SIP response code and understands that the lines are busy.
Other requirements / constraints