FPL SIP is not RFC complaint?

[olegmz]

OK. My question is for people who are deep into network stuff and know cisco IOS and FPL implementations of SIP. I apologize in advance for my long and hard-to-read message, but hope someone could help me

So I was trying to setup FPL software client to work through cisco routers and bumped into the following problem.
1) Everything works fine both ways with static access rules for incoming and outgoing traffic, even if no static NAT (port forwarding) rules are configured. SIP client sends keepalives all the time, so dynamic rules are there all the time for both - UDP/5060 and UDP/13000. But ports opened statically suck
2) If I try to configure SIP inspection (CBAC) to force my router to open proper inbound (from WAN) ports dynamically everything works again. SIP packet payloads are inspected and the router pre-opens proper inbound ports by looking at the negotiation data between the client and the server.
It also works with older IOS when I configure zone-based firewall inspection. as it acts the same way as "classic" CBAC.
3) However when I try to use zone-based firewall with recent IOS and use 'match protocol sip' statement in inspection class-map, incoming calls do not come through, no inspection rules are created and audit trail shows me that connection is dropped all the time stating reason as "SIP protocol violation". The problem is that latest IOS performs not just lookup of ports to be opened, but total inspection of the whole dialog between a SIP client and a SIP server and drops session when it discovers protocol violation.
I tried to enable debugging and saw that everything starts fine, but when FPL SIP server responds it uses some "not-documented" or "not-complaint" protocol extension which cisco router does not recognizes, considers it malicious and drops the connection.
I was able to make a workaround by using access-list with UDP/5060 port instead of 'inspect protocol sip' in inspection class-map. In this case my cisco router was "fooled" and considered this traffic as "some UDP protocol". After that it opened proper dynamic connections for both control (UDP/5060) and data (UDP/13000) traffic. But I am not sure it will work the same way with hardware VOIP gateway as it may not initiate outgoing connection to SIP server for VOIP data traffic as PFL client does.
I also tried to use third party software client (X-TEN, X-LITE) with other SIP server (JustVOIP in my case) and everything worked like charm - exchange is fine, no errors, dynamic inspection rules are created etc. I HAVE NOT tried third party softphone or VOIP gateway with SIP settings from FPL as I am yet to buy one.
So HERE IS MY QUESTION: Is FPL SIP server is NOT RFC complaint and uses some "customized" protocol for BOTH - FPL software client and hardware SIP gateways or there is a slim chance that if I buy setup file and configure third party VOIP hardware/ SIP software client, everything would be different? Or FPL SIP server uses some latest extensions to SIP protocol and latest cisco IOS just not aware of them?

[bridonca]

Wow, this is so new to me. There is an actual standard for SIP over NAT? Does it actually work? Obviously, tongue is in cheek here, but this Cisco RFC standard seems either a little too proprietary, or is so awful, it never took off. It amazes me I am so ignorant on this.

My experience with Cisco is with their consumer routers with their embarrassingly crappy stock firmware, and their NAT hostile consumer ATA's. I could never get stable SIP VOIP until I upgraded the router firmware to DD-WRT, and manually forwarded the needed ports to the ATA. I had these issues with many other SIP providers also, so I concluded SIP over NAT standards are still a fiasco.

Because of my ignorance on this topic, I cannot be much help to you. I can only say FPL seems to have done fine without RFC compliance, and that is only assuming it does not have, of which have no clue either way. I do know that when FPL switched from Cisco ATA's gear to Grandsteam ATA's, the complaints went down quite a bit. I have no doubt Cisco makes some nice enterprise gear, the consumer gear, not so much.

Do you know of other SIP providers that are RFC complaint? I would like to test my PAP2 on it, and see it's reliability.

[tbrummell]

So, you are using the FPL softphone, and are trying to inspect it for SIP compliance? It doesn't have to be SIP compliant, it's proprietary. If you want to reliably test them for SIP compliance, pay the $50 and have SIP access opened up for your account.

[Ice]

I'll start off my saying I don't know, I have no idea, can't answer your question - you may want to take your question offline directly with Kris (admin) or Steve (fpl-steve). I've looked at some of the session data for connections but never at the packet level.

