jitsi / jibri

Jitsi BRoadcasting Infrastructure
Apache License 2.0
600 stars 314 forks source link

Hard-coded --id argument breaks the video SIP call if it is triggered from UI (SIP-Jibri related) #496

Closed emrahcom closed 1 year ago

emrahcom commented 1 year ago

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):

https://github.com/jitsi/jibri/blob/master/src/main/kotlin/org/jitsi/jibri/sipgateway/pjsua/PjsuaClient.kt#L99-L100

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

saghul commented 1 year ago

What kind of value do you want to set there?

emrahcom commented 1 year ago

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.

emrahcom commented 1 year ago

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.  
bbaldino commented 1 year ago

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?

emrahcom commented 1 year ago

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.

saghul commented 1 year ago

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.

Why wouldn't you want to use registration in your case?

emrahcom commented 1 year ago

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.

saghul commented 1 year ago

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: https://github.com/jitsi/jibri/blob/ccc727806288644737f4927deadc9e8e1fcb14b0/src/main/kotlin/org/jitsi/jibri/sipgateway/pjsua/PjsuaClient.kt#L84

Have you tried that?

emrahcom commented 1 year ago

jibri config options

Which file is this? Do you mean jibri.conf? If so, I couldn't find related fields in the example config.

emrahcom commented 1 year ago

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.

saghul commented 1 year ago

Aha, that explains why I haven't been able to figure out where they come from indeed. @oanaianc thoughts?

emrahcom commented 1 year ago

Solved by https://github.com/jitsi/jibri/pull/502