[jitsi-dev] Using Jitsi behind NAT


#1

Hi all,

I see that Jitsi now has several NAT traversal tools for XMPP. Congrats!
However, I use Jitsi in a NATed environment (like the vast majority I would
assume) with SIP instead of XMPP.

How does everyone else deal with using Jitsi behind NAT? I don't see any
ICE/STUN/TURN options for SIP which always leads to 1 way audio issues for
me.

How are people using Jitsi behind NAT? Is there some hidden menu with STUN
and/or ICE configs like in the XMPP menu?

Thanks,

Peter


#2

Hi, Peter:

Typically, unless you are behind a full cone enterprise firewall like Cisco PIX or Sonicwall, that should not be necessary. Most SIP clients and servers well with the latest SBCs used by SIP providers without port forwarding or changes in the network.

ICE is a great feature, but not necessary in all cases.

marc.

···

__________________
+1-408-677-1346

On Jan 28, 2014, at 9:35 AM, Peter Villeneuve <petervnv1@gmail.com> wrote:

Hi all,

I see that Jitsi now has several NAT traversal tools for XMPP. Congrats!
However, I use Jitsi in a NATed environment (like the vast majority I would assume) with SIP instead of XMPP.

How does everyone else deal with using Jitsi behind NAT? I don't see any ICE/STUN/TURN options for SIP which always leads to 1 way audio issues for me.

How are people using Jitsi behind NAT? Is there some hidden menu with STUN and/or ICE configs like in the XMPP menu?

Thanks,

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


#3

Hey Peter,

Hi all,

I see that Jitsi now has several NAT traversal tools for XMPP. Congrats!
However, I use Jitsi in a NATed environment (like the vast majority I would
assume) with SIP instead of XMPP.

How does everyone else deal with using Jitsi behind NAT?

Most of the SIP servers would do that for you without requiring any
specific NAT traversal mechanisms in the client. Here's a description
of how this works:

http://tools.ietf.org/html/draft-ietf-mmusic-latching

I don't see any
ICE/STUN/TURN options for SIP which always leads to 1 way audio issues for
me.

Yes, this will come at some point. It's been lagging because of the
above but now we really seem to need it to facilitate webrtc
compatibility.

Hope this helps,
Emil

···

On Tue, Jan 28, 2014 at 6:35 PM, Peter Villeneuve <petervnv1@gmail.com> wrote:

--
https://jitsi.org


#4

Full cones, which are today referred as NATs with endpoint independent
mapping (EIM) and endoint independent filtering (EIP), just as well
as restricted cones, port restricted cones (EIM, EDF) and symmetric
NATs (EDM EDF) are all handled gracefully by severs (SBCs) with Hosted
NAT Traversal. The one case that fails here are environments that
completely block UDP. ICE has an advantage there because it has the
option of falling back to TCP in such situations.

Emil

···

On Tue, Jan 28, 2014 at 6:51 PM, Marc Abrams <marca56@fastmail.fm> wrote:

Hi, Peter:

Typically, unless you are behind a full cone enterprise firewall like Cisco
PIX or Sonicwall, that should not be necessary. Most SIP clients and servers
well with the latest SBCs used by SIP providers without port forwarding or
changes in the network.

ICE is a great feature, but not necessary in all cases.

marc.
__________________
+1-408-677-1346

On Jan 28, 2014, at 9:35 AM, Peter Villeneuve <petervnv1@gmail.com> wrote:

Hi all,

I see that Jitsi now has several NAT traversal tools for XMPP. Congrats!
However, I use Jitsi in a NATed environment (like the vast majority I would
assume) with SIP instead of XMPP.

How does everyone else deal with using Jitsi behind NAT? I don't see any
ICE/STUN/TURN options for SIP which always leads to 1 way audio issues for
me.

How are people using Jitsi behind NAT? Is there some hidden menu with STUN
and/or ICE configs like in the XMPP menu?

Thanks,

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

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

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31


#5

Peter:

One thing to try is to change the ports to something like 7000 (from 5060) as they are not likely to be blocking that. Most SBCs will just handle it fine. Think of it has a hard coded PRACK :slight_smile:

marc.

···

__________________
+1-408-677-1346

On Jan 28, 2014, at 9:47 AM, Peter Villeneuve <petervnv1@gmail.com> wrote:

Hi Emil,

Thanks for the quick reply. I guess I'll need to wait for ICE support to come along, as it seems my company's SIP server isn't handling NAT very well.

On Tue, Jan 28, 2014 at 5:42 PM, Emil Ivov <emcho@jitsi.org> wrote:
Hey Peter,

On Tue, Jan 28, 2014 at 6:35 PM, Peter Villeneuve <petervnv1@gmail.com> wrote:
> Hi all,
>
> I see that Jitsi now has several NAT traversal tools for XMPP. Congrats!
> However, I use Jitsi in a NATed environment (like the vast majority I would
> assume) with SIP instead of XMPP.
>
> How does everyone else deal with using Jitsi behind NAT?

Most of the SIP servers would do that for you without requiring any
specific NAT traversal mechanisms in the client. Here's a description
of how this works:

http://tools.ietf.org/html/draft-ietf-mmusic-latching

> I don't see any
> ICE/STUN/TURN options for SIP which always leads to 1 way audio issues for
> me.

Yes, this will come at some point. It's been lagging because of the
above but now we really seem to need it to facilitate webrtc
compatibility.

Hope this helps,
Emil

--
https://jitsi.org

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


#6

Emil,

what about the jitsi videobridge? I have been told that running videobridge behind that NAT is a bad idea
and in general is not supported. Needless to say this requirement places an extra burden on the users to
have public server allocated for the setup.

Is this still the case? Or the latest version of the videbridge now does support running behind that NAT. If
latter - then starting with which version?

Thanks
Yan

···

On 1/28/2014 9:42 AM, Emil Ivov wrote:

Hey Peter,

On Tue, Jan 28, 2014 at 6:35 PM, Peter Villeneuve <petervnv1@gmail.com> wrote:

Hi all,

I see that Jitsi now has several NAT traversal tools for XMPP. Congrats!
However, I use Jitsi in a NATed environment (like the vast majority I would
assume) with SIP instead of XMPP.

How does everyone else deal with using Jitsi behind NAT?

Most of the SIP servers would do that for you without requiring any
specific NAT traversal mechanisms in the client. Here's a description
of how this works:

http://tools.ietf.org/html/draft-ietf-mmusic-latching

I don't see any
ICE/STUN/TURN options for SIP which always leads to 1 way audio issues for
me.

Yes, this will come at some point. It's been lagging because of the
above but now we really seem to need it to facilitate webrtc
compatibility.

Hope this helps,
Emil


#7

Hi Emil,

Thanks for the quick reply. I guess I'll need to wait for ICE support to
come along, as it seems my company's SIP server isn't handling NAT very
well.

···

On Tue, Jan 28, 2014 at 5:42 PM, Emil Ivov <emcho@jitsi.org> wrote:

Hey Peter,

On Tue, Jan 28, 2014 at 6:35 PM, Peter Villeneuve <petervnv1@gmail.com> > wrote:
> Hi all,
>
> I see that Jitsi now has several NAT traversal tools for XMPP. Congrats!
> However, I use Jitsi in a NATed environment (like the vast majority I
would
> assume) with SIP instead of XMPP.
>
> How does everyone else deal with using Jitsi behind NAT?

Most of the SIP servers would do that for you without requiring any
specific NAT traversal mechanisms in the client. Here's a description
of how this works:

http://tools.ietf.org/html/draft-ietf-mmusic-latching

> I don't see any
> ICE/STUN/TURN options for SIP which always leads to 1 way audio issues
for
> me.

Yes, this will come at some point. It's been lagging because of the
above but now we really seem to need it to facilitate webrtc
compatibility.

Hope this helps,
Emil

--
https://jitsi.org


#8

By the way, do you know if Kamailio supports the HNT technique described in
the ietf document? I'd like to get it to work with Jitsi.

Thanks

···

On Tue, Jan 28, 2014 at 5:42 PM, Emil Ivov <emcho@jitsi.org> wrote:

Hey Peter,

On Tue, Jan 28, 2014 at 6:35 PM, Peter Villeneuve <petervnv1@gmail.com> > wrote:
> Hi all,
>
> I see that Jitsi now has several NAT traversal tools for XMPP. Congrats!
> However, I use Jitsi in a NATed environment (like the vast majority I
would
> assume) with SIP instead of XMPP.
>
> How does everyone else deal with using Jitsi behind NAT?

Most of the SIP servers would do that for you without requiring any
specific NAT traversal mechanisms in the client. Here's a description
of how this works:

http://tools.ietf.org/html/draft-ietf-mmusic-latching

> I don't see any
> ICE/STUN/TURN options for SIP which always leads to 1 way audio issues
for
> me.

Yes, this will come at some point. It's been lagging because of the
above but now we really seem to need it to facilitate webrtc
compatibility.

Hope this helps,
Emil

--
https://jitsi.org


#9

Hi Emil,

Thanks for the quick reply. I guess I'll need to wait for ICE support to
come along, as it seems my company's SIP server isn't handling NAT very
well.

