Feature Suggestion - IndividualCallee Dispatch Rule ({called-number}::{caller-number})

[yaniv-peretz]

Request for Feature

Feature

Add a 4th dispatch rule: IndividualCallee for inbound SIP calls.

The outcome destination room name would follow the format:
{room-prefix}-{called-number}::{caller-number}

Example

SIP Call from +123 → +456
Expected room name: test-+456::+123

Usage / Reason

Current dispatch rules expose either the caller-number or the called-number.
This proposed rule allows encoding both in the room name, enabling:

• Multi-tenant caller systems.
• Agent instructions determined by the called number.
• Caller context determined by the caller number.

This separation is critical in environments where the same system handles calls for multiple companies/clients, but agent behavior depends on which company is being called.

---

Example Scenario

• EndUserB calls CompanyA.
• With IndividualCallee, the room name becomes unique per callee-caller pair, allowing proper routing and context injection.

---

Reference

@dennwc

Relevant code location:
sip.go#L98

[dennwc]

Is the goal to have both numbers as an information for some external system? You can check participant attributes to get both numbers without parsing the room name.

[serhiynovos]

Is the goal to have both numbers as an information for some external system? You can check participant attributes to get both numbers without parsing the room name.

@dennwc had some similar thoughts to get caller and callee on room started before sip participant joined. Just was checking participant attributes and for the same external multi tenant systems it would be nice to have additional attributes like host which was called and what caller IP address which will to have better control our app layer.

For example we have 2 PBX systems. Which means different people there have the same extension (number).

For example now when we configure trunks on these PBXes we can tell them different domain name which will point to the same SIP server or they can be configured on the same domain name or IP but based on their external IP address we can know from where exactly call is and which user details to show

[yaniv-peretz]

Not exactly, @dennwc,

Is the goal to have both numbers as an information for some external system?

callee - used internally to query the agent instructions, webhook_url from db
caller - used to fetch data through the agent.webhook_url to get information about the caller

---

What you’re describing technically works, but it only gives us the missing piece of information after the participant joins. That means we can’t, for example, prepare a customized welcome message in advance, since we’re forced to pick between either caller or callee info at dispatch time.

Practical issue:
• If I dispatch by callee, I don’t have caller details (so I can’t webhook for the customer name before the call starts).
• If I dispatch by caller, I don’t know which business number they dialed (so I can’t load the right agent dynamically).

Right now, I work around this by mapping one trunk → one dispatch, so I get both pieces of info, but that approach doesn’t scale and is tedious to maintain.

In other words:
• The callee determines which agent or business context to load (“Hi, you’ve called Shop A”).
• The caller determines the customer context (“Your shopping history is XYZ”).

Having both available at dispatch time would unlock multi-tenant and personalized call flows without brittle workarounds.