[jitsi-users] Jitsi, SIP and TURN


#1

Heho,

after i've got Jitsi/jingle to work on my ejabberd using the reTurn TURN
server from the resiprocate project so that symmetric NAT cases are
handled as well i was trying to tackle SIP. For this i've setup the
repro SIP proxy server and i'm able to log in and make calls in
"friendly" NAT situations. So basics work. Problem is that for SIP too
i'd like to be able to tackle the symmetric NAT case. As far as i know
TURN can also be used together with SIP, as it also uses RTP streams for
actual data transport, right? With Jabber/Jingle accounts i can find a
TURN server configuration part in the account configuration of jitsi,
for SIP this is missing.

Why is that? Does jitsi support TURN with SIP? If so, where can/could i
enter the server address and credentials?

Any help appreciated ;P. Best Regards
- Dario


#2

Hey Dario,

Heho,

after i've got Jitsi/jingle to work on my ejabberd using the reTurn TURN
server from the resiprocate project so that symmetric NAT cases are
handled as well i was trying to tackle SIP. For this i've setup the
repro SIP proxy server and i'm able to log in and make calls in
"friendly" NAT situations. So basics work. Problem is that for SIP too
i'd like to be able to tackle the symmetric NAT case. As far as i know
TURN can also be used together with SIP, as it also uses RTP streams for
actual data transport, right? With Jabber/Jingle accounts i can find a
TURN server configuration part in the account configuration of jitsi,
for SIP this is missing.

We currently support ICE (and hence TURN) for XMPP only.

Why is that? Does jitsi support TURN with SIP? If so, where can/could i
enter the server address and credentials?

The main reason is that most SIP servers are configured to provide
hosted NAT traversal. They would override the SDP that clients send
and put themselves in the media path for all calls. This is pretty
much equivalent to using a TURN server for every call. This is of
course somewhat less efficient than ICE but they are equivalent in
terms of NAT traversal reliability.

Hope this helps,
Emil
.

···

On Tue, Aug 7, 2012 at 11:53 AM, Dario Ernst <daddel9@kanojo.de> wrote:


#3

Hey Dario,

Heho,

after i've got Jitsi/jingle to work on my ejabberd using the reTurn TURN
server from the resiprocate project so that symmetric NAT cases are

It's great to hear reTurn is working for you - are you using the Debian
or Ubunutu packages or a self-compiled version?

Any feedback on the packages is very welcome, as I've only released them
recently.

handled as well i was trying to tackle SIP. For this i've setup the
repro SIP proxy server and i'm able to log in and make calls in
"friendly" NAT situations. So basics work. Problem is that for SIP too
i'd like to be able to tackle the symmetric NAT case. As far as i know
TURN can also be used together with SIP, as it also uses RTP streams for

ICE/STUN/TURN is valid for SIP or Jabber

actual data transport, right? With Jabber/Jingle accounts i can find a
TURN server configuration part in the account configuration of jitsi,
for SIP this is missing.

We currently support ICE (and hence TURN) for XMPP only.

Just out of interest, Lumicall uses the same ice4j code from the Jitsi
project to provide full ICE/STUN/TURN support in SIP - so theoretically,
Jitsi already has > 95% of what it needs to support ICE with SIP?

Why is that? Does jitsi support TURN with SIP? If so, where can/could i
enter the server address and credentials?

The main reason is that most SIP servers are configured to provide
hosted NAT traversal. They would override the SDP that clients send

- Asterisk does this when configured to relay all RTP for a peer, so it
is trivial to achieve with Asterisk. But Asterisk is not a full SIP
proxy, and doesn't supported federated SIP with TLS, for example.

- The SER derivatives (Kamailio, OpenSIPS) only do it when using
rtpproxy and the nathelper module - it is slightly more complicated to
set up and it can be painful to integrate with other customizations in
the config file.

- SDP mangling also works against things like secure (signed/encrypted)
SIP message bodies

- repro has no support for RTP media proxying - as it ships with a TURN
server

and put themselves in the media path for all calls. This is pretty
much equivalent to using a TURN server for every call. This is of
course somewhat less efficient than ICE but they are equivalent in
terms of NAT traversal reliability.

It is the combination of all reasons just given that suggests people
should go directly for ICE/TURN rather than the rtpproxy solutions

Also, more and more SIP clients are supporting ICE - for example, it has
been speculated that the very popular Polycom handsets might have this
in an upcoming firmware. Lumicall (on Android) has it. There are many
people who would really like to see the leading softphone using ICE with
those other devices: what would be the effort to get it in Jitsi?

···

On 07/08/12 10:28, Emil Ivov wrote:

On Tue, Aug 7, 2012 at 11:53 AM, Dario Ernst <daddel9@kanojo.de> wrote:


#4

Hey Daniel,

Hey Dario,

Heho,

after i've got Jitsi/jingle to work on my ejabberd using the reTurn TURN
server from the resiprocate project so that symmetric NAT cases are

It's great to hear reTurn is working for you - are you using the Debian
or Ubunutu packages or a self-compiled version?

Any feedback on the packages is very welcome, as I've only released them
recently.

Would you be interested in also packaging TurnServer?

handled as well i was trying to tackle SIP. For this i've setup the
repro SIP proxy server and i'm able to log in and make calls in
"friendly" NAT situations. So basics work. Problem is that for SIP too
i'd like to be able to tackle the symmetric NAT case. As far as i know
TURN can also be used together with SIP, as it also uses RTP streams for

ICE/STUN/TURN is valid for SIP or Jabber

actual data transport, right? With Jabber/Jingle accounts i can find a
TURN server configuration part in the account configuration of jitsi,
for SIP this is missing.

We currently support ICE (and hence TURN) for XMPP only.

Just out of interest, Lumicall uses the same ice4j code from the Jitsi
project to provide full ICE/STUN/TURN support in SIP - so theoretically,
Jitsi already has > 95% of what it needs to support ICE with SIP?

95% is a bit too optimistic I guess. You are right however that the
only piece missing is the code that integrates ice4j into our SIP
provider. This would require some serious refactoring however. We need
to make sure that we still support raw UDP/TCP with no ICE, that we
handle the SIP reINVITE-s that ICE requires, the ICE restarts during
HOLD/unHOLD and transfer, etc, etc.

It will still happen at some point of course. Just not sure when.

Why is that? Does jitsi support TURN with SIP? If so, where can/could i
enter the server address and credentials?

The main reason is that most SIP servers are configured to provide
hosted NAT traversal. They would override the SDP that clients send

- Asterisk does this when configured to relay all RTP for a peer, so it
is trivial to achieve with Asterisk.

I think it is the only way Asterisk could work. If I am not mistaken,
the only alternative is to use that option where it reINVITEs
participants after the call has been established but I don't think
anyone is actually using that.

But Asterisk is not a full SIP proxy,

True. It is a UA that does not support ICE which is why it wouldn't
work with Asterisk even if both the participating agents had it.

and doesn't supported federated SIP with TLS, for example.

I am quite sure that it does. I am using Asterisk's TLS every day.

- The SER derivatives (Kamailio, OpenSIPS) only do it when using
rtpproxy and the nathelper module - it is slightly more complicated to
set up and it can be painful to integrate with other customizations in
the config file.

That's it, and every single SIP provider using any of the above is
configured to work with it. Some would try to be smart and not perform
HNT for clients with public IP addresses (which is a slippery slope),
but most won't, so in this case too, ICE would most likely not work
either given that the default candidates will not match and ICE will
have to be abandoned (because of ICE mismatch).

- SDP mangling also works against things like secure (signed/encrypted)
SIP message bodies

- repro has no support for RTP media proxying - as it ships with a TURN
server

and put themselves in the media path for all calls. This is pretty
much equivalent to using a TURN server for every call. This is of
course somewhat less efficient than ICE but they are equivalent in
terms of NAT traversal reliability.

It is the combination of all reasons just given that suggests people
should go directly for ICE/TURN rather than the rtpproxy solutions

Maybe they should ... but they aren't :slight_smile:

Note that there are also objective reasons against using ICE. People
often rely on HNT for privacy reasons for example. Also, ICE greatly
increases the time necessary for call establishment which is often
perceived as a great problem.

I am not arguing against ICE per se. I am just saying that the case
for implementing it with SIP is not as strong as it is for XMPP.
Again, we will end up doing it but it will depend on when we manage to
get the necessary resources.

Cheers,
Emil

···

On Tue, Aug 7, 2012 at 1:16 PM, Daniel Pocock <daniel@pocock.com.au> wrote:

On 07/08/12 10:28, Emil Ivov wrote:

On Tue, Aug 7, 2012 at 11:53 AM, Dario Ernst <daddel9@kanojo.de> wrote:


#5

But Asterisk is not a full SIP proxy,

True. It is a UA that does not support ICE which is why it wouldn't
work with Asterisk even if both the participating agents had it.

and doesn't supported federated SIP with TLS, for example.

I am quite sure that it does. I am using Asterisk's TLS every day.

It does support TLS - but it does not fully adhere to RFC 5922, so it is
only really suitable for a `closed' network, e.g. connecting phones to
the server.

https://issues.asterisk.org/jira/browse/ASTERISK-19268
(a vital element of federated SIP security, not an enthusiastic response
from Digium)

https://issues.asterisk.org/jira/browse/19147

Also, the TLS support is still troublesome even when just using it for a
normal user agent:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683956

Dedicated SIP proxies like Kamailio and repro don't have any of those
issues, their TLS code is at a much higher standard, and they are
designed for connection to the public Internet. That is one reason why
people typically run a SIP proxy as a front end to Asterisk.

- The SER derivatives (Kamailio, OpenSIPS) only do it when using
rtpproxy and the nathelper module - it is slightly more complicated to
set up and it can be painful to integrate with other customizations in
the config file.

That's it, and every single SIP provider using any of the above is
configured to work with it. Some would try to be smart and not perform

That is OK for SIP providers. However, this level of complexity is not
OK for people wanting to run their own SIP server at home or in a small
business.

It is the combination of all reasons just given that suggests people
should go directly for ICE/TURN rather than the rtpproxy solutions

Maybe they should ... but they aren't :slight_smile:

I think that the tide will turn.

Note that there are also objective reasons against using ICE. People
often rely on HNT for privacy reasons for example. Also, ICE greatly
increases the time necessary for call establishment which is often
perceived as a great problem.

IPv6 may solve some of these issues too.

I am not arguing against ICE per se. I am just saying that the case
for implementing it with SIP is not as strong as it is for XMPP.
Again, we will end up doing it but it will depend on when we manage to
get the necessary resources.

Even offering experimental support for it (without re-INVITE) would be a
good start - that's all I did for Lumicall. I need to update the web
site to reflect the fact it is a proof of concept for open source mobile
VoIP. Just try to transfer a call and see what happens :slight_smile:

···

On 07/08/12 13:00, Emil Ivov wrote:


#6

Hey,

But Asterisk is not a full SIP proxy,

True. It is a UA that does not support ICE which is why it wouldn't
work with Asterisk even if both the participating agents had it.

and doesn't supported federated SIP with TLS, for example.

I am quite sure that it does. I am using Asterisk's TLS every day.

It does support TLS - but it does not fully adhere to RFC 5922, so it is
only really suitable for a `closed' network, e.g. connecting phones to
the server.

https://issues.asterisk.org/jira/browse/ASTERISK-19268
(a vital element of federated SIP security, not an enthusiastic response
from Digium)

https://issues.asterisk.org/jira/browse/19147

Good to know! Thanks for the note!

Also, the TLS support is still troublesome even when just using it for a
normal user agent:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683956

Dedicated SIP proxies like Kamailio and repro don't have any of those
issues, their TLS code is at a much higher standard, and they are
designed for connection to the public Internet. That is one reason why
people typically run a SIP proxy as a front end to Asterisk.

- The SER derivatives (Kamailio, OpenSIPS) only do it when using
rtpproxy and the nathelper module - it is slightly more complicated to
set up and it can be painful to integrate with other customizations in
the config file.

That's it, and every single SIP provider using any of the above is
configured to work with it. Some would try to be smart and not perform

That is OK for SIP providers. However, this level of complexity is not
OK for people wanting to run their own SIP server at home or in a small
business.

Definitely.

It is the combination of all reasons just given that suggests people
should go directly for ICE/TURN rather than the rtpproxy solutions

Maybe they should ... but they aren't :slight_smile:

I think that the tide will turn.

Hopefully!

Note that there are also objective reasons against using ICE. People
often rely on HNT for privacy reasons for example. Also, ICE greatly
increases the time necessary for call establishment which is often
perceived as a great problem.

IPv6 may solve some of these issues too.

Highly unlikely. IPv6 does not mean no-IPv4. Even with IPv6, one would
still need to harvest candidates and make connectivity checks.

There are however some optimizations that we can try in ice4j in order
to address the latency issue. Starting with a Single TurnServer /
Jingle Nodes candidate may be worth trying although it could lead to
other problems.

I am not arguing against ICE per se. I am just saying that the case
for implementing it with SIP is not as strong as it is for XMPP.
Again, we will end up doing it but it will depend on when we manage to
get the necessary resources.

Even offering experimental support for it (without re-INVITE) would be a
good start - that's all I did for Lumicall. I need to update the web
site to reflect the fact it is a proof of concept for open source mobile
VoIP. Just try to transfer a call and see what happens :slight_smile:

Well ... that's not exactly ICE then. Again, we will be working on ICE
for SIP as soon as time permits.

We do have loads of cool stuff coming though (video conferences,
android, a new interface, opus, VP8) so it'll have to wait a bit
before we get to it :slight_smile:

Emil

···

