On 5/12/13, Leo Brown leo@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