Estimating RTC costs for smart hardware: devices, concurrency and call time

Build an RTC usage model before requesting a quote, distinguishing active devices, session minutes, participants, peak concurrency and additional services.

Shipping ten thousand devices does not mean ten thousand simultaneous calls, and it does not establish a monthly RTC bill. A useful budget starts with how the devices will be used, then applies the selected provider’s actual billing rules. Align those rules before comparing unit prices.

Build a usage model first

List total devices, the proportion active during the month, calls per active device per day, average call duration and days of use. These assumptions produce an estimate of session minutes. Next, identify the participants in each session, which participants send audio or video, and which streams each receives.

For an illustrative calculation, suppose one hundred active devices each make one ten-minute call on twenty days. That produces twenty thousand session minutes. If a quotation bills participant minutes and both endpoints attend each entire call, the corresponding illustration could be forty thousand participant minutes. This is arithmetic, not a provider’s pricing policy. Confirm billable participants, start and end events, rounding and any exceptions in the actual quotation.

Keep assumptions visible. A number with a clear usage model is easier to update after a pilot than an unexplained monthly estimate.

Treat concurrency as a separate requirement

Monthly minutes describe accumulated usage. Concurrency describes what happens at the same time. Distributing calls evenly across a day can conceal peaks during shift changes, inspections or scheduled sessions. Document when the peak occurs, how long it lasts and what operational headroom is needed.

Also define the object being counted. Devices, users, rooms and media streams are different units. Two proposals using the word “concurrency” may not describe equivalent capacity. Ask each supplier to apply the same business scenario to its definition.

Separate additional capabilities

Request distinct explanations for audio, video quality tiers, multiple subscriptions, recording, storage, transcoding and any other capability actually required. Features in a package should not automatically be treated as either essential expenditure or guaranteed value.

Confirm minimum commitments, overage rules, allowance expiry, treatment of unused capacity, regional differences and technical support. Separate device adaptation and application development from ongoing RTC use. This makes the initial implementation budget and the recurring service budget easier to assess.

The relevant question is not simply whether a feature exists, but whether the quoted scope includes the way your product will use it.

Model three usage scenarios

Create conservative, expected and growth scenarios by changing active-device rates and calling frequency. Check which assumptions have the largest effect on the budget. During the pilot, collect actual usage and replace estimates with observed behavior where possible.

After launch, reconcile a sample of session records with billing records. Investigate whether failed attempts, background participation or unexpected session duration affect billable usage under the agreed policy.

This is a general budgeting method and does not imply a particular price. For an RTC quotation, provide device volume, participant relationships, media types, deployment markets and a usage range.

Reference: W3C WebRTC specification provides background on sending and receiving media. It does not define commercial billing; the budgeting approach above is a procurement recommendation.

← Back to insights

LET’S CONNECT

Start with your device and use case.

Tell us your device type, communication needs and project stage to discuss RTC integration and pricing.

Discuss integration & pricing ↗