STUN in local network

TG
Thiago Guimarães
Mon, May 22, 2017 3:18 PM

Hi Nahum Nir

About your question regarding INVITE;

  • Yes, if the endpoints accounts are not using STUN/ICE, in any
    scenario I've tested, the INVITES arrived successfully.
  • The same thing with STUN enabled to the endpoint account.
  • But, enabling ICE, the INVITE does not arrive to the other endpoint,
    when the two endpoints are bellow a SYMMETRIC NAT. The Kamailio
    server sends to me "SIP/2.0 100 trying", but the INVITE not arrives to
    the other endpoint.

I'm using Kamailio to my SIP Server, with public IP. Still without the
RTPProxy configuration.

Thank you,
Thiago Guimarães

On Sat, May 20, 2017 at 2:28 PM, Nahum Nir hello.shalom.hi@gmail.com wrote:

ICE and STUN are media related so you should have at least have a call going
established without media. Do INVITEs get without doing anything regarding
STUN/ICE?

On 17 May 2017 05:38, "Thiago Guimarães" thiago.barcelos@gmail.com wrote:

The first network in question, which to me the STUN server reveals as
PJ_STUN_NAT_TYPE_PORT_RESTRICTED, is below another network that STUN
shows as PJ_STUN_NAT_TYPE_SYMMETRIC.

So, I'm running tests using ICE enabled, without setting up a TURN
server, in an attempt to find them on the local network. However, I'm
noticing that when ICE is enabled, the INVITE gets to the SIP server
(Kamailio), but I can not figure out why the INVITE does not reach the
other endpoint.

The main problem I want to understand / solve in this case is the call
on the local network (which is below a symmetric NAT), using STUN,
because I will also receive calls outside this network, which
apparently is already working well.

Maybe it´s a simple problem, but I still can't understanded, Why does
audio not "travel" to endpoints on the same network (with symmetric
NAT) when STUN is enabled? Do I need a TURN server for audio to
traffic on the same network?

If anyone can help me,
Thanks.
Thiago Guimarães

On Thu, May 11, 2017 at 3:32 PM, Thiago Guimarães
thiago.barcelos@gmail.com wrote:

Hello,

I'm using pjsua2 in conjunction with the classes and functions of pjlib
for
an application. But I'm having a little problem, which I could not solve.

On the same specific network, I have two endpoints registered on a remote
SIP server (public ip). When they are set to use STUN, I can do / accept
INVITE, but the audio does not travel over the network. In the same
environment, if one of the endpoints is not using STUN, audio travels
normally. Another detail, with STUN enabled at both endpoints, if one of
these endpoints is on another network, audio travels normally.

However, in another network with the same characteristics
(PJ_STUN_NAT_TYPE_PORT_RESTRICTED) according to the STUN resolution, the
two
endpoints "talk" normally.

Evaluating the firewall of this first network, I found nothing that could
be
blocking this communication.

Comparing the pjsip logs to the Xcode console, I could not find any
information that could help me understand what's happening.

If anyone can help me,
Thank
s
.
Thiago
Guimarães
.

Hi Nahum Nir About your question regarding INVITE; - Yes, if the endpoints accounts are not using STUN/ICE, in any scenario I've tested, the INVITES arrived successfully. - The same thing with STUN enabled to the endpoint account. - But, enabling ICE, the INVITE does not arrive to the other endpoint, when the *two* endpoints are bellow a SYMMETRIC NAT. The Kamailio server sends to me "SIP/2.0 100 trying", but the INVITE not arrives to the other endpoint. I'm using Kamailio to my SIP Server, with public IP. Still without the RTPProxy configuration. Thank you, Thiago Guimarães On Sat, May 20, 2017 at 2:28 PM, Nahum Nir <hello.shalom.hi@gmail.com> wrote: > ICE and STUN are media related so you should have at least have a call going > established without media. Do INVITEs get without doing anything regarding > STUN/ICE? > > On 17 May 2017 05:38, "Thiago Guimarães" <thiago.barcelos@gmail.com> wrote: > > The first network in question, which to me the STUN server reveals as > PJ_STUN_NAT_TYPE_PORT_RESTRICTED, is below another network that STUN > shows as PJ_STUN_NAT_TYPE_SYMMETRIC. > > So, I'm running tests using ICE enabled, without setting up a TURN > server, in an attempt to find them on the local network. However, I'm > noticing that when ICE is enabled, the INVITE gets to the SIP server > (Kamailio), but I can not figure out why the INVITE does not reach the > other endpoint. > > The main problem I want to understand / solve in this case is the call > on the local network (which is below a symmetric NAT), using STUN, > because I will also receive calls outside this network, which > apparently is already working well. > > Maybe it´s a simple problem, but I still can't understanded, Why does > audio not "travel" to endpoints on the same network (with symmetric > NAT) when STUN is enabled? Do I need a TURN server for audio to > traffic on the same network? > > If anyone can help me, > Thanks. > Thiago Guimarães > > On Thu, May 11, 2017 at 3:32 PM, Thiago Guimarães > <thiago.barcelos@gmail.com> wrote: >> Hello, >> >> I'm using pjsua2 in conjunction with the classes and functions of pjlib >> for >> an application. But I'm having a little problem, which I could not solve. >> >> On the same specific network, I have two endpoints registered on a remote >> SIP server (public ip). When they are set to use STUN, I can do / accept >> INVITE, but the audio does not travel over the network. In the same >> environment, if one of the endpoints is not using STUN, audio travels >> normally. Another detail, with STUN enabled at both endpoints, if one of >> these endpoints is on another network, audio travels normally. >> >> However, in another network with the same characteristics >> (PJ_STUN_NAT_TYPE_PORT_RESTRICTED) according to the STUN resolution, the >> two >> endpoints "talk" normally. >> >> Evaluating the firewall of this first network, I found nothing that could >> be >> blocking this communication. >> >> Comparing the pjsip logs to the Xcode console, I could not find any >> information that could help me understand what's happening. >> >> If anyone can help me, >> Thank >> s >> . >> Thiago >> Guimarães >> . > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > >