Am 08.02.2011 09:36, schrieb Laurent Schweizer: > yes, I think it's exactly this case. > > but now I have a question, > > I think that the nathelper module can get and transmit to rtpproxy the > correct source IP (but not the port), if it's a public IP in SDP we can > trust them so we can force natheper to use them or if the phone is behind a
If I understand the documentation right, this is done by the 'r' flag. > NAT and we have a private IP in the SDP he will use the public source IP of > the SIP message. Yes, that would be nice. > so in this case , why we allow the rtpproxy to update the pre-filled IP (the > ip passed by the nathelper to rtpproxy) with one different ? I think that > just the port can change. I think we must just reject packet with a > different IP. I think the main problem is that the behavior of rtpproxy is more or less undocumented, so we do not know if it is a bug or a failure in the design. regards klaus > > Regards > > Laurent > > -----Message d'origine----- > De : Klaus Darilion [mailto:klaus.mailingli...@pernau.at] > Envoyé : mardi 8 février 2011 09:12 > À : RTPproxy Users > Objet : Re: [RTPproxy Users] rtpproxy , problem with trusted IP > > > > Am 07.02.2011 17:16, schrieb Alex Hermann: >> On Wednesday 02 February 2011, Laurent Schweizer wrote: >>> Small problem with rtpproxy and nathelper >>> >>> >>> >>> as you can see in the log bellow , I use the force_rtp_proxy method with >>> the 'r' flag to indicate to trust the IP of the SDP. >>> >>> >>> >>> In the example bellow, the trusted IP is "95.128.80.6 3966" , the problem >>> is that the old rtp source (in this case a MoH server) continue to send 1 >>> or 2 packet so the RTP proxy change them with "95.128.80.92:1086" so >>> packet are not correctly forwarded. >>> >>> >>> >>> If the IP must be trusted why he take care of a received Packet ? >> >> I had a similar issue, which went unanswered on the mailinglist. A > followup >> mail of me had a patch attached, it should fix your issue as well. It will > not >> stop "learning" new addresses, but will accept the later address as > preferred. >> >> See my mail on rtpproxy-devel from 25-10-2010. > > Maybe related: At the end of this CCC talk the presenter mentions a > strange "latching" behavior of rtpproxy (it starts at 26:15) > > http://www.kapejod.org/2010/12/27c3-having-fun-with-rtp/ > > regards > Klaus > > _______________________________________________ > Users mailing list > Users@rtpproxy.org > http://lists.rtpproxy.org/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users@rtpproxy.org > http://lists.rtpproxy.org/mailman/listinfo/users _______________________________________________ Users mailing list Users@rtpproxy.org http://lists.rtpproxy.org/mailman/listinfo/users
