[jitsi-dev] Potential Bug: Hold does not operate correctly the first time it is activated during SIP calls


#1

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
the call:

   - 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
disabled properly.
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
following:

In CallPeerSipImpl.putOnHold() after calling
mediahandler.setLocallyOnHold(true) the call is successfully held locally
and muted.
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.

if (!CallPeerState.isOnHold(getState()))
{
        setState(CallPeerState.CONNECTED);
        getMediaHandler().start();

        // as its connected, set initial mute status,
        // corresponding call status
        if (isMute() != this.getCall().isMute())
                setMute(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.

Thank you.

Arlen Phillips, Developer.
Positronics Ent Innovation in PTT Applications

Unit 272 arlen.phillips@positronics.com
8128 128th St 604-628-9330 (direct)
Surrey, BC 604-585-2119 ext 106 (main)
Canada, V3W 1R1 604-585-3056 (fax)


#2

Hey Arlen,

Thanks for your report and investigation!

I just ran a few tests with our local Asterisk and couldn't reproduce
the issue: pressing the call button interrupts audio in both directions.

Note however that when you place someone on hold, they are have to stop
sending content your way, so even if Jitsi isn't muting playback, well,
there should be nothing to play back.

The fact that there is, makes me think that something went wrong while
the server processed our INVITE and it didn't really execute the "put
on-hold". This could be confirmed by the fact that your code tracing
seemed to show a rapid un-mute, which would happen if the OK from the
server doesn't have the recvonly attribute. Could it be that the one you
saw in your pcaps came from another exchange and not the one that was
left unmuted?

Emil

···

On 01.05.12 00:41, Arlen Phillips wrote:

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 the call:

  * 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
disabled properly.
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
following:

In CallPeerSipImpl.putOnHold() after calling
mediahandler.setLocallyOnHold(true) the call is successfully held
locally and muted.
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.

if (!CallPeerState.isOnHold(getState()))
{
        setState(CallPeerState.CONNECTED);
        getMediaHandler().start();

        // as its connected, set initial mute status,
        // corresponding call status
        if (isMute() != this.getCall().isMute())
                setMute(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.

Thank you.

Arlen Phillips, Developer.
Positronics Ent Innovation in PTT Applications
                             
Unit 272 arlen.phillips@positronics.com
<mailto:arlen.phillips@positronics.com>
8128 128th St 604-628-9330 (direct)
Surrey, BC 604-585-2119 ext 106 (main)
Canada, V3W 1R1 604-585-3056 (fax)

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31