project roadmap

[dberardo-com]

is there a roadmap for this project ? in particular, is IM support planned any time soon for this project ?

[vanbui1995]

@dberardo-com actually this is very small lib wrapper, and i used it for a project in the company, its enough feature for project, i am willing to implement any request from you, about the roadmap we can have it in the future depend on number of feature requests.

[dberardo-com]

we are testing the library ... perhaps we could add some IM features, right now we tested the audio calls that seem to work fine, next come video calls, then IM.

will keep you updated.

Btw, i have noticed that the "sessions" object gets a new key/value pair whenever a new call is started, but older sessions are not deleted. Is this a problem ? is there a way to know which sessions are idle / stale ? should perhaps a timer be set to performa the cleanup of this "ever-increasing" object ?

[vanbui1995]

@dberardo-com actually i guess the users in the few cases, they still need to access the old session

[dberardo-com]

so you mean that having the session object as an ever-increasing object was made by design ? for me this is not a big issue (maybe not so elegant, but still ok), as long as there is only one session in "active" state, meaning that all other sessions are in terminated or initial state. Otherwise i am not able to understand which session is the currently active one in case i need to, say, "hang up" the call, or things like that.

i understand that is not possible to guarantee that there will always be just one and only one session in active state right ? is that actually event a problem in your opinion?

they still need to access the old session

what could be such use case you have in mind ?

[vanbui1995]

as long as there is only one session in "active" state

actually i support multiple calls at the same time, that's why you can have multiple sessions for each client, as a client you can accept multiple calls, mute specific session, and handle these actions on specific session.

Otherwise i am not able to understand which session is the currently active one in case i need to, say, "hang up" the call, or things like that.

You can check the status of session, to know what sessions are active or not eg: https://github.com/vanbui1995/react-sipjs/blob/68cc585796630d140b8d4c4ae4c72660a7fe24fc/examples/full-example/src/CallSessionItem.tsx#L69C15-L69C15

what could be such use case you have in mind ? -> actually the core inside (sip.js) they still store sessions even they are on session's status is SessionState.Terminated, so i don't think it will help much, you can define a layer on top of the sessions list if you want to manage it

[dberardo-com]

actually i support multiple calls at the same time, that's why you can have multiple sessions for each client, as a client you can accept multiple calls, mute specific session, and handle these actions on specific session.

i see, interesting, so basically you have multiple sessions between users, but only one of them uses the microphone at a time ... or maybe that's not even an issue, meaning that the mic can be used by multiple sessions at the same time ? didnt know that.

-> actually the core inside (sip.js) they still store sessions even they are on session's status is SessionState.Terminated, so i don't think it will help much, you can define a layer on top of the sessions list if you want to manage it

thats totally fine, i just wanted to be sure that i was not doing anything wrong, as i was watching the session store increasing in size, but it seems thats by design.

what could be such use case you have in mind ?

the simplest use case possible, a single-session soft-phone, where the user can type in a number, call, and hang up. It is important in my use case that the sessions are properly terminated and there is always only one session active and no more.