[SR-Users] kamailio 4.0.1 and nokia e72 udp

[hiro]

makes sense, cool. now i just have to find a version of rtpproxy that
supports this stuff :)

On 5/14/13, Andres <andres at 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 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
>
>