We are using latest stable jitsi version 2.0.7577-1 and jigasi 1.1-265-g4049f97-1 on Ubuntu20.
The problem si that when calling participant via Jigasi and if Host is muted, participant is always muted as well.
After that when host unmutes itself sip participant also unmute which is fine, but the problem is when the sip user connects it is always muted if host is muted.
Regardles of the option org.jitsi.jigasi.ENABLE_SIP_STARTMUTED=false , participant is always muted when host is muted when sip user connects.
No errors reported in jigasi prosody jicofo nor Twillio logs.
Is this how it is supposed to be or there is some workaround for this , maybe we are hitting a bug
Jigasi is shown as muted but is it heard when there is audio from the sip side coming in?
This is situation when we are calling from the conference, dial out, jigasi user is not even shown as muted but nothing is heard from the participant and participant is not hearing anything (obviously because host is muted)
Hum this means that the hole punch packets don’t go through to the sip side for some reason…
Interestingly is that it is happening only when i am calling someone and host is muted.
If i call someone while i am un-muted and if i mute myself right after that everything is working fine.
So its just about when call is initiated and host is muted at that moment.
Logs from jigasi when its not working :
4:03:33.471 INFO:  SipGatewaySession$SipCallStateListener.handleCallState#1428: [ctx=1660226610980507992858] Sip call IN_PROGRESS: Call: id=1660226611407342090261 peers=1
2022-08-11 14:03:33.472 INFO:  SipGatewaySession$SipCallStateListener.handleCallState#1430: [ctx=1660226610980507992858] SIP call format used: rtpmap:0 PCMU/8000
2022-08-11 14:03:33.472 INFO:  SipGatewaySession$CallPeerListener.peerStateChanged#1501: [ctx=1660226610980507992858] SIP peer state: Connecting*
2022-08-11 14:03:33.472 INFO:  net.java.sip.communicator.service.protocol.media.CallPeerMediaHandler.start: Starting
2022-08-11 14:03:33.484 INFO:  net.java.sip.communicator.service.protocol.media.TransportManager.sendHolePunchPacket: Send NAT hole punch packets
2022-08-11 14:03:38.151 INFO:  SipGatewaySession$CallPeerListener.peerStateChanged#1501: [ctx=1660226610980507992858] SIP peer state: Connected
2022-08-11 14:03:38.152 INFO:  net.java.sip.communicator.service.protocol.media.CallPeerMediaHandler.start: Starting
2022-08-11 14:03:40.152 SEVERE:  SipGatewaySession$ExpireMediaStream.run#1366: [ctx=1660226610980507992858] Stopped receiving RTP for Call: id=1660226611407342090261 peers=1
Jicofo looks fine:
Jicofo 2022-08-11 14:13:12.698 INFO:  [firstname.lastname@example.org meeting_id=41087b09-1d4a-48c0-b4f1-8a94f3885bec] JitsiMeetConferenceImpl.onMemberJoined#590: Member joined:4ad1cc39 stats-id=null region=null audioMuted=false videoMuted=true isJibri=false isJigasi=true
Doesn’t look like sip provider issue.
Maybe for puch hole packets to go through we need to establish bi-directional communication, which means that it is not an option to call when host is muted ?
Anything specific we should address here, is anyone able to reproduce this ?
You are sending audio in this case even if its few milliseconds and no need for hole punching.