On Tue, Aug 7, 2012 at 6:09 PM, Daniel Pocock <daniel@pocock.com.au> wrote:

On 07/08/12 13:00, Emil Ivov wrote:


#7

Hey Guys,

thanks for all your clarifications about the SIP Situation in general
and ICE/TURN and that "hosted NAT traversal" in detail.

While i really appreciate the gain in knowledge, i feel a little at a
dead end here. I - as a admin - would really like to be able to provide
SIP to my endusers (and myself) since its widely used and has tons of
capable clients for mobile phones and other devices. While
XMPP/Jingle/JN is a really neat thing i feel that this fact kind of
forces me to also provide SIP to build a (to the enduser) feasible
"Skype Alternative".

So what would i do now?

I've ended up using repro/resiprocate because every other SIP server, be
it a proxy (kamailio) or a PBX (*) are so damn (excuse my klatchian)
overengeneered and made to fit each and every imaginable usecase that i
can't see how i would use them for just "federated voip". Especially
tiring is the fact that i've been looking for nat traversal techniques
for kamailio and *, but not found anything! In a few days of reading
documentation, howtos and even sourcecode i haven't come by what you
describe as "hosted nat traversal". Sure, some of those talk about "ahh,
just take that rtpproxy or that python thingy and deploy it next to our
server", but thats about it with instructions.

So even while this is the jitsi list ... do you have any experience with
that problem? If so, how did you solve it?

Thanks for all your work and explainations! I think that i too would
really love to see TURN support for SIP, as simplicity (for the enduser)
is a thing that would boost popularity ... and would maybe allow us to
win on front in the fight against Skype and other proprietary systems.

Best Regards and many Thanks!
- Dario


#8

Dario,

