This is awful code, I've duplicated the Dialog class with dialog2, with the invite method, and other stuff.
However, the INVITE example works (at least UDP/TCP)...
So, I'm bringing this up now as we could discuss how to refactor this. I think maybe it makes more sense to implement __aiter__ on dialogs to process incoming messages rather than having a router. There's potentially too much state in play to do anything differently. For example, I think its weird handling reinvites with a INVITE router callback when its so coupled to the dialog directly...
But if that's the case, does that simplify the current design? I suspect we might not need to maintain QueueTransaction with such a change, but I don't know how that would affect your proxying logic...
This is awful code, I've duplicated the Dialog class with
dialog2, with theinvitemethod, and other stuff.However, the INVITE example works (at least UDP/TCP)...
So, I'm bringing this up now as we could discuss how to refactor this. I think maybe it makes more sense to implement
__aiter__on dialogs to process incoming messages rather than having a router. There's potentially too much state in play to do anything differently. For example, I think its weird handling reinvites with aINVITErouter callback when its so coupled to the dialog directly...But if that's the case, does that simplify the current design? I suspect we might not need to maintain
QueueTransactionwith such a change, but I don't know how that would affect your proxying logic...