makes sense, cool. now i just have to find a version of rtpproxy that supports this stuff :)
On 5/14/13, Andres andres@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 andres@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