[jitsi-users] Using Registrarless SIP Over the Internet From Behind NAT


#1

Hi all,

I'm attempting to use registrarless SIP from behind a NAT (on both ends)
over the internet. It seems that Jitsi is not aware of the NAT, so all
the RTP packets get blackholed into the far end's private address on
each end of the call. Can anyone tell me if there's anything I can do to
work around that please? I guess ideally Jitsi would simply use the IP
address from the URI of the call instead, or would report it public
address from each end (ICE support is on the way I believe), but perhaps
there's a way around this that doesn't involve any code.

I created an issue here <http://java.net/jira/browse/JITSI-1030> before
I came across the mailing lists. My apologies if that was premature.

Thanks very much!!


#2

Hey Ehtyar,

Hi all,

I'm attempting to use registrarless SIP from behind a NAT (on both ends)
over the internet.

This doesn't start well :). RegistrarLess SIP is mostly meant for
testing and using it to connect UAs behind different NATs is definitely
not one of the use cases it was meant for.

It seems that Jitsi is not aware of the NAT, so all
the RTP packets get blackholed into the far end's private address on
each end of the call. Can anyone tell me if there's anything I can do to
work around that please? I guess ideally Jitsi would simply use the IP
address from the URI of the call instead, or would report it public
address from each end (ICE support is on the way I believe), but perhaps
there's a way around this that doesn't involve any code.

ICE is indeed on the way, but even when it does come it won't do
anything to help with NAT traversal for SIP signaling itself. Only media.

I created an issue here <http://java.net/jira/browse/JITSI-1030> before
I came across the mailing lists. My apologies if that was premature.

:slight_smile: ... we'll survive. We get this all the time.

Emil

···

On 24.03.12 09:56, Ehtyar Holmes wrote:

--
http://jitsi.org


#3

Hi Emil,

Thanks for your response. Now that you've mentioned it I see the
warning's everywhere :frowning: I'm very sorry for being ignorant of that!! I've
been in the IRC channel for a day or so, but I should have brought my
question to the mailing list prior to posting a bug.

In our tests, the signaling worked fine, it simply sent the private IP
address instead of the public one, directing the media stream to a
non-existant IP address. Would a STUN server not make the UA aware of
its public IP address which it would then use in signaling? It was my
understanding that packet relay would not be necessary provided the UAs
were able to connect to each other directly (i.e. have the right ports
forwarded etc).

That's a huge bummer. I was sure I'd found a way to get the **** off
Skype. We've had all sorts of issues with using Asterisk securely, and
the latency introduced by a server is less than ideal when you're
sending video and audio. My next port of call will be Freeswitch
compiled (I hope) with a copy of libzrtp, if I can find a copy of it
somewhere, as Mr Zimmermann has not responded to my enquiries and the
zphone download page has been down for months.

Thanks for being understanding, and again I'm very to have been ignorant
of the bug reporting policies!

Ehtyar.

···

On 25/03/2012 12:59 AM, Emil Ivov wrote:

Hey Ehtyar,

On 24.03.12 09:56, Ehtyar Holmes wrote:

Hi all,

I'm attempting to use registrarless SIP from behind a NAT (on both ends)
over the internet.

This doesn't start well :). RegistrarLess SIP is mostly meant for
testing and using it to connect UAs behind different NATs is definitely
not one of the use cases it was meant for.

It seems that Jitsi is not aware of the NAT, so all
the RTP packets get blackholed into the far end's private address on
each end of the call. Can anyone tell me if there's anything I can do to
work around that please? I guess ideally Jitsi would simply use the IP
address from the URI of the call instead, or would report it public
address from each end (ICE support is on the way I believe), but perhaps
there's a way around this that doesn't involve any code.

ICE is indeed on the way, but even when it does come it won't do
anything to help with NAT traversal for SIP signaling itself. Only media.

I created an issue here <http://java.net/jira/browse/JITSI-1030> before
I came across the mailing lists. My apologies if that was premature.

:slight_smile: ... we'll survive. We get this all the time.

Emil

--
http://jitsi.org


#4

Hi Emil,