What is the exact behaviour that you are seeing?

Emil

···

On Tue, Jan 28, 2014 at 6:47 PM, Peter Villeneuve <petervnv1@gmail.com> wrote:

On Tue, Jan 28, 2014 at 5:42 PM, Emil Ivov <emcho@jitsi.org> wrote:

Hey Peter,

On Tue, Jan 28, 2014 at 6:35 PM, Peter Villeneuve <petervnv1@gmail.com> >> wrote:
> Hi all,
>
> I see that Jitsi now has several NAT traversal tools for XMPP. Congrats!
> However, I use Jitsi in a NATed environment (like the vast majority I
> would
> assume) with SIP instead of XMPP.
>
> How does everyone else deal with using Jitsi behind NAT?

Most of the SIP servers would do that for you without requiring any
specific NAT traversal mechanisms in the client. Here's a description
of how this works:

http://tools.ietf.org/html/draft-ietf-mmusic-latching

> I don't see any
> ICE/STUN/TURN options for SIP which always leads to 1 way audio issues
> for
> me.

Yes, this will come at some point. It's been lagging because of the
above but now we really seem to need it to facilitate webrtc
compatibility.

Hope this helps,
Emil

--
https://jitsi.org

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31


#10

By the way, do you know if Kamailio supports the HNT technique described in
the ietf document? I'd like to get it to work with Jitsi.

Kamailio installations are often configured to behave exactly this way
yes. Note that Kamailio does not relay media itself. RTPPROXY, Media
Proxy and MediaProxy-ng are commonly used together with Kamailio for
this.

FreeSwitch and Asterisk on the other hand, handle it themselves.

Emil

···

On Tue, Jan 28, 2014 at 6:58 PM, Peter Villeneuve <petervnv1@gmail.com> wrote:

Thanks

On Tue, Jan 28, 2014 at 5:42 PM, Emil Ivov <emcho@jitsi.org> wrote:

Hey Peter,

On Tue, Jan 28, 2014 at 6:35 PM, Peter Villeneuve <petervnv1@gmail.com> >> wrote:
> Hi all,
>
> I see that Jitsi now has several NAT traversal tools for XMPP. Congrats!
> However, I use Jitsi in a NATed environment (like the vast majority I
> would
> assume) with SIP instead of XMPP.
>
> How does everyone else deal with using Jitsi behind NAT?

Most of the SIP servers would do that for you without requiring any
specific NAT traversal mechanisms in the client. Here's a description
of how this works:

http://tools.ietf.org/html/draft-ietf-mmusic-latching

> I don't see any
> ICE/STUN/TURN options for SIP which always leads to 1 way audio issues
> for
> me.

Yes, this will come at some point. It's been lagging because of the
above but now we really seem to need it to facilitate webrtc
compatibility.

Hope this helps,
Emil

--
https://jitsi.org

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31


#11

Emil,

what about the jitsi videobridge? I have been told that running videobridge
behind that NAT is a bad idea
and in general is not supported.

Running the bridge behind a home NAT is indeed generally a bad idea
and not supported (not without some hassle).
Running it behind an AWS kind of NAT is just not supported.

Needless to say this requirement places an
extra burden on the users to
have public server allocated for the setup.

That extra burden doesn't come from the bridge. The whole point of
using the bridge is so that you could relay media through a server
that has the bandwidth to do so. User's generally don't have that
amount of upstream available.

Is this still the case? Or the latest version of the videbridge now does
support running behind that NAT. If
latter - then starting with which version?

I guess, at some point in the following three months. Note again
however that this would mostly be support for NATed servers. The
bridge would never be able to run in a constrained environment such as
a home ADSL connection.

Hope this helps,
Emil

···

On Tue, Jan 28, 2014 at 7:04 PM, Yan Brenman <ybrenman@xopnetworks.com> wrote:

On 1/28/2014 9:42 AM, Emil Ivov wrote:

Hey Peter,

On Tue, Jan 28, 2014 at 6:35 PM, Peter Villeneuve <petervnv1@gmail.com> > wrote:

Hi all,

I see that Jitsi now has several NAT traversal tools for XMPP. Congrats!
However, I use Jitsi in a NATed environment (like the vast majority I would
assume) with SIP instead of XMPP.

How does everyone else deal with using Jitsi behind NAT?

Most of the SIP servers would do that for you without requiring any
specific NAT traversal mechanisms in the client. Here's a description
of how this works:

http://tools.ietf.org/html/draft-ietf-mmusic-latching

I don't see any
ICE/STUN/TURN options for SIP which always leads to 1 way audio issues for
me.

Yes, this will come at some point. It's been lagging because of the
above but now we really seem to need it to facilitate webrtc
compatibility.

Hope this helps,
Emil

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

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31


#12

Great discussion guys. As Emil knows, I've been a big proponent of having
ICE in Jitsi.
I too await eagerly the day we see an announcement here that Jitsi supports
ICE in SIP.

···

On Wed, Jan 29, 2014 at 7:14 AM, Emil Ivov <emcho@jitsi.org> wrote:

Full cones, which are today referred as NATs with endpoint independent
mapping (EIM) and endoint independent filtering (EIP), just as well
as restricted cones, port restricted cones (EIM, EDF) and symmetric
NATs (EDM EDF) are all handled gracefully by severs (SBCs) with Hosted
NAT Traversal. The one case that fails here are environments that
completely block UDP. ICE has an advantage there because it has the
option of falling back to TCP in such situations.

Emil

On Tue, Jan 28, 2014 at 6:51 PM, Marc Abrams <marca56@fastmail.fm> wrote:
> Hi, Peter:
>
> Typically, unless you are behind a full cone enterprise firewall like
Cisco
> PIX or Sonicwall, that should not be necessary. Most SIP clients and
servers
> well with the latest SBCs used by SIP providers without port forwarding
or
> changes in the network.
>
> ICE is a great feature, but not necessary in all cases.
>
> marc.
> __________________
> +1-408-677-1346
>
>
>
> On Jan 28, 2014, at 9:35 AM, Peter Villeneuve <petervnv1@gmail.com> > wrote:
>
> Hi all,
>
> I see that Jitsi now has several NAT traversal tools for XMPP. Congrats!
> However, I use Jitsi in a NATed environment (like the vast majority I
would
> assume) with SIP instead of XMPP.
>
> How does everyone else deal with using Jitsi behind NAT? I don't see any
> ICE/STUN/TURN options for SIP which always leads to 1 way audio issues
for
> me.
>
> How are people using Jitsi behind NAT? Is there some hidden menu with
STUN
> and/or ICE configs like in the XMPP menu?
>
> Thanks,
>
> Peter
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31

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


#13

Peter:

Have you tried setting up DNS entries for UDP and TCP connections to the repro or Kamalio servers?

marc.

···

__________________
+1-408-677-1346

On Jan 28, 2014, at 10:02 AM, Peter Villeneuve <petervnv1@gmail.com> wrote:

I've been trying Jitsi with both repro and (now) kamailio.
I'm seeing typical no audio behaviour when calling from behind a NATed pc on a different network than the server. Signalling goes through and the call is answered, but no RTP seems to flow.

On Tue, Jan 28, 2014 at 5:59 PM, Emil Ivov <emcho@jitsi.org> wrote:
On Tue, Jan 28, 2014 at 6:47 PM, Peter Villeneuve <petervnv1@gmail.com> wrote:
> Hi Emil,
>
> Thanks for the quick reply. I guess I'll need to wait for ICE support to
> come along, as it seems my company's SIP server isn't handling NAT very
> well.

What is the exact behaviour that you are seeing?

Emil

>
>
>
>
> On Tue, Jan 28, 2014 at 5:42 PM, Emil Ivov <emcho@jitsi.org> wrote:
>>
>> Hey Peter,
>>
>> On Tue, Jan 28, 2014 at 6:35 PM, Peter Villeneuve <petervnv1@gmail.com> > >> wrote:
>> > Hi all,
>> >
>> > I see that Jitsi now has several NAT traversal tools for XMPP. Congrats!
>> > However, I use Jitsi in a NATed environment (like the vast majority I
>> > would
>> > assume) with SIP instead of XMPP.
>> >
>> > How does everyone else deal with using Jitsi behind NAT?
>>
>> Most of the SIP servers would do that for you without requiring any
>> specific NAT traversal mechanisms in the client. Here's a description
>> of how this works:
>>
>> http://tools.ietf.org/html/draft-ietf-mmusic-latching
>>
>> > I don't see any
>> > ICE/STUN/TURN options for SIP which always leads to 1 way audio issues
>> > for
>> > me.
>>
>> Yes, this will come at some point. It's been lagging because of the
>> above but now we really seem to need it to facilitate webrtc
>> compatibility.
>>
>> Hope this helps,
>> Emil
>>
>> --
>> https://jitsi.org
>
>

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31

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


#14

I've been trying Jitsi with both repro and (now) kamailio.
I'm seeing typical no audio behaviour when calling from behind a NATed pc
on a different network than the server. Signalling goes through and the
call is answered, but no RTP seems to flow.

···

