Now that Cheogram SIP supports bidirectional voice, we're in a good spot to be thinking about making outgoing calls via Cheogram.

It is currently unclear whether a user's "direct message route" would always know their preferred voice route. I think maybe not, since sometimes it may be created separately out of band (vonage programmable SIP for example) and sometimes a user may even wish to use a voice route that is from a different carrier than their SMS.

So, the idea is to introduce a new per-user Cheogram setting, similar to the current "direct message route" setting for "outbound voice route".

What should this route be? The most obvious answer is the hostname of a SIP server. Cheogram can then transform Jingle calls to tel@cheogram.com to tel\40<chosen sip server>@sip.cheogram.com. Is this too limiting? Should it instead be possible to set a jingle host? For a jingle-only setting using sip.cheogram.com would require setting a suffix and not just a host (to get the \40<sip server> part in there too) which feels gross and brittle. Could allow setting a Jingle host and a "proxy host" instead of a dumb suffix, then Cheogram knows to do the right escaping. Or could allow Jingle host *or* SIP host where SIP host assumes sip.cheogram.com.

I'm currently leaning towards SIP host only setup. We can add other options to the command later if needed, but every realistic route to the PSTN is going to be over SIP for now.

CallerID

This is the biggest hurdle. Cheogram doesn't know (well, it sometimes does, but it doesn't *know* in a source of truth kind of way you want to trust for CallerID) the telephone numbers that go with JIDs. So calls can go out to your specified SIP host, but will come from sip:user%40domain.tld@sip.cheogram.com

My proposal for this is that SIP host targets must be aware of mapping. So a given voice backend will set up a SIP server that takes in calls from sip.cheogram.com and redirects them to the "actual" PSTN backend SIP host with a rewritten From header according to the records of the backend. This also allows blocking callers for billing reasons, tracking minutes for billing reasons, etc where relevant to the needs of a particular route.

For catapult this means running a SIP server alongside the SGX that can lookup CallerID in Redis. Probably this will be a JMP-only server for now, since it cannot know the billing details of other catapult SGX users or how their bandwidth trunk is setup, etc. It will need to make sure when looking in Redis that it is indeed looking at a JMP catapult record and not some other one.

For vonage I am hopeful that their "programmable SIP" dev preview may allow this kind of functionality with a simple addition to the SGX responding to an HTTP callback from them during SIP initiation, and thus use entirely their own SIP infrastructure without anyone hosting anything. This has the advantage that it should work for any vonage SGX user and not be a special case.