In this guide, we provide details and background information on how Proxy manages phone numbers and selects them from the number pool. If you just want to get started working with Proxy, head over to the quickstart.
For masked communications between two participants, Proxy relies on the concept of Sessions. Sessions are our pairings of two individuals. A Session doesn't just wrap up a single voice call or SMS message, it contains all the calls and messages for the given pairing of numbers. The following diagram shows a Session with two numbers wrapping up two SMS conversations and a Voice call.
Behind the scenes, Proxy intelligently manages phone number selection from your number pool. Let's walk through the example of a delivery service to understand how Proxy handles proxied numbers.
Different numbers in different countries will vary by capabilities; numbers which support multiple capabilities can have different conversation types in the same session.
Both of these numbers have voice and messaging capabilities.
A new delivery is created in our system, so we create a Proxy Session. Here are the steps Proxy runs through:
- We receive the customer's phone number and the driver's phone number so that they can communicate over SMS and Voice channels.
- Proxy realizes a Twilio number is needed to proxy communications, so it retrieves one from the phone number pool associated with Proxy.
- Both the driver and passenger are now paired and both receive a Proxy number to communicate.
- 顧客AとドライバーXはTwilio電話番号 #1-415-555-1212 でマッチングされます。
A second delivery is created in our system and we create a second Proxy Session. It's a different customer and different driver, so Proxy can re-use the number used in the first delivery.
From our first delivery session which is still ongoing:
- 顧客AはSession 1に対して[Customer A's phone number, Twilio proxy number #1-415-555-1212] として対応づけられます
- Driver X is matched to Session 1 as [Driver X's phone number, Twilio Proxy number #1-415-555-1212]
For our second delivery session, the following happens:
- Customer B is matched to Session 2 as [Customer B's phone number, Twilio Proxy number #1-415-555-1212]
- Driver Y is matched to Session 2 as [Driver Y's phone number, Twilio Proxy number #1-415-555-1212]
Proxy can re-use the same Twilio number for this masked communication because it is still able to identify both participants uniquely.
A third delivery is created in our system, and now it is Customer C being paired with Driver X. Proxy knows that Driver X already has a session ongoing (Session 1) so it needs to be careful about number allocation.
Here's how Proxy manages this complexity:
- Customer C is added as a participant. They have no other deliveries, so can be allocated #1-415-555-1212.
- Driver X already has an ongoing delivery (Session 1) so if they were allocated #1-415-555-1212 as their Proxy number, conversations would merge and cause serious confusion.
- Proxy knows this, so it will allocate a different number (#1-415-555-3434) to Driver X.
Note how Driver X now has two different numbers assigned internally to the service. This abstraction makes it so that when Driver X makes/receives texts or calls originating from Customer C, they are from a separate number to his other customers (Customer A in this example).
Proxy thus manages the complexity of 3 deliveries across 3 customers with 2 drivers with only 2 phone numbers.
With Proxy, both participants in the session don't have to use the same Proxy number. For example, if customer D is roaming on a UK phone number, and Driver Z is on a US phone number, the pairing may actually be:
- Customer D is matched to Session 4 as [Customer D's UK phone number, Twilio Proxy UK number #44-87-000-1234]
- Driver Z is matched to Session 4 as [Driver Z's US phone number, Twilio Proxy US number #1-415-555-3434]
This means that customer D won't have any trouble sending SMS messages to a UK number, but they will still be proxied through to reach Driver Z on a US number.
Proxy intelligently manages phone number allocation. Algorithmically, it attempts to optimize for many use cases and prioritizes:
- Using your number pool as efficiently as possible
- Avoiding any possibility of collision where conversations 'merge' the wrong participants
- Selecting numbers appropriate to end-user capabilities and conversation types
When presented with an end users phone number, Proxy will only match that number to a Twilio number in the same country. This is to ensure that routing between an end user's number and a Twilio number will always succeed. Beyond that, Proxy allows a number of configuration options on the Service with the parameter GeoMatchLevel.
|Country||Default. End-user numbers will only match with a same-country Twilio number. For example, if you have USA and UK users, they will each be assigned a number from their country.|
|AreaCode||電話番号が (米国の) ローカル市外局番と完全一致するようにします。|
|ExtendedAreaCode||電話番号が (米国の) 拡張市外局番と完全一致するようにします。|
Proxy provides two number selection "styles". These are configurable on the Service. The two settings are PreferSticky (default) and AvoidSticky.
PreferSticky means that Proxy will try and select the same number for a given participant if they have previous sessions but will select another number if that number cannot be used. This is useful for ridesharing like use cases, where there are low concurrent sessions, and you want drivers to see the same number when interacting with your service as much as possible.
AvoidSticky は同じ電話番号の使用を試みる代わりに、Pool内の別の電話番号を可能な限り使用しようとします。 これはエンドユーザーが別の人とマッチングされた際、可能な限り別の電話番号を表示したい場合に有用です。
We have a whole guide on that question, find that here: How many numbers do I need?
Hopefully, you now have a better understanding of how Proxy manages phone numbers in your pool of Twilio phone numbers and assigns them to the parties in your masked communications channels. If you still have questions, please reach out to us using the support channel below.