[jitsi-users] Weird behavior of Jitsi with local installation of Asterisk server


#1

Hello!

I'm having a small issue here. I'm not sure what is the problem. I found
Jitsi a quite interesting and I wanted to use it in our office environment
with SIP Asterisk Server.

The setup looks like that:

One asterisk server listening on local IP number.
Multiple local clients
The same machine that runs asterisk runs OpenVPN server as well so I can
connect from outside.

Jitsi setup:

registrar: asterisk server ip and port
proxy: asterisk server ip and port

Jitsi will always successfully register to Asterisk. I can see presence and
I can send / receive messages. I can even take phone calls if someone calls
me (other client running other software or external number).

The problem:

I can not initiate phone calls. It always freezes on "initiating call" and
then fails with "The remote party has not replied! Th call will be
disconnected!". It does not matter if I call other clients or if I try to
call external number. The outcome is the same.

Weird part:

When I connect trough the VPN using the very same Jitsi installation I've
used on the local net that didn't work, this time I can make a phone call.
There's no problem whatsoever.

The difference:

When calling trough VPN in Asterisk I see: Invite, Unauthorized, ACK, 2
Invite, Trying etc... and the call goes trough

When calling from local network I see: Invite, Unauthorized, ACK and that's
it. Nothing after that.

When I'm in local network my ip is from the same pool as the Asterisk IP.
192.168.1.200 - asterisk
192.168.1.140 - my ip

When trough VPN:
192.168.1.200 - asterisk
10.8.0.6 - my ip

I can't really figure out what's wrong. It might be because of my lack of
understanding of the technology. Why would a call work one way only ? Chat
works both ways so everything seems to be fine. As far as I know Chat uses
SIP protocol as well. It's not a firewall issue as there's no firewall
between those computers. Everything is in one network. It should work.

Could it be some sort of bug ?

I've tried Stable as well as night build.

Sorry for bothering you guys.

···

--
Daniel


#2

This may sound strange, but try setting "nat=yes" in the Jitsi client
definition in /etc/asterisk/sip.conf (and then "sip reload").

It sounds very much like a problem I had recently (not with Jitsi, but with a
cable modem containing a SIP client which I needed to register to my Asterisk
server on the same network), and a packet trace showed that the client was
putting a silly IP address (in my case, 127.0.0.1) in the "source" address of
the INVITE requests, and of course Asterisk couldn't reply to that. Setting
"nat=yes" tells Asterisk to ignore the address the client tells it, and reply
instead to the address the request actually came from across the network.

If that doesn't work, then a packet capture on the Asterisk server should give
you a good idea what's going on.

Regards,

Antony.

···

On Monday 12 October 2015 at 20:20:38, Wiechu wrote:

Hello!

I'm having a small issue here. I'm not sure what is the problem. I found
Jitsi a quite interesting and I wanted to use it in our office environment
with SIP Asterisk Server.

The problem:

I can not initiate phone calls. It always freezes on "initiating call" and
then fails with "The remote party has not replied! The call will be
disconnected!". It does not matter if I call other clients or if I try to
call external number. The outcome is the same.

Weird part:

When I connect trough the VPN using the very same Jitsi installation I've
used on the local net that didn't work, this time I can make a phone call.
There's no problem whatsoever.

--
This email was created using 100% recycled electrons.

                                                   Please reply to the list;
                                                         please *don't* CC me.


#3

Hello Antony,

Thank you for reply.

I did try that already, no joy. Also if that was the case, Chat shouldn't
work neither in my opinion.

···

--
Daniel

2015-10-12 21:07 GMT+02:00 Antony Stone <Antony.Stone@jitsi.open.source.it>:

On Monday 12 October 2015 at 20:20:38, Wiechu wrote:

> Hello!
>
> I'm having a small issue here. I'm not sure what is the problem. I found
> Jitsi a quite interesting and I wanted to use it in our office
environment
> with SIP Asterisk Server.

> The problem:
>
> I can not initiate phone calls. It always freezes on "initiating call"
and
> then fails with "The remote party has not replied! The call will be
> disconnected!". It does not matter if I call other clients or if I try to
> call external number. The outcome is the same.
>
> Weird part:
>
> When I connect trough the VPN using the very same Jitsi installation I've
> used on the local net that didn't work, this time I can make a phone
call.
> There's no problem whatsoever.

This may sound strange, but try setting "nat=yes" in the Jitsi client
definition in /etc/asterisk/sip.conf (and then "sip reload").

It sounds very much like a problem I had recently (not with Jitsi, but
with a
cable modem containing a SIP client which I needed to register to my
Asterisk
server on the same network), and a packet trace showed that the client was
putting a silly IP address (in my case, 127.0.0.1) in the "source" address
of
the INVITE requests, and of course Asterisk couldn't reply to that.
Setting
"nat=yes" tells Asterisk to ignore the address the client tells it, and
reply
instead to the address the request actually came from across the network.

If that doesn't work, then a packet capture on the Asterisk server should
give
you a good idea what's going on.

Regards,

Antony.

--
This email was created using 100% recycled electrons.

                                                   Please reply to the
list;
                                                         please *don't* CC
me.

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


#4

Oh, okay. In that case I suggest doing a packet capture on the Asterisk
server to see what it receives from the client and what it tries to send back.
That should show you either what the problem is, or at least what the
difference is between the working (VPN) and non-working (direct LAN) setups.

If you need any pointers on how to do the capture (or how to interpret the
results) feel free to email me offlist, since I don't think this is a Jitsi
problem.

Regards,

Antony.

···

On Monday 12 October 2015 at 21:37:47, Wiechu wrote:

Hello Antony,

Thank you for reply.

I did try that already, no joy. Also if that was the case, Chat shouldn't
work neither in my opinion.

--
Software development can be quick, high quality, or low cost.

The customer gets to pick any two out of three.


#5

Thanks,

I'll answer here as it is still not clear on which side the problem is
exactly. (At least for me).

The reason for which it does not work is a packet fragmentation. Somehow
the packet size of 2nd INVITE when using VPN is 1407 (not fragmented) but
the packet size of 2nd INVITE on the LAN is 1514 and it is being
fragmented, preventing the call from getting trough. That explains why
message gets trough. Smaller packet.

So now, the question is what does that have to do with it ? I've read in
few places that in case of UDP, application itself is responsible for
handling fragmentation. So if that's the case the question is, which side
does that incorrectly ? Jitsi or Asterisk ?

···

--
Daniel

2015-10-12 21:45 GMT+02:00 Antony Stone <Antony.Stone@jitsi.open.source.it>:

On Monday 12 October 2015 at 21:37:47, Wiechu wrote:

> Hello Antony,
>
> Thank you for reply.
>
> I did try that already, no joy. Also if that was the case, Chat shouldn't
> work neither in my opinion.

Oh, okay. In that case I suggest doing a packet capture on the Asterisk
server to see what it receives from the client and what it tries to send
back.
That should show you either what the problem is, or at least what the
difference is between the working (VPN) and non-working (direct LAN)
setups.

If you need any pointers on how to do the capture (or how to interpret the
results) feel free to email me offlist, since I don't think this is a Jitsi
problem.

Regards,

Antony.

--
Software development can be quick, high quality, or low cost.

The customer gets to pick any two out of three.

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


#6

Hi,

take a look at:
https://jitsi.org/faq#fragmentation

Regards
damencho

···

On Mon, Oct 12, 2015 at 4:02 PM, Wiechu <ddanecki@gmail.com> wrote:

Thanks,

I'll answer here as it is still not clear on which side the problem is
exactly. (At least for me).

The reason for which it does not work is a packet fragmentation. Somehow the
packet size of 2nd INVITE when using VPN is 1407 (not fragmented) but the
packet size of 2nd INVITE on the LAN is 1514 and it is being fragmented,
preventing the call from getting trough. That explains why message gets
trough. Smaller packet.

So now, the question is what does that have to do with it ? I've read in few
places that in case of UDP, application itself is responsible for handling
fragmentation. So if that's the case the question is, which side does that
incorrectly ? Jitsi or Asterisk ?

--
Daniel

2015-10-12 21:45 GMT+02:00 Antony Stone <Antony.Stone@jitsi.open.source.it>:

On Monday 12 October 2015 at 21:37:47, Wiechu wrote:

> Hello Antony,
>
> Thank you for reply.
>
> I did try that already, no joy. Also if that was the case, Chat
> shouldn't
> work neither in my opinion.

Oh, okay. In that case I suggest doing a packet capture on the Asterisk
server to see what it receives from the client and what it tries to send
back.
That should show you either what the problem is, or at least what the
difference is between the working (VPN) and non-working (direct LAN)
setups.

If you need any pointers on how to do the capture (or how to interpret the
results) feel free to email me offlist, since I don't think this is a
Jitsi
problem.

Regards,

Antony.

--
Software development can be quick, high quality, or low cost.

The customer gets to pick any two out of three.

_______________________________________________
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


#7

Thank you very much. Everything is crystal clear now.

···

--
Daniel

2015-10-12 23:08 GMT+02:00 Damian Minkov <damencho@jitsi.org>:

Hi,

take a look at:
https://jitsi.org/faq#fragmentation

Regards
damencho

On Mon, Oct 12, 2015 at 4:02 PM, Wiechu <ddanecki@gmail.com> wrote:
> Thanks,
>
> I'll answer here as it is still not clear on which side the problem is
> exactly. (At least for me).
>
> The reason for which it does not work is a packet fragmentation. Somehow
the
> packet size of 2nd INVITE when using VPN is 1407 (not fragmented) but the
> packet size of 2nd INVITE on the LAN is 1514 and it is being fragmented,
> preventing the call from getting trough. That explains why message gets
> trough. Smaller packet.
>
> So now, the question is what does that have to do with it ? I've read in
few
> places that in case of UDP, application itself is responsible for
handling
> fragmentation. So if that's the case the question is, which side does
that
> incorrectly ? Jitsi or Asterisk ?
>
> --
> Daniel
>
>
>
> 2015-10-12 21:45 GMT+02:00 Antony Stone <
Antony.Stone@jitsi.open.source.it>:
>>
>> On Monday 12 October 2015 at 21:37:47, Wiechu wrote:
>>
>> > Hello Antony,
>> >
>> > Thank you for reply.
>> >
>> > I did try that already, no joy. Also if that was the case, Chat
>> > shouldn't
>> > work neither in my opinion.
>>
>> Oh, okay. In that case I suggest doing a packet capture on the Asterisk
>> server to see what it receives from the client and what it tries to send
>> back.
>> That should show you either what the problem is, or at least what the
>> difference is between the working (VPN) and non-working (direct LAN)
>> setups.
>>
>> If you need any pointers on how to do the capture (or how to interpret
the
>> results) feel free to email me offlist, since I don't think this is a
>> Jitsi
>> problem.
>>
>>
>> Regards,
>>
>>
>> Antony.
>>
>> --
>> Software development can be quick, high quality, or low cost.
>>
>> The customer gets to pick any two out of three.
>>
>> _______________________________________________
>> 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

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