[jitsi-users] Jigasi NAT traversal


#1

Hello,

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 jigasi
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
trying to accept an incoming call (and failing). On the other, I have a
successful connection attempt through the same sip trunk with jitsi
communicator.

On the successful attempt, the SIP INVITE packet (from twilio) includes my
public facing IP address in the 'to' field. On the unsuccessful attempt,
jigasi is getting my local/internal ip address from twilio.

This leads me to believe jigasi has failed to identify itself properly.
I've 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
solve similar nat traversal issues, and I was hoping I could get a more
detailed explanation on how (or even if) jigasi can do something similar.

Cheers,
Kyle

sip2.pcap (26.5 KB)


#2

Hi,

Hello,

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 jigasi
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 trying
to accept an incoming call (and failing). On the other, I have a successful
connection attempt through the same sip trunk with jitsi communicator.

On the successful attempt, the SIP INVITE packet (from twilio) includes my
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. I've
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 solve
similar nat traversal issues, and I was hoping I could get a more detailed
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.

Regards
damencho

···

On Wed, May 3, 2017 at 10:34 AM, Kyle Galvin <kyle@cloudversify.com> wrote:

Cheers,
Kyle

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#3

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
registration.

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.
https://www.3cx.com/blog/voip-howto/sip-invite-header-fields/
http://stackoverflow.com/a/20616094

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?"

Thanks,
Kyle

sip-communicator.properties (44.7 KB)

···

On Wed, May 3, 2017 at 9:20 AM, Damian Minkov <damencho@jitsi.org> wrote:

Hi,

On Wed, May 3, 2017 at 10:34 AM, Kyle Galvin <kyle@cloudversify.com> > wrote:
> Hello,
>
> 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
jigasi
> 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
trying
> to accept an incoming call (and failing). On the other, I have a
successful
> connection attempt through the same sip trunk with jitsi communicator.
>
> On the successful attempt, the SIP INVITE packet (from twilio) includes
my
> 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.
I've
> 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
solve
> similar nat traversal issues, and I was hoping I could get a more
detailed
> 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.

Regards
damencho

>
> Cheers,
> Kyle
>
> _______________________________________________
> users mailing list
> users@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#4

Hi,

Please forgive me if I'm misunderstanding something, but I think my initial
question still remains:
How does jigasi do NAT traversal?

It doesn't, nor jitsi desktop does. It is the server how normally take
care of the nats and sends the messages to the address they were
received. The only thing that the client takes care of is to keep the
nat mapping open by sending some keep-ailve messages.

The contact header is created here:
https://github.com/jitsi/jitsi/blob/dd0d1c9f454afb11ae406b1f9c37279972cffb92/src/net/java/sip/communicator/impl/protocol/sip/ProtocolProviderServiceSipImpl.java#L1436-L1436

I don't have any problems using jigasi with asterisk running from my
dev macbook which is always behind nat or from my dev machine which is
in aws and is also behind nat. And the fact that you run it ok with
the desktop client means it's some network config weirdness on the
machine running jigasi... strange.
Is your hostname resolvable there?
$ ping `hostname`

Regards
damencho

···

On Wed, May 3, 2017 at 5:46 PM, Kyle Galvin <kyle@cloudversify.com> wrote:


#5

Hum, but when it creates the contact header it always uses the local
address, that doesn't matter .....
Hummm its really strange for some reason the server doesn't recognize
your internal address as not public one, in asterisk there is was a
config like that, to say these and these addresses to be recognized as
not public and handled as natted. It seems to me the problem is
something like that ... humm 11.0.0.. is this internal address, not
sure about that, can you change it to some standard one like 10...,
172..., 192... (https://en.wikipedia.org/wiki/Private_network)?

Regards
damencho

···

On Wed, May 3, 2017 at 6:57 PM, Damian Minkov <damencho@jitsi.org> wrote:

Hi,

On Wed, May 3, 2017 at 5:46 PM, Kyle Galvin <kyle@cloudversify.com> wrote:

Please forgive me if I'm misunderstanding something, but I think my initial
question still remains:
How does jigasi do NAT traversal?

It doesn't, nor jitsi desktop does. It is the server how normally take
care of the nats and sends the messages to the address they were
received. The only thing that the client takes care of is to keep the
nat mapping open by sending some keep-ailve messages.

The contact header is created here:
https://github.com/jitsi/jitsi/blob/dd0d1c9f454afb11ae406b1f9c37279972cffb92/src/net/java/sip/communicator/impl/protocol/sip/ProtocolProviderServiceSipImpl.java#L1436-L1436

I don't have any problems using jigasi with asterisk running from my
dev macbook which is always behind nat or from my dev machine which is
in aws and is also behind nat. And the fact that you run it ok with
the desktop client means it's some network config weirdness on the
machine running jigasi... strange.
Is your hostname resolvable there?
$ ping `hostname`

Regards
damencho