You can check out sipXecs (http://www.sipfoundry.org and the wiki at
http://wiki.sipfoundry.org). A true SIP proxy, has a SIP software SBC
included and XMPP.

It's built on top of some great open source projects such as freeswitch,
openfire, etc... Version 4.6 is just out for release now (still a little
young) but this adds some new features such as Homer (www.sipcapture.org)
fully integrated.

Enjoy.

Mike

···

On Wed, Aug 8, 2012 at 3:52 AM, Dario Ernst <daddel9@kanojo.de> wrote:

Hey Guys,

thanks for all your clarifications about the SIP Situation in general
and ICE/TURN and that "hosted NAT traversal" in detail.

While i really appreciate the gain in knowledge, i feel a little at a
dead end here. I - as a admin - would really like to be able to provide
SIP to my endusers (and myself) since its widely used and has tons of
capable clients for mobile phones and other devices. While
XMPP/Jingle/JN is a really neat thing i feel that this fact kind of
forces me to also provide SIP to build a (to the enduser) feasible
"Skype Alternative".

So what would i do now?

I've ended up using repro/resiprocate because every other SIP server, be
it a proxy (kamailio) or a PBX (*) are so damn (excuse my klatchian)
overengeneered and made to fit each and every imaginable usecase that i
can't see how i would use them for just "federated voip". Especially
tiring is the fact that i've been looking for nat traversal techniques
for kamailio and *, but not found anything! In a few days of reading
documentation, howtos and even sourcecode i haven't come by what you
describe as "hosted nat traversal". Sure, some of those talk about "ahh,
just take that rtpproxy or that python thingy and deploy it next to our
server", but thats about it with instructions.

So even while this is the jitsi list ... do you have any experience with
that problem? If so, how did you solve it?

Thanks for all your work and explainations! I think that i too would
really love to see TURN support for SIP, as simplicity (for the enduser)
is a thing that would boost popularity ... and would maybe allow us to
win on front in the fight against Skype and other proprietary systems.

Best Regards and many Thanks!
- Dario

--
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


#9

Was about to suggest this.

Thanks, Michael!

--sent from my mobile

···

On Aug 8, 2012 10:31 AM, "Michael Picher" <mpicher@gmail.com> wrote:

Dario,

You can check out sipXecs (http://www.sipfoundry.org and the wiki at
http://wiki.sipfoundry.org). A true SIP proxy, has a SIP software SBC
included and XMPP.

It's built on top of some great open source projects such as freeswitch,
openfire, etc... Version 4.6 is just out for release now (still a little
young) but this adds some new features such as Homer (www.sipcapture.org)
fully integrated.

Enjoy.

Mike

On Wed, Aug 8, 2012 at 3:52 AM, Dario Ernst <daddel9@kanojo.de> wrote:

Hey Guys,

thanks for all your clarifications about the SIP Situation in general
and ICE/TURN and that "hosted NAT traversal" in detail.

While i really appreciate the gain in knowledge, i feel a little at a
dead end here. I - as a admin - would really like to be able to provide
SIP to my endusers (and myself) since its widely used and has tons of
capable clients for mobile phones and other devices. While
XMPP/Jingle/JN is a really neat thing i feel that this fact kind of
forces me to also provide SIP to build a (to the enduser) feasible
"Skype Alternative".

So what would i do now?

I've ended up using repro/resiprocate because every other SIP server, be
it a proxy (kamailio) or a PBX (*) are so damn (excuse my klatchian)
overengeneered and made to fit each and every imaginable usecase that i
can't see how i would use them for just "federated voip". Especially
tiring is the fact that i've been looking for nat traversal techniques
for kamailio and *, but not found anything! In a few days of reading
documentation, howtos and even sourcecode i haven't come by what you
describe as "hosted nat traversal". Sure, some of those talk about "ahh,
just take that rtpproxy or that python thingy and deploy it next to our
server", but thats about it with instructions.

So even while this is the jitsi list ... do you have any experience with
that problem? If so, how did you solve it?

Thanks for all your work and explainations! I think that i too would
really love to see TURN support for SIP, as simplicity (for the enduser)
is a thing that would boost popularity ... and would maybe allow us to
win on front in the fight against Skype and other proprietary systems.

Best Regards and many Thanks!
- Dario

--
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


#10

Hey Michael,

thanks for your suggestion!

You can check out sipXecs (http://www.sipfoundry.org and the wiki at
http://wiki.sipfoundry.org). A true SIP proxy, has a SIP software SBC
included and XMPP.
It's built on top of some great open source projects such as freeswitch,
openfire, etc... Version 4.6 is just out for release now (still a
little young) but this adds some new features such as Homer
(www.sipcapture.org <http://www.sipcapture.org>) fully integrated.

I've been looking at this project already: sadly i've got two points
where i've got problems with it: First off its a real big meltingpot of
tons of other free software projects, which makes maintaining it hard.
As there are no Debian packages yet i'd have to build and maintain them
for myself. I doubt thats even possible, integrating all those projects
yet again. Also i cannot really see where i would get only a small
functionality out of this. I don't want a XMPP server (i already have
one), i don't want all those PBX functionality - whats missing is a
small, sleek, lean solution that does the right thing, and only the
right thing and no more. If i want more functionality i can always
integrate a * or so behind such a hosted-nat-traversal-sip-proxy. But i
can't find anything that does *only* that, and no (or at least little) more.

I know i'm a bit of a problem user with that. But having limited
resources on my server and the need to integrate something in a
pre-existing environment i fear sipXecs also doesn't suite my needs (and
the needs of many other users i think).

Thanks for the suggestion nonetheless!
- Dario

···

On 08/08/2012 10:31 AM, Michael Picher wrote:


#11

I resisted for a while as I don't want to sound like a broken record :slight_smile:

Hopefully at some point somebody will template jitsi config management into
the system.

Mike

···

On Wed, Aug 8, 2012 at 4:33 AM, Emil Ivov <emcho@jitsi.org> wrote:

Was about to suggest this.

Thanks, Michael!

--sent from my mobile
On Aug 8, 2012 10:31 AM, "Michael Picher" <mpicher@gmail.com> wrote:

Dario,

You can check out sipXecs (http://www.sipfoundry.org and the wiki at
http://wiki.sipfoundry.org). A true SIP proxy, has a SIP software SBC
included and XMPP.

It's built on top of some great open source projects such as freeswitch,
openfire, etc... Version 4.6 is just out for release now (still a little
young) but this adds some new features such as Homer (www.sipcapture.org)
fully integrated.

Enjoy.

Mike

On Wed, Aug 8, 2012 at 3:52 AM, Dario Ernst <daddel9@kanojo.de> wrote:

Hey Guys,

thanks for all your clarifications about the SIP Situation in general
and ICE/TURN and that "hosted NAT traversal" in detail.

While i really appreciate the gain in knowledge, i feel a little at a
dead end here. I - as a admin - would really like to be able to provide
SIP to my endusers (and myself) since its widely used and has tons of
capable clients for mobile phones and other devices. While
XMPP/Jingle/JN is a really neat thing i feel that this fact kind of
forces me to also provide SIP to build a (to the enduser) feasible
"Skype Alternative".

So what would i do now?

I've ended up using repro/resiprocate because every other SIP server, be
it a proxy (kamailio) or a PBX (*) are so damn (excuse my klatchian)
overengeneered and made to fit each and every imaginable usecase that i
can't see how i would use them for just "federated voip". Especially
tiring is the fact that i've been looking for nat traversal techniques
for kamailio and *, but not found anything! In a few days of reading
documentation, howtos and even sourcecode i haven't come by what you
describe as "hosted nat traversal". Sure, some of those talk about "ahh,
just take that rtpproxy or that python thingy and deploy it next to our
server", but thats about it with instructions.

So even while this is the jitsi list ... do you have any experience with
that problem? If so, how did you solve it?

Thanks for all your work and explainations! I think that i too would
really love to see TURN support for SIP, as simplicity (for the enduser)
is a thing that would boost popularity ... and would maybe allow us to
win on front in the fight against Skype and other proprietary systems.

Best Regards and many Thanks!
- Dario

--
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

--
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


#12

Hello,

Hey Michael,

thanks for your suggestion!

You can check out sipXecs (http://www.sipfoundry.org and the wiki at
http://wiki.sipfoundry.org). A true SIP proxy, has a SIP software SBC
included and XMPP.
It's built on top of some great open source projects such as freeswitch,
openfire, etc... Version 4.6 is just out for release now (still a
little young) but this adds some new features such as Homer
(www.sipcapture.org <http://www.sipcapture.org>) fully integrated.

I've been looking at this project already: sadly i've got two points
where i've got problems with it: First off its a real big meltingpot of
tons of other free software projects, which makes maintaining it hard.
As there are no Debian packages yet i'd have to build and maintain them
for myself. I doubt thats even possible, integrating all those projects
yet again. Also i cannot really see where i would get only a small
functionality out of this. I don't want a XMPP server (i already have
one), i don't want all those PBX functionality - whats missing is a
small, sleek, lean solution that does the right thing, and only the
right thing and no more. If i want more functionality i can always
integrate a * or so behind such a hosted-nat-traversal-sip-proxy. But i
can't find anything that does *only* that, and no (or at least little) more.

I know i'm a bit of a problem user with that. But having limited
resources on my server and the need to integrate something in a
pre-existing environment i fear sipXecs also doesn't suite my needs (and
the needs of many other users i think).

some notes related more to a previous message of this thread, but for sake of thread based browsing in archive, I am replying to the last message...

About Kamailio with nat traversal support using rtpproxy, for the last couple major releases, the default configuration file includes all what is needed in this regard, but those parts are disabled. To enable NAT traversal, just add:

#!define WITH_NAT

after the first line of kamailio.cfg (which is '#!KAMAILIO'). You need to install rtpproxy as well, then adjust the control socket either via rtpproxy module parameter in kamailio.cfg or via the command line option of rtpproxy. Actually, kamailio.cfg has some hint in this regard, pasting from there:

# *** To enable nat traversal execute:
# - define WITH_NAT
# - install RTPProxy: http://www.rtpproxy.org
# - start RTPProxy:
# rtpproxy -l _your_public_ip_ -s udp:localhost:7722

Other commonly used features are also in the default config file -- a tutorial about how to install and enable authentication is available at:

   * http://www.kamailio.org/wiki/install/3.3.x/git

For tls, just install tls module and add to config a line:

#!define WITH_TLS

Replace the self-signed ssl certificates from the kamailio config directory with your own, if you have better ones.
Federation by using DNS domains is out-of-the-box with default config, too.

I wrote a tutorial about using Kamailio and Jitsi for Skype like services, installing from debs, but for an older version (more than one year ago), 3.1:
   * http://kb.asipto.com/kamailio:skype-like-service-in-less-than-one-hour

The config there is the default from 3.1, adjusted with the changes listed above (enabled user auth, nat traversal and tls), so you can follow it even for newer versions.

Hope it helps,
Daniel

···

On 8/8/12 11:50 AM, Dario Ernst wrote:

On 08/08/2012 10:31 AM, Michael Picher wrote:

--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw

.


#13

Hello,

Hey Michael,

thanks for your suggestion!

You can check out sipXecs (http://www.sipfoundry.org and the wiki at
http://wiki.sipfoundry.org). A true SIP proxy, has a SIP software SBC
included and XMPP.
It's built on top of some great open source projects such as freeswitch,
openfire, etc... Version 4.6 is just out for release now (still a
little young) but this adds some new features such as Homer
(www.sipcapture.org <http://www.sipcapture.org>) fully integrated.

I've been looking at this project already: sadly i've got two points
where i've got problems with it: First off its a real big meltingpot of
tons of other free software projects, which makes maintaining it hard.
As there are no Debian packages yet i'd have to build and maintain them
for myself. I doubt thats even possible, integrating all those projects

That is what I've tried to address by packaging repro and reTurn

a) there are many people out there who feel exactly the same way as the
sysadmin who started the thread, imagine all those IT managers who have
a full time job that includes many things, desktop support, server
patching, less than 5% of their time for VoIP.

b) repro and reTurn do provide the simplest config file format, and when
using TURN (rather than rtpproxy) as a NAT solution, it is definitely
the most elegant and efficient. The golden rule: only use SIP clients
that support both TLS and ICE, and it should just work. People who
follow this rule will get it working.

yet again. Also i cannot really see where i would get only a small
functionality out of this. I don't want a XMPP server (i already have
one), i don't want all those PBX functionality - whats missing is a
small, sleek, lean solution that does the right thing, and only the
right thing and no more. If i want more functionality i can always
integrate a * or so behind such a hosted-nat-traversal-sip-proxy. But i
can't find anything that does *only* that, and no (or at least little)
more.

I know i'm a bit of a problem user with that. But having limited
resources on my server and the need to integrate something in a
pre-existing environment i fear sipXecs also doesn't suite my needs (and
the needs of many other users i think).

some notes related more to a previous message of this thread, but for
sake of thread based browsing in archive, I am replying to the last
message...

About Kamailio with nat traversal support using rtpproxy, for the last
couple major releases, the default configuration file includes all what
is needed in this regard, but those parts are disabled. To enable NAT
traversal, just add:

#!define WITH_NAT

< ... snip ... >

For tls, just install tls module and add to config a line:

#!define WITH_TLS

I agree kamailio can do this, and it is not too hard.

Remember, though, not everybody wants the inefficiency of relaying every
call. Emil mentioned a statistic from Google suggesting that only 8% of
calls need a relay, the others get by fine using STUN to discover their
public IP.

Another slight edge that repro has is the support for SIP OUTBOUND (and
the reg-id and instance-id URI parameters). These help eliminate
another common NAT problem, multiple registrations appearing from users
who have constantly changing IP addresses (e.g. mobile VoIP).

There are many, many people who would deploy federated SIP systems if it
was just `plug and play' - as easy as installing a mail server. That is
what I've aimed for with the repro/reTurn strategy.

I don't want to suggest that repro is in some way `better' than
Kamailio: just that they have different use cases, and I believe
repro+TURN is the ideal solution for the use case described.

.

···

On 08/08/12 11:34, Daniel-Constantin Mierla wrote:

On 8/8/12 11:50 AM, Dario Ernst wrote:

On 08/08/2012 10:31 AM, Michael Picher wrote:


#14

One solution that 'just works' is OpenSIPS + MediaProxy. It supports ICE in SIP end-points by inserting a valid TURN candidate in the ICE negotiation and requires no special settings in the clients.

http://mediaproxy.ag-projects.com/projects/mediaproxy/wiki/ICE

You can see it at work at http://sip2sip.info

Adrian

···

On Aug 8, 2012, at 2:02 PM, Daniel Pocock wrote:

On 08/08/12 11:34, Daniel-Constantin Mierla wrote:

Hello,

On 8/8/12 11:50 AM, Dario Ernst wrote:

Hey Michael,

thanks for your suggestion!

On 08/08/2012 10:31 AM, Michael Picher wrote:

You can check out sipXecs (http://www.sipfoundry.org and the wiki at
http://wiki.sipfoundry.org). A true SIP proxy, has a SIP software SBC
included and XMPP.
It's built on top of some great open source projects such as freeswitch,
openfire, etc... Version 4.6 is just out for release now (still a
little young) but this adds some new features such as Homer
(www.sipcapture.org <http://www.sipcapture.org>) fully integrated.

I've been looking at this project already: sadly i've got two points
where i've got problems with it: First off its a real big meltingpot of
tons of other free software projects, which makes maintaining it hard.
As there are no Debian packages yet i'd have to build and maintain them
for myself. I doubt thats even possible, integrating all those projects

That is what I've tried to address by packaging repro and reTurn

a) there are many people out there who feel exactly the same way as the
sysadmin who started the thread, imagine all those IT managers who have
a full time job that includes many things, desktop support, server
patching, less than 5% of their time for VoIP.

b) repro and reTurn do provide the simplest config file format, and when
using TURN (rather than rtpproxy) as a NAT solution, it is definitely
the most elegant and efficient. The golden rule: only use SIP clients
that support both TLS and ICE, and it should just work. People who
follow this rule will get it working.

yet again. Also i cannot really see where i would get only a small
functionality out of this. I don't want a XMPP server (i already have
one), i don't want all those PBX functionality - whats missing is a
small, sleek, lean solution that does the right thing, and only the
right thing and no more. If i want more functionality i can always
integrate a * or so behind such a hosted-nat-traversal-sip-proxy. But i
can't find anything that does *only* that, and no (or at least little)
more.

