A provider may use ‘SIP line’ to mean a user account, a registered endpoint, or one concurrent call channel. That ambiguity becomes expensive when a voice-agent launch adds burst traffic, transfers, several phone numbers, and failover. The useful comparison separates the trunk, channel, number, and call-start rate so you can size the carrier layer around the workload you will actually run.
The short answer: a line and a trunk are usually different layers
A Session Initiation Protocol (SIP) trunk is a logical connection between your voice system and a telephony provider. It can carry many call sessions. A SIP channel is usually one unit of concurrent call capacity on that trunk.
SIP line is less precise. Providers use it for at least three different things:
- a SIP account or registration assigned to one phone or endpoint;
- a service that permits one active call at a time; or
- a channel sold inside a larger SIP trunk.
That means “SIP line or SIP trunk?” is often the wrong procurement question. A team may buy one trunk with 100 channels, while another provider may describe the same capacity as 100 SIP lines. The contract and architecture must define the resource.
For a production voice agent, choose the interconnection model first. Then size concurrent call legs, calls per second, phone numbers, and recovery paths separately. With Dasha, the SIP trunk is the carrier boundary. Our managed voice-agent runtime is a separate layer with its own execution and operating requirements.
SIP line, channel, trunk, and number mean different things
SIP itself is an application-layer signaling protocol. It establishes, modifies, and ends sessions. It does not define a billable object called a “SIP line.” That term comes from service packaging.
| Term | What it represents | What it does not guarantee |
|---|---|---|
| SIP account or registration | Credentials and an address through which an endpoint registers with a SIP service | A particular number of concurrent calls |
| SIP channel | A provider-defined unit of simultaneous call capacity, commonly one active call leg | A phone number, extension, or call-start rate |
| SIP trunk | The logical interconnection and routing policy between a voice system and a provider | Unlimited channels, unlimited calls per second, or automatic redundancy |
| Direct inward dialing (DID) number | A public switched telephone network (PSTN) address routed toward a trunk or endpoint | A reserved channel or a one-to-one relationship with a user |
| SIP endpoint | A phone, private branch exchange (PBX), session border controller (SBC), or application that sends and receives SIP messages | Carrier access or PSTN numbering by itself |
The distinction between signaling and media matters too. SIP negotiates the session, while the Real-time Transport Protocol (RTP) carries media in a typical voice path. A successful SIP response therefore does not prove that two-way audio is flowing.
Phone numbers do not determine channel count
One direct inward dialing (DID) number can route several simultaneous calls through a trunk when the provider and receiving system allow it. One trunk can also carry many DIDs. Buying 200 numbers does not necessarily buy 200 channels, and buying 200 channels does not necessarily include any numbers.
Number inventory and capacity should have separate owners and budgets. This prevents a common launch failure where the numbers are ready but inbound concurrency is too low, or the trunk has spare capacity but the intended caller IDs are unavailable for the target routes.
SIP line vs. SIP trunk for a voice-agent workload
| Decision area | Individual SIP line or account | Multi-session SIP trunk |
|---|---|---|
| Capacity | Commonly one active call or a small fixed allowance, depending on the provider | Pooled capacity defined by channels, an account limit, or an elastic policy |
| Concurrency | Often tied to one registration or endpoint | Shared across agents, campaigns, numbers, tenants, or PBX extensions |
| Call-start rate | May be low or undocumented | Usually governed by a separate calls-per-second limit |
| Numbering | Often one number per account, though packaging varies | Commonly maps many DIDs to the same routing and security policy |
| Cost | Simple fixed charge for a small, stable workload | Fixed-channel, usage-based, committed-capacity, or hybrid pricing |
| Redundancy | A second account may provide a manual backup, but state and routing remain separate | Can support several ingress targets, SBCs, regions, or carriers under one routing design |
| Security | Credentials and registration controls are typical | Internet Protocol (IP) access rules, credentials, Transport Layer Security (TLS), Secure Real-time Transport Protocol (SRTP), SBC policy, and fraud controls can be applied at the interconnect boundary |
| Best fit | Development, a single phone, a low-concurrency workflow, or a small branch | Production voice agents, shared carrier access, an existing PBX, pooled capacity, and explicit failover |
These are common service patterns, not protocol rules. Any proposal that uses “line” should also state concurrent calls, inbound and outbound treatment, call-start rate, and what happens during ringing and transfer.
Size concurrency and calls per second separately
Voice-agent traffic is machine-paced and bursty. The capacity model needs two independent limits:
- Concurrency is the number of active call legs the system can hold at once.
- Calls per second (CPS) is the rate at which new call attempts may begin.
A trunk can support hundreds of simultaneous calls while accepting new outbound attempts slowly. The reverse can also occur in a tightly limited application. “Unlimited concurrent calls” does not mean unlimited call starts or unlimited application capacity.
Estimate the baseline from the busy interval
Use connected calls in the busiest interval as a starting point:
average concurrency = calls started per hour × average connected duration in minutes ÷ 60
If 600 connected calls start in the busiest hour and the average connected duration is three minutes, average concurrency is 30. Thirty channels would leave no room for clustering, longer calls, retries, transfers, or growth. Production sizing should use a high percentile from interval-level observations and retain explicit headroom.
Count call legs as well as conversations. A transfer that bridges the agent leg and the human leg can temporarily consume two carrier or application legs. Ringing and failed attempts may also consume setup capacity and, under some commercial definitions, a channel.
For outbound workloads, CPS controls ramp time. At five CPS, starting 300 attempts takes at least 60 seconds before retries and throttling are considered. Queueing and pacing therefore belong in the capacity design even when the trunk has ample concurrency.
Our SIP trunking architecture guide goes deeper into media bandwidth, codecs, dual-tone multifrequency (DTMF), response codes, and production diagnostics. The line-versus-trunk decision should remain focused on how the carrier resource is packaged and shared.
Compare total cost around the traffic shape
Common SIP contract structures include fixed channels, metered minutes, committed capacity, and bundled plans. No one model is cheapest for every voice-agent workload.
A complete monthly model includes:
- trunk or account charges;
- reserved channel or concurrency charges;
- inbound and outbound minutes by route;
- DID rental, porting, and regulatory fees;
- CPS upgrades or capacity commitments;
- simultaneous legs during transfers;
- SBCs, private interconnects, media egress, and operations;
- recording, storage, support, and fraud losses; and
- idle capacity reserved for peaks and failover.
An individual SIP line is easy to budget when one or two sessions run predictably. It becomes awkward when each new agent, tenant, or burst needs another isolated account. A trunk pools capacity, so idle headroom can serve whichever approved call flow needs it. Metered trunks often suit uneven demand, while fixed channels can be economical when utilization is steady and predictable.
Cost per connected minute is still an incomplete metric. For outbound agents, cost per completed outcome also reflects answer rate, carrier throttling, short-call billing, transfers, and caller-ID treatment. For inbound agents, abandonment and blocked calls expose the cost of insufficient peak capacity.
Design redundancy across failure domains
A second SIP credential on the same endpoint is not a complete failover design. Carrier, DNS, network, SBC, region, application, and number routing can each fail independently.
Three common architectures provide different levels of protection:
- One registered endpoint and one provider. This is simple and suitable for development or a low-impact workflow. The account, endpoint, internet path, and provider form a small set of concentrated failure domains.
- One provider trunk with redundant endpoints. Two SBCs or application ingress points protect against an endpoint or region failure when the provider can route between them. SIP can use the Domain Name System (DNS) for server discovery and backup selection, as defined in the SIP DNS procedures, but the provider's actual routing policy still controls failover.
- Multiple carriers and regions. Independent trunks can reduce carrier concentration risk. This design also needs separate capacity, credentials, monitoring, outbound routing, and an inbound-number recovery plan.
Inbound redundancy deserves special attention. A DID normally remains anchored to a carrier account. Adding a second application endpoint does not move the number to another carrier during an incident. Carrier-side rerouting, secondary numbers, and staged number portfolios solve different recovery cases.
Active calls also need an explicit failure assumption. A new SIP INVITE request may reach a backup target while an established call still drops when its SBC, media relay, or network path disappears. Recovery objectives should state which failures protect new calls and which can preserve in-progress media.
Secure signaling, media, and carrier access separately
A line is not inherently safer than a trunk. Security comes from the controls around the endpoint and path.
- Authentication: Restrict who may originate calls through the service with provider-supported IP access controls, credentials, registration, certificates, or a defined combination.
- Signaling encryption: TLS protects SIP signaling between TLS peers. Its termination points should be documented because another hop may follow.
- Media protection: When configured and negotiated, SRTP can provide confidentiality, message authentication, and replay protection for RTP and the RTP Control Protocol (RTCP). TLS on the SIP leg alone does not encrypt RTP audio.
- Fraud control: Destination allowlists, rate limits, spend thresholds, credential rotation, and alerts reduce exposure to toll fraud and compromised accounts.
- Application data: Recordings, transcripts, prompts, tool results, and call-detail records need their own access and retention controls. Transport encryption does not govern stored data.
An SBC can normalize headers and codecs, enforce network policy, hide internal topology, and anchor media. It also adds state, capacity limits, certificate work, and another failure domain. It earns a place when those functions are required, rather than as a default box on every diagram.
Choose the deployment architecture before the package name
Use an individual SIP account for a narrow endpoint
This model fits a desk phone, a development environment, or a voice workflow with one predictable session at a time. It minimizes infrastructure and makes the failure boundary easy to understand. Growth usually means more accounts or a move to pooled trunk capacity.
Terminate a trunk directly on a cloud voice application
Direct termination removes an intermediate PBX when the carrier and application have a defined, compatible connection mode. It fits cloud-native teams that want fewer hops and can operate public ingress, authentication, codec policy, number routing, capacity, and regional recovery at the application boundary.
Put an SBC or PBX between the carrier and the voice-agent runtime
This pattern fits an existing enterprise telephony estate, private extension dialing, human transfers, policy enforcement, or carrier normalization. It preserves established routing and numbers while adding operational ownership for the middle layer.
Use independent trunks for multi-carrier or multi-region service
This is the strongest fit when carrier or regional outages exceed the acceptable risk of a single trunk. The application needs deterministic route selection, capacity on every recovery path, shared call correlation, and regular failover exercises.
Provider-specific field names are implementation details, not portable SIP concepts. A field in our configuration does not establish a one-to-one mapping to Voximplant, Twilio, or another carrier field. The chosen connection mode, registration direction, authentication, transport, caller identity, and routing rules must come from the current contract for both endpoints.
A practical decision rule
Use an individual SIP line or account when all of these are true:
- the provider defines it clearly;
- one or very few simultaneous sessions cover the peak;
- the workload does not need pooled capacity across many numbers or agents; and
- the smaller failure and security model meets the service objective.
Use a SIP trunk when one or more of these are true:
- several calls must run concurrently;
- outbound traffic starts in bursts;
- many DIDs, agents, tenants, or call flows share carrier access;
- an SBC, PBX, or managed voice runtime needs a stable interconnect;
- routing must span endpoints, regions, or carriers; or
- security and fraud controls belong at a shared boundary.
If a quote describes channels as “SIP lines,” the answer may be both: one trunk with the number of lines required for peak concurrent call legs. Put the operational limits in the order form, including inbound and outbound concurrency, CPS, ringing and transfer treatment, number mapping, encryption, and recovery routing.
The carrier package handles reach and capacity. We handle the managed production runtime for the voice agent behind that boundary. Evaluate Dasha once the trunk, number, and capacity model is explicit.