Has anyone used this library to fully implement a stateful proxy? For example, for SIP distribution.

[lebuleng]

like title!

[dyfet]

I had been exploring it some for that kind of use case, too. For me, there are two things I desire; the ability to create multiple stack instances, and multipath calling (call distribution). For multiple stack instances I may have a stack bound on a internal subnet managing internal traffic, and an instance bound externally for external calling. They may even use different transport protocols. This also makes it easy to do traffic and code segregation since internal and external have different behaviors. I am not sure yet if we can start multiple stacks with sipgo as it is currently.

I also believe (hope) multipath calling (such as ringing multiple registered destinations) is possible, say by managing a list of active client transaction instances for a bunch of active client invites. There are techniques to do channel selects over a dynamically / arbitrarily sized list. Presumably then one could also maintain a multipath active transaction list that includes transactions made from the client transactions of another bound stack instance, too...??

For simpler single stack use cases, and especially for client endpoints in go, sipgo (and diego) may well be a slam dunk. For more complex proxy / call server development, we will have to see. There are a few far more minor annoyances it has, such as that it uses zerolog. It feels like a large extra dependency dragged in as I do my own logging system, so it's duplicate code I get stuck with disabling. But that I could live with ;).

[emiago]

There is plan to support std slog, so you can swap logger.

[dyfet]

I was actually more interested in the other questions such as multiple instances of the stack. But since the stack listener is tied to a context at startup, I imagine I can start separate stack instances as go routines and then shut them down together thru the context.

I also imagine it is possible to manage multiple calls as a list of transactions, and hope they do not all have to be from the same stack instance, and that I can get events in some kind of select from a managed dynamic list. The real use case is to ring a bunch of endpoints, and wait for one to answer, tracking their ringing states as they signal back. More ringing endpoints may be added to the list over time (call coverage, for example). Some may drop off with error responses or decline. They may not all be from the same stack instance. Eventually one answers, and the remaining invites are cancelled. It is really this kind of calling scenario that I am wondering if is possible, and I think is essentially the same as the original posters question on call distribution.

I actually have a project in mind, and it has a great name, too ;)...

[emiago]

Dialing multiple endpoints like answered else where behavior is something not given out of box, but it is not something hard to implement. You already have context for cancellation.
Anyway having said that, I would consider adding this as some wrapper on diago lib.

[dyfet]

Dialing multiple endpoints like answered else where behavior is something not given out of box, but it is not something hard to implement. You already have context for cancellation. Anyway having said that, I would consider adding this as some wrapper on diago lib.

Sure it could be made easier to do. I was only trying to understand if it was even possible to do. Since there is no example, I was working from the existing api trying to figure out how to within the existing code, and had thought it possible, and that interpenetration was all I was looking to confirm. Incidentally, as a feature, if you ever did a wrapper to make it easier, I think it belongs with sipgo rather than diago. It is very possible to do complex sip switching services that never directly process or even care about media. One use case is in establishing direct peer calling with return paths so the server is still notified about call events and disconnect.

[emiago]

I mean just to be clear, the library design was started as more closer to proxy usage, but overtime I simplified stuff, and therefore provide functionality closer to RFC.
So in some sense it should not have nothing that prevents you extend on top.
Still I would like that sipgo covers more but we also need stable API before extending, which is now main focus.