48 Replies Latest reply: Dec 12, 2013 12:56 AM by carlh RSS

RE: Ports, Routers and Traffic

whyfye? 2 Bar

In regards to this post: https://community.republicwireless.com/blogs/theproductguy/2011/12/19/ports-routers-and-traffic

 

Can you clarify what protocols are being used for the ports mentioned? I assume the following:

 

TCP for 5090

UDP for 16384 through 16402 based on Using FaceTime and iMessage behind a firewall

 

Thanks.

  • Re: RE: Ports, Routers and Traffic
    2 Bar

    Based on the packet captures from phone.

     

    Inbound to phone

    SIP

    UDP/5090

     

    RTP

    UDP/16384 - 16402

     

    Outbound from phone ( If you are running a "normal" home router then you shouldn't need to do anything with these ports. Home routers generally let any inside host connect to the internet on any port. )

     

    SIP

    UDP/5090

    .

    RTP

    UDP >16384

     

    I know this is many more than the article indicates but this was my observed traffic flows using wireshark.

    • Re: RE: Ports, Routers and Traffic
      jsmith 2 Bar

      Since the outbound RTP ports seems to change (as observed using Tomato Firmware), and are "UDP>16384" as janus_god noted...  how can one prioritize these packets?

       

      I've used Tomato's QOS to get the audio delay at home to a minimum, but this is the last step I could use some help with.

       

      Thanks

      • Re: RE: Ports, Routers and Traffic
        whyfye? 2 Bar

        I'm not sure about Tomato, but DD-WRT allows you to create a new service and enter a port range and prioritize based on that.

        • Re: RE: Ports, Routers and Traffic
          jsmith 2 Bar

          Thanks whyfye?

          I've done that already for the static ports (UDP/5090&5060,UDP/16384 - 16402), but not sure what do do about the changing ones ("UDP>16384").

          • Re: RE: Ports, Routers and Traffic
            2 Bar

            >16384 is really the same as 16384 - 65535 since the port header field is only 16 bits. I am still reviewing my network captures. You may find it easier to assign QoS by L2 or L3 information like the MAC address or IP address of your phone. If you choose the IP address of your phone you will need to make a DHCP reservation so the phone always receives the same IP Address each time it asks for an address.

            • Re: RE: Ports, Routers and Traffic
              jsmith 2 Bar

                   Thanks janus_god!  Exactly the direction I was looking for help!  I added the MAC address specific 16384 - 65535... thanks for the L2/L3 suggestion.  I do have a DHCP reservation for the phone, but went with the MAC in case I change my IP preference.

                   Can you keep watching the captures and share what you find?  I'll try using Wireshark too and see what I get.  So far I've noticed these in use as well:  5228,16042,9766,19294.  Your thoughts?

        • Re: RE: Ports, Routers and Traffic
          billmeek Ambassador

          Not needed on my router running DD-WRT.  Works fine without the QOS setup.

      • Re: RE: Ports, Routers and Traffic
        mwgardiner Ambassador

        More practical solution, create a class of VoIP, move it to the top of the priority stack, and assign the MAC of the phone to that class.  This will give all traffic from the phone the highest priority, which saves you hunting port ranges.  Other than phone calls, the phone generates so little outbound traffic that the increased priority should not be an issue on non-VoIP data.  This also gives any third-party VoIP apps you may install the same priority without hunting for ports.

        • Re: RE: Ports, Routers and Traffic
          nipstech 1 Bar

          I noticed something that I can't nail down. A long time ago I built a firewall using pfSense and was able to get my DefyXT to use WiFi to make calls. Last week I downloaded and installed Sophos UTM. Now, even though I can connect to my WiFi network with the DefyXT, it can no longer use WiFi to make calls. I'm quite familiar with the pfSense product, but the Sophus produce is a completely different animal. Has any of you successfully used the Sophus UTM firewall with RW?

           

          Thanks, Jon

          • Re: RE: Ports, Routers and Traffic
            mwgardiner Ambassador

            Not using any sort of firewall other than the intrinsic protection that NAT offers, which admittedly isn't that much, I couldn't really offer anything useful.  For what it is worth, I am currently using a Cisco/LinkSys WRT54GL running Tomato firmware.  I simply define the MAC of my phone to have the highest outbound priority without further tinkering. This gives me good results. If you are trying anything more sophisticated that is probably what is giving you trouble, trying to block anything outbound from the phone likely trips up the process by blocking a needed port.

      • Re: RE: Ports, Routers and Traffic
        karadi 2 Bar

        What is tomato firmware ?

    • Re: RE: Ports, Routers and Traffic
      1 Bar

      This is the first mention I've seen of outbound firewall rules, but it turned out to be what I needed for my Endian firewall (which is basically a web front-end for iptables).

       

      I had the same problem, where the call would drop in the first 2 seconds. I allowed outbound 16384-65535, and it starting working more often, but I still experienced some drops. I then allowed 1-65535 and haven't had a drop since.

  • Re: RE: Ports, Routers and Traffic
    2 Bar

    After reviewing more packet captures this evening I have found that RTP traffic does not seem limited to the ports specified in the republic wireless article for outbound phone calls.

     

    The blog post states UDP 16384 - 16402 should be RTP traffic. But I have seen conversations using UDP16822 and UDP 17148. This is for outgoing calls only. I have to test incoming calls tomorrow to see if there are any changes.

    • Re: RE: Ports, Routers and Traffic
      daler 2 Bar

      I placed a test call from an att landline to RW number while connected via wifi.

      I looked at my router log and found the following:

       

      1. udp to 50.23.200.18:5090 
      2. udp to 50.23.200.19:13268  -- used for a short time
      3. udp to 67.231.0.102:27522  -- used until end of call (same 'local' port #2. this is what I would expect)

       

      If I am interpreting this correctly, it looks like #1 is SIP call invite and probably re-invite on same address/port. #2 is first RTP stream which is 'handed off' to #3, the 2nd RTP stream.

       

      Ports used in #2 and #3 are outside the range specified by RW. What is the actual range of ports?.

       

      ps. addresses and ports were copied and pasted to avoid typo's.

      • Re: RE: Ports, Routers and Traffic
        2 Bar

        Flow 2 is the initial RTP flow that is setup, and flow 3 is the re-invite to media gateway that republic owns. Sean has stated that flow 3 is going to a much larger scale VoIP deployment so it can handle more calls than the server in flow 2 can.

         

        Another problem I have had but I am still working on if it is a NAT problem or something else but my flow 3 connection does not work because it appears that republic wireless server does not use exact same source/dest port that my phone used. This causes my NAT device to drop the packets since it doesn't match an existing flow.

        • Re: RE: Ports, Routers and Traffic
          daler 2 Bar

          janus_god wrote:

           

          Flow 2 is the initial RTP flow that is setup, and flow 3 is the re-invite to media gateway that republic owns. Sean has stated that flow 3 is going to a much larger scale VoIP deployment so it can handle more calls than the server in flow 2 can.

           

          Another problem I have had but I am still working on if it is a NAT problem or something else but my flow 3 connection does not work because it appears that republic wireless server does not use exact same source/dest port that my phone used. This causes my NAT device to drop the packets since it doesn't match an existing flow.

           

          I would not expect RW's servers to use the same ports as my phone. I don't think I understand your observation about flow 3.

           

          Relative to blocking flow 3:

          1. NAT - would block if did not have a mapping to a local port from the foreign port, e.g., no nat entry. The number entries will depend on the type of NAT/firewall -- Full cone, restricted cone, symmetric.
          2. Firewall
            1. without an application layer/level program/gateway (ALG) - firewall needs to implement a full cone UDP. Sometimes called address and port independent.
            2. with an an application layer/level program/gateway - the ALG needs to properly inspect the payloads of SIP packets and instruct the firewall to expect traffic from new address and/or port and add NAT entries as needed.

           

          I am not sure where RW's issues are, But a Full Cone (UDP only) Firewall/NAT function should work.

           

          I have searched for a server on the web that would do a test and determine type of NAT (full cone, restricted cone, symmetric) but have been unable to find a working NAT tester publicly available. If you know of one please post.

  • Re: RE: Ports, Routers and Traffic
    2 Bar

    I am headed back home to RTP area after some Juniper training this week. I think I will have some time tomorrow to sit down get observe some real traffic and try to define the possible flows. I still see the new media gateway flow being broken because the media gateway uses src port 1024 rather than the previous flow source ports.

  • Re: RE: Ports, Routers and Traffic
    m 1 Bar

    I noticed the RTP ports were well out of the range specified by rw and posted about it months ago when the old forum was being used.  republic responded to me that they would look into it, but I never heard anything about it from them since then.

     

    I believe my old posts have been buried with the old forum, so I'll try and summarize what I did to come as close as possible to prioritizing only VOIP traffic.

     

    First, the advantage of prioritizing by tcp/udp port over other methods such as MAC or IP.

    1.  You don't have to setup MAC/IP rules every time a guest shows up or have them not be prioritized at all.

    2.  MAC/IP rules prioritize all the traffic for those devices, and not just the VOIP traffic.  This can cause QOS issues, especially if you have more than one VOIP smartphone.

     

    Initially, I used a SIP tool in my UTM to prioritize the VOIP traffic regardless of the random port it decided to use, but I'd consistently loose audio after about 8 minutes due to an issue with the number of SIP connections the republic traffic initiated.  SIP calls initiated a new connection every minute which resulted in a connections exceeded error.  According to the UTM vendor, republic does not follow strict SIP standards and uses something like a 3CX approach, thereby resulting in the dropped audio issues.  So even though the SIP tool did an excellent job of prioritizing just the SIP traffic, I couldn't use it with republic.

     

    The current solution for me:

    I prioritize all ports (with some exceptions) between 2000 and 65535 for tcp and udp.  Almost nothing uses ports in that range and the few ports in that range which I specifically use for other things, I have specific QOS rules for.  It's not perfect, but it is as close as I can get.  Having said that, I would still prefer that republic just pick a sequential range of ports and tell us what they are.

  • Re: RE: Ports, Routers and Traffic
    keltic 2 Bar

    RW, could you publish a list of recommended ports for QOS, based on the ports you already know that are used, instead of making us guess, test and reverse engineer the service?

  • Re: RE: Ports, Routers and Traffic
    2 Bar

    Till we get the much desired official settings, here is what works for me on just about any router

     

    Disable ALG SIP (this would be great to have, except that it almost never works correctly for RW)

    Enable WMM (if you have the option)

    Disable Dynamic Fragmentation in QoS

    Set QoS and Application Rules and WISH with:

      Port 5090 open for both TCP and UDP and all ip address(QoS) (This seems to be Republic Specific)

      Ports 5060 - 5080 open for both TCP and UDP and all ip address(QoS) (helps with any SIP / VoIP setup)

      Ports 10000 - 65535 open for All traffic (the RTP audio is somewhere in here) (helps with any SIP / VoIP setup)

     

    Good Luck

    ps  enabling UPnP And Multicast Streaming will usually be good for any router

  • Re: RE: Ports, Routers and Traffic
    2 Bar

    republic tends to use ports outside of the facetime range, that is why i suggest opening ports 5090, 5060 - 5080, 10000 - 65535   until Republic officially tells us their port range.

    TCP / UDP - different ways of communicating over the ports

    Sip - Session Initiation Protocol  -  standard voice over ip protocol    can use TCP or UDP

    Other settings are options in higher end home routers to improve your wifi by giving priority to SIP voice traffic and your phone  over other internet connections  (so netflix doesn't make you phone call sound crappy)

  • Re: RE: Ports, Routers and Traffic
    2 Bar

    High end home routers

    * Disable ALG SIP (this would be great to have, except that it almost never works correctly for RW)

          (Application Level Gateway - SIP =  a automatic SIP setup system that rarely works correctly)

    * Set QoS and Application Rules and WISH with:   (WISH - other wireless service quality settings)

    *  Port 5090 open for both TCP and UDP and all ip address    (This seems to be Republic Specific)

    *  Ports 5060 - 5080 open for both TCP and UDP and all ip address (helps with any SIP / VoIP setup)

      * Ports 10000 - 65535 open for All traffic (the RTP audio is somewhere in here) (helps with any SIP / VoIP setup)   (RTP - Real Time Protocol  what handles the audio inside SIP protocol)

  • Re: RE: Ports, Routers and Traffic
    2 Bar

    If your buying a new router, get this one - will be worth it in a few years (supports WIFI AC - standardized cellular to wifi and wifi to cellular handoff)

    Asus RT-AC66U 802.11ac Dual-Band Wireless-AC1750 Gigabit Router

  • Re: RE: Ports, Routers and Traffic
    2 Bar

    Asus RT-AC66U 802.11ac router review: Latest firmware makes it a beast

    Asus RT-AC66U 802.11ac Dual-Band Wireless-AC1750 Gigabit Router Review - Routers - CNET Reviews

    Editors' note: This review was updated on October 30 with the router's rating adjusted to reflect its improvement thanks to a new major firmware update.

  • Re: RE: Ports, Routers and Traffic
    cufflink Ambassador

    I'm going to bump this thread... I have several employees that use RW phones here at our office and I'm trying to prioritize their traffic. Setting ports 10000 - 65535 as "High Priority" just isn't a viable option. Can someone from RW provide us with the actual port ranges?

  • Re: RE: Ports, Routers and Traffic
    sp386 2 Bar

    Bumping this thread as its a hot issue for those on secured, public networks. If anyone finds a corresponding thread or information in this matter, please reply here and make a post.

     

    As  cufflink stated:

    "Setting ports 10000 - 65535 as "High Priority" just isn't a viable option. Can someone from RW provide us with the actual port ranges?"

    • Re: RE: Ports, Routers and Traffic
      carlh 5 Bar

      While you wait for an official Republic response (I'm not holding my breath), the unofficial investigative report is here:

      WiFi behind a firewall

       

      I don't know that anyone has done a full-fledged analysis of the Moto X to see if it maintains those ports however.

       

      FWIW, most of us don't set high-priority QOS based on ports, we set it based on the MAC address of the phone.

      • Re: RE: Ports, Routers and Traffic
        jben Ambassador

        Am trying to get caught up on a couple things and my Moto X was 'under the weather' for 6 days.  Should be able to take some Wireshark traces to compare to those that I took on the Defy. On the one trace I have 5090 is the same and I saw data exchanges between my device and RW on 9050 and 50940

        I will try a 1/2 dozen calls and see it it's any different that before (they are a different IP address that seen on the Defy)