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 <23h...@gmail.com> wrote: > On 5/12/13, Leo Brown <l...@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
