You can also check out sipXecs... http://www.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.
On Sat, Mar 24, 2012 at 7:01 PM, Kertesz Laszlo > <firstname.lastname@example.org <mailto:email@example.com>> wrote:
On Sun, 25 Mar 2012 08:23:55 +1100 > Ehtyar Holmes <firstname.lastname@example.org <mailto:email@example.com>> 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
> been in the IRC channel for a day or so, but I should have
> question to the mailing list prior to posting a bug.
> In our tests, the signaling worked fine, it simply sent the
> address instead of the public one, directing the media stream to a
> non-existant IP address. Would a STUN server not make the UA
> its public IP address which it would then use in signaling? It
> understanding that packet relay would not be necessary provided
> were able to connect to each other directly (i.e. have the right
> 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
> 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
> 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
> of the bug reporting policies!
> 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
> >> 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
> > 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
> >> 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
> >> address from each end (ICE support is on the way I believe),
> >> 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.
> >> I created an issue here
> >> I came across the mailing lists. My apologies if that was
> > ... we'll survive. We get this all the time.
> > Emil
> > --
> > http://jitsi.org
O zi buna,
There are 10 kinds of people in this world, those who understand
binary and those who don't.
call: sip:firstname.lastname@example.org <mailto:sip%3Ampicher@sipxecs.info>