Open IvanRibakov opened 3 months ago
Have you tried maybe to inject this from caller side, as you can read this responses?
I'm interested in both UAC and UAS behaviours and I believe the UAS behaviour is a bit more involved. While this can probably be implemented externally I was wondering if there is any interest in adding native support for this feature. For example it could be enabled/disabled at the UA or Client/Server level to avoid impacting those library users that don't need it.
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 can not see currently is there any special need integrating on lower level.
My intention is keeping this lib low level, and there are many checks that are needed to comply rfc. This mostly boils down that INVITE is special thing, and therefore for now I see this better handled through dialog management. As it is add on, anybody should create better version.
I will update title a bit to try adding this on dialog first
yes, but not on client,server.
Fair enough. I think I for a second confused UAC/UAS with sipgo's Client and Server types.
This only is related to dialogs and this is where it can be optional value.
I find it a bit odd that a service would want this enabled for one INVITE dialog but not the other. But I can also see an argument of giving more granular control to the end users to let them make the ultimate decision so making it a dialog feature sounds ok.
My intention is keeping this lib low level
What exactly do you mean by this? I see PRACK a fairly low-level SIP protocol feature that has nothing to do with business logic that might be built on top of a SIP UA.
As it is add on, anybody should create better version.
I saw in the repository description that another "add-on" RFC was supported (RFC3581) so I assumed that generally speaking you were open to implementing SIP extensions provided that they did not contradict other core project values (so far I get that parsing performance is one fo those).
I saw in the repository description that another "add-on" RFC was supported (RFC3581) so I assumed that generally speaking you were open to implementing SIP extensions provided that they did not contradict other core project values (so far I get that parsing performance is one fo those).
Yes. Anyway, I am accepting this request. It will be added, and I hope all RFCs could be supported, but I am also planning some 1.0 release. I will try to have this before it ;)
As far as I can tell, 100rel/PRACK (RFC 3262) support is not currently implemented.
Are there any plans to support it? If so, any pointers for anyone who might decide to contribute this feature to the project?