Emia
Emia
Have you tried maybe to inject this from caller side, as you can read this responses?
yes, but not on client,server. This only is related to dialogs and this is where it can be optional value. Still I may not want to have this enable/disable thing....
> I saw in the repository description that another "add-on" RFC was supported ([RFC3581](https://datatracker.ietf.org/doc/html/rfc3581)) so I assumed that generally speaking you were open to implementing SIP extensions provided that they...
There is already working solution, but as builtin logic it will be more as part of other project I was mentioning to you. Now different architect could apply yes.
duplicate of #76
@IvanRibakov when you are in control of dialog, and you are dealing this on library level you have all you need. This is what you will basically have with those...
As for dialog replication, this is now refactored to level where now caller has full control over dialog and as stated in readme it should implement own caching. For even...
@hateeyan It is transaction cancel. In this case we have to create listener once dialog is created. This leads to additional goroutine. I will have to evaluate this, but idea...
Now no more handling Cancel. It is refactored to be closer to RFC. ServerTransaction -> Receive Cancel -> Terminates -> Dialog detect -> Dialog Context Done. Last part is still...
@hateeyan maybe check behavior on latest main. You should not handle anymore Cancelation.