Link JIGASI audio track to existing participant

Hi all,
first thanks for your great work. Jitsi is a great software!

I’m trying to link a JIGASI audio track to an existing participant (kind of like webex, or zoom).
Where you can enter a participant ID during phone dial-in).
I also would be willing to freely contribute this work (if the work is feasible).

I tried reading the code, but the whole audio track flow is hard to follow as someone who is new in the code.
In principle I see two different possibility:

  1. Exchange the SIP audio track via Colibri (meaning in jicofo)?
  2. “Fake” the UI-Elements in jitsi-meet:
    Pass a information flag/SIP-Header through jitsi up to the react UI, so that the react UI hides the new SIP participant and redirects all “isTalking” GUI events to the existing web participant.

I have the feeling that 2. is easier?

For both cases I need to transfer a SIP Header information (participant ID) through jitsi components. For case 1: up to jicofo, for case 2: up to jitsi-meet react UI.

Could you give me some hints where to look in the code?
Would you be willing to accept such a feature?

Regards,
Daniel

By default from jigasi you will see the number from the sip caller id. If you change it to contain display name you should see it in the meeting.

Thank you, I’ll try and report back here :slight_smile:

I’m sorry to report that this doesn’t work as expected:

If I set the Caller ID to the same name, as the web participant name I see two entries in jitsi-meet. E.g. if 10 people are dialed in via phone and have also browser open, to see screen-share, I’ll see 20 participants.
The background is, that there are people connecting via browser to see screen share, but somehow want to connect audio via phone (SIP).

I know I can also hide the sip users, but then I loose the ability to see who is speaking.
Is there a possibility to “merge” web and sip participant?
First I thought mod_speakerstats_component.lua may give me a posibility, but if I read it right, it is a “read only hook”. Meaning I can’t hook into the active speaker logic, remap from SIP to web participant and just hide the SIP participant.

Regards,
Daniel

You want to merge jigasi and web participants?

Why people need to dial in when they are already in the conference on the computer?
They loose quality, error correction of audio etc. etc. and downgrade from 48kHz to 8kHz!

First of all thank you for beeing so responsive and trying to help! I really appreciate your work :slight_smile:

Yes I want to merge one jigasi participant and one web participant together.
I’m also offering to implement and “donate” this feature if it is feasible and you want it.
Currently I’m searching the starting point and right architecture.

The reasons are:

  • Low bandwidh and connectivity losses: If we exchange audio I assume we can just stop sending audio to the web participant, reducing bandwith on client side. He just needs bandwith for screen share and if screen share is slow/delayed it is not that bad user experience compared to audio. We can kind of “offload” the audio stream.
  • Some setups in companies don’t have (or had, see below) computer audio
  • Some (cheap) laptops have crapy microphone or speakers
  • Some (cheap) laptops/computer setups have big problems with feedback
  • Older users are “just used to”
  • During corona crisis people are in home office with no headset/audio gear.
    Some users can’t set this up or company IT forbidds.
  • During corona crisis headsets are rare and expensive.
  • During corona crisis headsets have long lead times.
  • Some computers are not set up for this.
    Real case I experienced: Linux user (Debian Buster) couldn’t setup audio due to lack of knowledge. The user was no computer expert, had no root rights and is in home-office.
    (I assume that the audio level or audio output port was wrong by default)

Please keep in mind, that nearly every commercial solution with phone dialin
has kind of such a “merge” feature. They have money in focus,
they wouldn’t implement it without use-case.
I can understand that this is not a primary feature and may seem rather obscure.
But in my eyes it is an important feature, boosting Jitsi capabilities und increasing its competiveness even further :slight_smile:

Best Regards,
Daniel

Regarding audio quality and Jitsi reputation:
We could also somehow “fake” the connection quality to red/bad or something similar for SIP merges. To indicate to the user: You are loosing quality, it is not caused by Jitsi!

@DSchaef Did you ever end up implementing this? We’re looking for the same thing.