[SR-Users] kamailio 4.0.1 and nokia e72 udp

[Leo Brown]

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