Toggle sidebar Toggle sidebar

3CX and Jigasi (Jitsi)

Status
Not open for further replies.

MucCX

Free User
Joined
Dec 30, 2020
Messages
35
Reaction score
4
Hi,

Not sure if this is the right forum, but I didn't find a more specific one...

So I have set up a Jitsi video conference server and its sidekick Jigasi to allow calling into such a video conference. Jigasi registers as an extension with 3CX and I can actually call in from another extension (I haven't tried calling from outside yet). From the phone I will hear what is said in the conference but within the conference I can't hear what is said on the phone.

The Jitsi guys suggested I make sure that my SIP server supports "latching" and that it is configured for the extension Jigasi is using. But I can't find info on that.

Hence my questions:

- Does 3CX support "latching" (Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication (ietf.org)?
- Does it need to be configured in any particular way and if so, how?

Thanks!
 
MucCX said:
Hi,

Not sure if this is the right forum, but I didn't find a more specific one...

So I have set up a Jitsi video conference server and its sidekick Jigasi to allow calling into such a video conference. Jigasi registers as an extension with 3CX and I can actually call in from another extension (I haven't tried calling from outside yet). From the phone I will hear what is said in the conference but within the conference I can't hear what is said on the phone.

The Jitsi guys suggested I make sure that my SIP server supports "latching" and that it is configured for the extension Jigasi is using. But I can't find info on that.

Hence my questions:

- Does 3CX support "latching" (Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication (ietf.org)?
- Does it need to be configured in any particular way and if so, how?

Thanks!
Click to expand...
Have you tried simply enabling "PBX Delivers Audio" in the extension that Jitsi is connecting to?
 
Yes, I tried that but it didn‘t make a difference.
 
MucCX said:
Yes, I tried that but it didn‘t make a difference.
Click to expand...
It is odd. It could be a misconfig from the Jitsi side.

Beside "Supports Replaces" and "Supports Reinvite", there's not much control over the SIP handling in 3CX...
 
Do you have experience with this particular setup? Does it work for you? That indeed would indicate that 3CX is not to be faulted.
 
MucCX said:
Do you have experience with this particular setup? Does it work for you? That indeed would indicate that 3CX is not to be faulted.
Click to expand...
I never did that setup but I have a lot of experience with 3CX, and "bridging" it to 3rd-party systems has always been hit and miss with a lot of work.

I would be glad to go over the setup with you tho and see if I can spot something on either side that would indicate why it doesn't work or if it's even possible to make it work.

Understanding a bit more about how the Jitsi side works would help. I am familiar with the platform but never used the open-source version.
 
I can't recall the term "latching", previously being used in the forum.
 
  • Like
Reactions: Evolute IT
leejor said:
I can't recall the term "latching", previously being used in the forum.
Click to expand...
Agree. My searches only turned up door latches but never the word latching, particularly in the sense used by the Jitsi people. Nevertheless, it comes from - or at least is also used by - the IETF (cf the link in my OP). The Jitsi people explained it as sending audio to where it comes from. Which sounds like it could help in my case.

Maybe the concept is also known at 3CX, just under a different name?

This is from the memo (under the link mentioned):

"Mechanisms such as Session Traversal Utilities for NAT (STUN) [RFC5389], Traversal Using Relays around NAT (TURN) [RFC5766], and Interactive Connectivity Establishment (ICE) [RFC5245] did not exist when protocols like SIP began being deployed. Some mechanisms, such as the early versions of STUN [RFC3489], had started appearing but they were unreliable and suffered a number of issues typical for UNilateral Self-Address Fixing (UNSAF) and described in [RFC3424]. For these and other reasons, Session Border Controllers (SBCs) that were already being used by SIP domains for other SIP and media-related purposes began to use proprietary mechanisms to enable SIP devices behind NATs to communicate across the NATs. These mechanisms are often transparent to endpoints and rely on a dynamic address and port discovery technique called "latching".

So what the 3CX SBC does might be called "latching" by the IETF (and possibly Jitsi). Not that the SBC can help me here.
 
Okay, if I understand this clearly, it's direct media between Jitsi and PBX using STUN or TURN for NAT Traversal.

If that's correct, NAT shouldn't be affected here unless you host both servers on-premise.

Where are both hosted? And what does the Jitsi config looks like?
 
Frederick Marcoux said:
Okay, if I understand this clearly, it's direct media between Jitsi and PBX using STUN or TURN for NAT Traversal.

If that's correct, NAT shouldn't be affected here unless you host both servers on-premise.

Where are both hosted?
Click to expand...
Both are hosted on premise.

But TBH, that's why I would have thought that NAT (in principle) should _not_ play a role (because they sit both behind the same NAT, being the router, and they talk to each other directly on the local LAN).

I am saying "in principle" because while they both sit behind the same router (which makes me think there should be not NAT between them), Jitsi sits inside a docker container and is connected to a Docker internal network - which introduces another NAT that they don't share.

Given this setup, does NAT play a role here or not (I am confused)?
 
MucCX said:
Both are hosted on premise.

But TBH, that's why I would have thought that NAT (in principle) should _not_ play a role (because they sit both behind the same NAT, being the router, and they talk to each other directly on the local LAN).

I am saying "in principle" because while they both sit behind the same router (which makes me think there should be not NAT between them), Jitsi sits inside a docker container and is connected to a Docker internal network - which introduces another NAT that they don't share.

Given this setup, does NAT play a role here or not (I am confused)?
Click to expand...
For the docker, yes, NAT can cause issues, but you should be able to give a bridged network to the container.

Beside that, you just have to make sure everything is configured using private IPs.

My guess is: the Jitsi sends the NATed IP to the 3CX as audio route, the 3CX then tries to send audio to that IP but doesn't know how to route to it since it's not a local network nor a static route in your firewall (which is something you can try but probably won't work.)
 
MucCX said:
I have set up a Jitsi video conference server
Click to expand...

and why all this hassle when you get this all also bundled in 3CX Video Conferencing?
 
  • Like
Reactions: DavidM84
Status
Not open for further replies.

Latest Posts

Forum statistics

Threads
111,982
Messages
590,120
Members
164,909
Latest member
Jacob.Ive
3CX Logo Footer Copyright © Sitemap Privacy
Top Bottom