Doug,
Doug McLetchie wrote:
For inbound calls (calls coming from another carrier to my big expensive gateway & destined for a specific PBX), I'd like my gateway to send the call to the proxy, who will determine which PBX to send the call to, and then send the call to to correct PBX via the Gateway. I don't understand how to set up OpenSER to send the call via the Gateway. If I provision the static ip address of the PBX in the proxy, won't it try to send directly to that IP address instead of sending it to the Gateway? I think that the feature that I'm looking for is something like an outbound proxy, for the proxy. (does that make sense?)
OpenSER can certainly do what you are trying to accomplish.
SIP routing is done by URI, which consists of a "user" part and a "domain" part. The "user" part is the number (or alphanumeric identification, in the case of pure-VoIP peering) and the "domain" part is the IP "place" at which the "user" part is reachable.
When you route a call to some URI, what you are really saying is, "Here, domain, you must know what to do with this 'user' part - i.e. have reachability information for it (a SIP contact bound from a registration, for example)."
A proxy by itself isn't enough. If you need to reach these PBXs, you clearly need to know how to reach them. This requires a SIP registrar somewhere, so that the PBXs can register against it and say, "Here, you can reach me at such and such IP and port." Or, I suppose, you can define these contacts statically with a database interface from the proxy, in which case you don't need to use a registrar.
I don't know what this Big Expensive Gateway is, but if it's something like a Session Border Controller, it should be able to forward SIP REGISTER requests to your proxy/registrar. Or do they register against the gateway?
Either way, you can perform this resolution with OpenSER.
The problem you *might* run into is sending the same logical call leg back to the Gateway. Depending on what it is, it may not like that and perceive a call routing loop, because the call that went through it to the proxy is the "same" call (in terms of SIP Call-ID, and other things that make up a logical call "leg") that is now being sent back around to it. This problem is often solved with the introduction of a back-to-back user agent which can re-originate a different call leg.