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

On 07-Feb-12 06:16, Sundar Subramaniyan wrote:
> 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.
>

this is wired, if the test was performed on different machines and 
at the *same* time.
The router lease time can be short therefor the keep-alive mechanism.

Can you please send the related PCAP/log_files to us, so that we can 
check what is going on?

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

If PJNATH says, it's "Port Restricted NAT" you can take it to the 
bank ;o)

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

Don't get your question, why would the same router has more that one 
level of NAT/NAPT?

BTW can you please try this, on both instances of PJSUA running on 
different machines, register an account and check the addresses in 
the Via Header and the one in the Contact header?
Alternative call an account on the public internet and check the 
logs (Address used).

Cheers,
Alain


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

-- 
                             ""
                           (o)(o)
                 _____o00o__(__)__o00o_____
3072D/146D10DE 2011-09-29    Alain Totouom  <totouom at gmx.de>
PGP Fingerprint 39A4F092 FFA7C746 CC305CB0 69091911 146D10DE



[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