On Tue, Jan 28, 2014 at 5:59 PM, Emil Ivov <emcho@jitsi.org> wrote:

On Tue, Jan 28, 2014 at 6:47 PM, Peter Villeneuve <petervnv1@gmail.com> > wrote:
> Hi Emil,
>
> Thanks for the quick reply. I guess I'll need to wait for ICE support to
> come along, as it seems my company's SIP server isn't handling NAT very
> well.

What is the exact behaviour that you are seeing?

Emil

>
>
>
>
> On Tue, Jan 28, 2014 at 5:42 PM, Emil Ivov <emcho@jitsi.org> wrote:
>>
>> Hey Peter,
>>
>> On Tue, Jan 28, 2014 at 6:35 PM, Peter Villeneuve <petervnv1@gmail.com> > >> wrote:
>> > Hi all,
>> >
>> > I see that Jitsi now has several NAT traversal tools for XMPP.
Congrats!
>> > However, I use Jitsi in a NATed environment (like the vast majority I
>> > would
>> > assume) with SIP instead of XMPP.
>> >
>> > How does everyone else deal with using Jitsi behind NAT?
>>
>> Most of the SIP servers would do that for you without requiring any
>> specific NAT traversal mechanisms in the client. Here's a description
>> of how this works:
>>
>> http://tools.ietf.org/html/draft-ietf-mmusic-latching
>>
>> > I don't see any
>> > ICE/STUN/TURN options for SIP which always leads to 1 way audio issues
>> > for
>> > me.
>>
>> Yes, this will come at some point. It's been lagging because of the
>> above but now we really seem to need it to facilitate webrtc
>> compatibility.
>>
>> Hope this helps,
>> Emil
>>
>> --
>> https://jitsi.org
>
>

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31


#15

Yes, I just finished configuring mediaproxy-ng and will try it out.
But I thought that mediaproxy-ng decides to relay or not depending on the
ICE negotiation, which Jitsi doesn't yet support...? Also, I'd rather Jitsi
establish a direct p2p connection instead of having to relay through
mproxy-ng.
I guess I'll have to go over mediaproxy-ng more carefully.

···

On Tue, Jan 28, 2014 at 6:00 PM, Emil Ivov <emcho@jitsi.org> wrote:

On Tue, Jan 28, 2014 at 6:58 PM, Peter Villeneuve <petervnv1@gmail.com> > wrote:
> By the way, do you know if Kamailio supports the HNT technique described
in
> the ietf document? I'd like to get it to work with Jitsi.

Kamailio installations are often configured to behave exactly this way
yes. Note that Kamailio does not relay media itself. RTPPROXY, Media
Proxy and MediaProxy-ng are commonly used together with Kamailio for
this.

FreeSwitch and Asterisk on the other hand, handle it themselves.

Emil

>
> Thanks
>
>
> On Tue, Jan 28, 2014 at 5:42 PM, Emil Ivov <emcho@jitsi.org> wrote:
>>
>> Hey Peter,
>>
>> On Tue, Jan 28, 2014 at 6:35 PM, Peter Villeneuve <petervnv1@gmail.com> > >> wrote:
>> > Hi all,
>> >
>> > I see that Jitsi now has several NAT traversal tools for XMPP.
Congrats!
>> > However, I use Jitsi in a NATed environment (like the vast majority I
>> > would
>> > assume) with SIP instead of XMPP.
>> >
>> > How does everyone else deal with using Jitsi behind NAT?
>>
>> Most of the SIP servers would do that for you without requiring any
>> specific NAT traversal mechanisms in the client. Here's a description
>> of how this works:
>>
>> http://tools.ietf.org/html/draft-ietf-mmusic-latching
>>
>> > I don't see any
>> > ICE/STUN/TURN options for SIP which always leads to 1 way audio issues
>> > for
>> > me.
>>
>> Yes, this will come at some point. It's been lagging because of the
>> above but now we really seem to need it to facilitate webrtc
>> compatibility.
>>
>> Hope this helps,
>> Emil
>>
>> --
>> https://jitsi.org
>
>

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31


#16

Have you configured Kamailio to use rtpproxy, mediaproxy,
mediaproxy-ng or any other relaying tool?

Emil

···

On Tue, Jan 28, 2014 at 7:02 PM, Peter Villeneuve <petervnv1@gmail.com> wrote:

I've been trying Jitsi with both repro and (now) kamailio.
I'm seeing typical no audio behaviour when calling from behind a NATed pc on
a different network than the server. Signalling goes through and the call is
answered, but no RTP seems to flow.

On Tue, Jan 28, 2014 at 5:59 PM, Emil Ivov <emcho@jitsi.org> wrote:

