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 theinvite
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 aINVITE
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...