I know i'm a bit of a problem user with that. But having limited
resources on my server and the need to integrate something in a
pre-existing environment i fear sipXecs also doesn't suite my needs (and
the needs of many other users i think).

some notes related more to a previous message of this thread, but for
sake of thread based browsing in archive, I am replying to the last
message...

About Kamailio with nat traversal support using rtpproxy, for the last
couple major releases, the default configuration file includes all what
is needed in this regard, but those parts are disabled. To enable NAT
traversal, just add:

#!define WITH_NAT

< ... snip ... >

For tls, just install tls module and add to config a line:

#!define WITH_TLS

I agree kamailio can do this, and it is not too hard.

Remember, though, not everybody wants the inefficiency of relaying every
call. Emil mentioned a statistic from Google suggesting that only 8% of
calls need a relay, the others get by fine using STUN to discover their
public IP.

Another slight edge that repro has is the support for SIP OUTBOUND (and
the reg-id and instance-id URI parameters). These help eliminate
another common NAT problem, multiple registrations appearing from users
who have constantly changing IP addresses (e.g. mobile VoIP).

There are many, many people who would deploy federated SIP systems if it
was just `plug and play' - as easy as installing a mail server. That is
what I've aimed for with the repro/reTurn strategy.

I don't want to suggest that repro is in some way `better' than
Kamailio: just that they have different use cases, and I believe
repro+TURN is the ideal solution for the use case described.

.


#15

[....]

some notes related more to a previous message of this thread, but for
sake of thread based browsing in archive, I am replying to the last
message...

About Kamailio with nat traversal support using rtpproxy, for the last
couple major releases, the default configuration file includes all what
is needed in this regard, but those parts are disabled. To enable NAT
traversal, just add:

#!define WITH_NAT

< ... snip ... >

For tls, just install tls module and add to config a line:

#!define WITH_TLS

I agree kamailio can do this, and it is not too hard.

Remember, though, not everybody wants the inefficiency of relaying every
call. Emil mentioned a statistic from Google suggesting that only 8% of
calls need a relay, the others get by fine using STUN to discover their
public IP.

That could be in US, in Europe the percentage of symmetric NAT is higher and growing (every linux-based home router, like most of them these days, are using iptables natting which is symmetric), this kind of nat cannot be handled with STUN only.

Another slight edge that repro has is the support for SIP OUTBOUND (and
the reg-id and instance-id URI parameters). These help eliminate
another common NAT problem, multiple registrations appearing from users
who have constantly changing IP addresses (e.g. mobile VoIP).