On Tue, Jan 28, 2014 at 6:47 PM, Peter Villeneuve <petervnv1@gmail.com> >> wrote:
> Hi Emil,
>
> Thanks for the quick reply. I guess I'll need to wait for ICE support to
> come along, as it seems my company's SIP server isn't handling NAT very
> well.

What is the exact behaviour that you are seeing?

Emil

>
>
>
>
> On Tue, Jan 28, 2014 at 5:42 PM, Emil Ivov <emcho@jitsi.org> wrote:
>>
>> Hey Peter,
>>
>> On Tue, Jan 28, 2014 at 6:35 PM, Peter Villeneuve <petervnv1@gmail.com> >> >> wrote:
>> > Hi all,
>> >
>> > I see that Jitsi now has several NAT traversal tools for XMPP.
>> > Congrats!
>> > However, I use Jitsi in a NATed environment (like the vast majority I
>> > would
>> > assume) with SIP instead of XMPP.
>> >
>> > How does everyone else deal with using Jitsi behind NAT?
>>
>> Most of the SIP servers would do that for you without requiring any
>> specific NAT traversal mechanisms in the client. Here's a description
>> of how this works:
>>
>> http://tools.ietf.org/html/draft-ietf-mmusic-latching
>>
>> > I don't see any
>> > ICE/STUN/TURN options for SIP which always leads to 1 way audio
>> > issues
>> > for
>> > me.
>>
>> Yes, this will come at some point. It's been lagging because of the
>> above but now we really seem to need it to facilitate webrtc
>> compatibility.
>>
>> Hope this helps,
>> Emil
>>
>> --
>> https://jitsi.org
>
>

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31


#17

Hey Peter,

Yes, I just finished configuring mediaproxy-ng and will try it out.
But I thought that mediaproxy-ng decides to relay or not depending on the
ICE negotiation, which Jitsi doesn't yet support...?

That's only one of the options for using it. You can also use it in
the conventional ICEless way.

Also, I'd rather Jitsi
establish a direct p2p connection instead of having to relay through
mproxy-ng.

This won't be possible until we implement ICE. Also note that even
when ICE is supported you would still need to have something like that
as a fallback. The whole point of ICE is that allows you to use your
relay less. That's it. (Except for WebRTC where it also prevents some
attacks). For small deployments ICE barely makes a difference.

Emil

···

On Tue, Jan 28, 2014 at 7:05 PM, Peter Villeneuve <petervnv1@gmail.com> wrote:

I guess I'll have to go over mediaproxy-ng more carefully.

On Tue, Jan 28, 2014 at 6:00 PM, Emil Ivov <emcho@jitsi.org> wrote:

On Tue, Jan 28, 2014 at 6:58 PM, Peter Villeneuve <petervnv1@gmail.com> >> wrote:
> By the way, do you know if Kamailio supports the HNT technique described
> in
> the ietf document? I'd like to get it to work with Jitsi.

Kamailio installations are often configured to behave exactly this way
yes. Note that Kamailio does not relay media itself. RTPPROXY, Media
Proxy and MediaProxy-ng are commonly used together with Kamailio for
this.

FreeSwitch and Asterisk on the other hand, handle it themselves.

Emil

>
> Thanks
>
>
> On Tue, Jan 28, 2014 at 5:42 PM, Emil Ivov <emcho@jitsi.org> wrote:
>>
>> Hey Peter,
>>
>> On Tue, Jan 28, 2014 at 6:35 PM, Peter Villeneuve <petervnv1@gmail.com> >> >> wrote:
>> > Hi all,
>> >
>> > I see that Jitsi now has several NAT traversal tools for XMPP.
>> > Congrats!
>> > However, I use Jitsi in a NATed environment (like the vast majority I
>> > would
>> > assume) with SIP instead of XMPP.
>> >
>> > How does everyone else deal with using Jitsi behind NAT?
>>
>> Most of the SIP servers would do that for you without requiring any
>> specific NAT traversal mechanisms in the client. Here's a description
>> of how this works:
>>
>> http://tools.ietf.org/html/draft-ietf-mmusic-latching
>>
>> > I don't see any
>> > ICE/STUN/TURN options for SIP which always leads to 1 way audio
>> > issues
>> > for
>> > me.
>>
>> Yes, this will come at some point. It's been lagging because of the
>> above but now we really seem to need it to facilitate webrtc
>> compatibility.
>>
>> Hope this helps,
>> Emil
>>
>> --
>> https://jitsi.org
>
>

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31


#18

One way to cover all cases here with NAT is to use TCP, as Emil points out below. Though they don't often advertise the fact, almost all SIP providers support TCP. They don't like to do this because of the additional load placed on proxy servers.

···

--
--
Marc Abrams
+1-408-677-1346
marca56@fastmail.fm
Sunday, 02 February 2014, 09:58AM -08:00 from Privus P <privus007@gmail.com>:
Great discussion guys. As Emil knows, I've been a big proponent of having ICE in Jitsi.
I too await eagerly the day we see an announcement here that Jitsi supports ICE in SIP.
On Wed, Jan 29, 2014 at 7:14 AM, Emil Ivov < emcho@jitsi.org > wrote:

Full cones, which are today referred as NATs with endpoint independent
mapping (EIM) and endoint independent filtering (EIP), just as well
as restricted cones, port restricted cones (EIM, EDF) and symmetric
NATs (EDM EDF) are all handled gracefully by severs (SBCs) with Hosted
NAT Traversal. The one case that fails here are environments that
completely block UDP. ICE has an advantage there because it has the
option of falling back to TCP in such situations.

Emil

On Tue, Jan 28, 2014 at 6:51 PM, Marc Abrams < marca56@fastmail.fm > wrote:

Hi, Peter:

Typically, unless you are behind a full cone enterprise firewall like Cisco
PIX or Sonicwall, that should not be necessary. Most SIP clients and servers
well with the latest SBCs used by SIP providers without port forwarding or
changes in the network.

ICE is a great feature, but not necessary in all cases.

marc.
__________________
+1-408-677-1346

On Jan 28, 2014, at 9:35 AM, Peter Villeneuve < petervnv1@gmail.com > wrote:

Hi all,

I see that Jitsi now has several NAT traversal tools for XMPP. Congrats!
However, I use Jitsi in a NATed environment (like the vast majority I would
assume) with SIP instead of XMPP.

How does everyone else deal with using Jitsi behind NAT? I don't see any
ICE/STUN/TURN options for SIP which always leads to 1 way audio issues for
me.

How are people using Jitsi behind NAT? Is there some hidden menu with STUN
and/or ICE configs like in the XMPP menu?

Thanks,

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

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

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31

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

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


#19

Ok, thanks Emil. Ideally I'd like to have ICE implemented in all the
clients, and then use mediaproxy-ng only as a last resort, like you state.

I guess I'll just have to wait for now until ICE support is added.

Thanks

···

On Tue, Jan 28, 2014 at 6:22 PM, Emil Ivov <emcho@jitsi.org> wrote:

Hey Peter,

On Tue, Jan 28, 2014 at 7:05 PM, Peter Villeneuve <petervnv1@gmail.com> > wrote:
> Yes, I just finished configuring mediaproxy-ng and will try it out.
> But I thought that mediaproxy-ng decides to relay or not depending on the
> ICE negotiation, which Jitsi doesn't yet support...?

That's only one of the options for using it. You can also use it in
the conventional ICEless way.

> Also, I'd rather Jitsi
> establish a direct p2p connection instead of having to relay through
> mproxy-ng.

This won't be possible until we implement ICE. Also note that even
when ICE is supported you would still need to have something like that
as a fallback. The whole point of ICE is that allows you to use your
relay less. That's it. (Except for WebRTC where it also prevents some
attacks). For small deployments ICE barely makes a difference.

Emil

> I guess I'll have to go over mediaproxy-ng more carefully.
>
>
> On Tue, Jan 28, 2014 at 6:00 PM, Emil Ivov <emcho@jitsi.org> wrote:
>>
>> On Tue, Jan 28, 2014 at 6:58 PM, Peter Villeneuve <petervnv1@gmail.com> > >> wrote:
>> > By the way, do you know if Kamailio supports the HNT technique
described
>> > in
>> > the ietf document? I'd like to get it to work with Jitsi.
>>
>> Kamailio installations are often configured to behave exactly this way
>> yes. Note that Kamailio does not relay media itself. RTPPROXY, Media
>> Proxy and MediaProxy-ng are commonly used together with Kamailio for
>> this.
>>
>> FreeSwitch and Asterisk on the other hand, handle it themselves.
>>
>> Emil
>>
>>
>> >
>> > Thanks
>> >
>> >
>> > On Tue, Jan 28, 2014 at 5:42 PM, Emil Ivov <emcho@jitsi.org> wrote:
>> >>
>> >> Hey Peter,
>> >>
>> >> On Tue, Jan 28, 2014 at 6:35 PM, Peter Villeneuve < > petervnv1@gmail.com> > >> >> wrote:
>> >> > Hi all,
>> >> >
>> >> > I see that Jitsi now has several NAT traversal tools for XMPP.
>> >> > Congrats!
>> >> > However, I use Jitsi in a NATed environment (like the vast
majority I
>> >> > would
>> >> > assume) with SIP instead of XMPP.
>> >> >
>> >> > How does everyone else deal with using Jitsi behind NAT?
>> >>
>> >> Most of the SIP servers would do that for you without requiring any
>> >> specific NAT traversal mechanisms in the client. Here's a description
>> >> of how this works:
>> >>
>> >> http://tools.ietf.org/html/draft-ietf-mmusic-latching
>> >>
>> >> > I don't see any
>> >> > ICE/STUN/TURN options for SIP which always leads to 1 way audio
>> >> > issues
>> >> > for
>> >> > me.
>> >>
>> >> Yes, this will come at some point. It's been lagging because of the
>> >> above but now we really seem to need it to facilitate webrtc
>> >> compatibility.
>> >>
>> >> Hope this helps,
>> >> Emil
>> >>
>> >> --
>> >> https://jitsi.org
>> >
>> >
>>
>>
>>
>> --
>> Emil Ivov, Ph.D. 67000 Strasbourg,
>> Project Lead France
>> Jitsi
>> emcho@jitsi.org PHONE: +33.1.77.62.43.30
>> https://jitsi.org FAX: +33.1.77.62.47.31
>
>

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31


