Re: [MT-AU Public] SIP Identification issue in mangle and queues
Hey Paul, How are you talking to MyNetPhone? Do you have dedicated cross connects to them, or are you just talking over the internet? If it's over the internet, its the general consensus is that DSCP gets remarked to 0 through all providers - so it'd only be used within your network toward the upstream and down to your customer. Probably also why you won't see any markings from MyNetPhone inbound on your transit links. If you're just trying to QOS your last mile circuits so large downloads etc don't break SIP - can you move that to customer access device? Not sure what phones you are using but Polycom/Cisco/Yealink can all mark their RTP / Signal traffic with different markings. You could match these markings from your customer on your LNS and add those addresses to an address list with a ~15 minute timeout. You could then match that address list on your inbound interfaces from the internet and remark internally before routing to your customer site over last mile access. Obviously that'd mark everything for those IPs down to the customer and not just RTP - however if the provider only uses them for RTP, I don't really see the issue. Regards, Nick (p.s. Sorry for signature in advanced - it's enforced outbound on our MTA, just subbed personal email to this list so next reply won't have it - I promise) --- original message --- On Wed, Jul 25, 2018 at 04:53 pm, <paul@buildingconnect.com.au> Paul Julian wrote: Well I found the problem I think, I am still working out how to get around it though. It seems that mynetfone use different servers for their signalling and RTP, which means if you use the sip service type in Mikrotik, or port 5060/5061 to mark your packets then you will miss the RTP traffic which is really what you need to get. Somehow I need to mark packets that are related to the SIP connection, not just the SIP connection itself. I will have to have a think about this one..... Regards Paul -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Philip Loenneker Sent: Wednesday, 25 July 2018 2:41 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] SIP Identification issue in mangle and queues Fair call :) Are your mangle rules not matching, or only the queue not matching? -----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Julian Sent: Wednesday, 25 July 2018 2:18 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] SIP Identification issue in mangle and queues Hi Philip, Quite honestly we wouldn't trust any provider with DSCP values, they just don't get it, we mark everything based on connection type and/or ports and also pickup SIP servers dynamically based on those other criteria. The problem comes when we mark the packets they seem to get marked but the way we see them treated in queues is strange, they seem to have a bursty nature rather than having a consistent 80kbit/s sort of situation. There is something strange going on but it is only affecting this one customer who uses mynetfone, so I am trying to think outside the box and wondering what on earth could be happening to cause this. Regards Paul -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Philip Loenneker Sent: Wednesday, 25 July 2018 2:14 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] SIP Identification issue in mangle and queues Hi Paul, We have noticed that MyNetFone do NOT mark their packets with DSCP values, even if the handsets/softphones at the customer end do. You can see this clearly in torch and packet captures. We have asked them about it in the past, and didn't manage to get them to understand what DSCP was and why it was important. You may have more luck if you reach out to them, as it's been a while since we tried. If you do have some luck, please let me know so I can check our customers again :) Regards, Philip Loenneker | Network Engineer | TasmaNet 40-50 Innovation Drive, Dowsing Point, Tas 7010, Australia P: 1300 792 711 philip.loenneker@tasmanet.com.au www.tasmanet.com.au -----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Julian Sent: Wednesday, 25 July 2018 1:33 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: [MT-AU Public] SIP Identification issue in mangle and queues Hi All, Just wondering if anybody has seen this anomaly before. We use Mikrotik routers as LNS’s in many locations, we prioritise VOIP traffic outbound to our customers and it works very well. We do this using a mix of mangle rules and reconstruct the customer facing queues during login, this also works very well and allows us to prioritise any voice provider not just ourselves. Just recently we had a customer advise that they were having voice issues and were wondering if they needed to increase their capacity, upon looking at their usage history we could see that they were spiking a bit but also noticed that their VOIP queue was not matching any packets. Other customers were matching just fine with the same rules in place, however we totally went through everything and couldn’t find any issues. As a precaution we upgraded the ROS to the latest bugfix version and also upgraded firmware. After that the other customers VOIP queues were still matching just fine so we thought perhaps Mynetfone were doing something a bit weird with the voice traffic to this customer, so we even setup a dedicated queue for this customer with everything needed to match the traffic, but still nothing. It’s a really weird problem, it’s only this one customer, all other customers are working correctly, so I’m not sure whether it’s a mynetfone problem or maybe the customers router, but we only prioritise the outbound traffic TO the customer and across our network but in this case it’s the traffic from mynetfone to the customer which isn’t matching, as such I wouldn’t think that their CPE could impact what we are doing in any way. Any thoughts would be appreciated, I am fast running out of my remaining hair on this one ෞ ഀ吀栀愀渀欀猀ഀ倀愀甀氀 _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au --- end of original message ---
Hi Nick, The mynetfone stuff is just going in/out our transit so yeah I know I won't see anything in general, in fact we scrub any DSCP as it enters our network anyway and do our own QOS, but the part I am referring to is that last mile from our LNS to the CPE, the problem is that we want it to be more dynamic, then it will work for all SIP providers going over our network, this is the first time we have seen this issue though, up until now our system worked flawlessly. You have given me some ideas though, we a generally doing it like you suggest with the address list and mangle rules, but we are doing it based on the sip conversation and/or anything port 5060 for example, the problem is that RTP is random ports and in this case it's a different server to the SIP server so hence we can't match the traffic. I might just see if the customer phones are sending any DSCP value to that IP when they are talking, that could be a way to pick the server up reliably. Thanks Paul -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Nick Pratley | Servers Australia Sent: Wednesday, 25 July 2018 5:12 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] SIP Identification issue in mangle and queues Hey Paul, How are you talking to MyNetPhone? Do you have dedicated cross connects to them, or are you just talking over the internet? If it's over the internet, its the general consensus is that DSCP gets remarked to 0 through all providers - so it'd only be used within your network toward the upstream and down to your customer. Probably also why you won't see any markings from MyNetPhone inbound on your transit links. If you're just trying to QOS your last mile circuits so large downloads etc don't break SIP - can you move that to customer access device? Not sure what phones you are using but Polycom/Cisco/Yealink can all mark their RTP / Signal traffic with different markings. You could match these markings from your customer on your LNS and add those addresses to an address list with a ~15 minute timeout. You could then match that address list on your inbound interfaces from the internet and remark internally before routing to your customer site over last mile access. Obviously that'd mark everything for those IPs down to the customer and not just RTP - however if the provider only uses them for RTP, I don't really see the issue. Regards, Nick (p.s. Sorry for signature in advanced - it's enforced outbound on our MTA, just subbed personal email to this list so next reply won't have it - I promise) --- original message --- On Wed, Jul 25, 2018 at 04:53 pm, <paul@buildingconnect.com.au> Paul Julian wrote: Well I found the problem I think, I am still working out how to get around it though. It seems that mynetfone use different servers for their signalling and RTP, which means if you use the sip service type in Mikrotik, or port 5060/5061 to mark your packets then you will miss the RTP traffic which is really what you need to get. Somehow I need to mark packets that are related to the SIP connection, not just the SIP connection itself. I will have to have a think about this one..... Regards Paul -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Philip Loenneker Sent: Wednesday, 25 July 2018 2:41 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] SIP Identification issue in mangle and queues Fair call :) Are your mangle rules not matching, or only the queue not matching? -----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Julian Sent: Wednesday, 25 July 2018 2:18 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] SIP Identification issue in mangle and queues Hi Philip, Quite honestly we wouldn't trust any provider with DSCP values, they just don't get it, we mark everything based on connection type and/or ports and also pickup SIP servers dynamically based on those other criteria. The problem comes when we mark the packets they seem to get marked but the way we see them treated in queues is strange, they seem to have a bursty nature rather than having a consistent 80kbit/s sort of situation. There is something strange going on but it is only affecting this one customer who uses mynetfone, so I am trying to think outside the box and wondering what on earth could be happening to cause this. Regards Paul -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Philip Loenneker Sent: Wednesday, 25 July 2018 2:14 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] SIP Identification issue in mangle and queues Hi Paul, We have noticed that MyNetFone do NOT mark their packets with DSCP values, even if the handsets/softphones at the customer end do. You can see this clearly in torch and packet captures. We have asked them about it in the past, and didn't manage to get them to understand what DSCP was and why it was important. You may have more luck if you reach out to them, as it's been a while since we tried. If you do have some luck, please let me know so I can check our customers again :) Regards, Philip Loenneker | Network Engineer | TasmaNet 40-50 Innovation Drive, Dowsing Point, Tas 7010, Australia P: 1300 792 711 philip.loenneker@tasmanet.com.au www.tasmanet.com.au -----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Julian Sent: Wednesday, 25 July 2018 1:33 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: [MT-AU Public] SIP Identification issue in mangle and queues Hi All, Just wondering if anybody has seen this anomaly before. We use Mikrotik routers as LNS’s in many locations, we prioritise VOIP traffic outbound to our customers and it works very well. We do this using a mix of mangle rules and reconstruct the customer facing queues during login, this also works very well and allows us to prioritise any voice provider not just ourselves. Just recently we had a customer advise that they were having voice issues and were wondering if they needed to increase their capacity, upon looking at their usage history we could see that they were spiking a bit but also noticed that their VOIP queue was not matching any packets. Other customers were matching just fine with the same rules in place, however we totally went through everything and couldn’t find any issues. As a precaution we upgraded the ROS to the latest bugfix version and also upgraded firmware. After that the other customers VOIP queues were still matching just fine so we thought perhaps Mynetfone were doing something a bit weird with the voice traffic to this customer, so we even setup a dedicated queue for this customer with everything needed to match the traffic, but still nothing. It’s a really weird problem, it’s only this one customer, all other customers are working correctly, so I’m not sure whether it’s a mynetfone problem or maybe the customers router, but we only prioritise the outbound traffic TO the customer and across our network but in this case it’s the traffic from mynetfone to the customer which isn’t matching, as such I wouldn’t think that their CPE could impact what we are doing in any way. Any thoughts would be appreciated, I am fast running out of my remaining hair on this one ෞ ഀ吀栀愀渀欀猀ഀ倀愀甀氀 _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au --- end of original message --- _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
participants (2)
-
Nick Pratley | Servers Australia -
Paul Julian