BSNL JTO study materials
BSNL JTO study resources

SIP Trunk Sizing for a 400-Line Enterprise

BSNL JTO · Put your knowledge to work in context.

All case studies

SIP Trunk Sizing for a 400-Line Enterprise

A BSNL JTO is sizing voice capacity for an enterprise migrating 400 analog lines to SIP. In the busy hour each line averages 1.8 call attempts, and the mean holding time is 3 minutes. The enterprise currently has two E1 PRI links, i.e. 60 bearer channels, and expects the same 1% blocking grade of service. The proposed SIP trunk offers 50 simultaneous G.711 sessions with 1+1 session border controller redundancy. The JTO must verify whether 50 sessions are enough and whether the existing LAN can carry the voice traffic. Each G.711 stream uses a 20 ms payload; assume 40 bytes of RTP/UDP/IP overhead per packet and ignore Ethernet overhead for the first estimate. The access switch has a 1 Gbps uplink shared with data, and no QoS is configured. The vendor claims that 1:1 redundancy doubles usable capacity.

1. Compute the busy-hour offered traffic and the number of trunks needed at 1% GoS. Assess whether the proposed 50 SIP sessions are sufficient and whether the vendor’s 1+1 redundancy claim is correct.

Read the worked answer

Offered traffic A = call attempts x mean holding time / 60. A = 400 x 1.8 x 3 / 60 = 36 Erlangs.

Using Erlang B at 1% blocking, 36 Erlangs requires approximately 49 bearer channels. The exact table value is around 49; 48 channels would be marginal. Therefore the existing 60 E1 channels are overprovisioned, and the proposed 50 SIP sessions are just sufficient with almost no headroom.

The vendor’s claim is incorrect. 1+1 SBC redundancy provides failover of the session border controller, not double the number of simultaneous media sessions. Usable capacity remains 50 sessions, not 100. If the enterprise needs the same 1% GoS plus growth, 50 is too tight; ask for at least 60 sessions or retain the two E1s until measured traffic confirms the Erlang estimate. Also check whether the 50-session licence is a hard limit during SBC failover.

2. Estimate the bandwidth per G.711 call and for 50 simultaneous calls. Recommend a QoS approach for the shared 1 Gbps uplink.

Read the worked answer

G.711 payload is 64 kbps. At 20 ms, payload = 64,000 x 0.02 / 8 = 160 bytes. Add 40 bytes of RTP/UDP/IP overhead: 200 bytes per packet. Packet rate = 1 / 0.02 = 50 packets/s. Bandwidth per call = 200 x 8 x 50 = 80 kbps. Ignoring Ethernet overhead, 50 calls = 4 Mbps.

Bandwidth is not the bottleneck on a 1 Gbps uplink, but the absence of QoS is. Configure classification and marking at the IP phone or access switch, trust DSCP EF for RTP, place voice in a priority queue or low-latency queue, and set a bandwidth limit so bulk data cannot starve voice. Also enable call admission control so that the 50-session limit is not exceeded during failover or peak load. Monitor jitter, packet loss, and delay; one-way delay should stay well below 150 ms and jitter below 30 ms. The 1:1 SBC redundancy must preserve the same QoS markings and session limits after switchover.