makes sense, cool. now i just have to find a version of rtpproxy that supports this stuff :)
On 5/14/13, Andres <and...@telesip.net> wrote: > On 5/13/2013 2:17 PM, hiro wrote: >> It doesn't seem to be the router/NAT's problem though, as the Nokia >> itself binds to the right port at first, then gives up on it and >> changes to a port 20 higher instead. The second bind is also the one >> that it advertises in it's sdp. >> >> But that tip with listen for port changes is good, it would only be >> problematic if there are multiple concurrent calls from the same >> (perhaps NATted) IP, right? > No, it would not be a problem because multiple calls would go to > different destination UDP ports at the server. RTPproxy would be able > to match them all dynamically even if the source port on the client (or > clients) changes constantly during the calls. We have tested this > extensively and has worked flawlessly for years. I works so well that > even if the IP address on the client changes (like a DSL session going > down and up again), the rtpproxy will match the new stream from the > client immediatly. > > -- > Technical Support > http://www.cellroute.net > > >> >> On 5/13/13, Andres <and...@telesip.net> wrote: >>> On 5/11/2013 4:29 PM, hiro wrote: >>>> using kamailio-4.0.1_src.tar.gz with rtpproxy and a nokia e72 behind >>>> NAT registered via UDP I get no voice. >>>> The e72 strangely sends a single udp packet from a wrong port (49152) >>>> before the rtp stream should start. >>>> This quirk of the e72 doesn't seem to work well with rtpproxy if the >>>> following analysis is true: >>>> rtpproxy detects that single UDP packet from the wrong port and so we >>>> think that is where everything else will also come from and stop >>>> listening on other ports. we then also answer on that wrong port. >>>> Although all subsequent incoming packets arrive from the expected >>>> (49172) port sent also in the sdp and to the right one we had sent in >>>> the sdp earlier we never receive them, because we still listen on that >>>> wrong port with that one bogus packet. >>>> >>> I have seen such behavior before from other cheap NAT routers. The >>> solution was to keep rtpproxy in "listen mode for port changes" always. >>> That way it will keep working no matter how many times the port changes >>> on the client side. >>> >>> We are still running an older version of rtpproxy so I cannot comment on >>> how to patch the lastest version. The version we have is 1.0.2 and the >>> modification we did was to file main.c and commented the following >>> aroubd line 1415: >>> /*sp->canupdate[ridx] = 0;*/ >>> >>> Thats it. >>> >>> -- >>> Technical Support >>> http://www.cellroute.net >>> >>> >>> _______________________________________________ >>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >>> sr-users@lists.sip-router.org >>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >>> > > > -- > Technical Support > http://www.cellroute.net > > _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