Thanks for your response. Now that you've mentioned it I see the
warning's everywhere :frowning: I'm very sorry for being ignorant of that!! I've
been in the IRC channel for a day or so, but I should have brought my
question to the mailing list prior to posting a bug.

In our tests, the signaling worked fine, it simply sent the private IP
address instead of the public one, directing the media stream to a
non-existant IP address. Would a STUN server not make the UA aware of
its public IP address which it would then use in signaling? It was my
understanding that packet relay would not be necessary provided the UAs
were able to connect to each other directly (i.e. have the right ports
forwarded etc).

That's a huge bummer. I was sure I'd found a way to get the **** off
Skype. We've had all sorts of issues with using Asterisk securely, and
the latency introduced by a server is less than ideal when you're
sending video and audio. My next port of call will be Freeswitch
compiled (I hope) with a copy of libzrtp, if I can find a copy of it
somewhere, as Mr Zimmermann has not responded to my enquiries and the
zphone download page has been down for months.

There are some other alternatives:

1. Use a vpn and you will be able to route even peer-to-peer SIP calls with no issues.
2. You can use a a jabber server like openfire. Then you will have voice, video, text and file transfer. Plus it is so much easier to set up and operate than a SIP server (each one has their own quirks and stuff). And the jabber protocol is better for this kind of stuff than SIP (few NAT traversal issues).
3. Both of the above. Safest option, you will have everything flowing in a controlled environment, the routes are laid out in a simple way and you will not have any surprises.

···

On Sun, 25 Mar 2012 08:23:55 +1100 Ehtyar Holmes <lists@ehti.org> wrote:

Thanks for being understanding, and again I'm very to have been ignorant
of the bug reporting policies!

Ehtyar.

On 25/03/2012 12:59 AM, Emil Ivov wrote:
> Hey Ehtyar,
>
> On 24.03.12 09:56, Ehtyar Holmes wrote:
>> Hi all,
>>
>> I'm attempting to use registrarless SIP from behind a NAT (on both ends)
>> over the internet.
> This doesn't start well :). RegistrarLess SIP is mostly meant for
> testing and using it to connect UAs behind different NATs is definitely
> not one of the use cases it was meant for.
>
>> It seems that Jitsi is not aware of the NAT, so all
>> the RTP packets get blackholed into the far end's private address on
>> each end of the call. Can anyone tell me if there's anything I can do to
>> work around that please? I guess ideally Jitsi would simply use the IP
>> address from the URI of the call instead, or would report it public
>> address from each end (ICE support is on the way I believe), but perhaps
>> there's a way around this that doesn't involve any code.
>
> ICE is indeed on the way, but even when it does come it won't do
> anything to help with NAT traversal for SIP signaling itself. Only media.
>
>> I created an issue here <http://java.net/jira/browse/JITSI-1030> before
>> I came across the mailing lists. My apologies if that was premature.
> :slight_smile: ... we'll survive. We get this all the time.
>
> Emil
>
> --
> http://jitsi.org
>

--
O zi buna,

Kertesz Laszlo


#5

You can also check out sipXecs... http://www.sipfoundry.org /
http://wiki.sipfoundry.org

This is a stateless proxy and as such doesn't require media go through the
server... however, NAT traversal / media relay does kind of force your
hand here and cause it to be anchored by the media relay.

Freeswitch is included with the product but it is only used for its most
excellent media services. Openfire is also included as an integrated XMPP
server as well. Jitsi works quite nicely with it.

If you are communicating internally on a network or via VPN with other
users of the same system media flows device to device.

Thanks,
  Mike

···

On Sat, Mar 24, 2012 at 7:01 PM, Kertesz Laszlo <laszlo.kertesz@gmail.com>wrote:

On Sun, 25 Mar 2012 08:23:55 +1100 > Ehtyar Holmes <lists@ehti.org> wrote:

