Hard-coded --id argument breaks the video SIP call if it is triggered from UI (SIP-Jibri related)
emrahcom opened this issue · 12 comments
Description
When I try to start a video SIP session by inviting the other peer from UI, jibri adds an --id argument with a hard-coded value:
--id=$displayName <sip:jibri@127.0.0.1>
This value overwrites the --id value which comes from /etc/jitsi/jibri/pjsua.config and the hard-coded value doesn't work for my system.
Current behavior
The SIP session fails because the hard-coded --id doesn't match my environment.
Expected Behavior
jibri should not add a had-coded --id and allow admin to set it in /etc/jitsi/jibri/pjsua.config according to their environment.
Possible Solution
Removing the following codes (else case):
Steps to reproduce
Invite SIP peer from UI through SIP-jibri. Maybe this doesn't fail for all system if jibri@127.0.0.1 has a meaning for its SIP server.
Environment details
- Debian 11 Bullseye
- Jibri 8.0-140-gccc7278-1
- openjdk-11-jre-headless 11.0.16+8-1~deb11u1
- AMD64
What kind of value do you want to set there?
For example --id "1009 <sip:1009@freeswitch.mydomain.corp>" which works for my SIP server.
sip:1009@127.0.0.1 or sip:jibri@127.0.0.1 fails for me. I mean if I use these values, the authentication request is rejected by FreeSWITCH.
These are what I see in FreeSWITCH logs:
2022-12-05 19:28:34.430967 99.17% [INFO] sofia.c:10462 sofia/internal/jibri@127.0.0.1 receiving invite from ...
nua_stack.c:599 nua_stack_signal() nua((nil)): recv signal r_unref
2022-12-05 19:28:34.430967 99.17% [DEBUG] sofia.c:10556 verifying acl "domains" for ip/port 172.17.17.203:0.
2022-12-05 19:28:34.430967 99.17% [WARNING] sofia_reg.c:3223 Can't find user [1009@127.0.0.1] from 172.17.17.203
You must define a domain called '127.0.0.1' in your directory and add a user with the id="1009" attribute
and you must configure your device to use the proper domain in its authentication credentials.
I don't think we'd want to remove that else case, but do the existing parameters (pjsuaClientParams.sipClientParams.displayName, etc.) not suitable to be able to plug in what you need? If not, could look at making the params more configurable. Are you using the XMPP api or HTTP?
Hi @bbaldino,
Are you using the XMPP api or HTTP?
Both... There is no problem when the SIP session is started throught component-selector. In this case, --id is set correctly. This issue happens when the session is started through UI (I think XMPP API is used in this case)
I don't think we'd want to remove that else case, but do the existing parameters (
pjsuaClientParams.sipClientParams.displayName, etc.) not suitable to be able to plug in what you need?
AFAIK displayName contains only the callee name when the session is started from UI, not the full SIP address...
If I check the code correctly, removing the else case and adding --id "Jibri <jibri@127.0.0.1>" into pjsua.config as a default value will have a similar effect and not break anything.
For example
--id "1009 <sip:1009@freeswitch.mydomain.corp>"which works for my SIP server.
sip:1009@127.0.0.1orsip:jibri@127.0.0.1fails for me. I mean if I use these values, the authentication request is rejected byFreeSWITCH.
Why wouldn't you want to use registration in your case?
Hi @saghul,
I'm not sure I understand what you mean. I use registration and I have "--username" and "--password" fields in my pjsua.config but when jibri adds "--id" as an argument, this breaks the authentication in my environment. I have a typical FreeSWITCH server.
For now, I edit /opt/jitsi/jibri/pjsua.sh to delete --id argument as a hacky way.
Can you try to use jibri config options instead of modifying pjsua.conf for the username and password? Note in that case we generate the ID differently:
Have you tried that?
jibri config options
Which file is this? Do you mean jibri.conf? If so, I couldn't find related fields in the example config.
I checked the codes again. If I understand correctly, sipClientParams.userName and sipClientParams.password are only exist when the SIP session is created through sidecar. These values are null in XMPP API case.