Voxbeam claims to support G.723.1 (6.3 kbps) on all their routes. However, OBi devices don't implement that codec, so transcoding software would be needed at your end. I'm a satisfied Voxbeam customer, though I've never used or even tried their compression codecs.
Note that if you are using SIP (or H.323, MGCP or XMPP for that matter), the audio is encapsulated in RTP. In addition to the payload, each packet has 12 bytes of RTP overhead, 8 bytes UDP overhead, 20 bytes IP overhead, plus additional overhead dependent on the satellite technology employed.
With G.723.1, frames are fixed at 30 ms, containing 24 bytes payload + 40 bytes RTP/UDP/IP + ?? bytes for the link and physical layers. (17067 + ?? kbps)
With G.729, 20 ms packetization is most common, but if you chose 30 ms, the packet is only 6 bytes longer than for G.723.1. (18667 + ?? kbps)
IMO, it's likely that your problem is not caused by exceeding the bandwidth capability of the link, but by severe jitter, greater than what the jitter buffers can handle. At your end, your device may have some adjustments, or a software jitter buffer can be used. The OBi is very tolerant in this regard. Of course, such buffering is at the expense of already awful latency. In the upstream direction, you have a tougher problem, because you have no control over the jitter buffer at the provider. If you have intractable outbound choppy voice issues, you may need to set up an intermediate server. This may be in the cloud, at your headquarters, or anywhere that you have a solid, low-latency connection to the Internet.