> Hi Emil,
>
> Thanks for your response. Now that you've mentioned it I see the
> warning's everywhere :frowning: I'm very sorry for being ignorant of that!! I've
> been in the IRC channel for a day or so, but I should have brought my
> question to the mailing list prior to posting a bug.
>
> In our tests, the signaling worked fine, it simply sent the private IP
> address instead of the public one, directing the media stream to a
> non-existant IP address. Would a STUN server not make the UA aware of
> its public IP address which it would then use in signaling? It was my
> understanding that packet relay would not be necessary provided the UAs
> were able to connect to each other directly (i.e. have the right ports
> forwarded etc).
>
> That's a huge bummer. I was sure I'd found a way to get the **** off
> Skype. We've had all sorts of issues with using Asterisk securely, and
> the latency introduced by a server is less than ideal when you're
> sending video and audio. My next port of call will be Freeswitch
> compiled (I hope) with a copy of libzrtp, if I can find a copy of it
> somewhere, as Mr Zimmermann has not responded to my enquiries and the
> zphone download page has been down for months.
>

There are some other alternatives:

1. Use a vpn and you will be able to route even peer-to-peer SIP calls
with no issues.
2. You can use a a jabber server like openfire. Then you will have voice,
video, text and file transfer. Plus it is so much easier to set up and
operate than a SIP server (each one has their own quirks and stuff). And
the jabber protocol is better for this kind of stuff than SIP (few NAT
traversal issues).
3. Both of the above. Safest option, you will have everything flowing in a
controlled environment, the routes are laid out in a simple way and you
will not have any surprises.

> Thanks for being understanding, and again I'm very to have been ignorant
> of the bug reporting policies!
>
> Ehtyar.
>
> On 25/03/2012 12:59 AM, Emil Ivov wrote:
> > Hey Ehtyar,
> >
> > On 24.03.12 09:56, Ehtyar Holmes wrote:
> >> Hi all,
> >>
> >> I'm attempting to use registrarless SIP from behind a NAT (on both
ends)
> >> over the internet.
> > This doesn't start well :). RegistrarLess SIP is mostly meant for
> > testing and using it to connect UAs behind different NATs is definitely
> > not one of the use cases it was meant for.
> >
> >> It seems that Jitsi is not aware of the NAT, so all
> >> the RTP packets get blackholed into the far end's private address on
> >> each end of the call. Can anyone tell me if there's anything I can do
to
> >> work around that please? I guess ideally Jitsi would simply use the IP
> >> address from the URI of the call instead, or would report it public
> >> address from each end (ICE support is on the way I believe), but
perhaps
> >> there's a way around this that doesn't involve any code.
> >
> > ICE is indeed on the way, but even when it does come it won't do
> > anything to help with NAT traversal for SIP signaling itself. Only
media.
> >
> >> I created an issue here <http://java.net/jira/browse/JITSI-1030>
before
> >> I came across the mailing lists. My apologies if that was premature.
> > :slight_smile: ... we'll survive. We get this all the time.
> >
> > Emil
> >
> > --
> > http://jitsi.org
> >
>

--
O zi buna,

Kertesz Laszlo

--
There are 10 kinds of people in this world, those who understand binary and
those who don't.

mpicher@gmail.com
blog: http://www.sipxecs.info
call: sip:mpicher@sipxecs.info


#6

My apologies for taking so long to respond, it's been a hectic fortnight
here.

Thank you Michael and Kertesz for your responses.

I hadn't though of VPN, but although it may be less convenient, it is
certainly an option to consider since it would negate any NAT traversal
considerations and provide end-to-end security.

I had investigated XMPP as a potential messaging and voice transfer
solution alongside SIP, but hadn't considered using it for media streams
as well - I will investigate that further.

sipXecs seems to be almost exactly what I was aiming for in the first
place all tidily packaged up in one repo :slight_smile: I'll install it and give it
a go ASAP.

Thanks again for your suggestions guys, I really appreciate the advice!

Cheers.

···

On 25/03/2012 10:55 PM, Michael Picher wrote:

You can also check out sipXecs... http://www.sipfoundry.org /
http://wiki.sipfoundry.org

This is a stateless proxy and as such doesn't require media go through
the server... however, NAT traversal / media relay does kind of force
your hand here and cause it to be anchored by the media relay.

Freeswitch is included with the product but it is only used for its
most excellent media services. Openfire is also included as an
integrated XMPP server as well. Jitsi works quite nicely with it.

