[SR-Users] kamailio 4.0.1 and nokia e72 udp

[Leo Brown]

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.

Leo

Leo Brown | Technical Director
*Netfuse Telecom Limited*
 +44 5601 056 056
 +1 347 566 4200

On 11 May 2013, at 21:30, hiro <23hiro at gmail.com> wrote:

using kamailio-4.0.1_src.tar.gz with rtpproxy and a nokia e72 behind
NAT registered via UDP I get no voice.
The e72 strangely sends a single udp packet from a wrong port (49152)
before the rtp stream should start.
This quirk of the e72 doesn't seem to work well with rtpproxy if the
following analysis is true:
rtpproxy detects that single UDP packet from the wrong port and so we
think that is where everything else will also come from and stop
listening on other ports. we then also answer on that wrong port.
Although all subsequent incoming packets arrive from the expected
(49172) port sent also in the sdp and to the right one we had sent in
the sdp earlier we never receive them, because we still listen on that
wrong port with that one bogus packet.

tcplog, rtp should be running, but no voice:
...
00:02:13.829682 IP p5795BC1A.dip0.t-ipconnect.de.49172 >
koln-5d81d2a9.pool.mediaWays.net.49184: UDP, length 73
00:02:13.847063 IP koln-5d81d2a9.pool.mediaWays.net.49184 >
p5795BC1A.dip0.t-ipconnect.de.49152: UDP, length 73
...

/usr/sbin/rtpproxy -l 93.129.210.169 -s
unix:/var/run/rtpproxy/rtpproxy.sock -u kamailio kamailio -p
/var/run/rtpproxy/rtpproxy.pid

...
DBUG:handle_command: received command "Uc100,8,0,98
_39ZSWQBoIfK_g5i6W1ACRdB0cBVaB 192.168.1.56 40000
o5r7rmu5p1hc7vci0591;1"
INFO:handle_command: new session _39ZSWQBoIfK_g5i6W1ACRdB0cBVaB, tag
o5r7rmu5p1hc7vci0591;1 requested, type strong
INFO:handle_command: new session on a port 49184 created, tag
o5r7rmu5p1hc7vci0591;1
INFO:handle_command: pre-filling caller's address with 192.168.1.56:40000
DBUG:doreply: sending reply "49184 93.129.210.169
"
DBUG:handle_command: received command "Lc100,98
_39ZSWQBoIfK_g5i6W1ACRdB0cBVaB 87.149.188.26 49172
o5r7rmu5p1hc7vci0591;1 5qt1pav3
INFO:handle_command: lookup on ports 49184/49196, session timer restarted
INFO:handle_command: pre-filling callee's address with 87.149.188.26:49172
DBUG:doreply: sending reply "49196 93.129.210.169
"
INFO:rxmit_packets: callee's address filled in: 87.149.188.26:49152 (RTP)


DBUG:handle_command: received command "D
_39ZSWQBoIfK_g5i6W1ACRdB0cBVaB 5qt1pav3dsafun5p47o30tj2od1urm6v
o5r7rmu5p1hc7vci0591"
INFO:handle_delete: forcefully deleting session 1 on ports 49184/49196
INFO:remove_session: RTP stats: 1 in from callee, 3465 in from caller,
3466 relayed, 0 dropped
INFO:remove_session: RTCP stats: 0 in from callee, 0 in from caller, 0
relayed, 0 dropped
INFO:remove_session: session on ports 49184/49196 is cleaned up
DBUG:doreply: sending reply "0

what do you guys think? it only occured with kamailio+rtpproxy so far.
any insight about why the e72 sends such packet? it doesn't happen
when i use sip over tcp. is my analysis right, is it a bug in
rtpproxy?

greetings
hiro

_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20130511/56faa7eb/attachment.html>