#20

Many SIP providers do support TCP for signalling but very rarely do they do
that for media. ICE is the only decent way to add TCP into the mix and we
are still very keen on adding it.

--sent from my mobile

···

On 02 Feb 2014 8:54 PM, <marca56@fastmail.fm> wrote:

One way to cover all cases here with NAT is to use TCP, as Emil points out
below. Though they don't often advertise the fact, almost all SIP providers
support TCP. They don't like to do this because of the additional load
placed on proxy servers.

--
--
Marc Abrams
+1-408-677-1346
marca56@fastmail.fm

Sunday, 02 February 2014, 09:58AM -08:00 from Privus P <
privus007@gmail.com>:

Great discussion guys. As Emil knows, I've been a big proponent of having
ICE in Jitsi.
I too await eagerly the day we see an announcement here that Jitsi
supports ICE in SIP.

On Wed, Jan 29, 2014 at 7:14 AM, Emil Ivov < emcho@jitsi.org > wrote:
>Full cones, which are today referred as NATs with endpoint independent
>mapping (EIM) and endoint independent filtering (EIP), just as well
>as restricted cones, port restricted cones (EIM, EDF) and symmetric
>NATs (EDM EDF) are all handled gracefully by severs (SBCs) with Hosted
>NAT Traversal. The one case that fails here are environments that
>completely block UDP. ICE has an advantage there because it has the
>option of falling back to TCP in such situations.
>
>Emil
>
>On Tue, Jan 28, 2014 at 6:51 PM, Marc Abrams < marca56@fastmail.fm > > wrote:
>> Hi, Peter:
>>
>> Typically, unless you are behind a full cone enterprise firewall like
Cisco
>> PIX or Sonicwall, that should not be necessary. Most SIP clients and
servers
>> well with the latest SBCs used by SIP providers without port forwarding
or
>> changes in the network.
>>
>> ICE is a great feature, but not necessary in all cases.
>>
>> marc.
>> __________________
>> +1-408-677-1346
>>
>>
>>
>> On Jan 28, 2014, at 9:35 AM, Peter Villeneuve < petervnv1@gmail.com > > wrote:
>>
>> Hi all,
>>
>> I see that Jitsi now has several NAT traversal tools for XMPP. Congrats!
>> However, I use Jitsi in a NATed environment (like the vast majority I
would
>> assume) with SIP instead of XMPP.
>>
>> How does everyone else deal with using Jitsi behind NAT? I don't see any
>> ICE/STUN/TURN options for SIP which always leads to 1 way audio issues
for
>> me.
>>
>> How are people using Jitsi behind NAT? Is there some hidden menu with
STUN
>> and/or ICE configs like in the XMPP menu?
>>
>> Thanks,
>>
>> Peter
>> _______________________________________________
>> dev mailing list
>> dev@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/dev
>>
>>
>>
>> _______________________________________________
>> dev mailing list
>> dev@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
>--
>Emil Ivov, Ph.D. 67000 Strasbourg,
>Project Lead France
>Jitsi
>emcho@jitsi.org PHONE: +33.1.77.62.43.30
>https://jitsi.org FAX: +33.1.77.62.47.31
>
>_______________________________________________
>dev mailing list
>dev@jitsi.org
>Unsubscribe instructions and other list options:
>http://lists.jitsi.org/mailman/listinfo/dev

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

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