That's also in kamailio 3.3.x (latest stable) - Outbound and even GRUU support.

There are many, many people who would deploy federated SIP systems if it
was just `plug and play' - as easy as installing a mail server. That is
what I've aimed for with the repro/reTurn strategy.

I don't want to suggest that repro is in some way `better' than
Kamailio: just that they have different use cases, and I believe
repro+TURN is the ideal solution for the use case described.

I cannot comment on repro, never used it.

But one thing has to be kept in mind regarding Kamailio -- it is more like a framework to build SIP routing applications. Config file is actually the application. The one shipped with the sources/packages (named here the default config), includes several features, some enabled, some disabled. It happens for this particular discussion that the features are in there (nat traversal, tls & others), but there are much more that can be added.

As for the comparison with mail servers, I am not sure we are far from that regarding default installation -- with a mail server I still have to adjust type of the server, local domains, relay hosts, add aliases, etc... And if I would have to compare exim config with Kamailio config, I believe we are the winner of simplicity.

Then, there are few relevant aspects that own email server might be more frequent out there:

  - email is older in the market than SIP/VoIP, thus more popular and more knowledge base out there
  - telephony/voice comms were monopoly in many countries till several years ago, there were not many jumping in this business
  - email started as decentralized service from day one based on IP/DNS, while IP telephony got trapped in the old PSTN architecture, most of providers being closed networks, connecting still via PSTN for the reason of getting some money. On the other hand, DNS interconnect is in SIP and, for that matter, it does not require anything in regards to config file of Kamailio
- SIP clients are very limited in UI, practically over 90% of devices used out there (hardphones) make impossible to dial @domain or other alphanumeric IDs
I think we will see more and more own-SIP-server adoption, being it a pbx or a proxy/router, but it needs a critical mass to really become that popular -- as a small self-SIP-service is hard to interconnect with PSTN and as long as you cannot reach many people out there, it is not attractive.

With email you can reach anyone as soon as you have your domain and email server up. It is not the case for SIP -- there are not many SIP providers with relevant subscriber base that allow calls from any foreign domain -- btw, default config file in kamailio accepts calls from foreign domains to local users and from local users to foreign domains.

So run-your-own-sip-server in the masses is closer and closer ... just a matter of time ... less hardphones and more apps in smartphones, plus some big companies out there behaving more badly :slight_smile:

Cheers,
Daniel

···

On 8/8/12 2:02 PM, Daniel Pocock wrote:

On 08/08/12 11:34, Daniel-Constantin Mierla wrote:

--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw


#16

I must have been referring to this document:

https://developers.google.com/talk/libjingle/important_concepts

(or a derivative).

Note however that I've heard these numbers being disputed by many
providers. All in all, the general consensus seems to be that it is all
related to the geographic region you are dealing with (probably for
reasons of vendor and hence implementation market share).

Some have mentioned that direct connections can only happen in less than
10% of the cases for regions such as the middle east.

Emil

···

On 08.08.12, 14:02, Daniel Pocock wrote:

Emil mentioned a statistic from Google suggesting that only 8% of
calls need a relay, the others get by fine using STUN to discover their
public IP.


#17

guess i don't understand why you need a TURN server to do this when a
standard SBC does this now.

we're set so people can email/im/sip to user@domain. one contact.

mike

···

On Wed, Aug 8, 2012 at 10:40 AM, Daniel Pocock <daniel@pocock.com.au> wrote:

On 08/08/12 12:57, Daniel-Constantin Mierla wrote:

>> Remember, though, not everybody wants the inefficiency of relaying every
>> call. Emil mentioned a statistic from Google suggesting that only 8% of
>> calls need a relay, the others get by fine using STUN to discover their
>> public IP.
> That could be in US, in Europe the percentage of symmetric NAT is higher
> and growing (every linux-based home router, like most of them these
> days, are using iptables natting which is symmetric), this kind of nat
> cannot be handled with STUN only.

I don't know the stats for phone, but for snail mail, apparently only 3%
is between private citizens, the other 97% is business-to-business mail,
or business-to-consumer mail

I think we need to imagine a world where businesses: large businesses
and little ones: operate their own TURN servers, rather than relying on
their ISP or VoIP provider.

In fact, that is exactly how Microsoft sees it too, they promote a TURN
server called Lync Edge, as part of their Lync platform.

With that vision in mind, the role of ICE/STUN/TURN becomes
significantly more prominent.

>> Another slight edge that repro has is the support for SIP OUTBOUND (and
>> the reg-id and instance-id URI parameters). These help eliminate
>> another common NAT problem, multiple registrations appearing from users
>> who have constantly changing IP addresses (e.g. mobile VoIP).
>
> That's also in kamailio 3.3.x (latest stable) - Outbound and even GRUU
> support.

Great, I hadn't been following closely enough, but now it is there I
will add it to the list of things to test with Lumicall (which generates
a UUID for instance-id)

>> There are many, many people who would deploy federated SIP systems if it
>> was just `plug and play' - as easy as installing a mail server. That is
>> what I've aimed for with the repro/reTurn strategy.
>>
>> I don't want to suggest that repro is in some way `better' than
>> Kamailio: just that they have different use cases, and I believe
>> repro+TURN is the ideal solution for the use case described.
> I cannot comment on repro, never used it.
>
> But one thing has to be kept in mind regarding Kamailio -- it is more
> like a framework to build SIP routing applications. Config file is
> actually the application. The one shipped with the sources/packages
> (named here the default config), includes several features, some
> enabled, some disabled. It happens for this particular discussion that
> the features are in there (nat traversal, tls & others), but there are
> much more that can be added.
>
> As for the comparison with mail servers, I am not sure we are far from
> that regarding default installation -- with a mail server I still have
> to adjust type of the server, local domains, relay hosts, add aliases,
> etc... And if I would have to compare exim config with Kamailio config,
> I believe we are the winner of simplicity.

Actually, I remember the days of sendmail configuration files, a real
pain. kamailio.cfg is definitely easier than sendmail.cf

