Mapped ports using STUN in pjsua seems to be same as original ports

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Alain,

I tested the scenario with two machines under the router running pjsua with
same configuration.
The two instances declare the mapped ports to be same. RTP/RTCP ports from
4000 to 4007 and SIP UDP port to be 5060.

Per RFC 3489, referring to section 5 (Types of NAT), I believe that the
router does "port Restricted NAT" and this is what is discovered by pjnath
STUN client.
Per section 14 (limitations of STUN), there is no mention of port mapping
issues when only one instance of STUN client runs behind NAT.

So if there is more than one level of NAT/NAPT in the same router, will the
mapping fail?

Regards,
Sundar

On Thu, Feb 2, 2012 at 4:31 PM, Alain Totouom <alain.totouom at gmx.de> wrote:

> Hi Sundar,
>
>
> On 31-Jan-12 09:56, Sundar Subramaniyan wrote:
>
>> Hi all,
>>
>> The question is about the pjsua application, used with STUN (using host
>> stun.pjsip.org)
>>
>> The public IP address reported is correct, however the mapped ports look
>> the same as their original source ports. i.e. 5060 (SIP UDP port), and
>> 4000-4007 (RTP/RTCP ports)
>> It seemed to be valid to me initially since some home routers may perform
>> address translation alone.
>> But I checked if these ports are open from online port scanners, and they
>> seem to be closed from the outside.
>>
>> I've tried the application behind two different routers configured with
>> NAT. The behavior seems to be same. I didn't get a different port mapped
>> to
>> the source ports.
>> The NAT types detected were "port restricted" and "restricted" when using
>> different routers.
>>
>> I've only used the --stun-srv option without TURN/ICE.
>>
>> Is there any configuration I need to do to get the mapped ports apart from
>> specifying stun-srv?
>>
>>
> both routers do have *full cone NAT*, thus will try to map the same
> internal ip:port to the same external ip:port.
>
> The online port scanner fails because of the underlying *restricted cone*
> and *Port Restricted Cone* NAT. Both are full cone NAT with additional
> restrictions. May be you wanna check RFC #3489.
>
> To get the mapped port apart, run two different instances of pjsua behind
> the same router ;o)
>
> Cheers,
> Alain
>
>
>  Thanks in advance,
>> Sundar
>>
>
> --
>                            ""
>                          (o)(o)
>                _____o00o__(__)__o00o_____
> 3072D/146D10DE 2011-09-29    Alain Totouom  <totouom at gmx.de>
> PGP Fingerprint 39A4F092 FFA7C746 CC305CB0 69091911 146D10DE
>
> ______________________________**_________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/**mailman/listinfo/pjsip_lists.**pjsip.org<http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20120207/fba05f43/attachment.html>


[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux