[SR-Users] kamailio 4.0.1 and nokia e72 udp

[hiro]

I'm using rtpproxy with symmetric NAT, so that is no option. If the
packet with offset IP is not received by rtpproxy the call is fine
even with symmetric NAT. In case that wasn't clear earlier: I did
narrow it down to this single test before posting to simplify and thus
make it more clear to everyone.
RTP itself is working fine with the E72, only rtpproxy gets confused
by that single seemingly useless packet.

On 5/12/13, Leo Brown <leo at netfuse.org> wrote:
> Hi
>
> Have you tried using the "a" mode of force_rtp_proxy?
>
> This will disable symmetric RTP which it seems is broken by your E72.
>
> Leo
>
> On 12 May 2013, at 12:39, hiro <23hiro at gmail.com> wrote:
>
>> On 5/12/13, Leo Brown <leo at netfuse.org> wrote:
>>> Hi
>>>
>>> I don't know the e72, but if you do a `tcpdump -A -s0 port 5060` we can
>>> see
>>> the SDP data to determine the issue
>>>
>>> RTP should be sent to the address defined in SDP unless a symmetric RTP
>>> setup is used for auto NAT traversal- but I believe only Asterisk
>>> provides
>>> this, not rtpproxy.
>>
>> the SDP data seems fine to me. The only discrepancy was an
>> initial off-port packet from the E72, resulting in rtpproxy to report
>> the wrong port to kamailio. I assume a workaround would be to change
>> rtpproxy to wait for at least 2 packets from the same port. But I
>> imagine someone might have seen such issues with other Nokia phones
>> when using UDP? I can't reproduce it with a Nokia E5-00. Is this
>> behavior common? Does it happen with other phones?
>>
>> An other observation: 49152 is the start media port in nokia config.
>> 49152+20 is 49172.
>> If I change that to 40000 I get initial single packet from 40000 and
>> later real rtp packets from 40020. There always seems to be an offset
>> of 20. If I enable rtcp the rtcp port is 40001 in both initial packet
>> and later packets. The rest stays the same.
>>
>> Here is a more complete tcpdump showing the whole problem again:
>>
>> sdp when we invite the e72:
>> Content-Type: application/sdp
>> Accept-Language: de
>> Content-Length: 371
>>
>> v=0
>> o=3 63536614042291000 63536614042291000 IN IP4 93.129.248.7
>> s=-
>> c=IN IP4 93.129.248.7
>> t=0 0
>> m=audio 49180 RTP/AVP 100 8 0 98
>> a=sendrecv
>> a=rtpmap:100 AMR-WB/16000
>> a=ptime:20
>> a=maxptime:200
>> a=fmtp:100 mode-change-period=2; mode-change-neighbor=1
>> a=rtpmap:8 PCMA/8000
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:98 telephone-event/8000
>> a=fmtp:98 0-15
>> a=nortpproxy:yes
>>
>> normal SIP/2.0 100 Trying response
>>
>> ###This is strange. Single UDP packet coming from e72, from
>> random? port to correct rtp port on our side. It is the only packet
>> ever sent from 49152 port?
>> 11:27:48.772808 IP pD4B88CC0.dip0.t-ipconnect.de.49152 >
>> koln-5d81f807.pool.mediaWays.net.49180: UDP, length 13
>> E..)....<.......].........zb.x<..rPxC....
>>
>> then a normal SIP/2.0 180 Ringing response
>>
>> And then in this sdp from SIP/3.0 200 OK response we see port 49168
>> advertised by the e72, which is also what the NAT keeps using as the
>> real outgoing port in the RTP stream that begind afterwards.
>> Content-Type: application/sdp
>> Content-Length: 293
>>
>> v=0
>> o=8 63536614067392625 63536614067392625 IN IP4 212.184.140.192
>> s=-
>> c=IN IP4 212.184.140.192
>> t=0 0
>> m=audio 49168 RTP/AVP 100 98
>> a=sendrecv
>> a=rtpmap:100 AMR-WB/16000
>> a=ptime:20
>> a=maxptime:200
>> a=fmtp:100 mode-set=0,1,2,3,4,5,6,7,8
>> a=rtpmap:98 telephone-event/8000
>> a=fmtp:98 0-15
>>
>> rtp stream then goes like this (with the wrong 49152 port instead of
>> 49180,
>> because of that strange single erratic packet rtpproxy had received
>> with 49152 port):
>>
>> 11:27:51.985252 IP koln-5d81f807.pool.mediaWays.net.49180 >
>> pD4B88CC0.dip0.t-ipconnect.de.49152: UDP, length 13
>> 11:27:52.240291 IP pD4B88CC0.dip0.t-ipconnect.de.49168 >
>> koln-5d81f807.pool.mediaWays.net.49180: UDP, length 73
>> 11:27:52.307888 IP koln-5d81f807.pool.mediaWays.net.49180 >
>> pD4B88CC0.dip0.t-ipconnect.de.49152: UDP, length 73
>> 11:27:52.350607 IP pD4B88CC0.dip0.t-ipconnect.de.49168 >
>> koln-5d81f807.pool.mediaWays.net.49180: UDP, length 73
>>
>> thanks for your considerations
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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
>