Once again, though, the issue is about the user expectation: a lot of
users like a config file with `true/false' settings. The application
logic in kamailio.cfg actually intimidates people who don't have a
background in development.

Here is a sample repro.config:

https://www.resiprocate.org/ReproMutualTLSAuthenticationJitsi#Setup_the_repro_server

Notice how everything is easy to see with one glance?

Kamailio could do something similar, maybe parameterize the inputs to
kamailio.cfg, e.g. have a kamailio.ini file:

udp.port=5060
tls.port=5061

and then use placeholders (e.g. ${udp.port}) in kamailio.cfg to access
those values. Users would be instructed to never change kamailio.cfg -
just change the ini file

> Then, there are few relevant aspects that own email server might be more
> frequent out there:
>
I agree there have been many problems - no one product or person can be
blamed for the current state of VoIP federation (or the lack of it)

> I think we will see more and more own-SIP-server adoption, being it a
> pbx or a proxy/router, but it needs a critical mass to really become
> that popular -- as a small self-SIP-service is hard to interconnect with
> PSTN and as long as you cannot reach many people out there, it is not
> attractive.

Another big problem is that people are distracted: someone who sets up
Asterisk has actually done nothing towards federated VoIP, it is just a
private office system. Many people invest a lot of time and money in
Asterisk, and when they find out it is not suitable for federated use
(as per RFC 5922), they have no energy left to go further so they stop
there and leave it for another day.

> With email you can reach anyone as soon as you have your domain and
> email server up. It is not the case for SIP -- there are not many SIP
> providers with relevant subscriber base that allow calls from any
> foreign domain -- btw, default config file in kamailio accepts calls
> from foreign domains to local users and from local users to foreign
> domains.

Yes, many SIP providers have tried to emulate the model of traditional
phone companies: another distraction that has held back VoIP. Users who
buy those services think they are getting VoIP, but they are not getting
federated VoIP.

As I emphasized in the DebConf talk, businesses are now starting to play
with federated VoIP using Lync - I've seen this in various financial
organisations now. There is a real danger that a `critical mass' will
form around non-standard variations of SIP and ICE/TURN. Nonetheless,
the paradigm of using TURN on edge servers for each corporate is
something that is largely desirable.

--
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


#18

Remember, though, not everybody wants the inefficiency of relaying every
call. Emil mentioned a statistic from Google suggesting that only 8% of
calls need a relay, the others get by fine using STUN to discover their
public IP.

That could be in US, in Europe the percentage of symmetric NAT is higher
and growing (every linux-based home router, like most of them these
days, are using iptables natting which is symmetric), this kind of nat
cannot be handled with STUN only.

I don't know the stats for phone, but for snail mail, apparently only 3%
is between private citizens, the other 97% is business-to-business mail,
or business-to-consumer mail

I think we need to imagine a world where businesses: large businesses
and little ones: operate their own TURN servers, rather than relying on
their ISP or VoIP provider.

In fact, that is exactly how Microsoft sees it too, they promote a TURN
server called Lync Edge, as part of their Lync platform.

With that vision in mind, the role of ICE/STUN/TURN becomes
significantly more prominent.

Another slight edge that repro has is the support for SIP OUTBOUND (and
the reg-id and instance-id URI parameters). These help eliminate
another common NAT problem, multiple registrations appearing from users
who have constantly changing IP addresses (e.g. mobile VoIP).

That's also in kamailio 3.3.x (latest stable) - Outbound and even GRUU
support.

Great, I hadn't been following closely enough, but now it is there I
will add it to the list of things to test with Lumicall (which generates
a UUID for instance-id)

There are many, many people who would deploy federated SIP systems if it
was just `plug and play' - as easy as installing a mail server. That is
what I've aimed for with the repro/reTurn strategy.

I don't want to suggest that repro is in some way `better' than
Kamailio: just that they have different use cases, and I believe
repro+TURN is the ideal solution for the use case described.

I cannot comment on repro, never used it.

But one thing has to be kept in mind regarding Kamailio -- it is more
like a framework to build SIP routing applications. Config file is
actually the application. The one shipped with the sources/packages
(named here the default config), includes several features, some
enabled, some disabled. It happens for this particular discussion that
the features are in there (nat traversal, tls & others), but there are
much more that can be added.

As for the comparison with mail servers, I am not sure we are far from
that regarding default installation -- with a mail server I still have
to adjust type of the server, local domains, relay hosts, add aliases,
etc... And if I would have to compare exim config with Kamailio config,
I believe we are the winner of simplicity.

Actually, I remember the days of sendmail configuration files, a real
pain. kamailio.cfg is definitely easier than sendmail.cf

Once again, though, the issue is about the user expectation: a lot of
users like a config file with `true/false' settings. The application
logic in kamailio.cfg actually intimidates people who don't have a
background in development.

Here is a sample repro.config:

https://www.resiprocate.org/ReproMutualTLSAuthenticationJitsi#Setup_the_repro_server

Notice how everything is easy to see with one glance?

Kamailio could do something similar, maybe parameterize the inputs to
kamailio.cfg, e.g. have a kamailio.ini file:

udp.port=5060
tls.port=5061

and then use placeholders (e.g. ${udp.port}) in kamailio.cfg to access
those values. Users would be instructed to never change kamailio.cfg -
just change the ini file

Then, there are few relevant aspects that own email server might be more
frequent out there:

I agree there have been many problems - no one product or person can be
blamed for the current state of VoIP federation (or the lack of it)

I think we will see more and more own-SIP-server adoption, being it a
pbx or a proxy/router, but it needs a critical mass to really become
that popular -- as a small self-SIP-service is hard to interconnect with
PSTN and as long as you cannot reach many people out there, it is not
attractive.

Another big problem is that people are distracted: someone who sets up
Asterisk has actually done nothing towards federated VoIP, it is just a
private office system. Many people invest a lot of time and money in
Asterisk, and when they find out it is not suitable for federated use
(as per RFC 5922), they have no energy left to go further so they stop
there and leave it for another day.

With email you can reach anyone as soon as you have your domain and
email server up. It is not the case for SIP -- there are not many SIP
providers with relevant subscriber base that allow calls from any
foreign domain -- btw, default config file in kamailio accepts calls
from foreign domains to local users and from local users to foreign
domains.

Yes, many SIP providers have tried to emulate the model of traditional
phone companies: another distraction that has held back VoIP. Users who
buy those services think they are getting VoIP, but they are not getting
federated VoIP.

As I emphasized in the DebConf talk, businesses are now starting to play
with federated VoIP using Lync - I've seen this in various financial
organisations now. There is a real danger that a `critical mass' will
form around non-standard variations of SIP and ICE/TURN. Nonetheless,
the paradigm of using TURN on edge servers for each corporate is
something that is largely desirable.

···

On 08/08/12 12:57, Daniel-Constantin Mierla wrote:


#19

[...]

I think we need to imagine a world where businesses: large businesses
and little ones: operate their own TURN servers, rather than relying on
their ISP or VoIP provider.

In fact, that is exactly how Microsoft sees it too, they promote a TURN
server called Lync Edge, as part of their Lync platform.

With that vision in mind, the role of ICE/STUN/TURN becomes
significantly more prominent.

Support for TURN in clients would be a big relief for the SIP servers, because will obsolete the RTP relay -- it will be almost perfect if most of sip phones will support ice/stun/turn.

[...]

