I have indeed tried using the config file from jitsi desktop.
I started with the default config file that comes with jigasi. I then
edited it to become more and more like the jitsi desktop config file.
Finally I found the full list of jitsi desktop properties in my local
%APPDATA% directory, copied them into a new sip-communicator.properties,
and augmented it with the jigasi-specific config fields. Aside from a few
redacted usernames and passwords, I've attached my complete config file.
Please excuse the length, however I wanted to be thorough in mimicking
jitsi desktop at your suggestion.
I have also tried swapping out the sip trunk, moving back and forth from an
asterisk server to twilio services and back again. In both cases, the only
notable difference in the packet capture remains the same: jitsi desktop
receives an invite with my public IP address, while jigasi receives an
invite with my internal IP address attached. I have traced this issue and
it seems to be coming from the "Contact URI" field in the initial
In the beginning, there are 4 registration packets sent back and forth.
Request: Register (client to server)
Status: 407 Proxy Authentication Required (server to client)
Request: Register (client to server)
Status: 200 OK (server to client)
In the fourth and final packet, I find a Contact URI field. The remote
server registers jitsi communicator with its public IP, but jigasi
registers with the internal private IP. This seems to be the key difference
between connections succeeding and failing.
All the information I can gather on the sip contact URI seems to agree.
This has to be a globally reachable URI yet jigasi gets registered with the
private IP of my jitsi server.
Please forgive me if I'm misunderstanding something, but I think my initial
question still remains:
How does jigasi do NAT traversal?
Or more specifically (now that I have some more information on the problem)
"How does the SIP REGISTER resolve the Contact URI field, and how can I
configure this in such a way that it resolves to my public IP rather than
my private IP?"
sip-communicator.properties (44.7 KB)
On Wed, May 3, 2017 at 9:20 AM, Damian Minkov <firstname.lastname@example.org> wrote:
On Wed, May 3, 2017 at 10:34 AM, Kyle Galvin <email@example.com> > wrote:
> I was hoping to get some details on how jigasi does NAT traversal.
> I've been having connection issues trying to get an incoming call to
> through a twilio sip trunk (I've posted here recently about it, but the
> detail I had at the time was inadequate)
> I've since been comparing packet captures. On one side, I have jigasi
> to accept an incoming call (and failing). On the other, I have a
> connection attempt through the same sip trunk with jitsi communicator.
> On the successful attempt, the SIP INVITE packet (from twilio) includes
> public facing IP address in the 'to' field. On the unsuccessful attempt,
> jigasi is getting my local/internal ip address from twilio.
These fields are coming from the server.
Have you tried copying the config about the sip account you have in
Jitsi Desktop to the jigasi configuration? Jitsi Desktop and Jigasi
uses the same bundles and code to register and handle sip calls.
> This leads me to believe jigasi has failed to identify itself properly.
> attached a screen capture of the specific packet (jigasi on left, jitsi
> communicator on right) as well as the jigasi pcap file.
> I know jitsi video bridge uses a NAT_HARVESTER configuration option to
> similar nat traversal issues, and I was hoping I could get a more
> explanation on how (or even if) jigasi can do something similar.
The config you are mentioning is for ice, while sip in Jitsi is not
using ice. And this thing is for media while looking at the screenshot
I think you have a problem with signaling.
> users mailing list
> Unsubscribe instructions and other list options:
users mailing list
Unsubscribe instructions and other list options: