sipsorcery
sipsorcery copied to clipboard
Mutual hold/unhold during a call
Hello, it's me again !
I'm investigating hold/unhold scenarios as we previously discussed in the #479, but I also noticed that if two clients hold a call at once, the state of the user agent is kinda funky.
I've also noticed that the Softphone example explicitly removes the ability to hold locally whenever the remote does hold a call. Was this by design due to the UserAgent not being able to support it or was there another reasoning?
Thanks in advance !
but I also noticed that if two clients hold a call at once, the state of the user agent is kinda funky.
What happens? There are a LOT of edge cases with SIP and as far as this library goes if I didn't encounter it and nobody else raised it then it most likely wasn't considered.
The good news is in this case it shouldn't be too difficult to deal with since on/off hold actions are only a matter of adjusting the media stream status property to the desired value and either calling stop or start on the media session. The only new case should be if a call is already on a local hold and the remote agent sends a hold request the media stream status should probably change from sendonly
to inactive
and if media is being sent, like on hold music, stop it.
I've also noticed that the Softphone example explicitly removes the ability to hold locally whenever the remote does hold a call. Was this by design due to the UserAgent not being able to support it or was there another reasoning?
For pragmatic reasons. There didn't seem t be a lot of benefit to putting a call on hold when it's already on hold.
What happens? The sent media attribute says
inactive
. It seems like there's some side effects having both local and remote media tracks disabled that makes us skip setting the actual new stream status.
Example :
- both clients are on hold and their state is inactive on the media tracks
- call
TakeOffHold()
from one client - the client in question changes it's hold state, but when it gets to
ApplyHoldAndReinvite()
it skips the calls toSetMediaStreamStatus
since HasAudio/Video returns false when remote and local tracks are inactive - We send an invite with media still inactive since the SDP is built based on the Local media tracks
There are a LOT of edge cases with SIP
You can say that again
and if media is being sent, like on hold music, stop it.
I've got something that works locally, but that was one thing I had not covered. I'll check that out. Like you said, it's essentially all state management