1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

QoS and Layer7 RTP doesn't work?

Discussion in 'Tomato Firmware' started by az2008, Dec 12, 2008.

  1. az2008

    az2008 Addicted to LI Member

    I use a VOIP service (MagicJack). It keeps opens a SIP connection to their server. And, when a call occurs, it opens an RTP connection to another of their servers.

    I've been able to use Tomato's QoS by specifying the "to" IP address of those servers. (Also by specifying the dest port ranges.). I've verified that these rules take effect by placing a call, viewing the QoS "graphs," and seeing both connections in the "Highest" slice of the graph.

    But, when I change the QoS rule for the RTP connection to use Layer7->RTP, it never falls into the "Highest" slice of the graph.

    This rule is at the top of the list. I've tried a few permutations of UDP and L7->RTP. Port range and L7->RTP. And, just L7->RTP. It's the same result. It falls into another rule for "Lowest.".

    I've used WireShark to trace the activity of a call. It displays that connection as RTP protocol.

    Has anyone successfully used L7->RTP? I can provide the WireShark trace if it would help someone debug it.

  2. teddy_bear

    teddy_bear Network Guru Member

    I also had no success using l7-filter for RTP - it never prioritized RTP packets properly. Well, take a look at the comments in rtp.pat file on the official l7 site. Here's a quote:
    # RTP headers are *very* short and compact. They have almost nothing in 
    # them that can be matched by l7-filter.  If you want to match them 
    # along with their associated SIP packets, I think the best way might be 
    # to set up some iptables rules that watch for SIP packets and then also 
    # match any other UDP packets that are going between the same two IP 
    # addresses.
    # However, I will attempt a pattern anyway.  This is UNTESTED!
    The protocol filter also marked there as "marginal - might work, might not".

    So I'm back to using port ranges - works much better...
  3. az2008

    az2008 Addicted to LI Member

    Thanks. I'm glad to know it's not just me.

    The comments indicated it expected SIP and RTP to be on the same connection, or to the same server. Maybe that's the problem with MagicJack. SIP is on one connection (to one server). When a call occurs, a second connection (for RTP) is opened to a different server.

    What's strange is that a WireShark trace correctly identifies that second connection as RTP. If it can identify it, it seems like L7 could too.

    I don't like using the port range because MagicJack uses destination ports 10000-20000 for the RTP connection. A rule that broad is bound to give Highest priority to something else.

    I've used the Destination IP address of the RTP server. But, that makes me nervous that the IP address will change someday. I'm probably ok with remembering that I have this dependency in my QoS. But, when I recommend Tomato to MagicJack users, I'm worried that they won't understand (or remember) the significance of this dependency. Their service will deteriorate some day and then they'll spend hours with tech support, etc. over something hard-coded in Tomato.

    I was reminded that a rule can contain an IP address range. But, that starts to get broad again. I don't know the IP address range which MagicJack uses. And, they have two dozen regional servers which begin with 3-4 different high-level octets. It's conceivable that they could route people in one region to another region during an outage. Then it would require multiple rules for different ranges (which hopefully never change).

  4. az2008

    az2008 Addicted to LI Member

    FYI. I joined the L7 mailing list and asked that question. Also posted a Wireshark capture of the RTP traffic.

    I'll update this thread if I learn anything.

  5. az2008

    az2008 Addicted to LI Member

    The L7 maintainer (and Jon) was very helpful. He provided a filter which I gave to Jon. Jon added it to a test release of 1.23. I tested it and it worked perfectly.

    I'm waiting to hear how the L7 maintainer wants to handle it. It sounds like RTP is vague. There might be a risk that this new filter could misidentify things. Or, be too strict and break applications using the existing filter. I don't know if he'll have two RTP filters, or make this the RTP filter.

    Either way, it sounds like a future version of Tomato will have an L7->rtp that works with Magicjack. I'm excited about that because, as the economy goes sour, more (average) people are buying MJ to save money. It will be good to be able to recommend Tomato to them without the problems associated with QoS classifications using hard-coded IP addresses. When that happens I'll create a demonstration video showing how to flash a router, and create the QoS rule. I'll be sure to point out how people can donate a few dollars to Tomato.

  6. teddy_bear

    teddy_bear Network Guru Member

    Wow! So much happened in one day - l7 filter for RTP got updated (well, not officially yet), and tomato test build 1.23 already includes it :)... Could you post here, or PM me a new pattern? Or it's still a secret, and I'd better wait, or ask l7 maintainer for it?

    If RTP filter will work now, that would be great - and not only for MagicJack but any VoIP service! I hope they will release the update soon. The other firmwares - OpenWRT, dd-wrt etc - will benefit from it as well. Unfortunately, I'm not using Tomato - mostly because of no USB support. Do you know by any chance if Jon plans to add USB support in 1.23?
  7. az2008

    az2008 Addicted to LI Member

    The RTP pattern is:

    This may be subject to change. I haven't heard from the l7 maintainer yet.

    I don't know. That might be a good topic for a new thread. Maybe some of the people who create Tomato derivatives would know how feasible that would be.

    Also, I don't know the significance of the 1.23 build I was given to test. I know there are recent 1.22 test builds on the web site (recent because they contain TCP Vegas). Maybe between then and now Jon decided the next release would be 1.23 instead of a bump in the minor (.7) number?

    Finally, I was told that when using a L7 filter, it can be useful to qualify the classification with other information, like protocol, port, etc. Those items are checked first before the packet is inspected. It could improve performance by avoiding inspection of all packets.

    For example, for MagicJack I have two classifications right now.

    That last one is pretty broad. But, it could be slightly better than every packet being inspected. Such as HTTP traffic using TCP on port 80. Or DNS traffic, etc.

  8. az2008

    az2008 Addicted to LI Member

    The final 1.23 version was released.[1] It has the "rtp-test" (now named "rtp-2") protocol in the QoS->Classifications->Layer 7. That's the one which will work with MagicJack. Presumably this filter will be included in the L7 library, and this one which Jon added will be removed.

    I'm glad this made it in at the last minute. I didn't realize yesterday that it was the last minute. :) We got lucky.

    [1] http://www.polarcloud.com/tomato
  9. az2008

    az2008 Addicted to LI Member

    To teddy_bear

    "teddy_bear," I sent you a PM. But, I don't know how easy it is to notice you have a new PM.

    So, I'll hopefully get your attention here.

    The L7 maintainer said he would replace the existing "rtp" filter with the new one (which is "rtp-2" in Tomato 1.23).

    However, a few minutes later he said the filter contained a couple errors, and provided a new filter.

    I'm not capable of testing this because Tomato keeps the filters in ROM. And, I hate to bother Jon with requests for custom builds just to test filters.

    Then I remembered you created your own mod. And, I got the impression that you use MagicJack(?).

    I was wondering if you would be willing to test his new filter when you have time?

    The first, updated filter (now in "rtp-2") is:

    His suggested, corrected filter is:

    Let me know if my assumption about you being a MJ user is correct, and if you'd give it a try sometime. There's no hurry.

    Otherwise, I have to bother Jon to make me a custom 1.23 to test this. Or, I have to buy him (or someone else who deals in mods) a MagicJack unit. :)

  10. teddy_bear

    teddy_bear Network Guru Member

    I've got your PM too - just did not reply yet :)...
    I do use MJ, as well as other VoIP services. Sure, I'll try to test a new pattern as soon as I can.

    And I believe there's no need to make a new firmware build for testing, so you can test it as well. You only need to copy the new pattern file into /tmp (RAM), and mount it to the existing rtp-2.pat file in ROM:
    mount -o bind /tmp/rtp-2.par /usr/l7-filter/rtp-2.pat
    (I don't remember the exact path to the l7 pattern files in ROM though - you'll need to look there to find out).
    Restart QOS (/etc/qos stop && /etc/qus/start), and the new pattern should take effect.
  11. az2008

    az2008 Addicted to LI Member

    That's excellent! I spent the last hour or so playing with it. The new filter seems to work. However, you may want to test it yourself. I'm not sure I know what I'm doing.

    First, I named the file "rtp.pat" because I wanted to make sure I was replacing a pattern that shouldn't work. I was worried that if I overlayed "rtp-2," I wouldn't know for sure if the router was really using my /tmp copy or the other one in ROM.

    So, I'm doing this:

    # Create the file
    echo rtp > /tmp/rtp.pat
    echo '^\x80[\x01-"`-\x7f\x80-\xa2\xe0-\xff]?..........*\x80' >> /tmp/rtp.pat
    # See original ROM value
    cat /tmp/etc/l7-protocols/rtp.pat
    # Overlay the original ROM value
    mount -o bind /tmp/rtp.pat /etc/l7-protocols/rtp.pat
    # See new, replaced/overlayed value (not really in ROM)
    cat /tmp/etc/l7-protocols/rtp.pat
    However, the command-line stop/start commands didn't seem to do enough to force the router to pick up this change. When I started MJ and placed a call, the RTP (vms1 host) connection went to a low category.

    I had to either:

    - Go into QoS->Classification, change my L7 choice to a different value, save. Then, change it back to "rtp," save again.


    - Go into QoS->Basic Settings, disable QoS, save. Then, enable QoS again, save.

    Either of those caused it to refresh something a little more than the command-line start/stop. That's when the RTP (vms1 host) connection began to be marked as "Highest."

    I also found that exiting MJ before these adjustments (and starting it after) made it easier to see what was happening. When I left it connected through all the adjustments, I saw some strange stuff. Like, it was connecting to a different regional proxy. I've never seen it do that before.

    Anyway, I hope you'll try it yourself and confirm the newest filter works. Make sure I did this right.

  12. teddy_bear

    teddy_bear Network Guru Member

    Looking at your script you do know exactly what you're doing :)... Anyway, I tested it too tonight, and it worked very well on a few MJ calls, and several other VoIP calls made via different SIP providers using Asterisk. In all cases RTP connections were properly prioritized, and no wrong connections made it to the Highest priority.

    But I did not have any issues with the previuos pattern either. Probably it's some specific traffic that messes it up. What did Matthew say the problem was - was it the under- or overmatch?
    Yep. Sorry, I was typing from memory and just guessed that it may work... Looking at it now, it does not include the part marking the traffic, and the script is getting recreated every time you change the QoS settings. So you're right - you need to disable/re-enable QoS from GUI to actually restart it.
    I think what's hapenning is restarting QoS terminates or disables connections for a short period of time. MJ could not connect to the default proxy, so it keeps trying other proxies until connection is established. That's a nice thing for MJ to do in case some proxies are down :)...
  13. az2008

    az2008 Addicted to LI Member

    I don't know. These filters looks like Martian Morse Code to me. It scares me. I try not to ask too many questions. :wink:

  14. esaym

    esaym LI Guru Member

    There is really nothing wrong with putting the icmp and udp protocols in the highest class. Then not only will voip be fine, but most online games will play smoothly too. Thats the way I have been doing it for about 6 years now:)

Share This Page