[SR-Users] kamailio 4.0.1 and nokia e72 udp

[hiro]

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