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
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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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
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@gmail.com wrote:
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
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
I'm using rtpproxy with symmetric NAT, so that is no option. If the packet with offset IP is not received by rtpproxy the call is fine even with symmetric NAT. In case that wasn't clear earlier: I did narrow it down to this single test before posting to simplify and thus make it more clear to everyone. RTP itself is working fine with the E72, only rtpproxy gets confused by that single seemingly useless packet.
On 5/12/13, Leo Brown leo@netfuse.org wrote:
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@gmail.com wrote:
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
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
Hello,
On 5/12/13 9:48 PM, hiro wrote:
I'm using rtpproxy with symmetric NAT, so that is no option. If the packet with offset IP is not received by rtpproxy the call is fine even with symmetric NAT. In case that wasn't clear earlier: I did narrow it down to this single test before posting to simplify and thus make it more clear to everyone. RTP itself is working fine with the E72, only rtpproxy gets confused by that single seemingly useless packet.
it looks like rtpproxy needs to be patched, so that learning mode is kept for few packets and it will use the last src port for sending back traffic.
Other option could be playing with the firewall rules, to drop always first packet coming on rtpproxy ports range.
Cheers, Daniel
On 5/11/2013 4:29 PM, hiro 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.
I have seen such behavior before from other cheap NAT routers. The solution was to keep rtpproxy in "listen mode for port changes" always. That way it will keep working no matter how many times the port changes on the client side.
We are still running an older version of rtpproxy so I cannot comment on how to patch the lastest version. The version we have is 1.0.2 and the modification we did was to file main.c and commented the following aroubd line 1415: /*sp->canupdate[ridx] = 0;*/
Thats it.
It doesn't seem to be the router/NAT's problem though, as the Nokia itself binds to the right port at first, then gives up on it and changes to a port 20 higher instead. The second bind is also the one that it advertises in it's sdp.
But that tip with listen for port changes is good, it would only be problematic if there are multiple concurrent calls from the same (perhaps NATted) IP, right?
On 5/13/13, Andres andres@telesip.net wrote:
On 5/11/2013 4:29 PM, hiro 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.
I have seen such behavior before from other cheap NAT routers. The solution was to keep rtpproxy in "listen mode for port changes" always. That way it will keep working no matter how many times the port changes on the client side.
We are still running an older version of rtpproxy so I cannot comment on how to patch the lastest version. The version we have is 1.0.2 and the modification we did was to file main.c and commented the following aroubd line 1415: /*sp->canupdate[ridx] = 0;*/
Thats it.
-- Technical Support http://www.cellroute.net
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
On 5/13/2013 2:17 PM, hiro wrote:
It doesn't seem to be the router/NAT's problem though, as the Nokia itself binds to the right port at first, then gives up on it and changes to a port 20 higher instead. The second bind is also the one that it advertises in it's sdp.
But that tip with listen for port changes is good, it would only be problematic if there are multiple concurrent calls from the same (perhaps NATted) IP, right?
No, it would not be a problem because multiple calls would go to different destination UDP ports at the server. RTPproxy would be able to match them all dynamically even if the source port on the client (or clients) changes constantly during the calls. We have tested this extensively and has worked flawlessly for years. I works so well that even if the IP address on the client changes (like a DSL session going down and up again), the rtpproxy will match the new stream from the client immediatly.
makes sense, cool. now i just have to find a version of rtpproxy that supports this stuff :)
On 5/14/13, Andres andres@telesip.net wrote:
On 5/13/2013 2:17 PM, hiro wrote:
It doesn't seem to be the router/NAT's problem though, as the Nokia itself binds to the right port at first, then gives up on it and changes to a port 20 higher instead. The second bind is also the one that it advertises in it's sdp.
But that tip with listen for port changes is good, it would only be problematic if there are multiple concurrent calls from the same (perhaps NATted) IP, right?
No, it would not be a problem because multiple calls would go to different destination UDP ports at the server. RTPproxy would be able to match them all dynamically even if the source port on the client (or clients) changes constantly during the calls. We have tested this extensively and has worked flawlessly for years. I works so well that even if the IP address on the client changes (like a DSL session going down and up again), the rtpproxy will match the new stream from the client immediatly.
-- Technical Support http://www.cellroute.net
On 5/13/13, Andres andres@telesip.net wrote:
On 5/11/2013 4:29 PM, hiro 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.
I have seen such behavior before from other cheap NAT routers. The solution was to keep rtpproxy in "listen mode for port changes" always. That way it will keep working no matter how many times the port changes on the client side.
We are still running an older version of rtpproxy so I cannot comment on how to patch the lastest version. The version we have is 1.0.2 and the modification we did was to file main.c and commented the following aroubd line 1415: /*sp->canupdate[ridx] = 0;*/
Thats it.
-- Technical Support http://www.cellroute.net
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
-- Technical Support http://www.cellroute.net
-
Andres -
Daniel-Constantin Mierla -
hiro -
Leo Brown