Hello jitsi developers. I have run into what I beleive to be a bug in the
jitsi engine and/or the sip stack.
As per the website's instructions I am submitting it to the mailing list
for your consideration. If this is not the right place or format, please
let me know as I am not a regular user of mailing lists.
This bug appears on ubuntu 11.10 and 12.04 x64 using openjdk x64 and
windows xp x32 running in a virtual machine using sun java x32.
While in a SIP call to an asterisk machine the hold button does not
properly mute the other party the first time it is pressed. While on hold
for the first time per-call the jitsi interface and logging show that the
call status is "locally on hold" however the call's incoming audio is not
muted. After un-holding and re-holding, the call operates as expected, with
no incoming/outgoing audio.
It needs to be pressed a total of three times in order to successfully mute
- to hold and unsuccessfully mute the other party
- again to un-hold and un-mute the other party
- finally to hold and successfully mute the other party
Any presses of hold after this point work as expected, being enabled and
This happens once per call. This occurs on both a remote initiated call and
a locally initiated call, and happens with all endpoints that I have tried
it on, including other softphone clients and SIP desk phones.
I fired up wireshark and dove into the code to track down this issue. My
findings are as follows.
The sip dialog appears to be correct. Jitsi sends a re-invite with the
"sendonly" attribute set,
asterisk receives this properly and the remote endpoint responds back 100
trying, followed by 200 OK with "recvonly" set.
By stepping through with the java remote debugger I have discovered the
In CallPeerSipImpl.putOnHold() after calling
mediahandler.setLocallyOnHold(true) the call is successfully held locally
After the sendReInvite() line below returns, the call has been unmuted. I
tracked this down to a call to socket.write() in the Jain sip library which
sends the invite.
Since the socket cannot be causing this directly, I am assuming that this
bug is the result of some callback SIP code upon receiving the response from
the server/endpoint. As soon as the response is received, handlers are
called and this triggers an unmute somewhere.
The obivous candidate of CallPeerSipImpl.ProcessInviteOK() is called in
response to this, however by the time the block of code below has been
reached with a debugger attached,the audio has already been unmuted.
// as its connected, set initial mute status,
// corresponding call status
if (isMute() != this.getCall().isMute())
Furthermore, by adding a logging message just above this block it appears
the the current call state at this point is inconsistant.
It is always one of "locally on hold" or "connected" but differs between
calls, even when there is no debugger attached to cause timing issues.
Hopefully this should give you enough info to help track down the bug. I
can provide a wireshark dump or other information if you like upon request.
Arlen Phillips, Developer.
Positronics Ent Innovation in PTT Applications
Unit 272 firstname.lastname@example.org
8128 128th St 604-628-9330 (direct)
Surrey, BC 604-585-2119 ext 106 (main)
Canada, V3W 1R1 604-585-3056 (fax)