Following that though, some thoughts - tbrummel makes a very interesting point. Are you using the free softphone (only) or the softphone after paying the $50 access fee? I haven't looked much into this myself, but there's talk online about the connection being encrypted/etc because open access would otherwise require the $50 fee being paid. In other words, the free connection may (or not?) be proprietary and non-compliant in order to protect Freephoneline from unrestricted free access. The packets could be encrypted and/or could involve/include Freephoneline-specific headers/etc that you wouldn't see otherwise. Then again, maybe not.

I know after paying the fee, I've had some problems getting 3rd party services to work with some devices while other devices work without any problems, or it works if connected directly without a 3rd party service. After some troubleshooting, I turned to other solutions... while this may not answer your question, it does lead me to realize something didn't add up - which service/device was to blame I don't know (nor have I revisited it).

If you have a friend who has paid the fee to Freephoneline, I'd see they'd be willing to test their account on your connection. I'd reckon it take an hour or less and you could work out the details to minimize missed calls, etc.

Long story short, I'd just stick to one of your workarounds since it's a home solution anyways. I know of some homes with fancy setups, but it shouldn't rival or stop you from using a workaround. If you need a more rugged line (for business use or other), their parent company (Fibernetics) offers a business-quality service as well. Alternatively, there are other VoIP providers who will provide a DID/etc too but aren't free but may suit your needs better.

[olegmz]

OK. Today I did purchased PAP2T-NA VOIP gateway and configuration file for my account. After I setup the device according to recommendations. The only addition I made is enabling NAT keepalives to make sure dynamic NAT translations from VOIP device to WAN would exist as long as devide is online. So I do not have to worry about static NAT rules and and about IP address of the VOIP client. And I can have software VOIP clients running on computers in addition to PAP2T-NA at the same time as long as they use different accounts.
However it looks like that FPL SIP server implementation does not follow published RFC3261 standard which is used as a basis for inspection in cisco IOS. I configured both my accounts on PAP2T-NA - for FPL and JustVoip (each on a separate line) and both worked fine with "generic" inspection - when the router does not "recognize" UDP/5060 as SIP protocol, but treats it as a generic UDP connection. The connection for voice data is built with help of configured NAT keepalives and is treated the same way. As a result I can make incoming and outgoing calls no problem (well, justvoip is outgoing only by definition, but this not an issue.)
But as soon as I change the config to use "true" SIP inspection, FPL stops working and I see a bunch of error in logs related to protocol errors.
Just in case someone is interested here is the log quote:

000556: Apr 16 16:48:03.113 EDT: CCE: At least one mandatory header field for NOTIFY is missing

000557: Apr 16 16:48:03.113 EDT: CCE: mandatory: 524000288280, headers_found: 13400028A080
000558: Apr 16 16:48:03.113 EDT: CCE: SIP : Mandatory header field missing

000559: Apr 16 16:48:03.113 EDT: FIREWALL sis 84A03FA0: *** protocol error found ***
000560: Apr 16 16:48:03.113 EDT: %AIC-4-SIP_PROTOCOL_VIOLATION: SIP protocol violation (Mandatory header field missing) - dropping udp session

At the same time justvoip line works absolutely smoothly, building proper connections and communications. No errors in logs whatsoever.
As long as "workaround" with generic inspection works it is not a big concern for me. This is just a home phone line, not a corporate solution after all.

But it would be nice to know for sure if it is true, or I do miss something in my config and FPL SIP server is not to blame.

[curriegrad2004]

When I use the ip_nat_sip ALG, which similarly does what your cisco switch is doing, it does all the NAT transversal circus without any real issue at all from FPL's server. Is it your switch that's not recognizing the SIP packet properly? Or there's the possiblity that the netfilter team did some trickery for non-RFC compliant SIP packets...

And if you're interested, the SDP header describes that FPL uses Sippy as their server... not too sure if it is, but may as well is.

[watermark]

I encountered a similar problem few months ago. FPL voice data could not go in our firewall/NAT device - Foritnet Fortigate. UDP 5060 SIP messages were fine (100/183/200 request/trying/OK). However, inbound RTP packets didnot reach FPL softphone or 3rd party sip client such as Asterisk behind the firewall. The problem seemed that firewall failed to get the dynamic open rtp port info from the sip packets. I sniffered and found FPL used non-standard 5061 port for additional sip communication if my memory served correctly. I know Fortigate has a built-in sip proxy and works fine with many other sip proxies. It seems a bug of the FPL sip proxy.

[olegmz]

I sniffered and found FPL used non-standard 5061 port for additional sip communication if my memory served correctly. I know Fortigate has a built-in sip proxy and works fine with many other sip proxies. It seems a bug of the FPL sip proxy.

Non-standard port should not be a problem actually. Most of firewalls allow to specify custom port numbers for any protocol in addition (or even instead of) well-known values. However in this case port UDP/5061 is a SOURCE port of the client, not the DESTINATION port on the server which is UDP/5060. Source port may be random and may be set to different values.
If application inspection AKA application layer gateway (ALG) is working it will inspect outgoing connection from the client to the server to port UDP/5060 (and it does not matter which one was the source port) and builds appropriate flow state (remote IP:port - local IP:port). In addition it will check for payload (ALG part) and look for interesting ports. As an option it may just open a bunch of pre-defined ports without any actual packet payload inspection. This is often used in consumer grade devices and is called trigger ports.
Both software client and hardware gateways like PAP2T-NA have an option to enable keepalives to keep dynamic NAT and flows alive so you would not need to bother about creating static NAT translations (and preventing flows and dynamically opened ports alive if ALG is used).
My problem was that latest versions of IOS perform deep packet inspection and granular exchange control. So if something is not accordance with RFC standard it is considered protocol violation and connection is dropped immediately.
If FPL uses Sippy it is kinda strange, as this server claims to be RFC complaint. But who knows... I do not have much time now to dive very deep into this stuff right now. My workaround with configuring the router to treat SIP as a generic UDP in conjunction with NAT keepalives work so far. Maybe I will try to run wireshark, sniff packets and see who is a culprit one day. We'll see..

[watermark]

I checked the sniffer and found 5061 was just the contact info in the 200 OK packet from FPL:
Contact: "Anonymous"<sip:208.65.240.142:5061>

The sip client response via 5060:
ACK sip:208.65.240.142:5061 SIP/2.0

I doubt FPL sippy uses something strange. Regarding the "FPL sippy - firewall - sip client" scenario, NAT keepalive just help firewall forward incoming source 5060 in. In order to forward rtp voice data, firewall needs to open wide possible udp ports, or has capacity of finding out the message like "m=audio 35880 RTP/AVP 0" in the sip packet, and open that rtp port dynamically. Cisco IOS CBAC has this capacity.

[olegmz]

NAT keepalive just help firewall forward incoming source 5060 in. In order to forward rtp voice data, firewall needs to open wide possible udp ports, or has capacity of finding out the message like "m=audio 35880 RTP/AVP 0" in the sip packet, and open that rtp port dynamically. Cisco IOS CBAC has this capacity.

NAT keepalive prevents dynamic NAT translations, created by the client (by sending packets from inside the network to remote SIP server) to timeout. In case applicetion inspection is used it also prevents dynamic port forwarding entries in a connection state database to timeout also. In order to send and receive calls the firewall needs both - NAT translations and appropriate ports to be opened. Dynamic NAT(PAT) does the first part, application inspection does the second. You can replace any or both parts with static rules if you want.
CBAC (context based access control) in latest IOS has "simplified" version of application inspection, in comparison to zone-based firewall with MPF and deep packet inspection.
As I said in my first post - CBAC works just fine, as well as zone-based firewall on older IOS. But latest IOS does look much deeper into every SIP packet. It is possible to compare request and response, check and drop connections if username or server domain name is incorrect, allow only certain types of commands. As an added "bonus" this inspection drops the session if it finds non-complaint message exchange, and there is no way to disable this feature.