If you are communicating internally on a network or via VPN with other
users of the same system media flows device to device.

Thanks,
  Mike

On Sat, Mar 24, 2012 at 7:01 PM, Kertesz Laszlo > <laszlo.kertesz@gmail.com <mailto:laszlo.kertesz@gmail.com>> wrote:

    On Sun, 25 Mar 2012 08:23:55 +1100 > Ehtyar Holmes <lists@ehti.org <mailto:lists@ehti.org>> wrote:

    > Hi Emil,
    >
    > Thanks for your response. Now that you've mentioned it I see the
    > warning's everywhere :frowning: I'm very sorry for being ignorant of
    that!! I've
    > been in the IRC channel for a day or so, but I should have
    brought my
    > question to the mailing list prior to posting a bug.
    >
    > In our tests, the signaling worked fine, it simply sent the
    private IP
    > address instead of the public one, directing the media stream to a
    > non-existant IP address. Would a STUN server not make the UA
    aware of
    > its public IP address which it would then use in signaling? It
    was my
    > understanding that packet relay would not be necessary provided
    the UAs
    > were able to connect to each other directly (i.e. have the right
    ports
    > forwarded etc).
    >
    > That's a huge bummer. I was sure I'd found a way to get the **** off
    > Skype. We've had all sorts of issues with using Asterisk
    securely, and
    > the latency introduced by a server is less than ideal when you're
    > sending video and audio. My next port of call will be Freeswitch
    > compiled (I hope) with a copy of libzrtp, if I can find a copy of it
    > somewhere, as Mr Zimmermann has not responded to my enquiries
    and the
    > zphone download page has been down for months.
    >

    There are some other alternatives:

    1. Use a vpn and you will be able to route even peer-to-peer SIP
    calls with no issues.
    2. You can use a a jabber server like openfire. Then you will have
    voice, video, text and file transfer. Plus it is so much easier to
    set up and operate than a SIP server (each one has their own
    quirks and stuff). And the jabber protocol is better for this kind
    of stuff than SIP (few NAT traversal issues).
    3. Both of the above. Safest option, you will have everything
    flowing in a controlled environment, the routes are laid out in a
    simple way and you will not have any surprises.

    > Thanks for being understanding, and again I'm very to have been
    ignorant
    > of the bug reporting policies!
    >
    > Ehtyar.
    >
    > On 25/03/2012 12:59 AM, Emil Ivov wrote:
    > > Hey Ehtyar,
    > >
    > > On 24.03.12 09:56, Ehtyar Holmes wrote:
    > >> Hi all,
    > >>
    > >> I'm attempting to use registrarless SIP from behind a NAT (on
    both ends)
    > >> over the internet.
    > > This doesn't start well :). RegistrarLess SIP is mostly meant for
    > > testing and using it to connect UAs behind different NATs is
    definitely
    > > not one of the use cases it was meant for.
    > >
    > >> It seems that Jitsi is not aware of the NAT, so all
    > >> the RTP packets get blackholed into the far end's private
    address on
    > >> each end of the call. Can anyone tell me if there's anything
    I can do to
    > >> work around that please? I guess ideally Jitsi would simply
    use the IP
    > >> address from the URI of the call instead, or would report it
    public
    > >> address from each end (ICE support is on the way I believe),
    but perhaps
    > >> there's a way around this that doesn't involve any code.
    > >
    > > ICE is indeed on the way, but even when it does come it won't do
    > > anything to help with NAT traversal for SIP signaling itself.
    Only media.
    > >
    > >> I created an issue here
    <http://java.net/jira/browse/JITSI-1030> before
    > >> I came across the mailing lists. My apologies if that was
    premature.
    > > :slight_smile: ... we'll survive. We get this all the time.
    > >
    > > Emil
    > >
    > > --
    > > http://jitsi.org
    > >
    >

    --
    O zi buna,

    Kertesz Laszlo

--
There are 10 kinds of people in this world, those who understand
binary and those who don't.

mpicher@gmail.com <mailto:mpicher@gmail.com>
blog: http://www.sipxecs.info
call: sip:mpicher@sipxecs.info <mailto:sip%3Ampicher@sipxecs.info>