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

Michael Picher mpicher at gmail.com
Sun Mar 25 13:55:45 CEST 2012


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 at gmail.com>wrote:

> On Sun, 25 Mar 2012 08:23:55 +1100
> Ehtyar Holmes <lists at ehti.org> wrote:
>
> > Hi Emil,
> >
> > Thanks for your response. Now that you've mentioned it I see the
> > warning's everywhere :( 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.
> > > :) ... 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 at gmail.com
blog: http://www.sipxecs.info
call: sip:mpicher at sipxecs.info
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.jitsi.org/pipermail/users/attachments/20120325/89cc8e2c/attachment.html>


More information about the users mailing list