Hi Sundar, On 07-Feb-12 09:33, Sundar Subramaniyan wrote: > Hi Alain, > > The issue I face is registration could not be performed under NAT. The > registration is OK if I use a connection without NAT. > The registration request is sent many times without any response. I suspect > this is because of the invalid mapping obtained by STUN. > that might not be the reason why your REGISTER request is not going through. The Registrar if it gets/processes the request, would then notify you about a discrepancy with what your request claims the mapped port is, rport being used in the first place. > 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. >> > The two instances were run on the same time. Taking the STUN mapping alone > into account, the mapped addresses are same. > Yep, did try and you are correct. The STUN part (Binding Request/Response) is also correct. Did use the same iptel.org registrar with the same setting and everything is working perfectly. The thing i would like to try is receiving a call from both endpoints and see where the router sends that inbound request to ;o) But no time for that now! > Don't get your question, why would the same router has more that one level >> of NAT/NAPT? >> > I think i understood incorrectly from you, that the NAT is "full cone" as > viewed by the STUN server/client and "port restricted" from the inside. I > thought you meant there could be different levels of NAT within the same > router ;) > > Can you please send the related PCAP/log_files to us, so that we can check >> what is going on? >> > Please find attached the log captured from the console when running pjsua. > I use pjsip version 1.10. > From your logs, everything is just fine. There is something you need to figure out: why is the registrar not getting your packets. As i stated previously, did the same test with the same setting (Port restricted NAT), same registrar with different results. > 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? >> > Sorry, I cannot try it as the registration is failing. > You can force the proxy to talk to you and at least send you a 401/INVITE and then you check the rport thing ;o) Cheers, Alain > Thanks, > Sundar > > > On Tue, Feb 7, 2012 at 1:17 PM, Alain Totouom<alain.totouom at gmx.de> wrote: > >> 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> >>>> <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 >> >> ______________________________**_________________ >> 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> >> > > > > _______________________________________________ > 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 -- "" (o)(o) _____o00o__(__)__o00o_____ 3072D/146D10DE 2011-09-29 Alain Totouom <totouom at gmx.de> PGP Fingerprint 39A4F092 FFA7C746 CC305CB0 69091911 146D10DE
