RTP traffic from VOIP provider? (solved)

Discussions about using SIP Sorcery on your own computer/server
Post Reply
Nebukadnezar
Posts: 47
Joined: Tue Aug 10, 2010 1:46 pm

RTP traffic from VOIP provider? (solved)

Post by Nebukadnezar » Tue Sep 21, 2010 4:40 pm

The last couple of days I have been studying my firewall logs and noticed lots of dropped packets from my VOIP provider (voipplanet.nl); the dropped packets where all addressed to my server but originated with the provider, therefore my firewall dropped them. The last day I got series of 5K+ packets per second and my router crashed several times because of that. According to my provider, no unnecessary traffic was send to my server.
I decided to capture some of those packets (aimed at high numbered UDP ports) and take a closer look at them, so I installed Wireshark and let it run for a while using as filter [src host 84.243.247.100 ] and got nothing! (because my firewall dropped them all off course) so I inserted a temporary firewall rule that would allow all that, otherwise dropped, traffic to pass through.

And I got the following trace while making a call:

Code: Select all

27	2010-09-21 17:50:11.394375	84.243.247.100	192.168.0.5	SIP/SDP	Request: INVITE sip:xxxxx@212.187.xxx.xxx, with session description
28	2010-09-21 17:50:11.397864	84.243.247.100	192.168.0.5	SIP	Status: 180 Ringing
29	2010-09-21 17:50:16.561758	84.243.247.100	192.168.0.5	SIP	Request: ACK sip:212.187.xxx.xxx:5060
30	2010-09-21 17:50:16.564337	84.243.247.100	192.168.0.5	SIP/SDP	Status: 200 OK, with session description
31	2010-09-21 17:50:16.564476	84.243.247.100	192.168.0.5	RTP	PT=ITU-T G.729, SSRC=0x71CEB393, Seq=28955, Time=4160626544, Mark 
32	2010-09-21 17:50:16.586068	84.243.247.100	192.168.0.5	RTP	PT=ITU-T G.729, SSRC=0x71CEB393, Seq=28956, Time=4160626704 
33	2010-09-21 17:50:16.603432	84.243.247.100	192.168.0.5	RTP	PT=ITU-T G.729, SSRC=0x71CEB393, Seq=28957, Time=4160626864 
34	2010-09-21 17:50:16.623825	84.243.247.100	192.168.0.5	RTP	PT=ITU-T G.729, SSRC=0x71CEB393, Seq=28958, Time=4160627024 
35	2010-09-21 17:50:16.642597	84.243.247.100	192.168.0.5	RTP	PT=ITU-T G.729, SSRC=0x71CEB393, Seq=28959, Time=4160627184 
36	2010-09-21 17:50:16.662811	84.243.247.100	192.168.0.5	RTP	PT=ITU-T G.729, SSRC=0x71CEB393, Seq=28960, Time=4160627344 
37	2010-09-21 17:50:16.685215	84.243.247.100	192.168.0.5	RTP	PT=ITU-T G.729, SSRC=0x71CEB393, Seq=28961, Time=4160627504 
38	2010-09-21 17:50:16.709483	84.243.247.100	192.168.0.5	RTP	PT=ITU-T G.729, SSRC=0x71CEB393, Seq=28962, Time=4160627664 
39	2010-09-21 17:50:16.722704	84.243.247.100	192.168.0.5	RTP	PT=ITU-T G.729, SSRC=0x71CEB393, Seq=28963, Time=4160627824 
40	2010-09-21 17:50:16.741540	84.243.247.100	192.168.0.5	RTP	PT=ITU-T G.729, SSRC=0x71CEB393, Seq=28964, Time=4160627984 
41	2010-09-21 17:50:16.762808	84.243.247.100	192.168.0.5	RTP	PT=ITU-T G.729, SSRC=0x71CEB393, Seq=28965, Time=4160628144 
42	2010-09-21 17:50:16.782710	84.243.247.100	192.168.0.5	RTP	PT=ITU-T G.729, SSRC=0x71CEB393, Seq=28966, Time=4160628304 
43	2010-09-21 17:50:16.802913	84.243.247.100	192.168.0.5	RTP	PT=ITU-T G.729, SSRC=0x71CEB393, Seq=28967, Time=4160628464 
44	2010-09-21 17:50:23.095153	84.243.247.100	192.168.0.5	SIP	Request: OPTIONS sip:xxxxx@xxxxxxxxxx.org;rinstance=850654
45	2010-09-21 17:50:42.194152	84.243.247.100	192.168.0.5	SIP	Request: OPTIONS sip:xxxxx@xxxxxxxxxx.org;rinstance=801865
All those RTP packets used the same UDP ports: User Datagram Protocol, Src Port: 22612 (22612), Dst Port: 21768 (21768) and nothing on my server is listening to those ports.

Any ideas on what this type of traffic is about? Is this a piece of the audio stream just prior to the moment when then the two end RTP sockets are connected?
Last edited by Nebukadnezar on Thu Sep 30, 2010 5:23 pm, edited 1 time in total.

Aaron
Site Admin
Posts: 4652
Joined: Thu Jul 12, 2007 12:13 am

Re: RTP traffic from VOIP provider?

Post by Aaron » Tue Sep 21, 2010 10:38 pm

What you're seeing there is very typical and along with one-way audio issues is caused by the lack of any NAT handling capability within SIP. Your SIP client is placing a port number in its call request and sending it to your provider. Your provider will correctly attempt to forward RTP to that port. However the NAT in your router has either not seen a packet come from the inside of your network to your provider or has translated the port to a different one. What most providers are set up to do is to switch the socket they send RTP to once they receive an RTP packet from the client. It's a pretty cludgy situation really and again is a result of a sever lack of foresight in the original SIP designers.

Take a look at http://sipsorcery.wordpress.com/2009/08 ... -problems/ and in particular the diagram titled "NAT Mangling - Broken by PAT".

Nebukadnezar
Posts: 47
Joined: Tue Aug 10, 2010 1:46 pm

Re: RTP traffic from VOIP provider?

Post by Nebukadnezar » Wed Sep 22, 2010 6:13 am

Thanks for your explanation and I read your article (great stuff!), but the problem is that the trace shown is for a successfully placed call (no one-way audio problems). Could this simply be a result of using too old hardware? The server runs on an old P4 PC (1.6GHz, 512MB ram, IDE/PATA UDMA-4 disks) and the Thomson ST780 router in not a very recent model. It is running quite well apart from these RTP bursts. It would appear that the calls are set-up properly but the system is too slow to reply with the RTP socket to the provider and that they in turn default to the current connection? As soon as the two parties are connected, the RTP traffic disappears from my router logs. In the trace posted above, the RTP traffic disappears after a delay of .238437 seconds (length of the RTP traffic).

Before opening my firewall for this traffic my router log would show:

Code: Select all

Sep 18 11:05:20 127.0.0.1 time="2010-09-18 11:05:20" msg="VOIP: Recv 100 Trying"
Sep 18 11:05:23 127.0.0.1 time="2010-09-18 11:05:23" msg="FIREWALL rule (1 of 1719) : Protocol: UDP  Src ip: 84.243.247.100 Src port: 57752 Dst ip: 192.168.0.5 Dst port: 40376 Default Rule Action: drop"
Sep 18 11:05:23 127.0.0.1 time="2010-09-18 11:05:23" msg="VOIP: Recv 183 Session Progress"
In the above sample my firewall (IDS) would flag this as a "UDP flood" (1719 "unsolicited" UDP packets). (in a time frame of less than 3 seconds)

To prevent having to cope with too many NAT problems, the (few) clients connected to my server are using the same SIP client (ST780) and I try to keep it that way with the new clients (mostly family); for that purpose I bought a bunch of those Thomson routers (average $12 a piece).
Last edited by Nebukadnezar on Wed Sep 22, 2010 6:47 am, edited 2 times in total.

Aaron
Site Admin
Posts: 4652
Joined: Thu Jul 12, 2007 12:13 am

Re: RTP traffic from VOIP provider?

Post by Aaron » Wed Sep 22, 2010 6:45 am

The RTP packets bouncing off your firewall are the ones that come from your provider BEFORE it has recieved an RTP packet from your end. As soon as the provider gets an RTP packet from your end it switches the destination it sends the RTP to to the socket it is receiving from.

Nebukadnezar
Posts: 47
Joined: Tue Aug 10, 2010 1:46 pm

Re: RTP traffic from VOIP provider?

Post by Nebukadnezar » Wed Sep 22, 2010 6:48 am

Thanks! That would explain it. So I guess I will have to upgrade my server to a more recent model. I was planning to install the server on new hardware anyhow (current one is purely for testing purposes) but should Asterisk not wait sending out those RTP packets until it receives the appropriate end-socket?

Aaron
Site Admin
Posts: 4652
Joined: Thu Jul 12, 2007 12:13 am

Re: RTP traffic from VOIP provider?

Post by Aaron » Wed Sep 22, 2010 8:41 am

Which server are you going to upgrade? There only thing you could really do to alleviate this issue is put something like a FreeBSD box in as your router and take control over your NAT. It's a pretty small problem really at worst you may miss 1 or 2 seconds of audio at the start of your calls but generally it's more like 100 or 200ms. The majority of people using VoIP have exactly the same thing happening on their own networks and most wouldn't even be aware of it.

Asterisk, or any other SIP server, is doing what it should. It gets a socket in the SIP INVITE request to send RTP to and obediently does so. It cannot know that the NAT at the remote end is going to do a port swtich on it. It's actually going over and above the call of duty by switching it's RTP mid-stream to a different socket when it changes to sending to the socket it's receiving from rather than the socket it was asked to send to. There is nothing in the SIP standards which specifies this type of behaviour it's just evolved as a practical way to get SIP working with NAT. The people working on the SIP standards will politely cough and change the subject whenever NAT comes up.

Nebukadnezar
Posts: 47
Joined: Tue Aug 10, 2010 1:46 pm

Re: RTP traffic from VOIP provider?

Post by Nebukadnezar » Wed Sep 22, 2010 9:53 am

One or two seconds of missed audio at the beginning of a conversation is certainly not the problem. The reason I’m making a problem of it is that I’m still learning how this all operates and interacts and the fact that my (poor man’s) router has actually crashed 5 times one a single day under the load of thousands of RDP packets it did not understand and could not handle (firewall alerts).

Log fragment while two clients are setting up conversations:

Code: Select all

msg=""FIREWALL rule (1 of 1719) : Protocol: UDP  Src ip: 84.243.247.100 Src port: 57752 Dst ip: 192.168.0.5 Dst port: 40376 Default Rule Action: drop"""
msg=""FIREWALL rule (1 of 793) : Protocol: UDP  Src ip: 84.243.247.100 Src port: 39540 Dst ip: 192.168.0.5 Dst port: 40974 Default Rule Action: drop"""
msg=""FIREWALL rule (1 of 1567) : Protocol: UDP  Src ip: 84.243.247.100 Src port: 44504 Dst ip: 192.168.0.5 Dst port: 23904 Default Rule Action: drop"""
msg=""FIREWALL rule (1 of 558) : Protocol: UDP  Src ip: 84.243.247.100 Src port: 37496 Dst ip: 192.168.0.5 Dst port: 48792 Default Rule Action: drop"""
msg=""FIREWALL rule (1 of 1) : Protocol: UDP  Src ip: 84.243.247.100 Src port: 47904 Dst ip: 192.168.0.5 Dst port: 7566 Default Rule Action: drop"""
msg=""FIREWALL rule (1 of 1) : Protocol: UDP  Src ip: 84.243.247.100 Src port: 11894 Dst ip: 192.168.0.5 Dst port: 2272 Default Rule Action: drop"""
msg=""FIREWALL rule (1 of 1669) : Protocol: UDP  Src ip: 84.243.247.100 Src port: 33812 Dst ip: 192.168.0.5 Dst port: 41240 Default Rule Action: drop"""
msg=""FIREWALL rule (1 of 1330) : Protocol: UDP  Src ip: 84.243.247.100 Src port: 28514 Dst ip: 192.168.0.5 Dst port: 48932 Default Rule Action: drop"""
msg=""FIREWALL rule (1 of 1398) : Protocol: UDP  Src ip: 84.243.247.100 Src port: 46210 Dst ip: 192.168.0.5 Dst port: 4150 Default Rule Action: drop"""
msg=""FIREWALL rule (1 of 497) : Protocol: UDP  Src ip: 84.243.247.100 Src port: 12528 Dst ip: 192.168.0.5 Dst port: 44316 Default Rule Action: drop"""
msg=""FIREWALL rule (1 of 1201) : Protocol: UDP  Src ip: 84.243.247.100 Src port: 49076 Dst ip: 192.168.0.5 Dst port: 9824 Default Rule Action: drop"""

Total RTP packets dropped: 9543
That was the day I started to investigate my routers logs and noticed those RTP packets. Now I have learned (from you mostly, and by reading a lot on the Asterisk forums) that Asterisk indeed starts transmitting RTP as soon as it sends it’s ‘200 OK’ and before Sipsorcery sends it’s ‘ACK’. As long as my router does not keep crashing, I would consider this issue as solved. However, it does crash.

I thought upgrading the hardware of the server would reduce the gaps in SIP signaling speed and thus reducing the amount of zombie RTP packets, and perhaps that will make some difference, but I will get my hands on a fast working OpenWRrt router as soon as possible, and hopefully both changes will result in a stable server environment.

I will post the result here (will take some time).

Thanks again.

Post Reply