feat(sip): Add numbers field to SIPDispatchRuleInfo for filtering calls by called number

[civilcoder55]

• Add numbers field to filter calls by the called number (trunk number)
• Include numbers in dispatch rule priority calculation and validation
• Update dispatch rule matching logic to check both inbound and called numbers
• Add tests for number-specific dispatch rules and conflicts

Motivation:
Previously, when a trunk had multiple numbers and calls from each number needed to be dispatched to a different agent, a separate trunk had to be created for each number and linked to its own dispatch rule.

This change allows dispatch rules to be matched directly against trunk numbers (derived from the SIP To header). As a result, a single trunk can now contain multiple numbers, with each number correctly routed using its own dispatch rule.

[changeset-bot]

🦋 Changeset detected

Latest commit: f7d1e71

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

💥 An error occurred when fetching the changed packages and changesets in this PR

Some errors occurred when validating the changesets config:
The package or glob expression "github.com/livekit/protocol" specified in the `fixed` option does not match any package in the project. You may have misspelled the package name or provided an invalid glob expression. Note that glob expressions must be defined according to https://www.npmjs.com/package/micromatch.

[dennwc]

The change looks good! Updating SIP should automatically start using the new rules, but Cloud will need some extra work on our end to support this.

We were actually planning to redo the trunk/rules in a new API, so this use case may be covered in it already. But I'm not opposed to adding this extension for the current API in the meantime.

Curious what other team members think.

[civilcoder55]

Hello @nishadmusthafa,
What do you think of this change?

[nishadmusthafa]

hey @civilcoder55 , as @dennwc long term we will be moving to a different mechanism for dispatch rules that will be more flexible way to handle this use case. I'm also fine for this being a way to handle that until then. This was an attempt some time back at that solution which we haven't been able to prioritise

[civilcoder55]

Thank you @nishadmusthafa