[SR-Users] kamailio 4.0.1 and nokia e72 udp

[Andres]

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 at 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 at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>


-- 
Technical Support
http://www.cellroute.net