Once again, though, the issue is about the user expectation: a lot of
users like a config file with `true/false' settings. The application
logic in kamailio.cfg actually intimidates people who don't have a
background in development.

Here is a sample repro.config:

https://www.resiprocate.org/ReproMutualTLSAuthenticationJitsi#Setup_the_repro_server

Notice how everything is easy to see with one glance?

Kamailio could do something similar, maybe parameterize the inputs to
kamailio.cfg, e.g. have a kamailio.ini file:

udp.port=5060
tls.port=5061

and then use placeholders (e.g. ${udp.port}) in kamailio.cfg to access
those values. Users would be instructed to never change kamailio.cfg -
just change the ini file

This can be done with include files and/or defines. The first part of kamailio config file is for global parameters, which are in this format:

name=value

That part can be a separate file which is included in the main one via:

http://www.kamailio.org/wiki/cookbooks/3.3.x/core#include_file

Historically, from the first days of SER project, the target was that the admins should be fully aware of what the SIP server does. Apart of implicitly 'harmless' routing replies based on Via stack (as per RFC 3261), Kamailio does not do anything unless instructed via config routing blocks.

Splitting config in global parameters and routing blocks is extremely easy these days. There was no much interest in splitting the default config, and, IMO, one file give the chance to the people deploying it (and needing to adjust some parameters) to actually look over all content and (hopefully) become more aware of what they install.

We always took security very seriously (including privacy/tls), email was free service, if someone broke into email server app, it could send spam at expense of bandwidth, but not really direct critical financial damages. On the other hand, most of VoIP deployments are interconnected to PSTN and a break into it can have huge costs. From this perspective, no matter how much I would like to see lots of run-your-own-sip-server, I think people should get a bit of proper knowledge before adventuring to it.

Maybe because of 'do-nothing' default rule for requests, SER/Kamailio was not in the middle of dramatic stories with financial damages, but there are lot of them related to hacked IP PBX-es, because people just install the default with no minimum knowledge about what they actually did, what users they created, what is allowed without any security checks.

I guess the config for repo at the link you provided is just a sample, not including all the options/parameters that can be set there. And, just for example, somewhere I should read the docs to know that 5626 is a valid value for OutboundVersion and get also the alternatives that I could use if they fit better my needs. So 'one glance' is a matter of personal perspective and experience.

SIP is very flexible protocol, and if I think of some phones, they may have hundreds (if not thousands) of [cryptic name] options (like lynksys, snom) with many variants of [cryptic] values, making me feel the server config is too simple right now :slight_smile: .

Making a project easier to deploy is the goal of everyone, Jitsi conducting such efforts as well (e.g., auto/mass provisioning), but to succeed someone has to invest time and efforts. Unfortunately, proved by the facts, core developers are not the best/right persons to do that, for them all looks pretty simple. Community users have to take the lead, ask devs about how to do something and document (wiki, blogs, etc) -- in some cases could be easier than expected (like with this ini-style config for kamailio.cfg).

Seems like we diverted a bit from the subject of this mailing list (no much Jitsi in the content lately), sorry for the noise, but I think some real issues were approached here.

To conclude about stun/turn/ice, again, yes, they are good and I would like to see more devices/apps support them, a sip server has nothing to do with them, it's all about client side.

Cheers,
Daniel

···

On 8/8/12 4:40 PM, Daniel Pocock wrote:

--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw


#20

[...]

I think we need to imagine a world where businesses: large businesses
and little ones: operate their own TURN servers, rather than relying on
their ISP or VoIP provider.

In fact, that is exactly how Microsoft sees it too, they promote a TURN
server called Lync Edge, as part of their Lync platform.

With that vision in mind, the role of ICE/STUN/TURN becomes
significantly more prominent.

Support for TURN in clients would be a big relief for the SIP servers,
because will obsolete the RTP relay -- it will be almost perfect if most
of sip phones will support ice/stun/turn.

[...]

As mentioned previously, there are some strong suggestions that Polycom
could do this in a firmware release for their popular SoundPoint IP phones

and then use placeholders (e.g. ${udp.port}) in kamailio.cfg to access
those values. Users would be instructed to never change kamailio.cfg -
just change the ini file

This can be done with include files and/or defines. The first part of
kamailio config file is for global parameters, which are in this format:

name=value

That part can be a separate file which is included in the main one via:

http://www.kamailio.org/wiki/cookbooks/3.3.x/core#include_file

I agree it is pretty close to what I describe - maybe this could become
the default way of installing Kamailio?

To take it one step further, the full kamailio.cfg, with route logic,
would live in /usr/share or /usr/lib - just the properties file with
name=value stuff would be in /etc

Of course people could still run fully customized configs - but new
users would never see any of that any more

This type of simple config file is also very easily managed in packaging
systems, e.g. the debconf tool in Debian. It can ask the user questions
during package install (e.g. `Please tick checkboxes for the transports
you want [X] UDP [ ] TCP [ ] TLS' and then the debconf tool writes out
the properties file.
http://www.debian.org/doc/packaging-manuals/debconf_specification.html

Historically, from the first days of SER project, the target was that
the admins should be fully aware of what the SIP server does. Apart of
implicitly 'harmless' routing replies based on Via stack (as per RFC
3261), Kamailio does not do anything unless instructed via config
routing blocks.

Just to emphasize, I could use repro or Kamailio interchangeably myself
- I think it is a great design for someone who has more than 10% of
their job allocated to SIP and is really able to understand it

When I first saw the new MySQL support in repro (in v1.8), the first
thing that crossed my mind was making it interchangeable with Kamailio -
so somebody can start with repro and then upgrade to Kamailio if their
needs become more advanced:

http://list.resiprocate.org/archive/resiprocate-commit/msg06876.html

Maybe because of 'do-nothing' default rule for requests, SER/Kamailio
was not in the middle of dramatic stories with financial damages, but
there are lot of them related to hacked IP PBX-es, because people just
install the default with no minimum knowledge about what they actually
did, what users they created, what is allowed without any security checks.

I actually believe this is an administrative issue, not a technical issue

Too many people and companies sign open-ended contracts with their phone
company, like signing a blank cheque

Many more progressive phone companies now offer spending caps and
enforced credit limits - so the customer is not left with a 50,000 euro
bill.

I guess the config for repo at the link you provided is just a sample,
not including all the options/parameters that can be set there. And,
just for example, somewhere I should read the docs to know that 5626 is
a valid value for OutboundVersion and get also the alternatives that I
could use if they fit better my needs. So 'one glance' is a matter of
personal perspective and experience.

You are correct - I deliberately cut out stuff to make it look easy

But I am not completely cheating, the wiki page just shows those values
that are NOT set to their default, as in:

  diff repro.config.default repro.config.jitsi-tls-example

SIP is very flexible protocol, and if I think of some phones, they may
have hundreds (if not thousands) of [cryptic name] options (like
lynksys, snom) with many variants of [cryptic] values, making me feel
the server config is too simple right now :slight_smile: .

Polycom XML is another good example

But once again, for some of these, you only have to write a config file
that gives the non-default values - sometimes just 6-8 parameters.
Everything else will automatically be defaulted.

···

On 08/08/12 17:11, Daniel-Constantin Mierla wrote:

On 8/8/12 4:40 PM, Daniel Pocock wrote: